Index branch - success!
Hi Some progress on the index branch. I found that the flags at the end of mdr7 trigger the acceptance of the 20-29 sections. I can now download the maps to my Legend. Now when you try address search, it is in a completely different mode. There is a country field (although labelled region) and as you make selections in the country/city fields it reduces the options available in the streets field Addresses can be found in other tiles and not just the closest one. ..Steve
Wow! Big congratulations!!! I've tested a 6-tile map of germany and it's working (which means uploading to my Oregon 400 - search works!). Have fun! (I'm sure you have :-) WanMil
Hi
Some progress on the index branch.
I found that the flags at the end of mdr7 trigger the acceptance of the 20-29 sections.
I can now download the maps to my Legend.
Now when you try address search, it is in a completely different mode. There is a country field (although labelled region) and as you make selections in the country/city fields it reduces the options available in the streets field
Addresses can be found in other tiles and not just the closest one.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
I tried to compile a complete europe map. It failed with the following exception (sounds easy to fix...?-): Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.imgfmt.app.mdr.Mdr23.sortRegions(Mdr23.java:54) at uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:246) at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:223) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:335) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:419) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:129) WanMil
Wow! Big congratulations!!! I've tested a 6-tile map of germany and it's working (which means uploading to my Oregon 400 - search works!).
Have fun! (I'm sure you have :-) WanMil
Hi
Some progress on the index branch.
I found that the flags at the end of mdr7 trigger the acceptance of the 20-29 sections.
I can now download the maps to my Legend.
Now when you try address search, it is in a completely different mode. There is a country field (although labelled region) and as you make selections in the country/city fields it reduces the options available in the streets field
Addresses can be found in other tiles and not just the closest one.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 11/02/2011 20:59, WanMil wrote:
I tried to compile a complete europe map. It failed with the following exception (sounds easy to fix...?-):
Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.imgfmt.app.mdr.Mdr23.sortRegions(Mdr23.java:54)
Easy to stop the exception perhaps ;) but how is it getting to be null? All regions should have one of those set in the previous method. Anyway I just compilled a complete UK extract and tried to upload all the tiles and it failed with the usual error after a while. So a complete Europe build might be a bit ambitious at this time. ..Steve
Compiled germany with it. Compiling works. Copy gmap.img to 60CSX. Map works. Search same as in older days. Do i need Mapsource ? use OS X 10.6 ;-( Flabot
On Feb 11, 2011, at 22:31, flabot@googlemail.com wrote:
Compiled germany with it. Compiling works. Copy gmap.img to 60CSX. Map works. Search same as in older days. Do i need Mapsource ? use OS X 10.6 ;-(
On OS X, you should be able to use Garmin Basecamp and Mapinstall to install the maps. (You first need to create a .gmapi file from the .img files: there is a Perl script for that.) I have done this with older versions of mkgmap with semi-working address search, so I suspect that it should work with the index branch as well. Cheers.
On Feb 11, 2011, at 22:31, flabot@googlemail.com wrote:
Compiled germany with it. Compiling works. Copy gmap.img to 60CSX. Map works. Search same as in older days. Do i need Mapsource ? use OS X 10.6 ;-(
Just to update: I have now successfully transferred a map on Mac OS X to my Nüvi. Address search works. To review, this is my workflow: 1. Compile map with mgkmap using the --tdbfile option. 2. Use gmapi-builder.py to compile the .img and other map files to a .gmapi file. 3. Use Garmin MapManager to install the .gmapi file on your Mac. (The installed file can be viewed with Garmin BaseCamp. 4. Use Garmin MapInstall to transfer the map to your GPS device. (Using a card reader is normally the fastest method.) Cheers.
El 11/02/11 23:58, Clinton Gladstone escribió:
On Feb 11, 2011, at 22:31, flabot@googlemail.com wrote:
Compiled germany with it. Compiling works. Copy gmap.img to 60CSX. Map works. Search same as in older days. Do i need Mapsource ? use OS X 10.6 ;-(
Just to update: I have now successfully transferred a map on Mac OS X to my Nüvi. Address search works.
To review, this is my workflow:
1. Compile map with mgkmap using the --tdbfile option.
2. Use gmapi-builder.py to compile the .img and other map files to a .gmapi file.
3. Use Garmin MapManager to install the .gmapi file on your Mac. (The installed file can be viewed with Garmin BaseCamp.
4. Use Garmin MapInstall to transfer the map to your GPS device. (Using a card reader is normally the fastest method.) I use gmapi-builder.py to transform my maps into BaseCamp format, but it fails with those containing an Ñ (from España) in --country-name --area-name --family-name or series-name. Do you know a way to get it compiling? (other than changing España by Spain)
On Feb 12, 2011, at 16:59, Carlos Dávila wrote:
I use gmapi-builder.py to transform my maps into BaseCamp format, but it fails with those containing an Ñ (from España) in --country-name --area-name --family-name or series-name. Do you know a way to get it compiling? (other than changing España by Spain)
That's strange. What error message does it give? Could you please send the exact command line options which you use, so I can reproduce this? Cheers.
El 12/02/11 17:05, Clinton Gladstone escribió:
On Feb 12, 2011, at 16:59, Carlos Dávila wrote:
I use gmapi-builder.py to transform my maps into BaseCamp format, but it fails with those containing an Ñ (from España) in --country-name --area-name --family-name or series-name. Do you know a way to get it compiling? (other than changing España by Spain)
That's strange. What error message does it give?
Could you please send the exact command line options which you use, so I can reproduce this?
Cheers.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Failing maps are generated with: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=ESPAÑA --country-abbr=ESP --area-name=España --family-name="OpenStreetMap España" --family-id=14 --product-id=1 --series-name="OSM-España" --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args Working maps are generated with: java -Xmx1500m -enableassertions -Dlog.config=logging.properties -jar mkgmap.jar --max-jobs --generate-sea=polygons,extend-sea-sectors --route --latin1 --code-page=1252 --gmapsupp --country-name=SPAIN --country-abbr=ESP --area-name=Spain --family-name="OpenStreetMap Spain" --family-id=14 --product-id=1 --series-name="OSM-Spain" --index --road-name-pois=0x640a --ignore-maxspeeds --remove-short-arcs --add-pois-to-areas --adjust-turn-headings --report-similar-arcs --link-pois-to-ways --location-autofill=0 --drive-on-right --check-roundabouts --check-roundabout-flares --style=mio --delete-tags-file=quitar_is_in -c spain.args Conversion to gmap format in both cases: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-14.TYP 5514*.img osmmap.img
On Feb 12, 2011, at 17:52, Carlos Dávila wrote:
Conversion to gmap format in both cases: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-14.TYP 5514*.img osmmap.img
Try the attached file. I quickly hacked it up to support latin-1 encoding for names. Also, if you are using the --index option in mkgmap, remember to include the index files in gmapi-builder. Example: $ gmapi-builder.py -t 14000000.tdb -b 14000000.img -s 14.TYP -i 14000000.mdx -m 14000000_mdr.img *.img Cheers!
El 12/02/11 23:54, Clinton Gladstone escribió:
On Feb 12, 2011, at 17:52, Carlos Dávila wrote:
Conversion to gmap format in both cases: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-14.TYP 5514*.img osmmap.img
Try the attached file. I quickly hacked it up to support latin-1 encoding for names.
Also, if you are using the --index option in mkgmap, remember to include the index files in gmapi-builder. Example:
$ gmapi-builder.py -t 14000000.tdb -b 14000000.img -s 14.TYP -i 14000000.mdx -m 14000000_mdr.img *.img Thank you for the file, which works fine converting. I have not tested resulting maps though, because I don't have a Mac. In case any user of my maps report any problem I'll tell you. Thank you also for the tips about index. I had not seen any comment about -i and -m parameters on the wiki [1] neither on gmapi--builder_README.txt. According to [1] the version from [2] is supposed to be newer than the one from [3], but the later includes support for index whereas the former doesn't. Should I change it on the wiki?
[1] http://wiki.openstreetmap.org/wiki/Gmapibuilder#Commandline_version [2] http://bitbucket.org/berteun/gmapibuilder/downloads/gmapi-builder.tar.gz [3] http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py
On Feb 13, 2011, at 16:14, Carlos Dávila wrote:
Thank you also for the tips about index. I had not seen any comment about -i and -m parameters on the wiki [1] neither on gmapi--builder_README.txt. According to [1] the version from [2] is supposed to be newer than the one from [3], but the later includes support for index whereas the former doesn't. Should I change it on the wiki?
I'll try and check to see if the "newest" version according to the Wiki has any significant changes compared to the one in the mkgmap repository. I had previously attempted several times to contact the original developer of the script, but it seems that he has mostly lost interest. It could be that the "newest" version is simply the original moved to a new location. Cheers.
I'm also having some problems with getting a map of mine into BaseCamp for MacOS. My source is a self-generated map made from ireland.osm (Geofabrik) with the latest index branch snapshot. I had to persevere before I managed to get the command line version of gmapibuilder from: http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py ...to do what I wanted. I have always use the GUI version until now. I started wtih a command line like this: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i osmmap.mdx -m osmmap_mdr.img 55555555.img This completed, and Garmin Map Manager copied the result into place, but BaseCamp failed to use it. But including the base map in the list of maps at the end of the command line produced something that BaseCamp will accept: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 55555555.img The problem is, Basecamp still claims that the map lacks address information, so I'm out of ideas. Can anybody see a snag with what I've done? Dermot -- -------------------------------------- Igaühel on siin oma laul ja ma oma ei leiagi üles
El 15/02/11 17:41, Dermot McNally escribió:
I'm also having some problems with getting a map of mine into BaseCamp for MacOS. My source is a self-generated map made from ireland.osm (Geofabrik) with the latest index branch snapshot.
I had to persevere before I managed to get the command line version of gmapibuilder from: http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py
...to do what I wanted. I have always use the GUI version until now. I started wtih a command line like this:
python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i osmmap.mdx -m osmmap_mdr.img 55555555.img
This completed, and Garmin Map Manager copied the result into place, but BaseCamp failed to use it.
But including the base map in the list of maps at the end of the command line produced something that BaseCamp will accept:
python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 55555555.img
The problem is, Basecamp still claims that the map lacks address information, so I'm out of ideas. Can anybody see a snag with what I've done?
Dermot
Using latest script from Clinton Gladstone with a similar command line as yours I've seen osmmap_mdr.img is not included in the resulting files tree. Maybe this is the reason for the address information complain.
2011/2/15 Carlos Dávila <cdavilam@orangecorreo.es>:
Using latest script from Clinton Gladstone with a similar command line as yours I've seen osmmap_mdr.img is not included in the resulting files tree. Maybe this is the reason for the address information complain.
Interesting - I'm not very clued into what files should be in there and where, but here's what's being created: total 40 drwxr-xr-x 6 dermot staff 204 15 Feb 16:36 . drwxr-xr-x 3 dermot staff 102 15 Feb 16:36 .. -rw-r--r-- 1 dermot staff 535 15 Feb 16:36 Info.xml drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 OSMTiles -rw-r--r-- 1 dermot staff 11982 15 Feb 16:36 dermot3.TYP -rw-r--r-- 1 dermot staff 26 15 Feb 16:36 osmmap.mdx ./OSMTiles: total 8 drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 . drwxr-xr-x 6 dermot staff 204 15 Feb 16:36 .. drwxr-xr-x 7 dermot staff 238 15 Feb 16:36 55555555 drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 osmmap -rw-r--r-- 1 dermot staff 560 15 Feb 16:36 osmmap.tdb ./OSMTiles/55555555: total 48624 drwxr-xr-x 7 dermot staff 238 15 Feb 16:36 . drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 .. -rw-r--r-- 1 dermot staff 973088 15 Feb 16:36 55555555.LBL -rw-r--r-- 1 dermot staff 3506553 15 Feb 16:36 55555555.NET -rw-r--r-- 1 dermot staff 7943265 15 Feb 16:36 55555555.NOD -rw-r--r-- 1 dermot staff 12422575 15 Feb 16:36 55555555.RGN -rw-r--r-- 1 dermot staff 40062 15 Feb 16:36 55555555.TRE ./OSMTiles/osmmap: total 24 drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 . drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 .. -rw-r--r-- 1 dermot staff 275 15 Feb 16:36 63240000.LBL -rw-r--r-- 1 dermot staff 145 15 Feb 16:36 63240000.RGN -rw-r--r-- 1 dermot staff 462 15 Feb 16:36 63240000.TRE Are there any obvious omissions? If so, can I just copy stuff into place? Thanks, Dermot -- -------------------------------------- Igaühel on siin oma laul ja ma oma ei leiagi üles
The mdr file is missing. Here is the line from the script which I use: gmapi-builder.py -t /$OVERVIEW_MAPNAME.tdb -b $OVERVIEW_MAPNAME.img -s $TYP_LOCAL -i ${OVERVIEW_MAPNAME}.mdx -m ${OVERVIEW_MAPNAME}_mdr.img *.img Note at the end, I have a "*.img" statement, which includes ALL .img files in the builder. Your command would likely work with the following: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s dermot3.TYP -i osmmap.mdx -m osmmap_mdr.img osmmap.img 55555555.img osmmap_mdr.img - See that osmmap_mdr.img is listed twice on the command line: once after the -m switch, and once in the list of all .img files. Yes, this is somewhat redundant. ;-) Cheers On Feb 15, 2011, at 18:37, Dermot McNally wrote:
2011/2/15 Carlos Dávila <cdavilam@orangecorreo.es>:
Using latest script from Clinton Gladstone with a similar command line as yours I've seen osmmap_mdr.img is not included in the resulting files tree. Maybe this is the reason for the address information complain.
Interesting - I'm not very clued into what files should be in there and where, but here's what's being created:
total 40 drwxr-xr-x 6 dermot staff 204 15 Feb 16:36 . drwxr-xr-x 3 dermot staff 102 15 Feb 16:36 .. -rw-r--r-- 1 dermot staff 535 15 Feb 16:36 Info.xml drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 OSMTiles -rw-r--r-- 1 dermot staff 11982 15 Feb 16:36 dermot3.TYP -rw-r--r-- 1 dermot staff 26 15 Feb 16:36 osmmap.mdx
./OSMTiles: total 8 drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 . drwxr-xr-x 6 dermot staff 204 15 Feb 16:36 .. drwxr-xr-x 7 dermot staff 238 15 Feb 16:36 55555555 drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 osmmap -rw-r--r-- 1 dermot staff 560 15 Feb 16:36 osmmap.tdb
./OSMTiles/55555555: total 48624 drwxr-xr-x 7 dermot staff 238 15 Feb 16:36 . drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 .. -rw-r--r-- 1 dermot staff 973088 15 Feb 16:36 55555555.LBL -rw-r--r-- 1 dermot staff 3506553 15 Feb 16:36 55555555.NET -rw-r--r-- 1 dermot staff 7943265 15 Feb 16:36 55555555.NOD -rw-r--r-- 1 dermot staff 12422575 15 Feb 16:36 55555555.RGN -rw-r--r-- 1 dermot staff 40062 15 Feb 16:36 55555555.TRE
./OSMTiles/osmmap: total 24 drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 . drwxr-xr-x 5 dermot staff 170 15 Feb 16:36 .. -rw-r--r-- 1 dermot staff 275 15 Feb 16:36 63240000.LBL -rw-r--r-- 1 dermot staff 145 15 Feb 16:36 63240000.RGN -rw-r--r-- 1 dermot staff 462 15 Feb 16:36 63240000.TRE
Are there any obvious omissions? If so, can I just copy stuff into place?
Thanks, Dermot
-- -------------------------------------- Igaühel on siin oma laul ja ma oma ei leiagi üles _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 15 February 2011 18:31, Clinton Gladstone <clinton.gladstone@googlemail.com> wrote:
- See that osmmap_mdr.img is listed twice on the command line: once after the -m switch, and once in the list of all .img files.
Yes, this is somewhat redundant. ;-)
That was indeed the missing piece. Because this was a single tile map I didn't expect to need the wildcard (indeed, there's far too much junk in that directory for it to be safe). Time for some serious playing :) Thanks for solving this, Dermot -- -------------------------------------- Igaühel on siin oma laul ja ma oma ei leiagi üles
I have now compared the gmapi-builder linked from the Wiki with the one we have in the SVN repository. - The Wiki version includes a minor fix, which ensures that file names are upper-cased (usually not a problem). - The SVN version has updates for the index files, which the Wiki version is missing. I'll try to merge the fixes from the Wiki version into the SVN version, and then also finalize the latin-1 correction. After that we can update the Wiki, and I'll leave some more messages for the original author so he knows about this. Cheers. On Feb 13, 2011, at 16:14, Carlos Dávila wrote:
El 12/02/11 23:54, Clinton Gladstone escribió:
On Feb 12, 2011, at 17:52, Carlos Dávila wrote:
Conversion to gmap format in both cases: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-14.TYP 5514*.img osmmap.img
Try the attached file. I quickly hacked it up to support latin-1 encoding for names.
Also, if you are using the --index option in mkgmap, remember to include the index files in gmapi-builder. Example:
$ gmapi-builder.py -t 14000000.tdb -b 14000000.img -s 14.TYP -i 14000000.mdx -m 14000000_mdr.img *.img Thank you for the file, which works fine converting. I have not tested resulting maps though, because I don't have a Mac. In case any user of my maps report any problem I'll tell you. Thank you also for the tips about index. I had not seen any comment about -i and -m parameters on the wiki [1] neither on gmapi--builder_README.txt. According to [1] the version from [2] is supposed to be newer than the one from [3], but the later includes support for index whereas the former doesn't. Should I change it on the wiki?
[1] http://wiki.openstreetmap.org/wiki/Gmapibuilder#Commandline_version [2] http://bitbucket.org/berteun/gmapibuilder/downloads/gmapi-builder.tar.gz [3] http://svn.mkgmap.org.uk/mkgmap/trunk/scripts/gmapi-builder.py _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
El 16/02/11 00:01, Clinton Gladstone escribió:
I have now compared the gmapi-builder linked from the Wiki with the one we have in the SVN repository.
- The Wiki version includes a minor fix, which ensures that file names are upper-cased (usually not a problem).
- The SVN version has updates for the index files, which the Wiki version is missing.
I'll try to merge the fixes from the Wiki version into the SVN version, and then also finalize the latin-1 correction. After that we can update the Wiki, and I'll leave some more messages for the original author so he knows about this.
I still have problems converting one of my maps: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-38.TYP -i osmmap.mdx -m osmmap_mdr.img 553800*.img osmmap.img osmmap_mdr.img TDB Version: 4.07 Product ID: 1 Family ID: 38 Map Series: OSM-Iberia Map Family: OpenStreetMap Iberia Product Version: 1.00 Copyright: OSM Street map Copyright: http://www.openstreetmap.org/ Copyright: Map data licenced under Creative Commons Attribution ShareAlike 2.0 Copyright: http://creativecommons.org/licenses/by-sa/2.0/ Copyright: Map created with mkgmap-rsvn Copyright: Program released under the GPL Trademark: Test preview map Missing part: 0 of . in IMG-file. Only first map (55380001) out of 11 is created. You can get all input files from [1] if you want to have a look at the problem. [1] http://mapas.alternativaslibres.es/MapSource_amp.zip
On Feb 21, 2011, at 19:56, Carlos Dávila wrote:
I still have problems converting one of my maps: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-38.TYP -i osmmap.mdx -m osmmap_mdr.img 553800*.img osmmap.img osmmap_mdr.img
The second file, 55380002.img, appears to have an error. (in the internal FAT table?) At byte x600, there should be a filename, such as 55380002RGN. Instead it is blank. -> I don't know enough about the internal file structure to say. It could also potentially be the case that the blank entry at x600 should be skipped, and the next entry at x800 should be read. Does anyone else know? This is perhaps caused by the very large file size of 55380002.img; it is about 30 Mb. Cheers.
El 21/02/11 23:26, Clinton Gladstone escribió:
On Feb 21, 2011, at 19:56, Carlos Dávila wrote:
I still have problems converting one of my maps: python gmapi-builder.py -t osmmap.tdb -b osmmap.img -s typ/SPAIN-38.TYP -i osmmap.mdx -m osmmap_mdr.img 553800*.img osmmap.img osmmap_mdr.img
The second file, 55380002.img, appears to have an error. (in the internal FAT table?)
At byte x600, there should be a filename, such as 55380002RGN. Instead it is blank.
-> I don't know enough about the internal file structure to say. It could also potentially be the case that the blank entry at x600 should be skipped, and the next entry at x800 should be read. Does anyone else know?
This is perhaps caused by the very large file size of 55380002.img; it is about 30 Mb.
You caught it, splitting the tile it worked!
I perhaps don't allow non ASCII characters in the description, since I don't know if they are accepted or in what circumstances. Just need to try it and see what happens.
On 11/02/2011 20:59, WanMil wrote:
I tried to compile a complete europe map. It failed with the following exception (sounds easy to fix...?-):
Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.imgfmt.app.mdr.Mdr23.sortRegions(Mdr23.java:54)
Easy to stop the exception perhaps ;) but how is it getting to be null? All regions should have one of those set in the previous method.
Anyway I just compilled a complete UK extract and tried to upload all the tiles and it failed with the usual error after a while. So a complete Europe build might be a bit ambitious at this time.
..Steve
I think that happens in case the first region has an empty name "". Then the region is set to null in Mdr28.buildFromRegions(..). I try to change the lastName variable to another value. Maybe that works. WanMil
El 11/02/11 22:47, WanMil escribió:
On 11/02/2011 20:59, WanMil wrote:
I tried to compile a complete europe map. It failed with the following exception (sounds easy to fix...?-):
Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.imgfmt.app.mdr.Mdr23.sortRegions(Mdr23.java:54)
Easy to stop the exception perhaps ;) but how is it getting to be null? All regions should have one of those set in the previous method.
Anyway I just compilled a complete UK extract and tried to upload all the tiles and it failed with the usual error after a while. So a complete Europe build might be a bit ambitious at this time.
..Steve
I think that happens in case the first region has an empty name "". Then the region is set to null in Mdr28.buildFromRegions(..). I try to change the lastName variable to another value. Maybe that works. You are right. I've just found the node causing my map throw the exception: <node id='338743274' lat='42.0871129' lon='-8.4150653'> *<tag k='is_in' v=', Galicia, Spain'/>* <tag k='name' v='As Neves'/> <tag k='name:es' v='Nieves'/> <tag k='place' v='village'/> </node>
On 11/02/2011 20:59, WanMil wrote:
I tried to compile a complete europe map. It failed with the following exception (sounds easy to fix...?-):
Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.imgfmt.app.mdr.Mdr23.sortRegions(Mdr23.java:54)
Easy to stop the exception perhaps ;) but how is it getting to be null? All regions should have one of those set in the previous method.
Anyway I just compilled a complete UK extract and tried to upload all the tiles and it failed with the usual error after a while. So a complete Europe build might be a bit ambitious at this time.
..Steve
I think that happens in case the first region has an empty name "". Then the region is set to null in Mdr28.buildFromRegions(..). I try to change the lastName variable to another value. Maybe that works.
WanMil
Initializing lastName with null should do (?). The patch initializes lastName with null in all Mdr classes. This seems to be a c&p problem that might happen with all names in lot's of Mdr classes. Don't know if an empty name should be contained in map?! WanMil
Hi
Initializing lastName with null should do (?). The patch initializes lastName with null in all Mdr classes. This seems to be a c&p problem that might happen with all names in lot's of Mdr classes.
Don't know if an empty name should be contained in map?!
A region without a name is pretty useless as its name is its only useful attribute in the map. I'll apply the patch as it is reasonable. I think we should throw out regions with empty names at some point though. ..Steve
Sounds terrific! Congratulations :D Op 11-02-11 20:11, Steve Ratcliffe schreef:
Hi
Some progress on the index branch.
I found that the flags at the end of mdr7 trigger the acceptance of the 20-29 sections.
I can now download the maps to my Legend.
Now when you try address search, it is in a completely different mode. There is a country field (although labelled region) and as you make selections in the country/city fields it reduces the options available in the streets field
Addresses can be found in other tiles and not just the closest one.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
El 11/02/11 20:11, Steve Ratcliffe escribió:
Hi
Some progress on the index branch.
I found that the flags at the end of mdr7 trigger the acceptance of the 20-29 sections.
I can now download the maps to my Legend.
Now when you try address search, it is in a completely different mode. There is a country field (although labelled region) and as you make selections in the country/city fields it reduces the options available in the streets field
Addresses can be found in other tiles and not just the closest one.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Congratulations for your great work!! I sent an 8 tiles map to my nuvi and I can use Address search for the first time.
On Feb 11, 2011, at 20:11, Steve Ratcliffe wrote:
Some progress on the index branch.
I can also report that for the first time ever, address search works in Basecamp for Mac OS X. I'm delighted. You should treat yourself to a glass of Champagne for this, if you are so inclined. :-) I compiled a 36 tile map of Australia/Oceania to test. I have not yet tried to upload the map to my device though. Cheers.
Wow really great. So finally a lot of work for you has paid off. That's like the biggest mkgmap drawback that got solved. Even the intersection search is working now (in Mapsource). well not to stop here, or more fair, some ideas for the future on what would be nice to see improved. would it be possible to have a switch so that mkgmap can create the address index with less memory requirements? That would be great for tools that work on clientside to produce mapsets from different maps (e.g. maps & contourline merging -- which AFAIK is impossible without rewriting the address index .... or else someone may tell me how to do it without loosing the address index which would be even greater....) Oh yeah and some rules to get addresses working also when adding funny stuff to the name field in the style-file (like e.g. adding route names or changing to name_cycleway so that not that bad name is chosen for the index (or both which would be fine too). Probably a lot of other stuff on how to interprete OSM address data.
Hi, I get following error when testing with northrhinewestfalia.osm.bz2 (9 tiles). Already tried the suggested --block-size=8192, same error. Error seems to occur at the combine after the tiles have been created. SCHWERWIEGEND (BlockManager): overflowed directory with max block 65534, current=65535 Exception in thread "main" uk.me.parabola.imgfmt.MapFailedException: Too many blocks. Use a larger block size with an option such as --block-size=4096 or --block-size=8192 at uk.me.parabola.imgfmt.sys.BlockManager.allocate(BlockManager.java:58) at uk.me.parabola.imgfmt.sys.FileNode.write(FileNode.java:241) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:377) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:361) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:348) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyAllFiles(GmapsuppBuilder.java:301) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.addImg(GmapsuppBuilder.java:276) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.addAllFiles(GmapsuppBuilder.java:162) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:110) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:419) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:129) Christian
Am 12.02.2011 12:27, schrieb Chris66:
SCHWERWIEGEND (BlockManager): overflowed directory with max block 65534, current=65535
Ok, I could get rid of this error by using smaller tiles. Now in Basecamp the Mapinstall crashes when the progress bar of the index generating process is at 16%. mkgmap-index V1845 Christian
Hello
Now in Basecamp the Mapinstall crashes when the progress bar of the index generating process is at 16%.
I had this problem while upload a complete UK. I've since found that if I just upload a few tiles it doesn't happen. Hopefully I can track down exactly which tile(s) causes it which might lead to a solution. It would be worth trying the r1848 as there is an extra fix in there. ..Steve
Am 12.02.2011 13:24, schrieb Steve Ratcliffe:
Now in Basecamp the Mapinstall crashes when the progress bar of the index generating process is at 16%.
I had this problem while upload a complete UK. I've since found that if I just upload a few tiles it doesn't happen.
OK, when only sending *one* tile it works. Now when I find for addresses on my Legend HCX, I can choose between region "Deutschland" and region "Germany". Region Deutschland seems to show the basemap entries: Ahsen, DEU Alstätte, DEU Altenrheine, DEU ... while region "Germany" shows the OSM entries: Ahaus, Kreis Borken Albachten, Münster ... I used location-autofill=1 and --country-name=germany --country-abbr=DE --area-name=DE For region Deutschland I have to enter "LÜ" to find cities starting with "Lü" but for Region Germany I have to enter "LU" to find cities starting with "Lü". Greetings Christian
Am 12.02.2011 14:56, schrieb Chris66:
Am 12.02.2011 13:24, schrieb Steve Ratcliffe:
Now in Basecamp the Mapinstall crashes when the progress bar of the index generating process is at 16%. I had this problem while upload a complete UK. I've since found that if I just upload a few tiles it doesn't happen. OK, when only sending *one* tile it works.
Now when I find for addresses on my Legend HCX, I can choose between region "Deutschland" and region "Germany".
Region Deutschland seems to show the basemap entries: Ahsen, DEU Alstätte, DEU Altenrheine, DEU ...
while region "Germany" shows the OSM entries: Ahaus, Kreis Borken Albachten, Münster ...
I used location-autofill=1 and --country-name=germany --country-abbr=DE --area-name=DE
For region Deutschland I have to enter "LÜ" to find cities starting with "Lü" but for Region Germany I have to enter "LU" to find cities starting with "Lü".
Greetings Christian
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-de Hi, did you use --code-page//=1252? This should fix the problem with umlauts. Germany instead of Deutschland seems to to a "bug" in OSM is_in-tag, which contains the english name ;)
Henning
Am 12.02.2011 15:08, schrieb Henning Scholland:
Now when I find for addresses on my Legend HCX, I can choose between region "Deutschland" and region "Germany". [...] I used location-autofill=1 and --country-name=germany --country-abbr=DE --area-name=DE
when I change this to --country-name=Deutschland --country-abbr=DEU --area-name=DEU then only region "Deutschland" is available and this is choosen automatically in the address-find page.
For region Deutschland I have to enter "LÜ" to find cities starting with "Lü" but for Region Germany I have to enter "LU" to find cities starting with "Lü".
did you use --code-page//=1252? This should fix the problem with umlauts.
I used -latin1 but when I change to codepage/charset 1252 there is no difference. So, searching cities with "LÜ" now gives: Lünen, Kreis Unna Lünen-Süd, DEU and looking for "LU" gives: Lüdinghausen, Kreis Coesfeld Lünen, Kreis Unna Lünen-Süd, DEU Very funny. Another question: Searching for housenumbers is not yet possible? Chris
My report using mkgmap-index-r1850.jar. Args file: code-page=1252 tdbfile latin1 country-abbr=PHL country-name=PHILIPPINES remove-short-arcs=5 route add-pois-to-areas family-id=639 family-name=OSM_PHIL overview-mapname=40000001 series-name=OSM_PHIL description=OSM_PHIL generate-sea=polygons,extend-sea-sectors,close-gaps=1000 index make-poi-index adjust-turn-headings drive-on-right report-dead-ends ignore-maxspeeds link-pois-to-ways - Loading the map to basecamp and roadtrip - no crash - loading the map to nuvi 1310 using map install - no crash - using the Where to - Address - working! - I see two countries in the "Select Country" (Disputed Territory and Ph) - what do we mean by disputed territory? I can search for streets under the "Disputed Category" but not in "Ph" I'm using the default style for now. Will report back using my own style. Great work! On Sun, Feb 13, 2011 at 4:45 AM, Chris66 <chris66nrw@gmx.de> wrote:
Am 12.02.2011 15:08, schrieb Henning Scholland:
Now when I find for addresses on my Legend HCX, I can choose between region "Deutschland" and region "Germany". [...] I used location-autofill=1 and --country-name=germany --country-abbr=DE --area-name=DE
when I change this to --country-name=Deutschland --country-abbr=DEU --area-name=DEU then only region "Deutschland" is available and this is choosen automatically in the address-find page.
For region Deutschland I have to enter "LÜ" to find cities starting with "Lü" but for Region Germany I have to enter "LU" to find cities starting with "Lü".
did you use --code-page//=1252? This should fix the problem with umlauts.
I used -latin1 but when I change to codepage/charset 1252 there is no difference.
So, searching cities with "LÜ" now gives:
Lünen, Kreis Unna Lünen-Süd, DEU
and looking for "LU" gives:
Lüdinghausen, Kreis Coesfeld Lünen, Kreis Unna Lünen-Süd, DEU
Very funny.
Another question:
Searching for housenumbers is not yet possible?
Chris
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
- Loading the map to basecamp and roadtrip - no crash - loading the map to nuvi 1310 using map install - no crash - using the Where to - Address - working!
Good news!
- I see two countries in the "Select Country" (Disputed Territory and Ph) - what do we mean by disputed territory?
That must be in the data, the string 'disputed' does not appear in mkgmap anywhere.
I can search for streets under the "Disputed Category" but not in "Ph"
That seems strange, there are some islands that are disputed, but you would expect that most streets would be in "Ph". The country may need an entry in LocatorConfig.xml. ..Steve
You're right I found 21 instances containing this tag: http://www.openstreetmap.org/browse/node/302106226 It seems everything was tagged as with the country=disputed territory :) Is there a way to override the is_in:country since I'm only compiling with my own country. On Mon, Feb 14, 2011 at 5:45 PM, Steve Ratcliffe <steve@parabola.me.uk> wrote:
- Loading the map to basecamp and roadtrip - no crash - loading the map to nuvi 1310 using map install - no crash - using the Where to - Address - working!
Good news!
- I see two countries in the "Select Country" (Disputed Territory and Ph) - what do we mean by disputed territory?
That must be in the data, the string 'disputed' does not appear in mkgmap anywhere.
I can search for streets under the "Disputed Category" but not in "Ph"
That seems strange, there are some islands that are disputed, but you would expect that most streets would be in "Ph". The country may need an entry in LocatorConfig.xml.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- cheers, maning ------------------------------------------------------ "Freedom is still the most radical idea of all" -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ ------------------------------------------------------
Am 12.02.2011 21:45, schrieb Chris66:
So, searching cities with "LÜ" now gives:
Lünen, Kreis Unna Lünen-Süd, DEU
and looking for "LU" gives:
Lüdinghausen, Kreis Coesfeld Lünen, Kreis Unna Lünen-Süd, DEU
New result with v1850: No more crash in BaseCamp, so made gmapsupp.img for whole NorthRineWestfalia. Now, looking for "Lü" or "LU" in address find gives no result, so I have to scroll down in the city list to select one of these cities. Looking for "PO" gives only 1 city (Pochwerk), while in the scroll list there are 18 cities starting with PO. Pochwerk Pödinghausen (does he stop searching here because of the umlaut??) Poelyck Poeth Pohlhausen Poll .... Chris
Am 14.02.2011 14:19, schrieb Chris66: [address find on Legend-HCX]
Looking for "PO" gives only 1 city (Pochwerk), while in the scroll list there are 18 cities starting with PO.
Pochwerk Pödinghausen (does he stop searching here because of the umlaut??) Poelyck Poeth Pohlhausen Poll ....
Is this problem also occuring on new generation Garmin devices (Nuvi, Oregon, etc.) ? Chris
Am 14.02.2011 15:47, schrieb Chris66:
[address find on Legend-HCX has problems with umlauts]
so I tried to compile without any --latin1 or codepage options, but then I get an error: Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Warning: using default sort Exception in thread "main" java.lang.NullPointerException at java.lang.String.getBytes(Unknown Source) at uk.me.parabola.imgfmt.app.mdr.Mdr8.writeSectData(Mdr8.java:44) at uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSection(MDRFile.java:327) at uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:284) at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:228) at uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:333) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:419) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:129) Chris
With a Dakota or Nuvi, Search for a address, city Du -> Düffelward, DEU found Enter Street: F->Fährmannsweg->No matches found E->Ehlenstrasse->map is shown So it looks like when there's an umlaut involved it is shown in the index, however it can't locate the street on the map. Minko Chris wrote: Is this problem also occuring on new generation Garmin devices (Nuvi, Oregon, etc.) ?
On 14.02.2011 17:47, Minko wrote:
With a Dakota or Nuvi, Search for a address, city Du ->
Düffelward, DEU found
Enter Street: F->Fährmannsweg->No matches found E->Ehlenstrasse->map is shown
So it looks like when there's an umlaut involved it is shown in the index, however it can't locate the street on the map.
Minko
Chris wrote:
Is this problem also occuring on new generation Garmin devices (Nuvi, Oregon, etc.) ? _______________________________________________ It probably has to be solved somehow by having both names assigned to the same street. That's how it is done in garmin maps. You'll find a street both with Umlauts or without.
Looking for "PO" gives only 1 city (Pochwerk), while in the scroll list there are 18 cities starting with PO.
Pochwerk Pödinghausen (does he stop searching here because of the umlaut??) Poelyck Poeth Pohlhausen Poll
OK I have fixed it, there is another sort identifier inside the tiles themselves. You have to rebuild the tiles, not just the index r1853. ..Steve
Can i reindex tiles ? I split germany every days in the same way. I localy update only a few tiles an put the mix of old/new via gmapsup on my 60CSX. (java -jar mkgmap.jar --gmapsupp --family-id=4 --product-id=45 --family-name=basemap 70013*.img basemap.TYP) That words great. Can you say something about that ? secound question : Whats does Basecamp/ Map Installer do with the data when uploading via USB. Why cant this be done via gmapsupp ? Or can his be done in future ? Thx for the work.
On 15/02/11 20:40, flabot@googlemail.com wrote:
Can i reindex tiles ?
Yes, you do not need to change the tiles to create an index (unless the index doesn't work due to a bug in how the tiles where generated).
I split germany every days in the same way. I localy update only a few tiles an put the mix of old/new via gmapsup on my 60CSX. (java -jar mkgmap.jar --gmapsupp --family-id=4 --product-id=45 --family-name=basemap 70013*.img basemap.TYP)
That words great.
Can you say something about that ?
The family-id, product-id and family-name (and all those related options) are not "in" the tiles, so you do not need to recompile the tiles to change any of those options. If you only change a few tiles, then there is always the chance that routing connections between the tiles get broken if one tile changes the position of a road and the neighbouring tile is not also changed, just as you would expect, but apart from that kind of thing a mix of tiles will be just fine.
secound question : Whats does Basecamp/ Map Installer do with the data when uploading via USB. Why cant this be done via gmapsupp ? Or can his be done in future ?
It does a lot, unfortunately :( Almost everything about the MDR file that gets loaded into the gmapsupp.img is different. Many of those changes are simple, leaving fields and whole section out. Some sections contain extra unknown fields. And there there are whole new sections. In a way it will be easier than the initial development, because you can always tell if your file is correct by comparing it with what MapSource would produce. But there are 40 sections to go through so it quite a task. I'm sure it is entirely possible though. ..Steve
Am 15.02.2011 20:33, schrieb Steve Ratcliffe:
Looking for "PO" gives only 1 city (Pochwerk), while in the scroll list there are 18 cities starting with PO.
Pochwerk Pödinghausen (does he stop searching here because of the umlaut??) Poelyck Poeth Pohlhausen Poll
OK I have fixed it, there is another sort identifier inside the tiles themselves.
You have to rebuild the tiles, not just the index r1853.
This version again is crashing at 16% when building germany. Fehlerinformationen: App: MapInstall At: 15.02.2011 21:31:50 (UTC) OS: Windows 7 (64-bit) Processor: x86, Processor Level: 6, Processors:2, Model: 23 Stepping: 6, RAM: 4145068 MDR_TRIM_ADDR.CXX-440-3.14.4.0 Chris
On 15/02/11 21:39, Chris66 wrote:
Am 15.02.2011 20:33, schrieb Steve Ratcliffe:
Looking for "PO" gives only 1 city (Pochwerk), while in the scroll list there are 18 cities starting with PO.
Pochwerk Pödinghausen (does he stop searching here because of the umlaut??) Poelyck Poeth Pohlhausen Poll
OK I have fixed it, there is another sort identifier inside the tiles themselves.
You have to rebuild the tiles, not just the index r1853.
This version again is crashing at 16% when building germany.
Yes, I've not done anything to fix that further crash yet. If you just try with one file you can see if the umlaut problem is fixed for you. ..Steve
Am 15.02.2011 22:40, schrieb Steve Ratcliffe:
You have to rebuild the tiles, not just the index r1853.
This version again is crashing at 16% when building germany.
Yes, I've not done anything to fix that further crash yet.
just was wondering because v1850 was not crashing anymore.
If you just try with one file you can see if the umlaut problem is fixed for you.
Yes, this seems to work, thanks. Chris
Am 16.02.2011 00:19, schrieb Steve Ratcliffe:
just was wondering because v1850 was not crashing anymore.
Oh OK. Well I believe that now it should work again in 1855.
Yesss, Germany is working now. I see following regions: Be Belgique Berlin Bundesrepubblik Deutschalnd Cz Czech Republic Deutschland France Österreich Pl Poland Schweiz Could you add a mapping for Cz, Be and Pl to the LocatorConfig.xml ? How can I find the node with the typing error (Bundesrepubblik Deutschalnd) ? Chris
Am 16.02.2011 14:01, schrieb Henning Scholland:
How can I find the node with the typing error (Bundesrepubblik Deutschalnd) ?
You can search with taginfo.openstreetmap.de. I found them and will fix them.
Thanks for fixing. No I have to find out how to eliminate region 'Berlin'. ;) Chris
On Wed, Feb 16, 2011 at 01:53:35PM +0100, Chris66 wrote:
How can I find the node with the typing error (Bundesrepubblik Deutschalnd) ?
zgrep -B 20 'Bundesrepubblik Deutscalnd' *.osm.gz If the 20 lines of preceding context do not contain the node id, load the faulty tile in your favourite pager or editor and, search for the text again, and search backwards for id=. Marko
On 12/02/11 11:27, Chris66 wrote: Hello
SCHWERWIEGEND (BlockManager): overflowed directory with max block 65534, current=65535
Exception in thread "main" uk.me.parabola.imgfmt.MapFailedException: Too many blocks. Use a larger block size with an option such as --block-size=4096 or --block-size=8192 at uk.me.parabola.imgfmt.sys.BlockManager.allocate(BlockManager.java:58) at uk.me.parabola.imgfmt.sys.FileNode.write(FileNode.java:241) at uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.copyFile(GmapsuppBuilder.java:377)
This error is being caused while creating the gmapsupp.img. That is the one place where the block size is adjusted automatically and so the option does not have an affect. Obviously there must be a bug when the size is very close to a boundary needing a larger block size. I think that changing anything so that the size is a little larger or smaller will work round the problem. (From your next message I see you changed the size of the tiles which probably changed the size of the gmapsupp a bit). ..Steve
I observed that the MapSource search menu is disabled if the MDR file is larger than 0x7FFFFFF (134217727) bytes. Maybe in this case a flag must be set? WanMil
Hi
Some progress on the index branch.
I found that the flags at the end of mdr7 trigger the acceptance of the 20-29 sections.
I can now download the maps to my Legend.
Now when you try address search, it is in a completely different mode. There is a country field (although labelled region) and as you make selections in the country/city fields it reduces the options available in the streets field
Addresses can be found in other tiles and not just the closest one.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 12/02/11 15:32, WanMil wrote:
I observed that the MapSource search menu is disabled if the MDR file is larger than 0x7FFFFFF (134217727) bytes.
Maybe in this case a flag must be set?
My guess is in ImgHeader: // This sectors, head, cylinders stuff appears to be used by mapsource // and they have to be larger than the actual size of the map. It // doesn't appear to have any effect on a garmin device or other software. int sectors = 0x20; // 0x20 appears to be a max header.putShort(OFF_SECTORS, (short) sectors); int heads = 0x20; // 0x20 appears to be max header.putShort(OFF_HEADS, (short) heads); int cylinders = 0x100; // gives 128M will try more later Try boosting cylinders to 0x200, or try to find if there is a maximum useful value like it appears that there is for the others. ..Steve
On 12/02/11 15:32, WanMil wrote:
I observed that the MapSource search menu is disabled if the MDR file is larger than 0x7FFFFFF (134217727) bytes.
Maybe in this case a flag must be set?
My guess is in ImgHeader:
// This sectors, head, cylinders stuff appears to be used by mapsource // and they have to be larger than the actual size of the map. It // doesn't appear to have any effect on a garmin device or other software. int sectors = 0x20; // 0x20 appears to be a max header.putShort(OFF_SECTORS, (short) sectors); int heads = 0x20; // 0x20 appears to be max header.putShort(OFF_HEADS, (short) heads); int cylinders = 0x100; // gives 128M will try more later
Try boosting cylinders to 0x200, or try to find if there is a maximum useful value like it appears that there is for the others.
..Steve
My first simple tries were not successful. MapSource reject the maps with changed cylinder values. So I have started to implement the display for the IMG file header to be able to analyze it. There are many solutions possible: * Wrong E2 value? My large MDR-IMG files use E2=3. This seems to be too low. * There are still quite a number of unknown bytes. Some of them are set in my official Garmin maps. WanMil
On 12/02/11 15:32, WanMil wrote:
I observed that the MapSource search menu is disabled if the MDR file is larger than 0x7FFFFFF (134217727) bytes.
Maybe in this case a flag must be set?
My guess is in ImgHeader:
// This sectors, head, cylinders stuff appears to be used by mapsource // and they have to be larger than the actual size of the map. It // doesn't appear to have any effect on a garmin device or other software. int sectors = 0x20; // 0x20 appears to be a max header.putShort(OFF_SECTORS, (short) sectors); int heads = 0x20; // 0x20 appears to be max header.putShort(OFF_HEADS, (short) heads); int cylinders = 0x100; // gives 128M will try more later
Try boosting cylinders to 0x200, or try to find if there is a maximum useful value like it appears that there is for the others.
..Steve
My first simple tries were not successful. MapSource reject the maps with changed cylinder values. So I have started to implement the display for the IMG file header to be able to analyze it. There are many solutions possible: * Wrong E2 value? My large MDR-IMG files use E2=3. This seems to be too low. * There are still quite a number of unknown bytes. Some of them are set in my official Garmin maps.
WanMil
Hopefully the patch helps to find the correct settings for larger IMG files. WanMil
participants (13)
-
Carlos Dávila -
Chris66 -
Clinton Gladstone -
Dermot McNally -
Felix Hartmann -
flabot＠googlemail.com -
Henning Scholland -
Lambertus -
maning sambale -
Marko Mäkelä -
Minko -
Steve Ratcliffe -
WanMil