Add boundary= aboriginal_lands, national_park, and protected_area to polygon keys #3785
Conversation
jeisenbe
changed the title
|
It seems that rebase is missing or Github is making some mistake - see list of commits |
Adding these two features to the local polygon values list in openstreetmap-carto.lua will allow these features to be imported as polygons so that they will render properly
pnorman
force-pushed
the
national-park-closed-way
branch
from
8173d0c to
8141f3b
Compare
|
This came up with a few of them - for work on the schema change stuff you want to start with a checkout of To fix it I took the relevant commits, rebased to remove the commits between them and v4.21.1, then rebased those commits onto schema_change. |
|
Sorry! I’ll check for that next time
|
I'm not sure on this. If we wanted to change this, wouldn't it also apply to other |
The wiki pages and taginfo data for boundary=aboriginal_lands, boundary=national_park, and boundary=protected_area show that these features can be tagged on closed ways, not only on relations. I thought that boundary=administrative is supposed to be tagged on relations, not on closed ways. But according to the current wiki page this is possible: https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative "Because ways have a maximum number of nodes, you are not required to loop around a whole administration with a single way to form a closed area (although this is a good idea for very small administrative areas)" If this statement is correct, I could add another PR that would address boundary=administrative, or just import the whole boundary key as polygons when mapped as closed ways. The other common values of boundary=* with >1000 uses, and their definitions:
It looks like we won't be rendering any of these. But only boundary=marker (which should only be mapped as a node) would be a problem if imported as a polygon |
|
I'm iffy on this change, but need to sit down and think about why. |
|
I've updated the branch. @pnorman have you had any time to think about this? I think we should support closed ways for protected areas and national parks, or else the long-standing wiki documentation that suggests this mapping method needs to be changed. |
|
@pnorman - had you had a chance to think about this one? |
|
@pnorman are you available to review this? Does anyone else have thoughts about importing this |
|
Including boundary=administrative on ways would go against long-standing practice, so I'm against that. To me, it's always been type=boundary, boundary=* relations. |
|
OK. |
|
@pnorman and @matkoniecz - what are your thoughts about this PR, which does not address administrative relations? I just edited a few protected_area relations near my home town, and many are mapped as closed ways. These are rendered if they are tagged leisure=nature_reserve because leisure=* closed ways are imported as polygons, but if they are boundary=national_park or =protected_area they are not rendered. I believe we should fix this inconsistency. |
No. My view is that these should be on relations, where type=boundary will cause them to be processed as boundaries, not on ways. |
|
That view is not consistent in the wiki documentation and current use in Taginfo: https://wiki.openstreetmap.org/wiki/Tag:boundary%3Daboriginal_lands: https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dnational_park So all 3 mention that closed ways are an option (the last is implied by suggesting adding area=yes), and in fact ways are more common for 2 out of the 3 features. There are twice as many boundary=protected_area closed ways than relations. Why should mappers need to convert a simple way into a relation with 1 member or add |
|
We are currently only rendering There are
And with leisure=nature_reserve
In the past it was stated that we should not render a feature if adding Based on our policy, we should remove rendering of boundary=national_park, and boundary=aboriginal_lands for consistency, if this PR is rejected. I am willing to consider this as an alternative - and I believe @imagico was already in favor of removing protected areas rendering in favor of more clearly showing landuse/natural areas. |
National park is kind of a contentious tag that is used in cases it should't be to make currently none rendered protected area classes and other things render. Its also been floated in more then a few places that it should be depreciated. So, that would be a good thing IMO. |
@pnorman, I'm sorry that this is a long message. We're dealing with a complex issue here, and your repeated one-line statements such as the one above (or an earlier one where you simply shared words to the effect that you had a bad feeling about it), don't really provide a framework to address your concerns. I'd appreciate if you could read through this message and correct my reasoning. I've done enough map rendering by now to understand why administrative boundaries need a particular treatment. I intend to discuss below the reasons that they do, and the information that is garnered from the ways, and from the relations. The other The classic In particular, drawing the border of the (multi)polygons will ordinarily draw the shared border in opposite directions, because the renderer walks polygons according to the right-hand rule. If different administrative levels are represented by different dash patterns, as is common, then the dash patterns will be obscured or even spoilt by the overdrawing. The boundary relations are then used to give the topology, so that a data consumer can look at them and distinguish the inside and outside of an administrative region. This information is necessary if regions are to be shaded, for label placement, for statistical analysis, and so on. Ordinarily, you'll have an isolated administrative region only in particular cases. It happens often in New York for Villages and Hamlets, which are often isolated and not surrounded by other districts at Side note: As it happens, I haven't checked whether there are villages and hamlets around that are represented by single closed ways, rather than having boundary relations. Promoting those to boundary relations would certainly be a task for a mechanically assisted edit! (I never do full-up automated edits, everything is checked by eyeball and the JOSM validator before upload.) I had not recognized until fairly recently that having a closed way in place of a boundary relation is a data integrity issue for these; it seemed to me that the way could still be rendered linearly (and would not be shared with a neighbour, so there would be no dash-pattern confusion), and the fact that the way is closed would give the topology, so thanks for the heads-up! By contrast, In other words
Another side note: Akwesasne is a unique case where the claim of the Six Nations of the Haudenosaunee crosses the international border between the US and Canada. While neither of the larger powers recognizes Haudenosaunee autonomy, the Six Nations have from time to time issued passports, fielded Olympic teams, and performed similar minor functions of a sovereign state. There is at present no passport control for Akwesasne inhabitants within its borders. Attempts to institute such controls have been made multiple times by both the larger powers. The result has generally been violent protest. I'd tag this particular area as a de facto So, to my mind what's important is:
Aboriginal lands should be treated the same way as administrative regions if they fit into the jurisdiction's administrative structure and are expected to share boundaries. There's no convincing reason why New York's Indian Reservations could not, for instance, be surrounded by National parks and protected areas are not ordinarily expected to share boundaries, so the problem of double-rendering is less of an issue. For clean rendering, shared borders should be conflated where possible, which then requires the creation of multipolygons (or boundary relations, but mappers have consistently used multipolygons for these). I'm tentatively against elevating the should in the last sentence to a must, simply because existing renderings do not generally adopt a visual style that is confused by adjacency. @pnorman, have I adequately summarized your concerns? Given this summary, is there a way to go forward without retagging thousands of protected areas? Does it suffice to have the following rules? (a) Two regions of the same type (administrative, national park, aboriginal lands, protected area), if they have a border in common, should have that border represented by a shared way. (b) If a shared way is used, the two regions must be represented by I could see these rules extending to any type of area where the rendering emphasizes the border, rather than simply filling the interior or providing an interior highlight on the border. There may be other objects (some land uses or land covers, perhaps) that fit the pattern; I've not done any detailed investigation into how others render these. In any case, it's a separate discussion. |
...
Given these numbers I guess we should add it. I'm not particularly overjoyed about the current representation in the data. |
Agreed. So while we should add these features to the polygon list in lua, we might also want to reconsider whether they should all be rendered. |
I think the same arguments could be made for removing rendering of national parks and protected areas as there is for the removal bays and similar things. No clear boundaries, rendering encourages inaccurate tagging and mapping etc etc. |
|
Regarding the change - i think that is fine although i also don't really like the ambiguities in tag use this would support. Regarding stopping rendering of protected areas and other non-general-administration boundaries - yes i think from a cartographic viewpoint it would be good to drop those, for reasons explained in #3887 (comment) and #3887 (comment). But this is very different from the considerations for bays and straits. For bays and straits all arguments and evidence speak against the current rendering, for protected areas it is a matter of cartographic preferences and of making best use of the limited map real estate to show map users the most meaningful data in a way that is well readable. Even if objective arguments can be made (like i linked to above) it is ultimately a matter of setting priorities. @kennykb - i think most of what you write about is outside the scope of this issue tracker. But what we definitely do not want to do here is pushing mappers to map things in a way that is convenient for us. If mappers map things consistently in a certain way that is difficult for us to properly render it is our task to deal with that, not to try nudging the mappers to change their habits to make things easier for us. |
|
This is the one schema change that we still need to discuss before the next
release
My thought is that we should import closed ways as polygons with these tags
because mappers are often using them in this way.
If there is consensus that this mapping method is a serious problem, it
would be better to remove rendering of protected areas entirely, rather
than requiring mapper to add ‘area=yes’ or create single-object
multipolygon relations to force rendering.
In that case we still ought to import these closed ways properly in case
other adaptations of this style wish to render such features.
(I have been guilty of using both those options myself as a mapper, and one
of my changesets was criticized for creating multipolygon relations out of
a single closed way.)
|
I believe they should continue to be rendered, and don't see any connection between that and this issue. |
Fixes #1141
Changes proposed in this pull request:
This should be merged to the schema_changes branch so that it can be deployed when the database is reloaded