Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

non-geometrical members of a boundary relation treated as boundary #678

Closed
polarbearing opened this issue Jan 26, 2017 · 6 comments
Closed

Comments

@polarbearing
Copy link

polarbearing commented Jan 26, 2017

A boundary relation can have way members that describe the geometry of the boundary, such as outer, inner, and the deprecated enclave and exclave. Other members should not be treated as geometrical descriptions, such as admin_centre, even when they are ways and not nodes.

See gravitystorm/openstreetmap-carto#2559 for the effects of this issue, where a townhall is the admin_centre of various boundary relations, and the boundary style is rendered on the building outline.

Thanks @pnorman for pointing me here, help would be appreciated to create the test case.

@lonvia
Copy link
Collaborator

lonvia commented Jan 26, 2017

That's just plain wrong tagging. admin_centres should be place nodes, nothing else. Let's not add support for degenerating multipolygon/boundary/route relations into a collection of anything remotely related.

@polarbearing
Copy link
Author

admin_centre is an inherent part of the boundary relation, not something remotely, and not anything. Restricting tagging to a node is unreasonable.

The fundamental issue is that only roles defined for the geometry of the relation should be white-listed as such, and not any other way (i.e. catch-all).

@lonvia
Copy link
Collaborator

lonvia commented Jan 26, 2017

admin_centre was defined as a place node until you've changed the definition in the wiki yesterday. Do you mind linking to the discussion that prompted that change?

@polarbearing
Copy link
Author

Discussion page on the wiki page.

@lonvia
Copy link
Collaborator

lonvia commented Jan 26, 2017

Sorry, but this is not enough of a discussion. This seeming little change breaks pretty much any software that processes boundaries. I've reverted the change in the wiki page. Please bring up the issue on the tagging@ mailinglist for wider discussion first.

Closing here, as this is a tagging discussion, not a software issue.

@lonvia lonvia closed this as completed Jan 26, 2017
@polarbearing
Copy link
Author

Tagging discussion opened.

not a software issue.

Disagree here, it is a software issue (catch-all implementation) that is now triggered by a tagging choice. I propose to re-open.

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

No branches or pull requests

2 participants