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 for max-nodes but after getting that er
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 smaller --max-nodes value for splitter
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 -c DJS.cfg --latin1 --family-id=24566 > --name-tag-list=name,alt_name,loc_na
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 directory for the patched version; > > >- but where? > >
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 that is > > > freshly > > >
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", so ..\typfiles\xexisting.typ is writte
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] 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] 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
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, via email, send a
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 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, n
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 produces an error saying > "SEVERE (Main): name: file name doesn't e
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] 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_area [0x10e12 resolution 19].
>>
>> This wo
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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Dave Swarthout <daveswarth...@gmail.com>
> 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 <st...@parabola.me.uk
> <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 <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
> 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 <cdavi...@orangecorreo.es> 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 <po...@poczta.onet.pl> 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Andrzej Popowski <po...@poczta.onet.pl>
> 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
> Ticker Berkin <rwb-mkg...@jagit.co.uk>
> 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Gerd Petermann <gpetermann_muenc...@hotmail.com>
> > 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag
> > von Andrzej Popowski <po...@poczta.onet.pl>
> > 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von > Gerd Petermann <gpetermann_muenc...@hotmail.com> > 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=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=%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 <ligfiet...@hotmail.com> 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 <st...@parabola.me.uk>
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 (<exp)
> 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 <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von
>> Mike Baggaley <m...@tvage.co.uk>
>> 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 <po...@poczta.onet.pl>
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 <ligfiet...@hotmail.com> 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] Commit r3696: Fix documentation error.
On Mon, Oct 17, 2016 at 4:59 PM, Steve Ratcliffe <st...@parabola.me.uk>
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 <s...@mkgmap.org.uk> 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=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 <po...@poczta.onet.pl>
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 <po...@poczta.onet.pl>
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
the user acknowledges that terms and conditions have been read > > and that the user is bound by these criteria." > > I would suggest talking to the NJDEP and see if you can find a > sympathetic person, and if they would be willing to offer a license > compatible with the Contributor Terms. You can point them at MassGIS, > which has terms that are basically Public Domain with attribution > requested. But their terms are very far away from that, so I don't > expect rapid progress. > > You might look at USGS data, and the National Hydrography Dataset, > which, being a work of the US government, is actually public domain. > > http://nhd.usgs.gov/ > > ___ > 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] 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 <gregcr...@gmail.com> 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] 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 <gregcr...@gmail.com> 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 <po...@poczta.onet.pl> 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 <gregcr...@gmail.com> 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 <ligfiet...@online.nl> 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 <ligfiet...@online.nl> 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 <gregcr...@gmail.com> 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 <daveswarth...@gmail.com> > 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 <gregcr...@gmail.com> 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 <nao...@gmail.com> > wrote: > >> On Sat, Feb 27, 2016 at 5:44 PM, greg crago <gregcr...@gmail.com> 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 <ligfiet...@online.nl> 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 <gregcr...@gmail.com> 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 <po...@poczta.onet.pl> >> 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 <m...@jmuehldorfer.de> 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=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 >>> <m...@jmuehldorfer.de> >>> 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 <m...@jmuehldorfer.de>
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:
When a new version like this one is presented, that is, one that changes "access rules", are there changes in the internal mkgmap code or are these changes one can put into effect by merely adding the new lines to the style rules in file "access" (either by "patching" or manually adding them)?? Thanks Dave On Fri, Feb 19, 2016 at 2:21 PM, svn commit <s...@mkgmap.org.uk> wrote: > > Version mkgmap-r3668 was committed by gerd on Fri, 19 Feb 2016 > > improce access rules: > - treat access=forestry like agricultural (forestry.patch) > - treat access=delivery like destination > ___ > 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] TYPViewer
I had that same issue with Win 8.1 and the latest version of TYPViewer. I went round and round until I decided to cut my losses and use an older version. I'm using 4.5.24 successfully but YMMV with Win 10. Sorry, but I cannot recall from where I downloaded it. It's only 3 MB so if you wish I can put it in my Dropbox and you can get it from there. Let me know On Sun, Feb 7, 2016 at 11:48 AM, Mark Bradley <ethnicfoodisgr...@gmail.com> wrote: > I decided to download TYPViewer. Following the link in the wiki took me > to sites.google.com/site/sherco40/. This page states the latest version > is 4.5 20. Yet in a blog on a separate website the writers were referring > to newer versions, such as 4.5.35. I cannot find any site that offers > anything newer than 4.5.20. Is the Google site the correct site for the > latest version? > > > > When I try to run the program, I get this error message: > > > > Error 50003 (Unexpected error) in procedure Main of Module Demarrage, at > line: 340 > > > > I’m running Windows 10. Is TYPViewer incompatible? I would appreciate > input from anyone who has successfully used the program. > > > > Mark Bradley > > > > > > > > ___ > 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 v1] improve highway rules
Gerd,
I have no complaints. I am using my own style files I so ask where is the
best place to insert these new rules? I assume they should be placed in my
lines file ahead of the general highway processing rules. Does that make
sense?
Thanks
Dave
<https://www.avast.com/lp-safe-emailing?utm_medium=email_source=link_campaign=sig-email_content=webmail>
This
email has been sent from a virus-free computer protected by Avast.
www.avast.com
<https://www.avast.com/lp-safe-emailing?utm_medium=email_source=link_campaign=sig-email_content=webmail>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
On Sat, Dec 12, 2015 at 2:52 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:
> Hi all,
>
>
> I think the following lines shoud be added to the lines rules to make sure
> that
>
> these ways are not used for routing. For many of them I've tried to
> convince
>
> the mappers to find better tags, but without success so far.
>
> Some are part of proposals.
>
>
> # Remove highway tag from ways which are not suitable for routing
> highway=traffic_signals | highway=junction | highway=island |
> highway=centre_line | highway=traffic_island {delete highway}
> highway=piste | highway=ski {delete highway}
> highway=no | highway=none {delete highway}
>
>
> If I hear no complains I'll commit this patch on Monday.
>
>
> 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] default style: highway=path means unpaved?
Here in Thailand there is an understanding that an unclassified way is more
important than a residential way but less important than a tertiary
highway. See
http://wiki.openstreetmap.org/wiki/WikiProject_Thailand#Highway_classification
for more information. Most but not all unclassified ways are paved in
Thailand.
I never understood the reasoning behind this but the practice is in wide
use and mappers here generally abide by it. I think it might have come
about because mappers were looking for a way to classify roads that are
important connectors but were not strictly residential and that have no
official designation like a route number.
On Tue, Sep 8, 2015 at 4:13 PM, Felix Hartmann <extremecar...@gmail.com>
wrote:
> For Unclassified - yes I agree. It should be rather unpaved. However for
> at least highway=cycleway and highway=unclassified (very rare anyhow) - I
> think a country based list wouldn't be too bad. If you know that 99% of
> such ways in your country are paved - shout out Otherweise IMHO both
> should be assumed unpaved.
> Unclassified I would guess paved by default for Central/Western/ European
> countries? But unpaved for Northern (but not Denmark), Eastern European
> countries - and the rest of the world? Certainly unpaved for most of Asia
> and Africa...
>
> On 8 September 2015 at 10:46, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Felix,
>>
>> okay, got the point, but why do we assume that a highway=unclassified is
>> paved
>> when no other tag gives information?
>> Might be a good assumption in Germany or Austria, but probably not in
>> other areas.
>>
>> Gerd
>>
>>
>>
>> --
>> Date: Tue, 8 Sep 2015 10:32:14 +0200
>> From: extremecar...@gmail.com
>> To: mkgmap-dev@lists.mkgmap.org.uk
>> Subject: Re: [mkgmap-dev] default style: highway=path means unpaved?
>>
>>
>> Well that was introduced because it is unknown. If you have a map and
>> want to avoid unpaved ways - and select that - then there really should be
>> no unpaved ways. If we don't set unpaved here - the avoidance will not be
>> strict enough anymore...
>> highway=path & bicycle=designated could well be a tracktype=grade2 and
>> sometimes even grade3 or worse... And in cases of a mtb route - clearly
>> something completely unrideable for a normal cyclist...
>>
>> On 8 September 2015 at 10:19, Gerd Petermann <
>> gpetermann_muenc...@hotmail.com> wrote:
>>
>> Hi all,
>>
>> I just noted that the default style sets the mkgmap:unpaved
>> flag for many cycleways, e.g.
>> http://www.openstreetmap.org/way/276070019
>>
>> I see intensive discussions about wrong use of
>> highway=path and/or wrong interpretation of that tag.
>>
>> The rule in lines is
>> (highway=bridleway | highway=path | highway=track | highway=unsurfaced)
>> & surface!=* & tracktype!=* & smoothness!=* & sac_scale!=*
>> { add mkgmap:unpaved=1 }
>>
>> My understanding is that highway=track is likely to be unpaved, but
>> highway=path doesn't suggest that, esp. not in combination with
>> bicycle=designated.
>>
>> Does anybody have a better solution?
>>
>> Gerd
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>> Floragasse 9/11
>> 1040 Wien
>> Austria - Österreich
>>
>> ___ 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
>>
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
> Floragasse 9/11
> 1040 Wien
> Austria - Österreich
>
> ___
> 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] Exclude POIs from index
Yes, I already knew that, but thanks. I thought there might be a way to be more restrictive but I now think it's just that the All POIs search is just what it says it is: it displays *ALL* POIs. It's doing exactly what I told it to do. I sometimes use that option when I'm on a trip somewhere and looking for a POI and don't know which category to pick at the top level search. Having a list of nearby POIs often helps but one has to scroll through a lot of extra stuff to find anything useful. That's what I was trying to avoid and that's why I asked the question. I'm resolved now. Thanks to all. On Tue, Aug 25, 2015 at 4:28 PM, Andrzej Popowski po...@poczta.onet.pl wrote: Hi Dave, when you search for all POIs, then GPS look for all POI that are near your current position. It doesn't use index for that kind of search, so you can't exclude POIs selectively. You would have to remove them form map. You can try to search for a category of POIs or search by name to get only a selection of POIs. -- 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] Exclude POIs from index
When I search for All POIs on my Garmin Montana I get many useless unnamed POIs, even power poles, barriers, houses, etc. Is there some way to tell mkgmap to exclude such POIs from its search results? -- 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: r3608: change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not
0x2b03 is not listed in POI search on modern devices I don't understand that statement. Are you saying that type 0x2b03 cannot be displayed on modern devices? If it's not listed in POI search, how is that determined? On Fri, Jun 5, 2015 at 9:38 AM, svn commit s...@mkgmap.org.uk wrote: Version mkgmap-r3608 was committed by gerd on Fri, 05 Jun 2015 change type 0x2b03 to 0x2b05 for camping, 0x2b03 is not listed in POI search on modern devices ___ 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] Named bridges not displaying
Thanks for the clarifications.
I do want to see the bridge names, so apparently the label:1 option is the
correct one.
Believe me, I really appreciate the work that has been done, and continues
o get done, on mkgmap. Understanding the Garmin format without being an
insider or having some sort of a functional spec must be extremely
difficult. Kudos to you and all the other folks who support and enhance
mkgmap.
If I ever get familiar enough with the program to be of help in clarifying
the documentation, I will volunteer my time to do that. But at my present
level of understanding, I'm afraid I wouldn't be of much help.
Dave
On Wed, May 20, 2015 at 10:42 PM, Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Hi Dave,
I agree that the rules to set a name are very confusing, esp. when it
comes to roads. I guess one reason is that it took a while to discover
that a map object can have 4 labels,
another point is that we don't try to explain the Garmin format in this
manual, instead we presume that the reader knows the details of the
Garmin format quite well.
Maybe it would help to add a chapter with links to
the corresponding manuals and wiki pages.
If you have the time, please propose improvements, the sources are
almost normal text files.
Reg. your questions:
Why not addabel ?
I thought you want to see the bridge name in the map. If that is the case,
you have
to set mkgmap:label:1 . If you want to be able to find the bridge in
address search,
you can use addlabel without problems.
Why doesn't set name='${bridge:name}' work?
Because it sets the tag name to a new /different value. If it is not
followed
by a rule that uses this value to set mkgmap:label:* you will not see a
change.
Gerd
--
From: daveswarth...@gmail.com
Date: Wed, 20 May 2015 12:09:55 -0700
Subject: Re: [mkgmap-dev] Named bridges not displaying
To: gpetermann_muenc...@hotmail.com
Thank you very much. That worked like a charm.
As for the style manual,
4.3.6. name
This sets the first label of the element but only if it is not already
set. This is a helper action. The same
effect can be produced with different notations as it is shown in the
following example where all three
lines have the same effect.
{name '${name} (${ref})' | '${ref}' | '${name}'}
{add mkgmap:label:1='${name} (${ref})' | '${ref}' | '${name}'}
mkgmap:label:1!=* {set mkgmap:label:1='${name} (${ref})' | '${ref}' |
'${name}'}
How one would determine that this is a situation when one must assign a
mkgmap label is beyond me. I could have read that description a thousand
times and not figured out what to do. What's missing is WHY one would use
the name directive in this way. And then, some information about the use of
mkgmap:label:1 in these circumstances would be helpful too.
In scanning the manual I noticed another directive, addlabel which would
assign the next available label level. Why didn't you use that? I'm
thinking it's because you already knew the tags for these two bridges so
you knew mkgmap:label:1 was not being used. But wouldn't addlabel be a
safer way to go about this in the general case?
One last question: During my struggles I tried using the set command, {set
name='${bridge:name}' }, to replace the name of the section of highway that
crosses the bridge with the bridge name but it didn't work. Could you
venture a reason for that?
On Wed, May 20, 2015 at 10:02 AM, Gerd Petermann
gpetermann_muenc...@hotmail.com wrote:
Hi Dave,
the name action has no effect when mkgmap:label:1 is already
set. You may move your rule before those
that use the highway name, or you can use
bridge=* bridge:name=* {set mkgmap:label:1= '${bridge:name}'; echotags
}
See style manual section 4.3.6
Gerd
--
From: daveswarth...@gmail.com
Date: Wed, 20 May 2015 09:49:43 -0700
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Named bridges not displaying
Thanks for all the good effort on the exit_to and destination issues.
Everything is working well for me now.
I discovered another problem that might be simple to fix, or maybe there's
something that I'm doing wrong. There are two named bridges in my current
area but the names do not display on my maps.
I placed this rule in my lines style file:
bridge=* bridge:name=* {name '${bridge:name}'; echotags }
here is the stderr output
221689337 - [highway=tertiary,ref=CR 48,mkgmap:label:2=Lower Smith River
Road (CR 48),bridge=yes,name=Lower Smith River Road,bridge:name=Jack Franz
Bridge,surface=asphalt,mkgmap:street=Lower Smith River Road,mkgmap:label:1=
CR48 Lower Smith River Road,ele=1]
336150197 - [highway=residential,mkgmap:street=Goodpasture
Road,mkgmap:label:1=Goodpasture
Road,covered=yes,bridge=yes,bridge:name=Goodpasture Bridge,name=Goodpasture
Road]
The bridge name does not appear on the compiled maps.
Any ideas or suggestions?
Dave
--
Dave Swarthout
[mkgmap-dev] Named bridges not displaying
Thanks for all the good effort on the exit_to and destination issues.
Everything is working well for me now.
I discovered another problem that might be simple to fix, or maybe there's
something that I'm doing wrong. There are two named bridges in my current
area but the names do not display on my maps.
I placed this rule in my lines style file:
bridge=* bridge:name=* {name '${bridge:name}'; echotags }
here is the stderr output
221689337 - [highway=tertiary,ref=CR 48,mkgmap:label:2=Lower Smith River
Road (CR 48),bridge=yes,name=Lower Smith River Road,bridge:name=Jack Franz
Bridge,surface=asphalt,mkgmap:street=Lower Smith River Road,mkgmap:label:1=
CR48 Lower Smith River Road,ele=1]
336150197 - [highway=residential,mkgmap:street=Goodpasture
Road,mkgmap:label:1=Goodpasture
Road,covered=yes,bridge=yes,bridge:name=Goodpasture Bridge,name=Goodpasture
Road]
The bridge name does not appear on the compiled maps.
Any ideas or suggestions?
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] [Patch v1] improve handling of exits
When you say you didn't change the echotags code, did you rewrite the style
rule? If you did that I'm embarrassed to admit I am unable to see the
difference.
AFAIK I'm using the exact same style file for both runs, but the run with
the older executables produced no output. I replaced that jar file with the
new one (modified r3598) and all of a sudden output from echotags appeared.
Anyway, it's all good.
On Tue, May 19, 2015 at 11:03 AM, GerdP gpetermann_muenc...@hotmail.com
wrote:
Hi Dave,
I am not sure if you understand that echotags always worked.
The problem is/was that the rule was not executed because
the expression evaluated to false.
In other words, I did not change the echotags code,
I changed the code so that it is more likely that the
term mkgmap:exit_hint=true mkgmap:dest_hint=true
evaluates to true.
Gerd
Dave Swarthout wrote
On Mon, May 18, 2015 at 7:51 AM, Gerd Petermann
gpetermann_muenchen@
wrote:
@Dave: Please note the changes in the default style.
It would be great if you could test this patch and maybe suggest
a better description of the two options.
Sorry for the delay in responding. The modified r3598 produced output
from
the echotags function. I did not see anything regarding the exit_to tags
but my test destination tag was processed and this output went to stderr:
4611686018427392234 (168231839) -
[highway=motorway_link,destination=Beltline Road
East,mkgmap:exit_hint=true,mkgmap:dest_hint=true,bicycle=yes,mkgmap:way-has-pois=true,mkgmap:exit_hint_ref=195A,mkgmap:label:1=Dest:
Beltline Road East,oneway=yes] before
4611686018427392234 (168231839) -
[highway=motorway_link,destination=Beltline Road
East,mkgmap:exit_hint=true,mkgmap:dest_hint=true,bicycle=yes,mkgmap:way-has-pois=true,mkgmap:exit_hint_ref=195A,mkgmap:label:1=Dest:
Beltline Road East,oneway=yes] after
*(highway=motorway_link | highway=trunk_link) mkgmap:exit_hint=true *
*mkgmap:dest_hint=true*
* { echotags before;*
*name '${destination:ref|subst: =} ${destination|subst:;= |subst:/= }'
|*
* '${ref|subst: =} ${destination|subst:;= |subst:/= }' |*
* '${destination|subst:;= |subst:/= }' |*
* 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |*
* 'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |*
* 'Exit ${mkgmap:exit_hint_exit_to}' |*
* 'Exit ${mkgmap:exit_hint_name}' |*
* 'Exit ${mkgmap:exit_hint_ref}' ;*
*echotags after*
* }*
This is my rule for debugging the destination tag and it appears before
the
rule above:
*destination=* (highway=motorway_link | highway=trunk_link) {name
'Dest:
${destination}' }*
My exit_to rule is for points is here:
*exit_to=* {name 'Exit ${ref} ${exit_to}' | '${exit_to}' } [0x12615
resolution 24]*
This produces the desired output on my maps but doesn't show up in stderr
because I haven't yet put echotags into my points style file.
Thanks for the good work
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
View this message in context:
http://gis.19327.n5.nabble.com/Patch-v1-improve-handling-of-exits-tp5845035p5845192.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] Routing parameters
Yes, as you can see above, I understand the intent of those two options.
But if someone could further explain what's happening in the rule, I would
be most appreciative.
I'm guessing the first part assigns a name or ref if one appears in the
tagging but understanding the logic of the series of subst filters
following that is, for a newbie, quite challenging.
On Fri, May 15, 2015 at 12:17 PM, GerdP gpetermann_muenc...@hotmail.com
wrote:
Hi Dave,
please check the documentation for --process-destination and
--process-exits:
http://www.mkgmap.org.uk/doc/options
If I got this right, these option mark exits so that Garmin knows where
they are where they lead.
Gerd
Dave Swarthout wrote
I am curious to know how mkgmap handles the display of and text to speech
aspects of motorway junctions. It's hard to test for this without
actually
creating a route and then driving it to see and hear what the Garmin is
doing with the data or to discover where it gets the information from.
I'm assuming that whatever one puts in the exit_to=* tag gets displayed
and
spoken by the Garmin assistant. Does mkgmap ever use the destination=*
tag, and if so under what circumstances?
I found this rule in the lines style sheet, but I do not understand it
well
enough to help me answer my question
(highway=motorway_link | highway=trunk_link) mkgmap:exit_hint=true
mkgmap:dest_hint=true
{ name '${destination:ref|subst: =} ${destination|subst:;= |subst:/=
}' |
'${ref|subst: =} ${destination|subst:;= |subst:/= }' |
'${destination|subst:;= |subst:/= }' |
'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |
highway=road
'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |
'Exit ${mkgmap:exit_hint_exit_to}' |
'Exit ${mkgmap:exit_hint_name}' |
'Exit ${mkgmap:exit_hint_ref}'
}
As always, thanks in advance to any help you can provide.
Dave
--
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@.org
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
--
View this message in context:
http://gis.19327.n5.nabble.com/Routing-parameters-tp5844762p5844766.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
[mkgmap-dev] Routing parameters
I am curious to know how mkgmap handles the display of and text to speech
aspects of motorway junctions. It's hard to test for this without actually
creating a route and then driving it to see and hear what the Garmin is
doing with the data or to discover where it gets the information from.
I'm assuming that whatever one puts in the exit_to=* tag gets displayed and
spoken by the Garmin assistant. Does mkgmap ever use the destination=*
tag, and if so under what circumstances?
I found this rule in the lines style sheet, but I do not understand it well
enough to help me answer my question
(highway=motorway_link | highway=trunk_link) mkgmap:exit_hint=true
mkgmap:dest_hint=true
{ name '${destination:ref|subst: =} ${destination|subst:;= |subst:/=
}' |
'${ref|subst: =} ${destination|subst:;= |subst:/= }' |
'${destination|subst:;= |subst:/= }' |
'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_name}' |
highway=road
'Exit ${mkgmap:exit_hint_ref} ${mkgmap:exit_hint_exit_to}' |
'Exit ${mkgmap:exit_hint_exit_to}' |
'Exit ${mkgmap:exit_hint_name}' |
'Exit ${mkgmap:exit_hint_ref}'
}
As always, thanks in advance to any help you can provide.
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] Testing for a literal question mark
How would I write a regex style rule that fires when it encounters a question mark in a name? There is a group of local mappers that have used an invented name of Ban ? for towns they do not know the name of. I want to set the name to something more meaningful but I can't seem to discover a way to escape the ? without crashing mkgmap. -- 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] Testing for a literal question mark
That did the trick. Here's my simplified version:
(place=village | place=hamlet) name~'.*[?].*' {delete name}
I'm pretty sure I tried putting the question mark inside brackets but it
didn't work. Maybe the enclosing quotes make a difference? At any rate,
it's working now.
Thank you and best regards,
Dave
On Thu, Mar 19, 2015 at 4:16 AM, Walter Schlögl
walter.schloegl-re...@aon.at wrote:
I am checking, if names only include ? and delete it with this rule
name~'^(?=\s*\?)[?\s]+$'{ delete name }
Maybe it’s helpfull even if you are looking for a different solution.
Walter
*From:* Mike Baggaley m...@tvage.co.uk
*Sent:* Wednesday, March 18, 2015 4:53 PM
*To:* daveswarth...@gmail.com ; 'Development list for mkgmap'
mkgmap-dev@lists.mkgmap.org.uk
*Subject:* Re: [mkgmap-dev] Testing for a literal question mark
Hi Dave, I have a rule based on the following that includes a test for a
question mark, and it seems to work fine:
alt_name~'.*[!$%\^*_+=\[\]{}:;@~#,?/|\\].*' {echotags Road with
invalid character in alt_name; delete alt_name}
So I expect you should be able to put ~’.*[?].*’ as the test if the
question mark is not accepted outside the square brackets.
Regards,
Mike
*From:* Dave Swarthout [mailto:daveswarth...@gmail.com]
*Sent:* 18 March 2015 14:28
*To:* Development list for mkgmap
*Subject:* [mkgmap-dev] Testing for a literal question mark
How would I write a regex style rule that fires when it encounters a
question mark in a name?
There is a group of local mappers that have used an invented name of Ban
? for towns they do not know the name of. I want to set the name to
something more meaningful but I can't seem to discover a way to escape the
? without crashing mkgmap.
--
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 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] roadspeed in default style
I can answer this one: Are streets with 25 mph like streets with 30 kmh, pure residential without drive through traffic, or like normal streets with drive through traffic, but limits because of schools? Normal residential streets in the United States are generally posted 25 or 30 mph but school zones are 15 mph. And in my experience, the school zone limits are usually well enforced. On Mon, Mar 16, 2015 at 12:32 AM, GerdP gpetermann_muenc...@hotmail.com wrote: Hi Bernd, Bernd Weigelt wrote Where are you? Your system time looks strange ;-) I am at home (Germany), but I use the GIS interface to write this. Guess that's the reason. Gerd -- View this message in context: http://gis.19327.n5.nabble.com/roadspeed-in-default-style-tp5836280p5837284.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] Making site relations visible
Yes, ideally I'd like to show the contents of the name tag (for example, name=Nice Apartments), in the center of the space occupied by the three (or more) objects that make up the site. Is this possible? On Mon, Feb 23, 2015 at 6:08 PM, GerdP gpetermann_muenc...@hotmail.com wrote: Hi Dave, the relations file allows to add tags from the relations to the members. I guess you want to do something else, maybe calculate a polygon that encloses all members ? Gerd Dave Swarthout wrote Can someone give me information about rendering relations. I have tagged some relations of type=site but they don't show up in my maps. One such site is a named group of three apartment buildings. The relation itself has a name tag and each building is merely tagged as building=yes. I've had trouble with relations before and although they are the correct way to tag certain groups of objects the fact that they seem not to render properly exasperates me. Unfortunately, the relations style file that I am using deals only with routes. This is not really a development question but you're the experts. If you think this question should be asked elsewhere, please make a suggestion. Cheers, Dave ___ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/Making-site-relations-visible-tp5834634p5834638.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
[mkgmap-dev] Making site relations visible
Can someone give me information about rendering relations. I have tagged some relations of type=site but they don't show up in my maps. One such site is a named group of three apartment buildings. The relation itself has a name tag and each building is merely tagged as building=yes. I've had trouble with relations before and although they are the correct way to tag certain groups of objects the fact that they seem not to render properly exasperates me. Unfortunately, the relations style file that I am using deals only with routes. This is not really a development question but you're the experts. If you think this question should be asked elsewhere, please make a suggestion. Cheers, Dave ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Re: [mkgmap-dev] Oneway
No, everything is working as it should. I merely wanted to better understand how decisions are made about displaying the arrows in the correct direction. It is not obvious from reading TYP files or style directives how this is done. So if I reword my question again, let's say you have a dual carriageway. Both lanes have the same oneway=yes tag and both use the same TYP code. Yet one lane displays the arrows pointing left to right, while the other lane has them pointing right to left. Either the Garmin unit or mkgmap has to decide how to draw those arrows. From what you are saying, I'm assuming it's the direction the way was drawn that determines the directionality of those arrows. And furthermore, it is the Garmin software (and Basecamp) that actually makes the decision based on information in the IMG file. Is that correct? Thanks for taking the time to answer On Sun, Feb 22, 2015 at 6:48 PM, Andrzej Popowski po...@poczta.onet.pl wrote: Hi Dave, Garmin format as used in img allows only for equivalent of oneway=1. Mkgmap have to reverse line direction in case of oneway=-1. So you need only one pattern in TYP file, with arrows pointing form left to right. Actually it means arrows pointing from start of a line towards its end. I'm trying to guess what is your real question. Do you get arrows pointing in wrong direction? -- 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
Many thanks. Dave On Sun, Feb 22, 2015 at 8:47 PM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Dave, yes, I think you got it. One special case: mkgmap reverses the order of the points for a routable way with oneway=-1 tag . Gerd -- From: daveswarth...@gmail.com Date: Sun, 22 Feb 2015 20:19:46 +0700 To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] Oneway No, everything is working as it should. I merely wanted to better understand how decisions are made about displaying the arrows in the correct direction. It is not obvious from reading TYP files or style directives how this is done. So if I reword my question again, let's say you have a dual carriageway. Both lanes have the same oneway=yes tag and both use the same TYP code. Yet one lane displays the arrows pointing left to right, while the other lane has them pointing right to left. Either the Garmin unit or mkgmap has to decide how to draw those arrows. From what you are saying, I'm assuming it's the direction the way was drawn that determines the directionality of those arrows. And furthermore, it is the Garmin software (and Basecamp) that actually makes the decision based on information in the IMG file. Is that correct? Thanks for taking the time to answer On Sun, Feb 22, 2015 at 6:48 PM, Andrzej Popowski po...@poczta.onet.pl wrote: Hi Dave, Garmin format as used in img allows only for equivalent of oneway=1. Mkgmap have to reverse line direction in case of oneway=-1. So you need only one pattern in TYP file, with arrows pointing form left to right. Actually it means arrows pointing from start of a line towards its end. I'm trying to guess what is your real question. Do you get arrows pointing in wrong direction? -- 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 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
I'm wondering if someone could explain to me how oneway arrows are applied to ways. My oneways display as they should on my Garmin GPS and in Basecamp but from reading the style file for lines I can't understand how mkgmap determines the direction of the oneway. Here are two lines from my lines style file: # 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] My TYP file shows the 0X1 type as arrows pointing left to right while, as expected, the 0x10001 line has arrows pointing the other way. But how then does mkgmap cause arrows to display pointing right to left in cases where oneway !=-1, which is the vast majority of cases? 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] FW: Lines distorted
I'm still reading this thread but haven't tried the new mkgmap.jar yet. I was hoping for a way to smooth polygons and Gerd's reply to Enrico indicates that the patch and new binary only help smoothing lines, so I stopped paying attention. But I'm interested in learning more about mkgmap and the map making process in general. I saw another post a while back where Gerd says something along the lines of people still don't know how to use a patch. The documentation for mkgmap itself is pretty thin. There's the style manual, and the little blurb about TYP files but nothing to tie it all together. And I've not found anything about how to use mkgmap other then the options text file. The explanatory statements in there are helpful but leave a lot unsaid. A careful reading of the Optimization Options, for example, left me with more questions than answers. You are the developers of the program, so many of these things must seem glaringly obvious. But they are not. How is one supposed to know how to utilize a patch? Is there a users manual somewhere? Thanks, Dave On Sat, Jan 31, 2015 at 4:41 PM, Gerd Petermann gpetermann_muenc...@hotmail.com wrote: Hi Enrico, I fear I can't change mkgmap to fix this problem. The problem is more or less bad luck. In some cases, you have placed the points of the ways more or less exactly between the points of the Garmin grid, others are very near to the grid points. If I got it right, we can only produce a straight line in the garmin format when we allow to move certain points by more than 2 metres, and in that case the WrongAngleFixer will prefer the correct position to the bad angle. I''ve attached the grid as a gpx file, if you load that into JOSM you probably see what I mean. If you prefer nicer rendering on the Garmin map you may move some points closer to the grid to solve the problem. Gerd Date: Fri, 30 Jan 2015 09:40:37 -0700 From: e.rossin...@alice.it To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] FW: Lines distorted yes you'are right, I'm interested to straight out the line Via Ronchi Di San Francesco Di Paola. would be great if you'll find something to do this. THANKS. --enrico -- View this message in context: http://gis.19327.n5.nabble.com/Distorted-lines-tp5831842p5831971.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 ___ 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] Lines distorted
I want to continue Enrico's questioning a bit. I have a similar issue with the way polygons display on my Garmin device. What appears as a smooth curve on the OSM slippy map are very blocky on the device. I have played with the reduce-point-density=4 and reduce-point-density-polygon=8 parameters in an attempt to smooth those curves but they seem to have no effect. I can live with the distortion but I wonder, what do these two parameters actually control? Cheers, Dave On Fri, Jan 30, 2015 at 12:22 AM, Andrzej Popowski po...@poczta.onet.pl wrote: Hi Enrico, Garmin maps have limited resolution, about 2.4m. One can't draw precisely a line, which length is near to this resolution. You can try to assign the same Garmin object type to all these segments, then probably mkgmap will be able to merge them and smooth. -- 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] echo improvements for elements with fake ids
@Mike - Wonderful idea. I'm a complete newbie here but have been using mkgmap for a while now with good results. I was just asking about the echotags feature on the OSM Garmin list, and more specifically what the long number was that precedes the message. Now I read that it will be made to do some useful work for OSMers. How long before this patch makes it into the released application do you think? Cheers, Dave On Mon, Jan 19, 2015 at 6:55 PM, Mike Baggaley m...@tvage.co.uk wrote: The attached patch improves the echo and echotags messages by including the id of the original element when a fake id is generated by mkgmap, thus enabling you to find it in OSM. Please try, and commit if you are happy with the change. Regards, Mike ___ 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
