Re: [mkgmap-dev] Routing problem on GPSMAP 276Cx
Thank you Ticker and Gerdfor some reason i've been to restrictive in my device using 'Avoidence Setup' Problem solvedMit freundlichem Gruß Manfred Haiduk Ursprüngliche Nachricht Von: Ticker Berkin Datum: 13.10.2020 10:42 (GMT+01:00) An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Routing problem on GPSMAP 276Cx HiAlso:Routes through ferry terminals often involve service roads with a lowroad-class. Fastest time routing avoids using lower class roads in themiddle of a journey.Again, in a terminal there are often barriers and roads marked asaccess=customer or similar and these might set mkgmap:throughroute=no,again preventing routing.In complex terminals, there often isn't a clear route through onto theferry - I spent a while examining the terminals at both ends of a ferryand fixing various one-ways etc.Finally, after the doing the above, I still couldn't make thisparticular ferry work. Changing the ferry to a standard road didn't fixit. I could route from just outside one terminal to just outside theterminal at the other end, but not to points further along the road. Ithink there might be a problem with the internal routing structures(RouteCenter) where there is a single long distance as the onlyconnection within a RouteCenter and this is also the only connectionbetween the other RouteCenters at either end.TickerOn Tue, 2020-10-13 at 07:19 +, Gerd Petermann wrote:> Hi Manfred,> > did you make sure that the transport mode on your device is> configured to allow usage of ferries?> > Gerd> > > Von: mkgmap-dev im Auftrag> von Manfred Haiduk > Gesendet: Sonntag, 11. Oktober 2020 19:26> An: Development list for mkgmap> Betreff: [mkgmap-dev] Routing problem on GPSMAP 276Cx> > Hi all> > might be i stumbled again over a silly problem on my GPSMAP 276Cx.> Try> to route from my Hometown Hürtgenwald to Bad Honnef. The most obvious> way to do that is using the ferry Rolandseck <-> Bad Honnef.> MapSource> will use it but it seems, that the Garmin Device refuse to use any> ferry> routing, it chooses always a routing using bridges. Any idea, what> could> be wrong ?> > --> > Mit freundlichen Grüßen> > #> Manfred Haiduk,> Zum Fischbach 9,> 52393 Hürtgenwald> e-mail mhai...@t-online.de> #> > ___> 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___mkgmap-dev mailing listmkgmap-...@lists.mkgmap.org.ukhttp://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
Re: [mkgmap-dev] Routing problem on GPSMAP 276Cx
Disregard this e-mail, found out, what was going wrong ;-) Am 11.10.2020 um 19:26 schrieb Manfred Haiduk: Hi all might be i stumbled again over a silly problem on my GPSMAP 276Cx. Try to route from my Hometown Hürtgenwald to Bad Honnef. The most obvious way to do that is using the ferry Rolandseck <-> Bad Honnef. MapSource will use it but it seems, that the Garmin Device refuse to use any ferry routing, it chooses always a routing using bridges. Any idea, what could be wrong ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] highway=unclassified & area=yes
ThanksMit freundlichem Gruß Manfred Haiduk Ursprüngliche Nachricht Von: Ticker Berkin Datum: 13.09.2020 11:48 (GMT+01:00) An: Development list for mkgmap Betreff: Re: [mkgmap-dev] highway=unclassified & area=yes HiIn styles / default / lines, around line 181, the change would be:highway=unclassified [0x06 road_class=0 road_speed=3 resolution 21]to:highway=unclassified & area!=yes [0x06 road_class=0 road_speed=3resolution 21]If you style has a mop-up for unhandled highways, make sure that thisisn't triggeredTickerOn Sun, 2020-09-13 at 11:09 +0200, DD8KQ wrote:> Hi Ticker> > just for me a hint, how can i ignore this in a style ?> ___mkgmap-dev mailing listmkgmap-...@lists.mkgmap.org.ukhttp://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
Re: [mkgmap-dev] highway=unclassified & area=yes
Hi Ticker just for me a hint, how can i ignore this in a style ? Am 13.09.2020 um 09:59 schrieb Ticker Berkin: Hi all Checking the GBR, I detect 1865 of these highway areas. They are done in a consistent and systematic way by a number of mappers. I don't think it is a mapping error or an attempt to define the extent of a junction as per the proposed tagging highway=junction. Rather it is some option on the editing tool or some guidelines they are following that says to do this as a way of documenting the changes they have made within the junction area. I'll ask some of the mappers why they are doing it. These constructs can cause invalid routes to be calculated as well as confusing/irrelevant direction pop-ups and I now ignore them in my style. Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] CodePage number set to 0 after compiled
Hi Mike and Eugeny just thank you for your advice, that was my fault the option order in my batch file. Am 29.06.2020 um 23:14 schrieb Mike Baggaley: I suspect that the –latin1 option does not apply to the style compilation because the input file precedes the code page option. In general options only apply to input files that are placed after the option (with a few exceptions). Try moving your type file to after –c template.args. Cheers, Mike From: DD8KQ [mailto:dd...@gmx.de] Sent: 29 June 2020 13:40 To: Joris Bo ; Development list for mkgmap Subject: Re: [mkgmap-dev] CodePage number set to 0 after compiled Hi Joris, since the beginning of building my own maps for my device i allways added this option to my map building command, at least to have the correct mapid in the typ-file. Here is one example, how i do this : java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar -Dlog.config=logging.properties "c:\Program Files (x86)\KartenTools\mkgmap\mkgmap.jar" --location-autofill=is_in,nearest --mapname=70030001 --family-id=7003 .\styles\newstyle.txt --series-name="GERMANY TEST" --family-name="OpenStreetmap" --country-name=GERMANYTEST --country-abbr=GER --area-name=GER --overview-mapname="overview" --latin1 --style-file=.\styles --style=newstyle --max-jobs --keep-going --check-roundabouts --drive-on=detect,right --output-dir=.\out\MYGERMANY --index --bounds=.\bounds_latest --route --name-tag-list=name,place_name,loc_name --housenumbers --split-name-index --add-pois-to-areas --link-pois-to-ways --process-destination --process-exits --precomp-sea=.\sea_latest --tdbfile --draw-priority=10 --gmapsupp -c .\data\MYGERMANY\template.args --description=MYGERMANY --remove-ovm-work-files=true I opened this thread only to get an idea how to get rid of the TYPviewer error ;-) Am 29.06.2020 um 14:34 schrieb Joris Bo: Hi Manfred, I was not aware of Tickers tip that it was possible to supply a .txt in the same command line as the map building cmd. But it does make sense Always thought this must be a .typ and since the map building scripts only change when something gets broken I first noticed this a couple of month ago.. So I always first call mkgmap to create the .typ with correct codepage and family id and immediately after this, a second call to supply this newly created .typ to the map build call. At least this works for me. Kind regards, Joris -Oorspronkelijk bericht- Van: mkgmap-dev Namens DD8KQ Verzonden: maandag 29 juni 2020 13:16 Aan: mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] CodePage number set to 0 after compiled Hi all, i do not compile the typ.txt file as own process, its integrated in my command line for building my maps. But every now and then, i just open the resulting .typ-file with the viewer and since some time i saw these complaining errors. In my build options to create the map i'm using the option --latin1, as Joris suggested. But nevertheless, opening the typ file with TYPviewer i get allways this error. Am 29.06.2020 um 12:47 schrieb Ticker Berkin: > Hi Manfred > > Generally it is better to supply the TYP .txt file as an argument to > mkgmap when you build your map, rather than compiling it as a separate > process. > > Otherwise, as Joris says. > > Do you have a codePage specified in the file that is being ignored? > [_id]
Re: [mkgmap-dev] CodePage number set to 0 after compiled
Hi Joris, since the beginning of building my own maps for my device i allways added this option to my map building command, at least to have the correct mapid in the typ-file. Here is one example, how i do this : java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar -Dlog.config=logging.properties "c:\Program Files (x86)\KartenTools\mkgmap\mkgmap.jar" --location-autofill=is_in,nearest --mapname=70030001 --family-id=7003 .\styles\newstyle.txt --series-name="GERMANY TEST" --family-name="OpenStreetmap" --country-name=GERMANYTEST --country-abbr=GER --area-name=GER --overview-mapname="overview" --latin1 --style-file=.\styles --style=newstyle --max-jobs --keep-going --check-roundabouts --drive-on=detect,right --output-dir=.\out\MYGERMANY --index --bounds=.\bounds_latest --route --name-tag-list=name,place_name,loc_name --housenumbers --split-name-index --add-pois-to-areas --link-pois-to-ways --process-destination --process-exits --precomp-sea=.\sea_latest --tdbfile --draw-priority=10 --gmapsupp -c .\data\MYGERMANY\template.args --description=MYGERMANY --remove-ovm-work-files=true I opened this thread only to get an idea how to get rid of the TYPviewer error ;-) Am 29.06.2020 um 14:34 schrieb Joris Bo: Hi Manfred, I was not aware of Tickers tip that it was possible to supply a .txt in the same command line as the map building cmd. But it does make sense Always thought this must be a .typ and since the map building scripts only change when something gets broken I first noticed this a couple of month ago.. So I always first call mkgmap to create the .typ with correct codepage and family id and immediately after this, a second call to supply this newly created .typ to the map build call. At least this works for me. Kind regards, Joris -Oorspronkelijk bericht- Van: mkgmap-dev Namens DD8KQ Verzonden: maandag 29 juni 2020 13:16 Aan: mkgmap-dev@lists.mkgmap.org.uk Onderwerp: Re: [mkgmap-dev] CodePage number set to 0 after compiled Hi all, i do not compile the typ.txt file as own process, its integrated in my command line for building my maps. But every now and then, i just open the resulting .typ-file with the viewer and since some time i saw these complaining errors. In my build options to create the map i'm using the option --latin1, as Joris suggested. But nevertheless, opening the typ file with TYPviewer i get allways this error. Am 29.06.2020 um 12:47 schrieb Ticker Berkin: > Hi Manfred > > Generally it is better to supply the TYP .txt file as an argument to > mkgmap when you build your map, rather than compiling it as a separate > process. > > Otherwise, as Joris says. > > Do you have a codePage specified in the file that is being ignored? > [_id] > ... > CodePage= > ... > [End] > > Ticker > > On Mon, 2020-06-29 at 10:39 +, Joris Bo wrote: >> Hi Manfed, >> >> I encountered the same, since you must always supply the >> codepage on the commandline >> >> Like >> >> --code-page=65001 >> Or >> --code-page=latin1 >> >> >> Joris >> >> >> -Oorspronkelijk bericht- >> Van: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> Namens >> Manfred Haiduk >> Verzonden: maandag 29 juni 2020 12:29 >> Aan: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> >> Onderwerp: [mkgmap-dev] CodePage number set to 0 after compiled >> >> Hi all, >> >> i don't know, if i had something forgotten but since some time, if i >> compile my style.txt with mkgmap, the resulting typ-file seems to not >> have any codepage number other
Re: [mkgmap-dev] CodePage number set to 0 after compiled
Hi all, i do not compile the typ.txt file as own process, its integrated in my command line for building my maps. But every now and then, i just open the resulting .typ-file with the viewer and since some time i saw these complaining errors. In my build options to create the map i'm using the option --latin1, as Joris suggested. But nevertheless, opening the typ file with TYPviewer i get allways this error. Am 29.06.2020 um 12:47 schrieb Ticker Berkin: Hi Manfred Generally it is better to supply the TYP .txt file as an argument to mkgmap when you build your map, rather than compiling it as a separate process. Otherwise, as Joris says. Do you have a codePage specified in the file that is being ignored? [_id] ... CodePage= ... [End] Ticker On Mon, 2020-06-29 at 10:39 +, Joris Bo wrote: Hi Manfed, I encountered the same, since you must always supply the codepage on the commandline Like --code-page=65001 Or --code-page=latin1 Joris -Oorspronkelijk bericht- Van: mkgmap-dev Namens Manfred Haiduk Verzonden: maandag 29 juni 2020 12:29 Aan: Development list for mkgmap Onderwerp: [mkgmap-dev] CodePage number set to 0 after compiled Hi all, i don't know, if i had something forgotten but since some time, if i compile my style.txt with mkgmap, the resulting typ-file seems to not have any codepage number other than Zero. Only the TYPviewer complains about this, on my device (GPSMAP 476cx) or with MapSource i don't see any troubles. This is the error message the TYPviewer generates : * * Errors in the file : D:\GPS\Maps\MYGERMANY\newstyle.typ * * Unknown CodePage number: 0 TYPViewer has replaced it with 1252 If it doesn't fit, select an another CodePage number in the combobox "CodePage" Any ideas what to do ? btw i used mkgmap-r4487 to compile ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] cities*.zip extract error
Seems to be an error with all of the cities zip files. Also, if you look at the size of the files, there was something strange, because cities15000 is smaller in size than cities500 Am 02.04.2020 um 18:56 schrieb Steph: Hi, Have you got an error extracting cities*.zip files from http://download.geonames.org/export/dump/ since today ? $ unzip cities15000.zip Archive: cities15000.zip End-of-central-directory signature not found. Either this file is not a zipfile, or it constitutes one disk of a multi-part archive. In the latter case the central directory and zipfile comment will be found on the last disk(s) of this archive. unzip: cannot find zipfile directory in one of cities15000.zip or cities15000.zip.zip, and cannot find cities15000.zip.ZIP, period. So java (splitter) crash on this file… Regards Steph ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in memory calculation
Ah, now i understand Am 05.02.2020 um 22:33 schrieb Gerd Petermann: Hi Manfred, the calculation is only done when you don't use the --max-jobs option and when more than two input files are processed. Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Mittwoch, 5. Februar 2020 21:49 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Error in memory calculation Hi Gerd just did a small map job but on the console there is no print about number of max jobs. Is there a special log flag to get this print out ? What i've seen in the task manager while building the map, all 8 cpu's are used, but i don't know anything about the number of jobs ... Am 05.02.2020 um 21:35 schrieb Gerd Petermann: Hi Manfred, mkgmap contains code to estimate a suitable value for max-jobs if this parameter isn't set. This code fails and the result is that it believes that a first thread needed all available memory. This doesn't happen when the -Xms parameter in my sample call is removed, and it also doesn't happen with JRE 1.8 (both from OpenJDK and Oracle). I've not yet started to look at the details returned in class java.lang.management.MemoryPoolMXBean Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Mittwoch, 5. Februar 2020 21:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Error in memory calculation Hi Gerd i'm not sure what you are looking for. In my build environment i'm using java 1.8.0_241 (64 bit) and as my laptop have 32 Gb of memory availiable my command line to build is like this : java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar -Dlog.config=logging.properties "c:\Program Files (x86)\KartenTools\mkgmap\mkgmap.jar" and depending on which map i want to build, the occupied memory runs up nearly to 30Gb Am 05.02.2020 um 14:05 schrieb Ticker Berkin: Hi Gerd I don't have a 64bit environment or that much memory. In my normal environment, I get: $ java -Xms1500M -Xmx1540M -jar ../mkgmap.trunk/mkgmap.jar \ dummy.osm dummy.osm dummy.osm Time started: Wed Feb 05 12:56:28 GMT 2020 Setting max-jobs to 4 Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Wed Feb 05 12:56:29 GMT 2020 Total time taken: 1 second -Xmx1540M is the maximum value that allows Java to start up on my machine. With a newer version I loaded in October, but it didn't have any obvious advantages: $ /opt/jre1.8.0_231/bin/java -Xms1500M -Xmx1540M \ -jar ../mkgmap.trunk/mkgmap.jar \ dummy.osm dummy.osm dummy.osm Time started: Wed Feb 05 12:58:29 GMT 2020 Setting max-jobs to 4 Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Wed Feb 05 12:58:30 GMT 2020 Total time taken: 1 second Ticker On Fri, 2020-01-31 at 16:15 +, Gerd Petermann wrote: please try this command with openjdk 11 or 13 64Bit: java -Xms4G -Xmx10G -jar mkgmap.jar f:\osm\dummy.osm f:\osm\dummy.osm f:\osm\dummy.osm This is what I get: Time started: Fri Jan 31 17:12:53 CET 2020 Setting max-jobs to 1 Number of MapFailedExceptions: 0 To reduce the run time, consider increasing the amnount of memory available for use by mkgmap by using the Java -Xmx flag to set the memory to more than 41000 MB, providing this is less than the amount of physical memory installed. Number of ExitExceptions: 0 Time finished: Fri Jan 31 17:12:54 CET 2020 Total time taken: 1 second ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ 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 -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in memory calculation
Hi Gerd just did a small map job but on the console there is no print about number of max jobs. Is there a special log flag to get this print out ? What i've seen in the task manager while building the map, all 8 cpu's are used, but i don't know anything about the number of jobs ... Am 05.02.2020 um 21:35 schrieb Gerd Petermann: Hi Manfred, mkgmap contains code to estimate a suitable value for max-jobs if this parameter isn't set. This code fails and the result is that it believes that a first thread needed all available memory. This doesn't happen when the -Xms parameter in my sample call is removed, and it also doesn't happen with JRE 1.8 (both from OpenJDK and Oracle). I've not yet started to look at the details returned in class java.lang.management.MemoryPoolMXBean Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Mittwoch, 5. Februar 2020 21:16 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Error in memory calculation Hi Gerd i'm not sure what you are looking for. In my build environment i'm using java 1.8.0_241 (64 bit) and as my laptop have 32 Gb of memory availiable my command line to build is like this : java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar -Dlog.config=logging.properties "c:\Program Files (x86)\KartenTools\mkgmap\mkgmap.jar" and depending on which map i want to build, the occupied memory runs up nearly to 30Gb Am 05.02.2020 um 14:05 schrieb Ticker Berkin: Hi Gerd I don't have a 64bit environment or that much memory. In my normal environment, I get: $ java -Xms1500M -Xmx1540M -jar ../mkgmap.trunk/mkgmap.jar \ dummy.osm dummy.osm dummy.osm Time started: Wed Feb 05 12:56:28 GMT 2020 Setting max-jobs to 4 Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Wed Feb 05 12:56:29 GMT 2020 Total time taken: 1 second -Xmx1540M is the maximum value that allows Java to start up on my machine. With a newer version I loaded in October, but it didn't have any obvious advantages: $ /opt/jre1.8.0_231/bin/java -Xms1500M -Xmx1540M \ -jar ../mkgmap.trunk/mkgmap.jar \ dummy.osm dummy.osm dummy.osm Time started: Wed Feb 05 12:58:29 GMT 2020 Setting max-jobs to 4 Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Wed Feb 05 12:58:30 GMT 2020 Total time taken: 1 second Ticker On Fri, 2020-01-31 at 16:15 +, Gerd Petermann wrote: please try this command with openjdk 11 or 13 64Bit: java -Xms4G -Xmx10G -jar mkgmap.jar f:\osm\dummy.osm f:\osm\dummy.osm f:\osm\dummy.osm This is what I get: Time started: Fri Jan 31 17:12:53 CET 2020 Setting max-jobs to 1 Number of MapFailedExceptions: 0 To reduce the run time, consider increasing the amnount of memory available for use by mkgmap by using the Java -Xmx flag to set the memory to more than 41000 MB, providing this is less than the amount of physical memory installed. Number of ExitExceptions: 0 Time finished: Fri Jan 31 17:12:54 CET 2020 Total time taken: 1 second ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ 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 -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error in memory calculation
Hi Gerd i'm not sure what you are looking for. In my build environment i'm using java 1.8.0_241 (64 bit) and as my laptop have 32 Gb of memory availiable my command line to build is like this : java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar -Dlog.config=logging.properties "c:\Program Files (x86)\KartenTools\mkgmap\mkgmap.jar" and depending on which map i want to build, the occupied memory runs up nearly to 30Gb Am 05.02.2020 um 14:05 schrieb Ticker Berkin: Hi Gerd I don't have a 64bit environment or that much memory. In my normal environment, I get: $ java -Xms1500M -Xmx1540M -jar ../mkgmap.trunk/mkgmap.jar \ dummy.osm dummy.osm dummy.osm Time started: Wed Feb 05 12:56:28 GMT 2020 Setting max-jobs to 4 Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Wed Feb 05 12:56:29 GMT 2020 Total time taken: 1 second -Xmx1540M is the maximum value that allows Java to start up on my machine. With a newer version I loaded in October, but it didn't have any obvious advantages: $ /opt/jre1.8.0_231/bin/java -Xms1500M -Xmx1540M \ -jar ../mkgmap.trunk/mkgmap.jar \ dummy.osm dummy.osm dummy.osm Time started: Wed Feb 05 12:58:29 GMT 2020 Setting max-jobs to 4 Number of MapFailedExceptions: 0 Number of ExitExceptions: 0 Time finished: Wed Feb 05 12:58:30 GMT 2020 Total time taken: 1 second Ticker On Fri, 2020-01-31 at 16:15 +, Gerd Petermann wrote: please try this command with openjdk 11 or 13 64Bit: java -Xms4G -Xmx10G -jar mkgmap.jar f:\osm\dummy.osm f:\osm\dummy.osm f:\osm\dummy.osm This is what I get: Time started: Fri Jan 31 17:12:53 CET 2020 Setting max-jobs to 1 Number of MapFailedExceptions: 0 To reduce the run time, consider increasing the amnount of memory available for use by mkgmap by using the Java -Xmx flag to set the memory to more than 41000 MB, providing this is less than the amount of physical memory installed. Number of ExitExceptions: 0 Time finished: Fri Jan 31 17:12:54 CET 2020 Total time taken: 1 second ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter Build Failure
I have a short look to your failures. For me, it looks like you have to change the url-requests form http to https. But i don't know, where you have to change it. 'repo1.maven.org' don't want to communicate with unsecure http anymore. Am 30.01.2020 um 14:04 schrieb News: Hi Gerd Sorry. This still fails. Full info below [ivy:configure] impossible to define new type: class not found: org.apache.ivy.plugins.signer.bouncycastle.OpenPGPSignatureGenerator in [] nor Ivy classloader [ivy:configure] :: Apache Ivy 2.3.0-local-2017090712 - 2017090712 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = /home/miscellaneous/Maps/tile-splitter/splitter/ivysettings.xml resolve-compile: [ivy:retrieve] [ivy:retrieve] :: problems summary :: [ivy:retrieve] WARNINGS [ivy:retrieve] module not found: xpp3#xpp3;1.1.4c [ivy:retrieve] local: tried [ivy:retrieve] /home/user/.ivy2/local/xpp3/xpp3/1.1.4c/ivys/ivy.xml [ivy:retrieve] -- artifact xpp3#xpp3;1.1.4c!xpp3.jar: [ivy:retrieve] /home/user/.ivy2/local/xpp3/xpp3/1.1.4c/jars/xpp3.jar [ivy:retrieve] shared: tried [ivy:retrieve] /home/user/.ivy2/shared/xpp3/xpp3/1.1.4c/ivys/ivy.xml [ivy:retrieve] -- artifact xpp3#xpp3;1.1.4c!xpp3.jar: [ivy:retrieve] /home/user/.ivy2/shared/xpp3/xpp3/1.1.4c/jars/xpp3.jar [ivy:retrieve] public: tried [ivy:retrieve] http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.pom [ivy:retrieve] -- artifact xpp3#xpp3;1.1.4c!xpp3.jar: [ivy:retrieve] http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar [ivy:retrieve] mkgmap: tried [ivy:retrieve] http://ivy.mkgmap.org.uk/repo/xpp3/xpp3/1.1.4c/ivys/ivy.xml [ivy:retrieve] -- artifact xpp3#xpp3;1.1.4c!xpp3.jar: [ivy:retrieve] http://ivy.mkgmap.org.uk/repo/xpp3/xpp3/1.1.4c/jars/xpp3.jar [ivy:retrieve] :: [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: [ivy:retrieve] :: [ivy:retrieve] :: xpp3#xpp3;1.1.4c: not found [ivy:retrieve] :: [ivy:retrieve] ERRORS [ivy:retrieve] SERVER ERROR: HTTPS Required url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.pom [ivy:retrieve] SERVER ERROR: HTTPS Required url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar [ivy:retrieve] [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS BUILD FAILED /home/miscellaneous/Maps/tile-splitter/splitter/build.xml:113: impossible to resolve dependencies: resolve failed - see output for details Thanks Paul On 30/01/2020 13:10, Gerd Petermann wrote: Hi Paul, please update, see http://www.mkgmap.org.uk/websvn/revision.php?repname=splitter=596 Gerd Von: mkgmap-dev im Auftrag von News Gesendet: Donnerstag, 30. Januar 2020 13:05 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] Splitter Build Failure I recently clean reinstalled my PC (openSuSE Leap 15.1) and today was the first time I tried to build splitter and received the following errors BUILD FAILED /home/miscellaneous/Maps/tile-splitter/splitter/build.xml:95: Can't get http://repo1.maven.org/maven2/org/apache/ivy/ivy/2.2.0/ivy-2.2.0.jar to /home/miscellaneous/Maps/tile-splitter/splitter/lib/build/ivy-2.2.0.jar I changed the line in build.xml to use https instead of http and I then got past this error and received the following error snippet [ivy:retrieve] :: [ivy:retrieve] :: UNRESOLVED DEPENDENCIES :: [ivy:retrieve] :: [ivy:retrieve] :: xpp3#xpp3;1.1.4c: not found [ivy:retrieve] :: [ivy:retrieve] ERRORS [ivy:retrieve] SERVER ERROR: HTTPS Required url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.pom [ivy:retrieve] SERVER ERROR: HTTPS Required url=http://repo1.maven.org/maven2/xpp3/xpp3/1.1.4c/xpp3-1.1.4c.jar So it seems that maven.org is only accepting https connections but I can't find where to correct the above error Any suggestions? Thanks Paul ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http
Re: [mkgmap-dev] Precomp-sea (to DD8K)
Yes, you are right that only to get the area name printed on the map a transparent polygon is just an overkill. But, for me, it will not run to display the name using POI, i don`t know why. So i remember one of the first postings from Gerd regarding this, where he suggested also to make the polygon transparent. And this worked for me in my surrounding. May be, i will do another try to get the POI running Am 15.12.2019 um 16:07 schrieb David: Hi DD8K, Using a transparent polygon just to display a POI is a solution but there might be another one. Is it possible to play with a rule in polygons and points style files and, perhaps, in combination with pois-to-areas-placement ? 0x3d seems to be for large lake (77-250 km2) as for Garmin map Europe. 0x3b and 0x45 are defined as blue-unknown in cgpsmapper doc. Both are the limits of lake types range [0x3c 0x44]. There is also 0x29 blue-unknown between ocean and sea types. For bay, the POI type is 0x6503. David ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Precomp-sea problem solved
Hi all inspired from the discussion about polygon type 0x3d i made some tests yesterday and modified the polygon to be transparent. The data looks like this : [_polygon] Type=0x3d ;GRMN_TYPE: Water Areas/LAKE_30MI, LARGE_LAKE/Large lake, typically between 30 and 500 sq mi in area/Non NT String1=0x01, String2=0x02,Bucht String3=0x04,Bay String4=0x03,Baai String5=0x09, ExtendedLabels=Y FontStyle=NormalFont CustomColor=No Xpm="32 32 2 1" "! c #FF" " c none" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " ;12345678901234567890123456789012 [end] The advantage of this solution is that the name of all bay areas are written in the map. If you completely omit the polygon 0x3d you will not see the names of these areas (tested on map source with the west coast of ireland) Am 14.12.2019 um 22:15 schrieb David: Hi Gerd, Thank you for you to point me about the 0x3d polygon type used for bay. I removed it from my polygon style file and the result is good. I still cannot be able to compute any route with BaseCamp (MacOs). Strangely, the combo box of transport option is greyed except when I select « direct flight ». To create the map I use the option « route » without any « check-routing-island-len ». Is this option silently on with a default value ? All the best, David ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Alternative Source for osm files
Could this be something related with secure or non secure url ? The download with the opere browser is ready whilst the firefox browser still says, more than 1 hour to load Am 08.12.2019 um 19:17 schrieb Gerd Petermann: Hi Manfred, I've never seen performance problems with geofabrik, but https://extract.bbbike.org/ also provides downloads in osm.pbf format. I have no idea what tools they use, so data at polygon boundaries may not be complete. Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Sonntag, 8. Dezember 2019 18:53 An: Development list for mkgmap Betreff: [mkgmap-dev] Alternative Source for osm files Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. I have the feeling, that the download area from geofabrik is extremely throttled, may be due to the huge traffic from all over the world. And if they are really the only source for the files, than i have to live with. Any solutions ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Alternative Source for osm files
May be it is for me browser dependent. I started this afternoon the download of germany with Firefox, it gives me an average download rate of 160 kb/s. When it has reached nearly 50 percent of data, i started a second download for this region with opera, and guess what, the opera download overruns the one from firefox and will be ready earlier than the other. So i dont know, what is wrong with the firefox download ? Am 08.12.2019 um 19:17 schrieb Gerd Petermann: Hi Manfred, I've never seen performance problems with geofabrik, but https://extract.bbbike.org/ also provides downloads in osm.pbf format. I have no idea what tools they use, so data at polygon boundaries may not be complete. Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Sonntag, 8. Dezember 2019 18:53 An: Development list for mkgmap Betreff: [mkgmap-dev] Alternative Source for osm files Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. I have the feeling, that the download area from geofabrik is extremely throttled, may be due to the huge traffic from all over the world. And if they are really the only source for the files, than i have to live with. Any solutions ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Alternative Source for osm files
Hi all i just wondered, if there is an alternative source to download osm-files used by mkgmap. I have the feeling, that the download area from geofabrik is extremely throttled, may be due to the huge traffic from all over the world. And if they are really the only source for the files, than i have to live with. Any solutions ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] New branch for default typ file
Hi Gerd i can remember that some time ago i stumbled also about this fact and i asked the community. I don't remember who gave me the hint but after i've changed the colour into some kind of blue for polygon type 0x3d, it changed to be OK from that time on Am 06.12.2019 um 09:17 schrieb Gerd Petermann: Hi Ticker, I've learned that polygon type 0x3d (natural=bay) in mapnik typ is wrong. It renders as a gray area and may hide the sea below. I am not sure what the correction is. If possible I would use "transparent" without any colour, else the same as 0x32. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 5. Dezember 2019 11:20 An: mkgmap development Betreff: Re: [mkgmap-dev] New branch for default typ file Hi Gerd I think it would be good if the files from branches/default-typ/resources/typ-files were put into trunk and, in build.xml, after: this is added: Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] crude routing of my gpsmap 276Cx
Hi this afternoon i'm thinking about to add a rule in my style something like this : if access=destination and maxweight=xxx remove the tag access=destination ? Do you think its a good way to fix that problem if some garmin devices don't look at all tags ( the ones which are specially designed for camper, busses and lorries should do that) ? For my opinion the used tags for that street are ok as it is not allowed for cars havier than 7.5t to use that street Am 26.09.2019 um 10:31 schrieb Gerd Petermann: Hi Manfred, Just to make that clear: I think that the long route is correct given the tags of the mentioned ways if the vehicle is a car. So, your first goal should be to correct the tagging. Gerd Von: mkgmap-dev im Auftrag von manfred.haiduk Gesendet: Donnerstag, 26. September 2019 10:20 An: Development list for mkgmap; dd...@gmx.de Betreff: Re: [mkgmap-dev] crude routing of my gpsmap 276Cx Thank you for the information. I will try this later this week and keep you informed. BTW, i can remember some years ago when i have not used OSM Data on may Garmin but on a smartfone navigation system with OSM, there was the same fault on that device with a long detour. But after some data updates the routing failure on that device was gone Von meinem Samsung Gerät gesendet. Ursprüngliche Nachricht Von: Gerd Petermann Datum: 26.09.2019 09:52 (GMT+01:00) An: Development list for mkgmap , dd...@gmx.de Betreff: Re: [mkgmap-dev] crude routing of my gpsmap 276Cx Hi Manfred, I don't know the actual signs and I don't care if the tagging is right or wrong. At least the combination of bicycle=yes and foot=no on https://www.openstreetmap.org/way/25285589 looks very wrong: bicycle=yes fixme=check access rules foot=no highway=tertiary maxspeed=30 maxweight=7.5 name=Brandenberger Straße ref=K 30 Anyway, it seems that mkgmap sets the correct flags for the road, the Garmin algo seems to simply ignore the "no-through-route" flag when the detour is too long. I've tried this with a sample file where the shortest route goes through a road with access=destination + highway=residential and the longer route just has ways with highway=residential. As long as the detour is rather small Mapsource takes the longer (allowed) route when using the car profile. All other profiles seem to always use the shorter route. So, either something is wrong in the map data (problem in mkgmap) or something is wrong in the Garmin algo. Please try if you can reproduce the long route using a map created with mkgmap r4292 and the default style coming with that version. Gerd Von: mkgmap-dev im Auftrag von manfred.haiduk Gesendet: Donnerstag, 26. September 2019 09:14 An: Development list for mkgmap; dd...@gmx.de Betreff: Re: [mkgmap-dev] crude routing of my gpsmap 276Cx For your additional information, i think the tag access=destination is to be seen with the additional tag for weight limit, as the street is not allowed to be used for cars heavier than 7.5 tons Von meinem Samsung Gerät gesendet. Ursprüngliche Nachricht Von: Gerd Petermann Datum: 26.09.2019 08:55 (GMT+01:00) An: Development list for mkgmap , dd...@gmx.de Betreff: Re: [mkgmap-dev] crude routing of my gpsmap 276Cx Hi Manfred, I tried to reproduce your results with BC but I get a different route. at the moment I wonder why Mapsource shows the shorter route when using car/motorcycle. The ways https://www.openstreetmap.org/way/25285586 and https://www.openstreetmap.org/way/25285589 both have the tag access=destination, so my understanding is that cars should not be routed through them, but this seems to be ignored. I'll have to find out why. Gerd Von: DD8KQ Gesendet: Mittwoch, 25. September 2019 14:53 An: Development list for mkgmap; Gerd Petermann Betreff: Re: [mkgmap-dev] crude routing of my gpsmap 276Cx Hi Gerd it's really weird. Trying this with MapSource you are right, there is no long detour. But, then, i tried the same with BaseCamp and you know what, BaseCamp produced on my Laptop this detour, see attached picture Test2. And just for testing, i tried the same area on a Smartfone running the Navigator App with OSM maps, and this progromm is routing the same detour, see picture screenshot. So for me there must be something in the OSM Source regarding the street K30 which will cause the strange routing. But my experience is too small to figure it out Am 25.09.2019 um 11:12 schrieb Gerd Petermann: Hi Manfred, No idea. I cannot reproduce the result with the default style in Mapsource. I tried with vehicle car as well as with cycling or pedestrian, I never get the long detour. Can you reproduce it with Mapsource? If yes, please provide more details about the routing settings. Von: mkgmap-dev im Auftrag von DD8KQ Gesendet
Re: [mkgmap-dev] Possible Rendering Error on GPSMAP 276Cx
Hi i also thought about this, but if i choose in MapSource the option 'Kartenfunktion' the boundary of the highlighted tile is far away from that area. And the problem is only to be seen on the device and not in MapSource. For the other hint i have to figure it out, creating the gmapsupp with mkgmap Am 02.09.2019 um 19:55 schrieb Gerd Petermann: Hi Manfred, maybe there is a tile boundary? What do you get when you create the gmapsupp with mkgmap? Gerd Von: mkgmap-dev im Auftrag von DD8KQ Gesendet: Sonntag, 1. September 2019 15:07 An: Development list for mkgmap Betreff: [mkgmap-dev] Possible Rendering Error on GPSMAP 276Cx Hi all may be someone has an idea how this could happen: According to the screenshot of my device GPSMAP 276Cx you will see next to the cursor a white gap in the polygon fields and also some strange arcs on the nearby streets which will prevent the device from routing through. I checked this area on my PC with Mapsource and could not find any problems there. So it seems, it might be an error in the device or in building the image tiles by MapSource. Any comments ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 131, Issue 6
Thanks for all of your experiences Am 23.06.2019 um 22:20 schrieb John Thorn: In a TYP file that I inherited there is this comment : Basecamp will not display 17, 2c and 30=3f (dunno why!) In my experience 14 Railroad can cause problems too. On Sun, 23 Jun 2019 at 12:00, <mkgmap-dev-requ...@lists.mkgmap.org.uk> wrote: Send mkgmap-dev mailing list submissions to mkgmap-dev@lists.mkgmap.org.uk To subscribe or unsubscribe via the World Wide Web, visit http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev or, via email, send a message with subject or body 'help' to mkgmap-dev-requ...@lists.mkgmap.org.uk You can reach the person managing the list at mkgmap-dev-ow...@lists.mkgmap.org.uk When replying, please edit your Subject line so it is more specific than "Re: Contents of mkgmap-dev digest..." Today's Topics: 1. Polyline code 0x30 won't show up on maps (Manfred Haiduk) 2. Re: Polyline code 0x30 won't show up on maps (Ticker Berkin) -- Forwarded message -- From: Manfred Haiduk <manfred.hai...@freenet.de> To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Cc: Bcc: Date: Sat, 22 Jun 2019 22:51:08 +0200 Subject: [mkgmap-dev] Polyline code 0x30 won't show up on maps Hi does anybody know, why a polyline with code 0x30 won't show up on the map, neither in map source nor on my device GPSMAP 276Cx ? Or is there a of line codes, which are not rendered in a map ? -- Forwarded message -- From: Ticker Berkin <rwb-mkg...@jagit.co.uk> To: Development list for mkgmap <mkgmap-dev@lists.mkgmap.org.uk> Cc: Bcc: Date: Sun, 23 Jun 2019 09:38:09 +0100 Subject: Re: [mkgmap-dev] Polyline code 0x30 won't show up on maps Hi I found that, without TYP definition, line 0x30 didn't show on eTrex 30x or eTrex Legend HCx. They were there; hovering the cursor in the right place allowed them to be selected. 0x30 - 0x4f behaved like this Ticker On Sat, 2019-06-22 at 22:51 +0200, Manfred Haiduk wrote: > Hi > > does anybody know, why a polyline with code 0x30 won't show up on the > map, neither in map source nor on my device GPSMAP 276Cx ? Or is > there a > of line codes, which are not rendered in a map ? > > ___ > 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- ##### Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] typfile curiosity
Normaly, i prefer also the single line form. But in case you use the typ viewer to change something in the typ file and you want to write it back, the typ viewer changes all single line forms into the other way :-(. And that happans again to me somme days before and until i noticed that, i have build some maps with wrong POIs Am 16.04.2019 um 23:38 schrieb Steve Ratcliffe: Hi i just stumbled again about a curious effect of the built-in typ-compiler from mkgmap. Just figured out that hex-ids for points, which are built in the way Type = 0x108, SubType = 02 or equal are mixed up after the compile to 0x00102 ? I can avoid this by building the hex-id only in one line, i.e Type = 0x10802. Its not for all of the ids, may be only for points with ids > 0x100. Any idea ? When a type is written as 0x10802 it doesn't mean that the type is 0x108, since types are one byte. The first '1' means that it is an extended (also called marine) type, with type=0x8 and subtype=0x2. When you write Type=0x102 then that means Type=0x1, SubType=0x02, just as Type=0x411 means Type=0x4, SubType=0x11 The original way of writing it would be: Type=0x08 SubType=0x02 Marine=Y The Marine=Y isn't supported in the TYP compiler, since I don't think anyone write TYP files using that notation. It could be added if there really are lots of TYP files out there using it. I'd recomend always using the single line form. Steve ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] typfile curiosity
Hi i just stumbled again about a curious effect of the built-in typ-compiler from mkgmap. Just figured out that hex-ids for points, which are built in the way Type = 0x108, SubType = 02 or equal are mixed up after the compile to 0x00102 ? I can avoid this by building the hex-id only in one line, i.e Type = 0x10802. Its not for all of the ids, may be only for points with ids > 0x100. Any idea ? -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Curious behaviour of map text
Hi Gerd
as you suggested, i added the continue statement to the directive, but,
its still not working properly. Without that line, i can see nearly at
all relevant zoom-levels street and city names both on mapsource or my
GPSMAP 276Cx, with that line, on MapSource the city names will only be
displayed at lower zoom levels (let say starting at 1km, 1.5 km and
above) but on device they still are not visible.
BTW, as the housenumbers are shown on the device with really big
letters, i will forgot this option as it will make the maps on my device
nearly unreadable :'(
But anyway, its strange ...
Am 29.03.2019 um 06:18 schrieb Gerd Petermann:
Hi Manfred,
when you add that rule at the beginning I would expect that all points which
have the tag addr:housenumber are added as 0x1e04
and since you did not use continue you should not expect any other details.
Still, your rule should not change street names.
Gerd
Von: mkgmap-dev im Auftrag von Manfred
Haiduk
Gesendet: Donnerstag, 28. März 2019 22:44
An: Development list for mkgmap
Betreff: [mkgmap-dev] Curious behaviour of map text
Hi alllet say
i'm experimenting with housenumber display in my maps. To do this, i
added in my point style file this statement :
addr:housenumber=* { set name='${addr:housenumber}' } [0x1e04 resolution
24 ]
But if i do this, all other text is vanished, i.e street names, village
names etc, only housenumbers are displayed both in map source and on my
device.
Any idea whats going wrong ?
regards Manfred
___
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
--
#
Viele Grüße und 73 de Manfred Haiduk, DD8KQ
e-mail mhai...@t-online.de dd...@gmx.de
#
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] where are the house numbers gone?
rag von Team Rebenbummler mailto:rebenbumm...@cafekurzweil.de > Gesendet: Dienstag, 26. März 2019 21:25 An: mkgmap-dev@lists.mkgmap.org.uk mailto:mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] where are the house numbers gone? Hi … I have a strange behavior, the maps are generated, but no house numbers in the map. When the device searches for the address, it can find the street but not the house number. The map is build with the following statement java -Xmx12288m -Xms5120m -jar mkgmap-r4283\mkgmap.jar --gmapsupp --index --housenumbers --output-dir=C:\Users\Richard\Documents\work\map --mapname=5917 --description=Freiburg-Regbez --family-id=59170001 --family-name=Freiburg-Regbez --max-jobs --route --drive-on=detect,right --make-opposite-cycleways --bounds=C:\Users\Richard\Downloads\bounds-latest.zip --transparent --verbose C:\Users\Richard\Documents\work\splitter\59170001*.o5m Any hint what is going wrong? The house numbers where there in the past. Thanks Richard ___ 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 ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Possible sea.zip Problem
Thank you for the hint, Nick. That was the reason. My typ-file is derived from default.typ and there was the wrong colour Am 22.03.2019 um 14:15 schrieb osm@pinns: Hi The 'culprit' is natural=bay r Nick On 22/03/2019 12:37, Manfred Haiduk wrote: Hi all as i do have since short time a new laptop with huge amount of memory and a big cpu, i was trying to build a garmin map for whole europe, because i was curious to see other countries beside of central europe.And while doing this, i found a possible error in the sea.zip file, which i got from osm.thkukuk.de/data. If you look at the screenshot attached you will see some grey polygons, which is named 'meer' as the other blue areas but is drawn in the colour of the background. So i assume an error in the sea-file or in the boundary files ? Any one with an idea whats going wrong there ? my build script is build like this : del /q .\out\MYEUROPE\ pause del /q "d:\GPS\Kartentools\MapCreation\mkgmap.log*" java -Xmx3m -XX:-UseGCOverheadLimit -ea -jar -Dlog.config=logging.properties "c:\Program Files (x86)\KartenTools\mkgmap\mkgmap.jar" --location-autofill=is_in,nearest --mapname=7001 --family-id=7000 .\styles\newstyle.txt --series-name="MY OSM" --family-name="OpenStreetmap" --country-name=EUROPE --country-abbr=ALL --area-name=ALL --overview-mapname="overview" --latin1 --style-file=.\styles --style=newstyle --max-jobs --keep-going --check-roundabouts --drive-on=detect,right --output-dir=.\out\MYEUROPE --index --bounds=.\bounds_latest --route --name-tag-list=name,place_name,loc_name --housenumbers --x-split-name-index --add-pois-to-areas --link-pois-to-ways --process-destination --process-exits --precomp-sea=.\sea_latest --tdbfile --draw-priority=10 -c .\data\EUROPE\template.args --description=MYEUR --remove-ovm-work-files=true copy newstyle.typ .\styles move newstyle.typ .\out\MYEUROPE del /q "c:\Users\mhaiduk\AppData\Roaming\Garmin\MapSource\TileCache\" shutdown.exe /s ___ 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 -- ##### Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Openstreetmap URL
I don't think it's worth to change something like this. If you klick onto that link, you will be redirected to the correct https (at least within the Firefox-Browser) Am 28.11.2018 um 14:12 schrieb Gerd Petermann: Hi Nick, I am not sure what to do with that. The svn repo is full of urls starting with http: Many of them are in comments and point to other software. Some are in the distributed files, e.g. the README or the style files. The attached patch changes only those in the java sources which are written to the log or the img files. Gerd Von: mkgmap-dev im Auftrag von nwillink Gesendet: Mittwoch, 28. November 2018 10:10 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Openstreetmap URL Hi Gert Just a minor observation SEVERE (StyledConverter):args\16620002.o5m: Found multiple points with equal coords as CoordPOI at http://www.openstreetmap.org/?mlat=50.764580=-3.427609=17 Perhaps all openstreetmap urls included in an error message should precede with https not http? Regards Nick -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ 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 -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Server Down ?
I think, thats the default entry page from the server, no content but it states only : It works! This is the default web page for this server. The web server software is running but no content has been added, yet. May be, they have had a severe error and they try to start a new server now with this address ? Am 11.10.2018 um 19:18 schrieb osm@pinns: Hi The following seems very similar and exists http://osm.pleiades.uni-wuppertal.de/ On 11/10/2018 11:31, Manfred Haiduk wrote: From the url i guess it should be the University of Wuppertal Am 11.10.2018 um 12:17 schrieb Arndt Röhrig: Hi @all, the server is still down. Who is the owner? How do you get this data now? Helpless greets Arndt Manfred Haiduk hat am 6. Oktober 2018 um 16:55 geschrieben: Hi all today i tried to get sea.zip and bounds.zip files from http://osm2.pleiades.uni-wuppertal.de/sea/latest/ and i get no connection. Is this server down or do we have to use another address ? ___ 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 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] TYP compiling problem
Hi i have noticed the same problembut without making checks with Win7 (as i do not have any PC with this operating system any more). My workaround for this problem is, make changes only in the txt-typ-file and let mkgmap compile it into a "typ" file. Only use the TypViewer to visually check my changes Am 13.09.2018 um 22:13 schrieb ValentinAK: Hi. I have a problem with TYPViewer v4.5.43 in Windows 10. There is a file change while saving. I get mixing icons and code types after Mkgmap Render! But in Windows 7 it works without this error. I began to try to understand this. And what I found out: TYPViewer v4.5.43 in Windows 7 writes the point code as Type = 0x11711 for example. A Windows 10 records the same point as Type = 0x117 SubType = 0x11 Mkgmap does not support this description correctly and compiles this point into a TYP file like: Type = 0x001 SubType = 0x11 How to eliminate this trouble when I use Windows 10? There are two files in the attachment: the original by Win7 and the saved by Win10. Thank you! original.txt <http://gis.19327.n8.nabble.com/file/t318348/original.txt> saved.txt <http://gis.19327.n8.nabble.com/file/t318348/saved.txt> -- Sent from: http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] osmupdate
May be something related to DSVGO, see green banner on top of the download site The OpenStreetMap data files provided on this server do not contain the user names, user IDs and changeset IDs of the OSM objects. These metadata fields contain personal information about the OpenStreetMap contributors and are subject to data protection regulations in the European Union. Please note that these regulations apply even to processing that happens outside the European Union because some OpenStreetMap contributors live in the European Union. Extracts with full metadata are available to OpenStreetMap contributors only. Am 24.05.2018 um 11:00 schrieb lig fietser: Thanks Henning, I updated wget but it still does not work. My workflow: I have downloaded the europe extract from http://download.geofabrik.de I use osmconvert to cut a section from it (benelux.o5m) and with this file I weekly update it with osmupdate. Until last week this always went well but not anymore. Any idea how to solve this? Van: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> namens Henning Scholland <o...@hscholland.de> Verzonden: donderdag 24 mei 2018 00:38:10 Aan: Development list for mkgmap CC: Development list for mkgmap Onderwerp: Re: [mkgmap-dev] osmupdate You need to update wget to latest version as diffs are only served by https and older wget can't use local certificate store. Met the same problem recently... Henning Sent from BlueMail On 24 May 2018, at 14:01, lig fietser <ligfiet...@hotmail.com> wrote: Since recently I cannot update my osm maps anymore with osmupdate. Error: Could not get the newest daily timestamp from the Internet. Anyone familiar with this isssue and how to fix this? 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 -- # Viele Grüße und 73 de Manfred Haiduk, DD8KQ e-mail mhai...@t-online.de dd...@gmx.de # ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
