Dotted line of private service ways erroneously render inside larger streets

[nidico]

If a way tagged highway=service, service=driveway and access=private branches from a larger street, e.g. highway=residential, the dotted red lines which indicate the private access are rendered on top of the larger street, whereas they should be rendered just until the border of the larger street.

Example: http://www.openstreetmap.org/#map=19/47.29346/12.91515

I assume that might be done with the comp-op property, but don't understand the meaning of the various values. Is there any better documentation available?

[gravitystorm]

(Screenshot for clarity and posterity)

There's no better documentation on comp-op that what you have linked to.

However, it's not comp-op but instead draw-order that would solve this. The trick would be to draw the access dashes immediately after the fill for each road, rather than as a separate layer on top. This way the dashes would be cropped by the fill of the larger road. Larger roads are drawn later, based on their z_order.

It's the same process that prevents the rounded ends of the white residential road fills "leaking" into secondary road fills, e.g.

[nidico]

Thanks for the explanation! This is however a bit too much to fix for me now, so this issue is free for adoption ;)

[dieterdreist]

2013/9/1 Nicolas Dietrich notifications@github.com

Thanks for the explanation! This is however a bit too much to fix for me
now, so this issue is free for adoption ;)

Maybe this could be considered also a mapping problem? I'm usually
splitting the private ways where they leave private ground (e.g. at the
gate, at the border of the parcel) and I don't put access=private on the
short piece that connects the private part with the public road, e.g. here:

http://www.openstreetmap.org/#map=19/42.42997/12.90948

With current highway widths so narrow for high zooms (smaller than a
representation in scale would be) you can solve this problem by
micromapping at least for highest zoom levels (there might yet be some
overlap in medium zooms which should be addressed).

[matthijsmelissen]

Would this problem extend to street names, and (in particularly unlucky situations) to arrows of one-way streets?

[pnorman]

Would this problem extend to street names, and (in particularly unlucky situations) to arrows of one-way streets?

I believe I've seen misplaced arrows, but it's relatively uncommon since normally when you have a one-way and two-way road running parallel for any distance it's a link merging in, and the link is higher level and rendered on top.

[pnorman]

Related problem

http://www.openstreetmap.org/#map=19/40.61463/-89.46446

To some people it's not obvious that there is no access restriction at the intersection.

If the other ones overlaid the red lozenges it might be clearer, like

[dieterdreist]

2013/9/3 Paul Norman notifications@github.com

Related problem

http://www.openstreetmap.org/#map=19/40.61463/-89.46446

IMHO this is one of the situations were being more detailed with topology
(which road continues and which road discharges) can help to better
understand (and represent) this situation, I adjusted it with the help of
aerial imagery, have a look.

cheers,
Martin

[pnorman]

IMHO this is one of the situations were being more detailed with topology
(which road continues and which road discharges) can help to better
understand (and represent) this situation, I adjusted it with the help of
aerial imagery, have a look.

Well yes, there are a number of changes possible to the data that would make this particular occurrence moot. I'm not convinced that the change you did entirely clears it up, as there are still lozenges in the intersection.

[dieterdreist]

2013/9/3 Paul Norman notifications@github.com

Well yes, there are a number of changes possible to the data that would
make this particular occurrence moot. I'm not convinced that the change you
did entirely clears it up, as there are still lozenges in the intersection.

Yes, these could indeed be solved (in general and for generalized mapping
approaches without particular detail about where the private access starts)
with the solution partially described above (render access-hatches right
after the filling for each road, and render first access-private roads
fills and hatches and then other roads because of situations like this,
where roads with the same road class discharge into each other).

However also in this situation it seems as if more positional detail about
where the access starts would solve this as well (from the aerials there
seems to be the actual fence (or similar) after ~15m from the crossing of
the center lines, so splitting the way and removing the access-private for
the part before the fence would solve this also for lower zoom levels and
would be more precise).

[matthijsmelissen]

I solved this problem (including pnorman's version) in pull request #175.

[matkoniecz]

There is a small glitch that is consequence of this bug - access=no may be drawn over other access=no, resulting in darker pink dot: http://www.openstreetmap.org/?mlat=50.06840&mlon=19.91194#map=19/50.06840/19.91194

[matthijsmelissen]

To be honest, I don't think this is a consequence of the same bug. I also don't see a solution right away, does anyone know if there exists a solution?

[pointhi]

I'm only understand the basics of CartoCSS, but I think I know the bug:

Actually, I think the rendering sequence is like that:

• rendering low streets (as example teritary)
• rendering higher streets (as example secondary)
• ....
• rendering the dots to display the access

To solve that, ways with dots must rendered first, also, the dots must render while drawing streets, not at the end after drawing all of it. As example:

• rendering low street with dots
• rendering low street without dots
• rendering higher street with dots
• rendering higher street without dots
• ....

[matthijsmelissen]

Yes, your analysis is right. I have already solved this, and the solution has been merged, so it should appear on the main map as soon as @gravitystorm creates a new release.

[gravitystorm]

The release has been tagged (v2.7.0), it's just winding it's way through the deployment system :-)

[Rovastar]

How long does it take to things to wind through?

I thought it would be a couple of days but some change seem to be taking longer

[matthijsmelissen]

The original bug as reported by @nidico has been solved in 81d6ba2.

The problem reported by @pnorman is still open, it has been reported as #245 so I propose to discuss this issue there.

The problem reported by @Bulwersator has been solved in 81d6ba2 as well.

This issue can now be closed.

[nidico]

Yep, great, thanks!!

[pointhi]

how I see, the update is now active. Only the tiles must be rendered new. Thanks.