When label does not fit below icon, render label on top or side

[kocio-pl]

In places, where there is a lot of icons and names to display, carto is performing quite bad, because it always try to render icon with text under it, and when there is not enough space, it simply hides them. However HOT does it better - it tries to move the names so they don't overlap and don't have to be hidden.

Example - all 6 names instead of just 4 on the same zoom level (in the centre, top left corner of Francuska nad Walecznych crossing):

http://www.openstreetmap.org/#map=19/52.23517/21.05308
http://www.openstreetmap.org/#map=19/52.23517/21.05308&layers=H

[matthijsmelissen]

I think the relevant part of their code is:

text-placement-type: simple;
text-placements: "S,N,W,E";
text-dy: 12;
text-dx: 12;

[kocio-pl]

Could someone test it (and maybe also make the appropriate patch for osm-carto)?

[gravitystorm]

@kocio-pl If you need any help installing Tilemill or setting up your development environment, we'd be happy to help. It's much better if we have more people working together on this!

[kocio-pl]

I plan to do it, but currently I have much less time to play (new job...).

[matthijsmelissen]

@kocio-pl Out of curiosity, which operating system do you use?

[kocio-pl]

Ubuntu. I have just installed TileMill and it works. =} Where should I read next instructions to make my "development environment" working?

[matthijsmelissen]

Installing it on Ubuntu should be straightforward.

Next step would be loading the data: http://switch2osm.org/loading-osm-data/

We still don't have a single page explaining (or referring to) all steps, do we?

[matkoniecz]

@math1985 AFAIK no, and I may make one - see #657

[SomeoneElseOSM]

@kocio-pl (for info in case you haven't already seen it)

https://www.mapbox.com/tilemill/docs/crashcourse/introduction/

is a useful "tilemill introduction" - it also includes the basics of connecting to a database. Then load a small amount of OSM data only into a database - for me an English county works OK on an oldish laptop. Then export the stylesheet using "carto" from the command line rather than using TileMill's export, and point your rendering database at it. I've been meaning to do a "TileMill" companion page to http://wiki.openstreetmap.org/wiki/User:SomeoneElse/Ubuntu_1404_tileserver_load for a while but haven't got around to it.

[matthijsmelissen]

@kocio-pl I described the process in #657 (comment).

[kocio-pl]

OK, the TileMill is filled with the carto of the whole country (Poland), but it works painfully slow - database reads the disk all the time, even when the most layers are hidden, while memory and CPU are not that busy.

I also see only 4 tabs: style.mss, shapefile.mss, landcover.mss and water.mss and don't know how to see all the others.

I see that saving the project refreshes the map, so I know how to test my changes. But what should I do next? Where to export and how (there are many formats and zoom levels available)? And what to do with the slowness of my - rather contemporary - laptop?...

[kocio-pl]

Let's get back on topic again - there is more stuff about label placement, i will check it later:

https://www.mapbox.com/tilemill/docs/guides/labels-advanced/

[pnorman]

My concern about text-placements is that we could end up moving the icon in one direction and the text in another.

[matkoniecz]

@kocio-pl

it works painfully slow

I was working with a data for a single city obtained from Overpass API (Kraków) and it worked even in VM.

I also see only 4 tabs: style.mss, shapefile.mss, landcover.mss and water.mss and don't know how to see all the others.

It is necessary to edit in external text editor due to tilemill bug - see https://github.com/mapbox/tilemill/issues/190

Where to export and how (there are many formats and zoom levels available)?

I was exporting png of random location in five cities, for zoom levels 15 to 19 (see exporting from comand line on https://www.mapbox.com/tilemill/docs/manual/exporting/ ) - than publishing before/after images as a github repository.

And what to do with the slowness of my - rather contemporary - laptop?...

My solutions were to load smaller amount of data and script entire exporting so I can do something else as computer works (unfortunately script was lost in HDD crash - but it was a trivial one).

[kocio-pl]

@mkoniecz: In the meantime I've just found another workaround - I couldn't pass the z=8 with the whole country, so I hide most of the layers, zoomed to the chosen city (names layer was visible), and then I was able to switch on all the layers and it works reasonably fast (sliding is smooth, refreshing map is about 10 s).

You were only showing few small areas just as a proof, not the whole city etc, do I remember correctly?

[kocio-pl]

@pnorman: What do you mean by "moving the icon in one direction and the text in another"? Is it just about not-so-nice rendering or (maybe) something else?

As an avid big-city micromapper I can definietly say we've reached the point we need something to do with "invisible" POIs, because there are too many of them now - and it will get worse. Some very attractive places, like shopping or eating zones, are now half-readable, because we miss many names and, perhaps, some icons as well. Adding another zoom level would improve this situation, but I haven't heard it will happen anytime soon with OSM-carto, and sometimes the geometry is against us ("shopping/eating street" going vertically or even diagonally makes some POI names/icons conflicting).

The good news is that when there isn't too dense POI area, the rendering is as usual - this funny placement is enabled only when there are some conflicts of such points, so I think no one gets hurt by this. The other good news is we can try to squeeze a bit (N,S,E,W+NE,NW,SE,SW) or be more conservative (only N,S,E,W - exactly like on the HOT layer, you can check if it is acceptable for you). I don't know if the additional tweaking is possible here (both random placement and avoiding roads from the Mapbox tutorial require some database mangling), but even the simple HOT approach would be a blessing for me.

[matkoniecz]

@kocio-pl

You were only showing few small areas just as a proof, not the whole city etc, do I remember correctly?

yes, see #668

[pnorman]

@pnorman: What do you mean by "moving the icon in one direction and the text in another"? Is it just about not-so-nice rendering or (maybe) something else?

If you have one POI collide and shift its text east and another to the east collide and shift its icon west, you could end up with a confusing rendering.

[kocio-pl]

I don't think icons are shifted at all - it's all just text position mangling. What do you think about current HOT rendering, do you find it troublesome somewhere?

[matthijsmelissen]

I don't think icons are shifted at all

I think so too.

[matthijsmelissen]

And what to do with the slowness of my - rather contemporary - laptop?...

Poland is unworkably slow on my laptop too. Luxembourg works fine. I would expect that a single city or maybe even województwo should be fine.

You were only showing few small areas just as a proof, not the whole city etc, do I remember correctly?

Of course, if you are sending a pull request (or refer to a branch in your repository) everyone who has Tilemill set up can test for himself.

[matthijsmelissen]

Adding another zoom level would improve this situation, but I haven't heard it will happen anytime soon with OSM-carto

Technically OSM-carto is not the restriction, for example in Tilemill you can render tiles up to zoomlevel 22 with openstreetmap-carto. The restriction is a setting on the openstreetmap.org rendering servers.

[matthijsmelissen]

Renamed issue to more descriptive title.

[polarbearing]

This might be related, two adjacent Kindergartens:
http://www.openstreetmap.org/#map=17/52.46723/13.68515
http://www.openstreetmap.org/way/48080469
http://www.openstreetmap.org/way/300235641

Löwenzahn is labelled from z17,
Unterm Regenbogen never gets labelled,
probably due to its shape with a narrow centre, though there would be space in the bottom part.

[matthijsmelissen]

For this, we need text-placements, which does not seem to be supported in my version of Mapnik:

[tilemill] * attribute 'placements' with value 'N' at line 0

Does anyone know when text-placements was introduced?

[gravitystorm]

It's in mapnik 2.1 - see https://github.com/mapnik/mapnik-reference/blob/master/2.1.0/reference.json#L1569

[matthijsmelissen]

Strange. Does anyone else can get it to work?

[kocio-pl]

Back to business - I'll take a second chance on rendering at home:

@matkoniecz:

I was working with a data for a single city obtained from Overpass API (Kraków) and it worked even in VM.

I would like to try Warsaw, but don't know how to do it - can you help me? Overpass-Turbo Wizard does not allow me to get naive "* in Warsaw". What are the exact steps to obtain a single city data then?

[matkoniecz]

@kocio-pl

My method is described in point 1b in https://github.com/matkoniecz/bicycle_map_of_Krakow/blob/master/readme.txt

Numbers specify limits of bounding box so it is necessary to adjust values to download a different city (osm file for Kraków and nearby areas is 216 MB, it may be a good idea to start from a smaller area than a big city).

I based this query on one of examples found on wiki.openstreetmap.org/wiki/Overpass_API (or maybe http://wiki.openstreetmap.org/wiki/Overpass_API/Language_Guide ?).

[kocio-pl]

Thanks! I may try it if I want the most current data, but in the meanwhile I've found https://mapzen.com/metro-extracts/ with weekly data for key polish cities (including Warsaw and Cracow). However I was surprised that Cracow and nearby areas (Krakow_Poland) PBF file is only 15 MB. Why so big difference between your data and Metro?

[matkoniecz]

PBF format is more space efficient than .OSM (it is XML, famous for lack of space efficiency).

Note that Mapzen covers larger area, so this difference is even more significant.

Main benefit of downloading from Overpass is that I am frequently noticing problems in data. I may edit and within minutes (Overpass replication lag) it is possible to download a new version including my edit. It allows me to test rendering with a correct tagging.

[kocio-pl]

Metro OSM file is about 450 MB after bunzipping, so it may be true (they may use bigger box).

[kocio-pl]

At last I've made the test using @math1985 hint from #957 (comment). Because unlike the HOT style we have many types of objects, I applied those settings for shops and food/drink amenities for a start.

Simple retail area

before:

after:

Complex retail area

before:

after:

Complex amenity area

before:

after:

[pnorman]

How do they compare for cut off labels at metatile boundaries?

[mboeringa]

@kocio-pl , while a good idea to ensure stuff gets labelled, this also means a lot more labels in already overcrowded map areas. From a cartographic point of view, I would therefore suggest not to swap this this labelling for the existing one, but use a two stage approach instead:

• Current labelling when zoomed out, preventing overcrowding of labels
• Switching to this new labelling only at the very highest zoom level(s). It is likely even only really appropriate on Z18 or Z19 for features like shops and amenities like restaurants and pubs.

This way, you get the best of both worlds: a less crowded map when zoomed out (a bit), and stuff properly getting labelled when zoomed in.

[kocio-pl]

@mboeringa Thanks, you're right! HOT has much more subtle POI rendering so it works good there, but we have strong colors, so I moved it to z19 - this way it acts mainly as a substitute for higher zoom levels. First two examples are already on z19. For the eating amenities I could not spot any place where z19 would be still such a visible problem (the rendering is taken on z17), but they are common meeting places, so the name is even more important than for shops. Any other suggestions of improvement?

BTW: how should we avoid duplication of code here? Most of z>17 and z>19 sections are the same, except few labeling statements, and I'm not sure how to make it in the most elegant and readable way.

@pnorman I don't really understand your question (and the problem too, I guess), maybe somebody else could answer?

[matkoniecz]

@kocio-pl For start see https://www.mapbox.com/tilemill/docs/guides/metatiles/

[matkoniecz]

@kocio-pl

For the eating amenities I could not spot any place where z19 would be still such a visible problem

http://www.openstreetmap.org/#map=19/50.06048/19.93860 http://www.openstreetmap.org/#map=19/50.06423/19.93783 ?

[kocio-pl]

I didn't say I can't find any problems with amenity labeling. =} Parts of the "Complex amenity area" example also has the labeling problem at z19, but I consider them (and your examples) to be fairly small compared to some shop areas - no need to render again, I guess.

I'm aware of what the metatiles are, but I don't understand what @pnorman asks about them here. What difference could make just relocating of some labels in this context?

[pnorman]

I have a strong preference for keeping z17-z19 consistent in rendering rules.

What difference could make just relocating of some labels in this context?

If the text placement is shifted in different ways in different metatiles for the same text, it will result in cut off labels.

[mboeringa]

If the text placement is shifted in different ways in different metatiles for the same text, it will result in cut off labels.

How does HOT, or for that matter any other project using Mapnik and this type of more flexible labelling, solve this issue? It seems to me that this type of labelling by itself is quite normal.

I have a strong preference for keeping z17-z19 consistent in rendering rules.

While I fully understand the difficulties of managing multiple types of rendering and render rules in a style like this one, I do think at some point cartographic output dictates that maintaining the same render rules across three zoom levels, may not be feasible... I can't tell if that is the case here, but three zoom levels is a pretty huge difference in terms of labelling options and label "space".

[kocio-pl]

While I fully understand the difficulties of managing multiple types of rendering and render rules in a style like this one, I do think at some point cartographic output dictates that maintaining the same render rules across three zoom levels, may not be feasible... I can't tell if that is the case here, but three zoom levels is a pretty huge difference in terms of labelling options and label "space".

+1

My primary background in OSM is micromapping and I like the "mappers' map" concept very much, so I care more for showing the data we have than keeping the map surface clean (we have MapQuest Open for this already), so I for one would not object too loud for keeping the smart labeling in the whole POI range.

But see how serious are people regarding to POI clutter - we even have the separate issue around just one of the rarest places, and the problem is spotted on just one of zoom levels (Too many icons at z17?)! It surprised me a lot that a single, visually moderate - IMO - problem can create such a strong response. So I try to play safe here. My ultimate goal is to let people see the basic properties of POIs (type and name) on the map. With smart labeling just on z19 my goal is reached and I see no need to create more clutter at lower zoom levels.

I just treat z19 as a special "last zoom level". If we will eventually get z20 rendering one day, I will check if we still need the smart labeling at all and would move it there, because that would be the last resort for people to see the named POIs on this map.

[pnorman]

How does HOT, or for that matter any other project using Mapnik and this type of more flexible labelling, solve this issue? It seems to me that this type of labelling by itself is quite normal.

I don't know if or if not it will cause problems, which is why I asked. As for other stylesheets, I'm not aware of any which have as many point/center of area based labels.

While I fully understand the difficulties of managing multiple types of rendering and render rules in a style like this one, I do think at some point cartographic output dictates that maintaining the same render rules across three zoom levels, may not be feasible... I can't tell if that is the case here, but three zoom levels is a pretty huge difference in terms of labelling options and label "space".

There's a few cartographic reasons. One is that you want to keep the map from having too many different overall appearances and feels, drawing emphasis to different features on different zoom levels.

Another reason particularly relevant for POIs is that choosing what not to render is an important cartographic choice, and deciding to render everything is often a cop-out to avoid saying no.

In this case, I don't see any reason why z17-z19 can't be the same for text-placements. I can't see anyone mentioning that text-placements has bad results on z17.

[pnorman]

We might need to increase the minimum distance between labels

Right now, all labels are below icons, so it's normally clear what they belong to. In the example above, it's not clear if Matras is the shop to the left or below.

The distance from the icon to text placed on the right seems inconsistent.

[gravitystorm]

I just treat z19 as a special "last zoom level".

Be careful with this. One of the goals of the stylesheet is re-usabiilty, and even without making any changes, other people use these stylesheets on tileservers that have different zoom ranges available. Sometimes it stops at 18. Sometimes 22. So don't make too many assumptions based on what the 2 OSMF tileservers are doing - focus on the cartographic reasons to make a decision instead.

[kocio-pl]

@pnorman

Right now, all labels are below icons, so it's normally clear what they belong to. In the example above, it's not clear if Matras is the shop to the left or below.

It makes me think a bit longer, but then it's clear to me that it's always centred somehow, so Matras must belong to the POI below. People mark the POIs by hand, so in many cases it will be a useful hint.

The distance from the icon to text placed on the right seems inconsistent.

I guess the distance is measured from the whole icon box, not from the visible pixels, so most probably this might be a problem with different width of visible images.

@gravitystorm Thanks for bringing it on the table. As I said, this problem is secondary for me, so I will be happy in both cases of smart labeling (z17+ or z19+).

We have conflicting values here: straight labeling is more clear, but we lose some important informations, while smart labeling is quite the opposite. Going to z19+ with smart labeling would be kind of practical compromise between those general rules. We can also make another practical compromise: let's check how many deployments of osm-carto do we know and how many levels do they use. If something changes in the future, we can tweak again.

General rules are good thing, but there are always some practical limits and goals - I believe showing the names is one of very important goals for end users. How we should do this is a matter of weighting the importance of different rules and the costs.

[kocio-pl]

Sometimes it stops at 18. Sometimes 22.

Is it possible to start using variable called "zmax" maybe? Then we would apply smart labeling always at the very end of the zoom scale, no matter which one is used for given service.

[pnorman]

focus on the cartographic reasons to make a decision instead

Circling back to this, is there a reason not to use text-placements on more than one zoom level?

[kocio-pl]

I mentioned one reason already: the fear of the clutter at some zoom levels, especially the entry one for such POIs (namely z17). I could not however say if it's "cartographic" or not.

[kocio-pl]

Is there still some interest in this solution or is it problematic?

[daganzdaanda]

I dislike the big text-dy gap that we need now. So I wouldn't mind changing all the labels to sit on one side (right?) of the icons.
I don't think that an automated random placement left/right/below will work very well. It would need a lot of "padding" to make sure that it's always clear what is labeled. In the end, we would probably hide more POIs than necessary.

[kocio-pl]

There is no way to have consistent gap, because icon shape is within certain matrix (usually 14x14 px), but does not always touch the (bottom) border. Changing the side to some other fixed one does not help this problem, because some shapes are tall and don't touch the left/right border too. Or rather there is a way - we would have to change all the icons to touch given border - but those shapes would be then shifted from the centre and it is just a different problem which may be either better or worse.

I also believe that dynamic placing helps show more than with static placing - or at least not less.

[matthijsmelissen]

I have experimented a bit with left/right placement, but the results were not really legible. With left/right placement, it became very unclear which labels were connected to which icons. Sorry, no screenshot anymore. I therefore think alternating bottom/left/right-labelling is not viable, so I'll close this ticket. Feel free to open a new ticket for other ideas, such as right-only labelling.