Re: [mkgmap-dev] Help with registry for Basecamp
Hi Diego,Rather than having to edit the registry use the –gmapi option in mkgmap which will create a folder with a .gmap extension. Copy or move this folder to C:\ProgramData\Garmin\Maps and the map will be visible to Basecamp. Note ProgramData is a hidden folder. This avoids having to edit the registry or create reg files.CheersDave From: dd...@gmx.deSent: 26 February 2023 18:54To: mkgmap-dev@lists.mkgmap.org.ukReply to: mkgmap-dev@lists.mkgmap.org.ukSubject: Re: [mkgmap-dev] Help with registry for Basecamp Hi allfor all registration stuff concerning mapinstallation for mapsource and therefore also for Basecamp i use a programm called MapsetToolkit.Its working on all Windows Versions 10 and 11 since i use maps created by mkgmap Am 26.02.2023 um 17:21 schrieb skelter helter: Hello I need some help with this email from Eric sent here on the list some weeks ago: If you are creating mkgmap tiles and you do not need to distribute your map to others, then the NSIS installer is not required. Initial installation requires importing registration data (.reg file). Creating an NSIS installer takes time and then installing setup.exe also takes time. For instance: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Garmin\MapSource\Families\BIKE_Benelux] "ID"=hex:4a,9c "IDX"="G:\\BaseCamp\\BIKE_Benelux\\4001.mdx" "MDR"="G:\\BaseCamp\\BIKE_Benelux\\4001_mdr.img" "TYP"="G:\\BaseCamp\\BIKE_Benelux\\40010.TYP" [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Garmin\MapSource\Families\BIKE_Benelux\1] "BMAP"="G:\\BaseCamp\\BIKE_Benelux\\4001.img" "LOC"="G:\\BaseCamp\\BIKE_Benelux" "TDB"="G:\\BaseCamp\\BIKE_Benelux\\4001.tdb" Is there a way to create the REG file with Mkgmap, or do I have to create it by myself after generating the map ? If so, what is the meaning of the ID value and how do I choose the right one ? Thank you !! Diego Da: mkgmap-dev per conto di mkgmap-dev-requ...@lists.mkgmap.org.uk Inviato: giovedì 2 febbraio 2023 12:00 A: mkgmap-dev@lists.mkgmap.org.uk Oggetto: mkgmap-dev Digest, Vol 175, Issue 3 Send mkgmap-dev mailing list submissions to mkgmap-dev@lists.mkgmap.org.uk To subscribe or unsubscribe via the World Wide Web, visit https://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..." ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] NSIS option for Basecamp
Hi Diego, Further to Eric’s comments regarding a NSIS installer: On a windows machine if you use the gmapi option a folder with a .gmap extension is created with all the information regarding the map and tiles. This type of map does not use the registry, to get this map to show in Basecamp you need to copy or move the complete folder to "C:\ProgramData\Garmin\Maps". C:\ProgramData is a hidden folder so you will have to select ‘Show hidden items’ under ‘View’ in Explorer. Or you could use JaVaWa GMTK from this site https://www.javawa.nl/gmtk_en.html to install a .gmapi file by browsing to the created . gmap folder. The program is no longer supported but still works fine, it will also flag up errors in your maps, such as duplicated Family Ids, and repair some of them. Cheers, Dave From: mkgmap-dev On Behalf Of eric.detachm...@gmail.com Sent: Thursday, 2 February 2023 12:56 pm To: 'Development list for mkgmap' Subject: Re: [mkgmap-dev] NSIS option for Basecamp Hi Diego, Following up on Dave: MapInstall handles new Maps and Maps already installed on device differently. For Maps already installed all tiles are initially selected. OT (1): IMO it’s best practice to install Maps on SD-card, not in Device Memory. Reinstalling Maps on an SD card over and over leads to fragmentation of the SD card. To resolve (IMO): I delete folder “H:\Garmin\” by Windows Explorer before starting Basecamp (BaseCamp sometimes forgets to refresh the content). This is effectively a defrag and harmless (formatting is not harmless). And – perhaps (?!) – defragmenting also has a positive effect on performance. Now the map tiles are not selected as this is a new map. OT (2): If you are creating mkgmap tiles and you do not need to distribute your map to others, then the NSIS installer is not required. Initial installation requires importing registration data (.reg file). Creating an NSIS installer takes time and then installing setup.exe also takes time. For instance: Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Garmin\MapSource\Families\BIKE_Benelux] "ID"=hex:4a,9c "IDX"="G:\\BaseCamp\\BIKE_Benelux\\4001.mdx" "MDR"="G:\\BaseCamp\\BIKE_Benelux\\4001_mdr.img" "TYP"="G:\\BaseCamp\\BIKE_Benelux\\40010.TYP" [HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Garmin\MapSource\Families\BIKE_Benelux\1] "BMAP"="G:\\BaseCamp\\BIKE_Benelux\\4001.img" "LOC"="G:\\BaseCamp\\BIKE_Benelux" "TDB"="G:\\BaseCamp\\BIKE_Benelux\\4001.tdb" Regards, Eric From: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> > On Behalf Of Dave Jackman Sent: donderdag 2 februari 2023 09:34 To: Development list for mkgmap mailto:mkgmap-dev@lists.mkgmap.org.uk> > Subject: Re: [mkgmap-dev] NSIS option for Basecamp Hi Diego, You can right click on the tiles already selected to deselect them and then left click to select the tiles you want. You can click and hold the button down and drag to select/deselect multiple tiles. Hope this helps. Cheers Dave From: hskel...@hotmail.com <mailto:hskel...@hotmail.com> Sent: 2 February 2023 10:21 To: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> Reply to: mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk> Subject: [mkgmap-dev] NSIS option for Basecamp Hello Eric and Gerd, thanks for your reply. I create different tiles setting the Splitter to 1.600.000, then I add clipped contours and DEM with Mkgmap. I transfer the map with Basecamp/Mapinstall, both in the latest version available. When I click the button for a partial install, I can choose my map or the other I have installed. If I choose one of the others, such as Freizeitkarte, I get a full version of the map (I am working on Italy) divided into tiles, and I can select which ones I want to transfer to the device. If I do the same with my map, I get it already completely selected: I see the tiles, but I cannot select some of them, so my only option is to trasfer full Italy to the device. I tried many times and in one of them I was able to select the tiles... but I don't know how ! And then the map on the device wasn't complete: I had the selected area, but the contours and the shaded reliefs were not there. I am trying to do a partial selection because my map is slow when I use it on my Garmin: when I scroll the map I have to wait a few seconds to see the image, while with Freizeitkarte the loading is almost immediate. For this reason I would like to try to upload a small part, to have a lighter file. I also tried to edit my style files, removing all the objects I don't need, but it doesn't help... 🙁 Diego
Re: [mkgmap-dev] NSIS option for Basecamp
Hi Diego,You can right click on the tiles already selected to deselect them and then left click to select the tiles you want. You can click and hold the button down and drag to select/deselect multiple tiles.Hope this helps.Cheers Dave From: hskel...@hotmail.comSent: 2 February 2023 10:21To: mkgmap-dev@lists.mkgmap.org.ukReply to: mkgmap-dev@lists.mkgmap.org.ukSubject: [mkgmap-dev] NSIS option for Basecamp Hello Eric and Gerd, thanks for your reply. I create different tiles setting the Splitter to 1.600.000, then I add clipped contours and DEM with Mkgmap. I transfer the map with Basecamp/Mapinstall, both in the latest version available. When I click the button for a partial install, I can choose my map or the other I have installed. If I choose one of the others, such as Freizeitkarte, I get a full version of the map (I am working on Italy) divided into tiles, and I can select which ones I want to transfer to the device. If I do the same with my map, I get it already completely selected: I see the tiles, but I cannot select some of them, so my only option is to trasfer full Italy to the device. I tried many times and in one of them I was able to select the tiles... but I don't know how ! And then the map on the device wasn't complete: I had the selected area, but the contours and the shaded reliefs were not there. I am trying to do a partial selection because my map is slow when I use it on my Garmin: when I scroll the map I have to wait a few seconds to see the image, while with Freizeitkarte the loading is almost immediate. For this reason I would like to try to upload a small part, to have a lighter file. I also tried to edit my style files, removing all the objects I don't need, but it doesn't help... 🙁 Diego Da: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> per conto di mkgmap-dev-requ...@lists.mkgmap.org.uk <mkgmap-dev-requ...@lists.mkgmap.org.uk> Inviato: mercoledì 1 febbraio 2023 12:00 A: mkgmap-dev@lists.mkgmap.org.uk <mkgmap-dev@lists.mkgmap.org.uk> Oggetto: mkgmap-dev Digest, Vol 175, Issue 1 Send mkgmap-dev mailing list submissions to mkgmap-dev@lists.mkgmap.org.uk To subscribe or unsubscribe via the World Wide Web, visit https://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..." ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Compile error
I just saw your other email that the next release of mkgmap includes Carlos's patch. I've downloaded it. Thanks again to everyone on this list. Dave On Mon, May 2, 2022 at 10:43 PM Dave Swarthout wrote: > > OMG! > > I copied parts of my batch file for Thailand maps to make this batch > file when I came back to the U.S. but forgot to use the splitter > output file as inputs. I never noticed my omission. It works fine now: > > java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566 > --name-tag-list=name,alt_name,loc_name,int_name --description="Eugene" > splitter\*.o5m "C:\Users\Alask\Dropbox > (Personal)\Mapping\24983djs.TYP" > > Sorry for wasting your time. I must say, however, that the error > message I got didn't help diagnose or solve that problem. Maybe that > could be looked at and improved. > > Thanks, Gerd. > > On Mon, May 2, 2022 at 10:22 PM wrote: > > > > Hi Dave, > > > > I just double checked what you wrote before and it seems you feed mkgmap > > with > > the large file C:\Users\alask\Downloads\Maps\Eugene.osm ? > > You also posted a log that shows that you use splitter with the same file. > > So, change your mkgmap command to actually use the output from splitter and > > your > > problem shoud be solved. There is probably no need to use the small > > --max-nodes value. > > > > Gerd > > > > > > > > Von: Dave Swarthout > > Gesendet: Montag, 2. Mai 2022 23:13 > > An: Gerd Petermann > > Cc: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Compile error > > > > I don't create an overview map. No tiles show up with zero size nor > > are any of the 56 tiles larger than about 159,000 nodes. Carlos has > > offered a patch to indicate the problem tile but I'm on a Windows 10 > > system and am not willing to set up a Linux environment just to patch > > my mkgmap program. > > > > Is there a debugging tool or method that you can suggest? > > > > > > On Mon, May 2, 2022 at 11:10 AM Gerd Petermann > > wrote: > > > > > > Hi Dave, > > > > > > I would expect a tile with 0 bytes. Maybe you get this message for the > > > overview map? > > > > > > Gerd > > > > > > > > > Von: Dave Swarthout > > > Gesendet: Montag, 2. Mai 2022 20:02 > > > An: Gerd Petermann > > > Cc: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] Compile error > > > > > > Thanks, Gerd, > > > > > > I get the same error when using the default syle. In DJS.cfg, I placed > > > this line: > > > style-file=C:\Users\Alask\Documents\mkgmap\examples\styles\default. That > > > is correct usage, right? > > > > > > Another list member told me to look for the offending tile in order to > > > manually split it, however, all the tiles look alike to me in terms of > > > size. How would I tell which tile is the "bad one" that's causing this > > > RGN error? > > > > > > You mentioned adjusting some mkgmap parameters that would reduce the size > > > and/or complexity of the map I'm trying to create. The descriptive text > > > in the Options file for directives about processing lines and polygons > > > doesn't make clear how to reduce the amount of information they handle— > > > can you offer any suggestions? > > > > > > Thanks, > > > > > > Dave > > > > > > > > > > > > On Mon, May 2, 2022 at 9:23 AM Gerd Petermann > > > mailto:gpetermann_muenc...@hotmail.com>> > > > wrote: > > > Hi Dave, > > > > > > the max-nodes value is already very small, so maybe something in mkgmap > > > goes very wrong. > > > We probably need the input file (*.o5m) for the tile that fails and the > > > style unless you can reproduce the > > > problem also with the default style. > > > > > > Gerd > > > > > > > > > Von: Dave Swarthout > > > mailto:daveswarth...@gmail.com>> > > > Gesendet: Montag, 2. Mai 2022 18:08 > > > An: Gerd Petermann > > > Cc: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] Compile error > > > > > > Reducing the node count means I was adjusting the max-nodes value; I had > > > been using a value of 160,000
Re: [mkgmap-dev] Compile error
OMG! I copied parts of my batch file for Thailand maps to make this batch file when I came back to the U.S. but forgot to use the splitter output file as inputs. I never noticed my omission. It works fine now: java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566 --name-tag-list=name,alt_name,loc_name,int_name --description="Eugene" splitter\*.o5m "C:\Users\Alask\Dropbox (Personal)\Mapping\24983djs.TYP" Sorry for wasting your time. I must say, however, that the error message I got didn't help diagnose or solve that problem. Maybe that could be looked at and improved. Thanks, Gerd. On Mon, May 2, 2022 at 10:22 PM wrote: > > Hi Dave, > > I just double checked what you wrote before and it seems you feed mkgmap with > the large file C:\Users\alask\Downloads\Maps\Eugene.osm ? > You also posted a log that shows that you use splitter with the same file. > So, change your mkgmap command to actually use the output from splitter and > your > problem shoud be solved. There is probably no need to use the small > --max-nodes value. > > Gerd > > > > Von: Dave Swarthout > Gesendet: Montag, 2. Mai 2022 23:13 > An: Gerd Petermann > Cc: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Compile error > > I don't create an overview map. No tiles show up with zero size nor > are any of the 56 tiles larger than about 159,000 nodes. Carlos has > offered a patch to indicate the problem tile but I'm on a Windows 10 > system and am not willing to set up a Linux environment just to patch > my mkgmap program. > > Is there a debugging tool or method that you can suggest? > > > On Mon, May 2, 2022 at 11:10 AM Gerd Petermann > wrote: > > > > Hi Dave, > > > > I would expect a tile with 0 bytes. Maybe you get this message for the > > overview map? > > > > Gerd > > > > > > Von: Dave Swarthout > > Gesendet: Montag, 2. Mai 2022 20:02 > > An: Gerd Petermann > > Cc: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Compile error > > > > Thanks, Gerd, > > > > I get the same error when using the default syle. In DJS.cfg, I placed this > > line: > > style-file=C:\Users\Alask\Documents\mkgmap\examples\styles\default. That is > > correct usage, right? > > > > Another list member told me to look for the offending tile in order to > > manually split it, however, all the tiles look alike to me in terms of > > size. How would I tell which tile is the "bad one" that's causing this RGN > > error? > > > > You mentioned adjusting some mkgmap parameters that would reduce the size > > and/or complexity of the map I'm trying to create. The descriptive text in > > the Options file for directives about processing lines and polygons doesn't > > make clear how to reduce the amount of information they handle— can you > > offer any suggestions? > > > > Thanks, > > > > Dave > > > > > > > > On Mon, May 2, 2022 at 9:23 AM Gerd Petermann > > mailto:gpetermann_muenc...@hotmail.com>> > > wrote: > > Hi Dave, > > > > the max-nodes value is already very small, so maybe something in mkgmap > > goes very wrong. > > We probably need the input file (*.o5m) for the tile that fails and the > > style unless you can reproduce the > > problem also with the default style. > > > > Gerd > > > > > > Von: Dave Swarthout > > mailto:daveswarth...@gmail.com>> > > Gesendet: Montag, 2. Mai 2022 18:08 > > An: Gerd Petermann > > Cc: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Compile error > > > > Reducing the node count means I was adjusting the max-nodes value; I had > > been using a value of 160,000 for max-nodes but after getting that error > > message, I tried running splitter with max-nodes=120,000 and 100,000 nodes > > but that had zero effect on the error message. There were more tiles > > generated by splitter but the same error resulted. > > > > I've attached my splitter logs and the DJS.CFG file > > > > Thanks for the help > > > > On Mon, May 2, 2022 at 1:42 AM Gerd Petermann > > mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>> > > wrote: > > Hi Dave, > > > > what do you mean with "I've tried reducing the size of the node count but > > that had no effect"? A
Re: [mkgmap-dev] Compile error
I don't create an overview map. No tiles show up with zero size nor are any of the 56 tiles larger than about 159,000 nodes. Carlos has offered a patch to indicate the problem tile but I'm on a Windows 10 system and am not willing to set up a Linux environment just to patch my mkgmap program. Is there a debugging tool or method that you can suggest? On Mon, May 2, 2022 at 11:10 AM Gerd Petermann wrote: > > Hi Dave, > > I would expect a tile with 0 bytes. Maybe you get this message for the > overview map? > > Gerd > > ____ > Von: Dave Swarthout > Gesendet: Montag, 2. Mai 2022 20:02 > An: Gerd Petermann > Cc: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Compile error > > Thanks, Gerd, > > I get the same error when using the default syle. In DJS.cfg, I placed this > line: > style-file=C:\Users\Alask\Documents\mkgmap\examples\styles\default. That is > correct usage, right? > > Another list member told me to look for the offending tile in order to > manually split it, however, all the tiles look alike to me in terms of size. > How would I tell which tile is the "bad one" that's causing this RGN error? > > You mentioned adjusting some mkgmap parameters that would reduce the size > and/or complexity of the map I'm trying to create. The descriptive text in > the Options file for directives about processing lines and polygons doesn't > make clear how to reduce the amount of information they handle— can you offer > any suggestions? > > Thanks, > > Dave > > > > On Mon, May 2, 2022 at 9:23 AM Gerd Petermann > mailto:gpetermann_muenc...@hotmail.com>> > wrote: > Hi Dave, > > the max-nodes value is already very small, so maybe something in mkgmap goes > very wrong. > We probably need the input file (*.o5m) for the tile that fails and the style > unless you can reproduce the > problem also with the default style. > > Gerd > > > Von: Dave Swarthout mailto:daveswarth...@gmail.com>> > Gesendet: Montag, 2. Mai 2022 18:08 > An: Gerd Petermann > Cc: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Compile error > > Reducing the node count means I was adjusting the max-nodes value; I had been > using a value of 160,000 for max-nodes but after getting that error message, > I tried running splitter with max-nodes=120,000 and 100,000 nodes but that > had zero effect on the error message. There were more tiles generated by > splitter but the same error resulted. > > I've attached my splitter logs and the DJS.CFG file > > Thanks for the help > > On Mon, May 2, 2022 at 1:42 AM Gerd Petermann > mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>> > wrote: > Hi Dave, > > what do you mean with "I've tried reducing the size of the node count but > that had no effect"? A smaller --max-nodes value for splitter should always > have an effect: > More / different tiles. Maybe it just didn't change the size of the > problematic tile? > > So, if you don't want to "reduce the amount of information included in the > map" which means > changing the style or options like --reduce-points, --levels etc, your only > option is to tell splitter to produce smaller tiles. > That is done with the --max-nodes option or maybe allow trimming if the > problematic tile contains a huge area with sea only. > > Can't say much more without knowing the content of the problematic tile and > content of DJS.cfg. > > Gerd > > > > > Von: mkgmap-dev > mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>> > im Auftrag von Dave Swarthout > mailto:daveswarth...@gmail.com><mailto:daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>>> > Gesendet: Sonntag, 1. Mai 2022 02:06 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Compile error > > Hi, > > I'm not on this list anymore but I'm having a problem with mkgmap that I'm > unable to understand or fix. > > I'm getting this error all the time now. "The RGN section of the map or tile > is too big. The maximum size is 16777215 bytes. Try splitting the map into > smaller tiles or reducing the amount of information included in the map." > > I've tried reducing the size of the node count but that had no effect. Here's > my command line: > > java -Xmx4000m -jar mkgmap.jar
Re: [mkgmap-dev] Compile error
@Carlos, Thank you. I'm running mkgmap on a Windows 10 system. Installing a Linux-style environment so I can patch mkgmap is not something I want to do in order to get my maps to compile. Dave On Mon, May 2, 2022 at 11:31 AM Carlos Dávila wrote: > Failing tile should be 0 bytes size. Regarding this question, in the > past mkgmap showed the tile that was failing to compile, but this > feature was removed some time ago. I use a patched version which > re-implements it (see attached patch). > > El 2/5/22 a las 20:02, Dave Swarthout escribió: > > > > Another list member told me to look for the offending tile in order to > > manually split it, however, all the tiles look alike to me in terms of > > size. How would I tell which tile is the "bad one" that's causing this > > RGN error?___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Compile error
Thanks, Gerd, I get the same error when using the default syle. In DJS.cfg, I placed this line: style-file=C:\Users\Alask\Documents\mkgmap\examples\styles\default. That is correct usage, right? Another list member told me to look for the offending tile in order to manually split it, however, all the tiles look alike to me in terms of size. How would I tell which tile is the "bad one" that's causing this RGN error? You mentioned adjusting some mkgmap parameters that would reduce the size and/or complexity of the map I'm trying to create. The descriptive text in the Options file for directives about processing lines and polygons doesn't make clear how to reduce the amount of information they handle— can you offer any suggestions? Thanks, Dave On Mon, May 2, 2022 at 9:23 AM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > the max-nodes value is already very small, so maybe something in mkgmap > goes very wrong. > We probably need the input file (*.o5m) for the tile that fails and the > style unless you can reproduce the > problem also with the default style. > > Gerd > > > Von: Dave Swarthout > Gesendet: Montag, 2. Mai 2022 18:08 > An: Gerd Petermann > Cc: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Compile error > > Reducing the node count means I was adjusting the max-nodes value; I had > been using a value of 160,000 for max-nodes but after getting that error > message, I tried running splitter with max-nodes=120,000 and 100,000 nodes > but that had zero effect on the error message. There were more tiles > generated by splitter but the same error resulted. > > I've attached my splitter logs and the DJS.CFG file > > Thanks for the help > > On Mon, May 2, 2022 at 1:42 AM Gerd Petermann < > gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> > wrote: > Hi Dave, > > what do you mean with "I've tried reducing the size of the node count but > that had no effect"? A smaller --max-nodes value for splitter should always > have an effect: > More / different tiles. Maybe it just didn't change the size of the > problematic tile? > > So, if you don't want to "reduce the amount of information included in the > map" which means > changing the style or options like --reduce-points, --levels etc, your > only option is to tell splitter to produce smaller tiles. > That is done with the --max-nodes option or maybe allow trimming if the > problematic tile contains a huge area with sea only. > > Can't say much more without knowing the content of the problematic tile > and content of DJS.cfg. > > Gerd > > > > > Von: mkgmap-dev mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Dave Swarthout < > daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>> > Gesendet: Sonntag, 1. Mai 2022 02:06 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Compile error > > Hi, > > I'm not on this list anymore but I'm having a problem with mkgmap that I'm > unable to understand or fix. > > I'm getting this error all the time now. "The RGN section of the map or > tile is too big. The maximum size is 16777215 bytes. Try splitting the map > into smaller tiles or reducing the amount of information included in the > map." > > I've tried reducing the size of the node count but that had no effect. > Here's my command line: > > java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566 > --name-tag-list=name,alt_name,loc_name,int_name --description="Eugene" > "C:\Users\Alask\Downloads\Maps\Eugene.osm" "C:\Users\Alask\Dropbox > (Personal)\Mapping\24983djs.TYP" > > Splitter ends normally with 56 areas for a 1.5 GB input file > > Any ideas? > > Please address all replies to me as well as the list membership because I > was removed from this list for having "too many bounces", whatever that is > but I need a solution to this problem. > > Thanks in advance > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Compile error
Reducing the node count means I was adjusting the max-nodes value; I had been using a value of 160,000 for max-nodes but after getting that error message, I tried running splitter with max-nodes=120,000 and 100,000 nodes but that had zero effect on the error message. There were more tiles generated by splitter but the same error resulted. I've attached my splitter logs and the DJS.CFG file Thanks for the help On Mon, May 2, 2022 at 1:42 AM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > what do you mean with "I've tried reducing the size of the node count but > that had no effect"? A smaller --max-nodes value for splitter should always > have an effect: > More / different tiles. Maybe it just didn't change the size of the > problematic tile? > > So, if you don't want to "reduce the amount of information included in the > map" which means > changing the style or options like --reduce-points, --levels etc, your > only option is to tell splitter to produce smaller tiles. > That is done with the --max-nodes option or maybe allow trimming if the > problematic tile contains a huge area with sea only. > > Can't say much more without knowing the content of the problematic tile > and content of DJS.cfg. > > Gerd > > > > > Von: mkgmap-dev im Auftrag von > Dave Swarthout > Gesendet: Sonntag, 1. Mai 2022 02:06 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Compile error > > Hi, > > I'm not on this list anymore but I'm having a problem with mkgmap that I'm > unable to understand or fix. > > I'm getting this error all the time now. "The RGN section of the map or > tile is too big. The maximum size is 16777215 bytes. Try splitting the map > into smaller tiles or reducing the amount of information included in the > map." > > I've tried reducing the size of the node count but that had no effect. > Here's my command line: > > java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566 > --name-tag-list=name,alt_name,loc_name,int_name --description="Eugene" > "C:\Users\Alask\Downloads\Maps\Eugene.osm" "C:\Users\Alask\Dropbox > (Personal)\Mapping\24983djs.TYP" > > Splitter ends normally with 56 areas for a 1.5 GB input file > > Any ideas? > > Please address all replies to me as well as the list membership because I > was removed from this list for having "too many bounces", whatever that is > but I need a solution to this problem. > > Thanks in advance > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com splitter.log Description: Binary data areas.list Description: Binary data DJS.cfg Description: Binary data ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Compile error
Hi, I'm not on this list anymore but I'm having a problem with mkgmap that I'm unable to understand or fix. I'm getting this error all the time now. "The RGN section of the map or tile is too big. The maximum size is 16777215 bytes. Try splitting the map into smaller tiles or reducing the amount of information included in the map." I've tried reducing the size of the node count but that had no effect. Here's my command line: java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566 --name-tag-list=name,alt_name,loc_name,int_name --description="Eugene" "C:\Users\Alask\Downloads\Maps\Eugene.osm" "C:\Users\Alask\Dropbox (Personal)\Mapping\24983djs.TYP" Splitter ends normally with 56 areas for a 1.5 GB input file Any ideas? Please address all replies to me as well as the list membership because I was removed from this list for having "too many bounces", whatever that is but I need a solution to this problem. Thanks in advance -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] The x prepended to the *.typ file
Hi Gerd, It's probably because I don't use the default family id. I substitute my own to prevent problems when using more than one map in my GPSr. Here's my command line for my Eugene (Oregon) maps: java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566 --name-tag-list=name,loc_name,int_name,alt_name --description="Eugene" "C:\Users\Alask\Downloads\Maps\Eugene.osm" "C:\Users\Alask\Dropbox (Personal)\Mapping\24983djs.TYP" When compiling a map of Thailand, I use family-id=18028 and description="Thailand" in my command line. I picked those numbers out of the air, so to speak. It's an easy solution that eliminates "conflicts" when checking my maps with the JaVaWa Device Manager. My maps work fine so I presume these changes are a good fix. I don't use splitter; all my maps are for areas that require OSM downloads of less than 1 GByte. Dave On Sun, Sep 19, 2021 at 11:23 PM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > the typ file contains fields for the family-id and the product-id. If > those don't match the values used in the map it will not work, that's why > mkgmap creates a copy. > As Ticker said, there is code to prevent that a correct typ file is > overwritten, so I wonder how you manage to have the x-file with identical > content. > > Gerd > > > > Von: mkgmap-dev im Auftrag von > Dave Swarthout > Gesendet: Montag, 20. September 2021 02:08 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file > > Why would you have mkgmap modify a TYP file for any reason? (FYI: My > output goes to the same directory that contains my input files.) > > I would much rather see some sort of error message than have an > undocumented (AFAIK) feature modify my TYP file, especially since there is > no indication of that behaviour in the error stream. I've seen this x-file > for years and could not (and still don't) see why it exists. Both TYP files > always prove to be identical when checked by the ExamDiff program). > Reiterating, if there is some sort of conflict in family/product numbers, > let the user know about it through error messages and suggest remedies. But > don't change his/her TYP file behind the scenes. > > On Sun, Sep 19, 2021 at 2:53 PM Ticker Berkin <mailto:rwb-mkg...@jagit.co.uk>> wrote: > Hi > > My reading of the code is that it won't create an x-version that is > identical to the original, so I don't understand what Dave observes. > > I think the best solution is as Gerd suggests, if the binary input .typ > file has the wrong family/product and is in the output direction, an > error should be flagged. If it is in another directory, a patched > version with the same name should be created in the output directory. > > Ticker > > On Sun, 2021-09-19 at 10:35 -0700, Dave Swarthout wrote: > > FYI > > > > In my workflow, the source TYP file is not modified. Both TYP files, > > the original and the x-version, are identical. However, my TYP file > > is not a text file; it is a binary file that the TYPViewer program > > generates. How that plays in this scenario I have no idea. > > > > On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann < > > gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> > wrote: > > > Hi Ticker, > > > > > > OK, I agree that it isn't the best idea to modify a source file. > > > So, maybe mkgmap should stop with an error message if that would > > > happen? > > > > > > Gerd > > > > > > > > > Von: mkgmap-dev mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag > > > von Ticker Berkin rwb-mkg...@jagit.co.uk>> > > > Gesendet: Sonntag, 19. September 2021 18:31 > > > An: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file > > > > > > Hi > > > > > > With mkgmap compiling the .txt to .typ there is no problem - I'm > > > assuming this question is only concerned with what happens when > > > starting with a binary .typ file. > > > > > > If the .typ file already exists and has the wrong family/product > > > and is > > > in the directory that mkgmap will use for output files, then the > > > options are: > > > > > > 1/ change the original .typ file, patching the family/product; > > > - it must be wrong to change an input file. > > > > > > 2/ use a different direc
Re: [mkgmap-dev] The x prepended to the *.typ file
Why would you have mkgmap modify a TYP file for any reason? (FYI: My output goes to the same directory that contains my input files.) I would much rather see some sort of error message than have an undocumented (AFAIK) feature modify my TYP file, especially since there is no indication of that behaviour in the error stream. I've seen this x-file for years and could not (and still don't) see why it exists. Both TYP files always prove to be identical when checked by the ExamDiff program). Reiterating, if there is some sort of conflict in family/product numbers, let the user know about it through error messages and suggest remedies. But don't change his/her TYP file behind the scenes. On Sun, Sep 19, 2021 at 2:53 PM Ticker Berkin wrote: > Hi > > My reading of the code is that it won't create an x-version that is > identical to the original, so I don't understand what Dave observes. > > I think the best solution is as Gerd suggests, if the binary input .typ > file has the wrong family/product and is in the output direction, an > error should be flagged. If it is in another directory, a patched > version with the same name should be created in the output directory. > > Ticker > > On Sun, 2021-09-19 at 10:35 -0700, Dave Swarthout wrote: > > FYI > > > > In my workflow, the source TYP file is not modified. Both TYP files, > > the original and the x-version, are identical. However, my TYP file > > is not a text file; it is a binary file that the TYPViewer program > > generates. How that plays in this scenario I have no idea. > > > > On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann < > > gpetermann_muenc...@hotmail.com> wrote: > > > Hi Ticker, > > > > > > OK, I agree that it isn't the best idea to modify a source file. > > > So, maybe mkgmap should stop with an error message if that would > > > happen? > > > > > > Gerd > > > > > > > > > Von: mkgmap-dev im Auftrag > > > von Ticker Berkin > > > Gesendet: Sonntag, 19. September 2021 18:31 > > > An: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file > > > > > > Hi > > > > > > With mkgmap compiling the .txt to .typ there is no problem - I'm > > > assuming this question is only concerned with what happens when > > > starting with a binary .typ file. > > > > > > If the .typ file already exists and has the wrong family/product > > > and is > > > in the directory that mkgmap will use for output files, then the > > > options are: > > > > > > 1/ change the original .typ file, patching the family/product; > > > - it must be wrong to change an input file. > > > > > > 2/ use a different directory for the patched version; > > >- but where? > > > > > > 3/ use a different name for for the patched version; > > >- this could be improved, so that rather than prefixing with x, > > > a > > >clearer suffix is added to the actual file but when this is > > > added > > >to gmapi/gmapsupp, the original name is used for the embedded > > >component. > > > > > > At the moment mkgmap ignores the last condition "... is in the same > > > directory ...", but this could be tested and, if not, the name > > > could be > > > kept and the new file created in the natural output directory. > > > > > > Ticker > > > > > > On Sun, 2021-09-19 at 08:38 -0700, Dave Swarthout wrote: > > > > I have wondered where that "x-file" came from for years. To me, > > > it's > > > > totally unnecessary and confusing. I thought my typ file editor, > > > > TypViewer, was creating it. > > > > Even after reading the email and replies, I still don't > > > understand > > > > the reasoning behind having mkgmap creating this "backup" copy in > > > the > > > > first place but I think it should be got rid of. > > > > > > > > Thanks for clearing up the mystery! > > > > > > > > Dave > > > > > > > > On Sun, Sep 19, 2021 at 4:30 AM Gerd Petermann < > > > > gpetermann_muenc...@hotmail.com> wrote: > > > > > Hi Ticker, > > > > > > > > > > please explain why mkgmap is "stuck" with the fixed version. > > > What's > > > > > the difference between a fixed *.typ file and one
Re: [mkgmap-dev] The x prepended to the *.typ file
FYI In my workflow, the source TYP file is not modified. Both TYP files, the original and the x-version, are identical. However, my TYP file is not a text file; it is a binary file that the TYPViewer program generates. How that plays in this scenario I have no idea. On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Ticker, > > OK, I agree that it isn't the best idea to modify a source file. > So, maybe mkgmap should stop with an error message if that would happen? > > Gerd > > > Von: mkgmap-dev im Auftrag von > Ticker Berkin > Gesendet: Sonntag, 19. September 2021 18:31 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file > > Hi > > With mkgmap compiling the .txt to .typ there is no problem - I'm > assuming this question is only concerned with what happens when > starting with a binary .typ file. > > If the .typ file already exists and has the wrong family/product and is > in the directory that mkgmap will use for output files, then the > options are: > > 1/ change the original .typ file, patching the family/product; > - it must be wrong to change an input file. > > 2/ use a different directory for the patched version; >- but where? > > 3/ use a different name for for the patched version; >- this could be improved, so that rather than prefixing with x, a >clearer suffix is added to the actual file but when this is added >to gmapi/gmapsupp, the original name is used for the embedded >component. > > At the moment mkgmap ignores the last condition "... is in the same > directory ...", but this could be tested and, if not, the name could be > kept and the new file created in the natural output directory. > > Ticker > > On Sun, 2021-09-19 at 08:38 -0700, Dave Swarthout wrote: > > I have wondered where that "x-file" came from for years. To me, it's > > totally unnecessary and confusing. I thought my typ file editor, > > TypViewer, was creating it. > > Even after reading the email and replies, I still don't understand > > the reasoning behind having mkgmap creating this "backup" copy in the > > first place but I think it should be got rid of. > > > > Thanks for clearing up the mystery! > > > > Dave > > > > On Sun, Sep 19, 2021 at 4:30 AM Gerd Petermann < > > gpetermann_muenc...@hotmail.com> wrote: > > > Hi Ticker, > > > > > > please explain why mkgmap is "stuck" with the fixed version. What's > > > the difference between a fixed *.typ file and one that is freshly > > > compiled from *.txt? > > > > > > Gerd > > > > > > > > > Von: mkgmap-dev im Auftrag > > > von Ticker Berkin > > > Gesendet: Sonntag, 19. September 2021 13:25 > > > An: Development list for mkgmap; Steve Ratcliffe > > > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file > > > > > > Hi > > > > > > If you don't use --output_dir but have map sources (.osm.pbf) and > > > results (.img) all in the same place, and you specify a pre-built > > > TYPfile with extension .typ, but it has the wrong family/product, > > > mkgmap can adjust these, but is then stuck as to what to do with > > > the > > > fixed version, hence the "x" prefix to deal with this case. > > > > > > If --output-dir is specified and the .typ file wasn't in that when > > > specified as an input parameter, then could avoid the rename. > > > > > > This doesn't effect me as I always use mkgmap to generate the .typ > > > from > > > the .txt as part of the final map generation process. > > > > > > Ticker > > > > > > On Sun, 2021-09-19 at 10:22 +, Gerd Petermann wrote: > > > > Hi all, > > > > > > > > I think there is an old rather confusing glitch in mkgmap class > > > > TypSaver which it is used with a *.typ file as input, as in > > > > java -jar mkgmap.jar --output-dir= --family-id=4711 > > > ... > > > > -c splitter-dir\template.args ..\typfiles\existing.typ > > > > to make sure that family-id and product-id are correctly updated > > > in > > > > the *.typ file. > > > > Since 2012 the program creates / overwrites a copy of file > > > > existing.typ in the source(!) directory ..\typfiles with the > > > prefix > > > > "x"
Re: [mkgmap-dev] The x prepended to the *.typ file
I have wondered where that "x-file" came from for years. To me, it's totally unnecessary and confusing. I thought my typ file editor, TypViewer, was creating it. Even after reading the email and replies, I still don't understand the reasoning behind having mkgmap creating this "backup" copy in the first place but I think it should be got rid of. Thanks for clearing up the mystery! Dave On Sun, Sep 19, 2021 at 4:30 AM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Ticker, > > please explain why mkgmap is "stuck" with the fixed version. What's the > difference between a fixed *.typ file and one that is freshly compiled from > *.txt? > > Gerd > > > Von: mkgmap-dev im Auftrag von > Ticker Berkin > Gesendet: Sonntag, 19. September 2021 13:25 > An: Development list for mkgmap; Steve Ratcliffe > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file > > Hi > > If you don't use --output_dir but have map sources (.osm.pbf) and > results (.img) all in the same place, and you specify a pre-built > TYPfile with extension .typ, but it has the wrong family/product, > mkgmap can adjust these, but is then stuck as to what to do with the > fixed version, hence the "x" prefix to deal with this case. > > If --output-dir is specified and the .typ file wasn't in that when > specified as an input parameter, then could avoid the rename. > > This doesn't effect me as I always use mkgmap to generate the .typ from > the .txt as part of the final map generation process. > > Ticker > > On Sun, 2021-09-19 at 10:22 +, Gerd Petermann wrote: > > Hi all, > > > > I think there is an old rather confusing glitch in mkgmap class > > TypSaver which it is used with a *.typ file as input, as in > > java -jar mkgmap.jar --output-dir= --family-id=4711 ... > > -c splitter-dir\template.args ..\typfiles\existing.typ > > to make sure that family-id and product-id are correctly updated in > > the *.typ file. > > Since 2012 the program creates / overwrites a copy of file > > existing.typ in the source(!) directory ..\typfiles with the prefix > > "x", so ..\typfiles\xexisting.typ is written instead of > > \existing.typ. I can't find it now but I think there were > > complains that this name doesn't fit the 8+3 rule for old file > > systems and causes trouble on some devices. > > > > I think when Steve coded this he expected that the *.typ file is in > > the output directory, not somewhere else. My conclusions: > > - I think it is an error to create the copy in the source directory. > > - I see no reason to create a copy with the prepended "x", I would > > just create or alter the file in the given output directory. > > > > @Steve: What case am I missing? What's the reason for the different > > name in the copy? > > @all: Does anybody rely on this behaviour? > > > > Gerd > > ___ > > mkgmap-dev mailing list > > mkgmap-dev@lists.mkgmap.org.uk > > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] problems edge1030
Hi,See this link, https://www8.garmin.com/support/download_details.jsp?id=12819Regards,DaveFrom: ar...@speichenkarte.deSent: 30 June 2021 11:39To: mkgmap-dev@lists.mkgmap.org.ukReply to: mkgmap-dev@lists.mkgmap.org.ukSubject: Re: [mkgmap-dev] problems edge1030 HI Eric, thank you! I forget to say, that the problems comes with an update from the edge 1030.Before that, the maps work well. Greetz Arndt Eric Internet <ankeric@gmail.com> hat am 30.06.2021 10:07 geschrieben: I did find some information: https://openmtbmap.org/garmin/unicode-maps/ AnkEric (Eric) On Wed, Jun 30, 2021, 08:44 Eric Internet <ankeric@gmail.com> wrote: Not all Garmin devices accept UTF-8. If not an Error msg will show and map will not be displayed. I'm on vacation now, so I don't have any better information. AnkEric (Eric) On Wed, Jun 30, 2021, 07:22 Arndt Röhrig <ar...@speichenkarte.de> wrote: HI @all, some users reports problems with the device edge1030. It don´t start, when they use "Speichenkarte". Is it possible, that the style is so crazy, that this error can be? What can i look for? One user try another country. Same effect. He try also build the gmapsupp with MapSource instead of the ready Speiche-gmapsupp. Same effect. I would be very thankful for help. Greetz Arndt P.S. the styles & options are here: https://speichenkarte.de/ "Steuerdateien" I use mlgmap 4793 ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters
Hi all,Just to jump in regarding routing.In countries such as Zambia a GPS would be used by overland travelers and much of the tourist POI's and interesting out of the way places in OSM have been mapped by these travelers. While a lot of the OSM data in Africa is not of good quality the parks and lodge data is of better quality than Google Maps. I would not trust Google Maps apart from within the centre of major cities, using it in the peripheries will send you down some strange routes and some locations are just plain wrong. South Africa is different, Google maps is very good there.Where Google maps is good in the centre of a heavily congested city like Lusaka is avoiding the traffic bottle necks as it uses phone location data to show slow routes and will route to avoid it quite effectively. Just a different view point.Regards,Dave From: extremecar...@gmail.comSent: 5 May 2021 10:17To: mkgmap-dev@lists.mkgmap.org.ukReply to: mkgmap-dev@lists.mkgmap.org.ukSubject: Re: [mkgmap-dev] new branch low-res-opt to test improvements for filters Hi Karl,But even then you will never use the overview map. What resolution are you actually using on your device if routing on a highway? I guess 19 or 20... The thing is simply with high DP filter value that you can see the highway pretty straight, but as the route itself is not simplifed that much in Basecamp. The route will not be 1:1 visually of the map. But still very easy to see the the underlying highway. if you plan a route from Berlin to Mardrid, then zoom out and see the whole route - then it's not so beautiful anymore. But can any mkgmap created map actually route from Berlin to Madrid without via points? It's a long time that I looked at mgkmap created maps for car routing and some years ago this was not possible.On Wed, 5 May 2021 at 15:48, 7770 <7...@foskan.eu> wrote:Hi. Sorry for getting into the discussion. Routing over long distances is important, also via highways. There can be multiple nearby exists along the way that one does not know by heart and does not want to miss. Quite often one (at least i) does not want to fiddle around with device while driving, instead simply start the route in the beginning even if a large portion of the travel is fairly known. Regards Karl On onsdag 5 maj 2021 kl. 09:32:52 CEST Felix Hartmann wrote: > Really, routing over long distances on highways? I haven"t met people using > a Garmin GPS device routing via highways - however many who use it for > recreational purposes - so routing over short distances. > > Anyhow if you use a lower DP value no problem there. It's mainly if you > zoom out to overview map resolution at 18, 17 or wherever that starts. So > far mkgmap maps were unusable on devices for 17 or lower due to being very > slow. I'm not sure how much of this was too much data in those tiles, and > how much that the device has to look up too many tiles. That's what the > device is using the basemap for, and Basecamp using the overview map for. > So if you zoom out that far - no problems if the route doesn't fully follow > the underlying map. It's the same for Garmin city navigator maps. > > On Wed, 5 May 2021 at 15:27, Thomas Morgenstern <webmas...@img2ms.de> wrote: > > Hi all, I see this completly different : many people use osm data for > > routing. Routing is the main purpose for using OSM. If routing [ > > *quote] > > > > : ** it will look a bit strange [end quote] *is not akzeptable. > > > > Thomas > > > > > > Quote :. > > So yes with very high DP values and lots of simplification if you plan a > > car route over highways, at some point it will look a bit strange. But > > again, very few people use Garmin maps for car routing nowadays, and even > > less car routing based on OSM data. .. > > > > On Wed, 5 May 2021 at 14:29, Gerd Petermann < > > gpetermann_muenc...@hotmail.com> wrote: > > Hi Felix, > > > > I don't think that it only depends on the typ file. Programs like > > GpsMapEdit also show wrong merges. > > > > Reg. roads: Seems RoadMerger also doesn't reverse points, I didn't notice > > that before. So, I have two methods to improve. > > It's quite difficult to understand the effects because we > > - merge roads with equal attributes > > - possibly split those roads again to avoid loops or too long roads or too > > complex roads (too many connections) or other limits in IMG f
Re: [mkgmap-dev] tile takes very long time to generate
Hi Gerd, Nested polygons may not be as rare as you think, it was a situation I was thinking about when this discussion started. Zambia has a number of large wetlands where there are islands with wetland within the island, particularly as these wetlands are seasonal and the islands will be inundated during the rains with the low points of the island staying wet once the water recedes. This is similar to your forest with a lake that contains a forest. Dave Original Message From: gpetermann_muenc...@hotmail.com Sent: 18 March 2021 12:21 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] tile takes very long time to generate Hi all, I still struggle with the unit test because it's hard to say what we want to get in special cases. The current code doesn't really work in the way that I expected. I always thought that roles like "inner" and "outer" are completely ignored and that mkgmap calculates and uses the correct roles. This is only partly true. See attached file with MP were a forest contains a lake that contains a forest. For a nested polygon where the innermost ring has wrong role "inner" this doesn't work as expected. The forest in the lake is ignored. With the correct role "outer" it is not ignored. No idea if this is intended or an error. Fortunately nested MP are very rare. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 15. März 2021 17:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] tile takes very long time to generate Hi Gerd You might consider the some of the ideas here as improvements to the initial parts of MP processing. This is a patch based on trunk rather than the new branch. It isn't structured as for final usage, rather for minimising the spread of changes, working in parallel with the existing code so I could see if found the same MP problems as the existing code and having clearly identifiable diagnostics in the log file. Ticker ___ 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
Re: [mkgmap-dev] Multipolygon Role Understanding
Hi Jan, I had a look at your troublesome multipolygon and in my view it should not be a multipolygon at all. The inner roles in a multipolygon are 'cut outs' best explained where a multipolygon is applied to a lake with an island where the island is 'cut out' of the lake and has the role of inner, this prevents it from being rendered under the water of the lake. The tags relating to the lake are applied to the relation as a whole not the outer way but the tags relating to the island i.e. name etc. are applied to the way with the inner role. I presume that is why your workaround by changing the outer role to an inner one works for the tagging in mkgmap. Another example is perhaps an open area in a wood or open water in a wetland. In your situation some components that are not part of the relation but are obviously part of the water park render quite fine in OSM, technically the parts of the relation with the role inner are not part of the water park which in fact they are in this situation. A more suitable relation would be site (https://wiki.openstreetmap.org/wiki/Relation:site) but even that does not really apply here as the site is not dispersed over a wide area as a college campus may be for example. As to how you find these errors I am not sure, Geofabrik's OSM Inspector (http://tools.geofabrik.de/osmi/) can be used to find many multipolygon errors but does not find this one, zoom to the area you want to inspect and select "Areas" from the dropdown on the left to show up tagging and role errors. Just some thoughts. Dave -Original Message- From: mkgmap-dev On Behalf Of Gerd Petermann Sent: 11 February 2021 10:00 To: Development list for mkgmap Subject: Re: [mkgmap-dev] Multipolygon Role Understanding Hi Jan, the multipolygon processing happens before POI are generated. With the original MP mkgmap creates a POI for the unnamed leisure of the MP and probably also one for the outer way which (at this time) only has one tag name="Naturfreibad Sankt Märgen". There is no rule for such an object in the points file and therefore no POI is generated. I also wondered how to detect this error. I expected that JOSM would complain but it only shows an info message. Will look at this later. No idea yet how to find those cases with overpass. You may search for a specific tag like the leisure=water_park but I see no easy way to find all MP where the MP repeats an important tag of one of the outer ways. Gerd Von: mkgmap-dev im Auftrag von jan meisters Gesendet: Donnerstag, 11. Februar 2021 00:15 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Multipolygon Role Understanding Hi Gerd, yes, that works for me as described. As I understand, due to consecutive processing: nameless leisure gone, next matched? Another work_around I found by just changing the outer role to an inner. Both indicates imho more likely a mistagging. I´d like to have an overpass query to find similar examples - if anyone has an idea: appreciated ;-) Jan > Am 10.02.2021 um 23:13 schrieb Gerd Petermann : > > Hi all, > > sorry, the style file is OK. I just tried with the (locally) corrected MP (removed the leisure tag) and with that the name "Naturfreibad Sankt Märgen" is shown in the map. > I think the multipolygon code removes all tags from the outer way > which also appear in the MP. The remaining tags name=Naturfreibad > Sankt Märgen > opening_hours=Jun-Sep: Mo-Su 09:00-18:00 wheelchair=limited are > ignored by the default style. > > The behaviour is intended, but in fact a bit confusing. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Gerd Petermann > Gesendet: Mittwoch, 10. Februar 2021 23:03 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Multipolygon Role Understanding > > Hi Jan, > > I think the multipolygon describes the landuse, the outer way describes the leisure. It makes no sense to have both tags on the MP. > Reg. the missing "Naturfreibad Sankt Märgen": > The default style doesn't use the name of the leisure, neither for the polygon nor for the POI. Not sure why. I would have expected that inc/name does that. > > Gerd > > > Von: mkgmap-dev im Auftrag > von jan meisters > Gesendet: Mittwoch, 10. Februar 2021 21:11 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] Multipolygon Role Understanding > > Hi all, > > with my limited multipolygon knowledge I stumbled on missing poi tags here: > https://www.openstreetmap.org/relation/4077717 > > The multipolygon is tagged more limited than the outer role. > mkgmap renders the mp-tags, but drops the more useful outer tags (name etc.). > This useful it´s rendered on openstreetmap, but I can´t get it with m
Re: [mkgmap-dev] Garmin Topo Europe map
Hi Karl, I see you mention that automotive routing is disabled in the TopoActive Europe Map on your GPSMAP 66st, are you able to use automotive routing with your maps created with mkgmap? The reason I ask is I received a new Etrex 32x as a present and when I went online to check for any firmware updates I saw one of the changes from version 2.5 to 2.6 (for the Etrex 32x) was that automotive routing was disabled for OSM maps (https://www8.garmin.com/support/download_details.jsp?id=14889#Instruct). For this reason I did not update the firmware, the only other change was to text translations so would not affect the operation of the GPS. I did not want to update to try if automotive routing was disabled on all maps based on OSM data and then brick the device trying to go back to an old firmware if it was. Regards, Dave From: mkgmap-dev On Behalf Of Vuki Sent: 30 December 2020 11:17 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Garmin Topo Europe map Hi Karl, don't you want to share your minimal style? :) Köszi: Vuki On 2020.12.27. 20:59, 7770 wrote: Hi. A few observations about the TopoActive europe map. (i have it on a GPSMAP 66st). The map is rendered slower than most custom made maps. Updates occur 2 times per year, but even at those times many changes to OSM are not present. Perhaps they only update some parts yearly. Points lack all kind of additional information which other mappers add (opening hours, region, phone numbers, etc.). One nice thing is colour marked national parks and reserves. Being an outdoor map, it lacks some information about shelters in the wilderness. Routing is possible only for outdoor activities (cycle, walk, hike, direct), automotive routing (car, motorcycle) is disabled. I have tried creating a minimal style. This lowers the data to about 75 % or my normal set up. But i did not change the level, which i will try :-) Currently I am no way near the compression which TopoActive achieves. Using input data which is about 6,7 GB in pbf format, creates a gmapsupp just below 4 GB for normal and around 3 GB for minimal style. These numbers feels similar to getting France into 1.9 GB from 3.7 GB pbf (geofabrik). The minimal set up is not very fancy at all, it disables things not wanted. Buildings, shops, most of parkings, and a bit more. Today i cannot send off any style, but in case that would be of interest let me know and i can share it in a few days (guessing Wednesday or Thursday). Regards Karl On söndag 27 december 2020 kl. 20:08:10 CET Gerd Petermann wrote: Hi Pierre, my first guess would be that the level 0 is at resolution 23 instead of 24. Gerd Von: mkgmap-dev <mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Pierre Brico <mailto:pierre.br...@gmail.com> Gesendet: Sonntag, 27. Dezember 2020 19:37 An: Development list for mkgmap Betreff: [mkgmap-dev] Garmin Topo Europe map Hello guys, I've just discovered the Garmin TopoActive Europe map based on OpenStreetMap data. This map is sold at a price of 50€ or is pre-installed on some new devices. I've just seen it on the device of one of my friends and it looks very good. I'm surprised to see that for West Europe, it takes only 2.8GB and is quite complete (index for search, routable, ...). For now, I generate my own maps based on your excellent tool but the result is much bigger (1.9GB only for France with probably more details). So, my question is: does anybody have a similar configuration (style files and command line) to obtain a result like the Garmin TopoActive Europe ? Thanks, Pierre ___ 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
Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp
Hi Ticker, This is in the centre of Zambia so should not be affected by drive on right countries. Where Zambia borders drive on right countries such as Angola and DRC there are not likely to be any link roads particularly Angola as it is pretty remote and not many roads here anyway. I understand the idea of a time penalty for a right turn across traffic, it is something that is always considered when driving in Lusaka normally as it is very congested, making a journey with all left turns will nearly always be quicker than one with a right turn across the traffic, the new flyover is part of a program to ease this. My interest was in the fact that bounds plus link tagging caused the problem, bounds without link no problem, bounds plus any other tagging no problem. So the routing algo is obviously affected by the link even if it is following a direction away from the intended destination and then making a very tight right turn, tighter than 45 degrees that I am sure is illegal although not tagged with a no right tun in OSM. Following traffic regulations in Zambia is moot though and could endanger your life. I can live with the oddity. In connection with the default style, for appearance sake it may be worth using a narrower type with service way roundabouts as the current style shows them in a size out of proportion to the connecting service ways. As space is not at a premium in Zambia many of the mall parkings have roundabouts within them that are bigger than a mini roundabout, probably as big as a small roundabout in the UK. Regards, Dave Original Message From: rwb-mkg...@jagit.co.uk Sent: 14 November 2020 13:03 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp Hi Dave There are a few things going on here that might have effects on the routing behaviours you are seeing. Driving side - as Gerd has elaborated. I have an example where the Garmin routing algorithm will do 2 left turns, a u-turn and then a right turn anyway across the traffic to avoid the correct, single, right turn! I notice that Zambia has adjacent countries with drive-on-right, so you need to beware of tiles around the edge of your map where the automatic choice could be wrong for Zambia. The default style uses type 0x08 and 0x09 for link roads and these are thought to have special properties regarding pop-up hints, but not known to effect routing decisions. Link roads have the same road_class as their non-link equivalents so this shouldn't have drastic effect on routing, but they do have a lower speed, which should have favored the direct turn even more (being shorter as well). Changing between primary and secondary might have a small effect on which roads get their angle into/out-of the junction adjusted where they are at a tight angle (<= 45 degrees) from another road and the turn appear permissible for navigation - tight angles impose a routing penalty. Ticker ___ 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
Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp
Hi Gerd,
Yes the map is in Lusaka, Zambia. There is a new road layout with a flyover
bridge, newly constructed, so out of curiosity did a test routing here to
see what BaseCamp would do, that's when the strange route came up. I then
decided to try work out why BaseCamp would give such a obviously wrong
route. BaseCamp and Garmin devices do not always give good routing options
in Zambia as the OSM way tagging in Zambia does not always indicate unpaved
roads and many tracks are tagged as unclassified or even higher order
highways. This is mainly due to the many remote mappers mapping in Africa.
Many of the link roads (primary_link etc.) were tagged by a team of Apple
Mappers. After finding that the -- bounds option affected the routing I
wondered if an added factor was the tagging of the way, this particular way
is tagged as primary_link. I found if I removed the link tagging and tagged
as a primary, secondary or tertiary way the route was as expected. Using the
fastest preference routes as expected regardless of bounds or tagging, in
fact there should be no difference in routing it is a direct right turn.
Many of the links tagged as such are not true links as may be found in more
developed countries where the idea is perhaps more applicable to on ramps
and off ramps. Removing the link tagging just meant another eager beaver
Apple mapper just came through and retagged it as a link.
I just found it strange that the combination of bounds and the link tagging
would cause the error. Just now thought it may have something to do with one
way directions which would be dependent on the drive on side of the country.
But Just changing the link tagging as I did in my test map would not affect
the one way direction.
I have not come across another example of this in the current map but do
recall that I saw a similar thing many months ago at a roundabout coming
into Lusaka where the route was off the connecting road to the roundabout
and back on to the roundabout rather than just around the roundabout. It
does not occur now but I suspect the roundabout flare was tagged incorrectly
as a link and that has now been corrected.
Regards,
Dave
-Original Message-
From: mkgmap-dev On Behalf Of Gerd
Petermann
Sent: 13 November 2020 12:05
To: Development list for mkgmap
Subject: Re: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp
Hi Dave,
if I got that right this part of the map is in Zambia, so without bounds you
have to tell mkgmap that it is a drive-on-left country, else you'll get
completely wrong results. Besides that Basecamp often doesn't find the
shortest route in car mode.
Gerd
Von: mkgmap-dev im Auftrag von Dave
Gesendet: Mittwoch, 11. November 2020 09:22
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Unusual Routing Behaviour in BaseCamp
Hi All,
I have come across an unusual routing behaviour in BaseCamp on a stretch of
road in Lusaka. When using the driving profile with no avoidances selected
and the shorter distance route preference selected the route shown diverts
down a link road and is obviously not the shortest route. Changing the route
preference to faster time shows a more obvious route. Both route preferences
should, in my opinion, be the same. See attached screen shots.
After some investigations it would appear that this occurs when the -bounds
option is used with bounds-latest.zip, if I do not use this option it routes
as expected.
The following are the commands used with mkgmap r4587:
Routing problem:
java.exe -jar C:\Users\Dave\Documents\Maps\Utils\mkgmap-r4587\mkgmap.jar `
--output-dir='C:\Users\Dave\Documents\Maps\Temp\Output' `
-c C:\Users\Dave\Documents\Maps\Options\Default.cfg `
-c
C:\Users\Dave\Documents\Maps\Zambia\Split_Files\template.args `
The Default.cfg file has the following options:
country-name="Zambia"
area-name="Zambia"
country-abbr="ZMB"
overview-mapname=Zambia
product-id=1
family-id=2526
draw-priority=20
max-jobs
keep-going
tdbfile
order-by-decreasing-area
gmapsupp
bounds=C:\Users\Dave\Documents\Maps\Data\bounds-latest.zip
latin1
index
route
remove-ovm-work-files
nsis
By commenting out the bounds option I change the routing behaviour. I have
not used any typ or style files in case they were the cause of this. Also
not tried on my Garmin device yet to see if the same behaviour occurs there
as well. The routing error I have found occurs at this intersection but may
occur elsewhere https://www.openstreetmap.org/#map=19/-15.45547/28.26647.
After some experimentation this only happens when the adjoining way is
tagged as a link road, in this case primary_link. Using JOSM I have changed
the tag to secondary and later primary, saved the file to my laptop then
processed the saved file and the unusual routing does not occur.
Regards,
Dave
___
mkgmap-dev mailing list
Re: [mkgmap-dev] TYP-object names showing as blank, what did i do wrong?
Hi Karl, Older Garmin models can not read unicode characters so you need to use --latin1 in place of --unicode when compiling maps for these older devices. I had a similar problem with my Etrex. Regards, Dave Original Message From: 7...@foskan.eu Sent: 29 October 2020 09:35 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] TYP-object names showing as blank, what did i do wrong? Hi. It seems like it was a question of adding the option --unicode to the mkgmap command combining the mapdata with the TYP. This works for the GPSMAP 66st and correctly shows the descriptions (map legend) of objects. Loading the same map on the eTrex vista HCx works, but the local characters shows as garbage, it's ok for now but is there some way do change it or is the unit "too old"? Regards Karl On onsdag 28 oktober 2020 kl. 19:32:11 CET 7770 wrote: > Hi. > I have an issue with TYP-object names showing as blank on a GPSMAP 66st > instead of showing the names defined in the TYP file by the String=0xNN > data. > > I tried loading the very same gmapsupp.img onto an old etrex vista hcx, it > does show the defined default name (if i have english setup), or the next > translation if i select any other language (it does not seem to be able to > pair the languages). > > If i take [_line] objects as example. > I have defined cycleway. > The GPSMAP 66st does display the colour and drawing defined in the TYP file, > but not the text if i hover over the line. Hovering over a line section > that does not have a name, instead of saying "Cycleway" it shows nothing > "". > > There are no errors when compiling the TYP file. > > If i take a compiled map from opentopomap, for some line which they have > defined their own TYP, the device is showing the String for the same types > which my map shows blank. > It must be some error i have made, but what could it be? > > Regards > Karl ___ 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] Consolidation of mkgmap changes
Hello Back in December I suggested creating a periodic listing of the major changes to mkgmap so that users can more easily understand how the code base is changing and new features. Now that I have access to a computer I have created a list based on commits from April to the present, as attached. I have compressed the commits from 100 to 7 entries. I believe a good place to post this is in the Latest News section of mkgmap.org.uk. Please review and provide me feedback, including the Format and data of my entries Also if my list is too long or short If the community finds this useful, I will need a contact to review the lists and posting privileges on mkgmap.org. I can commit to producing this twice a year. Thanks, -- Dave Pitney mappit...@gmail.com - end of message Mkgmap Code Changes.docx Description: MS-Word 2007 document ___ 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
Well, if these areas are legitimate OSM objects, that's one thing. But if they're some mapper's idea of a way to customize the map for his or her (or a company's) particular use then I think they should be removed. Especially if they're causing routing problems. What are they? What purpose do they serve? If those questions cannot be answered then I say delete them. Dave On Sun, Sep 13, 2020 at 6:21 PM Ticker Berkin wrote: > I've found quite a few proper roads mapped as closed ways with > [highway=unclassified, area=yes], but in the cases I've looked at so > far, there has also been a correct unclosed way to represent the road. > > I can't think of any method using style rules to detect the case when > there isn't this additional road, but my preference is to ignore these > areas and so avoid messing up junctions on major roads at the expense > of maybe not having a route over unclassified roads. > > Ticker > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ 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
Those mappers might have used this new proposal for highway=junction incorrectly. https://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction I'm not sure about their motives or reasoning but clearly a changeset comment or an email to those people is in order. Dave On Sun, Sep 13, 2020 at 12:02 AM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Yes, look like mapping errors (mapping for the renderer?). Maybe > area:highway=* was meant. I would not change the style for them. > > Gerd > > > Von: mkgmap-dev im Auftrag von > ael > Gesendet: Samstag, 12. September 2020 18:52 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] highway=unclassified & area=yes > > On Sat, Sep 12, 2020 at 05:27:03PM +0100, Ticker Berkin wrote: > > Hi all > > > > Diagnosing what seemed like superfluous navigation pop-up, eg "Turn > > left on A1", while driving on the A1, I discover quite a few junctions > > are surrounded by a closed way with tags [highway=unclassified, > > area=yes] > > > > https://www.openstreetmap.org/way/239371846 > > https://www.openstreetmap.org/way/239371836 > > https://www.openstreetmap.org/way/239754207 > > > > I haven't found any references to this being something that is > > acceptable or is wrong, so I don't know if these should be deleted from > > OSM and/or ignored by the mkgmap style. > > They look clearly wrong to me, but then I don't have any local > knowledge. > > ael > > ___ > 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Splitter 597 xml format output problem
Hi Gerd, Thanks will try that next time. My initial problem has been solved. Dave -Original Message- From: mkgmap-dev On Behalf Of Gerd Petermann Sent: 02 September 2020 12:20 To: Development list for mkgmap Subject: Re: [mkgmap-dev] Splitter 597 xml format output problem Hi Dave, question is why JOSM refuses to load version 0.5 To solve your problem you may use splitter option --handle-element-version=fake Gerd Von: mkgmap-dev im Auftrag von Dave Gesendet: Mittwoch, 2. September 2020 11:52 An: 'Development list for mkgmap' Betreff: [mkgmap-dev] Splitter 597 xml format output problem Hi, While trying to troubleshoot a map creation problem I had I decided to output the data from Splitter using --output=xml rather than pbf so I could open the resultant file in JOSM version 16812 (I wasn't sure if the unexpected results were caused by Splitter or Mkgmap), JOSM gave the following error message: Could not read file '2641.osm'. Error is: Unsupported version: 0.5 (at line 2, column 56). 100 bytes have been read As a work around I edited the osm version to 0.6 and added visible="true" version="1" to node and way id lines and was able to open the file. (was a simple file only containing lines/ways no polygons etc.) This is not something I plan to do often but thought you should be aware. Dave ___ 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
[mkgmap-dev] Splitter 597 xml format output problem
Hi, While trying to troubleshoot a map creation problem I had I decided to output the data from Splitter using --output=xml rather than pbf so I could open the resultant file in JOSM version 16812 (I wasn't sure if the unexpected results were caused by Splitter or Mkgmap), JOSM gave the following error message: Could not read file '2641.osm'. Error is: Unsupported version: 0.5 (at line 2, column 56). 100 bytes have been read As a work around I edited the osm version to 0.6 and added visible="true" version="1" to node and way id lines and was able to open the file. (was a simple file only containing lines/ways no polygons etc.) This is not something I plan to do often but thought you should be aware. Dave ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] garmin zumo XT
Thanks from me too. I currently have two Garmin Montanas but have always been curious about the more modern Zumo models. I can put that issue to rest now because I make my own maps with mkgmap. It's tricky enough getting everything right with a Garmin GPS that behaves "normally". My Montana works well enough to do what I want with it. On Mon, Aug 10, 2020 at 8:59 AM brad wrote: > Thanks Ticker > That helped a lot.What I learned is that the Zumo does not like any > custom types for points. I tested it with my typ file and the mapnik > one. If there is something in the type file, nothing shows up on the zumo > for that type code. It does show me what the garmin icons are, so I'll > have to work with that. It really unfortunate, lesson learned: don't buy > a zumo. > Brad > > On 8/7/20 4:42 AM, Ticker Berkin wrote: > > Hi Brad > > test-map:all-elements isn't documented except in it's source: > > > https://svn.mkgmap.org.uk/mkgmap/mkgmap/trunk/src/uk/me/parabola/mkgmap/reader/test/AllElements.java > > It generates a map with blocks of POI, lines and polygons, both named and > unnamed. > > You might need to zoom in to see things. > > The TYP file sameOrder.txt does not supply any icons; maybe Qmapshack > doesn't either - I've never used it. > > It does non-obvious things like using a non-standard background for half > the above blocks and no background for the others, ie like a transparent > map. This required setting POI_FLAG_TRANSPARENT for the test map to be > displayed on the devices I tried. Maybe qmapshack has a different > understanding. > > How are the polygons messed up? > > I don't know anything about zumo/themes - sorry. > > Ticker > > On Thu, 2020-08-06 at 16:10 -0600, brad wrote: > > Even if I load a theme file with nothing in it, it doesn't seem to matter. > I have worked out a set of typ codes for the roads and trails that work. > Now I'm looking at points (POI), and I'm getting almost nothing on the > Zumo. The only POI I'm getting is a WC using the Openfietsmap_full style > & mapnik typ. > > Ticker Berkin posted a while back about a test map, this sounds useful, > so I generated a map with this: > java -jar ~/Apps/Mkgmap/mkgmap-r4565/mkgmap.jar --gmapsupp --verbose > --order-by-decreasing-area test-map:all-elements > ~/Apps/Mkgmap/mkgmap-r4565/examples/typ-files/sameOrder.txt > But I must be missing something because that doesn't show any POI's on > Qmapshack on my desktop, and the polygons are messed up. > Is this feature documented anywhere? > > Any help is appreciated. > > > > ___ > 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 -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] New style function is_drive_on_left()
Hi Gerd, Have done a quick test and the new function seems to work fine, I will compile a map covering both Zambia and DRC to fully test it. But I have received an error message: Error in style Error: (lines:395) : Error: No function with name 'length()' So it seems the length() function may no longer work. Dave > ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Swaziland changed name to Eswatini
Hi Gerd, Putting the arrows on top of the way is the simplest but they interfere with the road names then. I used Joris' OSM styles for the map from which the examples came and as they were developed for drive on right countries the arrow conflicts had not been noticed before. For my own personal use I have just inverted the arrows but thought the feature would be handy. Dave Original Message From: gpetermann_muenc...@hotmail.com Sent: 6 June 2020 19:52 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Swaziland changed name to Eswatini Hi Dave, I would draw the oneway arrows in the middle of the road, but you are right, I typically cycle in drive-right countries, and when I cycle in the UK or Ireland I use a ferry to get there, so there is never a situation where I change the lanes. Gerd Von: mkgmap-dev im Auftrag von Dave Gesendet: Samstag, 6. Juni 2020 19:33 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Swaziland changed name to Eswatini Hi Gerd, It may not be clear if you only make maps for drive on right countries, but have a look at the attached images from a dual carriage way in Lusaka, Zambia is drive on left. If the type arrows are on the right of the carriageways the following is the result, at Low zoom level in BaseCamp the arrows are in the wrong direction. At medium zoom they are under the carriageways and at high zoom they are mixed together in the middle of the carriageways. This does not occur if the arrows are on the left. If you are only making maps covering one country it is fine but at a border post between countries of different drivesides there are likely to be one ways and the direction of the arrows would be important. Maps downloaded from http://garmin.openstreetmap.nl/ would benefit from this in particular. Dave Original Message From: gpetermann_muenc...@hotmail.com Sent: 6 June 2020 18:24 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Swaziland changed name to Eswatini Hi Dave, I don't understand why a oneway needs arrows on the left or right side. Or do you think about cycleways for which the position is not given otherwise? Anyway, it should be easy enough to add this tag in the same process that adds e.g. mkgmap_adminlevel2=* Gerd Von: mkgmap-dev im Auftrag von Dave Jackman Gesendet: Freitag, 5. Juni 2020 21:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Swaziland changed name to Eswatini Hi, This looks good to me. With regards to Joris' enquiry, if there is no way to use information in LocatorConfig.xml in a style file to differentiate between drive on left and right roads would it be possible to include code that uses LocatorConfig.xml information to add a tag to ways, when they are processed, indicating they are drive on right/left. This tag could then be used in the style file to allocate the appropriate one way type. In a drive on left country the oneway arrows should be on the left of the road, if they are on the right they will get mixed up in the centre of a dual carriage way for example. This makes more sense when 2 countries that drive on opposite sides of the road border each other and the map created covers both countries. Not something that happens in Europe but does in Central/Southern Africa, Zambia, DRC and Angola for example. Kind regards, Dave On Fri, 5 Jun 2020, 18:35 Joris Bo, mailto:jori...@hotmail.com>> wrote: Hi, No complains on the change, I have recently searched for this LocatorConfig.xml after reading some posts, but could not find it in the mkgmap zip. I like to visualize the one-way arrow differently for drive-left countries. And for that reason want to use a different overlay line code which shifts the arrow to the other side of the road in the same direction. Only because it looks nice for those who drive left. I see in your example that this property is mentioned there 😉 So I wondered if it would be possible to get this information available within the style rules. Kind regards and above all.. enjoy the weekend Joris -Oorspronkelijk bericht- Van: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> Namens Gerd Petermann Verzonden: vrijdag 5 juni 2020 17:00 Aan: Development list for mkgmap mailto:mkgmap-dev@lists.mkgmap.org.uk>> Onderwerp: [mkgmap-dev] Swaziland changed name to Eswatini See https://en.wikipedia.org/wiki/Eswatini The attached patch changes LocatorConfig.xml to reflect this change. Any complains? Gerd ___ 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 ___
Re: [mkgmap-dev] Swaziland changed name to Eswatini
Hi Gerd, It may not be clear if you only make maps for drive on right countries, but have a look at the attached images from a dual carriage way in Lusaka, Zambia is drive on left. If the type arrows are on the right of the carriageways the following is the result, at Low zoom level in BaseCamp the arrows are in the wrong direction. At medium zoom they are under the carriageways and at high zoom they are mixed together in the middle of the carriageways. This does not occur if the arrows are on the left. If you are only making maps covering one country it is fine but at a border post between countries of different drivesides there are likely to be one ways and the direction of the arrows would be important. Maps downloaded from http://garmin.openstreetmap.nl/ would benefit from this in particular. Dave Original Message From: gpetermann_muenc...@hotmail.com Sent: 6 June 2020 18:24 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Swaziland changed name to Eswatini Hi Dave, I don't understand why a oneway needs arrows on the left or right side. Or do you think about cycleways for which the position is not given otherwise? Anyway, it should be easy enough to add this tag in the same process that adds e.g. mkgmap_adminlevel2=* Gerd Von: mkgmap-dev im Auftrag von Dave Jackman Gesendet: Freitag, 5. Juni 2020 21:54 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Swaziland changed name to Eswatini Hi, This looks good to me. With regards to Joris' enquiry, if there is no way to use information in LocatorConfig.xml in a style file to differentiate between drive on left and right roads would it be possible to include code that uses LocatorConfig.xml information to add a tag to ways, when they are processed, indicating they are drive on right/left. This tag could then be used in the style file to allocate the appropriate one way type. In a drive on left country the oneway arrows should be on the left of the road, if they are on the right they will get mixed up in the centre of a dual carriage way for example. This makes more sense when 2 countries that drive on opposite sides of the road border each other and the map created covers both countries. Not something that happens in Europe but does in Central/Southern Africa, Zambia, DRC and Angola for example. Kind regards, Dave On Fri, 5 Jun 2020, 18:35 Joris Bo, mailto:jori...@hotmail.com>> wrote: Hi, No complains on the change, I have recently searched for this LocatorConfig.xml after reading some posts, but could not find it in the mkgmap zip. I like to visualize the one-way arrow differently for drive-left countries. And for that reason want to use a different overlay line code which shifts the arrow to the other side of the road in the same direction. Only because it looks nice for those who drive left. I see in your example that this property is mentioned there 😉 So I wondered if it would be possible to get this information available within the style rules. Kind regards and above all.. enjoy the weekend Joris -Oorspronkelijk bericht- Van: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> Namens Gerd Petermann Verzonden: vrijdag 5 juni 2020 17:00 Aan: Development list for mkgmap mailto:mkgmap-dev@lists.mkgmap.org.uk>> Onderwerp: [mkgmap-dev] Swaziland changed name to Eswatini See https://en.wikipedia.org/wiki/Eswatini The attached patch changes LocatorConfig.xml to reflect this change. Any complains? Gerd ___ 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___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Swaziland changed name to Eswatini
Hi, This looks good to me. With regards to Joris' enquiry, if there is no way to use information in LocatorConfig.xml in a style file to differentiate between drive on left and right roads would it be possible to include code that uses LocatorConfig.xml information to add a tag to ways, when they are processed, indicating they are drive on right/left. This tag could then be used in the style file to allocate the appropriate one way type. In a drive on left country the oneway arrows should be on the left of the road, if they are on the right they will get mixed up in the centre of a dual carriage way for example. This makes more sense when 2 countries that drive on opposite sides of the road border each other and the map created covers both countries. Not something that happens in Europe but does in Central/Southern Africa, Zambia, DRC and Angola for example. Kind regards, Dave On Fri, 5 Jun 2020, 18:35 Joris Bo, wrote: > Hi, > > > > No complains on the change, > > I have recently searched for this LocatorConfig.xml after reading some > posts, but could not find it in the mkgmap zip. > > I like to visualize the one-way arrow differently for drive-left countries. > > And for that reason want to use a different overlay line code which shifts > the arrow to the other side of the road in the same direction. > > Only because it looks nice for those who drive left. > > > > I see in your example that this property is mentioned there 😉 > > So I wondered if it would be possible to get this information available > within the style rules. > > > > Kind regards and above all.. enjoy the weekend > > > > Joris > > > > > > > > > > -Oorspronkelijk bericht- > Van: mkgmap-dev Namens Gerd > Petermann > Verzonden: vrijdag 5 juni 2020 17:00 > Aan: Development list for mkgmap > Onderwerp: [mkgmap-dev] Swaziland changed name to Eswatini > > > > See https://en.wikipedia.org/wiki/Eswatini > > > > The attached patch changes LocatorConfig.xml to reflect this change. Any > complains? > > > > 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
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
Those were my suggestions based on my rather limited experience. I knew there are options for the java environment that require a single hyphen (ex: -Xmx4000m -jar), and then there is the configuration file parameter (which I forgot) but I ignored those for the sake of simplicity. I think given what you just said, the need for a comprehensive help guide is essential. Otherwise these sorts of questions and the amount of time it takes to sort out the answers will only increase as the program grows more complicated. Also, if your 3rd point is true it only adds more confusion to the debate " 3) The typ file can appear anywhere but it is a good idea to place it at the end" How can it be "a good idea" to place the filespec for the TYP file at the end if it is also true that it "can appear anywhere"? The two assertions appear to be in conflict in my reading of that statement Dave On Thu, Jun 4, 2020 at 10:34 PM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > sorry, but your suggestion would be very wrong, esp. this one: > "These parameters must be preceded by a double dash (two hyphens with no > spaces between them) which are immediately followed by a command string. > Each such parameter must be terminated with a comma with no space before or > after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3)" > > 1) For historic reasons, some parameters require only one dash, e.g. -c or > -n. > 2) Only some parameters expect a comma separated option list, and since > r4517 a "dangling" comma in those lists should provoke an error message. > 3) The typ file can appear anywhere but it is a good idea to place it at > the end > > The option handling is very difficult to understand, esp. as mkgmap offers > so many different ways to do it. There is no way to document it in a few > short sentences. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Dave Swarthout > Gesendet: Donnerstag, 4. Juni 2020 17:05 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10 > > Pitney wrote: > "The issue with options and order (of precedence?) still confuses me after > using mkgmap for years." > > I reckon that was my point in opening this topic all along. I think I've > got it now and it makes sense but the documentation could still be made > clearer IMO. For example: > > Invoking the mkgmap java program involves supplying a list of parameters > or commands that allow the user to control the operation of the program and > the output generated by it. > > These parameters must be preceded by a double dash (two hyphens with no > spaces between them) which are immediately followed by a command string. > Each such parameter must be terminated with a comma with no space before or > after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3) > > All input file specifications (filename.ext) must follow the last option > in the invocation string. You may use a full path for that filespec as long > as it is enclosed in quotes. (Windows/Dos example: > "C:\Users\username\Downloads\Maps\MyState.osm") > > Any type file specification (filename.typ) containing custom bitmaps for > Garmin lines, polygons and points must be the last file specification in > the list of input files. > > Etc. > > Thanks also to Gerd for the latest releases which addressed the spurious > space issue and improved the program's error reporting. I'm sure these will > go a long way toward smoother operations for those of us who are only > casual users of mkgmap. > > Dave > > On Thu, Jun 4, 2020 at 9:12 PM Pitney mappit...@gmail.com>> wrote: > Hello > The issue with options and order (of precedence?) still confuses me after > using mkgmap for years. My solution is to not use option files and to hard > code all file references. Not good scripting practice but it works. > I think this is a case of where examples are worth a thousand words. I > understand in theory option and file order but do not know how to implement > it in practice. Examples (in a separate file?) and how to work out which > files they will effect may reduce confusion. > I only have a tablet in quarantine so I apologize for any formatting > issues. > Pitney > > On June 4, 2020, at 2:11 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk > <mailto:mkgmap-dev-requ...@lists.mkgmap.org.uk> wrote: > > Send mkgmap-dev mailing list submissions to > mkgmap-dev@lists.mkgmap.org.uk 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, vi
Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
Pitney wrote: "The issue with options and order (of precedence?) still confuses me after using mkgmap for years." I reckon that was my point in opening this topic all along. I think I've got it now and it makes sense but the documentation could still be made clearer IMO. For example: Invoking the mkgmap java program involves supplying a list of parameters or commands that allow the user to control the operation of the program and the output generated by it. These parameters must be preceded by a double dash (two hyphens with no spaces between them) which are immediately followed by a command string. Each such parameter must be terminated with a comma with no space before or after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3) All input file specifications (filename.ext) must follow the last option in the invocation string. You may use a full path for that filespec as long as it is enclosed in quotes. (Windows/Dos example: "C:\Users\username\Downloads\Maps\MyState.osm") Any type file specification (filename.typ) containing custom bitmaps for Garmin lines, polygons and points must be the last file specification in the list of input files. Etc. Thanks also to Gerd for the latest releases which addressed the spurious space issue and improved the program's error reporting. I'm sure these will go a long way toward smoother operations for those of us who are only casual users of mkgmap. Dave On Thu, Jun 4, 2020 at 9:12 PM Pitney wrote: > Hello > The issue with options and order (of precedence?) still confuses me after > using mkgmap for years. My solution is to not use option files and to hard > code all file references. Not good scripting practice but it works. > I think this is a case of where examples are worth a thousand words. I > understand in theory option and file order but do not know how to implement > it in practice. Examples (in a separate file?) and how to work out which > files they will effect may reduce confusion. > I only have a tablet in quarantine so I apologize for any formatting > issues. > Pitney > > On June 4, 2020, at 2:11 AM, 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..." > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Options file
Hi again Gerd, Regarding the change to the error message. Well, yes, what you've done should help, however, the error in my case wasn't caused by an improper file specification but by a typo in a parameter. I think it would be really helpful to tell the user that the error was in a parameter as opposed to in a filespec. Then if the latter is the case, the error message would supply the offending filespec by name enclosed in quotes. I am not clear what you are saying in the first paragraph in your latest reply. I'm looking for a way to make the required arrangement of the parameters and input files in the mkgmap invocation more prominent. I simply missed the one mention of it because it wasn't very obvious as it is, which is included in a paragraph about splitter. I realize you can't use bold text in the options file (which is a plain ASCII text file) but if it were set off in some way so it was more easily seen, that would help a lot. You said, "Maybe mkgmap should warn once when such an option is not the same for all processed tiles?" I'm unclear about this. Aren't all "tiles" processed in a run of mkgmap? I'm not using splitter. My maps are always limited to a small enough piece of my immediate area so I don't need splitter. When I'm traveling I download new pieces of the state or country as I move through it and compile new maps as I go. Thanks for your effort. I really appreciate it. Dave On Thu, Jun 4, 2020 at 12:10 PM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > I fear we can document whatever we want, this misunderstanding happens > again and again. With the --style option it is very obvious and the user > will find out. With > other options like --link-pois-to-ways it might take longer as its effect > is not so obvious. > Maybe mkgmap should warn once when such an option is not the same for all > processed tiles? > > I've changed the error message a little bit : Severe(Main): name: input > file 'name' doesn't exist. > Maybe it should be changed to "SEVERE (Main): name: input file 'name' > doesn't exist. Was it meant as an option?" because the "filename" has no > dot and thus no extension? > > Gerd > > > Von: Dave Swarthout > Gesendet: Donnerstag, 4. Juni 2020 01:11 > An: Gerd Petermann > Cc: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Options file > > I agree that the bit about parm placement should not be repeated. I saw > and read the text you provided but for some reason associated it more with > splitter rather than mkgmap as a whole. It doesn't stand out very well the > way it's written now. My bad. > > Also, I think it would be good if the filename in the error message was > enclosed in quotes. Again, it might be obvious to you developers that "file > name" is different than "filename" but it wasn't to me. If the message had > said "SEVERE (Main): name: file "name" doesn't exist, it would have been so > much more helpful. > > I'm all set now. Thanks very much, Gerd. > > Dave > > On Wed, Jun 3, 2020 at 10:24 PM Gerd Petermann < > gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> > wrote: > Hi Dave, > > See r4511. > I don't know if it helps, command line parsing depends on the OS / used > shell as well. > On windows this change allows to use --name-tag-list="name:de,name:en, > name" > > Reg. your other question about the documentation of the importance of > order in the options: This is documented and it is true for almost all > options, so it makes no sense to repeat the hint for each option: > "The order of the options is significant in that options only apply to > subsequent input files. If you are using splitter, you probably will need > to > put most of your options before '-c template.args' (this file is generated > by > splitter). " > > Gerd > > > Von: Dave Swarthout daveswarth...@gmail.com>> > Gesendet: Mittwoch, 3. Juni 2020 16:59 > An: Gerd Petermann > Cc: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Options file > > OMG! An extra space? > > Yep, that fixed it. Is there some way to make the processing of that parm > string more robust? > > Thank you for your quick response. > > On Wed, Jun 3, 2020 at 6:01 PM Gerd Petermann < > gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com > ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote: > Hi Dave, > > I think
Re: [mkgmap-dev] Options file
I agree that the bit about parm placement should not be repeated. I saw and read the text you provided but for some reason associated it more with splitter rather than mkgmap as a whole. It doesn't stand out very well the way it's written now. My bad. Also, I think it would be good if the filename in the error message was enclosed in quotes. Again, it might be obvious to you developers that "file name" is different than "filename" but it wasn't to me. If the message had said "SEVERE (Main): name: file "name" doesn't exist, it would have been so much more helpful. I'm all set now. Thanks very much, Gerd. Dave On Wed, Jun 3, 2020 at 10:24 PM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > See r4511. > I don't know if it helps, command line parsing depends on the OS / used > shell as well. > On windows this change allows to use --name-tag-list="name:de,name:en, > name" > > Reg. your other question about the documentation of the importance of > order in the options: This is documented and it is true for almost all > options, so it makes no sense to repeat the hint for each option: > "The order of the options is significant in that options only apply to > subsequent input files. If you are using splitter, you probably will need > to > put most of your options before '-c template.args' (this file is generated > by > splitter). " > > Gerd > > > Von: Dave Swarthout > Gesendet: Mittwoch, 3. Juni 2020 16:59 > An: Gerd Petermann > Cc: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Options file > > OMG! An extra space? > > Yep, that fixed it. Is there some way to make the processing of that parm > string more robust? > > Thank you for your quick response. > > On Wed, Jun 3, 2020 at 6:01 PM Gerd Petermann < > gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> > wrote: > Hi Dave, > > I think there is a superflous space in the name-tag-list before name: > name:en,loc_name:en,int_name,alt_name:en,short_name:en, name > > This means that mkgmap searches for an input file with the name 'name' and > that also explains the error message. > > Gerd > > > Von: mkgmap-dev mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Dave Swarthout < > daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>> > Gesendet: Mittwoch, 3. Juni 2020 12:33 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Options file > > This is a two-part question. > Firstly: > I have been trying to change my compilation method to use a config file > but am having problems. During my experimentations I managed to insert the > style file directive "--style-file=directory|zip-filename|url" _after_ the > filespec for the OSM data file. My map compiled without errors but was not > using my styles. I was very confused because it had always worked before. > It took me 20 or 30 minutes to discover that I had accidentally "misplaced" > my style file parameter in the mkgmp parameter list. Once I moved it in > front of the filespecs for my OSM data file and custom TYP file, all was > well again. > > I am assuming that the "options" file included with every mkgmap download > is the primary help file for running mkgmap. So I guess I'm asking if > someone would please add a sentence to the options file where the use _and > placement_ of the style file parameter is explained more completely. The > way it is now, one cannot know that the placement of that parameter is > important. Apparently, the placement of ALL parameters must come before > any filespecs in the mkgmap invocation but that important fact isn't > obvious (at least to me) from reading the options help file. > > A line saying "the style file parameter must appear before any references > to a file specification for input data or custom TYP file." inserted just > after the "=== Style options ===" section divider would be very helpful > > Or perhaps a line at the very top of the options file saying "Note: all > options specified herein must appear on the mkgmap invocation before any > reference to an OSM input file or a custom TYP file." > > *** > Secondly: > > The problem I'm having with using a configuration file might be related to > file specifications, but I'm not sure. My first try used the filespecs in > quotes as they appear in my parm specification. That didn't work. When I > compile a map using the scenario below, mkgmap p
Re: [mkgmap-dev] Options file
OMG! An extra space? Yep, that fixed it. Is there some way to make the processing of that parm string more robust? Thank you for your quick response. On Wed, Jun 3, 2020 at 6:01 PM Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi Dave, > > I think there is a superflous space in the name-tag-list before name: > name:en,loc_name:en,int_name,alt_name:en,short_name:en, name > > This means that mkgmap searches for an input file with the name 'name' and > that also explains the error message. > > Gerd > > > Von: mkgmap-dev im Auftrag von > Dave Swarthout > Gesendet: Mittwoch, 3. Juni 2020 12:33 > An: Development list for mkgmap > Betreff: [mkgmap-dev] Options file > > This is a two-part question. > Firstly: > I have been trying to change my compilation method to use a config file > but am having problems. During my experimentations I managed to insert the > style file directive "--style-file=directory|zip-filename|url" _after_ the > filespec for the OSM data file. My map compiled without errors but was not > using my styles. I was very confused because it had always worked before. > It took me 20 or 30 minutes to discover that I had accidentally "misplaced" > my style file parameter in the mkgmp parameter list. Once I moved it in > front of the filespecs for my OSM data file and custom TYP file, all was > well again. > > I am assuming that the "options" file included with every mkgmap download > is the primary help file for running mkgmap. So I guess I'm asking if > someone would please add a sentence to the options file where the use _and > placement_ of the style file parameter is explained more completely. The > way it is now, one cannot know that the placement of that parameter is > important. Apparently, the placement of ALL parameters must come before > any filespecs in the mkgmap invocation but that important fact isn't > obvious (at least to me) from reading the options help file. > > A line saying "the style file parameter must appear before any references > to a file specification for input data or custom TYP file." inserted just > after the "=== Style options ===" section divider would be very helpful > > Or perhaps a line at the very top of the options file saying "Note: all > options specified herein must appear on the mkgmap invocation before any > reference to an OSM input file or a custom TYP file." > > *** > Secondly: > > The problem I'm having with using a configuration file might be related to > file specifications, but I'm not sure. My first try used the filespecs in > quotes as they appear in my parm specification. That didn't work. When I > compile a map using the scenario below, mkgmap produces an error saying > "SEVERE (Main): name: file name doesn't exist" but does not supply a > filename. Not very helpful. > > Here is my mkgmap invocation string and the configuration file I'm trying > to employ: > > java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --family-id=18028 > --name-tag-list=name:en,loc_name:en,int_name,alt_name:en,short_name:en, > name --description="Lanna" --country-name=THAILAND --country-abbr=THA > "C:\Users\alask\Downloads\Maps\Lanna.osm" > "C:\Users\alask\Dropbox\Mapping\24983djs.TYP" > > And the config file: DJS.cfg follows: > > gmapsupp > route > index > bounds=C:\Users\alask\Downloads\Maps\bounds.zip > precomp-sea=C:\Users\alask\Downloads\Maps\sea.zip > generate-sea=land-tag=natural=background > location-autofill=is_in,nearest > housenumbers > max-jobs > drive-on=detect > add-pois-to-areas > link-pois-to-ways > process-destination > process-exits > code-page=1252 > check-routing-island-len=700 > remove-ovm-work-files > #road-name-config=mkgmap-rel/examples/roadNameConfig.txt > split-name-index > make-opposite-cycleways > order-by-decreasing-area > style-file=C:\Users\alask\Dropbox\Mapping\DJS_styles > > I'm sure you experts will easily see what I'm doing wrong. Thanks in > advance. > > Cheers, > > Dave > > -- > Dave Swarthout > Homer, Alaska > Chiang Mai, Thailand > Travel Blog at http://dswarthout.blogspot.com > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Options file
This is a two-part question. Firstly: I have been trying to change my compilation method to use a config file but am having problems. During my experimentations I managed to insert the style file directive "--style-file=directory|zip-filename|url" _after_ the filespec for the OSM data file. My map compiled without errors but was not using my styles. I was very confused because it had always worked before. It took me 20 or 30 minutes to discover that I had accidentally "misplaced" my style file parameter in the mkgmp parameter list. Once I moved it in front of the filespecs for my OSM data file and custom TYP file, all was well again. I am assuming that the "options" file included with every mkgmap download is the primary help file for running mkgmap. So I guess I'm asking if someone would please add a sentence to the options file where the use _and placement_ of the style file parameter is explained more completely. The way it is now, one cannot know that the placement of that parameter is important. Apparently, the placement of ALL parameters must come before any filespecs in the mkgmap invocation but that important fact isn't obvious (at least to me) from reading the options help file. A line saying "the style file parameter must appear before any references to a file specification for input data or custom TYP file." inserted just after the "=== Style options ===" section divider would be very helpful Or perhaps a line at the very top of the options file saying "Note: all options specified herein must appear on the mkgmap invocation before any reference to an OSM input file or a custom TYP file." *** Secondly: The problem I'm having with using a configuration file might be related to file specifications, but I'm not sure. My first try used the filespecs in quotes as they appear in my parm specification. That didn't work. When I compile a map using the scenario below, mkgmap produces an error saying "SEVERE (Main): name: file name doesn't exist" but does not supply a filename. Not very helpful. Here is my mkgmap invocation string and the configuration file I'm trying to employ: java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --family-id=18028 --name-tag-list=name:en,loc_name:en,int_name,alt_name:en,short_name:en, name --description="Lanna" --country-name=THAILAND --country-abbr=THA "C:\Users\alask\Downloads\Maps\Lanna.osm" "C:\Users\alask\Dropbox\Mapping\24983djs.TYP" And the config file: DJS.cfg follows: gmapsupp route index bounds=C:\Users\alask\Downloads\Maps\bounds.zip precomp-sea=C:\Users\alask\Downloads\Maps\sea.zip generate-sea=land-tag=natural=background location-autofill=is_in,nearest housenumbers max-jobs drive-on=detect add-pois-to-areas link-pois-to-ways process-destination process-exits code-page=1252 check-routing-island-len=700 remove-ovm-work-files #road-name-config=mkgmap-rel/examples/roadNameConfig.txt split-name-index make-opposite-cycleways order-by-decreasing-area style-file=C:\Users\alask\Dropbox\Mapping\DJS_styles I'm sure you experts will easily see what I'm doing wrong. Thanks in advance. Cheers, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Errors with latest versions
I've been using a fairly old version of mkgmap and getting excellent results. However, I just tried to compile a map using several of the latest releases and keep getting errors. This is the run using r4306 of mkgmap. The command line is the same one I used last week to compile some OSM data from Alaska java -Xmx4000m -jar mkgmap.jar --max-jobs --latin1 --family-id=261 --name-tag-list=name,int_name,alt_name,loc_name,short_name --gmapsupp --description="AlaskaCustom" --country-name=USA --country-abbr=USA --index --location-autofill="is_in,nearest" --copyright-message="ODbL by OSM contributors" --add-pois-to-areas --link-pois-to-ways --reduce-point-density=4 --reduce-point-density-polygon=8 --merge-lines --route --drive-on=detect,right --housenumbers --x-split-name-index --check-roundabouts --check-roundabout-flares --process-destination --process-exits --poi-address --style-file="C:\Users\alask\Dropbox\Mapping\DJS_styles" --generate-sea=land-tag=natural=background --precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" "C:\Users\alask\Downloads\Maps\Kenai.osm" "C:\Users\alask\Dropbox\Mapping\24983djs.TYP" Time started: Thu May 28 19:50:01 ICT 2020 java.lang.NoClassDefFoundError: crosby/binary/file/BlockReaderAdapter at uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.(OsmMapDataSource.java:79) at uk.me.parabola.mkgmap.reader.MapReader.(MapReader.java:42) at uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:155) at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:58) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:291) at uk.me.parabola.mkgmap.main.Main$1.call(Main.java:287) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: java.lang.ClassNotFoundException: crosby.binary.file.BlockReaderAdapter at java.net.URLClassLoader.findClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) at java.lang.ClassLoader.loadClass(Unknown Source) ... 10 more Exiting - if you want to carry on regardless, use the --keep-going option Any ideas? Thank you, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Thanks
Hi, I would like to add my thanks as well for all the hard work. Joris Bo, I have tried your style on <http://download.geofabrik.de/africa/zambia-latest.osm.pbf> zambia-latest.osm.pbf and there are a few strange results mainly to do with wetlands that have open water as inner parts of a multipolygon relation, most notably the Lukanga Swamp, as the patches of water show at zoom levels before the dark green background shows, in OSM the green of the swamp shows at lower zoom levels, before the water. This is a minor niggle though and I think your style works well. Lukanga Swamp lies almost dead centre of Zambia just to the west of Kabwe and in fact is not a true swamp rather more like a wetland with reed beds. Kind regards, Dave From: mkgmap-dev On Behalf Of mural...@montevideo.com.uy Sent: 26 May 2020 17:47 To: mkgmap-dev ; jori...@hotmail.com Subject: Re: [mkgmap-dev] Thanks Yes. Thanks to all who contribute to this tool. Your work that mimics the web layout is impressive. I will try to build a map of my country with that style an test it. Anyway, the OSM web style is a generic one, and for driving, or cycling, it's probably better to have a specialized map for that activity. Regards, M. _ De: "Joris Bo" Para: "mkgmap-dev" Enviados: Martes, 26 de Mayo 2020 8:53:48 Asunto: [mkgmap-dev] Thanks Hello, I like to say thank you, to Gerd, Ticker and others who put a lot of effort in the mkgmap development. With the new features for IS_IN and ‘Nearby poi’ it’s possible to make the maps much nicer. The online tools for creating routes maybe better then what basecamp can do, but as soon as you want your gpx or route on your garmin device and experience the same nice layout, then have a look at my style which creates a “99,9%” identical copy of the https://www.openstreetmap.org/ layout. https://github.com/Jorisbo/Mkgmap-Mapnik-Style-Garmin/blob/master/README.md Kind regards, Joris Bo ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev --- <https://www.montevideocomm.uy/Pymes/Factura-electronica-uc194> Con el nuevo beneficio fiscal, tu facturación electrónica puede ser sin costo. Informate si aplicás aquí. <https://www.montevideocomm.uy/Pymes/Factura-electronica-uc194> --- ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt]
Hi Ticker, It may be worth adding the following to Section 2: lang:BWA = en lang:KEN = en lang:MWI = en lang:ZMB = en lang:ZWE = en They are Botswana, Kenya, Malawi, Zambia and Zimbabwe. Owing to their colonial past the still have a similar naming format to the UK and roads with similar suffixes such as Avenue, Boulevard, Close, Crescent, Drive and Way will be found. Lusaka still has a Birdcage Walk. Dave -Original Message- From: mkgmap-dev On Behalf Of Ticker Berkin Sent: 27 April 2020 15:20 To: Development list for mkgmap Subject: Re: [mkgmap-dev] [Fwd: Re: Suggestions for roadNameConfig.txt] Hi Gerd Could you apply this patch Thanks Ticker On Fri, 2020-04-17 at 10:18 +0100, Ticker Berkin wrote: > Hi Gerd > > Here is a patch with the GBR suffixes commented out. > > Ticker ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] NSIS Script
Hi All, Just to let you know that compiling NSIS scripts with the Nullsoft Install System v3.05 there are warnings that ANSI installers are deprecated. By inserting the line 'Unicode true' in the script file a Unicode installer is created, I have inserted it below the 'SetCompressor' line. But the same effect can be achieved by the user editing the nsisconf.nsh file in the NSIS install directory and adding Unicode true to that file, doing this means any NSIS script run on the users machine will produce an Unicode installer regardless. >From the documentation: 4.8.2.9 Unicode true|false Generate a Unicode installer. It can only be used outside of sections and functions and before any data is compressed. Regards, Dave ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] yearly summary of mkgmap changes ?
Another year of incredible development of mkgmap. Thanks! It would be helpful to have a yearly summary of the major mkgmap changes as there are too many for me to keep track of by following the dev-digest (although this is very helpful). Items such as new options, option changes/updates, code/behaviour changes, depreciated options are things that spring to mind. My concern is that following the dev-digest is following the trees and I may have missed the big picture. In addition, changes/updates that are planned during the next year would be helpful and maybe users could be polled for their top 3, although I have not had much success when polling my users. An option to not compress splitter file output is still top 'o my list. ; The wiki may be a good place for this list rather than buried in the dev-digest. I would offer to help with this but head off to Chile for 3 months of needed hiking, using maps made with mkgmap (of course) and will be without net connection. I am happy to review but leave in 2 weeks. Thanks, -- pitney - end of message ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Error Cannot calculate mapid for xxx.txt
Hi Gerd, It is not caused by the size of my mapids as without any other changes but the moving of the option in the command line I no longer get the error. Prior to moving the position of the reference to my typ file I removed all reference to any typ file and the map compiled just fine. This would indicate to me that for some reason Mkgmap is treating the text file as an OSM input file and not finding the correct data and failing, ignoring any input files that follow. I hope this helps. Dave Sent from my Lineage phone Original Message From: gpetermann_muenc...@hotmail.com Sent: 15 November 2019 10:59 To: mkgmap-dev@lists.mkgmap.org.uk Reply to: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Error Cannot calculate mapid for xxx.txt Hi Dave, thanks for reporting. Seems to be a regression from r4336 http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4336 I can reproduce it with a command like this: java -jar mkgmap.jar --mapname= f:\osm\dummy.osm mytype.txt I agree that this should not happen but i wonder why you would use these very high mapids? Gerd Von: mkgmap-dev im Auftrag von Dave Gesendet: Freitag, 15. November 2019 09:51 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: [mkgmap-dev] Error Cannot calculate mapid for xxx.txt Hi, Since release 4336 I have been getting ‘Cannot calculate mapid for xxx.txt ‘ error while running Mkgmap, with xxx.txt being the path and name of my typ file which was created some time ago with TYPWiz 3 and has not been edited recently. I do not have this problem with release 4323. After some investigation I realised Mkgmap was treating the txt file as an input file and not attempting to compile it as a typ file. I found by changing the order of my command options and placing the --output-dir option followed by the txt file near the beginning before the –gmapsupp option it would compile the typ file. This order did not seem to matter before. I thought I would just let you know. Rgds, Dave ___ 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] Error Cannot calculate mapid for xxx.txt
Hi, Since release 4336 I have been getting 'Cannot calculate mapid for xxx.txt ' error while running Mkgmap, with xxx.txt being the path and name of my typ file which was created some time ago with TYPWiz 3 and has not been edited recently. I do not have this problem with release 4323. After some investigation I realised Mkgmap was treating the txt file as an input file and not attempting to compile it as a typ file. I found by changing the order of my command options and placing the --output-dir option followed by the txt file near the beginning before the -gmapsupp option it would compile the typ file. This order did not seem to matter before. I thought I would just let you know. Rgds, Dave ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] mkgmap experimental options --x..
Hello - Is there a listing of mkgmap experimental options? I know these are not listed in the docs (nor should they be) but I may find one that is helpful. Also it should be stated that support for these may not be available. Thanks, -- pitney - end of message ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] splitter option? (or new request)
Hello - Is there is an option to not compress pbf output files when using splitter? I use the split files as input to mkgmap. Osmium has an option "pbf_compression=none" which is placed in the json file as an option. This increases file size (appx double) but allows faster file reading/writing. Given the low cost of storage and the (relatively) high cost of processing/time this may be a useful splitter option. I am current using r591. Thank you, -- pitney - end of message ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] posting test
testing if pitney can post -- pitney - end of message ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How can I force the inners of a boundary relation to display?
Regarding my last post: The rule you gave me works but, as I said, it
renders any boundary that has a name, including in my case, a township
administrative boundary. However, it also renders both inner and outer
ways. I'm going to give up on that for now, unless anyone can think of a
way to convince mkgmap to render inners separately from outers. It's not a
big deal. I can easily live with what I have.
The non-rendering islands issue was my own fault. I forgot to assign
role=inner to the islands in a multipolygon relation they are also a part
of. The boundary rendered fine but there was no "land" showing. (The
islands are all outers in the Kodiak National Wildlife Refuge relation.)
Anyway, all is well now.
Thanks,
Dave
On Sat, Dec 8, 2018 at 9:10 PM Dave Swarthout
wrote:
> That does work but it makes all ways that are named boundary relations (
> with mkgmap:boundary_name =*) render with the same style. I can live with
> that but I'm still wondering if there is a way to force it to only operate
> on inners and only on ways of type boundary=protected_area ? Can I set in
> "relations" and test in "lines" for a new mkgmap:boundary_name, for
> example, boundary1_name?
>
> Another interesting problem I just noticed is that simple islands (not
> multipolygons) whose coastlines are also boundaries do not display as
> islands, only as members of the refuge they are a part of. The coastlines
> fail to display whether or not the above code is active or commented out so
> it must be a separate issue. Take a look at Village Islands inside the
> Kodiak National Wildlife Refuge. These display as continuous boundaries
> with my style [0x10e12], but there is no "land" inside the boundaries, only
> sea. So, these objects are tagged as place=islet, natural=coastline, but
> they are also outers in the Kodiak National Wildlife Refuge.
>
> Dave
>
> On Sat, Dec 8, 2018 at 6:13 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Dave,
>>
>> there is code in mkgmap to treat multipolygon relations. See
>> mkgmap:mp_created and mkgmap:stylefilter in
>> http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf
>> The multipolygon code produces those extra ways only for the outer rings.
>> If you just want to render the outlines you may use something like
>> mkgmap:boundary_name=* 0x10e12 resolution 19 continue]
>> at the top of the lines file.
>>
>> Gerd
>>
>>
>> Von: Dave Swarthout
>> Gesendet: Samstag, 8. Dezember 2018 11:30
>> An: Gerd Petermann
>> Cc: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] How can I force the inners of a boundary
>> relation to display?
>>
>> Yes, that's confusing to me. I included those snippets to illustrate what
>> I am currently using — maybe you can explain to me stepwise how those
>> boundaries get rendered?
>>
>> Is there code inside mkgmap that interprets such directives and applies
>> tags to the outer ways of relations? If there is then I assume the same can
>> be done for those inners. And you would be the one who can best answer that
>> question.
>>
>> Thanks for taking the time to explain.
>>
>> Dave
>>
>> On Sat, Dec 8, 2018 at 5:03 PM Gerd Petermann <
>> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
>> wrote:
>> Hi Dave,
>>
>> in the relations rule you set mkgmap:boundary_name but in the lines rule
>> you don't use that.
>>
>> Gerd
>>
>>
>> Von: mkgmap-dev > mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Dave Swarthout <
>> daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>>
>> Gesendet: Samstag, 8. Dezember 2018 03:18
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] How can I force the inners of a boundary relation
>> to display?
>>
>> Hi,
>>
>> I've been adding large Alaskan National Wildlife Refuges to OSM. The
>> boundaries weren't displaying so I added a directive in my relations file
>> modeled after the administrative boundary code in the default style that
>> adds a name to protected areas like so:
>>
>> (type=boundary | type=multipolygon) & boundary=protected_area & name=*
>> { apply
>> {
>> set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' |
>> '${name}';
>> }
>> }
>>
>> Then in my lines file I included a line style defined as:
>> boundary=nature_reserve | boundary=protected_
Re: [mkgmap-dev] How can I force the inners of a boundary relation to display?
That does work but it makes all ways that are named boundary relations (
with mkgmap:boundary_name =*) render with the same style. I can live with
that but I'm still wondering if there is a way to force it to only operate
on inners and only on ways of type boundary=protected_area ? Can I set in
"relations" and test in "lines" for a new mkgmap:boundary_name, for
example, boundary1_name?
Another interesting problem I just noticed is that simple islands (not
multipolygons) whose coastlines are also boundaries do not display as
islands, only as members of the refuge they are a part of. The coastlines
fail to display whether or not the above code is active or commented out so
it must be a separate issue. Take a look at Village Islands inside the
Kodiak National Wildlife Refuge. These display as continuous boundaries
with my style [0x10e12], but there is no "land" inside the boundaries, only
sea. So, these objects are tagged as place=islet, natural=coastline, but
they are also outers in the Kodiak National Wildlife Refuge.
Dave
On Sat, Dec 8, 2018 at 6:13 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Dave,
>
> there is code in mkgmap to treat multipolygon relations. See
> mkgmap:mp_created and mkgmap:stylefilter in
> http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf
> The multipolygon code produces those extra ways only for the outer rings.
> If you just want to render the outlines you may use something like
> mkgmap:boundary_name=* 0x10e12 resolution 19 continue]
> at the top of the lines file.
>
> Gerd
>
>
> Von: Dave Swarthout
> Gesendet: Samstag, 8. Dezember 2018 11:30
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] How can I force the inners of a boundary
> relation to display?
>
> Yes, that's confusing to me. I included those snippets to illustrate what
> I am currently using — maybe you can explain to me stepwise how those
> boundaries get rendered?
>
> Is there code inside mkgmap that interprets such directives and applies
> tags to the outer ways of relations? If there is then I assume the same can
> be done for those inners. And you would be the one who can best answer that
> question.
>
> Thanks for taking the time to explain.
>
> Dave
>
> On Sat, Dec 8, 2018 at 5:03 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Dave,
>
> in the relations rule you set mkgmap:boundary_name but in the lines rule
> you don't use that.
>
> Gerd
>
>
> Von: mkgmap-dev mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Dave Swarthout <
> daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>>
> Gesendet: Samstag, 8. Dezember 2018 03:18
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] How can I force the inners of a boundary relation
> to display?
>
> Hi,
>
> I've been adding large Alaskan National Wildlife Refuges to OSM. The
> boundaries weren't displaying so I added a directive in my relations file
> modeled after the administrative boundary code in the default style that
> adds a name to protected areas like so:
>
> (type=boundary | type=multipolygon) & boundary=protected_area & name=*
> { apply
> {
> set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}';
> }
> }
>
> Then in my lines file I included a line style defined as:
> boundary=nature_reserve | boundary=protected_area [0x10e12 resolution 19].
>
> This works well but the lines bounding the inner areas of these relations
> do not render. How can I make them display?
>
> Many thanks
>
> Dave
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How can I force the inners of a boundary relation to display?
Yes, that's confusing to me. I included those snippets to illustrate what I
am currently using — maybe you can explain to me stepwise how those
boundaries get rendered?
Is there code inside mkgmap that interprets such directives and applies
tags to the outer ways of relations? If there is then I assume the same can
be done for those inners. And you would be the one who can best answer that
question.
Thanks for taking the time to explain.
Dave
On Sat, Dec 8, 2018 at 5:03 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Dave,
>
> in the relations rule you set mkgmap:boundary_name but in the lines rule
> you don't use that.
>
> Gerd
>
> ____
> Von: mkgmap-dev im Auftrag von
> Dave Swarthout
> Gesendet: Samstag, 8. Dezember 2018 03:18
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] How can I force the inners of a boundary relation
> to display?
>
> Hi,
>
> I've been adding large Alaskan National Wildlife Refuges to OSM. The
> boundaries weren't displaying so I added a directive in my relations file
> modeled after the administrative boundary code in the default style that
> adds a name to protected areas like so:
>
> (type=boundary | type=multipolygon) & boundary=protected_area & name=*
> { apply
> {
> set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}';
> }
> }
>
> Then in my lines file I included a line style defined as:
> boundary=nature_reserve | boundary=protected_area [0x10e12 resolution 19].
>
> This works well but the lines bounding the inner areas of these relations
> do not render. How can I make them display?
>
> Many thanks
>
> Dave
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] How can I force the inners of a boundary relation to display?
Greg,
I do use a fill. It isn't a solid color but a small letter "R" to stand for
Reserve. That does show me where the inners are in a fashion but I would
like to experiment with getting them to display with some sort of a line.
On Sat, Dec 8, 2018 at 10:54 AM Greg Troxel wrote:
>
> Dave Swarthout writes:
>
> > I've been adding large Alaskan National Wildlife Refuges to OSM. The
> > boundaries weren't displaying so I added a directive in my relations file
> > modeled after the administrative boundary code in the default style that
> > adds a name to protected areas like so:
> >
> > (type=boundary | type=multipolygon) & boundary=protected_area & name=*
> > { apply
> > {
> > set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' |
> '${name}';
> > }
> > }
> >
> > Then in my lines file I included a line style defined as:
> > boundary=nature_reserve
> > | boundary=protected_area [0x10e12 resolution 19].
> >
> > This works well but the lines bounding the inner areas of these relations
> > do not render. How can I make them display?
>
> Not what you asked, but I reject the notion that because the tag is
> "boundary=protected_area" that what should be rendered is a line on the
> boundary, rather than an area. I view this tag as denoting something
> about the area within the polygon -- basically landuse=conservation
> and/or leisure=nature_reserve.
>
> So I would treat these boundary tags as being about the area and use a
> green fill, and not focus so much on the boundary proper.
>
> I realize that mine is not a universally-held view :-)
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] How can I force the inners of a boundary relation to display?
Hi,
I've been adding large Alaskan National Wildlife Refuges to OSM. The
boundaries weren't displaying so I added a directive in my relations file
modeled after the administrative boundary code in the default style that
adds a name to protected areas like so:
(type=boundary | type=multipolygon) & boundary=protected_area & name=*
{ apply
{
set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}';
}
}
Then in my lines file I included a line style defined as:
boundary=nature_reserve
| boundary=protected_area [0x10e12 resolution 19].
This works well but the lines bounding the inner areas of these relations
do not render. How can I make them display?
Many thanks
Dave
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Style for pipeline routes
Yes, of course. Nothing is simple. For the purposes of the thread I wanted
to keep us on a single track. Issues of rendering are definitely important
but would only have confused that discussion. And with this added
information about pipelines, I see how complicated the chore of rendering
really is.
I don't really do much with pipelines but seeing as my mapping focus is
Alaska, the TAPS relation is something I see frequently in my work. I'm a
little surprised that someone would use man_made=cutline + cutline=pipeline
but maybe that's the best way to handle it. How else could a situation like
that be dealt with I wonder? Is there a better way?
I'll do some more looking, as you suggest, and maybe something will occur
to me. Thanks for the information.
I've got an appointment soon that will keep me from my computer until
tomorrow. But I want to thank you for your continuing interest in this
issue.
Dave
On Thu, Nov 8, 2018 at 12:45 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Dave,
>
> this route=pipeline (1) discussion made me think about the rules in the
> relations style file.
> I started like this:
> 1) Use the overpass api to download all relations with route=pipeline into
> JOSM (there are no too many of them)
> 2) Check those way members that are not tagged man_made=pipeline
>
> Result:
> - Some mappers use ways tagged as highway to build the pipeline route.
> - Some mappers use ways tagged as man_made=cutline + cutline=pipeline
> - Some mappers add objects like substations to the route
> - Some mappers add waterway=canals
>
> The idea behind the first 2 is obvious:
> The pipeline is below or next to these ways, so why should I draw a new
> way. They transferred rules for multipolygons here.
> The idea reg. substations is probably that they strongly relate to the
> pipeline, similar to a bus stop which is part of route=bus relation.
> I did not yet understand the canals, but I am pretty sure there is also a
> reason for this.
>
> Now, what does that mean for the style rules?
> If we simply apply tags to the ways we risk that those ways are handled by
> only one rule in the lines file, e.g. that for the highway.
> With the canals it might be the other way : we risk to render the pipeline
> instead of the canal.
>
> If you care about that you have to add more rules to the lines file to
> handle those unexpected combinations, esp. if you want to render the
> pipeline
> and the highway with the correct names.
>
> Gerd
>
> (1)
> http://gis.19327.n8.nabble.com/How-to-tag-named-group-of-named-water-areas-tp5923692p5926360.html
>
>
> Von: mkgmap-dev im Auftrag von
> Dave Swarthout
> Gesendet: Donnerstag, 8. November 2018 06:14
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Style for pipeline routes
>
> Gerd,
>
> Thanks for the help on the pipeline rendering. Your rule had one error in
> it, the word "way" but mkgmap complained and provided the line number of
> the error so it was easy to fix. I checked to see if the sections of the
> TAP pipeline where I removed the tags were rendered properly, and they
> were, even the sections that are underground or overground show up fine. Of
> course, those ways already carry the location tag. My line styles have
> provisions for both.
>
> type=route & route=pipeline
> {
> apply {
> set man_made=pipeline;
> }
> }
>
> During the long conversation about tagging relation members that began by
> trying to come up with a method of tagging groups of lakes. Someone
> suggested creating a new relation type of "group" to handle such things. I
> didn't want to do that so stuck with using a multipolygon to group a set of
> lakes that have a single name. Then I encountered a situation that was
> ideal for an experiment, three rocks near Kodiak Island that have the name
> "Three Sisters Rocks". These are nodes, not ways, so the multipolygon
> approach really doesn't suit them well. I create a new relation, tagged it
> as type=group and added the nodes to it. Of course, the rocks do not render
> on the OSM slippy map but they did on mymkgmap file because I added the
> following rule to the relations style sheet:
>
> type=group & name=*
> {
> apply {
>set name='${name}';
> }
> }
>
>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Pipeline route style
Hi again, Gerd,
Thanks for the help on the pipeline rendering rule. I checked to see if the
style renders the pipeline in the area where I removed the tags from the
way and it rendered there perfectly. There was one error in the rule you
provided, the word "way". When I tried to compile my map, mkgmap complained
and provided the line number of the error so it was easy to fix. Here's the
corrected rule:
type=route & route=pipeline
{
apply {
set man_made=pipeline;
}
}
During that long thread about tagging groups of lakes, someone suggested
creating a new relation type of "group". I wasn't ready to try creating
something new so I grouped my lakes into a standard multipolygon as I've
always done. Then a few days ago I came across a situation that was perfect
to experiment with the idea of a type=group. There are three large rocks
near Kodiak Island (Alaska) that together have the name "Three Sisters
Rocks". (See http://www.geonames.org/5876155/three-sisters-rocks.html) The
rocks are nodes, not ways, so the multipolygon approach wouldn't work. I
created a new relation, tagged it as type=group and added the three nodes
to it, added a name tag and saved it. Of course, OSM doesn't know anything
about it, not even the name, because it has no idea what to do with a
multipolygon of type=group. Then, because of your hint I was able to
construct this rule which made them visible in my mkgmap images!
type=group & name=*
{
apply {set name='${name}';}
}
I can't decide whether to leave them as a "group" or try to invent a new
scheme to tag them. I certainly will not be pushing for the creation of a
new relation type anytime soon. Life is too short LOL
Best,
Dave
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Style for pipeline routes
Gerd,
Thanks for the help on the pipeline rendering. Your rule had one error in
it, the word "way" but mkgmap complained and provided the line number of
the error so it was easy to fix. I checked to see if the sections of the
TAP pipeline where I removed the tags were rendered properly, and they
were, even the sections that are underground or overground show up fine. Of
course, those ways already carry the location tag. My line styles have
provisions for both.
type=route & route=pipeline
{
apply {
set man_made=pipeline;
}
}
During the long conversation about tagging relation members that began by
trying to come up with a method of tagging groups of lakes. Someone
suggested creating a new relation type of "group" to handle such things. I
didn't want to do that so stuck with using a multipolygon to group a set of
lakes that have a single name. Then I encountered a situation that was
ideal for an experiment, three rocks near Kodiak Island that have the name
"Three Sisters Rocks". These are nodes, not ways, so the multipolygon
approach really doesn't suit them well. I create a new relation, tagged it
as type=group and added the nodes to it. Of course, the rocks do not render
on the OSM slippy map but they did on mymkgmap file because I added the
following rule to the relations style sheet:
type=group & name=*
{
apply {
set name='${name}';
}
}
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
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
"+ve" does indeed mean positive. It's an older shorthand term sometimes
used by scientists in the U.S.
Dave
On Wed, Nov 7, 2018 at 1:02 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Ticker,
>
> I think what confused me was the use of abbreviation cf (I did not know
> that) and that seaSize is a named constant which means
> it should be in upper case. See my changes in r4248.
> There is another confusing comment in Way.java:
> // this is unadulterated size, +ve if clockwise
> I guess that +ve means positive? This is hard to understand for a
> non-native speaker who grew up before SMS and Twitter and just learned to
> use smileys ;-)
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Dienstag, 6. November 2018 10:43
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] New branch for default typ file
>
> Hi Gerd
>
> It's not the name of the map feature that I'm talking about; rather the
> string representation of the type which my device displays, along with
> the name, when the map feature is selected.
>
> So, for instance, I'd like to use one of the other the Park
> representations, say 0x20, for leisure=garden. In the TYP file I'd like
> to set the String for this type, but don't want to override the colour
> / bitmap or whatever representation.
>
> Concerning the background polygon, I want to set it's area to bigger
> than the sea area, where the default is set in SeaGenerator.java with
> the comment:
>
> /**
> * When order-by-decreasing-area we need all bit of sea to be output
> consistently.
> * Unless _draworder changes things, having seaSize as BIG causes
> polygons beyond the
> * coastline to be shown. To hide these and have the sea show up to the
> high-tide
> * coastline, can set this to be very small instead (or use
> _draworder).
> *
> * mkgmap:drawLevel can be used to override this value in the style -
> the default style has:
> * natural=sea { add mkgmap:skipSizeFilter=true; set mkgmap:drawLevel=2
> } [0x32 resolution 10]
> * which is equivalent to Long.MAX_VALUE-2.
> */
> private static final long seaSize = Long.MAX_VALUE-2; // sea is BIG
>
> I don't think having method just used by addBackground adds anything to
> clarity. I could put a constant with MAX_VALUE-1 and comment into
> MapperBasedMapDataSource instead if you'd prefer
>
>
> Regards
> Ticker
>
> On Tue, 2018-11-06 at 00:16 -0600, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > Ticker Berkin wrote
> > > Does anyone know if it would be possible to change mkgmap to allow
> > > this?
> >
> > Not sure if this is what you want, did you try default_name?
> > See e.g.
> > amenity=emergency_phone [0x2f12 resolution 24 default_name 'Emergency
> > Phone']
> >
> > I don't understand the comment in the patch:
> > background.setFullArea(Long.MAX_VALUE-1); // cf:
> > SeaGenerator.java:
> > seaSize
> > Wouldn't it be better to have a method named something like
> > setAreaSizeToMax() ?
> >
> > Gerd
> >
> >
> >
> > --
> > 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
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug into the style file: default\inc\compat_lines
Thank you.
On Thu, Feb 22, 2018 at 1:34 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Dave,
>
> you should not need it, it was introduced in 2013 to allow using old style
> files, see
> http://www.mkgmap.org.uk/news/2013/12/22/more-flexibility-
> in-style-files-style
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag von
> Dave Swarthout
> Gesendet: Donnerstag, 22. Februar 2018 01:44:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] bug into the style file: default\inc\compat_lines
>
> I found the line and made the fix Steve described. But, while doing that I
> learned that none of my style files calls compat_lines. Nor is it called
> from any of the files in the standard style set that came with mkgmap 3994.
>
> Can you explain where it should be used and why?
>
> On Thu, Feb 22, 2018 at 4:37 AM, Steve Ratcliffe <mailto:st...@parabola.me.uk>> wrote:
> On 21/02/18 20:40, Ataro wrote:
> the default style file:? default\inc\compat_lines
> have a bug into the line 124:? { setaccess=no;
>
> have to be changed as follows: { setaccess no;
>
> That is true, thanks. I've fixed this now.
>
>
> Best wishes
> Steve
> ___
> 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
>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] bug into the style file: default\inc\compat_lines
I found the line and made the fix Steve described. But, while doing that I
learned that none of my style files calls compat_lines. Nor is it called
from any of the files in the standard style set that came with mkgmap 3994.
Can you explain where it should be used and why?
On Thu, Feb 22, 2018 at 4:37 AM, Steve Ratcliffe
wrote:
> On 21/02/18 20:40, Ataro wrote:
>
>> the default style file:? default\inc\compat_lines
>> have a bug into the line 124:? { setaccess=no;
>>
>> have to be changed as follows: { setaccess no;
>>
>
> That is true, thanks. I've fixed this now.
>
>
> Best wishes
> Steve
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r3971: - roadNameConfig_v1.patch by Carlos Davida which adds more countries and languages
Is anyone interested in adding a section for Thailand?I don't know how to add them to the configuration file . There are only a few prefixes in use in Thailand, the most common by far is "thanon" (ถนน = road), and a few names begin with "soi" (ซอย = lane). Most often you find the word "soi" at the end of a street name, for example, Thanon Mahidol Soi 5 (Mahidol Road Lane 5). Having just those two prefixes in play would help a lot. Cheers, Dave On Wed, Jun 14, 2017 at 7:06 AM, Carlos Dávila wrote: > In what way do you think it is more efficient? I thought you could be > talking about roads including more than one prefix1 in their name, eg. > "Avenida de la Calle Mayor", but I tested that name and I can't see any > difference in search behavior on MapSource. By the way, I found that when > road name includes two words listed in prefix1 you can still search by the > original full name: > Road name: Avenida de la Calle Mayor > prefix1:es = "Alameda", "Avenida", "Calle", "Callecita", "Paseo" (or > "Alameda", "Calle", "Avenida", "Callecita", "Paseo") > You can search both Avenida de la Calle Mayor and Calle Mayor > Perhaps that can give a clue to include original name in all cases > > El 14/06/17 a las 15:11, Alexandre Folle de Menezes escribió: > > >> Hola Carlos, >> >> I see that you are listing the prefixes in alphabetic order. I believe >> it would be way more efficient to put the most common prefixes first. >> >> For Portuguese, that would be (as I suggested in a previous message): >> >> -# portugese >> -prefix1:pt = "Rua", "Avenida", "Travessa" >> -prefix2:pt = "da ", "do ", "de ", "das ", "dos " >> +# portuguese >> +prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco" >> +prefix2:pt = "da ", "do ", "das ", "dos ", "de ", "d'" >> Saludos, >> >> Alexandre >> >> Em 13/06/2017 18:19, Carlos Dávila escreveu: >> >>> El 12/06/17 a las 06:22, svn commit escribió: >>> >>>> Version mkgmap-r3971 was committed by gerd on Mon, 12 Jun 2017 >>>> >>>> - roadNameConfig_v1.patch by Carlos Davida which adds more countries >>>> and languages >>>> - Improve comments >>>> >>>> Attached is version 2 of roadNameConfig.patch >>> I'm working in the completion of roadNameConfig file. I think if I could >>> somehow get a file with the list of road names in a map I could advance >>> faster in this task. Is there any tool to get it in the display project? >>> >> > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Missing sea and coastline while using Splitter
Hi, I have been compiling my own maps of my local areas (<600 mB) for a couple of years now but the other day for the first time I had to use splitter to divide a large .osm file. It took several tries to get everything working to the point that a useful map emerged from the process. However, my directives are not being processed so the map I get is a plain vanilla version The sea and coastline are invisible in the finished product. In addition, some of my custom lines are missing, for example, the ones used for unpaved roads and waterway direction. Inexplicably, most of my custom styles for both highways and POIs are visible. Th simple splitter command line I'm using is here: [code]java -Xmx1000m -jar ..\splitter\splitter.jar "C:\Users\alask\Downloads\Maps\Alaska.osm" --output-dir=..\splitter > ..\splitter\splitter.log [/code] I've seen examples of a splitter command that uses the *--precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" *argument in its call but iI tried that and it made no difference in the result. Anyway, this generates three .osm files (63240001, 2, and 3) which I then process with mkgmap and the following command line. This exact comand line (but without the template.args parameter) runs perfectly and creates a map containing all my styles and shows the coastline and sea properly: java -Xmx1000m -jar mkgmap.jar *-c "C:\Users\Alask\Documents\splitter\template.args"* --latin1 --family-id=24983 --name-tag-list=name:en,int_name,name --gmapsupp --description="Alaska" --country-name=USA --country-abbr=USA --index --location-autofill="is_in,nearest" --copyright-message="ODbL by OSM contributors" --link-pois-to-ways --add-pois-to-areas --reduce-point-density=4 --reduce-point-density-polygon=8 --merge-lines --route --drive-on=right --net --housenumbers --x-split-name-index --check-roundabouts --check-roundabout-flares --process-destination --process-exits --poi-address *--generate-sea=land-tag=natural=background --style-file="C:\Users\alask\Dropbox\Mapping\DJS_styles" --precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" --bounds="C:\Users\alask\Downloads\Maps\bounds" "C:\Users\alask\Dropbox\Mapping\24983djs.TYP"* Is the placement or order of the arguments important? Any other ideas or suggestions much appreciated. Thanks for your help, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] (no subject)
Hi, I have been compiling my own maps of my local areas (<600 mB) for a couple of years now but the other day for the first time I had to use splitter to divide a large .osm file. It took several tries to get everything working to the point that a useful map emerged from the process. However, my directives are not being processed so the map I get is a plain vanilla version The sea and coastline are invisible in the finished product. In addition, some of my custom lines are missing, for example, the ones used for unpaved roads and waterway direction. Inexplicably, most of my custom styles for both highways and POIs are visible. Th simple splitter command line I'm using is here: [code]java -Xmx1000m -jar ..\splitter\splitter.jar "C:\Users\alask\Downloads\Maps\Alaska.osm" --output-dir=..\splitter > ..\splitter\splitter.log [/code] I've seen examples of a splitter command that uses the *--precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" *argument in its call but iI tried that and it made no difference in the result. Anyway, this generates three .osm files (63240001, 2, and 3) which I then process with mkgmap and the following command line. This exact comand line (but without the template.args parameter) runs perfectly and creates a map containing all my styles and shows the coastline and sea properly: java -Xmx1000m -jar mkgmap.jar *-c "C:\Users\Alask\Documents\splitter\template.args"* --latin1 --family-id=24983 --name-tag-list=name:en,int_name,name --gmapsupp --description="Alaska" --country-name=USA --country-abbr=USA --index --location-autofill="is_in,nearest" --copyright-message="ODbL by OSM contributors" --link-pois-to-ways --add-pois-to-areas --reduce-point-density=4 --reduce-point-density-polygon=8 --merge-lines --route --drive-on=right --net --housenumbers --x-split-name-index --check-roundabouts --check-roundabout-flares --process-destination --process-exits --poi-address *--generate-sea=land-tag=natural=background --style-file="C:\Users\alask\Dropbox\Mapping\DJS_styles" --precomp-sea="C:\Users\alask\Downloads\Maps\sea.zip" --bounds="C:\Users\alask\Downloads\Maps\bounds" "C:\Users\alask\Dropbox\Mapping\24983djs.TYP"* Is the placement or order of the arguments important? Any other ideas or suggestions much appreciated. Thanks for your help, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Directionality of stop signs
There is an ongoing discussion on the Tagging list that is trying to determine how to tag the directionality of stop signs and yield signs as well as traffic_signals. The arguments is that if a highway=stop is placed on a node that is at the intersection of two ways, it applies to all vehicles crossing that node. However, if the stop sign applies to only one of the ways at an intersection, the highway=stop node must appear on the proper way at a slight distance from the actual intersection. How does a routing engine determine whether it's approaching from the "front" of the sign, in which case a stop penalty should be calculated, or from the other direction, in which case the sign can be ignored? Does anybody know whether the Garmin routing algo even considers stop signs? Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] fixme rules
On Tue, Mar 21, 2017 at 7:03 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > yes, I also think that mkgmap should not modify the data by default. +1 -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] if-then-else in style and style options
No problem, Gerd. I can't explain it much better and there are probably other demands on your time that are more important. What was the original goal of the "if-then" item on the "to-do" list? On Thu, Mar 16, 2017 at 10:30 PM, Andrzej Popowski wrote: > Hi Gerd, > > if-then-else is great. The last problem with admin boundaries doesn't > change it. We can apply the same the basic syntax for a rule, regardless if > inside or outside of if-then-else condition and simply accept, that rules > for boundaries can't be rewritten with if-then-else. They are simple rules, > so no much gain anyway. > > For me the primary application for if-then-else would be with > style-option, like this: > > if (mkgmap:option:...=true) then > ... > else > ... > end > > -- > Best regards, > Andrzej > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Parallel major roads to cycleways
There is a fledgling effort underway here in Chiang Mai to do a similar thing. This effort centers around the desirability of a route for bicycling. It deals with scenic vs dangerous roads for cycling and the 3 point system it uses might be insufficient for your needs but it might be adapted. Worth a look at any rate. https://wiki.openstreetmap.org/wiki/WikiProject_Thailand#Bicycling_tagging_.28currently_for_Chiang_Mai_only.29 Dave On Thu, Mar 16, 2017 at 5:06 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Hi, > > I just want to share an idea which might be interesting for cycling maps: > In Germany and probably also Austria) many major roads have a parallel > cycleway close to it, often only separated by a patch of grass or > natural=tree_row. > Example: A way with bicycle=designated : > http://www.openstreetmap.org/way/243499929 > runs next to highway=primary B213 > http://www.openstreetmap.org/way/328470949 > > I think nearly no cyclist likes to use those ways -- they are just a bit > safer but still lots of cars are running with 100 km/h next to you -- > so I think it would be good to have a way to separate them from other ways > where no major road is close. > > A possible way would be this: > Simiar to the new ResidentialHook which sets the mkgmap:residential tag we > might implement a > hook which collects major roads and calculates an area around it (maybe > 20m on both sides). > Each way (maybe only those with highway=* ) could be checked against those > areas in a way that a rule could > decide to "dislike" a way which is mostly within such an area when the map > is for cyclists. > I guess bridges and tunnels (or more generally the layer tag) needs > special handling here. > > Questions: > 1) Do you think this would good to have? > 2) If yes, what kind of information would be needed in the style? > > Gerd > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] if-then-else in style and style options
I don't like it but I don't know what to tell you to replace it with. All
such "tricks" make writing code less than straightforward and penalize the
casual user greatly. I am grateful to you and Ticker, et. al., for making
an effort to add this functionality but IMO if you resort to such
techniques it will be defeating the very purpose of creating the If-Then
construct, that purpose being to simplify the writing of these somewhat
strange style rules.
Respectfully,
Dave
On Thu, Mar 16, 2017 at 3:34 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi Andrzej,
>
> well, my problem is the possible misinterpretation caused by ambiguity
> caused by the if-then interpretation,
> but I think I have found a possible solution.
>
> Let's look at some rules for boundaries in the default style:
> v1)
> boundary=administrative { name '${mkgmap:boundary_name}' }
> boundary=administrative & admin_level<3 [0x1e resolution 12]
> boundary=administrative & admin_level<5 [0x1d resolution 19]
> boundary=administrative & admin_level<7 [0x1c resolution 21]
> boundary=administrative & admin_level<9 [0x1c resolution 22]
> boundary=administrative [0x1c resolution 22]
>
> We said we want to be able to use if-then like this:
> v2)
> if (boundary=administrative ) then
> { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> [0x1c resolution 22]
> end
>
> With r3838 this did not work, because the each rule needs an expression.
> Ticker suggested to add a dummy expression like 1=1 so we would write
> v3)
> if (boundary=administrative ) then
> 1=1 { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> 1=1 [0x1c resolution 22]
> end
>
> but this is also not working as 1=1 is interpreted as $1='1' instead of
> "true"
>
> Now I noticed that the scanner allows to use () as an empty expression.
> So instead of v1 one already can write
> v4)
> if (boundary=administrative ) then
> () { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> () [0x1c resolution 22]
> end
>
> If we document this we no longer have a problem with the "one expression
> two objects" syntax like this:
> a=b [0xc ... resolution 24][0x10801 resolution 24]
> because we still say that a rule must start with an expression and mkgmap
> can automaticalyl
> add "continue" or "continue with_actions" for all but the last type
> defintion.
>
> If you don't like the () 'trick' I can again try to make a style function
> like true() work.
>
> Gerd
>
> Von: mkgmap-dev im Auftrag von
> Andrzej Popowski
> Gesendet: Freitag, 10. März 2017 20:14:49
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> my idea was more simple, than your implementation. I just would like to
> create multiple map objects with single rule. I didn't put "continue"
> there, because I assumed, that all element type definition should be
> processed.
>
> Still "continue" could be applied, it would mean, that OSM object is
> processed further, possibly resulting in 3-rd map object or more. I
> think "continue" or "continue with_actions" could be added to last type
> definition.
>
> Any other more complicated rules, like adding actions after first type
> definition, could be written just like now, with multiple statements.
> While I appreciate more flexibility I'm afraid, it could clutter the style.
>
> --
> 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
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] if-then-else in style and style options
This is probably coming too late but I was going to suggest earlier that
the "end" directive be changed to "endif" to be more consistent with other
programming languages. I've been away from programming for a long time -
many languages (Java, C++, PHP) seem to use braces to end a control loop
nowadays. No big deal either way.
Also, in your example, would an "Else" directive before the "[0x1c
resolution 22]" the do the job? The program would still have to 'remember"
that it was evaluating the "if " statement above, however.
Dave
On Wed, Mar 8, 2017 at 3:34 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> It would not work because 1=1 is interpreted as
> $1='1'
> and that will probably not be true.
> Same effect with '1' = '1' .
>
> Maybe we can add a style function "true()" which always retrurns true for
> this?
>
> Gerd
>
> Von: mkgmap-dev im Auftrag von
> Ticker Berkin
> Gesendet: Mittwoch, 8. März 2017 09:25:34
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi
>
> I think you should document that you need a dummy condition, ie
>
> if (...) then
> 1=1 {action}
> ...
> 1=1 [0x1c ...]
> end
>
> (I assume this should work OK)
>
> Ticker
>
> On Wed, 2017-03-08 at 08:07 +, Gerd Petermann wrote:
> > Hi all,
> >
> > while writing the documentation I noticed this possible problem case:
> > The lines file in the default style contains these rules:
> > boundary=administrative { name '${mkgmap:boundary_name}' }
> > boundary=administrative & admin_level<3 [0x1e resolution 12]
> > boundary=administrative & admin_level<5 [0x1d resolution 19]
> > boundary=administrative & admin_level<7 [0x1c resolution 21]
> > boundary=administrative & admin_level<9 [0x1c resolution 22]
> > boundary=administrative [0x1c resolution 22]
> >
> > So, one may want to extract the clause boundary=administrative like
> > this:
> > if (boundary=administrative) then
> > { name '${mkgmap:boundary_name}' }
> > admin_level<3 [0x1e resolution 12]
> > admin_level<5 [0x1d resolution 19]
> > admin_level<7 [0x1c resolution 21]
> > admin_level<9 [0x1c resolution 22]
> > [0x1c resolution 22]
> > end
> >
> > The problem: It doesn't work because the lines
> > { name '${mkgmap:boundary_name}' }
> > and
> > [0x1c resolution 22]
> > are not a valid rules and the rule parser "forgets" that the
> > boundary=administrative expression will be added.
> >
> > What do you think? Should mkgmap support this syntax?
> >
> > Gerd
> >
> > Von: mkgmap-dev im Auftrag
> > von Gerd Petermann
> > Gesendet: Dienstag, 7. März 2017 20:10:52
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] if-then-else in style and style options
> >
> > Hi Andrzej,
> >
> > thanks, so I'll try to document the new syntax next.
> >
> > Gerd
> >
> > Von: mkgmap-dev im Auftrag
> > von Andrzej Popowski
> > Gesendet: Dienstag, 7. März 2017 17:40:16
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] if-then-else in style and style options
> >
> > Hi Gerd,
> >
> > I have run some tests with current code and spotted no problems. I
> > have
> > tested both, if-then-else statement and style-option.
> >
> > --
> > 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
> > ___
> > 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
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] if-then-else in style and style options
I'm sorry Gerd, I want to experiment with the new statements but I just don't have the time to play at the moment. Please commit the changes if you haven't already, and I'll get the new version and experiment when I can. Dave On Tue, Mar 7, 2017 at 9:09 PM, Gerd Petermann < gpetermann_muenc...@hotmail.com> wrote: > Any feedback on this? > > If nobody is interested in using if-then-else in style I'd be happy to use > only the style-option_v3.patch > for trunk. > > Gerd > > Von: mkgmap-dev im Auftrag von > Gerd Petermann > Gesendet: Mittwoch, 1. März 2017 15:54:02 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: [mkgmap-dev] if-then-else in style and style options > > Hi all, > > I've applied the style-option_v3.patch to the branch, for details see log > message: > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3827 > > I've also tried to fix the known problems with the interpretation of if > then statements, > so I hope it works now: > http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&path=%2F&; > > Just to make this clear: The if statements are translated to "normal" > rules, so you cannot do anything > with if-then which would not work without, you should also not (yet) > exprect run time improvements. > The advantage is that you don't have to repeat phrases. > > A complex sample that shows a possible usage. > # Roundabouts > if (junction=roundabout) then > if (mkgmap:option:single-roundabout=true) then > (highway=trunk | highway=trunk_link) [0x0c road_class=4 > road_speed=2 resolution 18] > (highway=primary | highway=primary_link) [0x0c > road_class=3 road_speed=2 resolution 19] > (highway=secondary | highway=secondary_link) [0x0c > road_class=2 road_speed=2 resolution 20] > (highway=tertiary | highway=tertiary_link) [0x0c > road_class=1 road_speed=1 resolution 21] > else > (highway=trunk | highway=trunk_link) [0x0c road_class=4 > road_speed=2 resolution 24 continue] > (highway=trunk | highway=trunk_link) [0x10801 resolution > 18] > > (highway=primary | highway=primary_link) [0x0c > road_class=3 road_speed=2 resolution 24 continue] > (highway=primary | highway=primary_link) [0x10802 > resolution 19] > > (highway=secondary | highway=secondary_link) [0x0c > road_class=2 road_speed=2 resolution 24 continue] > (highway=secondary | highway=secondary_link) [0x10803 > resolution 20] > > (highway=tertiary | highway=tertiary_link) [0x0c > road_class=1 road_speed=1 resolution 24 continue] > (highway=tertiary | highway=tertiary_link) [0x10804 > resolution 21] > end > # minor roundabouts need no overlay > (highway=unclassified | highway=minor ) [0x0c road_class=1 > road_speed=1 resolution 21] > highway=* [0x0c road_class=0 road_speed=1 resolution 22] > end > > If the corresponding block in the default style lines file is replaced > with these rules, you can > use option --style-option=single-roundabout to enable the rules which > don't add 0x180x lines as overlays for roundabouts. > > It might be possible to completely remove rules which would never be > triggered but that is quite complex, so I leave that for later. > > 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] if-then in style
Hi Gert,
In your example you use proposed=footway. I've never seen any tagging like
that - what does it mean? Give us a better description of what you're
trying to accomplish in your test statement
if (highway=proposed)
proposed=footway {delete highway}
surface=asphalt {echotags "test" } [... ]
end
On Mon, Feb 27, 2017 at 5:51 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi all,
>
> I try to make up my mind about what is needed and what is not.
>
> 1) I did not yet find a good reason to have an else clause, so I think we
> should start without implementing it
>
> unless one can give a good example.
>
>
> 2) The banch now implements the syntax
> if (EXPR) then
> ...
> end
> by adding the expression EXPR to each of the rules between 'then' and
> 'end' . Nested if-then are allowed.
> This might cause confusion in the following case:
>
> if (highway=proposed)
> proposed=footway {delete highway}
> surface=asphalt {echotags "test" } [... ]
> end
> What should happen for a way with highway=proposed, proposed=footway,
> surface=asphalt ?
>
> I'd expect that the 2nd rule with echotags is triggered, but it is not
> because after the interpretation of the if-then clause the rules look like
> this:
>
> proposed=footway & highway=proposed {delete highway}
> surface=asphalt & highway=proposed {echotags "test" } [... ]
>
> and since the first rule deletes the highway tag the 2nd isn't triggered.
>
>
> My suggested interpretation was like this:
> highway=proposed {set mkgmap:if:1000=true}
>
> proposed=footway & mkgmap:if:1000=true {delete highway}
>
> surface=asphalt & mkgmap:if:1000=true {echotags "test" } [... ]
>
>
> And I think that we should make sure that those generated special tags
> like mkgmap:if:1000 are not used directly by the style author .
>
> Another option might be to disallow the modification of any tag which
> appears in EXPR.
> No idea if that would be easier to implement but I fear that it would lead
> to very confusing error messages.
>
> Comments?
>
>
> ciao,
>
> Gerd
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] [Patch] unpaved roads
On Thu, Feb 9, 2017 at 1:26 AM, lig fietser wrote: I would suggest to set smoothness ~ '.*(very_bad|horrible|impassable)' and > give smoothness=bad a road_speed penalty. +1 That's what I did in my styles. It's a useful compromise. -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] To do: If-Then-Else
It would be easier for the parser without curly braces:
+1
I was gonna suggest not using curly-braces earlier but don't know enough
about parsers to make such a request. Seeing as they're already required in
other places, it would be advantageous to not require them again in this
context.
Dave
On Wed, Feb 8, 2017 at 6:28 PM, Steve Ratcliffe
wrote:
>
> Hi
>
> don't know if this helps:
>> I see one possible implementation for a conditional rule like
>> if () {
>> some rules
>> } else {
>> other rules
>> }
>> where would be something like tag=val, maybe also a parameter given
>> to the program.
>> If someone knows how to implement the syntax parser for such an
>> if-thent-else clause the evaluation could simply
>>
>
> It would be easier for the parser without curly braces:
>
> if ( some rules
> else
> other rules
> endif
>
> I could make that work.
>
> ..Steve
>
> translate the if () to a rule like
>> exp {set special_var_x=true;}
>> and then add this special tag with tag=true or tag!=true to each
>> conditional rule.
>> So, we would not need many changes in the evaluation of the rules, only
>> in the parser.
>>
>> Gerd
>>
>>
>> Von: mkgmap-dev im Auftrag von
>> Mike Baggaley
>> Gesendet: Dienstag, 7. Februar 2017 18:22:32
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] To do: If-Then-Else
>>
>> Hi Andrzej, can you not make use of mkgmap:country to handle this
>> scenario?
>>
>> mkgmap:country=DZA | mkgmap:country=AGO | mkgmap:country=SHN |
>> mkgmap:country=BEN ... {set continent=AF}
>>
>> continent=AF & landuse=farmland [0x10f01 level 1]
>>
>> Would mkgmap be better with a mkgmap:continent variable using
>> place=continent added?
>>
>> Regards,
>> Mike
>>
>> -Original Message-
>> From: Andrzej Popowski [mailto:po...@poczta.onet.pl]
>> Sent: 07 February 2017 12:39
>> To: mkgmap-dev@lists.mkgmap.org.uk
>> Subject: Re: [mkgmap-dev] To do: If-Then-Else
>>
>> Hi Dave,
>>
>> I think the idea is to include some preprocessing capability to style
>> interpreter.
>>
>> I develop a single style for my topo maps, but I need some possibility
>> to get a small variation in style depending on region. For example I
>> prefer to show landuse=farmland on a map of Africa but to remove it on a
>> map of Europe. So instead of maintaining 2 nearly identical styles, I
>> would like to get a conditional statement, something like:
>>
>> if (SHOW_FARMS) (
>> landuse=farmland [0x10f01 level 1]
>> )
>>
>> and then add (or not) an option to mkgmap like --style-define=SHOW_FARMS
>>
>> --
>> 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
>>
>>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] To do: If-Then-Else
if () {
some rules
} else {
other rules
}
That's exactly what I had in mind. Adding another parameter, like a
CONSTANT, to the invocation would work (especially for the case of building
clutter) but is not nearly as flexible or powerful as an internal
if-then-else capability to process style rules and act on them
conditionally.
On Wed, Feb 8, 2017 at 4:35 AM, Andrzej Popowski
wrote:
> Hi Gerd,
>
> could you implement simple conditional statements, which would be analyzed
> at the stage of reading style? Similarly like statement "include" is
> processed.
>
> I think the simplest version would contain 3 tokens:
> ifdefined CONSTANT
> ifnotdefined CONSTANT
> endif
>
> Scanner should look for ifdefined/ifnotdefined, check if CONSTANT exist
> and then analyze or skip rules until it finds token endif. It should
> support nesting. CONSTANT would be given as command line option. Or maybe
> even as an additional token, like "define CONSTANT".
>
>
> --
> Best regards,
> Andrzej
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] unpaved roads
I have never mapped any myself. Mostly, AFAIK, ice roads are used by large
vehicles on the North Slope of Alaska where they haul supplies to the oil
fields or out to wellheads in the Arctic Ocean. There are only three in
Alaska, two are service roads, one uses the ice_road=yes tag, the other
surface=ice while the last is actually a ferry route on a frozen river.
That one was tagged with ice_road=yes and surface=ice_road. I changed the
surface tag to surface=ice and left the other tags as is but I don't think
tagging a ferry route as an ice_road is correct.
As for tagging, I would consider them unpaved at the minimum because IMO
drivers of ordinary vehicles would generally want to avoid them. In the
case of the oil field service roads, those are most likely restricted
(acess=private) anyway so shouldn't be used in a routing scenario. Your
ice_road rule looks good to me and sidesteps the question of setting them
to unpaved nicely.
I found your full surface rule and inserted it into my lines style sheet
instead of the one I had been using.
Thank you.
On Tue, Feb 7, 2017 at 4:08 PM, lig fietser wrote:
> Talking about surface=ice, how do we handle ice_road=yes? Those roads are
> common in the Arctic regions and cross frozen lakes, so only accessible in
> winter. See http://overpass-turbo.eu/s/ls3
>
> In the generic new style map I made those roads unroutable.
> https://github.com/ligfietser/mkgmap-style-sheets/blob/
> master/styles/generic%20new/lines
> highway=* & ice_road=yes { addlabel 'ice road' } [0x10002 resolution 24]
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] To do: If-Then-Else
I came across the mkgmap ToDo list the other day and one item struck me as
something I would really like to see in a coming release. The ability to
evaluate If-Then-Else constructs would make writing, evaluating and
debugging style rules so much easier.
+1 on this item
Also, a little clarification please. The list item says:
- conditional includes in style files and/or if else statements
I don't understand this statement. Perhaps it's because I'm assuming a
"conditional include" means:
If (condition) Then include 'inc/address';
Or does it mean, for example,
If (condition) { add mkgmap:unpaved=1 }
Thank you in advance.
AlaskaDave
-- Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] unpaved roads
But none are "paved" in the usual sense of that word. I would hate to drive
on a "fine gravel" road, or an ice road, unless I was prepared for it. Even
if the fine gravel were on top of a compacted substrate it would present a
hazard to bicycles and motorcycles. I'm not sure I care how a "salt" road
is classified - I've never seen one let alone driven on one.
On Tue, Feb 7, 2017 at 2:41 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi all,
>
> I noticed that the wiki
> http://wiki.openstreetmap.org/wiki/Key:surface
> mentions a few more surface values which are considered unpaved compared to
> the default style.
> The current rule in the lines file contains this
> highway=*
> & (surface=cobblestone | surface=compacted | surface=dirt |
>surface=earth | surface=grass | surface=grass_paver |
>surface=gravel | surface=grit | surface=ground | surface=mud |
>surface=pebblestone | surface=sand | surface=unpaved |
>mtb:scale=* |
>tracktype ~ 'grade[2-6]' |
>smoothness ~ '.*(bad|horrible|impassable)' |
>sac_scale ~ '.*(mountain|alpine)_hiking' |
>sport=via_ferrata)
> { add mkgmap:unpaved=1 }
>
> The wiki also llists these as unpaved:
> gravel_turf , fine_gravel, ice, salt, snow, woodchips
>
> I think the rule should at least contain gravel_turf, snow, and woodchips.
> My understanding is that fine_gravel, ice , and salt are rather smooth
> surfaces.
>
> Comments?
>
> Gerd
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/unpaved-roads-tp5890722.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r3696: Fix documentation error.
On Mon, Oct 17, 2016 at 4:59 PM, Steve Ratcliffe
wrote:
> () - parentheses
> [] - square brackets
> {} - curly braces
> <> - angle brackets
>
> All those sound fine from a UK perspective. Any problems?
>
Perfect. Sounds good.
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit r3696: Fix documentation error.
So, are these changes included in the new style manual that comes in the
mkgmap installation package?
Also, a small note about terminology. This issue pops up now and again and
it's not a big one but I feel I should point it out. When you refer to what
we in the U.S. call parentheses (singular parenthesis), you use the term
"brackets". Correct me if I'm wrong, but don't most mathematicians use
parenthesis to describe this character? "(" or ")".
The term bracket usually implies either this "[" or this "]", while braces
(or less often "curly brackets"), refer to "{" or "}"
I know certain programming languages, C and Pascal among them, use the
parentheses, brackets and braces terminology outlined above.
Cheers,
Dave
On Sun, Oct 16, 2016 at 10:05 PM, svn commit wrote:
> Version mkgmap-r3696 was committed by steve on Sun, 16 Oct 2016
>
> Fix documentation error.
>
> - Carlos Dávila
>
>
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3696
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] site relations
Awesome! That did the trick.
I will try that next for my multipolygon lakes.
Many thanks Andrzej
On Mon, Oct 10, 2016 at 9:22 PM, Andrzej Popowski
wrote:
> Hi Dave,
>
> your rule looks good except you should use curly brackets.
> '${..}' means tag from relation while '$(..)' is a tag from member of
> relation. Try for example:
>
> type=site & name=* {
> apply {add name='${name}';}
> }
>
> Or you can concatenate site name with building name, if exist:
>
> type=site & name=* {
> apply_once { set name='$(name) - ${name}' | '${name}'; }
>
> }
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] site relations
Thanks, Andrzej,
I don't understand what you're saying. You're telling me to transfer the
name tag from my site relation to the objects it contains. But how do I
tell from within mkgmap what the objects are?
I added this line to my relation style file but nothing happened. The
members of this relation are buildings. How to apply the name to them?
Should I add some rules to the polygons style file?
type=site & name=* {
apply {set name='$(name)'; }
}
On Mon, Oct 10, 2016 at 5:43 PM, Andrzej Popowski
wrote:
> Hi Dave,
>
> you can transfer tags from a relation to its objects. Look for "apply"
> rule in style-manual.pdf .
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] site relations
Hi, I'm hoping to be able to render site relations in a way that would make them more visible. I have used them several times to group related objects but the names don't show when I compile my maps. Usually the sites I've tagged have been a group of buildings that are members of a named apartment complex, however, the names don't show up on my maps. Currently, there is no mention of type=site in my relations style file other than an echotags argument I inserted to indicate their presence. Another issue I have with relations is in tagging multipolygons, usually groups of lakes that have a single name. These do not display a name either. My relation file is the default mkgmap style which deals only with boundaries and transportation routes. Can anyone help explain how I can get this functionality? Thanks, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] compat_lines
I'm working on trying to add the maxspeed tag value to my highways by creating or modifying style directives. In my investigations I noticed that the file compat_lines is not being called by any of my style files. Also, the default styles don't seem to use or call it either. Why is it present then? Or am I just missing a call that includes it somewhere else? Thanks, Dave -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] incorporating available data sets into osm
I would also hasten to add that not all datasets contain good data. Even data that is good spatially will have tags attached that are sometimes helpful but often wrong. Case in point, much of the Adirondack Forest Preserve data obtained from the NYS Dept. of Environmental Conservation, even the areas designated as wilderness, is tagged as landuse=forest, which is completely wrong. Careful checking with other interested parties, OSM gurus, and local mappers is essential before attempting such an import. North Carolina has a lot of state supplied watershed data too. But it's out of date and has not kept up with the proliferation of housing developments, malls,etc. It's quite common to see a stream going right through a large parking lot or other new development. Cheers, Dave On Thu, Jul 7, 2016 at 11:38 AM, Greg Troxel wrote: > > 987654...@use.startmail.com writes: > > > I am new to osm and am not sure if this is the appropriate forum in > > which to ask this question so if it is not, I would appreciate any > > direction with respect to the best place to post it. > > Gerd is quite right about the import process and list. I would advise > joining the list and lurking for a month or two before posting, so that > you can calibrate yourself on the reactions. > > > I am working in the Northeastern US. Many streams are missing from the > > map. I found a site > > Note that one thing you can do is to merge other data and OSM and then > run mkgmap on it. I am 99% sure that if you do not distribute the > merged data, you will be ok with respect to OSM's ODbL. > > Doing this has been on my todo list for a while, for both hydro and > addressing. > > > " Data Distribution Agreement > > > > I. Description of Data to be Provided. > > > > The data provided herein are distributed subject to the > > following conditions and restrictions: > > > > SUBJECT DATA LAYERS > > > > For all data contained herein, NJDEP makes no > > representations of any kind, including, but not limited to, the > > warranties of merchantability or fitness for a particular use, > > nor are any such warranties to be implied with respect to the > > digital data layers furnished hereunder. NJDEP assumes no > > responsibility to maintain them in any manner or form. > > > > II.Terms of Agreement > > > > 1. Digital data received from the NJDEP are to be used > > solely for internal purposes in the conduct of daily affairs. > > This is inconsistent with the Contributor Terms. So this data cannot > be added to OSM. > > > * 3. Digital data received from the NJDEP may not be > > reproduced or redistributed for use by anyone without first > > obtaining written permission from the NJDEP. This clause is not > > intended to restrict distribution of printed mapped information > > produced from the digital data.* > > Again this is inconsistent. > > > 4. Any maps, publications, reports, or other documents > > produced as a result of this project that utilize NJDEP digital > > data will credit the NJDEP's Geographic Information System (GIS) > > as the source of the data with the following credit/disclaimer: > > > > "This (map/publication/report) was developed using New > > Jersey Department of Environmental Protection Geographic > > Information System digital data, but this secondary product has > > not been verified by NJDEP and is not state-authorized." > > This doesn't fit; OSM can attribute on wiki pages or changeset comments, > but cannot possibly demand (and does not, more importantly) that any map > have thousands of such disclaimers. > > > 5.Users shall require any independent contractor, hired > > to undertake work that will utilize digital data obtained from > > the NJDEP, to agree not to use, reproduce, or redistribute NJDEP > > GIS data for any purpose other than the specified contractual > > work. All copies of NJDEP GIS data utilized by an independent > > contractor will be required to be returned to the original user > > at the close of such contractual work. > > wow > > > Users hereby agree to abide by the use and reproduction > > conditions specified above and agree to hold any independent > > contractor to the same terms. By using data provided herein, > > the user
[mkgmap-dev] Create Test map
Hi, I am looking for a way to create a dummy OSM file so I can test icons and styles without actually adding them to the real OSM database. Let's say I'm working on a new icon, or a style rule, and want to run several tests to make sure the statements are correct and the icon looks good. Another use for such a file would be so I could see all my custom icons grouped close enough together to fit in one Basecamp screen shot. Can anyone suggest how I might do this? -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Has anyone built NO-LEFT icons like the way JOSM shows them?
Yes, AFAIK you would need multiple icons. I have done something similar for LPG stations. In my TYP file there is an icon for a standard fuel station. It's a miniature gas pump like the one GArmin has built in. I have another icon that contains the characters LPG (written vertically) to the left of a transparent section that is large enough to allow the pump icon to be visible too. This allows me to use various other custom fuel icons on my maps and merely overlay the LPG icon when needed. If you still have my TYP file you can check out the appearance of those icons yourself. I don't think it matters if you use track up or north up but Gerd will know the answer to that one. I can't recall how my display works as I almost never use track up. In my points style I use the following rules: amenity=fuel & fuel:lpg=yes [ 0x2f16 resolution 24 continue] #0x2f16 sets the letters LPG vertically but does not end processing amenity=fuel [0x2f01 resolution 24] To do a similar thing for turn arrows one would make separate icons (either square or round) that are transparent and put an arrow into each corner, as you suggested in your post; a left turn arrow, a right turn arrow, and whatever other symbols you want to show. Dave On Mon, Mar 21, 2016 at 10:35 PM, greg crago wrote: > JOSM shows individual NO LEFT turn icons at the right side of each > intersection, if it is set > > It seems to me I would have to make 4 separate TYP symbols and lock my GPS > in NORTH-UP mode to keep orientation. > > I would also have to place a small NO LEFT turn symbol in each quadrant of > each TYP symbol and only use the appropriate icon. > > I just do not know how to write the code. Has anyone done this? > > Greg > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.
gt;>>
>>>>> Walter
>>>>>
>>>>>
>>>>> *From:* greg crago
>>>>> *Sent:* Saturday, March 05, 2016 10:53 PM
>>>>> *To:* Development list for mkgmap
>>>>> *Subject:* Re: [mkgmap-dev] Question about using different ROAD
>>>>> CLASS's andROAD SPEED's for one linetype.
>>>>>
>>>>> I have re-read your posts and I think I am still confused about your
>>>>> statement
>>>>>
>>>>> "you can also club together POIs with different Icons to the same
>>>>> POI-List entry"
>>>>>
>>>>> Again, what is a 'POI-list entry' and how is this a benefit?
>>>>>
>>>>> I understand about specific store BRANDS and using unique POINTS and
>>>>> then use a GENERIC icon for the rest of the category.
>>>>>
>>>>> Greg
>>>>>
>>>>> On Sat, Mar 5, 2016 at 4:49 AM, Walter Schlögl <
>>>>> walter.schloegl-re...@aon.at> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> here an example for supermarkets
>>>>>>
>>>>>> shop=supermarket & (name~'Hofer.*' | name~'HOFER.*'){ set
>>>>>> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
>>>>>> shop=supermarket & (name~'Aldi.*' | name~'ALDI.*'){ set
>>>>>> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
>>>>>> shop=supermarket & (name~'Lidl.*' | name~'LIDL.*'){ set
>>>>>> mkgmap_symbol=yes}[0x3502 resolution 23 continue with_actions]
>>>>>> ...
>>>>>> shop=supermarket & mkgmap_symbol!=yes
>>>>>> [0x3500 resolution 23 continue with_actions]
>>>>>> shop=supermarket[0x2E02
>>>>>> resolution 21] # POI
>>>>>>
>>>>>> There is one common symbol on 3500 and dedicated symbols on 3501 and
>>>>>> above.
>>>>>> (Hofer and Aldi is the same supermarket with the same Logo but with
>>>>>> different names in Austria and Germany)
>>>>>> If I find a dedicated name of the supermarket, I will show the
>>>>>> corresponding symbol. (at the moment about 30 in my list)
>>>>>> All other supermarkets will get the common symbol.
>>>>>> And all of them will get additionally an unvisible POI (well, not
>>>>>> totally unvisible but just 1 dot) for the POI-List
>>>>>> Since this 1 dot POI is placed at resolution 21, I can click on it
>>>>>> also in lower zoom levels.
>>>>>>
>>>>>> I’m doing the same with amenity=fuel (more than 20), shop=car and
>>>>>> many others.
>>>>>> My map has many dedicated symbols which makes it easier to find a POI
>>>>>> at one short look even without using the search function.
>>>>>>
>>>>>> Walter
>>>>>>
>>>>>>
>>>>>> *From:* greg crago
>>>>>> *Sent:* Friday, March 04, 2016 11:37 PM
>>>>>> *To:* Development list for mkgmap
>>>>>> *Subject:* Re: [mkgmap-dev] Question about using different ROAD
>>>>>> CLASS's andROAD SPEED's for one linetype.
>>>>>>
>>>>>> I am still confused.
>>>>>> Can you explain it one more time and use an example.
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>> On Fri, Mar 4, 2016 at 11:13 AM, Bernd Weigelt
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Greg
>>>>>>>
>>>>>>> No, this line catches only cuisine=french *or* cuisine=sea food, not
>>>>>>> 'cuisine=french;sea food;...' This key/value pair will be ignored
>>>>>>>
>>>>>>> ---
>>>>>>> cuisine~'.*;.*'
>>>>>>> {
>>>>>>> set cuisine='${cuisine|part:}';
>>>>>>> }
>>>>>>>
>>>>>>> This rule helps, to use the first part in the POIs, but all other
>>>>>>> will be
>>>>>>> ignored, too. Have it in my filter file.
>>>>>>>
>>>>>>> My example in my first answer is not really good, because the rule
>>>>>>> has to be
>>>>>>> executed in a loop until the last value, but i think MKGMAP didn't
>>>>>>> do this
>>>>>>>
>>>>>>> Bernd
>>>>>>>
>>>>>>> Am Freitag, 4. März 2016, 10:01:52 CET schrieb greg crago:
>>>>>>> > Bernd, Is this the same as (in the line file)
>>>>>>> >
>>>>>>> > amenity=restaurant & (cuisine=french | cuisine=sea food |
>>>>>>> cuisine=german |
>>>>>>> > cuisine=. ) [0x01150 resolution 24]
>>>>>>> >
>>>>>>> > Greg
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> 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
>>>>>>
>>>>>
>>>>> --
>>>>> ___
>>>>> 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
>>>>
>>>> ___
>>>> 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
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Should we have a ADVANCED_DEFAULT Style?
I doubt people want to keep their styles secret but I could be mistaken. It is more likely that my styles and POI icons, or someone elses, are not ones you would particularly care about. For example, I have special POIs for milestones (common in Thailand), and assorted trees (trees common in Thailand) and style rules that test for them and place them on my maps. In addition, everything I'm developing is in a continual state of flux — I'm changing rules and icons all the time as my ideas about what's important (or fun) to map change. Would my styles and TYP file be of any interest to you? If so, merely say the word and I'll post them in my Dropbox and send you the links. Best Dave On Tue, Mar 8, 2016 at 9:13 AM, greg crago wrote: > I see many good questions about advanced mapping techniques and I am > trying to incorporate these ideas into my maps. > > I was wondering if we could combine these ideas into a ADVANCED_DEFAULT > style? > > I do not know if everyone wants to keep their own mapping styles secret, > but I have added to the default_style and do not mind sharing my own > additions. > > That way new mappers can analyze this code and get up to speed faster and > maybe be able to add more ideas to the community. > > If you do not like a feature, you can always remove that piece of code. > > My goal is to try to use mkgmap to map maps that look like Garmin City > Navigator. > > So far I have added custom POI symbols for brand specific businesses > (fuel, fast food, resturants) > > Added 1 way arrows > Added Bridges over ways > Added Bicycle lanes. > > Greg > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway arrows
@nwillink Now that's a clever solution. Many thanks. I'll start working on it. @Andrzej : I did not try to see if the oneways that failed to show in Basecamp were visible on my Montana. Thanks for the tip. I think we can put this thread to rest now. Again, thanks to all for your help. On Tue, Mar 8, 2016 at 7:56 AM, Andrzej Popowski wrote: > Hi, > > it is worth noting, that on newer nuvis oneway arrows are displayed by > default. They are present on ways with no TYP graphics, and possibly on > non-bitmap graphics too, but I'm not sure about later. > > Other peculiarity of non-bitmap graphics is that way's width is scalable > on nuvis, depending on zoom. > > -- > Best regards, > Andrzej > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway arrows
Well, that seems to explain why my attempts aren't working. It also explains why the default style uses arrows that lie outside the highway lines. Garmin is overwriting the "arrow highway" line but the part it overwrites is the invisible part. Knowing Garmin overwrites bitmaps with those low-numbered ways means I would have to bump all highway codes up a notch and reassign them to get the effect I want. And that may produce unseen repercussions later. Or, alternatively, I could go with Wesley's or Greg's approach. I'll need to think about that for a while. As always, thanks for your help everyone. Cheers, Dave On Sun, Mar 6, 2016 at 10:34 PM, greg crago wrote: > I like Wesley's ARROWS built in to the ROAD, but my ARROWS are 16 pixels > wide and sit UNDER the road and you see them protrude outside the edge of > the road. (see picture) > > Here is my TYP file (look for 0x26) > > and my other post has my code for SECONDARY roads in my line file. > > I would like to get arrows built in to the road, mine looks bad, but does > convey the 1-way direction. > > It seems many of us are all working on similar features and it would be > nice if we all got together and made a SUPER-DEAFULT STYLE, where we could > combine all of these advanced features and if mappers do not wish to use > them, they can just DELETE those sections. > > I also wanted BRIDGES to be ON TOP, so I moved MOTORWAY linetype to 0x0b > and defined BRIDGES to be 0x01 and it works. Pinns suggested this on his > website, no roads cross 0x01 linetype. > > Greg > > On Sun, Mar 6, 2016 at 7:48 AM, Minko wrote: > >> I dont know how Gregs typ file looks like. It depends how you have >> configured your type of highway, either a bitmap or vector image. >> Bitmap (arrow) on top of a vector image will not work in most cases, >> unless that bitmap is one of the major line types as in the following >> example: >> >> Bitmap: >> >> [_line] >> Type=0x02 >> UseOrientation=N >> Xpm="32 3 2 1" >> "! c #0030FF" >> " c none" >> " " >> " " >> " " >> ;12345678901234567890123456789012 >> String1=0x04,cycle route >> String2=0x03,fietsroute >> String3=0x02,Radroute >> ExtendedLabels=Y >> FontStyle=SmallFont >> CustomColor=No >> [end] >> >> Vector: >> >> [_line] >> Type=0x03 >> UseOrientation=N >> LineWidth=5 >> BorderWidth=1 >> Xpm="0 0 2 0" >> "1 c #B4B4B4" >> "2 c #525252" >> String1=0x04,principal highway >> String2=0x03,N-weg >> String3=0x02,Hauptverbindungsstraße >> ExtendedLabels=Y >> FontStyle=SmallFont >> CustomColor=No >> [end] >> >> -- >> >> Dave wrote: >> >> @Minko - But Greg says he gets the results I want with the rules he's >> using. So how to explain that? >> >> >> ___ >> 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway arrows
@Minko - But Greg says he gets the results I want with the rules he's using. So how to explain that? On Sun, Mar 6, 2016 at 3:41 PM, Minko wrote: > The problem is that most Garmins don't display a bitmap on top of a vector > line (esp. the major highway types like 0x01, 0x02 etc will be put on top > of other lines). So you have to place the arrow on one side of the > underlying highway, instead of in the center. See the typ file of the new > generic map. This example will not work in some units though, it could be > that your Garmin still makes a mess out of it :-( > > > [_line] > Type=0x1 > UseOrientation=N > Xpm="32 15 2 1" > "! c #0065FF" > " c none" > "" > "" > "" > "" > "" > "" > "" > "" > "" > "" > "" > "" > " ! " > " !! " > " ! " > ;12345678901234567890123456789012 > String1=0x04,oneway > String2=0x03,eenrichtingsverkeer > ExtendedLabels=Y > FontStyle=NoLabel (invisible) > CustomColor=No > [end] > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway arrows
@Greg - Thanks, I'm working on it but still no luck. I reproduced your code for primary highways, used the continue statement as you did, removed my old arrow rules, made sure my new "arrow way" (also used 0x26 for a code) has a transparent background but I still can't get it to work. @Wesley - Thank you as well. Your approach is interesting and I like it but it seems to me I should be able to accomplish making those arrows overlay my highways by using the proper rules in the same img file. On Sun, Mar 6, 2016 at 5:01 AM, greg crago wrote: > Dave, I have done the same thing with 1 way arrows (linetype 0x26 for me) > > I have only done this for SECONDARY, TERTIARY, RESIDENTIAL, and SERVICE > roads. Here is my 'line' code for SECONDARY roads: > > highway=secondary & ( network=e-road | int_ref=* ) [0x04 resolution 19-19 > continue] > highway=secondary & oneway=yes [0x26 resolution 19 continue] > highway=secondary & cycleway=lane [0x00 resolution 19 continue] > highway=secondary & bridge!=yes [0x04 road_class=2 road_speed=3 resolution > 19 continue] > highway=secondary & bridge=yes [0x01 road_class=2 road_speed=3 resolution > 22] > highway=secondary_link & bridge!=yes [0x08 road_class=2 road_speed=1 > resolution 19 continue] > highway=secondary_link & bridge!=yes [0x23 resolution 19 continue] > highway=secondary_link & oneway=yes [0x26 resolution 19 continue] > highway=secondary_link & cycleway=lane [0x00 resolution 19 continue] > highway=secondary_link & bridge=yes [0x01 road_class=2 road_speed=1 > resolution 22] > > I do this for both the road and the *_link, This is 'mid-way' in my code. > You can see I also have overlay for BICYCLE lanes and BRIDGES > It works and looks great. > > Greg > > On Sat, Mar 5, 2016 at 1:28 AM, Dave Swarthout > wrote: > >> I would like to see oneway arrows drawn on top of the highway lines the >> way OSMAnd does it. I tried moving my oneway arrow rules to after the other >> highway rules were finished processing but they completely disappeared. The >> lines style rules are below and in my TYP file are defined as blue arrows >> on a transparent background. >> >> >> # display direction arrows on highways >> highway=* & (oneway=yes | oneway=1 | oneway=true) [0x1 resolution 24 >> continue with_actions] >> highway=* & oneway=-1 [0x10001 resolution 24 continue with_actions] >> >> Thanks, >> Dave >> >> ___ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] Oneway arrows
I would like to see oneway arrows drawn on top of the highway lines the way OSMAnd does it. I tried moving my oneway arrow rules to after the other highway rules were finished processing but they completely disappeared. The lines style rules are below and in my TYP file are defined as blue arrows on a transparent background. # display direction arrows on highways highway=* & (oneway=yes | oneway=1 | oneway=true) [0x1 resolution 24 continue with_actions] highway=* & oneway=-1 [0x10001 resolution 24 continue with_actions] Thanks, Dave ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
[mkgmap-dev] POIs to areas
Hi, I've got a little problem that I need help with. I use the "--add-pois-to-areas" switch when compiling a map. I use a small house icon to represent a building when the tags are building=house or building=home. However, if the building has been entered into OSM as a polygon then my icon is centered inside of it, which is consistent with the "--add-pois-to-areas" switch. What I want is a way to tell mkgmap to skip placing the house icon whenever the building it's describing is an area. Thanks for your help. -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Problem uploading data to JOSM wit 20 hour old OSM data, maybe a SPLIITTER issue?
Greg, Using JOSM and working with data that other people are also working with is a recipe for disaster. Resolving the inevitable conflicts that will arise is tedious and complicated. I have spent hours resolving conflicts made by "the other user" only to find out later that it was _my own data_ I was working against. The method you're trying to use will only work well if you're the only person modifying the data in that particular part of the world. Another possibility is to download smaller areas to work in which will keep the number of edits down. That way you won't have thousands of conflicts when you do get Internet again. And if you do, you won't lose much work. Not very satisfying I'm afraid but working with a live Internet connection is by far the best option. On Sun, Feb 28, 2016 at 9:42 PM, greg crago wrote: > I have thousands of map errors I have collected on my GPS from ground > observations. I just have not had time to upload them to OSM. I do not have > Internet access all the time. > > Downloading many states and then breaking them up using a 'splitter-type' > program, gives me the flexibility to edit sections of the country I want to. > > I thought UPLOAD conflicts only occur when objects I HAVE MODIFIED, > conflict with objects in the OSM database that have been modified since I > download MY VERSION. If I have large areas of 'outdated' OSM data, that I > do not modify, I should not have any problems when I upload, since I am not > sending that 'untouched' data back to OSM, correct? > > I thought this was a viable 'offline' solution. I do not know how to > filter overpass to download state-by-state regions. GEOFABRIK has already > done this, if SPLITTER kept the version dataset information., I could use > it. > > Greg > > On Sat, Feb 27, 2016 at 4:08 PM, Nelson A. de Oliveira > wrote: > >> On Sat, Feb 27, 2016 at 5:44 PM, greg crago wrote: >> > I want to download sections of the osm database (USA- Michigan) and >> make off >> > line changes in JOSM and upload back to OSM when I am back online. >> >> Will you edit the whole state? >> Do you really need to have all of it? >> >> Editing large areas and a lot of objects isn't usually the best thing >> to do: it can cause duplicate data in OSM and/or you will hit a lot of >> conflicts. >> >> overpass is the easiest way to get fresh data, but you need to filter >> a smaller region or some specific data that you want. >> ___ >> 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Anyone determine which linetypes are NOT visable in BaseCamp?
Huh? I can define the width of a way, its color, whether it is dashed or solid in my TYP file. Are you saying I don't need a TYP file to make a dashed, brown line of width 5 pixels with hex code 0x1007 that is then assigned via a style rule to an OSM way? If I do not then I agree; I don't understand anything about TYP files. Can you explain in a little more detail what you are trying to tell me? On Sat, Feb 27, 2016 at 4:45 PM, Minko wrote: > See also http://www.openfietsmap.nl/tips-tricks/customize > > ------ > > Hi Dave, > > > it seems you don't understand the meaning of TYP file. > > It is used to define how POI / lines / areas are displayed (in Basecamp > and the device). > > Such a file is not part of the mkgmap distribution, don't know why, maybe > the reason > > is that some devices don't support TYP files, maybe it's because > programmers aren't > > much interested in it ;-) > > You can find samples in other wellknown styles, e.g. here: > > https://github.com/ligfietser/mkgmap-style-sheets > > which contains the styles used for Minkos cycling maps: > > http://www.openfietsmap.nl/home > > I don't know if this page is up to date, but it may help as well: > > http://www.openfietsmap.nl/procedure > > > Gerd > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Anyone determine which linetypes are NOT visable in BaseCamp?
I am using line types 0x1 through 0x1001b for various lines and they all display in BC and on my Montana. 0x1 and 0x10001 are the oneway arrows that display alongside ways that are oneway. Of course, I have the styles defined in my lines file and the hexadecimal codes are in a custom TYP file. Hope this helps. Dave On Fri, Feb 26, 2016 at 5:16 AM, greg crago wrote: > Thank you, that worked well. > > In BaseCamp v4.6.1 linetype 0x17,0x2c,0x30-0x3f are NOT VISIBLE. > > Attached is a map that I changed all COLORS for lines and polygons to RED, > except for the background container 0x4b is white. This map is located NE > of London > > The Garmin Montana 600 can see linetypes 0x00-0x3f and polygons 0x01-0x7f > > Has anyone got EXTENDED linetype to be visible in BaseCamp? I used > 0x10001-0x10005 but they show up as thin lines only (no thickness) > > Greg > > On Thu, Feb 25, 2016 at 10:09 AM, Gerd Petermann < > gpetermann_muenc...@hotmail.com> wrote: > >> Hi Greg, >> >> >> try this command: >> >> java -jar mkgmap.jar test-map:all-elements >> >> >> to generate a map containing all possible types for lines and poi. >> >> >> Gerd >> >> >> -- >> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk < >> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von greg crago < >> gregcr...@gmail.com> >> *Gesendet:* Donnerstag, 25. Februar 2016 15:57 >> *An:* Development list for mkgmap >> *Betreff:* Re: [mkgmap-dev] Anyone determine which linetypes are NOT >> visable in BaseCamp? >> >> I realize that not all linetypes are visible in all GPS units. >> >> Since map development is easiest when I can see my results quickly, using >> BaseCamp is a great tool to see my results without having to download .img >> files to my GPS every 10 minutes. >> >> Do any of you 'mappers' have a TEST MAP file containing ALL POSSIBLE >> LINETYPES so I can use it and view in BaseCamp, or any GPS device to >> determine a USEFUL SET of visible LINETYPES. I think this would be a good >> to for mappers to have, otherwise, every time you want to add a new >> linetype, you have to see if it is visible in BaseCamp (or whatever >> software you are using) AND you need to verify that linetype is also >> visible in your GPS unit. >> >> I realize this 'test area' would have to exists in 1 location in the >> world, but you could make in the the ocean somewhere and just give >> coordinates so other mappers can find it. >> >> Has anyone else determined additional non visible linetypes in BaseCamp >> besides 0x17,0x31,0x32 and 0x34? >> >> Greg >> >> On Thu, Feb 25, 2016 at 8:48 AM, Andrzej Popowski >> wrote: >> >>> Hi Greg, >>> >>> there is no consistency in a way Garmin's devices display different >>> objects. Even if you see something in BaseCamp it doesn't mean that this >>> object will be visible on nuvi or outdoor device. >>> >>> There are some informations for meaning of objects (poi, lines, areas), >>> which you can find on some web pages, for example: >>> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types >>> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Polyline_Types >>> http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types >>> >>> As a general rule I suggest to follow description in cGPSmapper manual: >>> http://cgpsmapper.com/manual.htm >>> >>> Usually maps contain a TYP file, which define graphics for objects. This >>> somehow unify map view for different devices. I think TYP allows for >>> viewing some objects, that otherwise would be invisible. >>> >>> -- >>> 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 >> > > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Option "link pois to ways"
So, the number of traffic_signals encountered on one route vs another route isn't even a factor in mkgmp routing? I have been adding traffic_signals to my workload for the past year in hopes it would improve routing accuracy. How then does routing get calculated? On my Garmin there is a choice for "fastest" vs. "shortest" routes. Usually this choice doesn't make much difference in the overall time involved for a traverse along a route and I always assumed it was because here in Thailand so few of our highways have maxspeed tags. How are these two routing choices handled by makgmap? Sorry for the extra questions but I am curious to know these things. Cheers, Dave On Mon, Feb 22, 2016 at 12:23 AM, Jakob Mühldorfer wrote: > Oh, allright. > Maybe if you have time some day, you could look into it again. I think > there are some use cases. > One example where the OSRM traffic light penalty for example seems to have > chosen the clever way around the traffic light: > > https://www.openstreetmap.org/directions?engine=osrm_car&route=51.05581%2C13.72190%3B51.05522%2C13.71881#map=19/51.05541/13.72034 > > Regards > Jakob > > > Am 21.02.2016 um 18:19 schrieb Gerd Petermann: > >> Hi Jakob, >> >> I think this cannot be done with rules, it requires new java code. >> I thought about this a while ago and stoped because I doubted that this >> would improve routing. >> >> Gerd >> >> >> Von: mkgmap-dev-boun...@lists.mkgmap.org.uk < >> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Jakob Mühldorfer < >> m...@jmuehldorfer.de> >> Gesendet: Sonntag, 21. Februar 2016 17:59 >> An: Development list for mkgmap >> Betreff: Re: [mkgmap-dev] Option "link pois to ways" >> >> Hi Gerd, >> >> this would be the best solution I think. >> So far I found a rule that lowers the speed for the complete road with >> the traffic light, do you have one that splits it and adds a lower speed >> only on a part, like you said? >> >> Thanks >> Jakob >> >> Am 21.02.2016 um 17:57 schrieb Gerd Petermann: >> >>> Hi Jakob, >>> >>> the current code ignores nodes with highway=traffic_signals. >>> If I got you right you want to split a road maybe 30 m before the node >>> with >>> highway=traffic_signals and 30 after and set a lower road-speed value >>> for that 60m part? >>> >>> Gerd >>> >>> >>> >>> >>> Von: mkgmap-dev-boun...@lists.mkgmap.org.uk < >>> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Jakob Mühldorfer >>> >>> Gesendet: Sonntag, 21. Februar 2016 17:31 >>> An: Development list for mkgmap >>> Betreff: [mkgmap-dev] Option "link pois to ways" >>> >>> Hi, >>> >>> one more question I was not able to figure out from documentation or >>> source. >>> When the option "link pois to ways" is used, does it automatically >>> process traffic signals in a way that adds a time penalty for routing >>> through them in the map data. >>> >>> Thanks for help on that >>> Jakob >>> ___ >>> 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 >> ___ >> 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 > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Key "motorcar"
Thanks, Gerd. I had missed seeing the "add" in those rules. Now I
understand.
On Sun, Feb 21, 2016 at 5:31 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Dave Swarthout wrote
> > I ask because I am confused by line 29, where it seems my assumption is
> > reversed because the value for motor_vehicle is being transferred to the
> > motorcar tag :
> >
> > Line 29: motor_vehicle=* { add motorcar='${motor_vehicle}'; add
> > goods='${motor_vehicle}'; add hgv='${motor_vehicle}'; add
> > psv='${motor_vehicle}'; add emergency='${motor_vehicle}'; }
> >
> > And also this comment:
> >
> > Line 46: # Therefore we have to choose one vehicle type - and the winner
> > is: motorcar
> >
> > After which access is set for a range of situations all involving the
> term
> > "motorcar"
> >
> > Can someone take a few minutes to explain these rules?
>
> The idea is simple , if motor_vehicle=* is used and motorcar is not
> set,then
> set motorcar=* to the same value. Note that the action is add, not set.
>
> The line 46 is preceeded by this:
> # throughroute cannot be handled differently for different vehicle types
>
> It means that the Garmin format has only one bit that means "allow no
> through route"
> So, if we find motorcar=destination we set the flag.
> If I got that right, the flag is ignored when you select a bicycle as
> vehicle when routing with
> Garmin software, so the solution seems to be ok for me. One who creates a
> map for trucks
> should change this rule.
>
> Gerd
>
>
>
> --
> View this message in context:
> http://gis.19327.n5.nabble.com/Key-motorcar-tp5868207p5868217.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Key "motorcar"
Since this topic has been raised I checked my style files and can find many
uses of the word "motorcar" in various access rules. But that brings up the
question of how the term "motor_vehicle" relates to it.
I had assumed the definition of motor_vehicle would include all powered
vehicles: cars, trucks, hgv, motorcycles, etc.
while motorcar refers to only passenger cars. But that isn't clear in the
"access" style file.
I ask because I am confused by line 29, where it seems my assumption is
reversed because the value for motor_vehicle is being transferred to the
motorcar tag :
Line 29: motor_vehicle=* { add motorcar='${motor_vehicle}'; add
goods='${motor_vehicle}'; add hgv='${motor_vehicle}'; add
psv='${motor_vehicle}'; add emergency='${motor_vehicle}'; }
And also this comment:
Line 46: # Therefore we have to choose one vehicle type - and the winner
is: motorcar
After which access is set for a range of situations all involving the term
"motorcar"
Can someone take a few minutes to explain these rules?
Thanks in advance,
Dave
On Sun, Feb 21, 2016 at 6:52 AM, Jakob Mühldorfer
wrote:
> Found out rules are in place.
> I will examine the case and report back, if it indeed routes over this one
> track with motorcar=no
>
>
> Am 20.02.2016 um 21:45 schrieb Jakob Mühldorfer:
>
>> Hi,
>>
>> question: what is happening with a "motorcar=*" key at the moment?
>> My Garmin wanted to send me over a track with "motorcar=no", is that the
>> Garmin's fault or the mapdata's fault?
>>
>> Thanks
>> Jakob
>> ___
>> 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
>
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Commit: r3668: improce access rules:
Thanks for the clarification. I have already updated my styles. On Fri, Feb 19, 2016 at 7:51 PM, Steve Ratcliffe wrote: > Hi Gerd > > @Steve Maybe you can add such a (generated) link to the svn repo to the >> notification mail ? >> > > That's a good idea, I shall do that. > > ..Steve > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > -- Dave Swarthout Homer, Alaska Chiang Mai, Thailand Travel Blog at http://dswarthout.blogspot.com ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
