Talk:The Future of Areas/Areas on Nodes or Ways

Simplicity and Efficiency

Efficiency - I don't know if we care about how big the XML gets...allowing a "simple" area (which is just an area with the outer tag dropped) doesn't make my parsing code any simpler since I have to handle outer/inner anyway. But it does make files smaller. I'm not sure which is more important. Dropping an outer tag is a relatively trivial 'tweak' compared to the complexity of parsing the current spec we have now.

--Bsupnik 02:41, 11 April 2011 (BST)

By "efficiency" I don't mean just XML representation, but the actual data model, be that XML, in-memory objects or a database. XML is actually the least important one because there are alternative ways of serializing OSM data (PBF, ...) and because it is relatively easy to parse XML.

Introducing "simple areas" also reduces the complexity of "complex ares", because then you don't really need to support a mix of way and node references. --Breki 04:40, 11 April 2011 (BST)

outer/inner

Why do we need to state topology in tags? This can be determined by software, like it is now. Just <ring> should be enough. --Zverik 14:51, 11 April 2011 (BST)

Now it's not determined by software (at least none that I know of, and certainly isn't determined by Maperitive (which I am the author of). It actually isn't that computationally easy to determine outer/inner relationship, and we would be making life for mobile applications (one example) much more difficult if we left it for them to do this. The amount of world data grows and grows and even small tasks which look simple may end up a heavy burden in the long run. It also leaves the determining of topology to various interpretations, so we are not solving the current ambiguity problems with multipolygons. --Breki 18:39, 12 April 2011 (BST)

As far as I understand the term topology - the program Mapgen.pl actually computes this. But: it's a PITA and I don't whish my fellow programmers to have the same task. Once for programming, but this has to be done only once. Second for computing. Since with growing number of multipolygons, their members and the nodes of these members the effort you have to put into this task grows - and does so not linearly! Each polygon has to be checked against all others - from one multipolygon. Each point has to be checked whether it is inside or outside of another polygon - at least to an extent. My point is: I would like to see a data structure where a) the ways/nodes are already at hand and ordered and b.) the layer could be determined easily - preferably read. --Gary68 11:41, 13 April 2011 (BST)

I think this does at least bring up a point to be examined: how are the contours interpreted into a point set (area)? We could use inner/outer, direction of winding, or even an even/odd rule. (Think of how you would rasterize a polygon.)

Why examine this? Because polygonal data can contain junk (e.g. self intersecting ways) at least by our strict standards of inner/outer, etc. It would be good to know how the line data is interpreted into areas and what error reconstruction if any clients should do, so that error reconstruction can be the same.

For example, if a major map client can use an even-odd rule for self intersecting ways, there isn't a lot of motivation for casual mappers to ever fix the data. At least with the coastline tags, I've had to spend some time going "how the heck does the map show that feature if the data is 'wrong'?".

Anyway, there might be schemes like even-odd for polygonal areas that wouldn't require inner/outer tags. --Bsupnik 12:21, 19 April 2011 (BST)

This is the best solution so far + a few thoughts

I like this solution because it is a "shape construction" logic in itself; it shouldn't matter what 'form' it has (whether it contains ways, multiple ways or just nodes), it describes a "filled object" whose construction (rendering) method need not depend/impede upon (or be confused with) other attributes (such as relations) that should be reserved for other roles than describing shape.

The simplest of simple areas could be as follows:

<area>
    <building = "yes"> // rendering 'color' information, could be "grass", "concrete", etc.
    <anyotherkeys = ... >
    <nd ref="1" />
    <nd ref="2" />
    <nd ref="3" />
</area>

...the above node rendering process could default to an "outer" role (if there was no role="outer" key).

<area>
  <building = "yes"> // rendering 'color' information, could be "grass", "concrete", etc.
  <anyotherkeys = "..." >
   <outer>
    <way ref="1" />
    <way ref="2" />
    <way ref="3" />
  </outer>
  <inner>
    <nd ref="1" />
    <nd ref="2" />
    <nd ref="3" />
  </inner>
</area>

... this is just the existing example with added "key" attributes.

This system would also be useful for a problem I have heard a lot about, the rendering of large areas (needing many 'chained' ways): The area in question's keys could be attributed to its <area> tag, and the actual shape-rendering left to the ways/nodes within without ever having to resort to searching relations (and keys from other ways) for construction - in fact, a rendering engine would only have to look within the <area> (say, "Pacific Ocean") for the ways needed to render it within the existing viewport, and fill the created form (even an 'unclosed' shape) accordingly.

Creating shapes in this way would eliminate the need for the 'multipolygon' key, and could perhaps leave the 'relation' key to a more useful and coherent purpose: data relations.

Any thoughts? Cheers.ThePromenader 07:55, 19 April 2011 (BST)

ADDENDUM: Yes, I know that this will "break the system" if it is implemented as is, but there are ways around this. With all the open questions about its implementation/schema, Open Street Maps data, I'm sure, will have a new version eventually, and any implementation such as this one could be incorporated into it. It is entirely possible to imagine a script that would update existing OSM data to a new schema - I have already done the same using OsmOsis, mySql and php - and have two datasets, old and new, running parallelly until users have time to update their data-parsing software to the new version. This would really be a win-win situation because it would a) put all the key tags in a logical place (under the 'area' tag), b) eliminate the need for complicated user-side redundant searches (for all 'multipolygon members'), and c) lower server overhead because of b) and the replacement of the <relation> and <multipolygon> tags with the unique <area> one. Cheers. ThePromenader 10:26, 19 April 2011 (BST)

I do not understand how this system is much different or any better than the existing multipolygon relation ? If the only advantage is that it has a clearer name, then it really isn't worth the hassle. --Vincent De Phily 17:07, 19 April 2011 (BST)

The principal difference is that it does not use 'relations' at all. Cheers. ThePromenader 17:50, 19 April 2011 (BST)

To User:Vincent De Phily: here's one reason: relatively few areas are specified as MP relations right now. All other areas are represented as simple ways. Ways also represent polylines and there is no clear distinction between the two in the current system. Maybe we as intelligent beings can distinguish between a feature that represents a polyline and the one representing an area, but our software is much dumber and it can't --Breki 20:19, 19 April 2011 (BST)

And an "area" tag would be a super-low-overhead way of describing "what gets filled in" - OSM (and end-user programs) have to do key lookups (and program what keys get what treatment) before deciding whether to render a fill or not. Also, "area" would very nicely complete the "polygon, line, point" logic in use by most every mapping application today. ThePromenader 14:27, 21 April 2011 (BST)