[mkgmap-dev] Commit r4513: fix obvious typo in evaluation of seamark:light:character found by sonarlint

[svn commit]

Version mkgmap-r4513 was committed by gerd on Thu, 04 Jun 2020

fix obvious typo in evaluation of seamark:light:character found by sonarlint

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4513
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Options file

[Gerd Petermann]

Hi Dave,

it is not easy for mkgmap to understand that the string "name" was meant to be 
an option or a parameter for an option. The only hint is that the string 
doesn't contain a "." and thus it is unlikely to be an input file. Remember 
that it is the shell which parses the command first.

>  Aren't all "tiles" processed in a run of mkgmap?
Yes, but each one has it's own set of options.
Example : java -jar mkgmap.jar --gmapsupp in1.osm --latin1 --route in2.osm 
in3.osm
The options for file in1.osm are different to those used for in2.osm and in3.osm
Normally, this only makes sense for options like --description or --mapname 
which typically change with each input file.

Gerd


Von: Dave Swarthout 
Gesendet: Donnerstag, 4. Juni 2020 07:52
An: Gerd Petermann
Cc: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Options file

Hi again Gerd,

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

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

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

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

Thanks for your effort. I really appreciate it.

Dave



On Thu, Jun 4, 2020 at 12:10 PM Gerd Petermann 
mailto: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 mailto:daveswarth...@gmail.com>>
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 
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 
mailto:daveswarth...@gmail.com>>>
Gesendet: Mittwoch, 3. Juni 2020 16:59
An: Gerd Petermann
Cc: Development list for mkgmap
Betreff: Re: [

Re: [mkgmap-dev] Options file

[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>
> 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 >>> 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> mkgmap-dev-boun...@lists.mkgmap.org.uk mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Dave Swarthout <
> daveswarth...@gmail.com

Re: [mkgmap-dev] Options file

[Gerd Petermann]

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 
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 mailto: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 
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 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
 im Auftrag von Dave Swarthout 
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 herei

[mkgmap-dev] Commit r4512: improve "file doesn't exist" message: put name in quotes

[svn commit]

Version mkgmap-r4512 was committed by gerd on Thu, 04 Jun 2020

improve "file doesn't exist" message: put name in quotes

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4512
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Options file

[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>
> 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>
> 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\Map

Re: [mkgmap-dev] Options file

[Gerd Petermann]

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 
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 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Dave Swarthout 
mailto:daveswarth...@gmail.com>>
Gesendet: Mittwoch, 3. Juni 2020 12:33
An: Development list for mkgmap
Betreff: [mkgmap-dev] Options file

This is a two-part question.
Firstly:
I have been trying to change my compilation method to use a config file but am 
having problems. During my experimentations I managed to insert the style file 
directive "--style-file=directory|zip-filename|url" _after_ the filespec for 
the OSM data file. My map compiled without errors but was not using my styles. 
I was very confused because it had always worked before. It took me 20 or 30 
minutes to discover that I had accidentally "misplaced" my style file parameter 
in the mkgmp parameter list. Once I moved it in front of the filespecs for my 
OSM data file and custom TYP file, all was well again.

I am assuming that the "options" file included with every mkgmap download is 
the primary help file for running mkgmap. So I guess I'm asking if someone 
would please add a sentence to the options file where the use _and placement_ 
of the style file parameter is explained more completely. The way it is now, 
one cannot know that the placement of that parameter is important. Apparently,  
the placement of ALL parameters must come before any filespecs in the mkgmap 
invocation but that important fact isn't obvious (at least to me) from reading 
the options help file.

A line saying "the style file parameter must appear before any references to a 
file specification for input data or custom TYP file." inserted just after the 
"=== Style options ===" section divider would be very helpful

Or perhaps a line at the very top of the options file saying "Note: all options 
specified herein must appear on the mkgmap invocation before any reference to 
an OSM input file or a custom TYP file."

***
Secondly:

The problem I'm having with using a configuration file might be related to file 
specifications, but I'm not sure. My first try used the filespecs in quotes as 
they appear in my parm specification. That didn't work. When I compile a map 
using the scenario below, mkgmap produces an error saying "SEVERE (Main): name: 
file name doesn't 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] Commit r4511: allow to use single or double quotes in the name-tag-list option

[svn commit]

Version mkgmap-r4511 was committed by gerd on Wed, 03 Jun 2020

allow to use single or double quotes in the name-tag-list option

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4511
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit r4510: minor code improvements, no change in output expected

[svn commit]

Version mkgmap-r4510 was committed by gerd on Wed, 03 Jun 2020

minor code improvements, no change in output expected

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4510
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Options file

[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] Commit r4509: minor code improvements, no change in output expected

[svn commit]

Version mkgmap-r4509 was committed by gerd on Wed, 03 Jun 2020

minor code improvements, no change in output expected

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4509
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Commit r4508: minor code improvements, no change in output expected

[svn commit]

Version mkgmap-r4508 was committed by gerd on Wed, 03 Jun 2020

minor code improvements, no change in output expected

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4508
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Options file

[Gerd Petermann]

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
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Options file

[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

Re: [mkgmap-dev] is_in() function for point on line

[Gerd Petermann]

Hi Joris, Hi Mike,

I've implemented the suggested improvements with r4507. Please suggest 
improvements for the documentation changes.
I did not yet document the new prefix mkgmap:from-node: in the style because I 
found no simple description. Feel free to suggest something.
Reg. the implementation:
I decided to ignore all tags with the prefix mkgmap: , e,g. those from the 
LocationHook like mkgmap:admin_level2. It might happen that the values for the 
node are different to those copied from the way, but I don't assume that 
anybody wants to add extra rules for that.
Maybe I should change it the other way around so that the generated POI gets 
the "exact" values from the node (without the mkgmap:from-node: prefix?

The code should also work for POIs added with the --add-pois-to-areas option 
when the generated POI is using the location of a node because of the 
--pois-to-areas-placement option.

Gerd


Von: Mike Baggaley 
Gesendet: Montag, 1. Juni 2020 12:34
An: 'Gerd Petermann'; 'Development list for mkgmap'
Betreff: RE: [mkgmap-dev] is_in() function for point on line

Hi Gerd,

I have --add-pois-to-lines in my command, but right near the beginning of my 
points file I have

mkgmap:line2poitype=start | mkgmap:line2poitype=inner | mkgmap:line2poitype=end 
{deletealltags} # only centre of line wanted

I wonder whether there could be some efficiency improvement by extending the 
--add-pois-to-lines option to be something like

--add-pois-to-lines[=start|end|inner|mid[,...]]

We would then reduce the number of unwanted POIs created.

I actually only use this for placing bridge and tunnel names at the middle of 
the way and replacing line gates with point gates, so being able to do this in 
the lines file of my style sheet would be even better:

tunnel=* | bridge=* | barrier=gate {set mkgmap:addpoistoline=mid}

This assumes that generating POIs happens after the line stylesheet is 
processed.

Regards,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com]
Sent: 01 June 2020 10:50
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] is_in() function for point on line

Hi Joris,

probably my ideas don't work. Your case is very special because you render the 
POI only when it is part of a way. The example with
entrance=main is probably not a good one as
entrance=main & is_in(building,mall,on) [...]
already works.
I've coded a better patch so that your example will also work when option 
--link-pois-to-ways is not used. Up to now the patch depends on that.

I do not yet see how mkgmap can avoid the generation of all useless POI without 
adding a lot of code to analyse the rules in the points file, but I still think 
about this. Problem is that we have the generated tags like 
mkgmap:admin_level10 or mkgmap:residential and I fear to break something that 
uses tricky rules with just these tags.

> Or we could work the other way around, in stead of render all poi's for all 
> objects and not use them, the mapmaker specifies the explicit objects the 
> poi's are needed.
Yes, might be an option. An exclude list might also work.

Gerd



Von: mkgmap-dev  im Auftrag von Joris 
Bo 
Gesendet: Montag, 1. Juni 2020 10:51
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] is_in() function for point on line

Hallo Gerd,

This works perfect ! (points - file)
mkgmap:from-node:highway = turning_circle & highway = track [0x641a 
resolution 24]
mkgmap:from-node:highway = turning_circle & highway != track[0x641b 
resolution 24]

Your suggestion will indeed also feature your 'entrance=main' example which is 
actually a very useful one to avoid cluttering
The "add-poi-to-lines" option is still usefull I think ?
For example
- to give a bicycle route a name-poi
- render a symbol for the line leisure = slipway
- render a cable car symbol for aerialway = gondola
- a warning symbol at the highway = via_ferrata
- or incline symbols at the start of steep mountain highways?

If those could be solved without rendering thousands of poi's for complex 
multipolygon lines that would be great of course.
Or we could work the other way around, in stead of render all poi's for all 
objects and not use them, the mapmaker specifies the explicit objects the poi's 
are needed.

Kind regards
Joris

-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Gerd Petermann
Verzonden: zondag 31 mei 2020 11:38
Aan: Development list for mkgmap 
Onderwerp: Re: [mkgmap-dev] is_in() function for point on line

Hi Joris,

up to now we only mentioned nodes with a highway=* tag used in ways with a 
highway=* tag.
I've coded a rather simple patch for that, but while I did that I wondered why 
this should be limited to highways.
I decided to use the prefix "mkgmap:from-node:". Tags with prefix mkgmap:  are 
not copied.

My understanding is that you want a function which tells you if a tagged node 
is used in one or

[mkgmap-dev] Commit r4507: improve POIGeneratorHook

[svn commit]

Version mkgmap-r4507 was committed by gerd on Wed, 03 Jun 2020

improve POIGeneratorHook
- add parameter list to option add-pois-to-lines to give user more control 
about the POIs that are generated
- copy tags of original nodes with prefix mkgmap:from-node: to the generated 
POI when the points style checks the value. Example usage: 
mkgmap:from-node:highway = turning_circle & highway = track   [0x641a 
resolution 24]
mkgmap:from-node:highway = turning_circle & highway != track  [0x641b 
resolution 24]
- change OsmReadingHooks interface so that the style is passed in init() 
- some minor code simplifications

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=4507
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev