Re: [mkgmap-dev] type/subtype of points and cities
Hi Gerd MdrDisplay/cityPtrSize: I didn't change any significant behaviour. Because it seemed inconsistent, I put in a diagnostic. I also made the switch stmt in printSec11_city like the similar instances that do have to handle 1/2/3 byte objects rather than switch ... case 3: ... default: ... I should also have added handling cityPtrSize of 4. I fixed mkgmap to work correctly for this. However, when I get a tile that needs 4 byte pointers, the gmapsupp.img size jumps up, so I re-split the map with a different number of nodes until the city count reduces again. My preference here would be rename one of the cityPtrSize variables and keep/extend the switch statement. Happy to get rid of the test/system.out.printf MdrCheck/group/toType: The original code in check10() tried to re-constitute a type/subtype as per mkgmap from group/someBits data and it didn't do it fully or correctly. I agree that this tool should just display/validate the understanding of the Garmin IMG structure. However, in this case, because the fullType generated above is then validated against data from mdr11, it has to do this validation based on the grouping chosen by mkgmap. Similarly, if these mappings are changed in mkgmap, equivalent changes need to be made to Display (I put in a few comments to this effect in the relevant places) AllElements: On my Etrex device, it shows some points not in the correct place according to sequence with strange types or names. Some of these points are outside the map area! I can't quite remember the details, it has been a while since I last used it. So yes, I'm sure it is generating something it shouldn't and maybe the lower levels of mkgmap code should be checking/objecting as well. It might be related to indPoints sometimes having subtypes; I think there are assumptions that these are a fixed size items. I don't know if this will cause the problems you describe, but I'll have a look at it. Ticker On Thu, 2019-11-07 at 09:15 +, Gerd Petermann wrote: > Hi Ticker, > > I've not yet understood the changes regarding cityPtrSize. Do you > think that Garmin supports one-byte pointers when there are less than > 128 cities? > The transalpin demo map contains only a few cities or regions but > uses two bytes. > I've attached a patch with my proposed changes. > > One more hint: > I don't like the description "Understands the same MDR groups as > generated by mkgmap so it can recreate the correct full type." > My understanding of display tool is this: > - The main purpose is to find out how the Garmin algos encode things > in IMG format, so we should use maps produced by Garmin and > Mapsource/Basecamp to verify. The code in mkgmap should be the > results of those findings, not vice versa. > - I also use it to verify that changes made in mkgmap don't do > something unexpected. > > I've just learned that Mapsource doesn't like the map produced with > java -jar mkgmap.jar --index --gmapi test-map:all-elements > It crashes when you search for all POI and also when you search for > cities (both without giving a name) > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 5. November 2019 12:44 > An: mkgmap development > Betreff: Re: [mkgmap-dev] type/subtype of points and cities > > Hi Gerd > > Here is patch for Display. > > Changes are: > Couple of extra diagnostics. > Handles 1 byte cities. > Moves a call of getSection(11).get... out of a loop. > Consistent handling/display of point type/subtype. > Understands the same MDR groups as generated by mkgmap so > it can recreate the correct full type. > > Ticker > > On Tue, 2019-11-05 at 09:43 +, Gerd Petermann wrote: > > Hi Ticker, > > > > okay, looks good to me. In an earlier post you mentioned that > > display > > tool needs changes, too. Please post that patch as well. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Montag, 4. November 2019 18:12 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] type/subtype of points and cities > > > > Hi Gerd > > > > To stay compatible with "Openfietsmap full" style, I've updated the > > patch to change the range of city to be: > > type >= 0x0100 && type < 0x1100; > > Release mkgmap had this as: > > type >= 0x0100 && type <= 0x1100; > > > > In release mkgmap, a point with value 0x1100 was added to the RGN > > as > > an > > indPoint, but not indexed as a city by MDR. Also 0x1100 is not > > findable > > as a nearby city, at least on Garmin eTrex. I couldn't detect any > > useful behaviour for this combination. > > > > Ticker > > > > On Tue, 2019-10-22 at 15:03 +, Gerd Petermann wrote: > > > Hi Minko, > > > > > > "(like you say)" should have been ... "(like Ticker wrote)" > > > ... (a small dot with the label) ... > > > sorry, I forgot to use the typ file, so 0x1101 is displayed with > > > an > > > ic
Re: [mkgmap-dev] type/subtype of points and cities
Hi Ticker, the problems with AllElements are not new. I see them also with much older versions of mkgmap. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 7. November 2019 12:56 An: mkgmap development Betreff: Re: [mkgmap-dev] type/subtype of points and cities Hi Gerd MdrDisplay/cityPtrSize: I didn't change any significant behaviour. Because it seemed inconsistent, I put in a diagnostic. I also made the switch stmt in printSec11_city like the similar instances that do have to handle 1/2/3 byte objects rather than switch ... case 3: ... default: ... I should also have added handling cityPtrSize of 4. I fixed mkgmap to work correctly for this. However, when I get a tile that needs 4 byte pointers, the gmapsupp.img size jumps up, so I re-split the map with a different number of nodes until the city count reduces again. My preference here would be rename one of the cityPtrSize variables and keep/extend the switch statement. Happy to get rid of the test/system.out.printf MdrCheck/group/toType: The original code in check10() tried to re-constitute a type/subtype as per mkgmap from group/someBits data and it didn't do it fully or correctly. I agree that this tool should just display/validate the understanding of the Garmin IMG structure. However, in this case, because the fullType generated above is then validated against data from mdr11, it has to do this validation based on the grouping chosen by mkgmap. Similarly, if these mappings are changed in mkgmap, equivalent changes need to be made to Display (I put in a few comments to this effect in the relevant places) AllElements: On my Etrex device, it shows some points not in the correct place according to sequence with strange types or names. Some of these points are outside the map area! I can't quite remember the details, it has been a while since I last used it. So yes, I'm sure it is generating something it shouldn't and maybe the lower levels of mkgmap code should be checking/objecting as well. It might be related to indPoints sometimes having subtypes; I think there are assumptions that these are a fixed size items. I don't know if this will cause the problems you describe, but I'll have a look at it. Ticker On Thu, 2019-11-07 at 09:15 +, Gerd Petermann wrote: > Hi Ticker, > > I've not yet understood the changes regarding cityPtrSize. Do you > think that Garmin supports one-byte pointers when there are less than > 128 cities? > The transalpin demo map contains only a few cities or regions but > uses two bytes. > I've attached a patch with my proposed changes. > > One more hint: > I don't like the description "Understands the same MDR groups as > generated by mkgmap so it can recreate the correct full type." > My understanding of display tool is this: > - The main purpose is to find out how the Garmin algos encode things > in IMG format, so we should use maps produced by Garmin and > Mapsource/Basecamp to verify. The code in mkgmap should be the > results of those findings, not vice versa. > - I also use it to verify that changes made in mkgmap don't do > something unexpected. > > I've just learned that Mapsource doesn't like the map produced with > java -jar mkgmap.jar --index --gmapi test-map:all-elements > It crashes when you search for all POI and also when you search for > cities (both without giving a name) > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 5. November 2019 12:44 > An: mkgmap development > Betreff: Re: [mkgmap-dev] type/subtype of points and cities > > Hi Gerd > > Here is patch for Display. > > Changes are: > Couple of extra diagnostics. > Handles 1 byte cities. > Moves a call of getSection(11).get... out of a loop. > Consistent handling/display of point type/subtype. > Understands the same MDR groups as generated by mkgmap so > it can recreate the correct full type. > > Ticker > > On Tue, 2019-11-05 at 09:43 +, Gerd Petermann wrote: > > Hi Ticker, > > > > okay, looks good to me. In an earlier post you mentioned that > > display > > tool needs changes, too. Please post that patch as well. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Montag, 4. November 2019 18:12 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] type/subtype of points and cities > > > > Hi Gerd > > > > To stay compatible with "Openfietsmap full" style, I've updated the > > patch to change the range of city to be: > > type >= 0x0100 && type < 0x1100; > > Release mkgmap had this as: > > type >= 0x0100 && type <= 0x1100; > > > > In release mkgmap, a point with value 0x1100 was added to the RGN > > as > > an > > indPoint, but not indexed as a city by MDR. Also 0x1100 is not > > findable > > as a nearby city, at least on Garmin eTrex. I couldn't detect any > > useful behaviour for this co
Re: [mkgmap-dev] type/subtype of points and cities
Hi Ticker, maybe allElements should only produce POIs for types acepted by GTYpe.checkType()? When I do that I see no crashes in MapSource but the MdrCheck still complains about some mdr11 entries. Reg. MapPoint.isCityType(): According to MapSource only type 0x0100 .. 0x0d00 are cities (and subtype must be zero) When I use "Find Nearest Places" in Mapsource it doesn't show the other types when I limit the search to cities. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Donnerstag, 7. November 2019 13:18 An: Ticker Berkin; mkgmap development Betreff: Re: [mkgmap-dev] type/subtype of points and cities Hi Ticker, the problems with AllElements are not new. I see them also with much older versions of mkgmap. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 7. November 2019 12:56 An: mkgmap development Betreff: Re: [mkgmap-dev] type/subtype of points and cities Hi Gerd MdrDisplay/cityPtrSize: I didn't change any significant behaviour. Because it seemed inconsistent, I put in a diagnostic. I also made the switch stmt in printSec11_city like the similar instances that do have to handle 1/2/3 byte objects rather than switch ... case 3: ... default: ... I should also have added handling cityPtrSize of 4. I fixed mkgmap to work correctly for this. However, when I get a tile that needs 4 byte pointers, the gmapsupp.img size jumps up, so I re-split the map with a different number of nodes until the city count reduces again. My preference here would be rename one of the cityPtrSize variables and keep/extend the switch statement. Happy to get rid of the test/system.out.printf MdrCheck/group/toType: The original code in check10() tried to re-constitute a type/subtype as per mkgmap from group/someBits data and it didn't do it fully or correctly. I agree that this tool should just display/validate the understanding of the Garmin IMG structure. However, in this case, because the fullType generated above is then validated against data from mdr11, it has to do this validation based on the grouping chosen by mkgmap. Similarly, if these mappings are changed in mkgmap, equivalent changes need to be made to Display (I put in a few comments to this effect in the relevant places) AllElements: On my Etrex device, it shows some points not in the correct place according to sequence with strange types or names. Some of these points are outside the map area! I can't quite remember the details, it has been a while since I last used it. So yes, I'm sure it is generating something it shouldn't and maybe the lower levels of mkgmap code should be checking/objecting as well. It might be related to indPoints sometimes having subtypes; I think there are assumptions that these are a fixed size items. I don't know if this will cause the problems you describe, but I'll have a look at it. Ticker On Thu, 2019-11-07 at 09:15 +, Gerd Petermann wrote: > Hi Ticker, > > I've not yet understood the changes regarding cityPtrSize. Do you > think that Garmin supports one-byte pointers when there are less than > 128 cities? > The transalpin demo map contains only a few cities or regions but > uses two bytes. > I've attached a patch with my proposed changes. > > One more hint: > I don't like the description "Understands the same MDR groups as > generated by mkgmap so it can recreate the correct full type." > My understanding of display tool is this: > - The main purpose is to find out how the Garmin algos encode things > in IMG format, so we should use maps produced by Garmin and > Mapsource/Basecamp to verify. The code in mkgmap should be the > results of those findings, not vice versa. > - I also use it to verify that changes made in mkgmap don't do > something unexpected. > > I've just learned that Mapsource doesn't like the map produced with > java -jar mkgmap.jar --index --gmapi test-map:all-elements > It crashes when you search for all POI and also when you search for > cities (both without giving a name) > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 5. November 2019 12:44 > An: mkgmap development > Betreff: Re: [mkgmap-dev] type/subtype of points and cities > > Hi Gerd > > Here is patch for Display. > > Changes are: > Couple of extra diagnostics. > Handles 1 byte cities. > Moves a call of getSection(11).get... out of a loop. > Consistent handling/display of point type/subtype. > Understands the same MDR groups as generated by mkgmap so > it can recreate the correct full type. > > Ticker > > On Tue, 2019-11-05 at 09:43 +, Gerd Petermann wrote: > > Hi Ticker, > > > > okay, looks good to me. In an earlier post you mentioned that > > display > > tool needs changes, too. Please post that patch as well. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Tic
Re: [mkgmap-dev] type/subtype of points and cities
Hi Gerd Yes, I'll change allElements to not try subtypes for isCityType, and, elsewhere, assert that indPoints don't have a subtype. My Etrex only shows points in the range you mention in the results for nearby cities, but doing a spell search it finds whatever is in the appropriate MDR - presume group 0 in MDR 10. I find it a useful feature (for UK postcodes) - having a point that can be searched for by name but doesn't swamp the 'nearby' display. City search seemed to be the only place I could do this and the various old city range definitions allowed it anyway. Ticker On Thu, 2019-11-07 at 12:51 +, Gerd Petermann wrote: > Hi Ticker, > > maybe allElements should only produce POIs for types acepted by > GTYpe.checkType()? > When I do that I see no crashes in MapSource but the MdrCheck still > complains about some mdr11 entries. > > Reg. MapPoint.isCityType(): > According to MapSource only type 0x0100 .. 0x0d00 are cities (and > subtype must be zero) > When I use "Find Nearest Places" in Mapsource it doesn't show the > other types when I limit the search to cities. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Gerd Petermann > Gesendet: Donnerstag, 7. November 2019 13:18 > An: Ticker Berkin; mkgmap development > Betreff: Re: [mkgmap-dev] type/subtype of points and cities > > Hi Ticker, > > the problems with AllElements are not new. I see them also with much > older versions of mkgmap. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 7. November 2019 12:56 > An: mkgmap development > Betreff: Re: [mkgmap-dev] type/subtype of points and cities > > Hi Gerd > > MdrDisplay/cityPtrSize: > > I didn't change any significant behaviour. Because it seemed > inconsistent, I put in a diagnostic. I also made the switch stmt in > printSec11_city like the similar instances that do have to handle > 1/2/3 > byte objects rather than switch ... case 3: ... default: ... > > I should also have added handling cityPtrSize of 4. I fixed mkgmap to > work correctly for this. However, when I get a tile that needs 4 byte > pointers, the gmapsupp.img size jumps up, so I re-split the map with > a > different number of nodes until the city count reduces again. > > My preference here would be rename one of the cityPtrSize variables > and > keep/extend the switch statement. Happy to get rid of the > test/system.out.printf > > MdrCheck/group/toType: > > The original code in check10() tried to re-constitute a type/subtype > as > per mkgmap from group/someBits data and it didn't do it fully or > correctly. > > I agree that this tool should just display/validate the understanding > of the Garmin IMG structure. However, in this case, because the > fullType generated above is then validated against data from mdr11, > it > has to do this validation based on the grouping chosen by mkgmap. > Similarly, if these mappings are changed in mkgmap, equivalent > changes > need to be made to Display (I put in a few comments to this effect in > the relevant places) > > AllElements: > > On my Etrex device, it shows some points not in the correct place > according to sequence with strange types or names. Some of these > points > are outside the map area! I can't quite remember the details, it has > been a while since I last used it. > > So yes, I'm sure it is generating something it shouldn't and maybe > the > lower levels of mkgmap code should be checking/objecting as well. It > might be related to indPoints sometimes having subtypes; I think > there > are assumptions that these are a fixed size items. > > I don't know if this will cause the problems you describe, but I'll > have a look at it. > > Ticker > > > On Thu, 2019-11-07 at 09:15 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I've not yet understood the changes regarding cityPtrSize. Do you > > think that Garmin supports one-byte pointers when there are less > > than > > 128 cities? > > The transalpin demo map contains only a few cities or regions but > > uses two bytes. > > I've attached a patch with my proposed changes. > > > > One more hint: > > I don't like the description "Understands the same MDR groups as > > generated by mkgmap so it can recreate the correct full type." > > My understanding of display tool is this: > > - The main purpose is to find out how the Garmin algos encode > > things > > in IMG format, so we should use maps produced by Garmin and > > Mapsource/Basecamp to verify. The code in mkgmap should be the > > results of those findings, not vice versa. > > - I also use it to verify that changes made in mkgmap don't do > > something unexpected. > > > > I've just learned that Mapsource doesn't like the map produced with > > java -jar mkgmap.jar --index --gmapi test-map:all-elements > > It crashes when you search for all POI and also when you search for > > cities (both without giving a name) > > > > Gerd > > > > __
Re: [mkgmap-dev] precompiled sea files download
Same problem here with the sea-latest.zip from 0ct. 11 2019, file size ~203 Mb Problem solved with the file from today, size ~228 MB. Bernd Am Montag, 4. November 2019, 21:04:53 CET schrieb Joris Bo: > Hi, > > For my maps I suddenly had problems with the latest sea-files causing > flooding of complete Europe The next-day download was about 20Mb bigger > and worked fine again. I can’t exactly remember the dates or file sizes of > the download server The version which for me works fine again (screenshot > of my windows explorer): > Kind regards, Joris > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
