[OSM-dev] Consensus on areas?
ranaldo at unina.it
Tue Aug 29 11:18:45 BST 2006
> > 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
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
*) 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
*)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
*)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 :)
More information about the dev