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.
[firstname.lastname@example.org] 171_449.png was uploaded in error and can be removed.
[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?
[paul] Replying to [comment:2 artem]:
What are the options?
Place text label on straight line between start/end points?
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] 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 [http://local.google.com/?ie=UTF8&ll=41.95582,-87.705917&spn=0.016149,0.028067&z=15&om=1 Google] can do it, so should Mapnik ;)
[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] 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!
[springmeyer] Reid, collecting geometries like you mention above should now be possible, in a performant way, using PostGIS and the BBOX substitution and the ST_COLLECT or ST_UNION (ideally in postgis >=1.4) functions (along with a GROUP BY) as seen in #415.
New readers: See this long thread: http://lists.berlios.de/pipermail/mapnik-users/2008-January/000553.html
...culminates in solution to pre-process shapefile geometries by collecting adjacent linestring segments into multilinestrings, which can also be done on-the-fly when using a postgis datasource (see examples with #415).
[springmeyer] see also: https://savannah.nongnu.org/bugs/?27467
In a brief discussion with #maposmatic developers we considered that various potential solutions to label overflow could be to:
1) continue the line/char placement in the angle of last char placement (straight)
2) continue in an interpolated arc (curved)
3) attempt to break the line to create a shorter-wrapped line (break)
[Ldp] Option 3 is what I usually see used in commercial city maps.
Also, I've never really understood why the ticket would say 'exceeds width of the line', when clearly the length of the line was meant. The width of a line has no impact whatsoever on the label. Changing the ticket title accordingly.
[springmeyer] automatically shrinking text is an option:
[artem] Ok, as a first attempt to solve this issue we could try :
This should be optional e.g symbolizer paramater.
Our current approach uses PostGIS is to chain neighbouring road segments that have the same name. We also take into account other attributes that may influence the rendering of the street name (e.g. colour of the halo determined by the type of road and colour of the text determined by whether it is in a tunnel or not) To prevent all the road segments named "high street" to be one geometry in the database, we subsequently dump the chained segments like so:
CREATE TABLE nw_named as select name, frc, fow, freeway, net2class, oneway, shieldnum, feattyp, partstruc,
(ST_Dump(ST_Linemerge(ST_Union(geom3857)))).geom AS geom3857 FROM nw where "name" IS NOT NULL
GROUP BY name,frc,fow,freeway,net2class,oneway,shieldnum,feattyp,partstruc;
Another approach to shorten the labels instead of using a condensed font, suggested in the blog posting by fellow countryman Hans van der Maarel, would be to offer the label placement routine multiple columns from the database with ever shorter versions of the street name. From Hans' example:
For now, you could join the table with the road segment geometries with the table containing the street name spelling alternatives and order the joined table by the length of the street name. Longer street names are placed before their shorter spelling alternatives. Downside: it exponentially grows the already huge table of road segments.
more discussion at a downstream issue: http://support.mapbox.com/discussions/tilemill/2313-labels-extending-past-geometry-line
Still a must have feature.
QGIS default Parallel placement:
Not sure if this is still an issue closing for now
Is this really has been fixed?
Right, not fixed and we should expose and option to do what QGIS allows. Thanks for the graphic @Andrey-VI.