<div>Frederik wrote:</div>
<div>> I understand Stefan's idea to be a "read only" representation </div>
<div> </div>
<div>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). </div>

<div> </div>
<div>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).</div>

<div> </div>
<div>To Brett: You wrote</div>
<div>> way was just a convenient xml element for grouping nodes within the xml<br>Yes. The 'way' tag is just a convenient encoding, leading to simpler processing code. </div>
<div> </div>
<div>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!).</div>

<div> </div>
<div>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...?</div>

<div> </div>
<div>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.</div>

<div> </div>
<div>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.</div>

<div> </div>
<div>-- S.</div>
<div> </div>
<div class="gmail_quote">2008/7/10 Frederik Ramm <<a href="mailto:frederik@remote.org">frederik@remote.org</a>>:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">Hi, 
<div class="Ih2E3d"><br><br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">How are you handling nodes shared by multiple ways? Embedding them N<br>times, or outputting them first and referencing them?<br>
Same for ways referenced by areas (if that was the intention)?<br></blockquote><br></div>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.<br>
<br>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.<br>
<br>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.<br>
<br>Bye<br>Frederik<br><font color="#888888"><br>-- <br>Frederik Ramm  ##  eMail <a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>  ##  N49°00'09" E008°23'33"<br><br><br><br></font></blockquote>
</div><br>