Skip to content
This repository has been archived by the owner on Jul 24, 2021. It is now read-only.

[admin] Better rendering of boundaries that coincide with coastline #4313

Closed
openstreetmap-trac opened this issue Jul 23, 2021 · 4 comments
Closed

Comments

@openstreetmap-trac
Copy link

Reporter: rasher
[Submitted to the original trac issue database at 1.19pm, Friday, 23rd March 2012]

I think it would be a nice improvement to the stylesheet if boundaries that lie on top of coastlines were either not rendered at all, or rendered less prominently (with high opacity maybe?).

Examples:

At least in Denmark, these boundaries are correct, and are in fact defined by the coastline, but I think most maps would only draw the part of the boundary that lies inland.

@openstreetmap-trac
Copy link
Author

Author: Ldp
[Added to the original trac issue at 11.14pm, Saturday, 24th March 2012]

The problem here is that coastline lines and boundary lines in the rendering db are not related at all, when those boundary lines are built from a relation. They're two separate objects. It's even more difficult when the member ways aren't tagged as boundary by themselves.

The only solution I currently see is:

a) Stop rendering boundary relations as lines. Use these only for the name labels.

b) Tag the member ways as boundary. With appropriate highest order admin_level in case where the way is part of multiple boundary relations. The ways will then render as boundary. This also neatly stops the 'stacked boundary' effect.

c) Do not drop natural=coastline ways on import into the rendering db. When a boundary line is also tagged as coastline, don't render it as boundary.

Either that, or you're welcome to write a full-fledged patch for osm2pgsql that will parse boundary relations and filter down their attributes to the member ways, keeping admin_level in check and also fully working with diffs. I think my proposal is easier. :)

@openstreetmap-trac
Copy link
Author

Author: math1985
[Added to the original trac issue at 6.23pm, Tuesday, 10th June 2014]

This is duplicate with https://trac.openstreetmap.org/ticket/4313.

@openstreetmap-trac
Copy link
Author

Author: rasher
[Added to the original trac issue at 10.04pm, Tuesday, 10th June 2014]

4313 is this ticket. Which is the correct ticket?

@openstreetmap-trac
Copy link
Author

Author: math1985
[Added to the original trac issue at 10.26pm, Tuesday, 10th June 2014]

Sorry, should be https://trac.openstreetmap.org/ticket/2670.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant