bugMapOSMatic - Bugs: bug #27467, Some streets of the index are not...


bug #27467: Some streets of the index are not visible on the map

Submitter:  David Mentré <dmentre>
Submitted:  Thu 17 Sep 2009 09:39:56 AM UTC
Category:  ocitysmap Severity:  3 - Normal
Priority:  * 5 - Normal Status:  Confirmed
Privacy:  Public Assigned to:  dmentre
Open/Closed:  Open Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Wed 13 Jul 2016 11:36:06 AM UTC, comment #13: 

Mapnik bug tracking has moved to GitHub, the new upstream bug URL is


Hartmut Holzgraefe <hartmut>
Group Member
Sat 31 Mar 2012 10:35:56 AM UTC, comment #12: 

New B&W stylesheet now displays more streets. But smaller names are still not displayed.

David Mentré <dmentre>
Group administrator
Sun 08 Jan 2012 04:29:42 PM UTC, comment #11: 

I tested with Mapnik 2.0.0: the bug is still there! (i.e. street name does not appear in short streets)

David Mentré <dmentre>
Group administrator
Sun 01 Jan 2012 05:40:48 PM UTC, comment #10: 

A job to test the rendering engine: http://dev.maposmatic.org/jobs/301

David Mentré <dmentre>
Group administrator
Wed 13 Jan 2010 07:18:16 PM UTC, comment #9: 

Keep in mind that 25000x25000 pixels is roughly 2.5Gb (as ABGR) of raw image data, giving a clue as to why cairo refused to save Rennes at z=18 to PNG.

Jeroen van Rijn <jvrnix>
Group Member
Wed 13 Jan 2010 07:17:10 PM UTC, comment #8: 

Yep, crash is very early on PNG file. It seems to me that there is an hard-coded limit inside Cairo. One should check with Cairo's code.

David Mentré <dmentre>
Group administrator
Wed 13 Jan 2010 07:04:19 PM UTC, comment #7: 

Doesn't crash: ./ocitysmap-render -z 18 -c Rennes -f pdf
Crashes: ./ocitysmap-render -z 18 -c Rennes -f png

Backtrace gives the impression that either Cairo itself, or libpng as used by it can't handle 22750x24780 pixels. Which isn't surprising, entirely. I'll copy/paste the PDF rendition into the gimp and save as PNG, see what it does.

I'll also investigate backends for Cairo other raster formats than png. Perhaps it can be made to render to bmp or tiff, have ocitysmap not crash on zoom level 18, then run: optipng -o7 /tmp/result.bmp ?

Jeroen van Rijn <jvrnix>
Group Member
Wed 13 Jan 2010 06:50:36 PM UTC, comment #6: 

Regarding 0.7.0-rc1, it changed nothing: street "Jacques Ange Gabriel (Rue) ... J11" does not appear at zoom level 16 neither 17 (ocitysmap crashes at zoom level 18) for city "Rennes" (in France, has administrative boundaries).

David Mentré <dmentre>
Group administrator
Wed 13 Jan 2010 05:14:05 PM UTC, comment #5: 

I'll see if I can find some time later this month to do one of the following, or both:

- Implement ./ocitysmap-render -z auto
(auto mode would bump the zoom level to 17 or 18 if the area covered by the map is below certain thresholds, e.g. <25km2, zoom 17)

- Investigate Mapnik stylesheets, as per Dmentré's suggestion on #maposmatic.

dmentre: I see the bug has a milestone of 0.80 on mapnik's trac, did the 0.70-rc do anything at all in regards to labels being dropped?

Jeroen van Rijn <jvrnix>
Group Member
Mon 21 Dec 2009 04:00:31 PM UTC, comment #4: 

Documentation of TextSymbolizer:

David Mentré <dmentre>
Group administrator
Mon 21 Dec 2009 03:35:21 PM UTC, comment #3: 

Here is the part of osm.xml that handles the residential and unclassified streets at zoom level 16 :
<Style name="roads-text">
      <!-- ici -->
      <Filter>[highway] = 'unclassified' or [highway] = 'residential'</Filter>
      <TextSymbolizer name="name" fontset_name="book-fonts" size="9"
      fill="#f00" halo_radius="1" spacing="300" placement="line"
      avoid_edges="false" allow_overlap="true"/>

But we are in the case where the street name is longer that the line that supports it.

Unfortunately, this is a known issue in current Mapnik: Mapnik cannot render street name longer than the corresponding line. See this a recent thread:

The bug is known in Mapnik: http://trac.mapnik.org/ticket/13

David Mentré <dmentre>
Group administrator
Thu 17 Sep 2009 10:42:23 AM UTC, comment #2: 

I do think this is a real issue regarding the usability of the map: not being able to see the street renders the map useless.

Now, regarding the way to solve this, we could boost the zoom level to 17 or more or make our own map style-sheet. Experimentation is definitely needed here.

David Mentré <dmentre>
Group administrator
Thu 17 Sep 2009 09:53:53 AM UTC, comment #1: 

It's the street from the "Quai de la Prevalaye" to the recycling POI. Definitely a zoom issue. There's a dilemma here: what do we do with streets whose names aren't displayed on the map? I don't think we should remove them from the index, since the square indication can still help locate the street. But we also can't put the names of all the streets in the city as they sometimes don't fit.

I think this is a low-priority problem since the map and index, as-is, can still provide helpful information to locate the street and direct the user into the right 500x500m square. Finding the street then is not as hard.

Also, this specific problem can be solved by the "downtown" zoom box, which is a feature we haven't yet implemented.

Maxime Petazzoni <mpetazzoni>
Group administrator
Thu 17 Sep 2009 09:39:56 AM UTC, original submission:  

Some streets of the index are not visible on the map.

For example, in "Rennes", "Jacques Ange Gabriel (Rue) ... J11" is not visible on the map.

It could be a zoom issue.

David Mentré <dmentre>
Group administrator


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

No files currently attached


Depends on the following items: None found

   task dependencies.


Carbon-Copy List
  • -email is unavailable- added by hartmut (Posted a comment)
  • -email is unavailable- added by jvrnix (Posted a comment)
  • -email is unavailable- added by mpetazzoni (Posted a comment)
  • -email is unavailable- added by dmentre (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2010-01-13 jvrnix Dependencies- task #9917 is dependent
    2009-12-21 dmentre StatusNone Confirmed
        Assigned toNone dmentre

    Back to the top

    Powered by Savane 3.12