routing / address search: What makes a road (, house number, etc.) belong to a city (, country, etc.)
Hi there! As we have regular discussions about $SUBJECT on the German OSM list, I'd like to know about the current state within mkgmap and your opinions on that. Things which come to my mind to make things belong to others so far, are: 1) tags on the child like is_in or addr:street/addr:city 2) place and boundary polygons for the "parent" 3) relations Can you give a short summary which of those are currently used and which could probably make your life easier in the future? Especially taking into account a real, working address search with house numbers, post codes and all that... (I'm personally in strong favor for 2) when it comes to street->city and 3) when it comes to housenr->street) Some observations I made with my mkgmap cards in Bavaria, DE: * For the "road-name-pois", things look quite ok. All streets I looked up so far are labelled with the correct suffix ("/City"). However, for quite some, I've no clue how mkgmap figures this out - simply searching for the next city node? * On the other hand, with mkgmap cards loaded, my Nüvi seems to have no idea about streets being within or without a city. In Germany, a primary/secondary/tertiary road within a city is normally restricted to maxspeed=50, but to maxspeed=100 when it's outside - so we don't tag this explicitly. However, my Nüvi always expects me to go with something like 70km/h on primary roads - independent where I am. This makes ETAs in cities terribly wrong. It expects you to cross a city in 5 minutes which is usually quite ... optimistic. * For the "real address search", things seem to be quite indeterministic. Sometimes, a street is listed as part of "City, City", sometimes the city is prefixed with a long list of post codes. I'm even quite sure that I also saw "Suburb, City" in the past - however I'm not able to reproduce this with r1006 at the moment. I'm quite sure that is based on inconsistent data within OSM, but how exactly? TIA! -- Gernot
Hi Gernot,
1) tags on the child like is_in or addr:street/addr:city
I believe that info is currently used.
2) place and boundary polygons for the "parent"
I don't think that's currently used.
3) relations
Also, not used at the moment. I wrote the road-name-pois code and it simply associates roads with the nearest "city". It's very dumb but quite effective. I would have thought that having place/boundary polygons would be useful for determining the road names for cities. I haven't thought about general address info but relations sound useful because you could use a relation to associate a bunch of houses with a street, or a bunch of streets with a place. The street address search is semi-functional at the moment. Personally, I don't think it will improve much until we understand how to generate the extra data required. Unfortunately, that isn't going to happen soon due to lack of collective knowledge. Cheers, Mark
Mark Burton wrote:
I haven't thought about general address info but relations sound useful because you could use a relation to associate a bunch of houses with a street, or a bunch of streets with a place.
Linking every street within a place together into a place relation, idem for places within municipality's, idem for municipality's within provinces, idem for provinces within countries, idem for ... What I'm illustrating is that using relations for this type of information is far from optimal imho. We already have coordinates for each object so determining if an object is within a place/municipally/province/country seems a much better approach to me.
Hi there! Lambertus wrote:
Mark Burton wrote:
I haven't thought about general address info but relations sound useful because you could use a relation to associate a bunch of houses with a street, or a bunch of streets with a place.
Linking every street within a place together into a place relation, idem for places within municipality's, idem for municipality's within provinces, idem for provinces within countries, idem for ...
What I'm illustrating is that using relations for this type of information is far from optimal imho. We already have coordinates for each object so determining if an object is within a place/municipally/province/country seems a much better approach to me.
Sorry, but I'm not sure I really got your point. You suggest to use place polygons, right? If yes: +1! :-) However, this won't work for house numbers as polygons for streets definitely make no sense - especially taking into account how weird the houses of a street are spread in many places... -- Gernot
Gernot Hillier wrote:
Hi there!
Lambertus wrote:
Mark Burton wrote:
I haven't thought about general address info but relations sound useful because you could use a relation to associate a bunch of houses with a street, or a bunch of streets with a place. Linking every street within a place together into a place relation, idem for places within municipality's, idem for municipality's within provinces, idem for provinces within countries, idem for ...
What I'm illustrating is that using relations for this type of information is far from optimal imho. We already have coordinates for each object so determining if an object is within a place/municipally/province/country seems a much better approach to me.
Sorry, but I'm not sure I really got your point. You suggest to use place polygons, right? If yes: +1! :-)
I see I wasn't clear enough. Yes, using polygons is what I meant.
However, this won't work for house numbers as polygons for streets definitely make no sense - especially taking into account how weird the houses of a street are spread in many places...
Well, I'm not familiar with the Karlsruhe schema and other house numbering scheme's but I reckon the house numbers will eventually be linked to a way? Using the polygons you can lookup in which place the way is, and voila!
Hi! Lambertus wrote:
However, this won't work for house numbers as polygons for streets definitely make no sense - especially taking into account how weird the houses of a street are spread in many places...
Well, I'm not familiar with the Karlsruhe schema and other house numbering scheme's but I reckon the house numbers will eventually be linked to a way? Using the polygons you can lookup in which place the way is, and voila!
For Karlsruhe schema, it's not required that they're linked to a way and most of the time, they aren't. When you walk along a street, you just place nodes on the right and left side near the street and tag them with addr:housenumber. It doesn't make much sense to draw connection ways which aren't there in reality. To define the according street, you usually use either a tag "addr:street" on the house node (this string can be compared with the highway's name) or you use a relation of type=associatedStreet which includes "street" and "house"s. But I think this is not really an open point for discussion as the info is already in the OSM data, so the only missing bit is to convert it to the Garmin binary format. :) -- Gernot
Gernot Hillier wrote:
Hi!
Lambertus wrote:
However, this won't work for house numbers as polygons for streets definitely make no sense - especially taking into account how weird the houses of a street are spread in many places...
Well, I'm not familiar with the Karlsruhe schema and other house numbering scheme's but I reckon the house numbers will eventually be linked to a way? Using the polygons you can lookup in which place the way is, and voila!
For Karlsruhe schema, it's not required that they're linked to a way and most of the time, they aren't. When you walk along a street, you just place nodes on the right and left side near the street and tag them with addr:housenumber. It doesn't make much sense to draw connection ways which aren't there in reality.
I did not mean to actually make a way to link the nodes to the street. A relation can also link an address to a way as does tagging ;-)
To define the according street, you usually use either a tag "addr:street" on the house node (this string can be compared with the highway's name) or you use a relation of type=associatedStreet which includes "street" and "house"s.
But I think this is not really an open point for discussion as the info is already in the OSM data, so the only missing bit is to convert it to the Garmin binary format. :)
If the addresses are OSM nodes then they can be compared against polygons as well, which was my point :D
Hi! Mark Burton schrieb:
The street address search is semi-functional at the moment. Personally, I don't think it will improve much until we understand how to generate the extra data required. Unfortunately, that isn't going to happen soon due to lack of collective knowledge.
I already offered Bernhard to join his efforts in decrypting the MDRs a while ago, but it seems he's offline ATM. Someone else working on that and needing help from one of those dumb C programmers w/o knowledge of routing and Garmin stuff? ;-) -- Gernot
I just took out a r1006 map for a little ride. Two observations: At some point along a route my Garmin etrex legend HCx stopped telling me when to take exits, when to make a turn etc. I made some turns right out of memory, than failed. The etrex recalculated the route, but this didn't fix the missing turn advices. I failed again and the device recalculated, this time reverting to the 'normal' behaivior of making anouncements and drawing nixe turn advice screens. This may of course be a bug in the firmware, not in the generated map. Second thing: I unsuccessfully searched for a village name both in the city search and the all pois dialog. All streets in this village are there (found through road-name-pois). I found that the village is marked only as a polygon in the osm data. Could it be that city names without a dedicated node are not written to the poi list? Regards Stefan
Hi! stefan@binaervarianz.de schrieb:
I found that the village is marked only as a polygon in the osm data. Could it be that city names without a dedicated node are not written to the poi list?
According to the discussions we had on the German list for place polygons, this is definitely not intended. There should always be a node for a city and probably also an area. See also http://wiki.openstreetmap.org/wiki/Key:place So you should definitely check for the city centre and add a node there... -- Gernot
On Tue, Apr 21, 2009 at 07:49:05AM +0200, Gernot Hillier wrote:
Things which come to my mind to make things belong to others so far, are:
1) tags on the child like is_in or addr:street/addr:city 2) place and boundary polygons for the "parent" 3) relations
I am in favour of 2 - But i see some problems - Missing polygons - Not easy to determin as they are non visible fact. - Addresses might not always correlate to administrative boundaries. Are we shure they do? At least for Phone numbers i am very shure they do not match. - How do you suggest to migrate - I mean we will have years where our polygons will not be complete so there need to be multiple ways of finding the administrative relation. Flo -- Florian Lohoff flo@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin
Hi! Florian Lohoff wrote:
On Tue, Apr 21, 2009 at 07:49:05AM +0200, Gernot Hillier wrote:
Things which come to my mind to make things belong to others so far, are:
1) tags on the child like is_in or addr:street/addr:city 2) place and boundary polygons for the "parent" 3) relations
I am in favour of 2 - But i see some problems
- Missing polygons - Not easy to determin as they are non visible fact.
Well, as soon as we have widespread usage of OSM data for routing, I'm quite sure people will provide those very quickly. For small cities, one mapper can do 5 per hour - and for big cities, there are so much bored mappers already available, you know... :-) It should also be easy to write tools which make the problem visible in one or another way.
- Addresses might not always correlate to administrative boundaries. Are we shure they do? At least for Phone numbers i am very shure they do not match.
Therefore, I vote for using the place polygon, not the boundary one. This one should really include all the streets which belong to that city. I'm feeling this will work for for 99.99% of cases.
- How do you suggest to migrate - I mean we will have years where our polygons will not be complete so there need to be multiple ways of finding the administrative relation.
Well, if there's no polygon, just fall back to the "nearest city node" algorithm. A pretty nice description can already be found here: http://wiki.openstreetmap.org/wiki/OSM_tags_for_routing#City And IIRC, at least the TravelingSalesMan already has a working implementation for it. -- Gernot
participants (5)
-
Florian Lohoff -
Gernot Hillier -
Lambertus -
Mark Burton -
stefan＠binaervarianz.de