User talk:Sanderd17/Areas
| Proposal | Avoid overlapping lines | Avoid fictional lines (avoid splitting homogeneous areas) | Partial (unambiguous) downloads | Big features (needs partial download) | Immense features (coastline) | Store tags only once | Replaces current area types (ultimately) | Deprecates area tags on closed ways |
|---|---|---|---|---|---|---|---|---|
| Current state | Possible | no | no | yes | no | no | ||
| Simple Features | no | no | yes | area object will be too big, but doesn't need full download | yes | Yes, 2 new types | yes | |
| Areas on Nodes | no | no | no | yes | yes | yes | ||
| Areas on Ways | yes | no | no | yes | yes | yes | ||
| Areas on Nodes or Ways | yes | no | no | yes | Yes, 2 new types | yes | ||
| User:Sanderd17/Areas | yes | yes | Intended, but not in current state | area object will be too big, but doesn't need full download | yes | yes | yes | |
| User:Zverik/Areas | yes | yes | Intended, but not in current state | yes | Yes, 2 new types | yes | ||
| Tagging Outline Ways | Not if >1 area per boundary side | Yes, but limit of one area object / way side | no | yes | yes | |||
| Triangles (tesselation based areas) | yes | No, will cause fictional lines for every area | yes | area object will be too big, but doesn't need full download | yes | yes | yes | |
| Super Areas | yes | Not applicable | Yes (aggregation type) | yes | Extends upon any other type(s) | yes | ||
| Super Multipolygons | yes | Possible, depends on fixed multipolygons and recursion | yes | Revision of current types | yes | |||
Notes on table changes (above)
I've taken out column "clear distinction between area and way type", since this solely depends on a community decision for all proposals given. E.g. if the future convention will be to not use/allow closed ways as area anymore, than anything relation-based will just as clearly distinct areas from ways as something new top-level-type-based.
If, after a new top-level type is introduced, closed ways (and/or relation-based stuff) are continued to be used (or decided to be kept for compatibility reasons+nostalgia), we won't get that clear distinction either. So we can't give a clear yes or not for any of the proposals, imho. Maybe Can act as replacement for all other area types in use now is a fit criterion - but that info has better granularity by the three columns partial download, big and immense features already. --Cmuelle8 (talk) 04:37, 12 January 2016 (UTC)
I've reworked the table layout somewhat, added a column about the deprecation of areas on closed ways and grouped the three columns needing partial download capability using colspan. - please comment..
I suppose, Zveriks proposal has the same problem as yours, currently. Using a single reverse flag on ways is not enough to define an inside, if holes are involved, unless you define insides of individual rings may not be larger than half the sphere's surface. But even then, he will have to know if he's dealing with parts of inner or outer rings, because having parts only he can't decode any orientation. A part might have either been reversed because it did not fit the clockwise orientation of a segmented inner ring, or because it didn't fit the counter-clockwise one of a segmented outer ring, he simply won't know. --Cmuelle8 (talk) 01:14, 14 January 2016 (UTC)
The column "avoid fictional lines (split river)" was reordered, it directly relates to the three columns talking about partial downloads, it kind of repeats properties. Also Super Multipolygons were meant to target just that, allow very long area boundaries. I assume you put a "no" only, because they extend multipolygons, which we agree are not disambiguous on partial downloads.
Btw, we should ask ourselves, if partial data needs to be disambiguous for editing purpose. It might be true that you won't be able to render an inside having partial data, but that does not exclude the possiblity to modify boundary parts. E.g. if you have a tile layer in the background this might be good enough for a human editor to determine the inside of partially downloaded boundary segments (of course this is no good, if segments of a broken area not being rendered on a tile layer are downloaded).
Often, if a boundary of a valid MP is to be modified, you will retrieve bbox data using a rectangle on osm mapnik tiles that the valid MP has been drawn to, so a mapper will in most cases know if the area is left or right to the partially downloaded segment (even if the machine does not) --Cmuelle8 (talk) 02:12, 14 January 2016 (UTC)
Notes on your proposal (article page)
In section "consistency checks", the line
outer-most rings (when seeing the world as a rectangle rather than a sphere) should be ordered counter-clockwise
needs rework, imho. The proposal should not relate a counter-clockwise orientation to the world being a rectangle or a sphere, since the cw/ccw orientation solely results from the inside of an area being left or right to its outline/ring.
- If we define left side of a closed way to be the inside of an area: It will either run clockwise or counter-clockwise around that inside.
- Your proposal defines the inside to be always left side of a counter-clockwise oriented, closed ring. If a ring definition consists of
- a single closed way only, then decoding asserts, after rev-flag is processed, three things
- that the inside is left side of the way,
- that the way runs counter-clockwise around that inside and
- that the inside is the same as the one encoded.
- two or more ways with non-varying rev-flag values, then decoding asserts the same (if either none or all of the ways changed direction between encoding/decoding, if some change, even with referential integrity assured, see below).
- two or more ways with varying rev-flag values, then decoding asserts the first two things of the list above, but not the third. This is because your proposal has neither excluded the possibility of ring insides larger than half the sphere's surface (correct?) nor allows definition of anchor members in rings propagating their orientation to the rest of members. Or simpler: You cannot reconstruct the original orientation of the ring.
Decoding area objects according to your current proposal it cannot be determined why members have had their rev-flag set. It might have been set (or not) at definition time both, because they ran against a counter-clockwise perimeter around the larger inside (of two possible insides for a ring on the sphere) or ran against a counter-clockwise perimeter around the smaller possible one.
An example to illustrate: We've had Antarctica's coastline, lets build on that. Say that Antarctica's area is represented by an outline ring made of two joinable ways. We define inside of Antartica to be left side of first way (#10), and right of the second way (#20). According to your proposal this is
<area>
<ring>
<way id="10" reverse="false"/>
<way id="20" reverse="true"/>
</ring>
</area>
for Antarctica |
<area>
<ring>
<way id="10" reverse="true"/>
<way id="20" reverse="false"/>
</ring>
</area>
for all but Antarctica |
But when decoding this, we've lost the information about the orientation of the ring at definition time. The decoder does not know that for these rev-flag values inside was defined to be the smaller of two possible surfaces when concatenating #10 and #20 and so it might have been the larger as well. Since there is no anchor member, Antarctica might be interpreted as all but Antarctica and vice versa.
Imho, you can work around this problem
- by attributing rings with a reverse flag also and
- defining the smaller possible surface (of two definable by a ring on a sphere) to always be the inside of unreversed rings, i.e. rings attributed "reverse=false".
It might have implications on the section Determining outer vs inner as well. --Cmuelle8 (talk) 04:37, 12 January 2016 (UTC)
Actually you can't reconstruct/decode a correct orientation (and hence inside) for the non-varying case either. The chance is, even if we have referential integrity, that at definition/encoding time, without any rev-flags applied, all segments are oriented in the same direction; in the meantime one (of many) segments might change direction, the area object is updated; the next time the area object is decoded, it will have varying rev flags, the same issues as above apply. So we can not separate both cases.
Note that this issue is a little different than what we have discussed on my user talk page. Closer to the end of the thread we had focused on whether left;right coding is sufficient to tell apart inside;outside of an area presuming that all of the rings were oriented a specific way at definition/encoding time - and it is, but wrt your proposal only as long as a ring consists of a single member/way. In its current form, if a ring consists of more than one ways, with referential integrity assured, ring objects are ambiguous at decoding time. --Cmuelle8 (talk) 15:59, 12 January 2016 (UTC)