Hi

Mapsource crashes when I click on the search button. I removed code-page: 1252 from the parameters but it didnt help. Mapsource also crashes when I try to send the selected map to the GPS

Mkgmap args see http://mijndev.openstreetmap.nl/~ligfietser/openfietsmap/Scripts/osm_bnl.arg...

I would remove road-name-pois from those arguments. Felix has reported crashes from using it along with index, and really the option only exists as a work-around for the lack of a working index. Regards, ..Steve

On 11/01/11 12:21, Minko wrote:

Hi Steve, I removed road-name pois, but it didnt help. Mapsource still crashes.

OK, the option shouldn't cause a crash, but since it was reported as being a possible problem it was worth trying.

Does it solve the problem state/province on the newer GPS units (as well as on the nüvi)? Thats the reason why I use road-name-pois, to search for addresses via pois.

No I don't expect it will make any difference there. ..Steve

I found the reason what made my mapsource crashing (bad map id) when I clicked on the address search button. . The cause I have found in my mkgmap args file: mapname: 30010040 description: testmap input-file: 10010040.osm.gz It causes mkgmap to crash if I search for adresses. I thought it was caused because I used mkgmap-index-r1778.jar but it happened with other mkgmap versions too... Another test didnt cause a crash: mapname: 10010040 description: testmap input-file: 10010040.osm.gz So in my args file I noticed that it matters that at least the first input file and the mapname file must have the same map ID? I also found out that if I put a (already processed) contour img first before the osm tiles, the same crash happens (bad map id) if I click on the address search button: # contour lines first description: contourmap input-file: 10010101.img # osm tiles last mapname: 10010040 description: testmap input-file: 10010040.osm.gz However, this causes a crash in MS (address search button), but it doesnt crash if i put the osm tiles first: # osm tiles first mapname: 10010040 description: testmap input-file: 10010040.osm.gz # contour lines last description: contourmap input-file: 10010101.img Note that I don't put the line "mapname: 10010101.img" in the line above with "description: contourmap" because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the contourlines. I don't know if my findings are related to the address search problem, but maybe it helps. Cheers, Minko ----- Oorspronkelijk bericht ----- Van: "Minko" Aan: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Verzonden: Dinsdag 11 januari 2011 13:21:48 Onderwerp: Re: [mkgmap-dev] Improved street search in index branch Hi Steve, I removed road-name pois, but it didnt help. Mapsource still crashes. Does it solve the problem state/province on the newer GPS units (as well as on the nüvi)? Thats the reason why I use road-name-pois, to search for addresses via pois.

Just a thought while reading this: Has the MDR1 to be sorted in some way? Maybe the mapnames has to be sorted in ascending order? I think mostly they are sorted by pure random in ascending order because splitter creates an argument file this way. This would explain the crash with other filenames. Regards, Johann Minko schrieb:

I found the reason what made my mapsource crashing (bad map id) when I clicked on the address search button. . The cause I have found in my mkgmap args file:

mapname: 30010040 description: testmap input-file: 10010040.osm.gz

It causes mkgmap to crash if I search for adresses. I thought it was caused because I used mkgmap-index-r1778.jar but it happened with other mkgmap versions too...

Another test didnt cause a crash:

mapname: 10010040 description: testmap input-file: 10010040.osm.gz

So in my args file I noticed that it matters that at least the first input file and the mapname file must have the same map ID?

I also found out that if I put a (already processed) contour img first before the osm tiles, the same crash happens (bad map id) if I click on the address search button:

# contour lines first

description: contourmap input-file: 10010101.img

# osm tiles last

mapname: 10010040 description: testmap input-file: 10010040.osm.gz

However, this causes a crash in MS (address search button), but it doesnt crash if i put the osm tiles first:

# osm tiles first

mapname: 10010040 description: testmap input-file: 10010040.osm.gz

# contour lines last

description: contourmap input-file: 10010101.img

Note that I don't put the line "mapname: 10010101.img" in the line above with "description: contourmap" because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the contourlines.

I don't know if my findings are related to the address search problem, but maybe it helps.

Cheers, Minko

----- Oorspronkelijk bericht ----- Van: "Minko" Aan: "Development list for mkgmap" <mkgmap-dev@lists.mkgmap.org.uk> Verzonden: Dinsdag 11 januari 2011 13:21:48 Onderwerp: Re: [mkgmap-dev] Improved street search in index branch

Hi Steve, I removed road-name pois, but it didnt help. Mapsource still crashes.

Does it solve the problem state/province on the newer GPS units (as well as on the nüvi)? Thats the reason why I use road-name-pois, to search for addresses via pois. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Yep, it works now, no more crashes! Steve wrote: @Minko: can you confirm this is your problem? ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Am 21.01.2011 19:05, schrieb Carlos Dávila:

These are my results with index_branch r1792

1 tile map 2 tiles map 9 tiles map *POI search* Yes Yes Yes *Cities* Accented characters Yes Yes Yes Existing city Yes (3) Yes (3) Yes (3) Existing region Yes (1) Yes (1) Yes (1) Existing country Yes Yes Yes Combinations of city, region, country Yes (1) Yes (1) Yes *Streets* Existing street+city Yes Yes (2) Yes (2) Non existing street+city Yes Yes (2) Yes (2) Only street Yes Yes (2) Yes (2) *Send to device *

Yes

(1) Only places tagged in the form is_in=province,region,country. Those with complete is_in:province, is_in:region, is_in:country tagging are not found. (2) Missing all streets beginning by "Calle" before "Calle Real ..." (3) In the search results listed region information is missing.

All crashing and exception messages have disappeared.

Great statistic! Which MapSource version do you use? Do you have other maps installed in MapSource? WanMil

Carlos Dávila schrieb:

These are my results with index_branch r1792

1 tile map 2 tiles map 9 tiles map *POI search* Yes Yes Yes *Cities* Accented characters Yes Yes Yes Existing city Yes (3) Yes (3) Yes (3) Existing region Yes (1) Yes (1) Yes (1) Existing country Yes Yes Yes Combinations of city, region, country Yes (1) Yes (1) Yes *Streets* Existing street+city Yes Yes (2) Yes (2) Non existing street+city Yes Yes (2) Yes (2) Only street Yes Yes (2) Yes (2) *Send to device *

Yes

Indeed very impressing statistics :-D

(1) Only places tagged in the form is_in=province,region,country. Those with complete is_in:province, is_in:region, is_in:country tagging are not found. I think this should be solvable. The parsing code is not a unknown piece. (2) Missing all streets beginning by "Calle" before "Calle Real ..." From my stomach I get the idea, that this could be caused by the blank character. Could you give it a try with osm data, in which all occurences of "Calle " are search and replaced by "Calle" without blanks? Maybe it is a problem with the sorting, so binary search does not work correctly. Maybe the blanks should be sorted on the opposite end to the characters (after/before the chars).

Another idea is, that there are to much streets beginning with the character combination "Calle ". Maybe there is some overflow in internal structures if there are more than 1024 (256, 4096, 2^16 ...?) labels beginning with the same characters, which would need some extra handling. Is it possible for you to do a quick grep on the osm files, how much occurences of "Calle " are there contained?

(3) In the search results listed region information is missing.

All crashing and exception messages have disappeared.

------------------------------------------------------------------------

_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Thanks for testing. It looks like things are pretty good for small and medium sized maps. Did send to device fail for 1 & 2 tiles or did you just not try? I ask because I haven't tried it since the last round of changes, but I know that prior to the last round of changes there was a problem with a small map.

(1) Only places tagged in the form is_in=province,region,country. Those with complete is_in:province, is_in:region, is_in:country tagging are not found.

I can't find any place where is_in:province or is_in:region is used in mkgmap. So is probably just a case of supporting those tags, and not index related. On the other hand it should be possible to search for a city that does not have a region; it does have to have a region or a country, but there is a default country name ("ABC" if you don't set it in the commands).

(2) Missing all streets beginning by "Calle" before "Calle Real ..."

I suspect (like Johann) that having so many streets beginning with the same letters is confusing. But surely it is confusing to humans too? How are Spanish street directories normally indexed, do you normally ignore the "Calle" and then sort on the rest? It seems like this is possible in the Garmin format, but not something we have done.

(3) In the search results listed region information is missing.

OK, noted. Best wishes ..Steve

...

(2) Missing all streets beginning by "Calle" before "Calle Real ..."

I suspect (like Johann) that having so many streets beginning with the same letters is confusing. But surely it is confusing to humans too? How are Spanish street directories normally indexed, do you normally ignore the "Calle" and then sort on the rest? It seems like this is possible in the Garmin format, but not something we have done.

In the cpreview code it is handled by the 'multibody' feature. As far as I understand it, there are simply created some more entries in the mdr7 which point not to the beginning of the string but into the string. The offset of this pointer to the string start is saved in another byte. These entries are sorted among the others. If multibody is enabled, there is some additional handling by the so called xflag. This variable counts the occurences of equal strings. It stores the counter in one ore two (if > 256) extra bytes. I have not understood it fully. Maybe this feature is needed to store more than 2^15 strings with the same start and is the clue to the missing streets. Johann

On 21.01.2011 15:12, charlie@cferrero.net wrote:

Minko (ligfietser@online.nl) wrote:

[snip]

...

Note that I don't put the line "mapname: 10010101.img" in the line above with "description: contourmap" because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the contourlines.

No way! Is this why I can't get contour lines to display in MapSource (even though I know they're there because I can see the contour elevation labels)??? I'd given up on ever getting contours to work properly in MapSource. Prize for obscurest workaround of the year so far if this works. ;)

Highly off topic: 1. Check: Countourlines have to have exactly the same resolution as normal maps (if normal maps 24,22,20,18 countourline maps have to be 24,22,20 (you can skip the 18) - if normal maps are 24,23,22,21,20 then well, your contourline maps need to be also 24,23,22,21,20 - as soon as you leave out a resolution they won't be displayed anymore) 2. Contourline maps have to have higher mapname. --- both is irrelevant if you use basecamp or on GPS, which always shows contourlines if inside same tdb. Problem is 1, in general contourlines work better if you have 23,21,20 as levels on GPS or for Qlandkarte GT. DEM3 data, is not good enough resolution to justify the 2x space / render requirements of res 23.)

On 21.02.2011 07:09, Charlie Ferrero wrote:

On 21/01/2011 18:17, Felix Hartmann wrote:

...

On 21.01.2011 15:12, charlie@cferrero.net wrote:

...

Minko (ligfietser@online.nl) wrote:

[snip]

...

Note that I don't put the line "mapname: 10010101.img" in the line above with "description: contourmap" because this causes that the contours dont show up in Mapsource. If I leave mapname etc out, it shows the contourlines.

No way! Is this why I can't get contour lines to display in MapSource (even though I know they're there because I can see the contour elevation labels)??? I'd given up on ever getting contours to work properly in MapSource. Prize for obscurest workaround of the year so far if this works. ;)

Highly off topic: 1. Check: Countourlines have to have exactly the same resolution as normal maps (if normal maps 24,22,20,18 countourline maps have to be 24,22,20 (you can skip the 18) - if normal maps are 24,23,22,21,20 then well, your contourline maps need to be also 24,23,22,21,20 - as soon as you leave out a resolution they won't be displayed anymore) 2. Contourline maps have to have higher mapname.

--- both is irrelevant if you use basecamp or on GPS, which always shows contourlines if inside same tdb. Problem is 1, in general contourlines work better if you have 23,21,20 as levels on GPS or for Qlandkarte GT. DEM3 data, is not good enough resolution to justify the 2x space / render requirements of res 23.)

Hmmm - tried this and it still doesn't work. My contour style has exactly the same levels as the base style, and the mapnames are higher. All I can see is the contour labels, but not the contours themselves (see http://cferrero.net/maps/img/mkgmapdev_contourissue.png). If I just display the contour maps and not the basemap, it works as expected (see http://cferrero.net/maps/img/mkgmapdev_contourissue2.png)

I'm using Mapsource 6.16.3, my base map has mapname 63247001 and the contour tiles are 63247201-63247209, compiled with higher draw priority and --transparent Where did I write you are supposed to use --transparent. Drop that it causes only problems. The levels definition in both basemap and contours is levels = 0:24, 1:23, 2:22, 3:20, 4:18, 5:16

-- Charlie _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Hi Charlie, I recently noticed that my method of leaving the mapname: etc out didn't always work as expected :-( What always worked for me, was saving the contourlines files as *.mp instead of img with gpsmapedit. My contourlines are transparent but can have the same draw priority. Process the *.mp tiles together with your osm.gz tiles to make img's.

Yep Charlie, I recently discovered that after struggling two years ;-) My workaround until now was to save the contour img's as mp files. Only that way it was displayed correctly. Now I know we just have to leave the line "mapname: ..." out of the args file. Like Felix adviced, levels must be the the same, and the map numbers were higher with my maps as well. I also found out recently that the --show-profiles=1 option works now within the map (thought it only worked with a separate contour file map, not a combined one). Cheers, Minko ----- Oorspronkelijk bericht ----- Van: charlie No way! Is this why I can't get contour lines to display in MapSource (even though I know they're there because I can see the contour elevation labels)??? I'd given up on ever getting contours to work properly in MapSource. Prize for obscurest workaround of the year so far if this works. ;) -- Charlie

Hi

* Searching for streets works fine for me. * Searching for streets and cities does not work (error message from MapSource)

Hmm it is strange; I have a map of Germany where searching for street+city works very well. However I also have UK map where street+city does not work. So it isn't just down to accented characters. May be the number of cities, streets etc. ..Steve

On 12.01.2011 23:32, Steve Ratcliffe wrote:

...

Hi

...

* Searching for streets works fine for me. * Searching for streets and cities does not work (error message from MapSource) Hmm it is strange; I have a map of Germany where searching for street+city works very well. However I also have UK map where street+city does not work.

So it isn't just down to accented characters. May be the number of cities, streets etc.

..Steve _______________________________________________ Before Tuesdays round of commits, the searching for street& city worked fine (except cities with accented characters of course). Now on Austria it is not working anymore.

In general the index branch has not yet brought forward any progress to me. (normal branch, plus the change on accented characters, and going back on the mdx file to version rev 1760) would be best for the moment (though I think the current situation is two steps forward and one step back and hopefully in general the right way...). So for the main branch go back to rev. 1772, and then change the mdx creation back to how it worked in 1760 and bring in the changes related to accented characters in the city to trunk.

Felix, your proposal sounds like a lot of work that should better be invested in the branch itself. I think it is better to continue with the index branch until the whole branch is ready for merge. WanMil

Steve, I started with systematic testing and want to publish my first intermediate results. My mkgmap parameters: latin1 series-name=MkgmapIndex family-name=MkgmapTest remove-short-arcs make-poi-index net route tdbfile nsis MapSource version 6.16.3 Windows 7 Here are the problems I discovered: 1 tile: Search dialog crashes Mapsource immediately 2 tiles: POI search: - always shows exception but Mapsource does not crash Find cities: - Entering non existent letter in city field crashes Mapsource - Search only for existing region shows exception - Search only for existing country shows exception - Search for existing region and country shows exception - Only searches where the city field is supplied with an existing city are ok Find streets: - Existing and non existing street / city combination shows message (something like "Combination not supported by this product") So far so good. As a summary all searches with a city name not contained in the map have problems. So maybe it's good to start having a look at the city section?! WanMil Am 17.01.2011 11:14, schrieb Steve Ratcliffe:

Hi everyone

Well it appears that the results vary wildly!

Trouble is that everyone has their own set of map tiles a different set of options and so it is very difficult to make sense of the results.

It would be helpful to create an index of different sizes from the same tiles and same options.

- create a set of tiles - start creating the index, tdb, etc files with just one tile (the smallest perhaps). - test a number of searches - save the index and record the results against it. - repeat with two tiles and the same tests

I'd stick with some basic tests, some of:

- Search for a street only - search for street+city - with/without accented characters - attempt to download to device (don't have to complete it, if it is not going to work it usually fails very quickly).

I am expecting that you will get very different results with different sized indexes and hoping that together we will get enough information to work out the problems.

..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

...

1 tile: Search dialog crashes Mapsource immediately

Hmm... Not a good start!

Could you run test.display.MdrSummary on the index and send the output please.

I've just committed a fix that may help when the number of cities is between 127 and 256.

..Steve

I have recompiled the 1-tile map with r1787 but I have still the same problems. MapSource shows an exception and closes. I've attached the output of MdrSummary. My tiles have one speciality: They are quite small. I have splitted with max-nodes=100000. WanMil

Hi

...

My tiles have one speciality: They are quite small. I have splitted with max-nodes=100000.

I suspect that mdr8/12 should not be included if there is only one entry as it is in your case.

Once I get the chance I will try fixing that, but you might want to see if it helps removing the sections first.

I have removed them from the MdrFile class without any improvement. MapSource still crashes when opening the search dialog. WanMil

I have not noticed any improvement from those sections anyway.

..Steve

My tiles have one speciality: They are quite small. I have splitted with max-nodes=100000.

I have fixed it: the mdr15 offset size (PointerSize.getStrOffSize() ) has to be always at least 3 bytes. I made a number of indexes, ran MdrSummary on them and separated them into good and bad files. A quick grep showed that the only interesting thing was the the record sizes (in square brackets) were different and it quickly turned out that this was down the the string offset pointer size. $ grep 'MDR 5' ok MDR 5 NR=70 (00000046) [10]magic=0x1c (28) MDR 5 NR=60 (0000003c) [10]magic=0x1c (28) MDR 5 NR=57 (00000039) [10]magic=0x1c (28) $ grep 'MDR 5' bad MDR 5 NR=10 (0000000a) [ 9]magic=0x1c (28) MDR 5 NR=19 (00000013) [ 9]magic=0x1c (28) MDR 5 NR=46 (0000002e) [ 9]magic=0x1c (28) MDR 5 NR=43 (0000002b) [ 9]magic=0x1c (28) MDR 5 NR=36 (00000024) [ 9]magic=0x1c (28) MDR 5 NR=38 (00000026) [ 9]magic=0x1c (28) MDR 5 NR=38 (00000026) [ 9]magic=0x1c (28) MDR 5 NR=46 (0000002e) [ 9]magic=0x1c (28) MDR 5 NR=45 (0000002d) [ 9]magic=0x1c (28) MDR 5 NR=46 (0000002e) [ 9]magic=0x1c (28) $ grep 'MDR 7' ok MDR 7 NR=4049 (00000fd1) [ 7]magic=0x3 (3) MDR 7 NR=4173 (0000104d) [ 7]magic=0x3 (3) MDR 7 NR=3861 (00000f15) [ 7]magic=0x3 (3) $ grep 'MDR 7' bad MDR 7 NR=1269 (000004f5) [ 6]magic=0x3 (3) MDR 7 NR=1646 (0000066e) [ 6]magic=0x3 (3) MDR 7 NR=2489 (000009b9) [ 6]magic=0x3 (3) MDR 7 NR=3206 (00000c86) [ 6]magic=0x3 (3) MDR 7 NR=2020 (000007e4) [ 6]magic=0x3 (3) MDR 7 NR=3347 (00000d13) [ 6]magic=0x3 (3) MDR 7 NR=2160 (00000870) [ 6]magic=0x3 (3) MDR 7 NR=2569 (00000a09) [ 6]magic=0x3 (3) MDR 7 NR=2395 (0000095b) [ 6]magic=0x3 (3) MDR 7 NR=3262 (00000cbe) [ 6]magic=0x3 (3) ..Steve

El 18/01/11 10:16, Carlos Dávila escribió:

Second difference is that sending the map to SD fails. Is it useful to send you MapSource fail report? Surprisingly I've found that despite the error message, the map has been sent to the card and works on the device, being much bigger than the same gmapsupp generated by mkgmap (149 MB vs 122 MB) P.S. Forgot to comment test was done with r1786. Currently compiling with r1787...

El 18/01/11 19:18, Johann Gail escribió:

...

9 tiles Almost the same results than 1 tile. The first difference found is that there are a lot of missing streets.

Is there a pattern with the missing streets? Maybe only the streets from tile 1 are found, but not from the higher?

Missing streets are not tile related but spelling related, at least for the most important number of missing streets. When using trunk map if I type "Calle" in Select street dialog I get a list starting with "Calle" and ending with "Calle 8 de Marzo". On index map the list starts with "Calle Real Academia Valencia" and ends with "Calle Reina". Between "Calle 8 de Marzo" and "Calle Real Academia Valencia" there must be hundreds or thousands of streets, as calle means street in Spanish and most streets are tagged in the form "Calle ..." All those streets are missing in the index map. If I type "Calle Real Academia Valencia" in trunk I get exactly the same list than in index map just typing "Calle", so in this group no one is missing. Typing other letters I miss only 1-5 streets in a list of 100, but I would need to check one by one to see which ones/where are missing. Is there any tool to see the complete list of streets in a map? There are also some differences in the ordering. Typing "L" on trunk map I get a list starting by "L'string"->"L-number"->"La string". With the index map the list is ordered "L-number"->"L'string"->"La string"

I notice that a number of people are using: the --make-poi-index option which is marked as 'not yet useful' in the help. Has anyone checked if makes any difference and that it is not actually harmful? ..Steve

Hi Steve, you are doing a great job! I tested the latest index branch 1781 with Latin1 & codepage 1252, compiled a map of Soutern Africa in 2 tiles On mapsource I see no difference. Streets are searchable under address search as it was before with index -- that is, as long as you don't fill in the city fields. With the state or country fields completed the street are found very well. Observation: the values available in the state field correspond to the region-abbr value passed to MkGMap, and not to the state values in the map data. On my unit (Nuvi200W) the problem remains the same (as reported before by other people): Address search is not available, as the unit requests the state/province i.s.o. country, and refuse any input, or rather does not find any state. As I think your work currently looks at sorting the street names, I don't really expect a change here yet. The state/province obstacle prevents me from testing address search further on the unit. I will keep on testing every new version. The only other difference I've noticed is that I can not find streets in POI search as I switched road-name-pois off to test address search. Please never get rid of this option, until all units have proper address search. It is a life saver -- a map where you cannot find a street is useless. BennieD -------------------------------------------------------------------------------- Scanned by MailMarshal - Marshal's comprehensive email content security solution. Download a free evaluation of MailMarshal at www.marshal.com --------------------------------------------------------------------------------

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. 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). 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

Has anyone dared to look into the cpreview code?

So we do at the moment.

http://cgpsmapper.svn.sourceforge.net/viewvc/cgpsmapper/cgpsmapper/cpreview/...

There seems the structure of the bits be very well decoded.

More or less. Please feel free to start your own investigations and compare the mkgmap results to the format of the cpreview tool. Any hint or discussion what might be changed in the mkgmap processing is helpful!! WanMil

WanMil schrieb:

...

...

Has anyone dared to look into the cpreview code?

So we do at the moment.

...

http://cgpsmapper.svn.sourceforge.net/viewvc/cgpsmapper/cgpsmapper/cpreview/...

There seems the structure of the bits be very well decoded.

More or less. Please feel free to start your own investigations and compare the mkgmap results to the format of the cpreview tool. Any hint or discussion what might be changed in the mkgmap processing is helpful!!

I have tried to compile the source with linux, but had no success so far. Looks like it needs the intel compiler and some source dependencies, e.g. sqlite3 source. I have not tried hard, so maybe would need more time to become succesfull. Does anyone know which input files the cpreview tool will need? Does it import the prepared *.img files like mkgmap or does it need some other database or text files? If I would be able to generate a working index with it, I could play with it and see, which sections are really needed on the device.

Regards, Johann

Yep, so you are exactly at the same stage like I am. At the moment I am only able to do a code review of cpreview. I think Felix answered how cpreview should work so I continue in his thread. Have fun! WanMil

On 22/01/11 10:57, WanMil wrote:

I compared the MDR5 code to the cpreview code.

There is a unique flag for each city (0x800000). cpreview clears this flag if the previous region and city name are equal. The index branch checks for equality of map index and city name. I tried to change that but all I got was some new exceptions in MapSource.

Steve: Did you also play with this flag?

Not much I just set it recently the way that I thought it should be (I think before the index branch it was always set). I think that the map index is required both for consistency with other similar flags, and since the label offset is used rather than the actual string, there would be a chance of a false match if you didn't also check the offset was in the same map. (On the other hand the chance of the same name having the same offset in two different maps is also very low, so I think that removing the check for same map would, in practice, make very little difference). The trouble is I don't know why the flag exists. Is it there so that if you are doing a binary search and end up at a matching name you know that this is not the first match if the flag is not set? Or something completely different? If you include region then surely there would be very few duplicate cities with the same name in the same region? I'm not discouraged by the extra crashes when changing the flag, it rather indicates that it is more important than I thought. ..Steve