[OSM-dev] Relation - Multipolygon = "Area"

[Igor Brejc]

On Tue, Apr 19, 2011 at 8:04 PM, Ben Supnik <bsupnik at xsquawkbox.net> wrote:

> Hi Igor,
>
>
> On 4/19/11 1:53 PM, Igor Brejc wrote:
>
>  The way I plan to solve this is to leave to the user to tell the
>> renderer what kind of a feature she wants to draw and how to
>> construct the feature from OSM primitives. So for example:
>>
>> * "Draw me a road network using OSM ways tagged with highway=motorway
>> OR highway=trunk" * "Draw me simple polylines using OSM ways tagged
>> with power=line"
>>
>> Sometimes you want to avoid excessive feature compositing because of
>>  performance reasons, so I'd leave the decision to the user.
>>
>
> Wait, I'm sorry, I think I missed something here. :-(  The above
> examples, these are instructions to 'rendering' clients, right, e.g.
> "this is how you do your rendering given an input pile of OSM data"?
>
>
Right, I'm talking about rendering side of things.


> Or...
>
>
>  I'm more and more convinced something better is needed: OSM
>> primitives represent parts of the higher-level features and should be
>> treated as such.
>>
>
> 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?)


Well depends on how you look at it :). A simple example:

   - way 1 goes from node A to node B
   - way 2 goes from node B to node C

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.

Maperitive example:

   - It constructs road networks before rendering based on the highway tag
   (as an example).
   - 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.

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.


> The "reconstruction rules" wouldn't be global, they'd be per usage, right?
>
>
Again, it depends. Given

   - the complexity of various OSM tagging schemes,
   - the fact that OSM is global and can represent geographically very big
   and very distributed things

...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.

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.

Igor
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20110419/4bcc3d27/attachment.html>