Ticket #3611 (closed defect: wontfix)

Opened 3 years ago

Last modified 4 months ago

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

comment:1 follow-up: ↓ 2 Changed 3 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 3 years ago by JoshD

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

comment:3 Changed 3 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 2 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 14 months 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 14 months ago by mcld (previous) (diff)

comment:6 Changed 7 months ago by hadw

This one annoys me, too.

comment:7 Changed 5 months ago by pnorman

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

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 4 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.