Rendering text labels when point size of labels exceeds the width of the line

[reid@…]

We are building tiles where the point size of line labels can exceed the width of the line. In these case, labels are applied very sparsely (see example tiles).

I don't have a complete example to share, since it would require access to our database, but let me know if you can't reproduce it. I can try to get something out of rundemo.py.

Please feel free to contact me if you need more information or testing.

[reid@…]

orange roads should have more labels

[reid@…]

orange roads should have more labels

[reid@…]

171_449.png was uploaded in error and can be removed.

[reid@…]

yellow roads should be labeled

[artem]

At the moment there are no attempts to find text placement if length of geometry is less than text length : source:/trunk/src/placement_finder.cpp@452#L213

What are the options?

1. Place text label on straight line between start/end points?
2. ???

[paul]

Replying to artem:

What are the options? 1. Place text label on straight line between start/end points? 2. ???

For my applications, the common case is a straight street segment. So having the text label extend proportionally beyond the start and end points of the feature is acceptable.

If I were styling my map and the above behavior were implemented, and a particular were /not/ straight, I would expect the label to follow the feature as currently implemented, and then as it goes "off the edges," it would retain the angle of the last character drawn, like a vector extending out from each end.

[paul]

Highlighted blocks to be labeled

[paul]

Highlighted blocks to be labeled

[paul]

Labels with 3pt font size

[paul]

Labels with 4pt font size

[paul]

Labels at 9pt font size with point placement

[paul]

Highlighted individual segments

[paul]

Desired label layout

[paul]

For an example, I want to label "arterial" streets, highlighted here in red:

(It's worth remembering that these actually individual blocks that combine to appear to be contiguous streets; here is the "inverse", so you can see where the arterial segments are:)

If I use point placement of the labels, say 9pt font size, I get this:

I could control minimum distance and spacing at this point but would still get suboptimal results. Labels need to follow the line of the street. Changing to line placement, labels disappear at 9pt, so changing to a very small size just to see if it works at all (3pt) yields:

Increasing the font size starts to knock out most labels, as they get longer than the length of the underlying feature/block:

What I desire is this (mocked-up by hand in the GIMP):

If Google can do it, so should Mapnik ;)

[paul]

Strange label placement after reducing down blocks to streets

[dave]

I think the strange placement is caused by the text renderer not handling multi-linestrings nicely. If you could send me a small shapefile that can cause it I will investigate it.

[rpriedhorsky]

shapefile which exhibits the bug

[rpriedhorsky]

poorly labeled tile

[rpriedhorsky]

A ping on this bug. I just upgraded to 0.5.1 and it's still present.

The fix that I would really like to see is joining of separate but adjacent linestrings with the same name within mapnik. I had thought (and stated earlier) that this joining could be done in the database. I have not been able to figure out how to do this. The best I can do is to bring the linestrings together as multilinestrings (potentially with gaps), and this still has severe performance problems.

Bottom line: it may still be possible to do this in the database, but I'm not a PostGIS noob and in any case it seems rough to require users to write complex, tricky queries to get this (fairly basic IMO) functionality working.

I have attached two files. 232_2432.png is a rendering taken from our PostGIS database. There should be more labels here: all but the narrowest streets should be labeled at reasonable intervals.

The second attachment is a shapefile extract of our database for the same region as the tile. It is missing a few properties but I don't think they will be missed for this purpose.

Please let me know how I can help improve Mapnik in this aspect. Thanks!