Re: [mkgmap-dev] Compile error

2022-05-02 Thread Dave Swarthout
I just saw your other email that the next release of mkgmap includes
Carlos's patch. I've downloaded it.

Thanks again to everyone on this list.

Dave

On Mon, May 2, 2022 at 10:43 PM Dave Swarthout  wrote:
>
> OMG!
>
> I copied parts of my batch file for Thailand maps to make this batch
> file when I came back to the U.S. but forgot to use the splitter
> output file as inputs. I never noticed my omission. It works fine now:
>
> java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566
> --name-tag-list=name,alt_name,loc_name,int_name --description="Eugene"
> splitter\*.o5m "C:\Users\Alask\Dropbox
> (Personal)\Mapping\24983djs.TYP"
>
> Sorry for wasting your time. I must say, however, that the error
> message I got didn't help diagnose or solve that problem. Maybe that
> could be looked at and improved.
>
> Thanks, Gerd.
>
> On Mon, May 2, 2022 at 10:22 PM  wrote:
> >
> > Hi Dave,
> >
> > I just double checked what you wrote before and it seems you feed mkgmap 
> > with
> > the large file C:\Users\alask\Downloads\Maps\Eugene.osm ?
> > You also posted a log that shows that you use splitter with the same file.
> > So, change your mkgmap command to actually use the output from splitter and 
> > your
> > problem shoud be solved. There is probably no need to use the small 
> > --max-nodes value.
> >
> > Gerd
> >
> >
> > 
> > Von: Dave Swarthout 
> > Gesendet: Montag, 2. Mai 2022 23:13
> > An: Gerd Petermann
> > Cc: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Compile error
> >
> > I don't create an overview map. No tiles show up with zero size nor
> > are any of the 56 tiles larger than about 159,000 nodes. Carlos has
> > offered a patch to indicate the problem tile but I'm on a Windows 10
> > system and am not willing to set up a Linux environment just to patch
> > my mkgmap program.
> >
> > Is there a debugging tool or method that you can suggest?
> >
> >
> > On Mon, May 2, 2022 at 11:10 AM Gerd Petermann
> >  wrote:
> > >
> > > Hi Dave,
> > >
> > > I would expect a tile with 0 bytes. Maybe you get this message for the 
> > > overview map?
> > >
> > > Gerd
> > >
> > > 
> > > Von: Dave Swarthout 
> > > Gesendet: Montag, 2. Mai 2022 20:02
> > > An: Gerd Petermann
> > > Cc: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Compile error
> > >
> > > Thanks, Gerd,
> > >
> > > I get the same error when using the default syle. In DJS.cfg, I placed 
> > > this line:
> > > style-file=C:\Users\Alask\Documents\mkgmap\examples\styles\default. That 
> > > is correct usage, right?
> > >
> > > Another list member told me to look for the offending tile in order to 
> > > manually split it, however, all the tiles look alike to me in terms of 
> > > size. How would I tell which tile is the "bad one" that's causing this 
> > > RGN error?
> > >
> > > You mentioned adjusting some mkgmap parameters that would reduce the size 
> > > and/or complexity of the map I'm trying to create. The descriptive text 
> > > in the Options file for directives about processing lines and polygons 
> > > doesn't make clear how to reduce the amount of information they handle— 
> > > can you offer any suggestions?
> > >
> > > Thanks,
> > >
> > > Dave
> > >
> > >
> > >
> > > On Mon, May 2, 2022 at 9:23 AM Gerd Petermann 
> > > mailto:gpetermann_muenc...@hotmail.com>> 
> > > wrote:
> > > Hi Dave,
> > >
> > > the max-nodes value is already very small, so maybe something in mkgmap 
> > > goes very wrong.
> > > We probably need the input file (*.o5m) for the tile that fails and the 
> > > style unless you can reproduce the
> > > problem also with the default style.
> > >
> > > Gerd
> > >
> > > 
> > > Von: Dave Swarthout 
> > > mailto:daveswarth...@gmail.com>>
> > > Gesendet: Montag, 2. Mai 2022 18:08
> > > An: Gerd Petermann
> > > Cc: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Compile error
> > >
> > > Reducing the node count means I was adjusting the max-nodes value; I had 
> > > been using a value of 160,000

Re: [mkgmap-dev] Compile error

2022-05-02 Thread Dave Swarthout
OMG!

I copied parts of my batch file for Thailand maps to make this batch
file when I came back to the U.S. but forgot to use the splitter
output file as inputs. I never noticed my omission. It works fine now:

java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566
--name-tag-list=name,alt_name,loc_name,int_name --description="Eugene"
splitter\*.o5m "C:\Users\Alask\Dropbox
(Personal)\Mapping\24983djs.TYP"

Sorry for wasting your time. I must say, however, that the error
message I got didn't help diagnose or solve that problem. Maybe that
could be looked at and improved.

Thanks, Gerd.

On Mon, May 2, 2022 at 10:22 PM  wrote:
>
> Hi Dave,
>
> I just double checked what you wrote before and it seems you feed mkgmap with
> the large file C:\Users\alask\Downloads\Maps\Eugene.osm ?
> You also posted a log that shows that you use splitter with the same file.
> So, change your mkgmap command to actually use the output from splitter and 
> your
> problem shoud be solved. There is probably no need to use the small 
> --max-nodes value.
>
> Gerd
>
>
> 
> Von: Dave Swarthout 
> Gesendet: Montag, 2. Mai 2022 23:13
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Compile error
>
> I don't create an overview map. No tiles show up with zero size nor
> are any of the 56 tiles larger than about 159,000 nodes. Carlos has
> offered a patch to indicate the problem tile but I'm on a Windows 10
> system and am not willing to set up a Linux environment just to patch
> my mkgmap program.
>
> Is there a debugging tool or method that you can suggest?
>
>
> On Mon, May 2, 2022 at 11:10 AM Gerd Petermann
>  wrote:
> >
> > Hi Dave,
> >
> > I would expect a tile with 0 bytes. Maybe you get this message for the 
> > overview map?
> >
> > Gerd
> >
> > 
> > Von: Dave Swarthout 
> > Gesendet: Montag, 2. Mai 2022 20:02
> > An: Gerd Petermann
> > Cc: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Compile error
> >
> > Thanks, Gerd,
> >
> > I get the same error when using the default syle. In DJS.cfg, I placed this 
> > line:
> > style-file=C:\Users\Alask\Documents\mkgmap\examples\styles\default. That is 
> > correct usage, right?
> >
> > Another list member told me to look for the offending tile in order to 
> > manually split it, however, all the tiles look alike to me in terms of 
> > size. How would I tell which tile is the "bad one" that's causing this RGN 
> > error?
> >
> > You mentioned adjusting some mkgmap parameters that would reduce the size 
> > and/or complexity of the map I'm trying to create. The descriptive text in 
> > the Options file for directives about processing lines and polygons doesn't 
> > make clear how to reduce the amount of information they handle— can you 
> > offer any suggestions?
> >
> > Thanks,
> >
> > Dave
> >
> >
> >
> > On Mon, May 2, 2022 at 9:23 AM Gerd Petermann 
> > mailto:gpetermann_muenc...@hotmail.com>> 
> > wrote:
> > Hi Dave,
> >
> > the max-nodes value is already very small, so maybe something in mkgmap 
> > goes very wrong.
> > We probably need the input file (*.o5m) for the tile that fails and the 
> > style unless you can reproduce the
> > problem also with the default style.
> >
> > Gerd
> >
> > 
> > Von: Dave Swarthout 
> > mailto:daveswarth...@gmail.com>>
> > Gesendet: Montag, 2. Mai 2022 18:08
> > An: Gerd Petermann
> > Cc: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Compile error
> >
> > Reducing the node count means I was adjusting the max-nodes value; I had 
> > been using a value of 160,000 for max-nodes but after getting that error 
> > message, I tried running splitter with max-nodes=120,000 and 100,000 nodes 
> > but that had zero effect on the error message. There were more tiles 
> > generated by splitter but the same error resulted.
> >
> > I've attached my splitter logs and the DJS.CFG file
> >
> > Thanks for the help
> >
> > On Mon, May 2, 2022 at 1:42 AM Gerd Petermann 
> > mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
> >  wrote:
> > Hi Dave,
> >
> > what do you mean with "I've tried reducing the size of the node count but 
> > that had no effect"? A

Re: [mkgmap-dev] Compile error

2022-05-02 Thread Dave Swarthout
I don't create an overview map. No tiles show up with zero size nor
are any of the 56 tiles larger than about 159,000 nodes. Carlos has
offered a patch to indicate the problem tile but I'm on a Windows 10
system and am not willing to set up a Linux environment just to patch
my mkgmap program.

Is there a debugging tool or method that you can suggest?


On Mon, May 2, 2022 at 11:10 AM Gerd Petermann
 wrote:
>
> Hi Dave,
>
> I would expect a tile with 0 bytes. Maybe you get this message for the 
> overview map?
>
> Gerd
>
> ________
> Von: Dave Swarthout 
> Gesendet: Montag, 2. Mai 2022 20:02
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Compile error
>
> Thanks, Gerd,
>
> I get the same error when using the default syle. In DJS.cfg, I placed this 
> line:
> style-file=C:\Users\Alask\Documents\mkgmap\examples\styles\default. That is 
> correct usage, right?
>
> Another list member told me to look for the offending tile in order to 
> manually split it, however, all the tiles look alike to me in terms of size. 
> How would I tell which tile is the "bad one" that's causing this RGN error?
>
> You mentioned adjusting some mkgmap parameters that would reduce the size 
> and/or complexity of the map I'm trying to create. The descriptive text in 
> the Options file for directives about processing lines and polygons doesn't 
> make clear how to reduce the amount of information they handle— can you offer 
> any suggestions?
>
> Thanks,
>
> Dave
>
>
>
> On Mon, May 2, 2022 at 9:23 AM Gerd Petermann 
> mailto:gpetermann_muenc...@hotmail.com>> 
> wrote:
> Hi Dave,
>
> the max-nodes value is already very small, so maybe something in mkgmap goes 
> very wrong.
> We probably need the input file (*.o5m) for the tile that fails and the style 
> unless you can reproduce the
> problem also with the default style.
>
> Gerd
>
> 
> Von: Dave Swarthout mailto:daveswarth...@gmail.com>>
> Gesendet: Montag, 2. Mai 2022 18:08
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Compile error
>
> Reducing the node count means I was adjusting the max-nodes value; I had been 
> using a value of 160,000 for max-nodes but after getting that error message, 
> I tried running splitter with max-nodes=120,000 and 100,000 nodes but that 
> had zero effect on the error message. There were more tiles generated by 
> splitter but the same error resulted.
>
> I've attached my splitter logs and the DJS.CFG file
>
> Thanks for the help
>
> On Mon, May 2, 2022 at 1:42 AM Gerd Petermann 
> mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
>  wrote:
> Hi Dave,
>
> what do you mean with "I've tried reducing the size of the node count but 
> that had no effect"? A smaller --max-nodes value for splitter should always 
> have an effect:
> More / different tiles. Maybe it just didn't change the size of the 
> problematic tile?
>
> So, if you don't want to "reduce the amount of information included in the 
> map" which means
> changing the style or options like --reduce-points, --levels etc, your only 
> option is to tell splitter to produce smaller tiles.
> That is done with the --max-nodes option or maybe allow trimming if the 
> problematic tile contains a huge area with sea only.
>
> Can't say much more without knowing the content of the problematic tile and 
> content of DJS.cfg.
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev 
> mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
>  im Auftrag von Dave Swarthout 
> mailto:daveswarth...@gmail.com><mailto:daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>>>
> Gesendet: Sonntag, 1. Mai 2022 02:06
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Compile error
>
> Hi,
>
> I'm not on this list anymore but I'm having a problem with mkgmap that I'm 
> unable to understand or fix.
>
> I'm getting this error all the time now.  "The RGN section of the map or tile 
> is too big. The maximum size is 16777215 bytes. Try splitting the map into 
> smaller tiles or reducing the amount of information included in the map."
>
> I've tried reducing the size of the node count but that had no effect. Here's 
> my command line:
>
> java -Xmx4000m -jar mkgmap.jar 

Re: [mkgmap-dev] Compile error

2022-05-02 Thread Dave Swarthout
@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

2022-05-02 Thread Dave Swarthout
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

2022-05-02 Thread Dave Swarthout
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

2022-05-02 Thread Dave Swarthout
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

2021-09-20 Thread Dave Swarthout
Hi Gerd,

It's probably because I don't use the default family id. I substitute my
own to prevent problems when using more than one map in my GPSr.

Here's my command line for my Eugene (Oregon) maps:
java -Xmx4000m -jar mkgmap.jar -c DJS.cfg --latin1 --family-id=24566
--name-tag-list=name,loc_name,int_name,alt_name --description="Eugene"
"C:\Users\Alask\Downloads\Maps\Eugene.osm" "C:\Users\Alask\Dropbox
(Personal)\Mapping\24983djs.TYP"

When compiling a map of Thailand, I use family-id=18028 and
description="Thailand" in my command line.

I picked those numbers out of the air, so to speak. It's an easy solution
that eliminates "conflicts" when checking my maps with the JaVaWa Device
Manager. My maps work fine so I presume these changes are a good fix. I
don't use splitter; all my maps are for areas that require OSM downloads of
less than 1 GByte.

Dave

On Sun, Sep 19, 2021 at 11:23 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Dave,
>
> the typ file contains fields for the family-id and the product-id. If
> those don't match the values used in the map it will not work, that's why
> mkgmap creates a copy.
> As Ticker said, there is code to prevent that a correct typ file is
> overwritten, so I wonder how you manage to have the x-file with identical
> content.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Dave Swarthout 
> Gesendet: Montag, 20. September 2021 02:08
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
>
> Why would you have mkgmap modify a TYP file for any reason? (FYI: My
> output goes to the same directory that contains my input files.)
>
> I would much rather see some sort of error message than have an
> undocumented (AFAIK) feature modify my TYP file, especially since there is
> no indication of that behaviour in the error stream. I've seen this x-file
> for years and could not (and still don't) see why it exists. Both TYP files
> always prove to be identical when checked by the ExamDiff program).
> Reiterating, if there is some sort of conflict in family/product numbers,
> let the user know about it through error messages and suggest remedies. But
> don't change his/her TYP file behind the scenes.
>
> On Sun, Sep 19, 2021 at 2:53 PM Ticker Berkin  <mailto:rwb-mkg...@jagit.co.uk>> wrote:
> Hi
>
> My reading of the code is that it won't create an x-version that is
> identical to the original, so I don't understand what Dave observes.
>
> I think the best solution is as Gerd suggests, if the binary input .typ
> file has the wrong family/product and is in the output direction, an
> error should be flagged. If it is in another directory, a patched
> version with the same name should be created in the output directory.
>
> Ticker
>
> On Sun, 2021-09-19 at 10:35 -0700, Dave Swarthout wrote:
> > FYI
> >
> > In my workflow, the source TYP file is not modified. Both TYP files,
> > the original and the x-version, are identical. However, my TYP file
> > is not a text file; it is a binary file that the TYPViewer program
> > generates. How that plays in this scenario I have no idea.
> >
> > On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann <
> > gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> > > Hi Ticker,
> > >
> > > OK, I agree that it isn't the best idea to modify a source file.
> > > So, maybe mkgmap should stop with an error message if that would
> > > happen?
> > >
> > > Gerd
> > >
> > > 
> > > Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag
> > > von Ticker Berkin  rwb-mkg...@jagit.co.uk>>
> > > Gesendet: Sonntag, 19. September 2021 18:31
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
> > >
> > > Hi
> > >
> > > With mkgmap compiling the .txt to .typ there is no problem - I'm
> > > assuming this question is only concerned with what happens when
> > > starting with a binary .typ file.
> > >
> > > If the .typ file already exists and has the wrong family/product
> > > and is
> > > in the directory that mkgmap will use for output files, then the
> > > options are:
> > >
> > > 1/ change the original .typ file, patching the family/product;
> > >   - it must be wrong to change an input file.
> > >
> > > 2/ use a different direc

Re: [mkgmap-dev] The x prepended to the *.typ file

2021-09-19 Thread Dave Swarthout
Why would you have mkgmap modify a TYP file for any reason? (FYI: My output
goes to the same directory that contains my input files.)

I would much rather see some sort of error message than have an
undocumented (AFAIK) feature modify my TYP file, especially since there is
no indication of that behaviour in the error stream. I've seen this x-file
for years and could not (and still don't) see why it exists. Both TYP files
always prove to be identical when checked by the ExamDiff program).
Reiterating, if there is some sort of conflict in family/product numbers,
let the user know about it through error messages and suggest remedies. But
don't change his/her TYP file behind the scenes.

On Sun, Sep 19, 2021 at 2:53 PM Ticker Berkin 
wrote:

> Hi
>
> My reading of the code is that it won't create an x-version that is
> identical to the original, so I don't understand what Dave observes.
>
> I think the best solution is as Gerd suggests, if the binary input .typ
> file has the wrong family/product and is in the output direction, an
> error should be flagged. If it is in another directory, a patched
> version with the same name should be created in the output directory.
>
> Ticker
>
> On Sun, 2021-09-19 at 10:35 -0700, Dave Swarthout wrote:
> > FYI
> >
> > In my workflow, the source TYP file is not modified. Both TYP files,
> > the original and the x-version, are identical. However, my TYP file
> > is not a text file; it is a binary file that the TYPViewer program
> > generates. How that plays in this scenario I have no idea.
> >
> > On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann <
> > gpetermann_muenc...@hotmail.com> wrote:
> > > Hi Ticker,
> > >
> > > OK, I agree that it isn't the best idea to modify a source file.
> > > So, maybe mkgmap should stop with an error message if that would
> > > happen?
> > >
> > > Gerd
> > >
> > > 
> > > Von: mkgmap-dev  im Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Sonntag, 19. September 2021 18:31
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
> > >
> > > Hi
> > >
> > > With mkgmap compiling the .txt to .typ there is no problem - I'm
> > > assuming this question is only concerned with what happens when
> > > starting with a binary .typ file.
> > >
> > > If the .typ file already exists and has the wrong family/product
> > > and is
> > > in the directory that mkgmap will use for output files, then the
> > > options are:
> > >
> > > 1/ change the original .typ file, patching the family/product;
> > >   - it must be wrong to change an input file.
> > >
> > > 2/ use a different directory for the patched version;
> > >- but where?
> > >
> > > 3/ use a different name for for the patched version;
> > >- this could be improved, so that rather than prefixing with x,
> > > a
> > >clearer suffix is added to the actual file but when this is
> > > added
> > >to gmapi/gmapsupp, the original name is used for the embedded
> > >component.
> > >
> > > At the moment mkgmap ignores the last condition "... is in the same
> > > directory ...", but this could be tested and, if not, the name
> > > could be
> > > kept and the new file created in the natural output directory.
> > >
> > > Ticker
> > >
> > > On Sun, 2021-09-19 at 08:38 -0700, Dave Swarthout wrote:
> > > > I have wondered where that "x-file" came from for years. To me,
> > > it's
> > > > totally unnecessary and confusing. I thought my typ file editor,
> > > > TypViewer, was creating it.
> > > > Even after reading the email and replies, I still don't
> > > understand
> > > > the reasoning behind having mkgmap creating this "backup" copy in
> > > the
> > > > first place but I think it should be got rid of.
> > > >
> > > > Thanks for clearing up the mystery!
> > > >
> > > > Dave
> > > >
> > > > On Sun, Sep 19, 2021 at 4:30 AM Gerd Petermann <
> > > > gpetermann_muenc...@hotmail.com> wrote:
> > > > > Hi Ticker,
> > > > >
> > > > > please explain why mkgmap is "stuck" with the fixed version.
> > > What's
> > > > > the difference between a fixed *.typ file and one

Re: [mkgmap-dev] The x prepended to the *.typ file

2021-09-19 Thread Dave Swarthout
FYI

In my workflow, the source TYP file is not modified. Both TYP files, the
original and the x-version, are identical. However, my TYP file is not a
text file; it is a binary file that the TYPViewer program generates. How
that plays in this scenario I have no idea.

On Sun, Sep 19, 2021 at 9:56 AM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Ticker,
>
> OK, I agree that it isn't the best idea to modify a source file.
> So, maybe mkgmap should stop with an error message if that would happen?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Ticker Berkin 
> Gesendet: Sonntag, 19. September 2021 18:31
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
>
> Hi
>
> With mkgmap compiling the .txt to .typ there is no problem - I'm
> assuming this question is only concerned with what happens when
> starting with a binary .typ file.
>
> If the .typ file already exists and has the wrong family/product and is
> in the directory that mkgmap will use for output files, then the
> options are:
>
> 1/ change the original .typ file, patching the family/product;
>   - it must be wrong to change an input file.
>
> 2/ use a different directory for the patched version;
>- but where?
>
> 3/ use a different name for for the patched version;
>- this could be improved, so that rather than prefixing with x, a
>clearer suffix is added to the actual file but when this is added
>to gmapi/gmapsupp, the original name is used for the embedded
>component.
>
> At the moment mkgmap ignores the last condition "... is in the same
> directory ...", but this could be tested and, if not, the name could be
> kept and the new file created in the natural output directory.
>
> Ticker
>
> On Sun, 2021-09-19 at 08:38 -0700, Dave Swarthout wrote:
> > I have wondered where that "x-file" came from for years. To me, it's
> > totally unnecessary and confusing. I thought my typ file editor,
> > TypViewer, was creating it.
> > Even after reading the email and replies, I still don't understand
> > the reasoning behind having mkgmap creating this "backup" copy in the
> > first place but I think it should be got rid of.
> >
> > Thanks for clearing up the mystery!
> >
> > Dave
> >
> > On Sun, Sep 19, 2021 at 4:30 AM Gerd Petermann <
> > gpetermann_muenc...@hotmail.com> wrote:
> > > Hi Ticker,
> > >
> > > please explain why mkgmap is "stuck" with the fixed version. What's
> > > the difference between a fixed *.typ file and one that is freshly
> > > compiled from *.txt?
> > >
> > > Gerd
> > >
> > > 
> > > Von: mkgmap-dev  im Auftrag
> > > von Ticker Berkin 
> > > Gesendet: Sonntag, 19. September 2021 13:25
> > > An: Development list for mkgmap; Steve Ratcliffe
> > > Betreff: Re: [mkgmap-dev] The x prepended to the *.typ file
> > >
> > > Hi
> > >
> > > If you don't use --output_dir but have map sources (.osm.pbf) and
> > > results (.img) all in the same place, and you specify a pre-built
> > > TYPfile with extension .typ, but it has the wrong family/product,
> > > mkgmap can adjust these, but is then stuck as to what to do with
> > > the
> > > fixed version, hence the "x" prefix to deal with this case.
> > >
> > > If --output-dir is specified and the .typ file wasn't in that when
> > > specified as an input parameter, then could avoid the rename.
> > >
> > > This doesn't effect me as I always use mkgmap to generate the .typ
> > > from
> > > the .txt as part of the final map generation process.
> > >
> > > Ticker
> > >
> > > On Sun, 2021-09-19 at 10:22 +, Gerd Petermann wrote:
> > > > Hi all,
> > > >
> > > > I think there is an old rather confusing glitch in mkgmap class
> > > > TypSaver which it is used with a *.typ file as input, as in
> > > > java -jar mkgmap.jar --output-dir= --family-id=4711
> > > ...
> > > > -c splitter-dir\template.args ..\typfiles\existing.typ
> > > > to make sure that family-id and product-id are correctly updated
> > > in
> > > > the *.typ file.
> > > > Since 2012 the program creates / overwrites a copy of file
> > > > existing.typ in the source(!) directory ..\typfiles with the
> > > prefix
> > > > "x"

Re: [mkgmap-dev] The x prepended to the *.typ file

2021-09-19 Thread Dave Swarthout
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

2020-09-13 Thread Dave Swarthout
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

2020-09-12 Thread Dave Swarthout
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

2020-08-09 Thread Dave Swarthout
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

2020-06-04 Thread Dave Swarthout
Those were my suggestions based on my rather limited experience. I knew
there are options for the java environment that require a single hyphen
(ex: -Xmx4000m -jar), and then there is the configuration file parameter
(which I forgot) but I ignored those for the sake of simplicity.

I think given what you just said, the need for a comprehensive help guide
is essential. Otherwise these sorts of questions and the amount of time it
takes to sort out the answers will only increase as the program grows more
complicated.

Also, if your 3rd point is true it only adds more confusion to the debate "
3) The typ file can appear anywhere but it is a good idea to place it at
the end"

How can it be "a good idea" to place the filespec for the TYP file at the
end if it is also true that  it "can appear anywhere"? The two assertions
appear to be in conflict in my reading of that statement

Dave

On Thu, Jun 4, 2020 at 10:34 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Dave,
>
> sorry, but your suggestion would be very wrong, esp. this one:
> "These parameters must be preceded by a double dash (two hyphens with no
> spaces between them) which are immediately followed by a command string.
> Each such parameter must be terminated with a comma with no space before or
> after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3)"
>
> 1) For historic reasons, some parameters require only one dash, e.g. -c or
> -n.
> 2) Only some parameters expect a comma separated option list, and since
> r4517 a "dangling" comma in those lists should provoke an error message.
> 3) The typ file can appear anywhere but it is a good idea to place it at
> the end
>
> The option handling is very difficult to understand, esp. as mkgmap offers
> so many different ways to do it. There is no way to document it in a few
> short sentences.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Dave Swarthout 
> Gesendet: Donnerstag, 4. Juni 2020 17:05
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10
>
> Pitney wrote:
> "The issue with options and order (of precedence?) still confuses me after
> using mkgmap for years."
>
> I reckon that was my point in opening this topic all along. I think I've
> got it now and it makes sense but the documentation could still be made
> clearer IMO. For example:
>
> Invoking the mkgmap java program involves supplying a list of parameters
> or commands that allow the user to control the operation of the program and
> the output generated by it.
>
> These parameters must be preceded by a double dash (two hyphens with no
> spaces between them) which are immediately followed by a command string.
> Each such parameter must be terminated with a comma with no space before or
> after it. (example: java -jar mkgmap.jar --parm1,--parm2,--parm3)
>
> All input file specifications (filename.ext) must follow the last option
> in the invocation string. You may use a full path for that filespec as long
> as it is enclosed in quotes. (Windows/Dos example:
> "C:\Users\username\Downloads\Maps\MyState.osm")
>
> Any type file specification (filename.typ) containing custom bitmaps for
> Garmin lines, polygons and points must be the last file specification in
> the list of input files.
>
> Etc.
>
> Thanks also to Gerd for the latest releases which addressed the spurious
> space issue and improved the program's error reporting. I'm sure these will
> go a long way toward smoother operations for those of us who are only
> casual users of mkgmap.
>
> Dave
>
> On Thu, Jun 4, 2020 at 9:12 PM Pitney  mappit...@gmail.com>> wrote:
> Hello
> The issue with options and order (of precedence?) still confuses me after
> using mkgmap for years. My solution is to not use option files and to hard
> code all file references. Not good scripting practice but it works.
> I think this is a case of where examples are worth a thousand words. I
> understand in theory option and file order but do not know how to implement
> it in practice. Examples (in a separate file?) and how to work out which
> files they will effect may reduce confusion.
> I only have a tablet in quarantine so I apologize for any formatting
> issues.
> Pitney
>
> On June 4, 2020, at 2:11 AM, mkgmap-dev-requ...@lists.mkgmap.org.uk
> <mailto:mkgmap-dev-requ...@lists.mkgmap.org.uk> wrote:
>
> Send mkgmap-dev mailing list submissions to
> mkgmap-dev@lists.mkgmap.org.uk mkgmap-dev@lists.mkgmap.org.uk>
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> or, vi

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 143, Issue 10

2020-06-04 Thread Dave Swarthout
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

2020-06-03 Thread Dave Swarthout
Hi again Gerd,

 Regarding the change to the error message. Well,  yes, what you've done
should help, however, the error in my case wasn't caused by an improper
file specification but by a typo in a parameter. I think it would be really
helpful to tell the user that the error was in a parameter as opposed to in
a filespec. Then if the latter is the case, the error message would supply
the offending filespec by name enclosed in quotes.

I am not clear what you are saying in the first paragraph in your latest
reply. I'm looking for a way to make the required arrangement of the
parameters and input files in the mkgmap invocation more prominent. I
simply missed the one mention of it because it wasn't very obvious as it
is, which is included in a paragraph about splitter. I realize you can't
use bold text in the options file (which is a plain ASCII text file) but if
it were set off in some way so it was more easily seen, that would help a
lot.

You said, "Maybe mkgmap should warn once when such an option is not the
same for all processed tiles?"

I'm unclear about this. Aren't all "tiles" processed in a run of mkgmap?
I'm not using splitter. My maps are always limited to a small enough piece
of my immediate area so I don't need splitter. When I'm traveling I
download new pieces of the state or country as I move through it and
compile new maps as I go.

Thanks for your effort. I really appreciate it.

Dave



On Thu, Jun 4, 2020 at 12:10 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Dave,
>
> I fear we can document whatever we want, this misunderstanding happens
> again and again. With the --style option it is very obvious and the user
> will find out. With
> other options like --link-pois-to-ways it might take longer as its effect
> is not so obvious.
> Maybe mkgmap should warn once when such an option is not the same for all
> processed tiles?
>
> I've changed the error message a little bit : Severe(Main): name: input
> file 'name' doesn't exist.
> Maybe it should be changed to "SEVERE (Main): name: input file 'name'
> doesn't exist. Was it meant as an option?" because the "filename" has no
> dot and thus no extension?
>
> Gerd
>
> 
> Von: Dave Swarthout 
> Gesendet: Donnerstag, 4. Juni 2020 01:11
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Options file
>
> I agree that the bit about parm placement should not be repeated. I saw
> and read the text you provided but for some reason associated it more with
> splitter rather than mkgmap as a whole. It doesn't stand out very well the
> way it's written now. My bad.
>
> Also, I think it would be good if the filename in the error message was
> enclosed in quotes. Again, it might be obvious to you developers that "file
> name" is different than "filename" but it wasn't to me. If the message had
> said "SEVERE (Main): name: file "name" doesn't exist, it would have been so
> much more helpful.
>
> I'm all set now. Thanks very much, Gerd.
>
> Dave
>
> On Wed, Jun 3, 2020 at 10:24 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Dave,
>
> See r4511.
> I don't know if it helps, command line parsing depends on the OS / used
> shell as well.
> On windows this change allows to use  --name-tag-list="name:de,name:en,
> name"
>
> Reg. your other question about the documentation of the importance of
> order in the options: This is documented and it is true for almost all
> options, so it makes no sense to repeat the hint for each option:
> "The order of the options is significant in that options only apply to
> subsequent input files. If you are using splitter, you probably will need
> to
> put most of your options before '-c template.args' (this file is generated
> by
> splitter). "
>
> Gerd
>
> 
> Von: Dave Swarthout  daveswarth...@gmail.com>>
> Gesendet: Mittwoch, 3. Juni 2020 16:59
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Options file
>
> OMG!  An extra space?
>
> Yep, that fixed it. Is there some way to make the processing of that parm
> string more robust?
>
> Thank you for your quick response.
>
> On Wed, Jun 3, 2020 at 6:01 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi Dave,
>
> I think

Re: [mkgmap-dev] Options file

2020-06-03 Thread Dave Swarthout
I agree that the bit about parm placement should not be repeated. I saw and
read the text you provided but for some reason associated it more with
splitter rather than mkgmap as a whole. It doesn't stand out very well the
way it's written now. My bad.

Also, I think it would be good if the filename in the error message was
enclosed in quotes. Again, it might be obvious to you developers that "file
name" is different than "filename" but it wasn't to me. If the message had
said "SEVERE (Main): name: file "name" doesn't exist, it would have been so
much more helpful.

I'm all set now. Thanks very much, Gerd.

Dave

On Wed, Jun 3, 2020 at 10:24 PM Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Dave,
>
> See r4511.
> I don't know if it helps, command line parsing depends on the OS / used
> shell as well.
> On windows this change allows to use  --name-tag-list="name:de,name:en,
> name"
>
> Reg. your other question about the documentation of the importance of
> order in the options: This is documented and it is true for almost all
> options, so it makes no sense to repeat the hint for each option:
> "The order of the options is significant in that options only apply to
> subsequent input files. If you are using splitter, you probably will need
> to
> put most of your options before '-c template.args' (this file is generated
> by
> splitter). "
>
> Gerd
>
> 
> Von: Dave Swarthout 
> Gesendet: Mittwoch, 3. Juni 2020 16:59
> An: Gerd Petermann
> Cc: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Options file
>
> OMG!  An extra space?
>
> Yep, that fixed it. Is there some way to make the processing of that parm
> string more robust?
>
> Thank you for your quick response.
>
> On Wed, Jun 3, 2020 at 6:01 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Dave,
>
> I think there is a superflous space in the name-tag-list before name:
> name:en,loc_name:en,int_name,alt_name:en,short_name:en, name
>
> This means that mkgmap searches for an input file with the name 'name' and
> that also explains the error message.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Dave Swarthout <
> daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>>
> Gesendet: Mittwoch, 3. Juni 2020 12:33
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Options file
>
> This is a two-part question.
> Firstly:
> I have been trying to change my compilation method to use a config file
> but am having problems. During my experimentations I managed to insert the
> style file directive "--style-file=directory|zip-filename|url" _after_ the
> filespec for the OSM data file. My map compiled without errors but was not
> using my styles. I was very confused because it had always worked before.
> It took me 20 or 30 minutes to discover that I had accidentally "misplaced"
> my style file parameter in the mkgmp parameter list. Once I moved it in
> front of the filespecs for my OSM data file and custom TYP file, all was
> well again.
>
> I am assuming that the "options" file included with every mkgmap download
> is the primary help file for running mkgmap. So I guess I'm asking if
> someone would please add a sentence to the options file where the use _and
> placement_ of the style file parameter is explained more completely. The
> way it is now, one cannot know that the placement of that parameter is
> important. Apparently,  the placement of ALL parameters must come before
> any filespecs in the mkgmap invocation but that important fact isn't
> obvious (at least to me) from reading the options help file.
>
> A line saying "the style file parameter must appear before any references
> to a file specification for input data or custom TYP file." inserted just
> after the "=== Style options ===" section divider would be very helpful
>
> Or perhaps a line at the very top of the options file saying "Note: all
> options specified herein must appear on the mkgmap invocation before any
> reference to an OSM input file or a custom TYP file."
>
> ***
> Secondly:
>
> The problem I'm having with using a configuration file might be related to
> file specifications, but I'm not sure. My first try used the filespecs in
> quotes as they appear in my parm specification. That didn't work. When I
> compile a map using the scenario below, mkgmap p

Re: [mkgmap-dev] Options file

2020-06-03 Thread Dave Swarthout
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

2020-06-03 Thread Dave Swarthout
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

2020-05-28 Thread Dave Swarthout
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?

2018-12-09 Thread Dave Swarthout
Regarding my last post: The rule you gave me works but, as I said, it
renders any boundary that has a name, including in my case, a township
administrative boundary. However, it also renders both inner and outer
ways. I'm going to give up on that for now, unless anyone can think of a
way to convince mkgmap to render inners separately from outers. It's not a
big deal. I can easily live with what I have.

The non-rendering islands issue was my own fault. I forgot to assign
role=inner to the islands in a multipolygon relation they are also a part
of. The boundary rendered fine but there was no "land" showing. (The
islands are all outers in the Kodiak National Wildlife Refuge relation.)
Anyway, all is well now.

Thanks,

Dave

On Sat, Dec 8, 2018 at 9:10 PM Dave Swarthout 
wrote:

> That does work but it makes all ways that are named boundary relations (
> with mkgmap:boundary_name =*) render with the same style. I can live with
> that but I'm still wondering if there is a way to force it to only operate
> on inners and only on ways of type boundary=protected_area ? Can I set in
> "relations" and test in "lines" for a new mkgmap:boundary_name, for
> example, boundary1_name?
>
> Another interesting problem I just noticed is that simple islands (not
> multipolygons) whose coastlines are also boundaries do not display as
> islands, only as members of the refuge they are a part of. The coastlines
> fail to display whether or not the above code is active or commented out so
> it must be a separate issue. Take a look at Village Islands inside the
> Kodiak National Wildlife Refuge. These display as  continuous boundaries
> with my style [0x10e12], but there is no "land" inside the boundaries, only
> sea. So, these objects are tagged as place=islet, natural=coastline, but
> they are also outers in the Kodiak National Wildlife Refuge.
>
> Dave
>
> On Sat, Dec 8, 2018 at 6:13 PM Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Dave,
>>
>> there is code in mkgmap to treat multipolygon relations. See
>> mkgmap:mp_created and mkgmap:stylefilter in
>> http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf
>> The multipolygon code produces those extra ways only for the outer rings.
>> If you just want to render the outlines you may use something like
>> mkgmap:boundary_name=* 0x10e12 resolution 19 continue]
>> at the top of the lines file.
>>
>> Gerd
>>
>> 
>> Von: Dave Swarthout 
>> Gesendet: Samstag, 8. Dezember 2018 11:30
>> An: Gerd Petermann
>> Cc: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] How can I force the inners of a boundary
>> relation to display?
>>
>> Yes, that's confusing to me. I included those snippets to illustrate what
>> I am currently using — maybe you can explain to me stepwise how those
>> boundaries get rendered?
>>
>> Is there code inside mkgmap that interprets such directives and applies
>> tags to the outer ways of relations? If there is then I assume the same can
>> be done for those inners. And you would be the one who can best answer that
>> question.
>>
>> Thanks for taking the time to explain.
>>
>> Dave
>>
>> On Sat, Dec 8, 2018 at 5:03 PM Gerd Petermann <
>> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
>> wrote:
>> Hi Dave,
>>
>> in the relations rule you set mkgmap:boundary_name but in the lines rule
>> you don't use that.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev > mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Dave Swarthout <
>> daveswarth...@gmail.com<mailto:daveswarth...@gmail.com>>
>> Gesendet: Samstag, 8. Dezember 2018 03:18
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] How can I force the inners of a boundary relation
>> to  display?
>>
>> Hi,
>>
>> I've been adding large Alaskan National Wildlife Refuges to OSM. The
>> boundaries weren't displaying so I added a directive in my relations file
>> modeled after the administrative boundary code in the default style that
>> adds a name to protected areas like so:
>>
>> (type=boundary | type=multipolygon) & boundary=protected_area & name=*
>> { apply
>>   {
>> set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' |
>> '${name}';
>>   }
>> }
>>
>> Then in my lines file I included a line style defined as:
>> boundary=nature_reserve | boundary=protected_

Re: [mkgmap-dev] How can I force the inners of a boundary relation to display?

2018-12-08 Thread Dave Swarthout
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?

2018-12-08 Thread Dave Swarthout
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?

2018-12-07 Thread Dave Swarthout
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?

2018-12-07 Thread Dave Swarthout
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

2018-11-07 Thread Dave Swarthout
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

2018-11-07 Thread Dave Swarthout
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

2018-11-07 Thread Dave Swarthout
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

2018-11-06 Thread Dave Swarthout
"+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

2018-02-22 Thread Dave Swarthout
Thank you.

On Thu, Feb 22, 2018 at 1:34 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Dave,
>
> you should not need it, it was introduced in 2013 to allow using old style
> files, see
> http://www.mkgmap.org.uk/news/2013/12/22/more-flexibility-
> in-style-files-style
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Dave Swarthout 
> Gesendet: Donnerstag, 22. Februar 2018 01:44:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] bug into the style file: default\inc\compat_lines
>
> I found the line and made the fix Steve described. But, while doing that I
> learned that none of my style files calls compat_lines. Nor is it called
> from any of the files in the standard style set that came with mkgmap 3994.
>
> Can you explain where it should be used and why?
>
> On Thu, Feb 22, 2018 at 4:37 AM, Steve Ratcliffe  <mailto:st...@parabola.me.uk>> wrote:
> On 21/02/18 20:40, Ataro wrote:
> the default style file:? default\inc\compat_lines
> have a bug into the line 124:? { setaccess=no;
>
> have to be changed as follows: { setaccess no;
>
> That is true, thanks.  I've fixed this now.
>
>
> Best wishes
> Steve
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
>
> --
> Dave Swarthout
> Homer, Alaska
> Chiang Mai, Thailand
> Travel Blog at http://dswarthout.blogspot.com
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] bug into the style file: default\inc\compat_lines

2018-02-21 Thread Dave Swarthout
I found the line and made the fix Steve described. But, while doing that I
learned that none of my style files calls compat_lines. Nor is it called
from any of the files in the standard style set that came with mkgmap 3994.

Can you explain where it should be used and why?

On Thu, Feb 22, 2018 at 4:37 AM, Steve Ratcliffe 
wrote:

> On 21/02/18 20:40, Ataro wrote:
>
>> the default style file:? default\inc\compat_lines
>> have a bug into the line 124:? { setaccess=no;
>>
>> have to be changed as follows: { setaccess no;
>>
>
> That is true, thanks.  I've fixed this now.
>
>
> Best wishes
> Steve
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r3971: - roadNameConfig_v1.patch by Carlos Davida which adds more countries and languages

2017-06-14 Thread Dave Swarthout
Is anyone interested in adding a section for Thailand?I don't know how to
add them to the configuration file .

There are only a few prefixes in use in Thailand, the most common by far is
"thanon" (ถนน = road), and a few names begin with "soi" (ซอย = lane). Most
often you find the word "soi" at the end of a street name, for example,
Thanon Mahidol Soi 5 (Mahidol Road Lane 5).

Having just those two prefixes in play would help a lot.

Cheers,

Dave

On Wed, Jun 14, 2017 at 7:06 AM, Carlos Dávila 
wrote:

> In what way do you think it is more efficient? I thought you could be
> talking about roads including more than one prefix1 in their name, eg.
> "Avenida de la Calle Mayor", but I tested that name and I can't see any
> difference in search behavior on MapSource. By the way, I found that when
> road name includes two words listed in prefix1 you can still search by the
> original full name:
> Road name: Avenida de la Calle Mayor
> prefix1:es = "Alameda", "Avenida", "Calle", "Callecita", "Paseo" (or
> "Alameda", "Calle", "Avenida", "Callecita", "Paseo")
> You can search both Avenida de la Calle Mayor and Calle Mayor
> Perhaps that can give a clue to include original name in all cases
>
> El 14/06/17 a las 15:11, Alexandre Folle de Menezes escribió:
>
>
>> Hola Carlos,
>>
>> I see that you are listing the prefixes in alphabetic order.  I believe
>> it would be way more efficient to put the most common prefixes first.
>>
>> For Portuguese, that would be (as I suggested in a previous message):
>>
>> -# portugese
>> -prefix1:pt = "Rua", "Avenida", "Travessa"
>> -prefix2:pt = "da ", "do ", "de ", "das ", "dos "
>> +# portuguese
>> +prefix1:pt = "Rua", "Avenida", "Travessa", "Alameda", "Beco"
>> +prefix2:pt = "da ", "do ", "das ", "dos ", "de ", "d'"
>> Saludos,
>>
>> Alexandre
>>
>> Em 13/06/2017 18:19, Carlos Dávila escreveu:
>>
>>> El 12/06/17 a las 06:22, svn commit escribió:
>>>
>>>> Version mkgmap-r3971 was committed by gerd on Mon, 12 Jun 2017
>>>>
>>>> - roadNameConfig_v1.patch by Carlos Davida which adds more countries
>>>> and languages
>>>> - Improve comments
>>>>
>>>> Attached is version 2 of roadNameConfig.patch
>>> I'm working in the completion of roadNameConfig file. I think if I could
>>> somehow get a file with the list of road names in a map I could advance
>>> faster in this task. Is there any tool to get it in the display project?
>>>
>>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Missing sea and coastline while using Splitter

2017-04-11 Thread Dave Swarthout
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)

2017-04-11 Thread Dave Swarthout
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

2017-03-22 Thread Dave Swarthout
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

2017-03-21 Thread Dave Swarthout
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

2017-03-17 Thread Dave Swarthout
No problem, Gerd. I can't explain it much better and there are probably
other demands on your time that are more important. What was the original
goal of the "if-then" item on the "to-do" list?

On Thu, Mar 16, 2017 at 10:30 PM, Andrzej Popowski 
wrote:

> Hi Gerd,
>
> if-then-else is great. The last problem with admin boundaries doesn't
> change it. We can apply the same the basic syntax for a rule, regardless if
> inside or outside of if-then-else condition and simply accept, that rules
> for boundaries can't be rewritten with if-then-else. They are simple rules,
> so no much gain anyway.
>
> For me the primary application for if-then-else would be with
> style-option, like this:
>
> if (mkgmap:option:...=true) then
>   ...
> else
>   ...
> end
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Parallel major roads to cycleways

2017-03-16 Thread Dave Swarthout
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

2017-03-16 Thread Dave Swarthout
I don't like it but I don't know what to tell you to replace it with. All
such "tricks" make writing code less than straightforward and penalize the
casual user greatly. I am grateful to you and Ticker, et. al., for making
an effort to add this functionality but IMO if you resort to such
techniques it will be defeating the very purpose of creating the If-Then
construct, that purpose being to simplify the writing of these somewhat
strange style rules.

Respectfully,

Dave

On Thu, Mar 16, 2017 at 3:34 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Andrzej,
>
> well, my problem is the possible misinterpretation caused by ambiguity
> caused by the if-then interpretation,
> but I think I have found a possible solution.
>
> Let's look at some rules for boundaries in the default style:
> v1)
> boundary=administrative { name '${mkgmap:boundary_name}' }
> boundary=administrative & admin_level<3 [0x1e resolution 12]
> boundary=administrative & admin_level<5 [0x1d resolution 19]
> boundary=administrative & admin_level<7 [0x1c resolution 21]
> boundary=administrative & admin_level<9 [0x1c resolution 22]
> boundary=administrative [0x1c resolution 22]
>
> We said we want to be able to use if-then like this:
> v2)
> if (boundary=administrative ) then
> { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> [0x1c resolution 22]
> end
>
> With r3838 this did not work, because the each rule needs an expression.
> Ticker suggested to add a dummy expression like 1=1 so we would write
> v3)
> if (boundary=administrative ) then
> 1=1 { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> 1=1 [0x1c resolution 22]
> end
>
> but this is also not working as 1=1 is interpreted as $1='1' instead of
> "true"
>
> Now I noticed that the scanner allows to use () as an empty expression.
> So instead of v1 one already can write
> v4)
> if (boundary=administrative ) then
> () { name '${mkgmap:boundary_name}' }
> admin_level<3 [0x1e resolution 12]
> admin_level<5 [0x1d resolution 19]
> admin_level<7 [0x1c resolution 21]
> admin_level<9 [0x1c resolution 22]
> () [0x1c resolution 22]
> end
>
> If we document this we no longer have a problem with the "one expression
> two objects" syntax like this:
> a=b [0xc ... resolution 24][0x10801 resolution 24]
> because we still say that a rule must start with an expression and mkgmap
> can automaticalyl
> add "continue" or "continue with_actions" for all but the last type
> defintion.
>
> If you don't like the () 'trick' I can again try to make a style function
> like true()  work.
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag von
> Andrzej Popowski 
> Gesendet: Freitag, 10. März 2017 20:14:49
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi Gerd,
>
> my idea was more simple, than your implementation. I just would like to
> create multiple map objects with single rule. I didn't put "continue"
> there, because I assumed, that all element type definition should be
> processed.
>
> Still "continue" could be applied, it would mean, that OSM object is
> processed further, possibly resulting in 3-rd map object or more. I
> think "continue" or "continue with_actions" could be added to last type
> definition.
>
> Any other more complicated rules, like adding actions after first type
> definition, could be written just like now, with multiple statements.
> While I appreciate more flexibility I'm afraid, it could clutter the style.
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] if-then-else in style and style options

2017-03-08 Thread Dave Swarthout
This is probably coming too late but I was going to suggest earlier that
the "end" directive be changed to "endif" to be more consistent with other
programming languages. I've been away from programming for a long time -
many languages (Java, C++, PHP) seem to use braces to end a control loop
nowadays. No big deal either way.

Also, in your example, would an "Else" directive before the "[0x1c
resolution 22]" the do the job? The program would still have to 'remember"
that it was evaluating the "if " statement above, however.

Dave

On Wed, Mar 8, 2017 at 3:34 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> It would not work because 1=1 is interpreted as
> $1='1'
> and that will probably not be true.
> Same effect with '1' = '1' .
>
> Maybe we can add a style function "true()" which always retrurns true for
> this?
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag von
> Ticker Berkin 
> Gesendet: Mittwoch, 8. März 2017 09:25:34
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] if-then-else in style and style options
>
> Hi
>
> I think you should document that you need a dummy condition, ie
>
> if (...) then
>   1=1 {action}
>   ...
>   1=1 [0x1c ...]
> end
>
> (I assume this should work OK)
>
> Ticker
>
> On Wed, 2017-03-08 at 08:07 +, Gerd Petermann wrote:
> > Hi all,
> >
> > while writing the documentation I noticed this possible problem case:
> > The lines file in the default style contains these rules:
> > boundary=administrative { name '${mkgmap:boundary_name}' }
> > boundary=administrative & admin_level<3 [0x1e resolution 12]
> > boundary=administrative & admin_level<5 [0x1d resolution 19]
> > boundary=administrative & admin_level<7 [0x1c resolution 21]
> > boundary=administrative & admin_level<9 [0x1c resolution 22]
> > boundary=administrative [0x1c resolution 22]
> >
> > So, one may want to extract the clause boundary=administrative  like
> > this:
> > if (boundary=administrative) then
> > { name '${mkgmap:boundary_name}' }
> > admin_level<3 [0x1e resolution 12]
> > admin_level<5 [0x1d resolution 19]
> > admin_level<7 [0x1c resolution 21]
> > admin_level<9 [0x1c resolution 22]
> > [0x1c resolution 22]
> > end
> >
> > The problem: It doesn't work because the lines
> > { name '${mkgmap:boundary_name}' }
> > and
> > [0x1c resolution 22]
> > are not a valid rules and the rule parser "forgets" that the
> > boundary=administrative expression will be added.
> >
> > What do you think? Should mkgmap support this syntax?
> >
> > Gerd
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Gerd Petermann 
> > Gesendet: Dienstag, 7. März 2017 20:10:52
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] if-then-else in style and style options
> >
> > Hi Andrzej,
> >
> > thanks, so I'll try to document the new syntax next.
> >
> > Gerd
> > 
> > Von: mkgmap-dev  im Auftrag
> > von Andrzej Popowski 
> > Gesendet: Dienstag, 7. März 2017 17:40:16
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] if-then-else in style and style options
> >
> > Hi Gerd,
> >
> > I have run some tests with current code and spotted no problems. I
> > have
> > tested both, if-then-else statement and style-option.
> >
> > --
> > Best regards,
> > Andrzej
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] if-then-else in style and style options

2017-03-07 Thread Dave Swarthout
I'm sorry Gerd, I want to experiment with the new statements but I just
don't have the time to play at the moment. Please commit the changes if you
haven't already, and I'll get the new version and experiment when I can.

Dave

On Tue, Mar 7, 2017 at 9:09 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Any feedback on this?
>
> If nobody is interested in using if-then-else in style I'd be happy to use
> only the style-option_v3.patch
> for trunk.
>
> Gerd
> 
> Von: mkgmap-dev  im Auftrag von
> Gerd Petermann 
> Gesendet: Mittwoch, 1. März 2017 15:54:02
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] if-then-else  in style and style options
>
> Hi all,
>
> I've applied the style-option_v3.patch to the branch, for details see  log
> message:
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3827
>
> I've also tried to fix the known problems with the interpretation of if
> then statements,
> so I hope it works now:
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&path=%2F&;
>
> Just to make this clear: The if statements are translated to "normal"
> rules, so you cannot do anything
> with if-then which would not work without, you should also not (yet)
> exprect run time improvements.
> The advantage is that you don't have to repeat phrases.
>
> A complex sample that shows a possible usage.
> # Roundabouts
> if (junction=roundabout) then
> if (mkgmap:option:single-roundabout=true) then
> (highway=trunk | highway=trunk_link) [0x0c road_class=4
> road_speed=2 resolution 18]
> (highway=primary | highway=primary_link) [0x0c
> road_class=3 road_speed=2 resolution 19]
> (highway=secondary | highway=secondary_link) [0x0c
> road_class=2 road_speed=2 resolution 20]
> (highway=tertiary | highway=tertiary_link) [0x0c
> road_class=1 road_speed=1 resolution 21]
> else
> (highway=trunk | highway=trunk_link) [0x0c road_class=4
> road_speed=2 resolution 24 continue]
> (highway=trunk | highway=trunk_link) [0x10801 resolution
> 18]
>
> (highway=primary | highway=primary_link) [0x0c
> road_class=3 road_speed=2 resolution 24 continue]
> (highway=primary | highway=primary_link) [0x10802
> resolution 19]
>
> (highway=secondary | highway=secondary_link) [0x0c
> road_class=2 road_speed=2 resolution 24 continue]
> (highway=secondary | highway=secondary_link) [0x10803
> resolution 20]
>
> (highway=tertiary | highway=tertiary_link) [0x0c
> road_class=1 road_speed=1 resolution 24 continue]
> (highway=tertiary | highway=tertiary_link) [0x10804
> resolution 21]
> end
> # minor roundabouts need no overlay
> (highway=unclassified | highway=minor ) [0x0c road_class=1
> road_speed=1 resolution 21]
> highway=* [0x0c road_class=0 road_speed=1 resolution 22]
> end
>
> If the corresponding block in the default style lines file is replaced
> with these rules, you can
> use option --style-option=single-roundabout to enable the rules which
> don't add 0x180x lines as overlays for roundabouts.
>
> It might be possible to completely remove rules which would never be
> triggered but that is quite complex, so I leave that for later.
>
> Gerd
> _______
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] if-then in style

2017-02-27 Thread Dave Swarthout
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

2017-02-08 Thread Dave Swarthout
On Thu, Feb 9, 2017 at 1:26 AM, lig fietser  wrote:

I would suggest to set smoothness ~ '.*(very_bad|horrible|impassable)'  and
> give smoothness=bad a road_speed penalty.


+1

That's what I did in my styles. It's a useful compromise.


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] To do: If-Then-Else

2017-02-08 Thread Dave Swarthout
It would be easier for the parser without curly braces:
+1

I was gonna suggest not using curly-braces earlier but don't know enough
about parsers to make such a request. Seeing as they're already required in
other places, it would be advantageous to not require them again in this
context.

Dave

On Wed, Feb 8, 2017 at 6:28 PM, Steve Ratcliffe 
wrote:

>
> Hi
>
> don't know if this helps:
>> I see one possible implementation for a conditional rule like
>> if () {
>>  some rules
>> } else {
>> other rules
>> }
>> where  would be something like tag=val, maybe also a parameter given
>> to the program.
>> If someone knows how to implement the syntax parser for such an
>> if-thent-else clause the evaluation could simply
>>
>
> It would be easier for the parser without curly braces:
>
> if (  some rules
> else
>  other rules
> endif
>
> I could make that work.
>
> ..Steve
>
> translate the if () to a rule like
>> exp {set special_var_x=true;}
>> and then add this special tag with tag=true or tag!=true to each
>> conditional rule.
>> So, we would not  need many changes in the evaluation of the rules, only
>> in the parser.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> Mike Baggaley 
>> Gesendet: Dienstag, 7. Februar 2017 18:22:32
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] To do: If-Then-Else
>>
>> Hi Andrzej, can you not make use of mkgmap:country to handle this
>> scenario?
>>
>> mkgmap:country=DZA | mkgmap:country=AGO |  mkgmap:country=SHN |
>> mkgmap:country=BEN ... {set continent=AF}
>>
>> continent=AF & landuse=farmland [0x10f01 level 1]
>>
>> Would mkgmap be better with a mkgmap:continent variable using
>> place=continent added?
>>
>> Regards,
>> Mike
>>
>> -Original Message-
>> From: Andrzej Popowski [mailto:po...@poczta.onet.pl]
>> Sent: 07 February 2017 12:39
>> To: mkgmap-dev@lists.mkgmap.org.uk
>> Subject: Re: [mkgmap-dev] To do: If-Then-Else
>>
>> Hi Dave,
>>
>> I think the idea is to include some preprocessing capability to style
>> interpreter.
>>
>> I develop a single style for my topo maps, but I need some possibility
>> to get a small variation in style depending on region. For example I
>> prefer to show landuse=farmland on a map of Africa but to remove it on a
>> map of Europe. So instead of maintaining 2 nearly identical styles, I
>> would like to get a conditional statement, something like:
>>
>> if (SHOW_FARMS) (
>> landuse=farmland [0x10f01 level 1]
>> )
>>
>> and then add (or not) an option to mkgmap like --style-define=SHOW_FARMS
>>
>> --
>> Best regards,
>> Andrzej
>>
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] To do: If-Then-Else

2017-02-07 Thread Dave Swarthout
if () {
 some rules
} else {
other rules
}

That's exactly what I had in mind. Adding another parameter, like a
CONSTANT, to the invocation would work (especially for the case of building
clutter) but is not nearly as flexible or powerful as an internal
if-then-else capability to process style rules and act on them
conditionally.


On Wed, Feb 8, 2017 at 4:35 AM, Andrzej Popowski 
wrote:

> Hi Gerd,
>
> could you implement simple conditional statements, which would be analyzed
> at the stage of reading style? Similarly like statement "include" is
> processed.
>
> I think the simplest version would contain 3 tokens:
> ifdefined CONSTANT
> ifnotdefined CONSTANT
> endif
>
> Scanner should look for ifdefined/ifnotdefined, check if CONSTANT exist
> and then analyze or skip rules until it finds token endif. It should
> support nesting. CONSTANT would be given as command line option. Or maybe
> even as an additional token, like "define CONSTANT".
>
>
> --
> Best regards,
> Andrzej
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

2017-02-07 Thread Dave Swarthout
I have never mapped any myself. Mostly, AFAIK, ice roads are used by large
vehicles on the North Slope of Alaska where they haul supplies to the oil
fields or out to wellheads in the Arctic Ocean. There are only three in
Alaska, two are service roads, one uses the ice_road=yes tag, the other
surface=ice while the last is actually a ferry route on a frozen river.
That one was tagged with ice_road=yes and surface=ice_road. I changed the
surface tag to surface=ice and left the other tags as is but I don't think
tagging a ferry route as an ice_road is correct.

As for tagging, I would consider them unpaved at the minimum because IMO
drivers of ordinary vehicles would generally want to avoid them. In the
case of the oil field service roads, those are most likely restricted
(acess=private) anyway so shouldn't be used in a routing scenario. Your
ice_road rule looks good to me and sidesteps the question of setting them
to unpaved nicely.

I found your full surface rule and inserted it into my lines style sheet
instead of the one I had been using.

Thank you.

On Tue, Feb 7, 2017 at 4:08 PM, lig fietser  wrote:

> Talking about surface=ice, how do we handle ice_road=yes? Those roads are
> common in the Arctic regions and cross frozen lakes, so only accessible in
> winter. See http://overpass-turbo.eu/s/ls3
>
> In the generic new style map I made those roads unroutable.
> https://github.com/ligfietser/mkgmap-style-sheets/blob/
> master/styles/generic%20new/lines
> highway=* & ice_road=yes { addlabel 'ice road' } [0x10002 resolution 24]
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] To do: If-Then-Else

2017-02-07 Thread Dave Swarthout
I came across the mkgmap ToDo list the other day and one item struck me as
something I would really like to see in a coming release. The ability to
evaluate If-Then-Else constructs would make writing, evaluating and
debugging style rules so much easier.

+1 on this item

Also, a little clarification please. The list item says:

   - conditional includes in style files and/or if else statements

I don't understand this statement. Perhaps it's because I'm assuming a
"conditional include" means:

If (condition) Then include 'inc/address';

Or does it mean, for example,

If (condition) { add mkgmap:unpaved=1 }

Thank you in advance.

AlaskaDave

-- Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] unpaved roads

2017-02-06 Thread Dave Swarthout
But none are "paved" in the usual sense of that word. I would hate to drive
on a "fine gravel" road, or an ice road, unless I was prepared for it. Even
if the fine gravel were on top of a compacted substrate it would present a
hazard to bicycles and motorcycles. I'm not sure I care how a "salt" road
is classified - I've never seen one let alone driven on one.

On Tue, Feb 7, 2017 at 2:41 PM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi all,
>
> I noticed that the wiki
> http://wiki.openstreetmap.org/wiki/Key:surface
> mentions a few more surface values which are considered unpaved compared to
> the default style.
> The current rule in the lines file contains  this
> highway=*
> & (surface=cobblestone | surface=compacted | surface=dirt |
>surface=earth | surface=grass | surface=grass_paver |
>surface=gravel | surface=grit | surface=ground | surface=mud |
>surface=pebblestone | surface=sand | surface=unpaved |
>mtb:scale=* |
>tracktype ~ 'grade[2-6]' |
>smoothness ~ '.*(bad|horrible|impassable)' |
>sac_scale ~ '.*(mountain|alpine)_hiking' |
>sport=via_ferrata)
> { add mkgmap:unpaved=1 }
>
> The wiki also llists these as unpaved:
> gravel_turf , fine_gravel, ice, salt, snow, woodchips
>
> I think the rule should at least contain gravel_turf, snow, and woodchips.
> My understanding is that fine_gravel, ice , and salt are rather smooth
> surfaces.
>
> Comments?
>
> Gerd
>
>
>
> --
> View this message in context: http://gis.19327.n8.nabble.
> com/unpaved-roads-tp5890722.html
> Sent from the Mkgmap Development mailing list archive at Nabble.com.
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r3696: Fix documentation error.

2016-10-17 Thread Dave Swarthout
On Mon, Oct 17, 2016 at 4:59 PM, Steve Ratcliffe 
wrote:

> () - parentheses
> [] - square brackets
> {} - curly braces
> <> - angle brackets
>
> All those sound fine from a UK perspective.  Any problems?
>

Perfect. Sounds good.


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r3696: Fix documentation error.

2016-10-16 Thread Dave Swarthout
So, are these changes included in the new style manual that comes in the
mkgmap installation package?

Also, a small note about terminology. This issue pops up now and again and
it's not a big one but I feel I should point it out. When you refer to what
we in the U.S. call parentheses (singular parenthesis), you use the term
"brackets".  Correct me if I'm wrong, but don't most mathematicians use
parenthesis to describe this character? "(" or ")".

The term bracket usually implies either this "[" or this "]", while braces
(or less often "curly brackets"), refer to "{" or "}"

I know certain programming languages, C and Pascal among them, use the
parentheses, brackets and braces terminology outlined above.

Cheers,
Dave

On Sun, Oct 16, 2016 at 10:05 PM, svn commit  wrote:

> Version mkgmap-r3696 was committed by steve on Sun, 16 Oct 2016
>
> Fix documentation error.
>
> - Carlos Dávila
>
>
> http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3696
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] site relations

2016-10-10 Thread Dave Swarthout
Awesome! That did the trick.

I will try that next for my multipolygon lakes.

Many thanks Andrzej

On Mon, Oct 10, 2016 at 9:22 PM, Andrzej Popowski 
wrote:

> Hi Dave,
>
> your rule looks good except you should use curly brackets.
> '${..}' means tag from relation while '$(..)' is a tag from member of
> relation. Try for example:
>
> type=site & name=* {
>  apply {add name='${name}';}
> }
>
> Or you can concatenate site name with building name, if exist:
>
> type=site & name=* {
>  apply_once { set name='$(name) - ${name}' | '${name}'; }
>
> }
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] site relations

2016-10-10 Thread Dave Swarthout
Thanks, Andrzej,

I don't understand what you're saying. You're telling me to transfer the
name tag from my site relation to the objects it contains. But how do I
tell from within mkgmap what the objects are?

I added this line to my relation style file but nothing happened. The
members of this relation are buildings. How to apply the name to them?
Should I add some rules to the polygons style file?

type=site & name=* {
 apply {set name='$(name)';  }
}

On Mon, Oct 10, 2016 at 5:43 PM, Andrzej Popowski 
wrote:

> Hi Dave,
>
> you can transfer tags from a relation to its objects. Look for "apply"
> rule in style-manual.pdf .
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] site relations

2016-10-09 Thread Dave Swarthout
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

2016-07-25 Thread Dave Swarthout
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

2016-07-07 Thread Dave Swarthout
 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

2016-04-14 Thread Dave Swarthout
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?

2016-03-21 Thread Dave Swarthout
Yes, AFAIK you would need multiple icons.

I have done something similar for LPG stations. In my TYP file there is an
icon for a standard fuel station. It's a miniature gas pump like the one
GArmin has built in. I have another icon that contains the characters LPG
(written vertically) to the left of a transparent section that is large
enough to allow the pump icon to be visible too. This allows me to use
various other custom fuel icons on my maps and merely overlay the LPG icon
when needed. If you still have my TYP file you can check out the appearance
of those icons yourself. I don't think it matters if you use track up or
north up but Gerd will know the answer to that one. I can't recall how my
display works as I almost never use track up.

In my points style I use the following rules:

amenity=fuel & fuel:lpg=yes [ 0x2f16 resolution 24 continue]  #0x2f16 sets
the letters LPG vertically but does not end processing
amenity=fuel [0x2f01 resolution 24]

To do a similar thing for turn arrows one would make separate icons (either
square or round) that are transparent and put an arrow into each corner, as
you suggested in your post; a left turn arrow, a right turn arrow, and
whatever other symbols you want to show.


Dave


On Mon, Mar 21, 2016 at 10:35 PM, greg crago  wrote:

> JOSM shows individual NO LEFT turn icons at the right side of each
> intersection, if it is set
>
> It seems to me I would have to make 4 separate TYP symbols and lock my GPS
> in NORTH-UP mode to keep orientation.
>
> I would also have to place a small NO LEFT turn symbol in each quadrant of
> each TYP symbol and only use the appropriate icon.
>
> I just do not know how to write the code. Has anyone done this?
>
> Greg
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Question about using different ROAD CLASS's andROAD SPEED's for one linetype.

2016-03-10 Thread Dave Swarthout
gt;>>
>>>>> Walter
>>>>>
>>>>>
>>>>> *From:* greg crago 
>>>>> *Sent:* Saturday, March 05, 2016 10:53 PM
>>>>> *To:* Development list for mkgmap 
>>>>> *Subject:* Re: [mkgmap-dev] Question about using different ROAD
>>>>> CLASS's andROAD SPEED's for one linetype.
>>>>>
>>>>> I have re-read your posts and I think I am still confused about your
>>>>> statement
>>>>>
>>>>> "you can also club together POIs with different Icons to the same
>>>>> POI-List entry"
>>>>>
>>>>> Again, what is a 'POI-list entry' and how is this a benefit?
>>>>>
>>>>> I understand about specific store BRANDS and using unique POINTS and
>>>>> then use a GENERIC icon for the rest of the category.
>>>>>
>>>>> Greg
>>>>>
>>>>> On Sat, Mar 5, 2016 at 4:49 AM, Walter Schlögl <
>>>>> walter.schloegl-re...@aon.at> wrote:
>>>>>
>>>>>> Hi Greg,
>>>>>>
>>>>>> here an example for supermarkets
>>>>>>
>>>>>> shop=supermarket & (name~'Hofer.*'  | name~'HOFER.*'){ set
>>>>>> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
>>>>>> shop=supermarket & (name~'Aldi.*'   | name~'ALDI.*'){ set
>>>>>> mkgmap_symbol=yes}[0x3501 resolution 23 continue with_actions]
>>>>>> shop=supermarket & (name~'Lidl.*'   | name~'LIDL.*'){ set
>>>>>> mkgmap_symbol=yes}[0x3502 resolution 23 continue with_actions]
>>>>>> ...
>>>>>> shop=supermarket & mkgmap_symbol!=yes
>>>>>> [0x3500 resolution 23 continue with_actions]
>>>>>> shop=supermarket[0x2E02
>>>>>> resolution 21] # POI
>>>>>>
>>>>>> There is one common symbol on 3500 and dedicated symbols on 3501 and
>>>>>> above.
>>>>>> (Hofer and Aldi is the same supermarket with the same Logo but with
>>>>>> different names in Austria and Germany)
>>>>>> If I find a dedicated name of the supermarket, I will show the
>>>>>> corresponding symbol. (at the moment about 30 in my list)
>>>>>> All other supermarkets will get the common symbol.
>>>>>> And all of them will get additionally an unvisible POI (well, not
>>>>>> totally unvisible but just 1 dot) for the POI-List
>>>>>> Since this 1 dot POI is placed at resolution 21, I can click on it
>>>>>> also in lower zoom levels.
>>>>>>
>>>>>> I’m doing the same with amenity=fuel (more than 20), shop=car and
>>>>>> many others.
>>>>>> My map has many dedicated symbols which makes it easier to find a POI
>>>>>> at one short look even without using the search function.
>>>>>>
>>>>>> Walter
>>>>>>
>>>>>>
>>>>>> *From:* greg crago 
>>>>>> *Sent:* Friday, March 04, 2016 11:37 PM
>>>>>> *To:* Development list for mkgmap 
>>>>>> *Subject:* Re: [mkgmap-dev] Question about using different ROAD
>>>>>> CLASS's andROAD SPEED's for one linetype.
>>>>>>
>>>>>> I am still confused.
>>>>>> Can you explain it one more time and use an example.
>>>>>>
>>>>>> Greg
>>>>>>
>>>>>> On Fri, Mar 4, 2016 at 11:13 AM, Bernd Weigelt 
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Greg
>>>>>>>
>>>>>>> No, this line catches only cuisine=french *or* cuisine=sea food, not
>>>>>>> 'cuisine=french;sea food;...' This key/value pair will be ignored
>>>>>>>
>>>>>>> ---
>>>>>>> cuisine~'.*;.*'
>>>>>>> {
>>>>>>> set cuisine='${cuisine|part:}';
>>>>>>> }
>>>>>>>
>>>>>>> This rule helps, to use the first part in the POIs, but all other
>>>>>>> will be
>>>>>>> ignored, too. Have it in my filter file.
>>>>>>>
>>>>>>> My example in my first answer is not really good, because the rule
>>>>>>> has to be
>>>>>>> executed in a loop until the last value, but i think MKGMAP didn't
>>>>>>> do this
>>>>>>>
>>>>>>> Bernd
>>>>>>>
>>>>>>> Am Freitag, 4. März 2016, 10:01:52 CET schrieb greg crago:
>>>>>>> > Bernd, Is this the same as (in the line file)
>>>>>>> >
>>>>>>> > amenity=restaurant & (cuisine=french | cuisine=sea food |
>>>>>>> cuisine=german |
>>>>>>> > cuisine=. ) [0x01150 resolution 24]
>>>>>>> >
>>>>>>> > Greg
>>>>>>>
>>>>>>>
>>>>>>> ___
>>>>>>> mkgmap-dev mailing list
>>>>>>> mkgmap-dev@lists.mkgmap.org.uk
>>>>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> ___
>>>>>> mkgmap-dev mailing list
>>>>>> mkgmap-dev@lists.mkgmap.org.uk
>>>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>>>
>>>>>> ___
>>>>>> mkgmap-dev mailing list
>>>>>> mkgmap-dev@lists.mkgmap.org.uk
>>>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>>>
>>>>>
>>>>> --
>>>>> ___
>>>>> mkgmap-dev mailing list
>>>>> mkgmap-dev@lists.mkgmap.org.uk
>>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>>
>>>>> ___
>>>>> mkgmap-dev mailing list
>>>>> mkgmap-dev@lists.mkgmap.org.uk
>>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>>
>>>>
>>>> --
>>>> ___
>>>> mkgmap-dev mailing list
>>>> mkgmap-dev@lists.mkgmap.org.uk
>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>
>>>> ___
>>>> mkgmap-dev mailing list
>>>> mkgmap-dev@lists.mkgmap.org.uk
>>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>>
>>>
>>>
>>
>>
>
>
> --
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Should we have a ADVANCED_DEFAULT Style?

2016-03-07 Thread Dave Swarthout
I doubt people want to keep their styles secret but I could be mistaken. It
is more likely that my styles and POI icons, or someone elses, are not ones
you would particularly care about. For example, I have special POIs for
milestones (common in Thailand), and assorted trees (trees common in
Thailand) and style rules that test for them and place them on my maps. In
addition, everything I'm developing is in a continual state of flux — I'm
changing rules and icons all the time as my ideas about what's important
(or fun) to map change.

Would my styles and TYP file be of any interest to you?

If so, merely say the word and I'll post them in my Dropbox and send you
the links.

Best
Dave

On Tue, Mar 8, 2016 at 9:13 AM, greg crago  wrote:

> I see many good questions about advanced mapping techniques and I am
> trying to incorporate these ideas into my maps.
>
> I was wondering if we could combine these ideas into a ADVANCED_DEFAULT
> style?
>
> I do not know if everyone wants to keep their own mapping styles secret,
> but I have added to the default_style and do not mind sharing my own
> additions.
>
> That way new mappers can analyze this code and get up to speed faster and
> maybe be able to add more ideas to the community.
>
> If you do not like a feature, you can always remove that piece of code.
>
> My goal is to try to use mkgmap to map maps that look like Garmin City
> Navigator.
>
> So far I have added custom POI symbols for brand specific businesses
> (fuel, fast food, resturants)
>
> Added 1 way arrows
> Added Bridges over ways
> Added Bicycle lanes.
>
> Greg
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Oneway arrows

2016-03-07 Thread Dave Swarthout
@nwillink

Now that's a clever solution. Many thanks. I'll start working on it.

@Andrzej : I did not try to see if the oneways that failed to show in
Basecamp were visible on my Montana. Thanks for the tip.

I think we can put this thread to rest now.

Again, thanks to all for your help.

On Tue, Mar 8, 2016 at 7:56 AM, Andrzej Popowski 
wrote:

> Hi,
>
> it is worth noting, that on newer nuvis oneway arrows are displayed by
> default. They are present on ways with no TYP graphics, and possibly on
> non-bitmap graphics too, but I'm not sure about later.
>
> Other peculiarity of non-bitmap graphics is that way's width is scalable
> on nuvis, depending on zoom.
>
> --
> Best regards,
> Andrzej
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Oneway arrows

2016-03-06 Thread Dave Swarthout
Well, that seems to explain why my attempts aren't working. It also
explains why the default style uses arrows that lie outside the highway
lines. Garmin is overwriting the "arrow highway" line but the part it
overwrites is the invisible part.

Knowing Garmin overwrites bitmaps with those low-numbered ways means I
would have to bump all highway codes up a notch and reassign them to get
the effect I want. And that may produce unseen repercussions later. Or,
alternatively, I could go with Wesley's or Greg's approach. I'll need to
think about that for a while.

As always, thanks for your help everyone.

Cheers,
Dave

On Sun, Mar 6, 2016 at 10:34 PM, greg crago  wrote:

> I like Wesley's ARROWS built in to the ROAD, but my ARROWS are 16 pixels
> wide and sit UNDER the road and you see them protrude outside the edge of
> the road. (see picture)
>
> Here is my TYP file (look for 0x26)
>
> and my other post has my code for SECONDARY roads in my line file.
>
> I would like to get arrows built in to the road, mine looks bad, but does
> convey the 1-way direction.
>
> It seems many of us are all working on similar features and it would be
> nice if we all got together and made a SUPER-DEAFULT STYLE, where we could
> combine all of these advanced features and if mappers do not wish to use
> them, they can just DELETE those sections.
>
> I also wanted BRIDGES to be ON TOP, so I moved MOTORWAY linetype to 0x0b
> and defined BRIDGES to be 0x01 and it works. Pinns suggested this on his
> website, no roads cross 0x01 linetype.
>
> Greg
>
> On Sun, Mar 6, 2016 at 7:48 AM, Minko  wrote:
>
>> I dont know how Gregs typ file looks like. It depends how you have
>> configured your type of highway, either a bitmap or vector image.
>> Bitmap (arrow) on top of a vector image will not work in most cases,
>> unless that bitmap is one of the major line types as in the following
>> example:
>>
>> Bitmap:
>>
>> [_line]
>> Type=0x02
>> UseOrientation=N
>> Xpm="32 3 2  1"
>> "! c #0030FF"
>> "  c none"
>> "    "
>> "    "
>> "    "
>> ;12345678901234567890123456789012
>> String1=0x04,cycle route
>> String2=0x03,fietsroute
>> String3=0x02,Radroute
>> ExtendedLabels=Y
>> FontStyle=SmallFont
>> CustomColor=No
>> [end]
>>
>> Vector:
>>
>> [_line]
>> Type=0x03
>> UseOrientation=N
>> LineWidth=5
>> BorderWidth=1
>> Xpm="0 0 2 0"
>> "1 c #B4B4B4"
>> "2 c #525252"
>> String1=0x04,principal highway
>> String2=0x03,N-weg
>> String3=0x02,Hauptverbindungsstraße
>> ExtendedLabels=Y
>> FontStyle=SmallFont
>> CustomColor=No
>> [end]
>>
>> --
>>
>> Dave wrote:
>>
>> @Minko - But Greg says he gets the results I want with the rules he's
>> using. So how to explain that?
>>
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Oneway arrows

2016-03-06 Thread Dave Swarthout
@Minko - But Greg says he gets the results I want with the rules he's
using. So how to explain that?

On Sun, Mar 6, 2016 at 3:41 PM, Minko  wrote:

> The problem is that most Garmins don't display a bitmap on top of a vector
> line (esp. the major highway types like 0x01, 0x02 etc will be put on top
> of other lines). So you have to place the arrow on one side of the
> underlying highway, instead of in the center. See the typ file of the new
> generic map. This example will not work in some units though, it could be
> that your Garmin still makes a mess out of it :-(
>
>
> [_line]
> Type=0x1
> UseOrientation=N
> Xpm="32 15 2  1"
> "! c #0065FF"
> "  c none"
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> ""
> " !  "
> " !! "
> " !  "
> ;12345678901234567890123456789012
> String1=0x04,oneway
> String2=0x03,eenrichtingsverkeer
> ExtendedLabels=Y
> FontStyle=NoLabel (invisible)
> CustomColor=No
> [end]
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Oneway arrows

2016-03-05 Thread Dave Swarthout
@Greg - Thanks, I'm working on it but still no luck. I reproduced your code
for primary highways, used the continue statement as you did, removed my
old arrow rules, made sure my new "arrow way" (also used 0x26 for a code)
has a transparent background but I still can't get it to work.

@Wesley - Thank you as well. Your approach is interesting and I like it but
it seems to me I should be able to accomplish making those arrows overlay
my highways by using the proper rules in the same img file.

On Sun, Mar 6, 2016 at 5:01 AM, greg crago  wrote:

> Dave, I have done the same thing with 1 way arrows (linetype 0x26 for me)
>
> I have only done this for SECONDARY, TERTIARY, RESIDENTIAL, and SERVICE
> roads. Here is my 'line' code for SECONDARY roads:
>
> highway=secondary & ( network=e-road | int_ref=* ) [0x04 resolution 19-19
> continue]
> highway=secondary & oneway=yes [0x26 resolution 19 continue]
> highway=secondary & cycleway=lane [0x00 resolution 19 continue]
> highway=secondary & bridge!=yes [0x04 road_class=2 road_speed=3 resolution
> 19 continue]
> highway=secondary & bridge=yes [0x01 road_class=2 road_speed=3 resolution
> 22]
> highway=secondary_link & bridge!=yes [0x08 road_class=2 road_speed=1
> resolution 19 continue]
> highway=secondary_link & bridge!=yes [0x23 resolution 19 continue]
> highway=secondary_link & oneway=yes [0x26 resolution 19 continue]
> highway=secondary_link & cycleway=lane [0x00 resolution 19 continue]
> highway=secondary_link & bridge=yes [0x01 road_class=2 road_speed=1
> resolution 22]
>
> I do this for both the road and the *_link, This is 'mid-way' in my code.
> You can see I also have overlay for BICYCLE lanes and BRIDGES
> It works and looks great.
>
> Greg
>
> On Sat, Mar 5, 2016 at 1:28 AM, Dave Swarthout 
> wrote:
>
>> I would like to see oneway arrows drawn on top of the highway lines the
>> way OSMAnd does it. I tried moving my oneway arrow rules to after the other
>> highway rules were finished processing but they completely disappeared. The
>> lines style rules are below and in my TYP file are defined as blue arrows
>> on a transparent background.
>>
>>
>> # display direction arrows on highways
>> highway=* & (oneway=yes | oneway=1 | oneway=true) [0x1 resolution 24
>> continue with_actions]
>> highway=* &  oneway=-1 [0x10001 resolution 24 continue with_actions]
>>
>> Thanks,
>> Dave
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Oneway arrows

2016-03-04 Thread Dave Swarthout
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

2016-02-29 Thread Dave Swarthout
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?

2016-02-28 Thread Dave Swarthout
Greg,

Using JOSM and working with data that other people are also working with is
a recipe for disaster. Resolving the inevitable conflicts that will arise
is tedious and complicated. I have spent hours resolving conflicts made by
"the other user" only to find out later that it was _my own data_ I was
working against. The method you're trying to use will only work well if
you're the only person modifying the data in that particular part of the
world.

Another possibility is to download smaller areas to work in which will keep
the number of edits down. That way you won't have thousands of conflicts
when you do get Internet again. And if you do, you won't lose much work.

Not very satisfying I'm afraid but working with a live Internet connection
is by far the best option.

On Sun, Feb 28, 2016 at 9:42 PM, greg crago  wrote:

> I have thousands of map errors I have collected on my GPS from ground
> observations. I just have not had time to upload them to OSM. I do not have
> Internet access all the time.
>
> Downloading many states and then breaking them up using a 'splitter-type'
> program, gives me the flexibility to edit sections of the country I want to.
>
> I thought UPLOAD conflicts only occur when objects I HAVE MODIFIED,
> conflict with objects in the OSM database that have been modified since I
> download MY VERSION. If I have large areas of 'outdated' OSM data, that I
> do not modify, I should not have any problems when I upload, since I am not
> sending that 'untouched' data back to OSM, correct?
>
> I thought this was a viable 'offline' solution. I do not know how to
> filter overpass to download state-by-state regions. GEOFABRIK has already
> done this, if SPLITTER kept the version dataset information., I could use
> it.
>
> Greg
>
> On Sat, Feb 27, 2016 at 4:08 PM, Nelson A. de Oliveira 
> wrote:
>
>> On Sat, Feb 27, 2016 at 5:44 PM, greg crago  wrote:
>> > I want to download sections of the osm database (USA- Michigan) and
>> make off
>> > line changes in JOSM and upload back to OSM when I am back online.
>>
>> Will you edit the whole state?
>> Do you really need to have all of it?
>>
>> Editing large areas and a lot of objects isn't usually the best thing
>> to do: it can cause duplicate data in OSM and/or you will hit a lot of
>> conflicts.
>>
>> overpass is the easiest way to get fresh data, but you need to filter
>> a smaller region or some specific data that you want.
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Anyone determine which linetypes are NOT visable in BaseCamp?

2016-02-27 Thread Dave Swarthout
Huh? I can define the width of a way, its color, whether it is dashed or
solid in my TYP file. Are you saying I don't need a TYP file to make a
dashed, brown line of width 5 pixels with hex code 0x1007 that is then
assigned via a style rule to an OSM way?

If I do not then I agree; I don't  understand anything about TYP files.

Can you explain in a little more detail what you are trying to tell me?


On Sat, Feb 27, 2016 at 4:45 PM, Minko  wrote:

> See also http://www.openfietsmap.nl/tips-tricks/customize
>
> --
>
> Hi Dave,
>
>
> it seems you don't understand the meaning of TYP file.
>
> It is used to define how POI / lines /  areas are displayed (in Basecamp
> and the device).
>
> Such a file is not part of the mkgmap distribution, don't know why, maybe
> the reason
>
> is that some devices don't support TYP files, maybe it's because
> programmers aren't
>
> much interested in it ;-)
>
> You can find samples in other wellknown styles, e.g. here:
>
> https://github.com/ligfietser/mkgmap-style-sheets
>
> which contains the styles used for Minkos cycling maps:
>
> http://www.openfietsmap.nl/home
>
> I don't know if this page is up to date, but it may help as well:
>
> http://www.openfietsmap.nl/procedure
>
>
> Gerd
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Anyone determine which linetypes are NOT visable in BaseCamp?

2016-02-26 Thread Dave Swarthout
I am using line types 0x1 through 0x1001b for various lines and they
all display in BC and on my Montana. 0x1 and 0x10001 are the oneway
arrows that display alongside ways that are oneway. Of course, I have the
styles defined in my lines file and the hexadecimal codes are in a custom
TYP file.

Hope this helps.

Dave

On Fri, Feb 26, 2016 at 5:16 AM, greg crago  wrote:

> Thank you, that worked well.
>
> In BaseCamp v4.6.1 linetype 0x17,0x2c,0x30-0x3f are NOT VISIBLE.
>
> Attached is a map that I changed all COLORS for lines and polygons to RED,
> except for the background container 0x4b is white. This map is located NE
> of London
>
> The Garmin Montana 600 can see linetypes 0x00-0x3f and polygons 0x01-0x7f
>
> Has anyone got EXTENDED linetype to be visible in BaseCamp? I used
> 0x10001-0x10005 but they show up as thin lines only (no thickness)
>
> Greg
>
> On Thu, Feb 25, 2016 at 10:09 AM, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Greg,
>>
>>
>> try this command:
>>
>> java -jar mkgmap.jar test-map:all-elements
>>
>>
>> to generate a map containing all possible types for lines and poi.
>>
>>
>> Gerd
>>
>>
>> --
>> *Von:* mkgmap-dev-boun...@lists.mkgmap.org.uk <
>> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von greg crago <
>> gregcr...@gmail.com>
>> *Gesendet:* Donnerstag, 25. Februar 2016 15:57
>> *An:* Development list for mkgmap
>> *Betreff:* Re: [mkgmap-dev] Anyone determine which linetypes are NOT
>> visable in BaseCamp?
>>
>> I realize that not all linetypes are visible in all GPS units.
>>
>> Since map development is easiest when I can see my results quickly, using
>> BaseCamp is a great tool to see my results without having to download .img
>> files to my GPS every 10 minutes.
>>
>> Do any of you 'mappers' have a TEST MAP file containing ALL POSSIBLE
>> LINETYPES so I can use it and view in BaseCamp, or any GPS device to
>> determine a USEFUL SET of visible LINETYPES. I think this would be a good
>> to for mappers to have, otherwise, every time you want to add a new
>> linetype, you have to see if it is visible in BaseCamp (or whatever
>> software you are using) AND you need to verify that linetype is also
>> visible in  your GPS unit.
>>
>> I realize this 'test area' would have to exists in 1 location in the
>> world, but you could make in the the ocean somewhere and just give
>> coordinates so other mappers can find it.
>>
>> Has anyone else determined additional non visible linetypes in BaseCamp
>> besides 0x17,0x31,0x32 and 0x34?
>>
>> Greg
>>
>> On Thu, Feb 25, 2016 at 8:48 AM, Andrzej Popowski 
>> wrote:
>>
>>> Hi Greg,
>>>
>>> there is no consistency in a way Garmin's devices display different
>>> objects. Even if you see something in BaseCamp it doesn't mean that this
>>> object will be visible on nuvi or outdoor device.
>>>
>>> There are some informations for meaning of objects (poi, lines, areas),
>>> which you can find on some web pages, for example:
>>> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/POI_Types
>>> http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Polyline_Types
>>> http://wiki.openstreetmap.org/wiki/Editing_OSM_Map_On_Garmin/Area_Types
>>>
>>> As a general rule I suggest to follow description in cGPSmapper manual:
>>> http://cgpsmapper.com/manual.htm
>>>
>>> Usually maps contain a TYP file, which define graphics for objects. This
>>> somehow unify map view for different devices. I think TYP allows for
>>> viewing some objects, that otherwise would be invisible.
>>>
>>> --
>>> Best regards,
>>> Andrzej
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>>
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Option "link pois to ways"

2016-02-21 Thread Dave Swarthout
So, the number of traffic_signals encountered on one route vs another route
isn't even a factor in mkgmp routing? I have been adding traffic_signals to
my workload for the past year in hopes it would improve routing accuracy.

How then does routing get calculated? On my Garmin there is a choice for
"fastest" vs. "shortest" routes. Usually this choice doesn't make much
difference in the overall time involved for a traverse along a route and I
always assumed  it was because here in Thailand so few of our highways have
maxspeed tags. How are these two routing choices handled by makgmap?

Sorry for the extra questions but I am curious to know these things.

Cheers,
Dave

On Mon, Feb 22, 2016 at 12:23 AM, Jakob Mühldorfer 
wrote:

> Oh, allright.
> Maybe if you have time some day, you could look into it again. I think
> there are some use cases.
> One example where the OSRM traffic light penalty for example seems to have
> chosen the clever way around the traffic light:
>
> https://www.openstreetmap.org/directions?engine=osrm_car&route=51.05581%2C13.72190%3B51.05522%2C13.71881#map=19/51.05541/13.72034
>
> Regards
> Jakob
>
>
> Am 21.02.2016 um 18:19 schrieb Gerd Petermann:
>
>> Hi Jakob,
>>
>> I think this cannot be done with rules, it requires new java code.
>> I thought about this a while ago and stoped because I doubted that this
>> would improve routing.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev-boun...@lists.mkgmap.org.uk <
>> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Jakob Mühldorfer <
>> m...@jmuehldorfer.de>
>> Gesendet: Sonntag, 21. Februar 2016 17:59
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Option "link pois to ways"
>>
>> Hi Gerd,
>>
>> this would be the best solution I think.
>> So far I found a rule that lowers the speed for the complete road with
>> the traffic light, do you have one that splits it and adds a lower speed
>> only on a part, like you said?
>>
>> Thanks
>> Jakob
>>
>> Am 21.02.2016 um 17:57 schrieb Gerd Petermann:
>>
>>> Hi Jakob,
>>>
>>> the current code ignores nodes with highway=traffic_signals.
>>> If I got you right you want to split a road maybe 30 m before the node
>>> with
>>> highway=traffic_signals and 30 after and set a lower road-speed value
>>> for that 60m part?
>>>
>>> Gerd
>>>
>>>
>>>
>>> 
>>> Von: mkgmap-dev-boun...@lists.mkgmap.org.uk <
>>> mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Jakob Mühldorfer
>>> 
>>> Gesendet: Sonntag, 21. Februar 2016 17:31
>>> An: Development list for mkgmap
>>> Betreff: [mkgmap-dev] Option "link pois to ways"
>>>
>>> Hi,
>>>
>>> one more question I was not able to figure out from documentation or
>>> source.
>>> When the option "link pois to ways" is used, does it automatically
>>> process traffic signals in a way that adds a time penalty for routing
>>> through them in the map data.
>>>
>>> Thanks for help on that
>>> Jakob
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Key "motorcar"

2016-02-21 Thread Dave Swarthout
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"

2016-02-20 Thread Dave Swarthout
Since this topic has been raised I checked my style files and can find many
uses of the word "motorcar" in various access rules. But that brings up the
question of how the term "motor_vehicle" relates to it.

I had assumed the definition of motor_vehicle would include all powered
vehicles: cars, trucks, hgv, motorcycles, etc.
while motorcar refers to only passenger cars. But that isn't clear in the
"access" style file.

I ask because I am confused by line 29, where it seems my assumption is
reversed because the value for motor_vehicle is being transferred to the
motorcar tag :

Line 29: motor_vehicle=*  { add motorcar='${motor_vehicle}'; add
goods='${motor_vehicle}'; add hgv='${motor_vehicle}'; add
psv='${motor_vehicle}'; add emergency='${motor_vehicle}'; }

And also this comment:

Line 46: # Therefore we have to choose one vehicle type - and the winner
is: motorcar

After which access is set for a range of situations all involving the term
"motorcar"

Can someone take a few minutes to explain these rules?

Thanks in advance,

Dave

On Sun, Feb 21, 2016 at 6:52 AM, Jakob Mühldorfer 
wrote:

> Found out rules are in place.
> I will examine the case and report back, if it indeed routes over this one
> track with motorcar=no
>
>
> Am 20.02.2016 um 21:45 schrieb Jakob Mühldorfer:
>
>> Hi,
>>
>> question: what is happening with a "motorcar=*" key at the moment?
>> My Garmin wanted to send me over a track with "motorcar=no", is that the
>> Garmin's fault or the mapdata's fault?
>>
>> Thanks
>> Jakob
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r3668: improce access rules:

2016-02-19 Thread Dave Swarthout
Thanks for the clarification. I have already updated my styles.

On Fri, Feb 19, 2016 at 7:51 PM, Steve Ratcliffe 
wrote:

> Hi Gerd
>
> @Steve Maybe you can add such a (generated) link to the svn repo to the
>> notification mail ?
>>
>
> That's a good idea, I shall do that.
>
> ..Steve
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit: r3668: improce access rules:

2016-02-19 Thread Dave Swarthout
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  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

2016-02-06 Thread Dave Swarthout
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 
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

[mkgmap-dev] Order of objects rendered

2016-01-27 Thread Dave Swarthout
I saw a note on the tagging list just now that reflects on something I've
been curious about for some time. If mkgmap comes upon an object that has
two tags, both of which are valid, which one will mkgmap use? Here is the
post:

One of the rules we use is the "one feature, one OSM element” [1]
This makes sense for a lot of elements, e.g. if something has the tag:
higway=residential it would be silly to also have amenity=restaurant on the
same element.
But it is not very uncommon to have a memorial that was created as a piece
of art by an artist. One could tag such an object with:

tourism=artwork
historic=memorial

and of course add other relevant stuff like artist_name etc.

But what should be rendered in such a case? The memorial or the artwork?

>From my understanding, once a node or way with a valid code has been
encountered during style processing, mkgmap considers it finished and moves
to the next item. But let's say I prefer to see the historic=memoriaI tag
rendered and don't care about artwork, is there a way to prioritize the
assignment of icons to one of those tags?

Cheers,
Dave

-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
This
email has been sent from a virus-free computer protected by Avast.
www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
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

2015-12-12 Thread Dave Swarthout
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&utm_source=link&utm_campaign=sig-email&utm_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&utm_source=link&utm_campaign=sig-email&utm_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?

2015-09-08 Thread Dave Swarthout
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 
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

2015-08-25 Thread Dave Swarthout
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 
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

2015-08-24 Thread Dave Swarthout
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

2015-06-05 Thread Dave Swarthout
"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  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

2015-05-21 Thread Dave Swarthout
>
> 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
>
>
>
>
> --
> 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
>



-- 
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] Named bridges not displaying

2015-05-20 Thread Dave Swarthout
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

2015-05-19 Thread Dave Swarthout
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 
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] question reg. exits

2015-05-19 Thread Dave Swarthout
That's very interesting. I didn't know about the exit:to tag and apparently
nobody else does either because taginfo shows zero occurrences of it.

Taginfo also shows 381 uses of exit_to:left and 334 uses of exit_to:right
so perhaps that's something to look at also.

On Tue, May 19, 2015 at 1:43 AM, Thorsten Kukuk  wrote:

>
> Hi,
>
> On Tue, May 19, Gerd Petermann wrote:
>
> > Hi all,
> >
> > I just noticed that mkgmap treats POI with
> >  0x2000 <= type < 0x2800
> > special.
> > It looks for the tags
> > exit:to=*  and exit:facility=* to add extra information to
> > the POI.
> > This info is shown when you click on an exit in Basecamp,
> > it shows the fields Name, Description, and Overnight Parking.
> >
> > The source was added with r984 in 2009 and it seems nobody noticed that
> > these tags don't exist in OSM anymore (or maybe they were typos)?
> >
> > Or maybe that were meant to be set in the style?
>
> http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2009q1/001287.html
>
> exit:facility needs to be set by the style, exit:to looks like
> a proposed OSM tag never introduced.
> But I admit that I don't really understand the examples in that mail...
>
>   Thorsten
>
> --
> Thorsten Kukuk, Senior Architect SLES & Common Code Base
> SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany
> GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB
> 21284 (AG Nürnberg)
> ___
> 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 handling of exits

2015-05-19 Thread Dave Swarthout
Okay, just now I added the echotags directive to my points style file:

exit_to=* {name 'Exit ${ref} ${exit_to}' | '${exit_to}' ; echotags ""}
 #[0x12615 resolution 24]

Here is a portion of the exit_to tag output to stderr. There are many more
of them but this section is typical

39682119 - [highway=motorway_junction,ref=7A,exit:road_ref=OR
569,mkgmap:label:1=Exit 7A Prairie
Road,mkgmap:osmid=39682119,exit_to=Prairie Road]
272994915 - [highway=motorway_junction,ref=10,exit:road_ref=OR
569,mkgmap:label:1=Exit 10 Delta Hwy.; Valley River Cnt.;
Downtown,mkgmap:osmid=272994915,exit_to=Delta Hwy.; Valley River Cnt.;
Downtown]
272994818 - [highway=motorway_junction,ref=10B,exit:road_ref=OR
569,mkgmap:label:1=Exit 10B Delta Hwy. N.; Ayers
Rd.,mkgmap:osmid=272994818,exit_to=Delta Hwy. N.; Ayers Rd.]

On Tue, May 19, 2015 at 7:08 AM, Dave Swarthout 
wrote:

>
> On Mon, May 18, 2015 at 7:51 AM, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> 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
>



-- 
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

2015-05-19 Thread Dave Swarthout
On Mon, May 18, 2015 at 7:51 AM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> 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@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] FW: Routing parameters

2015-05-17 Thread Dave Swarthout
Yes, that explains how the Garmin can display a destination even if an
exit_to tag does not exist. I also understand better now, after your
clarifications, how the destination code works with the mkgmap hinting
variables.

I'm still having trouble getting the echotags command to work, even with
your package. It's complicated to explain because I'm trying to keep your
code separate from my stuff but I will keep trying. In the meantime, I
solved the problem another way. I merely created two style rules to process
exit_to and destination tags so they display on my maps. Now, when I drive
past exits the tagging data, if present, will display. In addition I can
easily tell from my desktop in Basecamp whether the exit_to tag has been
added on that particular node and if not, I can add it myself.

destination=* {name 'Dest: ${destination}' }   #lines style file

exit_to=* {name 'Exit ${ref} ${exit_to}' | '${exit_to}' }  [0x12615
resolution 24]  #points style file - uses an icon I created

I don't think these two rules will affect the processing of the following
rules that we've been discussing because those check highway=*_link tags.
At any rate, I have what I need for now.

I'll let you know about my trials with the echotags command later.

Thanks very much,

Dave

PS: Thanks for including that Java code snippet. I can understand why
placing an exit_to tag on highways other than trunk or motorway will never
show up. The code only processes links for motorways and trunks. Just in
passing let me say it would be helpful if primary highways were included
there as many of those have exits similar to motorways. But that's a topic
for another day.


On Sun, May 17, 2015 at 8:24 AM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi all,
>
> okay, I have now analysed a few situations and I think
> one problem with the documentation of the --process-exits
> and --process-destination option is that it doesn't clearly explain
> what problem you have when you don't use the option.
>
> My understanding now is  this:
> When Garmin calculates a  route and it finds
> a *_link way with type 0x08 or 0x09
> on that route it looks for the name
> of the next road which is not a link. This name is used for the
> "exit to ..." messsage.
> When you want to see / here the information in the destination=* tag
> or the exit_to=* tag mkgmap has to create a way that is not a link
> and that has the wanted name.
> The options --process-exits and process-destination prepare this
> by splitting the link way and creating a short way tagged  with as much
> info as available
> while the style rules are used to calculate the name.
>
> I see a few problems regarding the algo, esp. when a motorway
> splits into two motorway_link roads. The current algo seems to
> add the exit_to tag to both links, see e.g. node 97002577.
> I guess it should ignore the exit_to tag in this case?
>
> The current source also ignores the tags exit_to:left / exit_to:right.
> These tags are not often used, so I think this problem is small.
>
> Does all that make sense?
>
> Gerd
>
> --
> From: daveswarth...@gmail.com
> Date: Sat, 16 May 2015 15:43:20 -0700
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: Re: [mkgmap-dev] FW: Routing parameters
>
>
> Also, not to be a pest, but does anyone know how the exit_to tag is
> processed?
>
> On Sat, May 16, 2015 at 2:18 PM, Dave Swarthout 
> wrote:
>
> Thanks for the help but the echotags directive does not work for me the
> way you have it. I've tried everything I can think of to make it go. Spaces
> before and after, semicolon or no semicolon, braces or no braces  - I get
> nothing in my stderr file.
>
> I tried to use echotags in a simplified rule just to make sure I was
> writing the output to the correct file. It appears to be a very fussy
> command...
>
> this works
>
> (highway=motorway_link | highway=trunk_link) { echotags "motorway or
> trunk link seen" }
>
> but this does not
>
> (highway=motorway_link | highway=trunk_link) { echotags }
>
> nor does this
>
> (highway=motorway_link | highway=trunk_link) {echotags}
>
> According to the style manual, all those statements should produce output.
> However, the style manual isn't very informative unfortunately.
>
> Your suggestion
>
> (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|sub

Re: [mkgmap-dev] FW: Routing parameters

2015-05-16 Thread Dave Swarthout
Also, not to be a pest, but does anyone know how the exit_to tag is
processed?

On Sat, May 16, 2015 at 2:18 PM, Dave Swarthout 
wrote:

> Thanks for the help but the echotags directive does not work for me the
> way you have it. I've tried everything I can think of to make it go. Spaces
> before and after, semicolon or no semicolon, braces or no braces  - I get
> nothing in my stderr file.
>
> I tried to use echotags in a simplified rule just to make sure I was
> writing the output to the correct file. It appears to be a very fussy
> command...
>
> this works
>
> (highway=motorway_link | highway=trunk_link) { echotags "motorway or
> trunk link seen" }
>
> but this does not
>
> (highway=motorway_link | highway=trunk_link) { echotags }
>
> nor does this
>
> (highway=motorway_link | highway=trunk_link) {echotags}
>
> According to the style manual, all those statements should produce output.
> However, the style manual isn't very informative unfortunately.
>
> Your suggestion
>
> (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"
>}
>
> produced nothing at all. I know there must be a way to debug these blasted
> rules but the echotags and echo command don't seem to work all that well.
>
> On Sat, May 16, 2015 at 12:22 PM, GerdP 
> wrote:
>
>> Hi Dave,
>>
>> well, I am not an expert for the styles nor did I write the java code
>> in LinkDestinationHook.java, but I try again:
>>
>> The action block of the rule starts with name, so what it does is to set
>> the
>> mkgmap:label:1 tag. This is explained in the style manual.
>> The contents of the tags like mkgmap:exit_hint_ref depends on the OSM data
>> and what the java code in LinkDestinationHook.java does.
>> If you want to find out what values are passed to the rule and
>> what the action block changes, use the echotags action:
>> (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"
>>}
>>
>> BTW: You posted a rule which doesn't appear in the default style,
>> the phrase "highway=road" looks wrong there.
>>
>> Ciao,
>> Gerd
>>
>>
>> Dave Swarthout wrote
>> > @Gerd,
>> >
>> > There is no problem and your brief explanation helped. Everything is
>> > working fine but I wanted to understand the logic of the rule better.
>> But
>> > because I don't have any way to experiment with running different
>> strings
>> > through those filters I'm having trouble visualizing what they are
>> doing.
>> > In the style manual some examples of the subst filter in action are
>> shown
>> > for illustrative purposes:
>> >
>> > Example, if name ="Queen Street"
>> > ${name|subst:"Queen=>"} returns " Street"
>> > ${name|subst:"Queen=>King"} returns "King Street"
>> > ${name|subst:".*\s~>"} returns "Street"
>> >
>> > I was wanting some similar explanation for how that long rule works.
>> > Something like this:
>> >
>> > If the following tag exists on a way, destination:ref=US 20;Rochester
>> > the results will be
>> 

Re: [mkgmap-dev] FW: Routing parameters

2015-05-16 Thread Dave Swarthout
Thanks for the help but the echotags directive does not work for me the way
you have it. I've tried everything I can think of to make it go. Spaces
before and after, semicolon or no semicolon, braces or no braces  - I get
nothing in my stderr file.

I tried to use echotags in a simplified rule just to make sure I was
writing the output to the correct file. It appears to be a very fussy
command...

this works

(highway=motorway_link | highway=trunk_link) { echotags "motorway or
trunk link seen" }

but this does not

(highway=motorway_link | highway=trunk_link) { echotags }

nor does this

(highway=motorway_link | highway=trunk_link) {echotags}

According to the style manual, all those statements should produce output.
However, the style manual isn't very informative unfortunately.

Your suggestion

(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"
   }

produced nothing at all. I know there must be a way to debug these blasted
rules but the echotags and echo command don't seem to work all that well.

On Sat, May 16, 2015 at 12:22 PM, GerdP 
wrote:

> Hi Dave,
>
> well, I am not an expert for the styles nor did I write the java code
> in LinkDestinationHook.java, but I try again:
>
> The action block of the rule starts with name, so what it does is to set
> the
> mkgmap:label:1 tag. This is explained in the style manual.
> The contents of the tags like mkgmap:exit_hint_ref depends on the OSM data
> and what the java code in LinkDestinationHook.java does.
> If you want to find out what values are passed to the rule and
> what the action block changes, use the echotags action:
> (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"
>}
>
> BTW: You posted a rule which doesn't appear in the default style,
> the phrase "highway=road" looks wrong there.
>
> Ciao,
> Gerd
>
>
> Dave Swarthout wrote
> > @Gerd,
> >
> > There is no problem and your brief explanation helped. Everything is
> > working fine but I wanted to understand the logic of the rule better. But
> > because I don't have any way to experiment with running different strings
> > through those filters I'm having trouble visualizing what they are doing.
> > In the style manual some examples of the subst filter in action are shown
> > for illustrative purposes:
> >
> > Example, if name ="Queen Street"
> > ${name|subst:"Queen=>"} returns " Street"
> > ${name|subst:"Queen=>King"} returns "King Street"
> > ${name|subst:".*\s~>"} returns "Street"
> >
> > I was wanting some similar explanation for how that long rule works.
> > Something like this:
> >
> > If the following tag exists on a way, destination:ref=US 20;Rochester
> > the results will be
> > 
> >
> > I was not seeing what this part of that single long rule was doing until
> > you mentioned cleaning up blanks and semicolons:
> >
> > name '${destination:ref|subst: =>} ${destination|subst:;=> |subst:/=> }'
> >
> > To me it appeared to be setting the name of the way to blank or null if
> it
> > encounters the tag destination:ref but now I understand it is eliminating
> > blanks and other punctuation because I noticed the blank character
> > following the colon in the subst command. So that means the second 

Re: [mkgmap-dev] FW: Routing parameters

2015-05-16 Thread Dave Swarthout
@Gerd,

There is no problem and your brief explanation helped. Everything is
working fine but I wanted to understand the logic of the rule better. But
because I don't have any way to experiment with running different strings
through those filters I'm having trouble visualizing what they are doing.
In the style manual some examples of the subst filter in action are shown
for illustrative purposes:

Example, if name ="Queen Street"
${name|subst:"Queen=>"} returns " Street"
${name|subst:"Queen=>King"} returns "King Street"
${name|subst:".*\s~>"} returns "Street"

I was wanting some similar explanation for how that long rule works.
Something like this:

If the following tag exists on a way, destination:ref=US 20;Rochester
the results will be


I was not seeing what this part of that single long rule was doing until
you mentioned cleaning up blanks and semicolons:

name '${destination:ref|subst: =>} ${destination|subst:;=> |subst:/=> }'

To me it appeared to be setting the name of the way to blank or null if it
encounters the tag destination:ref but now I understand it is eliminating
blanks and other punctuation because I noticed the blank character
following the colon in the subst command. So that means the second part
removes semicolons. But why is it doing that? And what part gets passed to
the Garmin "assistant" who then voices the information as the exit on a
route is approached?

Continuing: After all the punctuation has been stripped from the
destination tag we move to the next part of the rule.

  '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}'

This seems to be setting a variable named "Exit" to whatever is contained
in the mkgmap internal variables. Is that what's happening? Where are those
variables defined and set? Where does the data come from?

Another big question is about the exit_to tag. Take this example of a
motorway junction node. No destination tag appears on the linking way
itself but my Garmin will speak the words properly as you approach Exit 10:

highway=motorway_junction
ref:Exit 10
exit_to:Greenville;South NC 40; US 421

I cannot find a rule that tells me how an exit_to tag is handled. Where
does that information get processed? And how does the "assistant" know what
words to speak?

In summary, those are the questions I'm trying to answer. Now that I'm
writing style rules of my own I want to better understand how they work.
It's a slow process, especially when the examples in the manual are so
simple. Perhaps a more complex, real world, example would help future
mappers.

Dave


On Sat, May 16, 2015 at 3:04 AM, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

>
>
> --
> From: gpetermann_muenc...@hotmail.com
> To: daveswarth...@gmail.com
> Subject: RE: [mkgmap-dev] Routing parameters
> Date: Sat, 16 May 2015 12:02:22 +0200
>
>
> Hi Dave,
>
> not sure what the problem is.
> The subst filters are just used to remove some blanks or semicolons.
> The rest is more or less "a list of alternative expressions separated with
> a vertical bar",
> you can search for that term in the style manual:
> http://www.mkgmap.org.uk/doc/pdf/style-manual.pdf
>
> I've never tried these options because I use my GPS only for cycling,
> but my understanding is that the types 0x08 and 0x09 are special
> as they instruct the Garmin device to use the name of the road for the
> destination hint, and these rules are used to fill this name with useful
> information.
>
> Does that help?
>
> Gerd
>
> --
> From: daveswarth...@gmail.com
> Date: Fri, 15 May 2015 17:51:13 -0700
> To: mkgmap-dev@lists.mkgmap.org.uk
> Subject: 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 
> 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.
>
&g

Re: [mkgmap-dev] Routing parameters

2015-05-15 Thread Dave Swarthout
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 
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

2015-05-15 Thread Dave Swarthout
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

Re: [mkgmap-dev] Testing for a literal question mark

2015-03-18 Thread Dave Swarthout
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 
> *Sent:* Wednesday, March 18, 2015 4:53 PM
> *To:* daveswarth...@gmail.com ; 'Development list for mkgmap'
> 
> *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

[mkgmap-dev] Testing for a literal question mark

2015-03-18 Thread Dave Swarthout
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] roadspeed in default style

2015-03-15 Thread Dave Swarthout
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 
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

2015-02-23 Thread Dave Swarthout
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 
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

2015-02-23 Thread Dave Swarthout
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

2015-02-22 Thread Dave Swarthout
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 
> 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

Re: [mkgmap-dev] Oneway

2015-02-22 Thread Dave Swarthout
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 
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

  1   2   >