Commit: r1268: Make all fields that are known to be variable size
Version 1268 was commited by steve on 2009-10-08 12:41:46 +0100 (Thu, 08 Oct 2009) BRANCH: mdr Make all fields that are known to be variable size configurable in the code to the size that they are meant to be. Record size fields are now set correctly taking into account the number of maps and everything else we know about. There is still a lot unknown in this area and very small maps just do not work.
svn commit wrote:
Version 1268 was commited by steve on 2009-10-08 12:41:46 +0100 (Thu, 08 Oct 2009) BRANCH: mdr
Make all fields that are known to be variable size configurable in the code to the size that they are meant to be.
Record size fields are now set correctly taking into account the number of maps and everything else we know about.
There is still a lot unknown in this area and very small maps just do not work.
I have just retested this version with my map of Austria. Problems: State/County is still mostly wrong - even though POIs in the area usually are attributed correctly (as seen under "Properties"! Same goes for Cities Address Search: Residential streets are not included, Tertiary, Secondary and Primary are however. Also some other types are missing. How is it determined which type to be included? I have not retested, but with 1261 all big countries produced out of memory mdr errors (Netherlands, Germany, France, Alps, UK --- all from geofabrik, all others European countries worked allright)
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 08/10/09 16:45, Felix Hartmann wrote:
Problems: State/County is still mostly wrong - even though POIs in the area usually are attributed correctly (as seen under "Properties"! Same goes for Cities
OK I will take a look at that. I agree it doesn't always look right, but I was never sure if it was just bad data.
Address Search: Residential streets are not included, Tertiary, Secondary and Primary are however. Also some other types are missing. How is it determined which type to be included?
I just include lines with types less than 8. Residential roads should show up with the default style and they do for me. ..Steve
Steve Ratcliffe wrote:
On 08/10/09 16:45, Felix Hartmann wrote:
Problems: State/County is still mostly wrong - even though POIs in the area usually are attributed correctly (as seen under "Properties"! Same goes for Cities
OK I will take a look at that. I agree it doesn't always look right, but I was never sure if it was just bad data.
Address Search: Residential streets are not included, Tertiary, Secondary and Primary are however. Also some other types are missing. How is it determined which type to be included?
I just include lines with types less than 8. Residential roads should show up with the default style and they do for me.
..Steve
Where can this be changed - I have residential on 0x08? I would like to have all ROUTABLE lines included. (0x01-0x13; 0x16; 0x1a; 0x1b)
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
svn commit wrote:
Version 1268 was commited by steve on 2009-10-08 12:41:46 +0100 (Thu, 08 Oct 2009) BRANCH: mdr
Make all fields that are known to be variable size configurable in the code to the size that they are meant to be.
Record size fields are now set correctly taking into account the number of maps and everything else we know about.
That's adapting for the number of entries in MDR1 is it? Forensics on other sources of MDR files seems to indicate that the indexes into the MDR1 list (which occur in many other MDR sections) may use one or two bytes, depending (presumably) on the length of MDR1.
There is still a lot unknown in this area and very small maps just do not work.
Do you know if the definition of "very small map" is that the number of cities is less than some given constant, or what? The number of entries in MDR1 was mentioned above, but I could imagine troubles if the number of entries in MDR10 or MDR11 crossed certain boundaries too. I could maybe understand issues arising if the number of entries in (somewhere) exceeded 7-bits, 14-bits or 21-bits capacity. Numbers stored with variable numbers of bytes, exhibiting behaviour-transitions at those values have been seen in MDR17 for instance, but could well be employed elsewhere too. Steve
Hi On 08/10/09 17:20, Steve Hosgood wrote:
That's adapting for the number of entries in MDR1 is it? Forensics on other sources of MDR files seems to indicate that the indexes into the MDR1 list (which occur in many other MDR sections) may use one or two bytes, depending (presumably) on the length of MDR1.
It is pretty much every place that a quantity is stored. So yes you are right that the map number (index into MDR1) is two bytes if there are more than 255 maps. But there are also minimum sizes that apply. So the index in mdr11 that points back to mdr5 is always at least two bytes, and will expand if needed, whereas the pointer in mdr10 is fully variable sized. I am able to just try setting different minimum values to see what works and so I currently believe that the index to MDR15 in many of the sections has a min size of three.
There is still a lot unknown in this area and very small maps just do not work.
Do you know if the definition of "very small map" is that the number of cities is less than some given constant, or what?
Maybe, I don't have enough information to know. Also things get progressively worse the smaller the map so its not like you get more than 127 cities and then it suddenly all works or anything. A map no more than a mile radius fails even when searching for a city, whereas on larger files that may be ok and a crash only occurs when attempting to search for a state/county in the address tab. ..Steve
If I use the --index option with 1268 on any "big" country file from Geofabrik, the mdr file is not created: "D:\Garmin\mkgmap_680>start /low /b /wait java -enableassertions -jar -Xmx2800M mkgmap.jar --max-jobs=3 --latin1 --index --ignore-maxspeeds --ignore-turn-restrictions --remove-short-arcs=1 --road-name-pois=0x2f2d --locatio n-autofill=1 --description=openmtbmap_alp_09.10.2009 --route --country-abbr=alp --style-file=new2 --country-name=alps --mapname=65280000 --family-id=6528 --product-id=1 --series-name=openmtbmap_alp_09.10.2009 --family-nam e=mtbmap_alp_09.10.2009 --tdbfile --overview-mapname=mapset00 65280*.osm.gz *There is not enough room in a single garmin map for all the input data The .osm file should be split into smaller pieces first." *Splitting offers of course no help. The above is against alps.osm.bz2 from Geofabrik. (same problem with UK,NL,DE)
participants (4)
-
Felix Hartmann -
Steve Hosgood -
Steve Ratcliffe -
svn commit