<div>> That looks awfully similar to relations.<br>It's *is* actually like a relationship - but it's clearly encoded and directly parseably as a primitve geometry type 'area'.<br></div>
<div>> So I have to ask: what is the net gain from using an "area" data primitive?<br>Simpler encoding and clear semantics.<br></div>
<div>> So a renderer has to actually walk through *all* the data to render it *all*?<br>> What's the problem?!</div>
<div> </div>
<div>The problem is 1. memory, 2. the fact that there are parts of an area object unnecessaryly distributed over three(!) sections of a file (or three tables) and 3. relying on user tags instead of clear encoding on a system level!</div>

<div> </div>
<div>Let's lower the barriers primarily for writing OSM reader software and secondary also for OSM writer software if possible.</div>
<div> </div>
<div>-- S.<br></div>
<div class="gmail_quote">2008/5/6 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 Martes, 6 de Mayo de 2008, Stefan Keller escribió:<br>
<div class="Ih2E3d">> Urging editors and converters to maintain direction constraints breaks<br>> almost all implementations and makes it harder to implement.<br>> There are simple ways like the encoding I proposed.<br>
</div>[snip]<br>
<div class="Ih2E3d"> <area id="8007396" visible="true" timestamp="2007-09-26T19:07:16+01:00"<br>user="a_user"><br>   <wy ref="59907908"/><br>   <wy ref="59907909"/><br>
   <wy ref="59907910"/><br>   ...<br>   <tag k="created_by" v="an_application"/><br>   <tag k="a_tag" v="a_value"/><br> </area><br></div>[snip]<br>
<br>That looks awfully similar to relations.<br><br>I see your point, though: polygons/areas are 2-dimensional entities, whereas<br>ways/lines are 1-dimensional entities and, from a topologist point of view<br>they *have* to be different.<br>
<br>From a code-monkey point of view, though, it actually makes sense not to make<br>a distinction. You start a drawing path, lineTo() the next point, then apply<br>the styles and either fill or stroke the drawing path. 99% percent of the<br>
code is shared, so refactorization kicks in, and all of a sudden a line and<br>an area are the same thing.<br><br>So I have to ask: what is the net gain from using an "area" data primitive?<br>
<div class="Ih2E3d"><br><br><br>> Think about what reading OSM areas currently means to<br>> validators/converters/editors/renderers because of the<br>> node-ways-relationships-and-fancy-tags-stucture:<br>> First they have to read in all(!) nodes into memory befor he can assemble<br>
> them to ways.<br>> Second, they have to check (hopefully closed) way tags in order to find<br>> out, if there is a tag which claims to be an area tag, which is<br>> eventually(!?) documented in the wiki.<br>
> Third, they have to read in the whole(!) relationship section in order to<br>> find out if there are eventually relationships which refer to areas.<br><br></div>So a renderer has to actually walk through *all* the data to render it *all*?<br>
What's the problem?!<br><br><br>Cheers,<br>--<br>----------------------------------<br>
<div class="Ih2E3d">Iván Sánchez Ortega <<a href="mailto:ivan@sanchezortega.es">ivan@sanchezortega.es</a>><br><br></div>cat knowledge | grep understanding<br></blockquote></div><br>