[OSM-dev] Consensus on areas?

[Nicola Ranaldo]

> > A list of nodes is not sufficient. You  need an *ordered* list of nodes.
> > As the community prefers not rigid formalized data structures, the only
> > way to
> > get an ordered list of nodes is via software sourcing from a list of
> > segments.
>
> A way *is* an ordered list of nodes (sort of).  A way is defined as an
> ordered list of segments.  Each segment defines a from and to node.  The
> net result is an ordered list of nodes.

Sorry Etienne, i was not precise in my last post, ways are really defined as 
an ordered list of segments, but i have some doubts about splitted ways, 
*rings*, ways with duplicated or unexistent seg-id and so i'm not sure data 
from planet.osm is *semantically* correct. From my very little experience, as 
i'm trying to code a realtime browser running off planet.osm, i can say that 
i have to check and recheck data to avoid gangling references or loops and 
reorganize them, as example, when i draw a way, to render the text properly 
and to have a faster paint i have to extract the ordered list of nodes,  and 
split them in sublists (to avoid rings and loops!) resulting in a faster 
paint too, as my code has to do a moveTo(x,y) call for every sublist, instead 
of n as number of segments, and n lineTo(x,y). 
Of course it would be easyer for me avoiding those pieces of code, but i 
should assume data is perfect both in the db source and in semantic, no 
duplicates, no unexistent segments, no unexistent node, well-ordered ways and 
so on, or while rendering i will get a random segment network, mad text names 
or a program freeze or crash! To avoid this actually i assume as segments are 
not ordered.
I do not want to bore the community again asking strong formalized data 
specifications, rest/db triggers and so on... but it would be very nice to 
have at least a general developer's guide to not waste time in wrong 
assumptions.
For example:
*) to avoid nodes duplications editors before uploading a new node should do a 
map request, and should warning the user if there ar a node closest to the 
new, letting him  in creating a new node or updating the one existing
*)when rendering ways and walking trough segments does not manipulate the 
order, if it's wrong someuser will correct data if needed
or
*)editors should take special care of segments ordering in a way, rearranging 
them when a different order create a well-formed way, and warning user to 
apply changes...
*)when importing planet.osm or making api requests check data referencing, 
segments->nodes, ways->segments..., actually there is no plan to enforce db 
checks or to clean data
*)when editing areas absolutely avoid the creation of unclosed path of the 
underlying segments, some renderer may not fill the interior part!

and so on!


> The real problem is that segments have very little purpose in this model.
> They do define the direction, but an ordered list of nodes would do the
> same job.  You can also put tags on segments, but a hierarchical
> arrangement of ways would make this redundant.

Yes, actually i think tags on segments should be used only when properties are 
different from the containing way. The same, and better, if ways can be 
splitted in subways with different tag sets. With this you may assume the 
subway is connected and has no rings too :).

> > For example area could be a recursive set of subareas you can add or
> > subtract
> > from the shape, to create holes, ring and other kind of complex objects.
>
>  The SVG approach (see
> http://www.w3.org/TR/SVG/painting.html#FillProperties) is quite elegant and
> seems to cover most possibilities.

Yes, and for this ways are sufficient again :)

Niko