<div>> Extrapolating your reasoning, we should end implementing the 12 entities<br>> defined in OGC's Simple Features, and every piece of OSM software should know<br></div>
<div>I'm proposing three primitive geometry datatypes, namely: point (syn. node), polyline (syn. linestring, way) and area (syn. surface, polygon), eventually with parameters. In Switzerland we have used this since about 15 years, so I can assure you that this works for all real world use cases we mentioned so far (topology, coordinate transform, etc.) and it's easy to implement (at least easier as the current area usage in OSM).</div>

<div> </div>
<div>You are right, that it would be nice to share common nodes and common boundaries and that there are arguments for both. But believe me, the encoding I'm referring to here is preferrable because it is "object oriented" and more data processing friendly than the topology model, while it still allows topology and (conceptually) shared boundaries to be derived from it.<br>
</div>
<div>OSM data primitives currently lack a primitive geometry datatype 'area', which needs a clear semantic definition and a simple encoding. </div>
<div> </div>
<div>If we could agree on this we could take the most useful parts out of Simple Feature and the Interlis spec. I referenced before.</div>
<div> </div>
<div>-- Stefan</div>
<div> </div>
<div> </div>
<div class="gmail_quote">2008/5/7 Iván Sánchez Ortega <<a href="mailto:ivan@sanchezortega.es">ivan@sanchezortega.es</a>>:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">El Miércoles, 7 de Mayo de 2008, Stefan Keller escribió:<br>
<div class="Ih2E3d">> > So I have to ask: what is the net gain from using an "area" data<br>> > primitive?<br><br>> Simpler encoding and clear semantics.<br><br></div>Sorry, I don't see how having two identical data primitives with different<br>
meaning allows for simple encoding. It makes the software worry about more<br>tokens to parse and more data structures to worry about.<br><br>Extrapolating your reasoning, we should end implementing the 12 entities<br>defined in OGC's Simple Features, and every piece of OSM software should know<br>
about them 12 and implement them. Right know, 3 data primitives are a lot<br>easier to understand and implement than 12.<br>
<div class="Ih2E3d"><br>> > So a renderer has to actually walk through *all* the data to render it<br>> > *all*? What's the problem?!<br>><br>> The problem is 1. memory,<br><br></div>It's arguable. By using a relational model, you actually save memory if a node<br>
is shared be several ways. Put in a graph-edge model for areas, the savings<br>nearly duplicate.<br>
<div class="Ih2E3d"><br>> 2. the fact that there are parts of an area object unnecessaryly distributed<br>> over three(!) sections of a file (or three tables) and<br><br></div>... but reprojection has to be applied only to nodes, which is a boon for<br>
software; using cross-linked relational tables it's trivial to fetch a<br>spatially-backed instance of a feature. And end-user editors have it *much*<br>easier when moving a node that is shared along several ways...<br>
<br>I think this is turning again into a "spatial features vs. graph" discussion<br>again. No side will win the argument.<br>
<div class="Ih2E3d"><br>> 3. relying on user tags instead of clear encoding on a system level!<br><br></div>If it's a semantic problem, leave it to tags, not to the system.<br>
<div class="Ih2E3d"><br><br><br><br>Cheers,<br>--<br>----------------------------------<br>Iván Sánchez Ortega <<a href="mailto:ivan@sanchezortega.es">ivan@sanchezortega.es</a>><br><br></div>Toma mi consejo, Yo no lo uso de todas formas.<br>
</blockquote></div><br>