[PATCH v10] - patch to support road find by name (now thinking about putting this in trunk)

v10 - based on r987. Functionally, should be identical to last version. If no one has any problems with either v9 or this version, I would like to commit this within the next few days. So please speak up if you have any issues with it. ----------- 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

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
Hi Mark, The address search seems to work well but I can't find any intersections. As I've probably misunderstood this feature here's an example of what I've been trying http://openstreetmap.org/?lat=53.50969&lon=-2.31557&zoom=15&layers=B000FTF If I use the address search for Agecroft Road, Pendlebury I'm taken to the point at which Agecroft Road and the A666 meet (the intersection?). Similarly if I search for A666, Pendlebury then I'm taken to the roundabout at the end of the A666, going past Agecroft Road on the way. If I then search for an intersection where Street 1 is Agecroft Road and Street 2 is A666 and City is Pendlebury I get no intersections found. WHat am I doing wrong? Cheers Paul

Hi Paul, Did you get out on your bike today, it was a super day around here.
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
Hi Mark,
The address search seems to work well but I can't find any intersections. As I've probably misunderstood this feature here's an example of what I've been trying
http://openstreetmap.org/?lat=53.50969&lon=-2.31557&zoom=15&layers=B000FTF
If I use the address search for Agecroft Road, Pendlebury I'm taken to the point at which Agecroft Road and the A666 meet (the intersection?). Similarly if I search for A666, Pendlebury then I'm taken to the roundabout at the end of the A666, going past Agecroft Road on the way. If I then search for an intersection where Street 1 is Agecroft Road and Street 2 is A666 and City is Pendlebury I get no intersections found.
WHat am I doing wrong?
Quite possibly, nothing wrong at all. Perhaps anyone else can confirm if the intersection feature is working correctly? Sorry, I have never used it before. Cheers, Mark

Hi. Ended up to China, Dalian to be exact. http://www.openstreetmap.org/?lat=39.009&lon=121.675&zoom=10&layers=B000FTF Loaded up several maps, splitted them up (with splitter.jar) and created an .img with mkgmap (leaving out the routing information). to my disapointment, my eTrex legend doesn't show the map, it just uses the base map instead, which is next to nothing. I even tried loading cloudmade built gmapsupp.img of china but results are the same. yet mapnik shows the coast and some details. Is the problem in mkgmap or eTrex? See comparison of mapnik and eTrex http://img256.imageshack.us/my.php?image=img1402.jpg (200kb)

Sorry, too much flying and too few sleep. My message was pretty confusing. Problem: Map of china generated by mkgmap is not used by eTrex Legend. Tested also a map of China (gmapsupp.img) available at cloudmade with same results.

Can you try deactivate the basic mao? It is ok for my 60csx... 2009/3/30 Jani Patanen <sqzwxa202@sneakemail.com>
Sorry, too much flying and too few sleep. My message was pretty confusing.
Problem: Map of china generated by mkgmap is not used by eTrex Legend. Tested also a map of China (gmapsupp.img) available at cloudmade with same results. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi. Noticed that the not appearing map problem appeared only when I tried to combine several tiles into one. Using mkgmap to build just china.osm produced ok map. I had split up Finland, Russia and China and tried to combine that as one gmapsupp.img produced the problems. I'd appreciate if someone could comment my procedure of making the map. Splitted the .osm files with splitter. then used mkgmap with option -c new.args.txt Contents of new.args.txt (disregard the quote marks):
# This file can be given to mkgmap using the -c option # Please edit it first to add a description of each map. #
# You can set the family id for the map # family-id: 980 # product-id: 1
charset: latin1 gmapsupp: name-tag-list=name:fi,name:en,int_name,name
# Following is a list of map tiles. Add a suitable description # for each one.
mapname: 63240001 description: OSM Map input-file: 63240001.ch.osm.gz
mapname: 63240002 description: OSM Map input-file: 63240002.ch.osm.gz
mapname: 63240004 description: OSM Map input-file: ru.63240001.osm.gz
mapname: 63240005 description: OSM Map input-file: ru.63240002.osm.gz
mapname: 63240006 description: OSM Map input-file: ru.63240003.osm.gz
mapname: 63240007 description: OSM Map input-file: ru.63240004.osm.gz
mapname: 63240008 description: OSM Map input-file: ru.63240005.osm.gz
mapname: 63240009 description: OSM Map input-file: ru.63240006.osm.gz
mapname: 63240010 description: OSM Map input-file: ru.63240007.osm.gz
mapname: 63240011 description: OSM Map input-file: fi.63240001.osm.gz
mapname: 63240012 description: OSM Map input-file: fi.63240002.osm.gz
mapname: 63240013 description: OSM Map input-file: fi.63240003.osm.gz

Sorry for the delay, my subscriber cable was accidentally cut by road construction workers on Thursday and fixed today. On Sun, Mar 29, 2009 at 10:10:57PM +0100, Mark Burton wrote:
Hi Paul,
Did you get out on your bike today, it was a super day around here.
I'm not Paul, but I couldn't resist. The roads were nice and dry on Saturday morning when my 3-year-old wanted to have a ride on our family bike (Santana Cabrio Quad, currently configured as a triplet). It was already pouring some snow flakes when we went for a quick ride. An hour later, there was some 5 cm (2 inches) of snow everywhere. All in all, we probably got 3 inches (15 cm) on Saturday. I was hoping for summer-like road conditions soon, but now it looks like we must wait for a couple of more weeks for the first real family ride.
Please test this patch and report success/failure.
One failure that I've had for a longer time is that I can't find the intersection Sillitie/Nahkiaisentie or Sillitie/Nieriäisentie. Nahkiaisentie/Nieriäisentie is found fine. Could it be a problem with T-intersections? Two more T-intersections that are not found: Jokivarrenkuja/Nahkiaisentie, Sorvatie/Nieriäisentie. Here are the intersections: http://www.openstreetmap.org/browse/node/290434977 http://www.openstreetmap.org/browse/node/290435001 http://www.openstreetmap.org/browse/node/288480793 http://www.openstreetmap.org/browse/node/288481297 Here is one more failing T-intersection where the names of all three intersecting ways change: http://www.openstreetmap.org/browse/node/288485085 I failed to find both these: Nieriäisenkuja/Nahkiaisentie Sorvatie/Nahkiaisentie (the main road) However, Nieriäisenkuja/Sorvatie is found, reported as "Nieriäisenkuja & Sorvatie & Nahkiaisentie". I also tried it as Sorvatie/Nieriäisenkuja, successfully. Best regards, Marko

Hi Marko,
Sorry for the delay, my subscriber cable was accidentally cut by road construction workers on Thursday and fixed today.
On Sun, Mar 29, 2009 at 10:10:57PM +0100, Mark Burton wrote:
Hi Paul,
Did you get out on your bike today, it was a super day around here.
I'm not Paul, but I couldn't resist. The roads were nice and dry on Saturday morning when my 3-year-old wanted to have a ride on our family bike (Santana Cabrio Quad, currently configured as a triplet). It was already pouring some snow flakes when we went for a quick ride. An hour later, there was some 5 cm (2 inches) of snow everywhere. All in all, we probably got 3 inches (15 cm) on Saturday. I was hoping for summer-like road conditions soon, but now it looks like we must wait for a couple of more weeks for the first real family ride.
Well, we can get snow here way past Easter but not quite in the same league.
Please test this patch and report success/failure.
One failure that I've had for a longer time is that I can't find the intersection Sillitie/Nahkiaisentie or Sillitie/Nieriäisentie. Nahkiaisentie/Nieriäisentie is found fine. Could it be a problem with T-intersections? Two more T-intersections that are not found: Jokivarrenkuja/Nahkiaisentie, Sorvatie/Nieriäisentie. Here are the intersections:
http://www.openstreetmap.org/browse/node/290434977 http://www.openstreetmap.org/browse/node/290435001 http://www.openstreetmap.org/browse/node/288480793 http://www.openstreetmap.org/browse/node/288481297
Here is one more failing T-intersection where the names of all three intersecting ways change:
http://www.openstreetmap.org/browse/node/288485085
I failed to find both these:
Nieriäisenkuja/Nahkiaisentie Sorvatie/Nahkiaisentie (the main road)
However, Nieriäisenkuja/Sorvatie is found, reported as "Nieriäisenkuja & Sorvatie & Nahkiaisentie". I also tried it as Sorvatie/Nieriäisenkuja, successfully.
I admit that I know nothing about how the intersection stuff works. The code we have been trying out simply outputs a data structure that lists the roads in alphabetic order. By including that data in the map, the gps now shows the find by address and find intersection options. It's the gps that's finding the intersections, not mkgmap. Cheers, Mark

Hi Mark, On Mon, Mar 30, 2009 at 08:33:27PM +0100, Mark Burton wrote:
Well, we can get snow here way past Easter but not quite in the same league.
The spring is extraordinarily late this year. A couple decades ago, we used to have some snow even in May, but the last three winters were very short, less than a month of permanent snow cover. I still firmly believe in global and local warming: also this winter, the permanent snow fell one or two months later than normal, in January.
I admit that I know nothing about how the intersection stuff works. The code we have been trying out simply outputs a data structure that lists the roads in alphabetic order.
By including that data in the map, the gps now shows the find by address and find intersection options. It's the gps that's finding the intersections, not mkgmap.
Sure. Without using a debugger, it's like shooting in the dark. Does MapSource or some other software (not firmware) support these find options? I only run GNU/Linux, so I don't know what MapSource does or what debuggers can do on Windows. I tried bicycle routing on my Edge 705 tonight, and it worked. (With the usual shortcomings: it didn't recalculate the route until I was very much off the route.) For all intents and purposes, your patch works. Please commit it. The current shortcomings can be documented on the wiki. I'd like to release my next Garmin map of Finland with the street name data, and I prefer to document the exact revisions of the tools used. Uncommitted patches would complicate that. Best regards, Marko

Hi Marko,
On Mon, Mar 30, 2009 at 08:33:27PM +0100, Mark Burton wrote:
Well, we can get snow here way past Easter but not quite in the same league.
The spring is extraordinarily late this year. A couple decades ago, we used to have some snow even in May, but the last three winters were very short, less than a month of permanent snow cover. I still firmly believe in global and local warming: also this winter, the permanent snow fell one or two months later than normal, in January.
Well, I'm sure the winters here now are not like they were when I was a kid.
I admit that I know nothing about how the intersection stuff works. The code we have been trying out simply outputs a data structure that lists the roads in alphabetic order.
By including that data in the map, the gps now shows the find by address and find intersection options. It's the gps that's finding the intersections, not mkgmap.
Sure. Without using a debugger, it's like shooting in the dark. Does MapSource or some other software (not firmware) support these find options? I only run GNU/Linux, so I don't know what MapSource does or what debuggers can do on Windows.
Mapsource doesn't show them. I use Linux 99.99% of the time but I can run Windoze XP using VMWare and it works very well for what I need to do.
I tried bicycle routing on my Edge 705 tonight, and it worked. (With the usual shortcomings: it didn't recalculate the route until I was very much off the route.) For all intents and purposes, your patch works. Please commit it. The current shortcomings can be documented on the wiki.
I'd like to release my next Garmin map of Finland with the street name data, and I prefer to document the exact revisions of the tools used. Uncommitted patches would complicate that.
OK that's a good enough reason to commit it, especially as nobody has reported any breakage when using the patch. Personally, I think the search weirdness we are seeing would go away if we could implement the extra indexing stuff (MDR file?) The reason I believe that is because I installed the complete NZ mapset (not produced by mkgmap) on my gps and the road search function worked just as you would hope. But then I installed a small portion of the map and the road search then behaved like it does on our maps. So, I think that the extra file(s) in the mapset alter how the road search works. Cheers, Mark

Hi Mark,
Personally, I think the search weirdness we are seeing would go away if we could implement the extra indexing stuff (MDR file?)
The reason I believe that is because I installed the complete NZ mapset (not produced by mkgmap) on my gps and the road search function worked just as you would hope. But then I installed a small portion of the map and the road search then behaved like it does on our maps. So, I think that the extra file(s) in the mapset alter how the road search works.
By 'complete NZ mapset', do you mean a commercial (and therefor encrypted) mapset? I'm far from understanding the garmin file formats, but if there are non-crypted examples of maps with working street search, couldn't there been extracted at least some knowledge? As an example I have here some OSM maps generated with some unknown tool (I asked the developer but got no answer) with working street search. So at least some tool out there knows how to do it. So is someone knows this tool, wouldn't it be possible to generate simplistic example maps (like with one or two streets) to study the format of the files? So my question is: are there any known tools that can generate street search enabled maps? I obviously only use mkgmap so far. Does cgsmapper have this functionality? regards Stefan

Hi Stefan,
Personally, I think the search weirdness we are seeing would go away if we could implement the extra indexing stuff (MDR file?)
The reason I believe that is because I installed the complete NZ mapset (not produced by mkgmap) on my gps and the road search function worked just as you would hope. But then I installed a small portion of the map and the road search then behaved like it does on our maps. So, I think that the extra file(s) in the mapset alter how the road search works.
By 'complete NZ mapset', do you mean a commercial (and therefor encrypted) mapset? I'm far from understanding the garmin file formats, but if there are non-crypted examples of maps with working street search, couldn't there been extracted at least some knowledge?
As an example I have here some OSM maps generated with some unknown tool (I asked the developer but got no answer) with working street search. So at least some tool out there knows how to do it.
So is someone knows this tool, wouldn't it be possible to generate simplistic example maps (like with one or two streets) to study the format of the files?
So my question is: are there any known tools that can generate street search enabled maps? I obviously only use mkgmap so far. Does cgsmapper have this functionality?
I agree, to improve the search functionality of our maps we need to learn what's missing/wrong and looking at simple examples of working maps can be very informative. Cheers, Mark
participants (6)
-
Jani Patanen
-
Mark Burton
-
Marko Mäkelä
-
Paul
-
stefan@binaervarianz.de
-
Xia Zhang