Talk:The Future of Areas/Fixing Multipolygons

What happens, if I will reverse a line which are referenced by ring relation? Who is responsible for changing its role inside relations?

If referential integrity is introduced server-side (which needs to be voted up on), the server will take care to adjust and reverse role of effected relations (unless your changeset already includes updated relations). This is something osm does not have today and something that is hard to implement; a lot of people will vow "that referential integrity for relations" was not checked server-side for ages and that it should stay this way.

Without having referential integrity the client is responsible. Using a client that updates role inside relations itself, implies that the client needs to have the ring relation in the dataset it's working on. This is how relations ought to be updated now and sometimes it breaks them (e.g. if not all referring relations are part of dataset worked on).

If client-based referential integrity cannot be assured for all changesets committed, clients will be able to detect if role information of a partial download is valid with much less effort than with current multipolygons.

Even if we could assure client-based referential integrity for all edits, then an implementation of this proposal allows clients to deal with partial downloads (like e.g. Sanderd17's proposal intended it to be). Clients will be able to use valid role data to determine an interior with respect to the fragments of an area definition downloaded. This is not possible with the current multipolygon documentation/definition in osm. It always needs to be downloaded fully to assemble, regardless of whether referential integrity was hurt in the meantime or not. --Cmuelle8 (talk) 18:39, 19 January 2016 (UTC)

This added robustness may come at the price of having more relation objects in the database (compared to using multipolygons). This is not very true comparing multipolygon relations with a few rings (as one stand-alone ring will in the majority of cases be reused to define what's on both of its sides), but for multipolygon relations containing lots of rings, e.g. those having lots of unnested, simple outer rings:

Consider a multipolygon relation containing 12 unnested, outer rings, each made of a single closed way. There will be two valid equivalents using the ring/polyring proposal:

1. Create a ring relation for each of the 12 closed ways, tag those. (This duplicates some tags, but benefits spatial requests, because a bbox may interset these ever which way. Additionally it has a clear separation between the areas and their outline. If one of the 12 patches changes, tagging that change will be simple.)
2. Create a ring relation for each of the 12 closed ways, add all 12 to a polyring, tag the polyring relation. (If the rings are not re-used in other relations this seems wasteful. But it's more robust against future changes. If some of the rings are segmented, the polyring won't change. If one or some ring changes tags, it may be removed from the polyring definition and tagged stand-alone.)

Consider we have 12 separate parking space areas: A polyring could be tagged with all common tags and the overall capacity (like now, with MPs), but this does not tell us how that capacity is distributed to the 12 patches. If it is not equally distributed we could tag capacity on each of the rings and rely on inheritance for the rest of the tags from the polyring, while the outline tags describe the outline. Of course, they can be mapped without using a polyring, repeating some tags, as well - it's up to the mapper to explicitely aggregate the patches in a relation or not. --Cmuelle8 (talk) 19:29, 19 January 2016 (UTC)

It may be a good schema for polygons and multipolygons if it were accepted before current version of MP relation, but now we have tons of exists relations and quite a lot of software working with them. Nobody wants to rewrite software. How to deal with that? Dkiselev (talk) 19:44, 19 January 2016 (UTC)

It will have to be implemented additionally in software for a very long time (much like closed ways are not phased out for a long time, even though it becomes a popular concept that area tags should be separated from outline tags). I do not propose to change / remove / delete existing multipolygons over night. If the proposal and an implementation is sound, it will be adopted gradually by mappers using it - if they do not find it beneficial, then it is indeed not needed.

Of course this will have an implementation frontier as well, i.e. even if it is beneficial to use it (say josm only has a good implementation), it won't be used if the majority of software driving osm cannot handle or does not recognize it.

I think this applies to the other proposals on the future of areas as well. Unless it can be agreed on to repeat something like we've had with the redaction bot, I see no other option to do it. If you have another idea, post it. --Cmuelle8 (talk) 20:09, 19 January 2016 (UTC)

See, if just the role field of MP is re-stuffed to contain the same information (like suggested at the beginning of the page), the same process would apply, as this will be incompatible with current multipolygons too. So the thinking is, if we extend on "extended or advanced multipolygons" to fix some of their shortcomings, we should think a long time first and then do implementation. I do not think, that this proposal is yet the best way to do it, but it might be a step in the right direction. --Cmuelle8 (talk) 20:14, 19 January 2016 (UTC)