Hi all, It seems that r3942 produces maps which work quite well with MapSource and Basecamp. I can find roads with names like Æblegården or "Außer Ort". I find POI in the expected category. Anyhow, I see different results on my devices. It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Road names containing characters which appear in the "expand" section cause trouble. For cp-1252 (--latin1) these are expand … to . . . expand ¼ to 1 / 4 expand ½ to 1 / 2 expand ¾ to 3 / 4 expand æ to a e expand Æ to A E expand œ to o e expand Œ to O E expand ß to s s expand ™ to T M I am pretty sure now that this is a bug in the Oregon firmware. It would be interesting to know if firmware 4.60 worked. According to this page http://www8.garmin.com/support/download_details.jsp?id=6157 there was a change described "Improved address search" with 4.80. Unfortunately I was not able to download any previous version. Any hints? The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken. This also happens when I use MapSource to install the map on the device. The installed map "GARMIN CN Europe NTU 2018.1" is a unicode map and works fine. So, if you create maps which contain road names containing special characters, please try how maps created with r3942 work on your device(s). I've uploaded a copy of the version here: http://files.mkgmap.org.uk/download/351/mkgmap-optimize-index-r3942.zip These are the test cases that don't work on my Oregon: Map around Copenhagen: - Search for all roads in Denmark starting with Æ (switch to Danish keyboard to be able to type that character) or Ae doesn't find any road, it should find many. - Search for other special characters like Ø works fine. - Search for all roads in city "Albertslund Kommune" lists ... Abildgården Æblets Kvt Alberts Have Alberts Vænge ... When I search for roads starting with A in Albertslund Kommune it lists only Abildgården Similar results with other searches, the device seems to stop reading the data when the first name with Æ is hit. When I search for AL (so that it doesn't read the Æ name) it lists the above roads. Don't know if I should contact Garmin ? Gerd
Hi Gerd There is an archive of Garmin updates here http://gawisp.com/perry/ <http://gawisp.com/perry/> and for Oregon here http://gawisp.com/perry/oregon/ <http://gawisp.com/perry/oregon/> and this may be the 4.6 update gawisp.com/perry/oregon/Oregon6x0_WebUpdater__460.gcd <http://gawisp.com/perry/oregon/Oregon6x0_WebUpdater__460.gcd> I have not used these before so I am unsure if you can revert to the older state using these? Nev
On 15 May 2017, at 3:52 PM, Gerd Petermann <gpetermann_muenchen@hotmail.com> wrote:
Hi all,
It seems that r3942 produces maps which work quite well with MapSource and Basecamp. I can find roads with names like Æblegården or "Außer Ort". I find POI in the expected category.
Anyhow, I see different results on my devices. It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Road names containing characters which appear in the "expand" section cause trouble. For cp-1252 (--latin1) these are expand … to . . . expand ¼ to 1 / 4 expand ½ to 1 / 2 expand ¾ to 3 / 4 expand æ to a e expand Æ to A E expand œ to o e expand Œ to O E expand ß to s s expand ™ to T M I am pretty sure now that this is a bug in the Oregon firmware. It would be interesting to know if firmware 4.60 worked. According to this page http://www8.garmin.com/support/download_details.jsp?id=6157 there was a change described "Improved address search" with 4.80. Unfortunately I was not able to download any previous version. Any hints?
The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken. This also happens when I use MapSource to install the map on the device. The installed map "GARMIN CN Europe NTU 2018.1" is a unicode map and works fine.
So, if you create maps which contain road names containing special characters, please try how maps created with r3942 work on your device(s). I've uploaded a copy of the version here: http://files.mkgmap.org.uk/download/351/mkgmap-optimize-index-r3942.zip
These are the test cases that don't work on my Oregon: Map around Copenhagen: - Search for all roads in Denmark starting with Æ (switch to Danish keyboard to be able to type that character) or Ae doesn't find any road, it should find many. - Search for other special characters like Ø works fine. - Search for all roads in city "Albertslund Kommune" lists ... Abildgården Æblets Kvt Alberts Have Alberts Vænge ... When I search for roads starting with A in Albertslund Kommune it lists only Abildgården Similar results with other searches, the device seems to stop reading the data when the first name with Æ is hit. When I search for AL (so that it doesn't read the Æ name) it lists the above roads. Don't know if I should contact Garmin ?
Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Nev, thanks for the hint, just tried it. The downgrade works but it doesn't solve the problem, so I am using 5.00 again (and restoring my settings ... ) Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von nwastra <nwastra@gmail.com> Gesendet: Montag, 15. Mai 2017 08:35:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd There is an archive of Garmin updates here http://gawisp.com/perry/ and for Oregon here http://gawisp.com/perry/oregon/ and this may be the 4.6 update gawisp.com/perry/oregon/Oregon6x0_WebUpdater__460.gcd<http://gawisp.com/perry/oregon/Oregon6x0_WebUpdater__460.gcd> I have not used these before so I am unsure if you can revert to the older state using these? Nev On 15 May 2017, at 3:52 PM, Gerd Petermann <gpetermann_muenchen@hotmail.com<mailto:gpetermann_muenchen@hotmail.com>> wrote: Hi all, It seems that r3942 produces maps which work quite well with MapSource and Basecamp. I can find roads with names like Æblegården or "Außer Ort". I find POI in the expected category. Anyhow, I see different results on my devices. It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Road names containing characters which appear in the "expand" section cause trouble. For cp-1252 (--latin1) these are expand … to . . . expand ¼ to 1 / 4 expand ½ to 1 / 2 expand ¾ to 3 / 4 expand æ to a e expand Æ to A E expand œ to o e expand Œ to O E expand ß to s s expand ™ to T M I am pretty sure now that this is a bug in the Oregon firmware. It would be interesting to know if firmware 4.60 worked. According to this page http://www8.garmin.com/support/download_details.jsp?id=6157 there was a change described "Improved address search" with 4.80. Unfortunately I was not able to download any previous version. Any hints? The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken. This also happens when I use MapSource to install the map on the device. The installed map "GARMIN CN Europe NTU 2018.1" is a unicode map and works fine. So, if you create maps which contain road names containing special characters, please try how maps created with r3942 work on your device(s). I've uploaded a copy of the version here: http://files.mkgmap.org.uk/download/351/mkgmap-optimize-index-r3942.zip These are the test cases that don't work on my Oregon: Map around Copenhagen: - Search for all roads in Denmark starting with Æ (switch to Danish keyboard to be able to type that character) or Ae doesn't find any road, it should find many. - Search for other special characters like Ø works fine. - Search for all roads in city "Albertslund Kommune" lists ... Abildgården Æblets Kvt Alberts Have Alberts Vænge ... When I search for roads starting with A in Albertslund Kommune it lists only Abildgården Similar results with other searches, the device seems to stop reading the data when the first name with Æ is hit. When I search for AL (so that it doesn't read the Æ name) it lists the above roads. Don't know if I should contact Garmin ? Gerd _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
just downloaded r3942, installed it , downloading and extracing osm of australia latest from http://download.geofabrik.de/australia-oceania/australia.html will compile the map soon and test on montana 680 T Stephen On Mon, May 15, 2017 at 4:57 PM, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Nev,
thanks for the hint, just tried it. The downgrade works but it doesn't solve the problem, so I am using 5.00 again (and restoring my settings ... )
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von nwastra <nwastra@gmail.com> Gesendet: Montag, 15. Mai 2017 08:35:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] please test r3942
Hi Gerd There is an archive of Garmin updates here http://gawisp.com/perry/ and for Oregon here http://gawisp.com/perry/oregon/ and this may be the 4.6 update gawisp.com/perry/oregon/ Oregon6x0_WebUpdater__460.gcd<http://gawisp.com/perry/ oregon/Oregon6x0_WebUpdater__460.gcd> I have not used these before so I am unsure if you can revert to the older state using these?
Nev
On 15 May 2017, at 3:52 PM, Gerd Petermann <gpetermann_muenchen@hotmail. com<mailto:gpetermann_muenchen@hotmail.com>> wrote:
Hi all,
It seems that r3942 produces maps which work quite well with MapSource and Basecamp. I can find roads with names like Æblegården or "Außer Ort". I find POI in the expected category.
Anyhow, I see different results on my devices. It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Road names containing characters which appear in the "expand" section cause trouble. For cp-1252 (--latin1) these are expand … to . . . expand ¼ to 1 / 4 expand ½ to 1 / 2 expand ¾ to 3 / 4 expand æ to a e expand Æ to A E expand œ to o e expand Œ to O E expand ß to s s expand ™ to T M I am pretty sure now that this is a bug in the Oregon firmware. It would be interesting to know if firmware 4.60 worked. According to this page http://www8.garmin.com/support/download_details.jsp?id=6157 there was a change described "Improved address search" with 4.80. Unfortunately I was not able to download any previous version. Any hints?
The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken. This also happens when I use MapSource to install the map on the device. The installed map "GARMIN CN Europe NTU 2018.1" is a unicode map and works fine.
So, if you create maps which contain road names containing special characters, please try how maps created with r3942 work on your device(s). I've uploaded a copy of the version here: http://files.mkgmap.org.uk/download/351/mkgmap-optimize-index-r3942.zip
These are the test cases that don't work on my Oregon: Map around Copenhagen: - Search for all roads in Denmark starting with Æ (switch to Danish keyboard to be able to type that character) or Ae doesn't find any road, it should find many. - Search for other special characters like Ø works fine. - Search for all roads in city "Albertslund Kommune" lists ... Abildgården Æblets Kvt Alberts Have Alberts Vænge ... When I search for roads starting with A in Albertslund Kommune it lists only Abildgården Similar results with other searches, the device seems to stop reading the data when the first name with Æ is hit. When I search for AL (so that it doesn't read the Æ name) it lists the above roads. Don't know if I should contact Garmin ?
Gerd _______________________________________________ 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
Hi Gerd, I have compiled map of Poland using r3942, search looks OK in nuvi 1440, but we don't have characters like 'Æ' or 'ß', so I probably can't test your problem. I'm downloading data for Europe, will compile and test it later. The only glitch I have noticed is in Mapsource. It looks like index doesn't contain references to last word of street name. For example, there are streets "Marszałka Ferdynanda Focha" and "Aleja Grunwaldzka". I can search for "Ferdynanda Focha" but not for "Focha" alone. I can search for "Grunwaldzka", which exist in another location, but I won't find "Aleja Grunwaldzka" with that search. This isn't new, the same behavior show my older maps.
It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Maybe there is something wrong with SRT? I have uploaded samples of original SRT, you can compare with srt from mkgmap: http://files.mkgmap.org.uk/download/352/srt.7z
Garmin uses 2 types of CP1252, I think one of differences is that "Western European2 Sort" expands 'Æ'. You can check srt files, that comes with cgpsmapper too, there is file "sort.img" in cGPSmapper distribution, which contains multiple srt subfiles.
The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken.
I have never seen that kind of message. I would expect something like "can't authenticate map", which means that Garmin doesn't want you to use free Unicode maps in this device. You would need a bit older model to test Unicode, for example 23xx, 24xx, 34xx, 35xx.
Don't know if I should contact Garmin ?
Would be nice to get support for mkgmap from Garmin ;) I think you can find developers on Garmin forum: https://forums.garmin.com I don't know how helpful they could be in case of problems caused by non-Garmin map. -- Best regards, Andrzej
road test so far is ok on montanna 680 T , but Today i will do a address search with it from home to clients and see how It goes. Stephen . On Wed, May 17, 2017 at 8:49 AM, Andrzej Popowski <popej@poczta.onet.pl> wrote:
Hi Gerd,
I have compiled map of Poland using r3942, search looks OK in nuvi 1440, but we don't have characters like 'Æ' or 'ß', so I probably can't test your problem. I'm downloading data for Europe, will compile and test it later.
The only glitch I have noticed is in Mapsource. It looks like index doesn't contain references to last word of street name. For example, there are streets "Marszałka Ferdynanda Focha" and "Aleja Grunwaldzka". I can search for "Ferdynanda Focha" but not for "Focha" alone. I can search for "Grunwaldzka", which exist in another location, but I won't find "Aleja Grunwaldzka" with that search. This isn't new, the same behavior show my older maps.
It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Maybe there is something wrong with SRT? I have uploaded samples of original SRT, you can compare with srt from mkgmap: http://files.mkgmap.org.uk/download/352/srt.7z
Garmin uses 2 types of CP1252, I think one of differences is that "Western European2 Sort" expands 'Æ'.
You can check srt files, that comes with cgpsmapper too, there is file "sort.img" in cGPSmapper distribution, which contains multiple srt subfiles.
The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken.
I have never seen that kind of message. I would expect something like "can't authenticate map", which means that Garmin doesn't want you to use free Unicode maps in this device. You would need a bit older model to test Unicode, for example 23xx, 24xx, 34xx, 35xx.
Don't know if I should contact Garmin ?
Would be nice to get support for mkgmap from Garmin ;) I think you can find developers on Garmin forum: https://forums.garmin.com I don't know how helpful they could be in case of problems caused by non-Garmin map.
-- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Steve, thanks for testing. Please report anything that is different to the trunk version, also if it is better. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Sgalowski <steve.sgalowski@gmail.com> Gesendet: Mittwoch, 17. Mai 2017 00:56:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] please test r3942 road test so far is ok on montanna 680 T , but Today i will do a address search with it from home to clients and see how It goes. Stephen . On Wed, May 17, 2017 at 8:49 AM, Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> wrote: Hi Gerd, I have compiled map of Poland using r3942, search looks OK in nuvi 1440, but we don't have characters like 'Æ' or 'ß', so I probably can't test your problem. I'm downloading data for Europe, will compile and test it later. The only glitch I have noticed is in Mapsource. It looks like index doesn't contain references to last word of street name. For example, there are streets "Marszałka Ferdynanda Focha" and "Aleja Grunwaldzka". I can search for "Ferdynanda Focha" but not for "Focha" alone. I can search for "Grunwaldzka", which exist in another location, but I won't find "Aleja Grunwaldzka" with that search. This isn't new, the same behavior show my older maps.
It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Maybe there is something wrong with SRT? I have uploaded samples of original SRT, you can compare with srt from mkgmap: http://files.mkgmap.org.uk/download/352/srt.7z
Garmin uses 2 types of CP1252, I think one of differences is that "Western European2 Sort" expands 'Æ'. You can check srt files, that comes with cgpsmapper too, there is file "sort.img" in cGPSmapper distribution, which contains multiple srt subfiles.
The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken.
I have never seen that kind of message. I would expect something like "can't authenticate map", which means that Garmin doesn't want you to use free Unicode maps in this device. You would need a bit older model to test Unicode, for example 23xx, 24xx, 34xx, 35xx.
Don't know if I should contact Garmin ?
Would be nice to get support for mkgmap from Garmin ;) I think you can find developers on Garmin forum: https://forums.garmin.com I don't know how helpful they could be in case of problems caused by non-Garmin map. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, thanks for testing. The problem with my Oregon is that it doesn't find any of the characters in the expand section. You are right, it might be an error in the SRT file which is ignored by the PC programs and also by my nüvi. I've already fixed one error (see http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3942) but that did not solve my problem, so I wanted to find out if other devices show the same problem. I'll also try to reproduce your problem case. I assume you use --latin1 and --x-split-name-index ? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 00:49:37 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd, I have compiled map of Poland using r3942, search looks OK in nuvi 1440, but we don't have characters like 'Æ' or 'ß', so I probably can't test your problem. I'm downloading data for Europe, will compile and test it later. The only glitch I have noticed is in Mapsource. It looks like index doesn't contain references to last word of street name. For example, there are streets "Marszałka Ferdynanda Focha" and "Aleja Grunwaldzka". I can search for "Ferdynanda Focha" but not for "Focha" alone. I can search for "Grunwaldzka", which exist in another location, but I won't find "Aleja Grunwaldzka" with that search. This isn't new, the same behavior show my older maps.
It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Maybe there is something wrong with SRT? I have uploaded samples of original SRT, you can compare with srt from mkgmap: http://files.mkgmap.org.uk/download/352/srt.7z
Garmin uses 2 types of CP1252, I think one of differences is that "Western European2 Sort" expands 'Æ'. You can check srt files, that comes with cgpsmapper too, there is file "sort.img" in cGPSmapper distribution, which contains multiple srt subfiles.
The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken.
I have never seen that kind of message. I would expect something like "can't authenticate map", which means that Garmin doesn't want you to use free Unicode maps in this device. You would need a bit older model to test Unicode, for example 23xx, 24xx, 34xx, 35xx.
Don't know if I should contact Garmin ?
Would be nice to get support for mkgmap from Garmin ;) I think you can find developers on Garmin forum: https://forums.garmin.com I don't know how helpful they could be in case of problems caused by non-Garmin map. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Andrzej, I can reproduce the search problems with your poland map from 2016, but not with one created with the default style and r3942. The only problem that I see is that MapSource and Basecamp list the entries in a rather strange order, see attached picture. We think we know a solution for that which works in Basecamp, but not in MapSource. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 00:49:37 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd, I have compiled map of Poland using r3942, search looks OK in nuvi 1440, but we don't have characters like 'Æ' or 'ß', so I probably can't test your problem. I'm downloading data for Europe, will compile and test it later. The only glitch I have noticed is in Mapsource. It looks like index doesn't contain references to last word of street name. For example, there are streets "Marszałka Ferdynanda Focha" and "Aleja Grunwaldzka". I can search for "Ferdynanda Focha" but not for "Focha" alone. I can search for "Grunwaldzka", which exist in another location, but I won't find "Aleja Grunwaldzka" with that search. This isn't new, the same behavior show my older maps.
It seems that the Oregon 600 with firmware 5.00 doesn't "understand" the GARMIN SRT file. Maybe there is something wrong with SRT? I have uploaded samples of original SRT, you can compare with srt from mkgmap: http://files.mkgmap.org.uk/download/352/srt.7z
Garmin uses 2 types of CP1252, I think one of differences is that "Western European2 Sort" expands 'Æ'. You can check srt files, that comes with cgpsmapper too, there is file "sort.img" in cGPSmapper distribution, which contains multiple srt subfiles.
The Nüvi2447 seems to work fine with maps created with --latin1 (also with --lower-case) but says that --unicode maps are broken.
I have never seen that kind of message. I would expect something like "can't authenticate map", which means that Garmin doesn't want you to use free Unicode maps in this device. You would need a bit older model to test Unicode, for example 23xx, 24xx, 34xx, 35xx.
Don't know if I should contact Garmin ?
Would be nice to get support for mkgmap from Garmin ;) I think you can find developers on Garmin forum: https://forums.garmin.com I don't know how helpful they could be in case of problems caused by non-Garmin map. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I use my own style, --code-page=1250 (it is for Polish) and --x-split-name-index. If problem is about srt file for cp1252, then probably my test is not good. I have started compilation of Europe map with cp1252 but it will take some time.
MapSource and Basecamp list the entries in a rather strange order
Maybe MapSource lists entries exactly as sorted in index? Probably search is done with partial name but result shows full street name. I guess that sort key in mkgmap deals only with partial name and when partial names in comparison are the same, full names remain in random order. Maybe you could extend sort key to use full name too? I'm not sure if lack of possibility to select "Focha" alone is error of Mapsource or mkgmap. It looks like partial names aren't listed in Mapsource but they are present when searching in nuvi. The same search in City Navigator works a bit different. I think CN adds "ulica" (street) prefix to a name. I can see entries: "ulica Ferdynada Focha" "ulica Focha" "ulica marsz. Ferdynanda Focha" When I select "ulica Focha" i get a correct hit at "ulica marsz. Ferdynanda Focha". -- Best regards, Andrzej
Hi Andrzej, yes, MapSource lists the entries in the order in which they appear in the index. With r3942 mkgmap sorts by partial name + full name, and the order is probably essential. The PC index contains a list of the (full) road names (MDR15) and a list in MDR7 sorted by partial name + full name that refers to the entries in Mdr15. Both MapSource and Basecamp show the name written to MDR15. The index for the device doesn't contain Mdr15, instead MDR7 points to the label. The data in Mdr7 tells Garmin software what part of the label was used, so I think Garmin can show that part as well. Maybe your problem is that many entries are found and the one you expect comes too late. By default MapSource shows only the first 30 entries, maybe change it to 100 or so. Basecamp evaluates more information and the index allows to specify the order in which results should appear, but I've not yet implemented this (because MapSource ignores the info and I don't fully understand how to compute the data). I've now also compiled map for poland with code-page=1250 and see the same result for Focha as with 1252. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 09:48:45 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd, I use my own style, --code-page=1250 (it is for Polish) and --x-split-name-index. If problem is about srt file for cp1252, then probably my test is not good. I have started compilation of Europe map with cp1252 but it will take some time.
MapSource and Basecamp list the entries in a rather strange order
Maybe MapSource lists entries exactly as sorted in index? Probably search is done with partial name but result shows full street name. I guess that sort key in mkgmap deals only with partial name and when partial names in comparison are the same, full names remain in random order. Maybe you could extend sort key to use full name too? I'm not sure if lack of possibility to select "Focha" alone is error of Mapsource or mkgmap. It looks like partial names aren't listed in Mapsource but they are present when searching in nuvi. The same search in City Navigator works a bit different. I think CN adds "ulica" (street) prefix to a name. I can see entries: "ulica Ferdynada Focha" "ulica Focha" "ulica marsz. Ferdynanda Focha" When I select "ulica Focha" i get a correct hit at "ulica marsz. Ferdynanda Focha". -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd,
list in MDR7 sorted by partial name + full name
I'm looking at this code. I have doubts about function getInitialPart(), shouldn't it accommodate for prefix length? Like return name.substring((prefixOffset & 0xff), (nameOffset & 0xff) + (prefixOffset & 0xff)); -- Best regards, Andrzej
Hi Andrzej, the method is not used in the current code. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 11:07:32 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd,
list in MDR7 sorted by partial name + full name
I'm looking at this code. I have doubts about function getInitialPart(), shouldn't it accommodate for prefix length? Like return name.substring((prefixOffset & 0xff), (nameOffset & 0xff) + (prefixOffset & 0xff)); -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I see this method used in Mdr7.java, line 188. Isn't it just the code to make full name included in sorting by partial name? -- Best regards, Andrzej
Hi Andrzej, this is code in trunk (r3909), r3942 is in the optimize-index branch. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 12:04:19 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd, I see this method used in Mdr7.java, line 188. Isn't it just the code to make full name included in sorting by partial name? -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, my bad, I thought that if I looked at the same release number, then I had the same code. I have compiled map with r3942 from download page, I hope that it is the same as you posted in this thread. Will test some more. -- Best regards, Andrzej
Hi Andrzej, svn can be missleading. When you use svn update in trunk it will say svn update Updating '.': At revision 3942. Better use svn info to see something like this: Working Copy Root Path: D:\mkgmap-tr URL: https://svn.mkgmap.org.uk/svn/mkgmap/trunk Relative URL: ^/trunk Repository Root: https://svn.mkgmap.org.uk/svn/mkgmap Repository UUID: 25d90789-57f7-4ee0-8453-03a3dfeeeb22 Revision: 3942 Node Kind: directory Schedule: normal Last Changed Author: gerd Last Changed Rev: 3909 Last Changed Date: 2017-04-21 07:15:20 +0200 (Fr, 21 Apr 2017) The 2nd last line shows the important info. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 13:49:48 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd, my bad, I thought that if I looked at the same release number, then I had the same code. I have compiled map with r3942 from download page, I hope that it is the same as you posted in this thread. Will test some more. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, I'm not proficient with SVN but I have managed to download this branch. A lot of changes! I have one doubt. When you sort "allstreets", you fill the table "streets" and add index in table to Mdr7Record. I think these indexes start form 1, shouldn't they start form 0? Sorry if I miss something obvious. -- Best regards, Andrzej
Hi Andrzej, in MDR many tables start at 1 instead of 0. I assume 0 is reserved for "no data". The code is based on the reports and checks made with the display tool against original Garmin maps and the gmapsupp.img created with MapSource. When I change the code as you suggest MapSource will often fail to find a road with message like "The selected street is not valid in this map product. Please select a different street." and that means that the index is broken. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 14:28:01 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942 Hi Gerd, I'm not proficient with SVN but I have managed to download this branch. A lot of changes! I have one doubt. When you sort "allstreets", you fill the table "streets" and add index in table to Mdr7Record. I think these indexes start form 1, shouldn't they start form 0? Sorry if I miss something obvious. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
on my Garmin Montanna 680 T . so far all is good . the only thing i Had probs with is with routing and it's distance routing and distance between the preferred route and the route you are on . if the preferred road is 100 meters or so away from the road you are on , it does not re calculate your position to the road you are on. example is . Moggill road Pinjarra hills , and Vyner road Pinjarra hils ( Brisbane queensland australia ) also 2nd example , Rafting ground road and Brookfield road Kenmore Hills ( brisbane queensland australia ) . am checking on a longer route today also . Stephen On Wed, May 17, 2017 at 10:52 PM, Gerd Petermann < GPetermann_muenchen@hotmail.com> wrote:
Hi Andrzej,
in MDR many tables start at 1 instead of 0. I assume 0 is reserved for "no data". The code is based on the reports and checks made with the display tool against original Garmin maps and the gmapsupp.img created with MapSource. When I change the code as you suggest MapSource will often fail to find a road with message like "The selected street is not valid in this map product. Please select a different street." and that means that the index is broken.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Mittwoch, 17. Mai 2017 14:28:01 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] please test r3942
Hi Gerd,
I'm not proficient with SVN but I have managed to download this branch. A lot of changes!
I have one doubt. When you sort "allstreets", you fill the table "streets" and add index in table to Mdr7Record. I think these indexes start form 1, shouldn't they start form 0?
Sorry if I miss something obvious.
-- Best regards, Andrzej _______________________________________________ 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
participants (4)
-
Andrzej Popowski -
Gerd Petermann -
nwastra -
Steve Sgalowski