Re: [mkgmap-dev] Address index changes in dev-index branch
Okay I'm uploading the gmapsupp.img now. However the difference isn't that small - at least in data size. For my testcase, Austria, it is 239.4MB (mkgmap) vs 239.6MB (Mapsource). http://openmtbmap.org/gmapsupp_mapsource.img vs http://openmtbmap.org/GMAPSUPP_diff_sort.IMG mkgmap does throw a warning now: different sort order, but of course Mapsource can handle it... ------------------- Oh and there is a second change - I forgot mentioning in the earlier mails. the address branch doesn't add .tmp to broken mdr and mdx files, I hope this is changed back before merging and only for testing, as the .tmp ending is really practical and needed for automatic checking if the mkmgap output went through without major errors. On 12.06.2012 23:38, Steve Ratcliffe wrote:
On 06/12/2012 10:28 PM, Felix Hartmann wrote:
Yes, I'll upload it tomorrow (both working and broken).
So far I didn't see any changes. So it seems okay.
Thanks. There are very few differences between the mkgmap index and the mapsource index in my tests, so it shouldn't be too hard to solve this.
Cheers,
Steve
Hi Thanks for uploading them.
I think this one may have failed to upload fully, it hasn't got any larger in the last hour or so.
The GMAPSUPP_diff_sort.IMG I downloaded is 246284288 bytes and looks complete. However it does not contain an index at all, so that is why it is broken. If I extract the .img files and recombine I do get an index. What is your command line you used to creat it?
Oh and there is a second change - I forgot mentioning in the earlier mails. the address branch doesn't add .tmp to broken mdr and mdx files, I hope this is changed back before merging and only for testing, as the .tmp ending is really practical and needed for automatic checking if the mkmgap output went through without major errors.
There is nothing I think of that would cause this, there is certainly no deliberate change. Perhaps this is related to the other problem? ..Steve
oh damn, my mistake.... I'm just uploading the proper mkgmap created gmapsupp and again the gmapsupp by Mapsource - even with address index, my fault before, it is .4MB smaller than the one generated by Mapsource... openmtbmap.org/gmapsupp_mapsource.img (239.6MB - should be online in 40 minutes from now) openmtbmap.org/gmapsupp_mkgmap.img (239.1MB - should be online in 80 minutes from now) Here is the commandline for mkgmap to write the gmapsupp: start /low /b /wait java -jar -Xmx3000M mkgmap.jar --latin1 --family-id=6365 "--index" --show-profiles=1 --description=""omtbmap_srtm"_openmtbmap_a_13.06.2012" --series-name=""omtbmap_srtm"_openmtbmap_a_13.06.2012" --family-name=""omtbmap_srtm"_openmtbmap_a_13.06.2012" --product-id=1 --gmapsupp 6*.img 7*.img trad6365.TYP Time started: Wed Jun 13 12:25:21 CEST 2012 WARNING: input files have differing sort orders Time finished: Wed Jun 13 12:25:42 CEST 2012 Total time taken: 21073ms On 13.06.2012 12:18, Steve Ratcliffe wrote:
Hi
Thanks for uploading them.
http://openmtbmap.org/gmapsupp_mapsource.img I think this one may have failed to upload fully, it hasn't got any larger in the last hour or so.
http://openmtbmap.org/GMAPSUPP_diff_sort.IMG The GMAPSUPP_diff_sort.IMG I downloaded is 246284288 bytes and looks complete.
However it does not contain an index at all, so that is why it is broken.
If I extract the .img files and recombine I do get an index. What is your command line you used to creat it?
Oh and there is a second change - I forgot mentioning in the earlier mails. the address branch doesn't add .tmp to broken mdr and mdx files, I hope this is changed back before merging and only for testing, as the .tmp ending is really practical and needed for automatic checking if the mkmgap output went through without major errors. There is nothing I think of that would cause this, there is certainly no deliberate change. Perhaps this is related to the other problem?
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 06/13/2012 11:34 AM, Felix Hartmann wrote:
oh damn, my mistake....
I'm just uploading the proper mkgmap created gmapsupp and again the gmapsupp by Mapsource - even with address index, my fault before, it is .4MB smaller than the one generated by Mapsource...
Thanks, that all looks OK now. The differences in size are all down to POI sections of the index. There are no obvious street address related differences so it is going to be tricky to track down the important change. First I will have to see if I can reproduce the problems, because I've not really seen the difference in my own tests. ..Steve
So for you the address index in BOTH gmapsupp.img is working?? (and it's the only map on the etrex 30)? The mkgmap created gmapsupp won't break address search of other maps for me, but it doesn't work on itself. On 13.06.2012 15:53, Steve Ratcliffe wrote:
On 06/13/2012 11:34 AM, Felix Hartmann wrote:
oh damn, my mistake....
I'm just uploading the proper mkgmap created gmapsupp and again the gmapsupp by Mapsource - even with address index, my fault before, it is .4MB smaller than the one generated by Mapsource...
Thanks, that all looks OK now.
The differences in size are all down to POI sections of the index. There are no obvious street address related differences so it is going to be tricky to track down the important change.
First I will have to see if I can reproduce the problems, because I've not really seen the difference in my own tests.
..Steve
On 06/13/2012 07:23 PM, Felix Hartmann wrote:
So for you the address index in BOTH gmapsupp.img is working?? (and it's the only map on the etrex 30)?
The mkgmap created gmapsupp won't break address search of other maps for me, but it doesn't work on itself.
I might be on to something... I'll just say what happened with your maps that I downloaded today. 1. Copied gmapsupp_mkgmap.img to an SD card and put it in my eTrex 30: didn't work. 2. Copied gmapsupp_mapsource.img to SD card: also didn't work !? 3. Disabled the map (the mapsource generated one) 3a. Tried to search with the map disabled - crashed. (don't suppose this is relevent but mentioned for completeness). 4. Enabled the map (the mapsource generated one) - now works! So it seems like there is some memory or caching of previous maps which is fixed by disabling & enabling the map. When I was trying the mkgmap maps, I was also messing about disabling and enabling the basemaps and I suspect that was why it was eventually working. I'm about to investigate further with mkgmap map now. ..Steve
I'm about to investigate further with mkgmap map now.
I copied the mkgmap map onto the SD card, and it worked for searching straight away. (I did not disable/enable the map). So both maps work or don't work depending on what was installed before hand. I should note that I copied the map on top of the existing one and didn't delete the existing one first. You wouldn't normally expect that to make a difference, but who knows... ..Steve
well, best copy it in with a different name. Well and I should probably generate a new map with Mapsource using different FID, then there will be no caching enacted. Another reason, why the Mapsource generated map maybe didn't work, was that you had no GPS reception (yet)??? I noticed that with all mkgmap generated maps (in comparison to Garmin CN maps which don't have this problem) without GPS reception, address search doesn't work (or I ran into some caching here, but this seemed to be consistent). On 13.06.2012 22:11, Steve Ratcliffe wrote:
On 06/13/2012 07:23 PM, Felix Hartmann wrote:
So for you the address index in BOTH gmapsupp.img is working?? (and it's the only map on the etrex 30)?
The mkgmap created gmapsupp won't break address search of other maps for me, but it doesn't work on itself.
I might be on to something...
I'll just say what happened with your maps that I downloaded today.
1. Copied gmapsupp_mkgmap.img to an SD card and put it in my eTrex 30: didn't work.
2. Copied gmapsupp_mapsource.img to SD card: also didn't work !?
3. Disabled the map (the mapsource generated one)
3a. Tried to search with the map disabled - crashed. (don't suppose this is relevent but mentioned for completeness).
4. Enabled the map (the mapsource generated one) - now works!
So it seems like there is some memory or caching of previous maps which is fixed by disabling & enabling the map.
When I was trying the mkgmap maps, I was also messing about disabling and enabling the basemaps and I suspect that was why it was eventually working.
I'm about to investigate further with mkgmap map now.
..Steve
Another reason, why the Mapsource generated map maybe didn't work, was that you had no GPS reception (yet)???
I always waited until there was GPS reception. I am outside the area of the map, which you earlier said may a difference, for what it is worth. So does the mkgmap map work for you if you disanable and then re-enable it? ..Steve
Sorry for the long time to reply. Yes enabling/disabling the map does help. It also works without enabling/disabling, as long as I use a different MapID. Also, unlike your testcase, I get no crash if map is disabled, and it seems the GPS reception doesn't matter if I enable/disable. So I think you can commit the branch. Nevertheless, it would be cool, if mkgmap could generate the POI the way Mapsource/Basecamp do, just to make sure it's more on the same standard, if possible. I noticed that people who created maps for the GPS with mkgmap and address search, instead of using Mapsource/Basecamp where more likely to run into the "memory full" bug (which is however corrected in the newest generation firmwares, but it will take some time till everyone uses the newest generation firmwares). Felix On 14.06.2012 16:01, Steve Ratcliffe wrote:
Another reason, why the Mapsource generated map maybe didn't work, was that you had no GPS reception (yet)???
I always waited until there was GPS reception.
I am outside the area of the map, which you earlier said may a difference, for what it is worth.
So does the mkgmap map work for you if you disanable and then re-enable it?
..Steve
Hi
Yes enabling/disabling the map does help. It also works without enabling/disabling, as long as I use a different MapID. Also, unlike your testcase, I get no crash if map is disabled, and it seems the GPS reception doesn't matter if I enable/disable.
I have since found that just clicking Enable was enough on my etrex30, there was no need to disable first.
So I think you can commit the branch. Nevertheless, it would be cool, if mkgmap could generate the POI the way Mapsource/Basecamp do, just to
Yes of course. I've had a few false starts in getting it right. I think I will back out the change I made on the branch before merging and then resume fixing it fully. ..Steve
On Wed, Jun 13, Felix Hartmann wrote:
Another reason, why the Mapsource generated map maybe didn't work, was that you had no GPS reception (yet)??? I noticed that with all mkgmap generated maps (in comparison to Garmin CN maps which don't have this problem) without GPS reception, address search doesn't work (or I ran into some caching here, but this seemed to be consistent).
At cannot confirm this, at least not for my GPSmap 62s with firmware 3.90. Address search did and does always work. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
participants (3)
-
Felix Hartmann -
Steve Ratcliffe -
Thorsten Kukuk