On Tue, Apr 19, 2011 at 8:04 PM, Ben Supnik <[email protected]> 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
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
