On Mon, 6 Apr 2009, andrzej zaborowski wrote: > I'm not completely sure either representation is better... maybe both > types should be standardised - the UMP project makes maps particularly > for Garmin devices so apparently if you upload your map into your > Garmin receiver and ask it to route you to a given housenumber, it > will want to know the first and last housenumber for all way segments, > and will interpolate the position...
The bad part of standardizing on both ways is that applications that use OSM data for routing or rendering addresses would need to support both ways. > now I'm sure that at some point a lot of people will want to use OSM > on the Garmins (very few people do now) and the converter will have to > translate the Karlsruhe scheme back into the Garmin/canvec/geobase > scheme. This can be done by converting the addr:interpolation ways > into new "garmin" ways that will have the address information but will > not be routable - but then they will be disconnected from the road > network and the routing may fail. The other option is to *project* > the lateral addr:interpolation ways onto the street segment, but this > is a little more complex to implement (imagine zigzagging streets and > zigzagging addr:interpolation ways) If the interpolation ways model the geometry of the original way just offset by some factor then the interpolation ways wouldn't cross the street segment. If your source for the addresses is the same as the source for your roads (as is this case with geobase) then this isn't hard to implement but results in a lot of extra nodes. If your trying to overlay some address data onto existing roads this becames a bit harder but is still doable (get the project your addresses onto the road segment, and duplicate+offset it). The big concern I have with having the interpolation ways model the geometry of the original road is that we are increasing the number of nodes (and ways) required by a factor of 3. One set of nodes + way for the road, a second set all shifted x meters to for the right side and a third set shifted -x meters for the left side. Steve _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
