Commit: r1275: Fill in the extra header values separately and
Version 1275 was commited by steve on 2009-10-11 22:24:36 +0100 (Sun, 11 Oct 2009) BRANCH: mdr Fill in the extra header values separately and controlled by the section class itself. These values appear to control what fields appear in the section records and their sizes. I have confirmed by contstructing maps that the bottom two bits of the MDR 5 extra value are the size of the local city field in mdr5 minus one, ie they are zero for a size of one. This worked for all values of the bottom two bits. The next two bits appear to relate the3byte label field, but here only three (for the full size of the field) and zero for its complete absence appear to work. Anyway small maps now work.
svn commit wrote:
Version 1275 was commited by steve on 2009-10-11 22:24:36 +0100 (Sun, 11 Oct 2009) BRANCH: mdr
Fill in the extra header values separately and controlled by the section class itself.
These values appear to control what fields appear in the section records and their sizes.
Excellent guess, Steve You beat me to suggesting pretty much exactly the same idea, except I was just expecting just a bitfield indicating what to expect, but not for the actual field sizes to be encoded there. After all, bitfields telling what's present and what is not seem to appear in .NOD files, so why not here? Now we'll have to work to see if all the other header fields (known as 'flags' in the MDR-format wiki currently) work in similar ways. Steve
Steve Hosgood wrote:
svn commit wrote:
Version 1275 was commited by steve on 2009-10-11 22:24:36 +0100 (Sun, 11 Oct 2009) BRANCH: mdr
Fill in the extra header values separately and controlled by the section class itself.
These values appear to control what fields appear in the section records and their sizes.
Excellent guess, Steve You beat me to suggesting pretty much exactly the same idea, except I was just expecting just a bitfield indicating what to expect, but not for the actual field sizes to be encoded there.
After all, bitfields telling what's present and what is not seem to appear in .NOD files, so why not here?
Now we'll have to work to see if all the other header fields (known as 'flags' in the MDR-format wiki currently) work in similar ways.
Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Just to report. Searching on the GPS still only works for the tile you are situated in at the time being (or better GPS fix position...). Otherwise (except the "ref" problem) no showstopper to put it into trunk I think.
Just discovered a really nasty bug in the search index! I think this has been present in previous versions too - Streetnames starting with "a" or "b" are NOT included in the search index (at least in Mapsource). I can't find home using the address search therefore. :-) Maybe they need special "care" or can there seriously be such a bug undiscovered that mkgmap drops them? Felix
On Mon, Oct 12, 2009 at 01:06:39AM +0200, Felix Hartmann wrote:
Just discovered a really nasty bug in the search index! I think this has been present in previous versions too - Streetnames starting with "a" or "b" are NOT included in the search index (at least in Mapsource). I can't find home using the address search therefore. :-)
Sorry if you are talking about Mapsource and the MDR branch only, but I have successfully searched for Aakkulankatu in my Edge 705 some months ago. Then again, there should not be any ref=A1 or the like in Finland. In Germany, the motorways and trunk roads carry ref=[AB][0-9]+, as far as I remember. Could that (together with wrong sort order between numbers and letters) be causing the problem? Marko
On 10/12/2009 07:39 AM, Marko Mäkelä wrote:
In Germany, the motorways and trunk roads carry ref=[AB][0-9]+, as far as I remember.
To be precise we have in Germany: A[0-9]{1-3} for Autobahn B[0-9]{1-3} for Bundesstrassen (Federal Roads, normally highway=trunk or primary) L[0-9]{1-4} for Landesstrassen (State Roads, mostly highway=secondary) St[0-9]{1-4} for Staatsstrassen (State Roads, mostly highway=secondary) K[0-9]{1-4} for Kreisstrassen (County Roads, mostly highway=tertiary) Then there is the parallel system of the European E-Road network numbering.
participants (5)
-
Felix Hartmann -
Marko Mäkelä -
Ralf Kleineisel -
Steve Hosgood -
svn commit