<div>Iván,</div>
<div> </div>
<div>You wrote:</div>
<div>> We already have ways and relationships, which are a very powerful tool.<br>> And you must stop thinking of polygons as areas, and start thinking about<br>> the OSM data being a *big* graph, the loops in the graph being the<br>
> polygons.<br></div>
<div>That's a tempting concept, and it's possibly true on a conceptual level. </div>
<div>But there are some theoretic and many practical drawbacks: First, I makes parallel editing theoretically and practically much more complicated (who own's the common boundary). In any case, ways would need to be mandatory tagged as "boundary" (if it's part of a polygon). What about polygons which belong together (multi-polygons)? (using relations for such a "data type" would be a clumsy solution)? What happens to the adjacent area and it's attributes (key/values) when you delete a common boundary??</div>

<div> </div>
<div>Then there are practical issues, mostly coming from the encoding: It makes validation(!) and rendering much more complicated (how to assemble all boundaries (ways) distributed all over the database?). Just to begin with a fre drawbacks... so it's no surprise, that all de-facto and de-jure standards in GIS (sorry to mention this beast) I'm aware of - except Interlis 1 which we changed to Version 2 because of this(!) among others - are *not* using a graph structure or have abandoned it.</div>

<div> </div>
<div>-- Stefan</div>
<div> </div>
<div class="gmail_quote">2008/5/6 Iván Sánchez Ortega <<a href="mailto:ivansanchez@escomposlinux.org">ivansanchez@escomposlinux.org</a>>:<br>
<blockquote class="gmail_quote" style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<div class="Ih2E3d"><br>On Tue, May 6, 2008 18:18, Karl Newman wrote:<br>> Well, it's probably too big of a change for the next API change, but it<br>> would be nice to get a native polygon primitive. I understand it used to<br>
> exist but was removed because nobody was using it. (!) It would be nice to<br>> have this because it would allow us to deal with polygons in a generic way<br>> without having to know which tags on a way indicate a polygon.<br>
<br></div>I don't think so. A polygon primitive would be, IMHO, a step back in time.<br><br>We already have ways and relationships, which are a very powerful tool.<br>And you must stop thinking of polygons as areas, and start thinking about<br>
the OSM data being a *big* graph, the loops in the graph being the<br>polygons.<br><br>Basically, this means that polygons can be defined with the current<br>primitives, saving at least 50% of the space needed to store them as data<br>
primitives. Think boundaries shared by several polygons, being a graph<br>edge. The order of the relationship would mark the clockwiseness* of the<br>polygon.<br><br>* Is that a word?<br><br>(Yes, I know I should make a good, nice proposal about this with lots of<br>
drawings.)<br>
<div class="Ih2E3d"><br>> I'm thinking specifically of tile cutting where a polygon needs to be<br>> managed differently than a simple line. Without a specific polygon type,<br>> any tool dealing with them will have to be updated to track changes in<br>
> polygon tagging.<br><br></div>If polgons became relationships of graph edges, you could render 'em just<br>as t@h renders coastline. You know the clockwiseness, so you can fill the<br>space on one side of the uncompleted polygon.<br>
<br>Besides that, some cronjob to calculate which polygon is inside which<br>polygon would be needed. It could be done offline based on the graph<br>topology, so no prob.<br><br>I do think that relationships (or relations) are the way to go. But OSM<br>
would need some proposals to make this work, and *tools* to manage a<br>polygon-graph model based on ways+relations.<br><br><br>Cheers,<br><font color="#888888">--<br>Iván Sánchez Ortega <<a href="mailto:ivan@sanchezortega.es">ivan@sanchezortega.es</a>><br>
<br>Un ordenador no es un televisor ni un microondas, es una herramienta<br>compleja.<br></font>
<div>
<div></div>
<div class="Wj3C7c"><br>_______________________________________________<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev" target="_blank">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev</a><br>
</div></div></blockquote></div><br>