Modify

Opened 13 years ago

Closed 13 years ago

Last modified 10 years ago

#6523 closed enhancement (fixed)

Enhancement [patch] Recognize boundary relations and handle them as multipolygons

Reported by: Don-vip Owned by: team
Priority: normal Milestone:
Component: Internal mappaint style Version: latest
Keywords: Cc:

Description

Boundary relations are widely used [1] to map areas [2].
Their design is like multipolygon: one or more sets of ways tagged as "outer" or "inner". In France, the roles "enclave" and "exclave" are used for administrative boundaries, with the same graphical meaning as outer and inner.

JOSM does not currently treat these relations as areas, that forbids to define custom stylesheets for them. Moreover, enclave/exclave roles are unknown.

Please find attached a suggested patch that resolves these two issues, an example of stylesheet and its graphical result.

[1] http://taginfo.openstreetmap.org/tags/type=boundary#wiki
[2] http://wiki.openstreetmap.org/wiki/Relation:boundary

Attachments (3)

patch_with_enclave_exclave.txt (13.5 KB ) - added by Don-vip 13 years ago.
result_with_enclave_exclave.png (186.6 KB ) - added by Don-vip 13 years ago.
Styles_EPCI_France-style.xml (1.3 KB ) - added by Don-vip 13 years ago.

Download all attachments as: .zip

Change History (18)

by Don-vip, 13 years ago

by Don-vip, 13 years ago

by Don-vip, 13 years ago

comment:1 by stoecker, 13 years ago

Whereas supporting boundary as a sort of area type is ok, I don't think we want to support the exclave and enclave roles. They are superfluos and could easily be replaced by inner and outer.

comment:2 by Don-vip, 13 years ago

Alright :)

comment:3 by bastiK, 13 years ago

So shall we simply change isMultipolygon()?

comment:4 by anonymous, 13 years ago

Fine for me, I didn't choose this option because I was afraid of potential side effects I wasn't aware of.

in reply to:  3 comment:5 by stoecker, 13 years ago

Replying to bastiK:

So shall we simply change isMultipolygon()?

I think so. Yes.

comment:6 by stoecker, 13 years ago

Resolution: fixed
Status: newclosed

In [4213/josm]:

fix #6523 - handle boundary like multipolygon

comment:7 by Don-vip, 13 years ago

I remember now why I didn't choose this option: there's a sideeffect in JOSM validator: A warning is raised at validation (Non-Way in multipolygon) when the boundary contains an admin_centre node.
The problem is checkMembersAndRoles() method of MultipolygonTest: the error must only be raised with real multipolygons and not with boundaries.

comment:8 by stoecker, 13 years ago

In [4219/josm]:

see #6523 - don't warn for admin_centre

comment:9 by anonymous, 13 years ago

"Exclaves" just have to be mapped with the "outer" role, listing their defining ways after the ways for the main "outer" ways, each one in order. The optional various exclaves should be listed preferably in decreasing area order (so that the most important features appear first in the list), after the main area (also defined with "outer" roles).

  • For each group of ways defining an exclave, these ways will be grouped together, so that they appear connected in the list (reorder the ways if needed).
  • Finally it should be better to sort these member ways (if there are several) so that they connect in counter-clockwise order (only meaningful if there are at least 3 ways in it), so that the inner points remains on the left side of the connected ways (however this is apparently not a requirement and it seems to work in wellknown tilers). Note that when you have multiple ways defining an area, shared by adjoining separate areas (this is effectively the case between neighouring administrative areas), it will be impossible to enforce the direction within each member way (so ignore the direction up/down of arrows appearing in the list).

You should list all "enclaves" (mapped with the "inner" role assigned to their defining ways) just after the main area ou "exclave" in which they are present: first define the "inner" boundary of the hole in the containing "outer" area, then list the enclaves with "outer" role as well.

  • These enclaves should be preferably listed also in decreasing surface order, so that the most important enclaves (islands) within an hole appears first, before the smaller ones.
  • Here also, if an hole is defined with several member ways, these member ways should be connected together in the list, but now preferably in clockwise order (so that the inner points remains on the left of the connected ways).

We can then easily determine which enclosed area is the main area, or an exclave (outside the main area and listed after it), or an enclave (listed after the "inner" hole in its containing area (itself main or exclave). The relative order of member ways and how they connect together in the list order (or with the first way of each area) will immediately reveal their role.

Note that JOSM should be able to sort the list of inner and outer ways in a relation itself, without depending on us sorting the lists manually in the interface (JOSM can even compute the effective surfaces for each area). This would avoid manual search and many zooms trying on the map just to figure out how to connect these ways. JOSM should even be able to do that automatically if we split or merge ways that are a member of any relation.

comment:10 by anonymous, 13 years ago

I have also a warning four the role "label" added to a multipolygon. Currently, JOSM just accepts interconnected ways, but nodes present in it can only be a single "admin_centre".

One example: Metropolitan France is defined with a multipolygon containing two sublists of way (the first interconnected sublist for the continental part, including territorial waters, the second interconnected sublist for Corsica, which is an exclave). Its "admin_centre" is inserted to include the capital (Paris). But this node is not the best location for labelling "France".

Tilers try to figure out where to place the country name, by just using the center of the bounding box of all ways, but this is in some case not very convenient is the boundary is concave (on that case, the displayed "name" property of the boundary will not be at a convenient location, and may even fall outside of this area.

As well, the "admin_centre" may not be central in the boundary (this is the case for Paris which is decentral, more to the North).

We need another place for better locating the label (here "France", not "Paris"), and the documentation says we can insert a node with role "label" for that.

But JOSM complains that this is not a way, and makes no exception other than allowing only an "admin_centre" (and in fact it also silently accepts several "admin_centre" in the same boundary). Instead, it should accept any number of isolated nodes within each boundary, provided that they have distinct roles (excluding "inner" or "outer" reserved for ways defining the boundary).

It should even accept an "admin_center" defined as a relation (another boundary) instead of a just a single node (that other relation will contain the "admin_center" node), recursively. But the "label" role should only be a single node having the "name" property (and all other information about the label only : translated names fo rthe country, population of the country, wikipedia reference, country codes, ...).

I would also prefer to have the "is_in" property deprecated for subdivisions:

  • Instead, we should be able to list other relations as members of a boundary, using the "subdivisions" role.
  • For example we would first list the 22 administative regions of Metropolitan France, as members of a new separate relation (which may be named "Régions de France") of type "subdivisions" containing the 22 boundaries of regions
  • Then we would just have to insert this "Régions de France" relation as a member (with role "subdivisions") of the boundary for Metropolitan France.
  • Some administrative areas will need several subdivision hierarchies, that may overlap together, but organized differently (e.g. in France we have "pays (loi Voynet)" that may span communes of several departments or even several regions, such as Pays de Redon): they are not direct descendant of either regions or departments or arrondissements: this is a separate collection, which does not cover the whole directory (by the list "pays (Loi Voynet)" contains no pair of pays that are overlapping).
  • Each kind of subdivisions may be listed in a separate relation, but all these relations should be listable as members of the country, by adding each one with the role "subdivisions", which will offer a possible choice of subdivisions hierarchies. For example we would have a member with role "subdivisions" linking to the list of 22 administrative regions that are fully covering and tiling France, and another linking to the collection of pays (Loi Voinet) named "Pays (loi Voynet)" that are partly convering and tiling most of France.
  • We could aven add non-administrative subdivisions as well (such as historic provinces, cultural areas. For each hierarchy, this would be a relation of type "subdivisions", containing the various boundaries of the same type (or assimilated types for the defined subdivisions type : e.g. Corsica is not formally a "région" but a "collectivité territoriale", but may be listed in "Régions de France").

comment:11 by stoecker, 13 years ago

JOSM does not sort relations automatically. This would violate API. Users can do so themselves in the relation editor with the help of the editor and the results is near to what you want.

Most of the other stuff you talk about does not belong here. This is an bugtracker for the editor. Standardization about how and what to do belongs to different places.

Regarding "label". It is still not properly described anywhere how this should be used and whether anyone really supports it. So josm still does not include it yet.

comment:12 by anonymous, 13 years ago

Regarding "label", it IS documented directly within the wiki page describing keys for administrative boundaries, along with the "name" property of a boundary, it cites the member elements that can be placed in it:

  • connected ways for the "outer"/"inner" role.
  • an optional node with role "admin_center" for placing and naming the administrative capital/center,
  • and an optional node with role "label" to override the "name" property of the boundary itself (and other translations or info about the area limited in that boundary, such as "wikipedia"), and locate it in a more convenient location than the default one which does not always fit correctly in the boundary (notably when it contains holes or exclaves very far away, because the label by default is just place in the center of the bounding box, which may not be within the area).

Note: I don't see why sorting the member ways to connect the boundaries in the correct best order, would violate the API. This is not different from reordering members manually, except that it can fully be sorted this way automatically, instead of having to lookup each way (most of them being given only numeric IDs, we have to zoom on each one to see how to interconnect them: JOSM can autodetect ways that are interconnected with a common node, it can detect ways whose interconnections form a loop and close these loops, it can then compute the effective area (ignore the number of nodes within them, it's not significant) of each closed area, and reorder these loops automatically, it can also detect closed loops that are within each other; it can then detect those loops that have the wrong "inner"/"outer" role or missing this role, and signal them (and propose a fix for these incorrectly assigned roles); other member ways that are assigned other roles than empty/inner or outer should be left untouched.

Of course this can only occur in JOSM, with user supervision, and not automatically on the server, because a map could be saved in an incomplete state with missing ways, or unexpectedly overlapping ways, or ways with incorrect geolocalisation (which cannot be fixed automatically). The fix should be proposed and not forced (for example a user may have moved inadvertantly a closed boundary on the map with the mouse.

Anyway, I think it could be a good idea to have an "outer" loop of ways defining an exclave labelled with a distinct role, notably for exclaves. It would allow detecting boundary relations that contain ways outside of the first closed area, which should enclose all the other ways, and which should then have the role "outer" for all its ways. The other ways will either be closed inner ways signaling holes, or outer ways within such hole. In a boundary, all ways should be closed, or interconnected to creater a loop.

And closed ways (or closed loops of multiple interconnected ways) should have no intersection of their stroke (all closed areas in the boundary must be fully inside or fully outside of another one: this can also be checked automatically, by just seeing that each node of ways defining a closed inner or outer or exclave area are either fully inside or outside of the other area: just check the even/odd parity of the number of strokes at the same latitude or longitude, the algorithm is straightforward).

comment:13 by anonymous, 13 years ago

Another possible check: all member nodes of a boundary relation should also be within the inner part of the boundary (excluding holes defined with the inner role, but reincluding enclaves that also have the inner role but within an hole area): this can help detect nodes that were incorrectly selected in the JOSM editor and added inadvertantly to the boundary relation, or detect ways that have inadvertantly modified by moving some of its nodes, or by inconsistant/imprecise updates to the geolocalisation of these border ways during some imports.

comment:14 by Don-vip, 13 years ago

Please, this is NOT the place to have such a huge debate on boundaries.
This ticket aimed only to make JOSM recognize relations as areas for editing purpose, it's done.
If you think JOSM has a deffect in boundaries handling, please open a new ticket.
If you just want to debate, the mailing lists and Wiki Talk pages are designed for that.

comment:15 by Don-vip, 10 years ago

Ticket #7550 has been marked as a duplicate of this ticket.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.