Steve Ratcliffe schrieb:
Hi
I had some looks at the code, especially on MDRSection7, which is important for street search. And, yes, there are some more fields decoded. But most of the comments are in polish, so it's very hard (at least for me) to unterstand what those fields are used for and where to get the required data.
There are other possible fields but they are not necessarily essential as mapsource adds some of these fields when it downloads to a device, so they do not need to be present in the index to begin with.
Correct, I think we should get basic search working first. But my final destination would be a working search on the devices without downloading from mapsource. I would be very happy, if we get so far.
As far as I understand it, one of these fields is a flag to say that there is more than one word in the name of the street (or perhaps a count).
The xflag seems to be a count of some sort. The count could become greater then 256 and then it will be splitted to two bytes. Or are this the accented characters with an ascii code > 256? I don't think so. Also I think this is optional and not needed for basic working.
Another field is used for an alternative kind of index where every word in the street name is indexed separately. So if you had a name:
Yellow Grass Lane
it would be sorted under 'Y' as normal, but also under 'G'. The entry that was under 'G' would have this field set to the position of the character 'G' in the name - so 8 in this case (or 7 if it starts at 0 - whatever).
While this would be useful, we need to get the basic index working first.
It would be good to know exactly what is required to get things working on the device, since the index has very many possible sections and we don't have enough people working on it to implement everything.
My next guess would be mdr 20, 21, 22 as these are referred to in the reverse index which is used by mapsource to determine what is downloaded to the device. They are lists of pointers into the street names ordered in particular ways (city, region etc) and so very relevant to the problem areas.
..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev .