<br><div class="gmail_quote">On Tue, Apr 19, 2011 at 8:04 PM, Ben Supnik <span dir="ltr"><<a href="mailto:bsupnik@xsquawkbox.net">bsupnik@xsquawkbox.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Hi Igor,<div class="im"><br>
<br>
On 4/19/11 1:53 PM, Igor Brejc wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The way I plan to solve this is to leave to the user to tell the<br>
renderer what kind of a feature she wants to draw and how to<br>
construct the feature from OSM primitives. So for example:<br>
<br>
* "Draw me a road network using OSM ways tagged with highway=motorway<br>
OR highway=trunk" * "Draw me simple polylines using OSM ways tagged<br>
with power=line"<br>
<br>
Sometimes you want to avoid excessive feature compositing because of<br>
 performance reasons, so I'd leave the decision to the user.<br>
</blockquote>
<br></div>
Wait, I'm sorry, I think I missed something here. :-(  The above<br>
examples, these are instructions to 'rendering' clients, right, e.g.<br>
"this is how you do your rendering given an input pile of OSM data"?<br>
<br></blockquote><div><br></div><div>Right, I'm talking about rendering side of things.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Or...<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm more and more convinced something better is needed: OSM<br>
primitives represent parts of the higher-level features and should be<br>
treated as such.<br>
</blockquote>
<br></div>
Ah but...the higher level features are not actually _in_ the OSM database?  (That is, their existence is derived via reconstruction rules like the above?)  </blockquote><div><br></div><div>Well depends on how you look at it :). A simple example:</div>
<div><ul><li>way 1 goes from node A to node B</li><li>way 2 goes from node B to node C</li></ul>A "higher-level feature" could (but not necessarily should!) in this case be a polyline that starts from node A and ends in node C. There's nothing explicitly specified in the DB that this is the case. So you need some external source/knowledge to let the renderer know this. For example, if I as a user say "join all ways which have the same name tag", this is the external semantics to get such a feature. If she says "join all ways which have the same highway tag", you could end up with a different collection of merged polylines.</div>
<div><br></div><div>Maperitive example:</div><div><ul><li>It constructs road networks before rendering based on the highway tag (as an example).</li><li>But when labeling streets, it constructs a different network based on the value of the "name" (or user-specified) tag. Sometimes a street is split into several small OSM ways and it would be impossible (and/or ugly) to render a label for each such segment. Instead, Maperitive merges all segments into a single line and only then decides where and how to render the label. </li>
</ul></div><div>On the other hand, you could have such semantics specified in the DB as a relation, one example are bus routes. But there you still need some external knowledge on how to handle various roles of this type of a relation.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">The "reconstruction rules" wouldn't be global, they'd be per usage, right?<div><div></div>
<div class="h5"><br></div></div></blockquote><div><br></div><div>Again, it depends. Given</div><div><ul><li>the complexity of various OSM tagging schemes,</li><li>the fact that OSM is global and can represent geographically very big and very distributed things</li>
</ul>...it will always be very difficult to encode _all_ the semantics within OSM DB. This is where good tools which can synthesize OSM data come into play.</div><div> </div><div>But I do feel that the area as an OSM primitive is badly needed. Here even _with_ external semantics it is sometimes difficult to determine whether an OSM way represents a polyline or a closed polygon.</div>
<div><br></div><div>Igor </div></div>