Opened 4 years ago

Closed 18 months ago

Last modified 17 months ago

#3611 closed defect (wontfix)

private service roads bleeding to much into roads with no access restriction

Reported by: flaimo Owned by: mapnik-team@…
Priority: major Milestone:
Component: mapnik Version:
Keywords: Cc: JoshD, mcld

Description

when mapping a lot of roads with highway=service + service=driveway + access=private, the red color from the private driveways bleeds too much into the public main road to which they are connected to.

example: http://www.openstreetmap.org/?lat=48.24079&lon=14.25934&zoom=16&layers=M

it looks even worse on zoom level 15.

since service roads are less important than residential roads (or higher), the red color shouldn't bleed into them at all.

Change History (8)

comment:1 follow-up: Changed 4 years ago by JoshD

  • Cc JoshD added

I agree this is a bug, however for me it's not a problem, since I split the driveway into two parts, the part that is truly private and the county right of way:
http://www.openstreetmap.org/?lat=38.78494&lon=-77.30976&zoom=17&layers=M

If micromapping then this is also better for routing purposes, since it allows a pedestrian/cyclist to be routed from the road up the ramp and on to the sidewalk. I realize this may be US-centric (or even more local than that!).

comment:2 in reply to: ↑ 1 Changed 4 years ago by JoshD

Let me correct that, it does bleed horribly on zoom level 15.

comment:3 Changed 4 years ago by flaimo

maybe that works out for longer driveways, like in your case, but often the driveway is so short, that it is completely covered by the residential highway on zoom level 15-. yet the red color from the access restriction still shows. i consider this a bug. the residential road is more important and therefor should lay above the service roads when it comes to decide which color to use.

comment:4 Changed 3 years ago by OceanVortex

This problem has always irked me. It makes the map look messy. Not to mention that at zoom level 16, the pink dashes make the way look too wide.

I hope it can be fixed soon.

comment:5 Changed 2 years ago by mcld

  • Cc mcld added

This issue is also irking me. JoshD's workaround is not always appropriate, and there are lots of places on the current map where a private driveway is rendered so it looks like there's some kind of blockage in the road. e.g. http://osm.org/go/0EERddn6X--

I realise that rendering to avoid this is difficult. The problem is not exactly the order-of-render (as #2776 claimed), more that when a public and a private way meet at a node (implying that the node is public, I guess), we'd like the private highlighting not to continue all the way through the "thickness" of the rendered junction. Or I guess one way to address it would be to render private ways (the way and the highlighting) before public ones. Just thinking out loud though.

#4330 is a duplicate of this.

Last edited 2 years ago by mcld (previous) (diff)

comment:6 Changed 20 months ago by hadw

This one annoys me, too.

comment:7 Changed 18 months ago by pnorman

  • Resolution set to wontfix
  • Status changed from new to closed

The "mapnik" component in trac is for the old XML-based openstreetmap.xml stylesheets which are not deployed on OpenStreetMap.org. Since June the default style on OpenStreetMap.org has been openstreetmap-carto, which has its own issue tracker at https://github.com/gravitystorm/openstreetmap-carto/issues.

I'm going to go ahead and close this issue as wontfix to avoid people being confused by it and commenting on it instead of somewhere where it will effect the rendering on osm.org. Closing it doesn't mean the issue won't be fixed in openstreetmap-carto, just that this ticket is against old unmaintained software that has been replaced and this ticket has zero chance of being resolved.

There is an openstreetmap-carto ticket discussing private service ways rendering inside larger streets at https://github.com/gravitystorm/openstreetmap-carto/issues/119.

comment:8 Changed 17 months ago by math1985

For information, this issue has now been resolved. Thank you for reporting it.

Note: See TracTickets for help on using tickets.