Feedback: Searchable Addresses (using r991)

As others have commented - congratulations are in order for the guys who've got *any* of this feature working. I've got a Streetpilot i3, and some of it works, other bits don't. If you go to "Where To"/"Address" on the Streetpilot, you first have to enter a "City Name". It seems that this actually means "Conurbation Name" since you're not restricted to cities - you can select villages too. However - if you select "Swansea" as the city (and it is a city), you next get asked for a house number.You can just enter anything in here since OSM doesn't (yet) do house numbers. That takes you to the bit where you select the street, or partially enter the street name. This is where things start getting odd. The list of selectable street names consists of all the streets in all the towns on the map! So presumably, the internal organisation of the tables isn't quite right yet? I'd have thought I'd only get to see the streets in the "city" that I'd selected? Anyway - typically when you select one of these streets (even ones that *are* in your "city"), the machine reports "Not Found". But I've noticed that this isn't always the case - if the street is within about 500m of the "place=city" marker for your city, then the street can be found. However, I've seen cases where streets that come within even 400m of the "place=city" marker can't be found, so it may be that the first or last point in the street's "way" must be within 500m. I've not managed to find a consistent rule for this yet. Additionally, I've seen cases where the street-name completion doesn't work. There's a street in Swansea called "Marlborough Road", but by the time you've entered "MAR" the machine will report "No Match". However, the street *can* be found if you enter "MA" then step into the list it offers and use the scrollwheel to find it. Not sure why that should happen. Hopefully some of these observations might be useful... Nice work so far - it's looking promising! Steve

Some more feedback about address search, in nüvi: When you select the Address option you're prompted for a State and a button to spell state is presented. If you push it a list of states is shown, but it's empty. Pushing "back" button leads you to a keyboard to enter state name, but any letter you push sends you back to the empty list with "No results found" message. The map I'm using to test is generated with the option --country-name=ESPAÑA. Can anyone with a nuvi confirm this behavior? Steve Hosgood escribió:
As others have commented - congratulations are in order for the guys who've got *any* of this feature working. I've got a Streetpilot i3, and some of it works, other bits don't.
If you go to "Where To"/"Address" on the Streetpilot, you first have to enter a "City Name". It seems that this actually means "Conurbation Name" since you're not restricted to cities - you can select villages too.
However - if you select "Swansea" as the city (and it is a city), you next get asked for a house number.You can just enter anything in here since OSM doesn't (yet) do house numbers. That takes you to the bit where you select the street, or partially enter the street name.
This is where things start getting odd.
The list of selectable street names consists of all the streets in all the towns on the map! So presumably, the internal organisation of the tables isn't quite right yet? I'd have thought I'd only get to see the streets in the "city" that I'd selected?
Anyway - typically when you select one of these streets (even ones that *are* in your "city"), the machine reports "Not Found". But I've noticed that this isn't always the case - if the street is within about 500m of the "place=city" marker for your city, then the street can be found.
However, I've seen cases where streets that come within even 400m of the "place=city" marker can't be found, so it may be that the first or last point in the street's "way" must be within 500m. I've not managed to find a consistent rule for this yet.
Additionally, I've seen cases where the street-name completion doesn't work. There's a street in Swansea called "Marlborough Road", but by the time you've entered "MAR" the machine will report "No Match". However, the street *can* be found if you enter "MA" then step into the list it offers and use the scrollwheel to find it. Not sure why that should happen.
Hopefully some of these observations might be useful... Nice work so far - it's looking promising! Steve
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale OpenOffice desde http://es.openoffice.org/programa/index.html OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. OpenOffice es gratis. El uso de OpenOffice es totalmente legal. OpenOffice funciona mejor que otros paquetes de oficina. OpenOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.

Hi Carlos, yes I can confirm this behavior on the nuvi. It looks like the nuvi needs the MDR file for the address search option. Is there anybody who wants to join me in understanding the MDR file ? I did already some research on the MDR file. Most of the sections I have not decoded until now. The MDR file has about 20 mysterious sections. What I found out so far is that we need at least 7 sections to enable the Nuvi address search. I found this out by removing section by section out of the header of a working MDR file. I have added some code to libgarmin to display some sections of the MDR. I'm able to decode some parts of the city, street and region index. I also started implementing some prototype to write this MDR blocks in mkgmap. Until know I didn't managed to generate a file that would open at least the country select dialog on the nuvi. I think it will be a long way. But I think it is doable since there are working examples e.g. generated by cgpsmapper that are not encrypted. First of all I think we need a site to collect information ? I'm not so sure if the OSM wiki is the right location to collect garmin file information ? Thanks Berni.
Some more feedback about address search, in nüvi: When you select the Address option you're prompted for a State and a button to spell state is presented. If you push it a list of states is shown, but it's empty. Pushing "back" button leads you to a keyboard to enter state name, but any letter you push sends you back to the empty list with "No results found" message. The map I'm using to test is generated with the option --country-name=ESPAÑA. Can anyone with a nuvi confirm this behavior

On Wed, Apr 08, 2009 at 07:36:09PM +0200, Bernhard Heibler wrote:
Is there anybody who wants to join me in understanding the MDR file ? I did already some research on the MDR file. Most of the sections I have not decoded until now. The MDR file has about 20 mysterious sections. What I found out so far is that we need at least 7 sections to enable the Nuvi address search. I found this out by removing section by section out of the header of a working MDR file. I have added some code to libgarmin to display some sections of the MDR. I'm able to decode some parts of the city, street and region index.
Have you looked at the MdrDisplay program in the display svn: http://svn.mkgmap.org.uk/display/trunk/src/test/display/MdrDisplay.java This contains everything I know about the format. Hopefully you can add to that knowledge. One difficulty is that there are different versions of the sections with different sizes. Also when downloaded to a GPSr device some of the sections are not sent and the sections that are can have a reduced size. MDR5 contains pointers the the string table in MDR 15 and also to the LBL section. I guess that the MDR 15 pointers are used by mapsource and the LBL pointers by the device. Neither the MDR15 section nor the pointers to it are in the device version. ..Steve

Steve Ratcliffe wrote:
On Wed, Apr 08, 2009 at 07:36:09PM +0200, Bernhard Heibler wrote:
Is there anybody who wants to join me in understanding the MDR file ? I did already some research on the MDR file. Most of the sections I have not decoded until now. The MDR file has about 20 mysterious sections. What I found out so far is that we need at least 7 sections to enable the Nuvi address search. I found this out by removing section by section out of the header of a working MDR file. I have added some code to libgarmin to display some sections of the MDR. I'm able to decode some parts of the city, street and region index.
Have you looked at the MdrDisplay program in the display svn: http://svn.mkgmap.org.uk/display/trunk/src/test/display/MdrDisplay.java This contains everything I know about the format. Hopefully you can add to that knowledge.
Is it possible to run a wiki page (or a set of wiki pages) so as to accumulate reverse-engineered knowledge on a file format? I've been in other situations where this sort of idea seemed to be the "right way" to go about it, but in practice it seems to be easier said than done. Especially for documenting a file-format. The problem for mkgmap developers as I see it right now is that John Mechelas's 2005 documents are often cited as the starting point, with Steve Ratcliffe's extensions to that knowledge being partially written up as documents (in a different style) and partially represented as the code in a bunch of .java programs. There are probably many other contributors whose work is only seen in the form of code in the .java programs. But currently, there is no place for a newcomer to go to read up on this stuff. I think a wiki page (if it could be kept in a unified format) would win over some documentation file kept under SVN. Anyone got any better ideas? Steve

Steve Ratcliffe wrote:
On Wed, Apr 08, 2009 at 07:36:09PM +0200, Bernhard Heibler wrote:
Is there anybody who wants to join me in understanding the MDR file ? I did already some research on the MDR file. Most of the sections I have not decoded until now. The MDR file has about 20 mysterious sections. What I found out so far is that we need at least 7 sections to enable the Nuvi address search. I found this out by removing section by section out of the header of a working MDR file. I have added some code to libgarmin to display some sections of the MDR. I'm able to decode some parts of the city, street and region index.
Have you looked at the MdrDisplay program in the display svn: http://svn.mkgmap.org.uk/display/trunk/src/test/display/MdrDisplay.java This contains everything I know about the format. Hopefully you can add to that knowledge.
Might I suggest everyone contributes info to the wiki? I just created a page for the IMG file as a whole, and I intend to seed it with info from John Mechelas's 2005 document, then add in all the other info I can find to try and fill in the gaps - it's here: http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format You'll see that although it hardly contains any useful info yet, it mentions the sorts of subfiles contained inside the IMG file, and I created a placeholder page for the MDR subfile too. Currently, that page is even more useless than the IMG page (:-)), but it will grow if anyone thinks (as I do) that this would be a good way to aggregate info as the file formats are reverse-engineered. Stone Soup and all that jazz... ( I'm making use of the "wikitable" class in order to keep the formatting of the info under some sort of control and with a similar "look and feel" across the pages as they grow (if they grow). You may know a better method, but this one seems to work OK for Wikipedia. ) Hope it proves useful Steve
participants (4)
-
Bernhard Heibler
-
Carlos Dávila
-
Steve Hosgood
-
Steve Ratcliffe