[OSM-dev] Area support

[Stefan Keller]

Frederik wrote:
> I understand Stefan's idea to be a "read only" representation

The XML encoding we are talking about is about data exchange between two
systems. Geospatial data especially has the property to be "write once, read
many times". Now, there's often the question who has more work to do: the
writer (i.e. editor) or the reader process. The encoding of
ways/linestrings/polylines and areas/polygons poses some dilemmas whether to
make more easy the writer's or the reader's job (and being hopefully free of
redundancy).

The encoding I suggested has some redundancies if you want to share nodes.
My point here is, that there are less occasions where nodes are really
shared - except for, say, natural, which suggests "areas which don't
overlap". We actually shared ways in similar manner in INTERLIS Version 1
(which works since 1985!). We actually called this AREA network as opposite
to a SURFACE, which can overlap. We then switched to an unified "object
oriented" encoding as I suggested above while still having one basic
geomerty type 'area' which conceptually (in the model/schema) is modelled as
allowing overlaps or not (the writer/sender then has to ensure this
property). This "object oriented" encoding was chosen at the same time by
all new formats (like GML or ESRI's geodatabase).

To Brett: You wrote
> way was just a convenient xml element for grouping nodes within the xml
Yes. The 'way' tag is just a convenient encoding, leading to simpler
processing code.

To me, if optionally having references to nodes/coordinates out of ways
instead of "inline coordinates" really is a necessity, I could live with it
(although, again, this would mean that all "nodes" have to be held in a
readers memory/table before writing the very first way/area!).

And again: We really need areas/polygons which can have "wholes"! Every
second forest has meadows, every other lake has islands, Italy has Vatican
City, Spain Andorra, about 3% of Swiss counties have it... want more
examples...?

To be precise, we need a common understanding what is a valid area/polygon
geometry type conceptually (I propose to say, that non-overlapping polygons
is an additional constraint). I could give precise definitions (in wrods and
figures) on that. Then the eoncoding comes in.

Regarding the word "multi", please be carefull: in informatics lingo, a
multi-way is a composition/collection of ways and a multi-polygon is a
composition/collection of (possibly overlapping) areas/polygons. "Multi"
does not refer to multiple inner boundaries ("wholes") as they are part of a
single, valid area/polygon.

-- S.

2008/7/10 Frederik Ramm <frederik at remote.org>:

> Hi,
>
> How are you handling nodes shared by multiple ways? Embedding them N
>> times, or outputting them first and referencing them?
>> Same for ways referenced by areas (if that was the intention)?
>>
>
> I understand Stefan's idea to be a "read only" representation at the
> individual object level, so I assume that he wants the coordinates
> duplicated whenever a node is shared by multiple objects.
>
> I say "read only" because obviously it has no topology, so it is unsuitable
> for loading it into an editor and changing the outline of the area there -
> the editor would have to upload *all* coordinates for the whole area even
> for a small change, and without node IDs the upload could not be matched to
> the database contents. We'd be editing shapefiles, basically, which is not
> something we want.
>
> I agree that having coordinates "inline" would greatly simplify many
> application but this has nothing to do with areas (applies to ways and
> relations as well), but I also believe that our database should concentrate
> on the simple tasks like it does now, and a full geometry output could be
> delivered by another system further down the line. With osm2pgsql going in
> the direction of processing diffs, it is viable to have a PostGIS with
> current data loaded and allow all kinds of spatial queries returning
> standard PostGIS geometries.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20080710/877caabf/attachment.html>