<div>2008/7/9 Jochen Topf wrote:<br>> Having "real" areas would make the handling quite a bit more practical.</div>
<div><br>Agreed. An area (or polygon) simply is a basic geometry type; it's a fact in practice and computational geometry. </div>
<div> </div>
<div>The actual XML encoding of ways never really was according to best practices and will not scale. This is because even for ways we have to read in all nodes until the end of the stream/file before any way can be created. Now, when we misuse (application oriented) relations to encode areas, processors are again forced to read in *all* relation instances before any area can be instantiated... Can't we do that better? (the crazyness would be complete when one would 'consequently' encode areas *and* ways as partially ordered relation instances which would point to nodes).</div>
<div> </div>
<div>I would take this discussion as a chance to enhance the OSM/XML encoding: Ways should be encoded with nodes (coordinates) embedded, and areas (polygons) ought to be encoded with one way as outer boundary and zero or more inner ways (boundaries) - embedded. I would even differentiate areas which overlap and areas which don't (but this is more on the conceptional and application modelling level and makes no difference in the encoding). Look on the simplicity and usability of such an XML encoding below...<br>
</div>
<div>Stefan</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">Example of a enhanced OSM data encoding of an area and its boundaries (ways) as proper property types:</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote"> <area id="4304746" timestamp="2008-03-25T21:31:01+00:00" user="anonymous"><br> <tag k="landuse" v="water"/><br> <tag k="created_by" v="JOSM"/><br>
<tag k="natural" v="water"/><br> <tag k="name" v="Lake of Zuerich"/><br> <geometry><br> <outerboundary><br> <way><br> <node lat="47.23439" lon="8.82187"</node><br>
<node lat="47.23411" lon="8.82362"</node> <br> ...<br> </way><br> <way><br> ...<br> </way><br> </outerboundary><br>
<innerboundary><br> <way><br> <node lat="47.23411" lon="8.82111"</node><br> ...<br> </way><br> </innerboundary><br> <innerboundary><br>
<way><br> <node lat="47.23499" lon="8.82199"</node><br> ...<br> </way><br> </innerboundary><br> </geometry><br> </area><br>
</div>
<div class="gmail_quote"> </div>
<div class="gmail_quote">2008/7/9 Jochen Topf <<a href="mailto:jochen@remote.org">jochen@remote.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">On Wed, Jul 09, 2008 at 02:55:27PM +0200, Frederik Ramm wrote:<br>> > No, we could continue to use multipolygon relations for that.<br>> ><br>> > I just wanted to point out that our existing primitives are "simple" ones: no compound objects, no holes, only one single coherent object. The new area primitive would be different from that (which of course is not necessarily an argument against it).<br>
><br>> You are right, but proponents of a proper area type also rightly say<br>> that it is slightly inelegant to use relations on an upper level<br>> (combining ways into routes etc.) on one hand and on a very basic<br>
> geometry level (putting holes into areas) on the other hand.<br><br></div>Having "real" areas would make the handling quite a bit more practical.<br>At the moment you can't read the ways sequentially and just do something<br>
with all the areas in there bit by bit. You always have to go through<br>all of the ways and then all of the relations just to find out that most<br>areas have no relation but are simple and you could have just used the<br>
way.<br><br>Currently there are two ways of modelling an area, one for areas without<br>holes, one for areas with holes. This makes handling it always a bit more<br>difficult. Say you have a relation pointing to all parking lots belonging<br>
to a soccer stadium. Some of the parking lots have holes, some don't. So<br>you have<br><br>relation(all parking lots) +--> some ways (amenity=parking) --> some nodes<br> +--> some relations (multipolygon) --> some ways (amenity=parking) --> some nodes<br>
<br>Also to decide whether a way is a linestring or an area you have to look<br>at the tags. If you have unknown tags, you can't decide what it is. If<br>you had a distinct area type you can, say render areas you don't<br>
recognize in a default color or so.<br><br>Jochen<br><font color="#888888">--<br>Jochen Topf <a href="mailto:jochen@remote.org">jochen@remote.org</a> <a href="http://www.remote.org/jochen/" target="_blank">http://www.remote.org/jochen/</a> +49-721-388298<br>
</font>
<div>
<div></div>
<div class="Wj3C7c"><br><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>