[PATCH v7] - alpha patch to support road find by name
v7 - now supports zip records for roads (data comes from addr:postcode tag). Also supports multiple ref names separated by ";" (e.g. ref="A123;B999") extra spaces should not matter. It still works for non-multiple ref names but I haven't actually tested it with multiple ref names (lack of suitable OSM data), feedback would be appreciated. ----------- Hi, The attached patch is for the current SVN trunk and it generates the sorted road data that is required by the gps to find roads/intersections by name. As for the number field, I haven't thought yet how that would get its data. Please test this patch and report success/failure. If it doesn't break anything for anyone, I would like to commit it fairly soon as I think that quite a few people will be happy to have street finding added to the trunk. Cheers, Mark
I realise that for the v7 patch, if a road has no name but multiple ref symbols, it will end up with a name containing the ref symbols which may not be what you want. To be honest, I think the statement in the lines file that assigns the ref to the name is not useful so future versions of this patch will comment out that line altogether. Cheers, Mark
Hi Mark, On Wed, Mar 18, 2009 at 12:26:53PM +0000, Mark Burton wrote:
v7 - now supports zip records for roads (data comes from addr:postcode tag).
Where can I see those? Maybe there is no such data in finland.osm yet. I tested the patch, and it looks like r984 is the most visible change since the pre-r984 patch I tried: the motorway exits are numbered and highlighted even at low zoom levels. I can search for "4" but there is no "E 75". Can you please also map int_ref? When I search for "14", the list will only show "14", not "140". Searching for "140" returns the road with ref=140. When it comes to joining roads, it would be good not to join long roads (several hundred kilometers), such as the 140. Now the list of matches will display useful information: which section of the ref=140 I want to go to. You could implement it so that road sections are joined when both sections are in the same "city". Marko
Hi Marko,
v7 - now supports zip records for roads (data comes from addr:postcode tag).
Where can I see those? Maybe there is no such data in finland.osm yet.
It's quite likely that the data isn't there. When I tested the feature, the zip info was displayed along with the city name when matching roads are shown. It could possibly also be displayed if you select a road on the map (not tested, just guessing).
I tested the patch, and it looks like r984 is the most visible change since the pre-r984 patch I tried: the motorway exits are numbered and highlighted even at low zoom levels.
I can search for "4" but there is no "E 75". Can you please also map int_ref?
OK - I will look at adding int_ref.
When I search for "14", the list will only show "14", not "140". Searching for "140" returns the road with ref=140.
You've lost me here - are you searching for an exit called 14?
When it comes to joining roads, it would be good not to join long roads (several hundred kilometers), such as the 140. Now the list of matches will display useful information: which section of the ref=140 I want to go to. You could implement it so that road sections are joined when both sections are in the same "city".
Good point - actually, I haven't got my head around the joining of roads to minimise the number of hits. It's not as simple to implement as you may imagine. Cheers, Mark
On Wed, Mar 18, 2009 at 01:54:04PM +0000, Mark Burton wrote:
Good point - actually, I haven't got my head around the joining of roads to minimise the number of hits. It's not as simple to implement as you may imagine.
Without any knowledge about the garmin format - Is the problem to find adjacent same referenced (name, ref) roads, or is it unknown/impossible to represent multiple road snippets under the same name/ref? I mean - there is another level of indirection as when there is a road with the same name one can search for a housenumber and specify a specific sub-part of the road. 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 Mark, I just returned from a 60 km bike journey. The routing worked great. When I refused to enter a track that was covered by soft snow, the Edge either computed a new route or allowed me to continue on a parallel road while displaying the "correct" route on the map.
When I tested the feature, the zip info was displayed along with the city name when matching roads are shown. It could possibly also be displayed if you select a road on the map (not tested, just guessing).
OK, I'll look into this. The zip info would be a very useful addition.
When I search for "14", the list will only show "14", not "140". Searching for "140" returns the road with ref=140.
You've lost me here - are you searching for an exit called 14?
In Finland, the motorways starting from Helsinki are numbered 1 through 7. The secondary roads parallel to the motorways are numbered 110, 120, 130, ..., 170. There is a road with ref=14 up north (not a motorway, AFAIK). In the search dialog for street names, the search is incremental for names, e.g., if I type "A", I see street names starting with "A". Same thing if I search for "1". Alas, if I type "14", the list will reduce to just "14". If I type "140", the road with ref=140 will show up again.
When it comes to joining roads, it would be good not to join long roads (several hundred kilometers), such as the 140. Now the list of matches will display useful information: which section of the ref=140 I want to go to. You could implement it so that road sections are joined when both sections are in the same "city".
Good point - actually, I haven't got my head around the joining of roads to minimise the number of hits. It's not as simple to implement as you may imagine.
I have programmed long enough to know that simple-sounding features are not necessarily easy to implement. Marko
Hi Marko,
I just returned from a 60 km bike journey. The routing worked great. When I refused to enter a track that was covered by soft snow, the Edge either computed a new route or allowed me to continue on a parallel road while displaying the "correct" route on the map.
I went out on my bike late afternoon. Lovely here, sunny, 12C and no wind (or snow!) I quite often use the routing to test it and it always seems to cope if I decide to use a different route - it just recalculates after a while.
When I tested the feature, the zip info was displayed along with the city name when matching roads are shown. It could possibly also be displayed if you select a road on the map (not tested, just guessing).
OK, I'll look into this. The zip info would be a very useful addition.
On the etrex, I think the zip info is only shown with the results of an address search.
When I search for "14", the list will only show "14", not "140". Searching for "140" returns the road with ref=140.
You've lost me here - are you searching for an exit called 14?
In Finland, the motorways starting from Helsinki are numbered 1 through 7. The secondary roads parallel to the motorways are numbered 110, 120, 130, ..., 170. There is a road with ref=14 up north (not a motorway, AFAIK). In the search dialog for street names, the search is incremental for names, e.g., if I type "A", I see street names starting with "A". Same thing if I search for "1". Alas, if I type "14", the list will reduce to just "14". If I type "140", the road with ref=140 will show up again.
Thanks for spelling that out, I understand now. Hmmm, doesn't sound good. Not sure what's the problem there.
When it comes to joining roads, it would be good not to join long roads (several hundred kilometers), such as the 140. Now the list of matches will display useful information: which section of the ref=140 I want to go to. You could implement it so that road sections are joined when both sections are in the same "city".
Good point - actually, I haven't got my head around the joining of roads to minimise the number of hits. It's not as simple to implement as you may imagine.
I have programmed long enough to know that simple-sounding features are not necessarily easy to implement.
Due to time constraints (I do have to work as well!) I haven't had a real good think about this. I'm quite busy now so perhaps someone else will take up the challenge. To be honest, I'm fed up because I have put a lot of hours into the exit stuff and some more into this road addressing stuff and both features have annoying usability faults. So close... Cheers, Mark
Hi Mark,
Due to time constraints (I do have to work as well!) I haven't had a real good think about this. I'm quite busy now so perhaps someone else will take up the challenge.
To be honest, I'm fed up because I have put a lot of hours into the exit stuff and some more into this road addressing stuff and both features have annoying usability faults. So close...
Hey, it's not that bad. I think that the road name search is a useful feature even in its current form. The faults can be documented, and fixes can be attempted later. Come to think of it, even the maps without routing support were useful. Marko
Hi Marko,
Due to time constraints (I do have to work as well!) I haven't had a real good think about this. I'm quite busy now so perhaps someone else will take up the challenge.
To be honest, I'm fed up because I have put a lot of hours into the exit stuff and some more into this road addressing stuff and both features have annoying usability faults. So close...
Hey, it's not that bad. I think that the road name search is a useful feature even in its current form. The faults can be documented, and fixes can be attempted later. Come to think of it, even the maps without routing support were useful.
True, true - Rome wasn't built in a day, etc. Playing around with the road name search, I just verified that if you prefix your numeric road names with one or more letters ('AA', for example) they are now incrementally searchable. So we could put in a hack to add the prefix? Cheers, Mark
On Wed, Mar 18, 2009 at 10:21:53PM +0000, Mark Burton wrote:
Subject: Re: [mkgmap-dev] [PATCH v7] - alpha patch to support road find by name
Hi Marko,
Due to time constraints (I do have to work as well!) I haven't had a real good think about this. I'm quite busy now so perhaps someone else will take up the challenge.
To be honest, I'm fed up because I have put a lot of hours into the exit stuff and some more into this road addressing stuff and both features have annoying usability faults. So close...
Hey, it's not that bad. I think that the road name search is a useful feature even in its current form. The faults can be documented, and fixes can be attempted later. Come to think of it, even the maps without routing support were useful.
True, true - Rome wasn't built in a day, etc.
Playing around with the road name search, I just verified that if you prefix your numeric road names with one or more letters ('AA', for example) they are now incrementally searchable. So we could put in a hack to add the prefix?
Might it be that the order is wrong in the data? Probably the least specific match should be first: 1 14 140 vs 140 14 1 Probably the search stops if it finds an exact match so less specifics need to come first ... 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
To be honest, I'm fed up because I have put a lot of hours into the exit stuff and some more into this road addressing stuff and both features have annoying usability faults. So close...
I know that feeling. Still, you have your bike and the great weather at the moment so get pedalling, enjoy the fruits of your labour on your eTrex and leave the coding for a few days. That's what I'm doing Cheers Paul
Good point - actually, I haven't got my head around the joining of roads to minimise the number of hits. It's not as simple to implement as you may imagine.
I have implemented merging lines (not roads) in my simplifyWayPatch. The merging happens at another level, but you may take it at a start. I have tought a little about merging roads at import osm stage and found some problems: - The roads in the osm data are often splitted because of some reason, e.g. some segments of it has lower max speeds. So the merging has to take place AFTER the routing information has been extracted. - When is it allowed to merge two segments? At least the name and type has to be the same. - What to do, if three segements of the same road has the same start coordinate? (Sometimes seen on residentials)
Hi Johann,
Good point - actually, I haven't got my head around the joining of roads to minimise the number of hits. It's not as simple to implement as you may imagine.
I have implemented merging lines (not roads) in my simplifyWayPatch. The merging happens at another level, but you may take it at a start.
The road name pois code has a way joining routine because it tries to minimise the number of RNP points that have the same name. A similar algorithm could be helpful for the current requirement.
I have tought a little about merging roads at import osm stage and found some problems:
- The roads in the osm data are often splitted because of some reason, e.g. some segments of it has lower max speeds. So the merging has to take place AFTER the routing information has been extracted.
- When is it allowed to merge two segments? At least the name and type has to be the same.
From the point of view of finding roads with a given name, the type is irrelevant, surely?
- What to do, if three segements of the same road has the same start coordinate? (Sometimes seen on residentials)
Actually, you don't need to "join" the roads at all to limit the number of hits when searching for a street name. You simply have to limit the number of entries in the sorted road data structure to one entry per group of connected roads with the same name (not forgetting the observation that if the road stretches between "cities" you probably don't want to consider it all one road). Cheers, Mark
I have tought a little about merging roads at import osm stage and found some problems:
- The roads in the osm data are often splitted because of some reason, e.g. some segments of it has lower max speeds. So the merging has to take place AFTER the routing information has been extracted.
- When is it allowed to merge two segments? At least the name and type has to be the same.
From the point of view of finding roads with a given name, the type is irrelevant, surely?
Yes, you're right. In this situation the type shold not matter.
Actually, you don't need to "join" the roads at all to limit the number of hits when searching for a street name. From my point of view I would have tried to merge the segments at an early stage, so that all further tasks can work with the cleaned data. But the more I think about it, it will most probably not work.
Merging has to take place place after extraction of routing information. (see above) But before routing extraction the ways gets splitted to not exceed some size limits. If merging takes place afterwards, then the ways could get to long again. At the moment I've no idea where it would be a usefull place for merging to take place. With the words of Mark: More thinking required....
participants (5)
-
Florian Lohoff -
Johann Gail -
Mark Burton -
Marko Mäkelä -
Paul