Re: [mkgmap-dev] arabic translation to latin

[Gerd Petermann]

Hi all,

sorry, seems arabic names where transliterated. They looked okay on my side. 
Please refer to the strings rendered in OSM, not the garbage that arrived on 
the list.

Gerd


Von: Gerd Petermann 
Gesendet: Montag, 29. April 2024 08:08
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] arabic translation to latin

Hi Thomas,

the way https://www.osm.org/way/786582586 (in version 2) has the tags
addr:street=مدخل المدينة
amenity=hospital
healthcare=hospital
name:ar=مستشفى التاهيل
name=مستشفى التاهيل

I think "MSTSHF ?LT?HYL" is the transliteration for the content of the name 
tag. The transliteration is done with generated tables,
the tables were generated in 2010, so maybe something changed since then. I 
think the ? character is the default for anything that was not
translated. If you think this transliteration could be improved please tell us 
what characters you would expect or post a patch. The sources for the tables are
in \mkgmap\resources\chars\latin1

I have no idea what you mean with  "automatic translation from arabic to latin".
When I feed Deepl with   مستشفى التاهيل it says this means "Rehabilitation 
hospital", but mkgmap cannot do this, it just replaces character by character 
and
maybe doesn't even recognize that the name is to be read from right to left.

If you just want to avoid to have unreadable names in your map maybe add a rule 
to check if the name contains arabic (or hebrew or ...) characters and - if so 
- ignore it?
I guess it can be done with a regular expression but I can't say how it should 
look like.

Gerd


Von: mkgmap-dev  im Auftrag von Thomas 
Morgenstern 
Gesendet: Sonntag, 28. April 2024 08:50
An: Development list for mkgmap
Betreff: [mkgmap-dev] arabic translation to latin

Hello at All,
in some tiles from africa are only name-tags as name:ar=. Example : 
OSM -ID 786.582.586 : addr:street=  ; amenity=hospital; 
healthcare=hospital; name:ar=. If I compile this tile with 
code-page=1252,  there shows up as name very cryptic  like Mstshf ~?Lt?Hyl.  If 
I use codepage=65001 ,then shows up the original arabic chars. But I am not 
able to read arabic. Because that I am looking for a solution to automatic 
translation from arabic to latin.  mkgmap includes already  a 
translation-table. But this table do not contain arabic. Can you give me any 
hints for integrating arabic to latin ? How to expand this table? It should 
contain also arabic.
thanks thomas
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] arabic translation to latin

[Gerd Petermann]

Hi Thomas,

the way https://www.osm.org/way/786582586 (in version 2) has the tags
addr:street=مدخل المدينة
amenity=hospital
healthcare=hospital
name:ar=مستشفى التاهيل
name=مستشفى التاهيل

I think "MSTSHF ?LT?HYL" is the transliteration for the content of the name 
tag. The transliteration is done with generated tables,
the tables were generated in 2010, so maybe something changed since then. I 
think the ? character is the default for anything that was not
translated. If you think this transliteration could be improved please tell us 
what characters you would expect or post a patch. The sources for the tables are
in \mkgmap\resources\chars\latin1

I have no idea what you mean with  "automatic translation from arabic to latin".
When I feed Deepl with   مستشفى التاهيل it says this means "Rehabilitation 
hospital", but mkgmap cannot do this, it just replaces character by character 
and
maybe doesn't even recognize that the name is to be read from right to left.

If you just want to avoid to have unreadable names in your map maybe add a rule 
to check if the name contains arabic (or hebrew or ...) characters and - if so 
- ignore it?
I guess it can be done with a regular expression but I can't say how it should 
look like.

Gerd


Von: mkgmap-dev  im Auftrag von Thomas 
Morgenstern 
Gesendet: Sonntag, 28. April 2024 08:50
An: Development list for mkgmap
Betreff: [mkgmap-dev] arabic translation to latin

Hello at All,
in some tiles from africa are only name-tags as name:ar=. Example : 
OSM -ID 786.582.586 : addr:street=  ; amenity=hospital; 
healthcare=hospital; name:ar=. If I compile this tile with 
code-page=1252,  there shows up as name very cryptic  like Mstshf ~?Lt?Hyl.  If 
I use codepage=65001 ,then shows up the original arabic chars. But I am not 
able to read arabic. Because that I am looking for a solution to automatic 
translation from arabic to latin.  mkgmap includes already  a 
translation-table. But this table do not contain arabic. Can you give me any 
hints for integrating arabic to latin ? How to expand this table? It should 
contain also arabic.
thanks thomas
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] UBUNTU JVM

[Gerd Petermann]

Hi Thomas,

this is more likely a hardware or driver problem and not related to mkgmap or 
the java run time. You may try a test program which forces a max. CPU load or a 
memory test.

Gerd


Von: mkgmap-dev  im Auftrag von Thomas 
Morgenstern 
Gesendet: Montag, 15. April 2024 08:45
An: Development list for mkgmap
Betreff: [mkgmap-dev] UBUNTU JVM

Hello, under W10 ,32 GB RAM, Ryzen 7- 8 Core, mkgmap-r4919 (and also previous 
versions) stops processing large data sets after about 600 tiles. That's why I 
installed an UBUNTU 22-04 system. And the java-1.11.0-openjdk,  installs 
jdk-21-oracle-x64 and jdk-22-oracle-x64 machines.
 None of the JVM works. On java-1.11.0, Ubuntu crashes completely after 
starting mkgamp.
Under jdk-21, mkgmap creates ~40 tiles and the terminal exits.
Under jdk-22 mkgmap creates ~40 tiles and the terminal closes.
Which JVM on UBUNTU needs to be installed to fix this error ?

Under Windows 10, the generation ends after ~ 600 tiles from 1215 tiles. Why? 
What do you have to set up on W10 to make mkgmap work to the end ?

Half a year ago, this went without any problems. Now it doesn't work on W10 or 
Linux.
Hints very welcome.
thomas

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Patch to update documentation for splitter

[Gerd Petermann]

Hi all,

Steve updated the doc page manually last night, there is indeed no automatic 
process.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Sonntag, 7. April 2024 09:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Patch to update documentation for splitter

Hi Ticker,

Yes, yesterday I asked Steve to check if this is meant to be done manually. No 
response yet.
The html is indeed outdated, it differs in many points. I'll do the changes 
manually on
Tuesday if Steve doesn't respond before.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Samstag, 6. April 2024 14:14
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Patch to update documentation for splitter

It seems that splitter build/release process for www.mkgmap.org.uk doesn't
regenerate the online documentation or produce the formatted text version of
doc/splitter.txt from the raw wiki format splitter.txt. Looking back to an older
downloaded version from Dec-2018 it didn't do it then either.

Ticker

On Fri, 2024-04-05 at 16:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Looking at the svn log it seems that the man page splitter.1 which is in groff
> format can be generated from splitter.1.xml which is in DocBook XML format. I
> can't be bothered to install and try this so I think just keep all files as
> you
> have.
>
> The version of splitter.txt I attached can go in dist/doc where it will be
> copied into a local system you make with ant - check what you have there to
> see
> of this makes sense. If splitter.html is there replace that as well. I presume
> Steve's automatic building process does this; I'll have a look next week to
> see
> if splitter-r654 has been created and the contents of its doc.
>
> Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Patch to update documentation for splitter

[Gerd Petermann]

Hi Ticker,

Yes, yesterday I asked Steve to check if this is meant to be done manually. No 
response yet.
The html is indeed outdated, it differs in many points. I'll do the changes 
manually on
Tuesday if Steve doesn't respond before.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Samstag, 6. April 2024 14:14
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Patch to update documentation for splitter

It seems that splitter build/release process for www.mkgmap.org.uk doesn't
regenerate the online documentation or produce the formatted text version of
doc/splitter.txt from the raw wiki format splitter.txt. Looking back to an older
downloaded version from Dec-2018 it didn't do it then either.

Ticker

On Fri, 2024-04-05 at 16:08 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> Looking at the svn log it seems that the man page splitter.1 which is in groff
> format can be generated from splitter.1.xml which is in DocBook XML format. I
> can't be bothered to install and try this so I think just keep all files as
> you
> have.
>
> The version of splitter.txt I attached can go in dist/doc where it will be
> copied into a local system you make with ant - check what you have there to
> see
> of this makes sense. If splitter.html is there replace that as well. I presume
> Steve's automatic building process does this; I'll have a look next week to
> see
> if splitter-r654 has been created and the contents of its doc.
>
> Ticker

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Patch to update documentation for splitter

[Gerd Petermann]

Hi Ticker,

thanks for checking. I also don't know where those doc files are used or how a 
man file should be installed.
I'd be happy to drop any doc which is of no use.

I've committed r654 for now. Not sure what to do with your version of 
splitter.txt.

Gerd




Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Freitag, 5. April 2024 12:09
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Patch to update documentation for splitter

Hi Gerd

The unix man entry looks fine

$ man -l ${splitterSvn}/trunk/doc/splitter.1

but I don't know how anyone would be expected to find and use it unless it gets
installed with the other man pages

dist/doc/splitter.txt and .html generated with mwconf from doc/splitter.txt are
attached; I don't know if you need either or both before committing the change,
but I doubt if you need the .html version - www.mkgmap.org.uk should re-generate
it in the correct context.

I have no idea how splitter.1.xml is used

Ticker


On Fri, 2024-04-05 at 07:37 +, Gerd Petermann wrote:
> Hi Felix,
>
> don't worry. My contribution should be read by other developers.
> If you want to become one see https://www.mkgmap.org.uk/dev/index.html
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von Felix
> Herwegh 
> Gesendet: Freitag, 5. April 2024 09:03
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Patch to update documentation for splitter
>
> What exactly should one do?
>
> I'm on Debian but so far have never compiled from source.
>
> //Felix
>
>
>  Original Message 
> From: Gerd Petermann 
> Sent: April 5, 2024 7:16:37 AM GMT+02:00
> To: "mkgmap-dev@lists.mkgmap.org.uk" 
> Subject: [mkgmap-dev] Patch to update documentation for splitter
>
> Hi all,
>
> the attached patch adds a hint that holes in *.poly files are ignored.
> It also adds the --polygon-desc-file option in splitter.txt.
>
> Unfortunately I don't know how to test the formatting in the various
> formats, esp. the man page. Would be nice if someone on a linux system
> could test this.
>
> 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

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Patch to update documentation for splitter

[Gerd Petermann]

Hi Felix,

don't worry. My contribution should be read by other developers.
If you want to become one see https://www.mkgmap.org.uk/dev/index.html

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Freitag, 5. April 2024 09:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Patch to update documentation for splitter

What exactly should one do?

I'm on Debian but so far have never compiled from source.

//Felix


 Original Message 
From: Gerd Petermann 
Sent: April 5, 2024 7:16:37 AM GMT+02:00
To: "mkgmap-dev@lists.mkgmap.org.uk" 
Subject: [mkgmap-dev] Patch to update documentation for splitter

Hi all,

the attached patch adds a hint that holes in *.poly files are ignored.
It also adds the --polygon-desc-file option in splitter.txt.

Unfortunately I don't know how to test the formatting in the various
formats, esp. the man page. Would be nice if someone on a linux system
could test this.

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

Re: [mkgmap-dev] Patch to update documentation for splitter

[Gerd Petermann]

Oops, forgot to attach the patch. Here it is.

Gerd



Von: Gerd Petermann 
Gesendet: Freitag, 5. April 2024 07:16
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Patch to update documentation for splitter

Hi all,

the attached patch adds a hint that holes in *.poly files are ignored.
It also adds the --polygon-desc-file option in splitter.txt.

Unfortunately I don't know how to test the formatting in the various
formats, esp. the man page. Would be nice if someone on a linux system
could test this.

Gerd


poly-doc.patch
Description: poly-doc.patch
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Patch to update documentation for splitter

[Gerd Petermann]

Hi all,

the attached patch adds a hint that holes in *.poly files are ignored.
It also adds the --polygon-desc-file option in splitter.txt.

Unfortunately I don't know how to test the formatting in the various 
formats, esp. the man page. Would be nice if someone on a linux system 
could test this.

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Error in gmapsupp blocksize calculation with huge number of tiles

[Gerd Petermann]

Hi all

see https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2024q2/034252.html
I think the experiments by Felix Herwegh showed a bug in the blocksize 
calculation. If the user combines a huge number of tiles (e.g. 6000) in one 
gmapsupp
the code may not find the best blocksize due to an integer overflow. Not sure, 
maybe this also happens with < 2048 tiles in some cases. 

The attached patch fixes the calculation. It will result in smaller gmapsupp 
sizes where the error occured.

Gerd





blksize.patch
Description: blksize.patch
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] split using --polgon-file

[Gerd Petermann]

keeping an eye on filesizes? 
At least for targeting non-rectangular shaped maps?
And that some few tiles with very few nodes may be unavoidable and have to be 
accepted at times (p.e. due to having nearly all sea, if the polygon is not 
exactly following shore)? Is a max. accepted tilesize (@ min. tile count) 
known, and perhaps already handled by splitter?

reg. 5: Global index? The figures I gave where using mkgmap without index. 
Wouldn't labels space requirement grow linear with tile count?

Cheers Felix

On 03.04.24 15:49, Gerd Petermann wrote:

Hi Felix,

reg 1: The polygon is used to filter the input, splitter cannot write 
non-rectangulare tiles.
The logic with the 40 or less edges is very special. The idea was to take a 
split file for a continent or planet and group tiles.
reg. 2: (poly with hole) See e.g. 
http://download.geofabrik.de/africa/south-africa.poly
reg. 3: Splitter tries several times to split, maybe you were confused by 
partial results?
reg. 4: If I remember correctly it was reported that some devices cannot handle 
a gmapsupp with > 2048 tiles, that's why some map providers try to create large 
tiles.
reg. 5: See above. Reg. size: I assume the global index requires much more 
space, also the labels which are repeated in each tile.
reg. 6:
--search-limit : It may save some time to use a higher limit when you know that 
the default will not find a solution
--num-tiles: This is nomally used to divide a huge file (e.g. a continent) into 
a few (2 .. 6) tiles so that these files can be used again as input for 
splitter.

Hope this helps...
Gerd



Von: mkgmap-dev 
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von Felix Herwegh <mailto:mlmm...@herwegh.de>
Gesendet: Mittwoch, 3. April 2024 15:18
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: [mkgmap-dev] split using --polgon-file

Hi,

recently I started playing with splitting using polygon files, primarily based 
on the documentation in https://www.mkgmap.org.uk/doc/splitter.html. Got it to 
work, even with multiple areas in one .poly file (testing only, no 
application). The idea is to better cut out neighboring countries' and sea area 
for countries poorly aligned to lat/lon (NL, BE, IT...).

Digging deeper though, severeal questions arose, that I couldn't answer, 
neither by the doc mentioned above nor by the (seemingly somewhat more topical 
but brief) --help output of splitter, not even by searching this lists archives.

  1.  Although the doc for --polygon-files says:
"If the polygon area(s) describe(s) a rectilinear area with no more than 40 
vertices, splitter will try to create output files that fit exactly into the 
area, otherwise it will approximate the polygon area with rectangles."
So far I have not been able to generate a single split, that exactly follows 
the polygon, even if quite simple (<<40 points). I always get tiles on or 
extending the polygone.
I'm not shure, I understand that quoted sentence. Does it (for a single area) 
mean a polygone of <= 41 points, hence <=40 lines (if first and last point are 
identical)?
Is this functionatlity still in place, or has it been deprecated?
Neither am I shure, I understand the target.
Should splitter generate non-rectangular tiles with an alignment according to a 
polygone at all, or only rectangular aligned to lat/lon? If the latter, 
"exactly follows" could only work for polygones having each line parallel lat 
or lon?

  2.  The .poly files should follow the Osmosis syntax, which also specifies:
"The polygon section name may optionally be prefixed with "!" to subtract the 
polygon. The section(s) containing the larger area from which to subtract 
should be listed first. All the polygon sections are combined together to 
create the final filter area."
I couldn't make that work. Tried "!" directly in front of the section-name, 
separated by blank and on an individual line. Splitter does not complain, but 
seems generate identical splits for all 3 tries and without that area specified 
at all.
Does splitter respect this syntax at all? (testing only, no application)

  3.  From what I've read so far, one might want to aim for "solution is nice", 
sufficiently even distributed node counts over all tiles, right?
Is that 80% tiles @ > 80% targeted nodes and <3% tiles below 33% targeted nodes?
Why do I get nice solutions although (after having the search limit being 
increased in several steps) splitter comments "No good solution found, trying 
to find one accepting anything"?
What would define a good split?

  4.  My initial approach was to increase tile count to better follow the 
polygone. I basically did that by decreasing --max-nodes and, when splitter ran 
into tiles having >100% targeted nodes, raising resolution to allow for those 
tiles (cities...) to be smaller. I eaven had t

Re: [mkgmap-dev] split using --polgon-file

[Gerd Petermann]

Hi Felix,

reg 1: The polygon is used to filter the input, splitter cannot write 
non-rectangulare tiles.
The logic with the 40 or less edges is very special. The idea was to take a 
split file for a continent or planet and group tiles.
reg. 2: (poly with hole) See e.g. 
http://download.geofabrik.de/africa/south-africa.poly
reg. 3: Splitter tries several times to split, maybe you were confused by 
partial results?
reg. 4: If I remember correctly it was reported that some devices cannot handle 
a gmapsupp with > 2048 tiles, that's why some map providers try to create large 
tiles.
reg. 5: See above. Reg. size: I assume the global index requires much more 
space, also the labels which are repeated in each tile.
reg. 6:
--search-limit : It may save some time to use a higher limit when you know that 
the default will not find a solution
--num-tiles: This is nomally used to divide a huge file (e.g. a continent) into 
a few (2 .. 6) tiles so that these files can be used again as input for 
splitter.

Hope this helps...
Gerd



Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Mittwoch, 3. April 2024 15:18
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] split using --polgon-file

Hi,

recently I started playing with splitting using polygon files, primarily based 
on the documentation in https://www.mkgmap.org.uk/doc/splitter.html. Got it to 
work, even with multiple areas in one .poly file (testing only, no 
application). The idea is to better cut out neighboring countries' and sea area 
for countries poorly aligned to lat/lon (NL, BE, IT...).

Digging deeper though, severeal questions arose, that I couldn't answer, 
neither by the doc mentioned above nor by the (seemingly somewhat more topical 
but brief) --help output of splitter, not even by searching this lists archives.

  1.  Although the doc for --polygon-files says:
"If the polygon area(s) describe(s) a rectilinear area with no more than 40 
vertices, splitter will try to create output files that fit exactly into the 
area, otherwise it will approximate the polygon area with rectangles."
So far I have not been able to generate a single split, that exactly follows 
the polygon, even if quite simple (<<40 points). I always get tiles on or 
extending the polygone.
I'm not shure, I understand that quoted sentence. Does it (for a single area) 
mean a polygone of <= 41 points, hence <=40 lines (if first and last point are 
identical)?
Is this functionatlity still in place, or has it been deprecated?
Neither am I shure, I understand the target.
Should splitter generate non-rectangular tiles with an alignment according to a 
polygone at all, or only rectangular aligned to lat/lon? If the latter, 
"exactly follows" could only work for polygones having each line parallel lat 
or lon?

  2.  The .poly files should follow the Osmosis syntax, which also specifies:
"The polygon section name may optionally be prefixed with "!" to subtract the 
polygon. The section(s) containing the larger area from which to subtract 
should be listed first. All the polygon sections are combined together to 
create the final filter area."
I couldn't make that work. Tried "!" directly in front of the section-name, 
separated by blank and on an individual line. Splitter does not complain, but 
seems generate identical splits for all 3 tries and without that area specified 
at all.
Does splitter respect this syntax at all? (testing only, no application)

  3.  From what I've read so far, one might want to aim for "solution is nice", 
sufficiently even distributed node counts over all tiles, right?
Is that 80% tiles @ > 80% targeted nodes and <3% tiles below 33% targeted nodes?
Why do I get nice solutions although (after having the search limit being 
increased in several steps) splitter comments "No good solution found, trying 
to find one accepting anything"?
What would define a good split?

  4.  My initial approach was to increase tile count to better follow the 
polygone. I basically did that by decreasing --max-nodes and, when splitter ran 
into tiles having >100% targeted nodes, raising resolution to allow for those 
tiles (cities...) to be smaller. I eaven had the "feeling", that my Edge 1040 
appreciated more smaller tiles by zooming and scrolling smoother.
On the other hand from the doc and for example some discussion here between 
Gerd and Felix Hartmann regarding and around r609 release I've got the 
impression, that the typical target might be minimum tile count, as long as 
some (Garmin?) max. tilesize (?) is not reached. Why is that?

  5.  Increasing a significant portion of Germany maps tile count ~by factor 7 
from ~280 tiles (@ max-nodes=120, resolution=13) to ~2000 tiles (@ 
max-nodes=15, resolution=15) only took around an additional 8% in gmappsupp 
filesize, but another factor of 3 to ~6000 tiles (@ max-nodes=5, 
resolution=??) made it "explode" to 300% of the original size. This map did 
still load 

Re: [mkgmap-dev] Splitter Java Heap

[Gerd Petermann]

Hi Felix,

if you feed the same input (same file(s) , same options) into identical 
splitter and run it on identical JRE with identical JRE options but on two 
different machines you still have to compare the number of parallel threads 
(max-threads).

Gerd



Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Mittwoch, 20. März 2024 20:39
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Splitter Java Heap

Hi Gerd,

Thanks!

>From the java --version output (in the first mail) I assumed already beeing on 
>a 64-bit JRE and, following your advice, set -Xmx4G. Bingo, succes in the 
>first pass on the weak machine.

JVM Memory Info: Current 3990MB (1967MB used, 2023MB free) Max 4096MB

I still wonder how to read the figures though, as for the former successfull 
passes only about 1300 MB where reported used. and every pass reportedly still 
had free memory, although "current" was = "max." on the fails.

So, how to figure out an appropriate allocation? By map and/or machine?

Altough reading up on splitters documentation I seem to have been derailled by 
the description for  --max-areas parameter

Higher numbers ... require more memory

Note that the first stage of the processing has a fixed memory overhead 
regardless of what this is set to so if you are running out of memory before 
the areas.list file is generated, you need to either increase your -Xmx value...

Therefore I fiddled with max-areas, but didn't try to use -Xmx myself.

But, I now see, why --max-areas didn't change a thing in my case, as -for the 
map in question- I get:

Processing 293 areas in a single pass

// Felix


On 20.03.24 15:16, Gerd Petermann wrote:

Hi Felix,

I guess your laptop is running a 32-bit JRE, so your first step should be to 
install a 64 bit version if you have a 64 bit OS.
With this done you can increase the max heap to e.g. 4GB with something like
java -Xmx4G -jar splitter.jar 
If you cannot increase the memory you can switch of the --keep-complete option 
(with the corresponding disadvantages)

Gerd



Von: mkgmap-dev 
<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>
 im Auftrag von Felix Herwegh <mailto:mlmm...@herwegh.de>
Gesendet: Mittwoch, 20. März 2024 15:03
An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
Betreff: [mkgmap-dev] Splitter Java Heap

Hi,

switching to my Ultrabook (6 GB) while travelling I recently faced some kind of 
borderline condition with splitter. On the first run it throws 
"OutOfMemoryError: Java heap space", on closely subsequent runs without any 
modifications it does not. Repeating the task after some delay fails again. I 
guess, there might be some self-optimization involved for this.

fail:
...
40.000.000 ways parsed... id=888262666
  Number of stored tile combinations in multiTileDictionary: 4.525
41.000.000 ways parsed... id=929920953
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap$ChunkMem.(SparseLong2IntMap.java:189)
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap.saveCurrentChunk(SparseLong2IntMap.java:627)
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap.replaceCurrentChunk(SparseLong2IntMap.java:886)
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap.put(SparseLong2IntMap.java:691)
at 
uk.me.parabola.splitter.SplitProcessor.processWay(SplitProcessor.java:149)
at 
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:84)
at uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:157)
at uk.me.parabola.splitter.Main.writeTiles(Main.java:542)
at uk.me.parabola.splitter.Main.start(Main.java:132)
at uk.me.parabola.splitter.Main.main(Main.java:81)
Elapsed time: 8m 0s   Memory: Current 1466MB (1339MB used, 127MB free) Max 
1466MB

success:
...
48.000.000 ways parsed... id=1262369277
Writing relations Tue Mar 19 10:50:36 CET 2024
100.000 relations parsed... id=1783690
200.000 relations parsed... id=4148045
300.000 relations parsed... id=7895430
400.000 relations parsed... id=11681672
500.000 relations parsed... id=15581604
coord Map: 312.851.126 stored long/int pairs require ca. 3 bytes per pair. 
14.225.657 chunks are used, the avg. number of values in one 64-chunk is 21.
coord Map details: ~852 MB, including 88 array(s) with 8 MB

way Map: 48.015.926 stored long/int pairs require ca. 3 bytes per pair. 
3.974.651 chunks are used, the avg. number of values in one 64-chunk is 12.
way Map details: ~123 MB, including 10 array(s) with 8 MB

  JVM Memory Info: Current 1466MB (1357MB used, 109MB free) Max 1466MB
Full Node tests:  62.230.523
Quick Node tests: 282.354.912
Thread worker-2 has finished
...

My main machine has 24 GB of main memory, and runs troublefree using the 
following memory allocation on the same task:

JVM Memory Info: Curre

Re: [mkgmap-dev] Splitter Java Heap

[Gerd Petermann]

Hi Felix,

I guess your laptop is running a 32-bit JRE, so your first step should be to 
install a 64 bit version if you have a 64 bit OS.
With this done you can increase the max heap to e.g. 4GB with something like
java -Xmx4G -jar splitter.jar 
If you cannot increase the memory you can switch of the --keep-complete option 
(with the corresponding disadvantages)

Gerd



Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Mittwoch, 20. März 2024 15:03
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Splitter Java Heap

Hi,

switching to my Ultrabook (6 GB) while travelling I recently faced some kind of 
borderline condition with splitter. On the first run it throws 
"OutOfMemoryError: Java heap space", on closely subsequent runs without any 
modifications it does not. Repeating the task after some delay fails again. I 
guess, there might be some self-optimization involved for this.

fail:
...
40.000.000 ways parsed... id=888262666
  Number of stored tile combinations in multiTileDictionary: 4.525
41.000.000 ways parsed... id=929920953
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap$ChunkMem.(SparseLong2IntMap.java:189)
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap.saveCurrentChunk(SparseLong2IntMap.java:627)
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap.replaceCurrentChunk(SparseLong2IntMap.java:886)
at 
uk.me.parabola.splitter.tools.SparseLong2IntMap.put(SparseLong2IntMap.java:691)
at 
uk.me.parabola.splitter.SplitProcessor.processWay(SplitProcessor.java:149)
at 
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:84)
at uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:157)
at uk.me.parabola.splitter.Main.writeTiles(Main.java:542)
at uk.me.parabola.splitter.Main.start(Main.java:132)
at uk.me.parabola.splitter.Main.main(Main.java:81)
Elapsed time: 8m 0s   Memory: Current 1466MB (1339MB used, 127MB free) Max 
1466MB

success:
...
48.000.000 ways parsed... id=1262369277
Writing relations Tue Mar 19 10:50:36 CET 2024
100.000 relations parsed... id=1783690
200.000 relations parsed... id=4148045
300.000 relations parsed... id=7895430
400.000 relations parsed... id=11681672
500.000 relations parsed... id=15581604
coord Map: 312.851.126 stored long/int pairs require ca. 3 bytes per pair. 
14.225.657 chunks are used, the avg. number of values in one 64-chunk is 21.
coord Map details: ~852 MB, including 88 array(s) with 8 MB

way Map: 48.015.926 stored long/int pairs require ca. 3 bytes per pair. 
3.974.651 chunks are used, the avg. number of values in one 64-chunk is 12.
way Map details: ~123 MB, including 10 array(s) with 8 MB

  JVM Memory Info: Current 1466MB (1357MB used, 109MB free) Max 1466MB
Full Node tests:  62.230.523
Quick Node tests: 282.354.912
Thread worker-2 has finished
...

My main machine has 24 GB of main memory, and runs troublefree using the 
following memory allocation on the same task:

JVM Memory Info: Current 3342MB (2378MB used, 964MB free) Max 6000MB

Splitter 653 so far is involved without explicit memory allocation (java -jar 
.../splitter-latest/splitter.jar ...), using

java --version
openjdk 11.0.22 2024-01-16
OpenJDK Runtime Environment (build 11.0.22+7-post-Debian-1deb10u1)
OpenJDK 64-Bit Server VM (build 11.0.22+7-post-Debian-1deb10u1, mixed mode, 
sharing)

Following up on splitter tuning hints (areas.list gets generated in each case) 
I reduced --max-areas= from 4096 to 2048 to 1024, but to no avail (not even 
significantly on the runtimes), once I figured out the effect above. It fails 
on all first runs and succeeds on all shortly following next ones.

Unfortunately its not possible to increase main hardware memory on the small 
machine, but system tools report only about 2...3 GB being used anyway.
Is it possible to tweak Java to overcome the problem without hurting the maps, 
preferably by machine, to be able to run identical scripts? Some pointers would 
be appreciated, also on how to monitor the Java memory situation.

Thanks, Felix


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Missing surface=chipseal in default style

[Gerd Petermann]

Hi Carlos,

 thanks for the patch, I've commited that with r4918.

ciao,
Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Mittwoch, 6. März 2024 07:57
An: Development list for mkgmap
Betreff: [mkgmap-dev] Missing surface=chipseal in default style

Hello all

One user of my maps has reported estrange detours in New Zealand. I have
found the reason was the lack of a rule for surface=chipseal in default
lines style, causing those roads to be considered as unpaved. Attached
patch fixes the issue.

Carlos
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Ranking of relations

[Gerd Petermann]

Hi Bernard,

I still think that you also have to collect the different network values and 
use a regex to check if the list of values contains e.g. icn.

Gerd


Von: mkgmap-dev  im Auftrag von Bernard 
Mai 
Gesendet: Samstag, 27. Januar 2024 19:37
An: Development list for mkgmap; m...@tvage.co.uk
Betreff: Re: [mkgmap-dev] Ranking of relations

Dear Mike,

I looks like your suggestion did the trick. With the following lines in the 
"relations" file I get the desired display of routes in my overlay map:

# bicycle routes
route=bicycle
{
apply
{set route='${route}';set 
route_name='$(route_name),${name}'|'${name}';set 
route_ref='$(route_ref),${ref}'|'${ref}';}
}
type=route & route=bicycle & network=icn{apply {add route_icn=yes;}}
type=route & route=bicycle & network=ncn{apply {add route_ncn=yes;}}
type=route & route=bicycle & network=rcn{apply {add route_rcn=yes;}}
type=route & route=bicycle & network=lcn{apply {set route_lcn=yes;}}

# mountainbike routes
route=mtb
{
apply
{add route_mtb=yes; add 
route_mtb_name='$(route_mtb_name),${name}'|'${name}'; add 
route_mtb_ref='$(route_mtb_ref),${ref}'|'${ref}';}
}

In the "lines" file I can adjust the zoom-level display and naming. For me the 
following lines work well:

# bicycle routes
route_icn=yes   
 [0x10f01 resolution 18-20 continue]
route_icn=yes{name '${route_ref}'}  
  [0x10f01 resolution 20-23 continue]
route_icn=yes{name '${route_name} 
(${route_ref})'|'${route_name}'|'${route_ref}'}[0x10f02 
resolution 24]

route_ncn=yes   
 [0x10f01 resolution 20-22 continue]
route_ncn=yes{name '${route_ref}'}  
  [0x10f01 resolution 23 continue]
route_ncn=yes{name '${route_name} 
(${route_ref})'|'${route_name}'|'${route_ref}'}[0x10f02 
resolution 24]

route_rcn=yes   
 [0x10f03 resolution 21-22 continue]
route_rcn=yes{name '${route_ref}'}  
  [0x10f03 resolution 23 continue]
route_rcn=yes{name '${route_name} 
(${route_ref})'|'${route_name}'|'${route_ref}'}[0x10f04 
resolution 24]

route_lcn=yes   
 [0x10f05 resolution 23 continue]
route_lcn=yes{name '${route_name}'|'${route_ref}'}  
  [0x10f05 resolution 24]

# mtb routes
route_mtb=yes{name '${route_mtb_ref}'}  
  [0x10f06 resolution 23 continue]
route_mtb=yes{name '${route_mtb_name} 
(${route_mtb_ref})'|'${route_mtb_name}'|'${route_mtb_ref}'}[0x10f06 
resolution 24]

Now I can play around, as the display of these lines as overlay map on a Garmin 
Epix watch is quite thin (even with lines up to 18 pixel width, having 6-7 
pixel width used with a colour and the remaining pixels transparent to show the 
route beside any way). In general, my experience is that specially on a watch 
all bitmap lines are hard to see.

Many thanks and regards,
Bernard

Am 27.01.2024 um 16:11 schrieb m...@tvage.co.uk:
HI Bernard,

I can’t see why bicycle routes should be displaying in the wrong order, but if 
an MTB route runs along a bicycle route and its relation is processed after the 
bicycle one, I think the route value will be changed from bicycle to mtb. I 
suggest using add instead of set on the relation statement for mountain bike 
routes:

type=route & route=mtb
{
apply
{add route='${route}'; set 
route_mtb_name='$(route_mtb_name),${name}'|'${name}'; set 
route_mtb_ref='$(route_mtb_ref),${ref}'|'${ref}';}
}

Regards,
Mike

From: Bernard Mai 
Sent: 26 January 2024 10:50
To: mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Ranking of relations

Dear all,
I want to generate an overlay map to be used as additional layer on a Garmin 
watch. This layer can be turned on/off on the watch and should show only 
bicycle routes (route=bicycle and route=mtb).
As most routes in openstreetmap are defined as relations I am using the 
following rules in my bike-routes style:

relations (file)
# Route relations as additional transparent layer for:
#   bicycle
#   mtb

# bicycle routes
type=route & route=bicycle
{
apply
{set 

Re: [mkgmap-dev] Ranking of relations

[Gerd Petermann]

Hi Bernard,

I think the problem is in the block
type=route & route=bicycle & network=icn{apply {set route_icn=yes;}}
type=route & route=bicycle & network=ncn{apply {set route_ncn=yes;}}
type=route & route=bicycle & network=rcn{apply {set route_rcn=yes;}}
type=route & route=bicycle & network=lcn{apply {set route_lcn=yes;}}

Whatever relation type comes last overwrites the values for the other. You have 
to collect (concatenate) the different values instead of replacing.
I think the clause above shows how that works.

Gerd


Von: mkgmap-dev  im Auftrag von Bernard 
Mai 
Gesendet: Freitag, 26. Januar 2024 11:50
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Ranking of relations

Dear all,
I want to generate an overlay map to be used as additional layer on a Garmin 
watch. This layer can be turned on/off on the watch and should show only 
bicycle routes (route=bicycle and route=mtb).
As most routes in openstreetmap are defined as relations I am using the 
following rules in my bike-routes style:

relations (file)
# Route relations as additional transparent layer for:
#   bicycle
#   mtb

# bicycle routes
type=route & route=bicycle
{
apply
{set route='${route}';set 
route_name='$(route_name),${name}'|'${name}';set 
route_ref='$(route_ref),${ref}'|'${ref}';}
}
type=route & route=bicycle & network=icn{apply {set route_icn=yes;}}
type=route & route=bicycle & network=ncn{apply {set route_ncn=yes;}}
type=route & route=bicycle & network=rcn{apply {set route_rcn=yes;}}
type=route & route=bicycle & network=lcn{apply {set route_lcn=yes;}}

# mountainbike routes
type=route & route=mtb
{
apply
{set route='${route}'; set 
route_mtb_name='$(route_mtb_name),${name}'|'${name}'; set 
route_mtb_ref='$(route_mtb_ref),${ref}'|'${ref}';}
}

lines (file)
# bicycle routes
route=bicycle & route_icn=yes{name '${route_ref}'}  
  [0x10f01 resolution 18-22 continue]
route=bicycle & route_icn=yes{name '${route_name} 
(${route_ref})'|'${route_name}'|'${route_ref}'}[0x10f02 resolution 23-24]

route=bicycle & route_ncn=yes   
 [0x10f01 resolution 20-22 continue]
route=bicycle & route_ncn=yes{name '${route_ref}'}  
  [0x10f02 resolution 23 continue]
route=bicycle & route_ncn=yes{name '${route_name} 
(${route_ref})'|'${route_name}'|'${route_ref}'}[0x10f02 resolution 24]

route=bicycle & route_rcn=yes   
 [0x10f03 resolution 20-22 continue]
route=bicycle & route_rcn=yes{name '${route_ref}'}  
  [0x10f04 resolution 23 continue]
route=bicycle & route_rcn=yes{name '${route_name} 
(${route_ref})'|'${route_name}'|'${route_ref}'}[0x10f04 resolution 24]

route=bicycle & route_lcn=yes{name '${route_name} 
(${route_ref})'|'${route_name}'|'${route_ref}'}[0x10f05 resolution 24]

# mtb routes
route=mtb {name '${route_mtb_ref}'} 
   [0x10f06 resolution 23 continue]
route=mtb {name '${route_mtb_name} 
(${route_mtb_ref})'|'${route_mtb_name}'|'${route_mtb_ref}'}[0x10f06 
resolution 24]


In general, these routes are drawn by mkgmap and I am able to generate an 
overlay map, but sometimes a route with "lower" priority (i. e. a route=mtb) 
hides a route with "higher" priority. In other words, I would like to show the 
routes in a ranking: The routes tagged with network=icn should be on top, 
followed by network=ncn and so on. The route=mtb should be only shown, if no 
other bicycle route is on the same way.
Is this possible to achieve with mkgmap alone? Or do I need some sort of 
additional script to rank the relations before rendering them with mkgmap?
I have read something, that the draw order depends on the ID of the relation 
and mkgmap renders the lower IDs first. But what about the higher relation IDs? 
It looks like ways tagged from the relation only get the tags from the relation 
with the lowest ID. Is this correct?
Does anybody have an idea, how this could be overcome?

Example:
Way ID has 3 bicycle relevant relations: relation IDs 2119154, 9623717,2956920. 
With the style from above only the last one (relation ID 2956920, route=mtb) is 
shown although the second one (relation ID 9623717, network=icn) would be 
desired as it is an international bicycle route.

Regards,
Bernard
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Splitter feature request

[Gerd Petermann]

Hi Carlos,

since nobody else reacted:
I wonder in what situation an L-shaped tile could be the result of a 
split-process.
Do you think about some kind of post-processor which would recombine 2 or more 
tiles so that they still don't
reach the maxnodes boundary? Thinking about the way how a split is done, I 
think it can happen that the combination of two connected tiles are still below 
the limit,
but I would assume that an L-shape is rather rare.
Anyway, if splitter would write non-rectangular tiles we need
a) a further output file (or a new output format) to store the tile-boundary 
for input in mkgmap
b) some new logic in mkgmap to cut ways and polygons along that boundary

It might be easier to implement b) when boundary lines are only horizontal or 
vertical, but I am pretty sure this wouldn't solve most of the problems
reg.  right/left hand side driving.

ciao
Gerd



Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Sonntag, 3. Dezember 2023 12:26
An: Development list for mkgmap
Betreff: [mkgmap-dev] Splitter feature request

Hi all

I usually let splitter decide tiles based on max-nodes value, but for
some maps I need to supply splitter an areas.list file which I adjust
manually. Reasons for that include reducing the total number of tiles,
avoiding cutting of some islands and separating right/left hand side
driving areas or reducing number of tiles with both sides driving. For
these cases, it would be helpful to be able to build "L shaped tiles",
as in the attached image. I think these tiles could be defined by three
coordinates (A,B,C), which would define the two rectangles in which the
L shaped tile can be split, and a switch (1,2,3,4) to determine de
orientation of the "L".

1: tile = A-lat, A-lon to B-lat, B-lon + A-lat,B-lon to C-lat,C-lon

2: tile = B-lat, A-lon to C-lat, C-lon + A-lat,B-lon to B-lat,C-lon

3: tile = A-lat, A-lon to B-lat, B-lon + B-lat,A-lon to C-lat,C-lon

4: tile = A-lat, A-lon to C-lat, B-lon + A-lat,B-lon to B-lat,C-lon

This raises several questions. First of all, if is feasible, then if it
is worth the effort to implement it, how would if affect splitter
performance and if it makes sense for other users. Perhaps it could be a
first step towards irregular tiles...
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Fix and augment sort definitions

[Gerd Petermann]

Hi Ticker,

please can you provide a unit test for this?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Donnerstag, 12. Oktober 2023 09:18
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Fix and augment sort definitions

Hi Gerd

Last year it was reported that string ordering with the '#' character was 
incorrect. This was
because, in the sort/cp*.txt files, the relevant line with the '#' was taken as 
a comment.

I had a patch that fixed all the files, but it also attempted to do more with 
ß/ss and
dipthongs.

I've done another patch that doesn't have any contentious changes, just fixes 
the #, makes the
layout consistent between the files, increments the version/id2 values and 
slight improvements
to the documentation.

Ticker

On Tue, 2022-01-11 at 14:00 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > if you don't mind I'd like to postpone this patch until the active branches 
> > are merged into
> > trunk.
> >
> > Gerd
> >
> >
> > 
> > Von: mkgmap-dev  im Auftrag von 
> > Ticker Berkin
> > 
> > Gesendet: Dienstag, 11. Januar 2022 11:25
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Fix and augment sort definitions
> >
> > Hi Gerd
> >
> > Yes - gmapsupp builder gives a warning if id1/id2 are not consistent in
> > all the .img files. It is just a warning and gmapsupp is built anyway
> > and I think the warning can be ignored. gmapi doesn't notice.
> >
> > Almost all of the significant sorting where the Garmin device... needs
> > to know the sort details happens in Mdr, so this isn't a problem.
> >
> > Other uses are mostly for de-duping/efficient processing, so these
> > shouldn't matter either.
> >
> > However the LBL file does hold id1/id2 and many sections (Countries,
> > Regions, Cities, Zips, POIs) are sorted so the effect here is unknown.
> >
> > If using --latin2 / 1252, the only change in ordering is around AE/OE
> > dipthongs.
> >
> > Within the same commit or build as sortResource_v2, the attached
> > sortMashExp.patch should be applied, as it effects the binary SRT file
> > and I don't want to increment all the id2's again. This patch changes
> > the sort.expand TERTIARY mashing from 2 to 3, which is slightly more
> > consistent with the Garmin SRT binaries I've seen and allows SrtDisplay
> > to show expansions with what looks like a meaningful case.
> >
> > Ticker
> >
> > On Tue, 2022-01-11 at 06:31 +, Gerd Petermann wrote:
> > > > Hi Ticker,
> > > >
> > > > didn't try it: Will mkgmap complain when building an indexed
> > > > gmapi/gmapsupp
> > > > where some tiles where freshly compiled with the new version and
> > > > others with
> > > > an older (like Felix and Carlos do)?
> > > >
> > > > Gerd
> > > >
> > > > 
> > > > Von: mkgmap-dev  im Auftrag
> > > > von Ticker Berkin 
> > > > Gesendet: Montag, 10. Januar 2022 12:04
> > > > An: Development list for mkgmap
> > > > Betreff: Re: [mkgmap-dev] Fix and augment sort definitions
> > > >
> > > > Hi Gerd
> > > >
> > > > What I meant was that keyboards/devices don't normally have ways of
> > > > entering the single chars "…", "¼", "½", "¾", "™".
> > > >
> > > > Names with these might be presented by Garmin software after some
> > > > initial chars have been entered and you can then select the complete
> > > > name that contains these chars.
> > > >
> > > > I didn't see a good reason to remove the expand for these and find
> > > > some
> > > > arbitrary sort PRIMARY for them. No one has complained about them.
> > > > Also
> > > > cp65001 had over 1000 expands and I really don't want to start
> > > > touching
> > > > these.
> > > >
> > > > Ticker
> > > >
> > > >
> > > > On Mon, 2022-01-10 at 10:29 +, Gerd Petermann wrote:
> > > > > > Hi Ticker,
> > > > > >
> > > > > > I've committed displaySrt_v2.patch .
> > > > > >
> > > > > > I don't fully understand the comment
> > > > > > "Leave the above because no method of inputting them anyway and
> > > > > > unlikely at start of names

Re: [mkgmap-dev] Contour lines without elevation. What shoul mkgmap do?

[Gerd Petermann]

Hi Ticker,

my concern is that the data in the labels is also used to calculate a height 
profile when routing is enabled.
Maybe this also depends on the --show-profiles option.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 11. Oktober 2023 11:51
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Contour lines without elevation. What shoul mkgmap do?

Hi Gerd

Looking at the code, there shouldn't be any crash from mkgmap if a contour line 
doesn't have an
"ele" tag. I assume the Garmin device will just draw the appropriate line 
without a label. This
might be common where alternate contours are not given heights.

So, no; I don't think you should add any checks.

Ticker

On Wed, 2023-10-11 at 08:16 +0000, Gerd Petermann wrote:
> Hi all,
>
> in a private mail I was informed that mkgmap crashes when polish input 
> contains no label for
> types which are considered as contour line data like this
> [POLYLINE]
> Type=0x20
> Data0=(51.5300781,-0.0988259), (51.5305501,-0.0989852), 
> (51.5311576,-0.0992174)
> [END]
>
> The same data was handled without problem before r4907.
> As a quick hack I've added a null check to restore the old behaviour, but I 
> wonder if it would
> be better to stop with an error message
> or maybe ignore contour line data when no elevation is given in the label?
>
> I guess the same problem can happen with OSM data when a style uses the line 
> types  0x20 ..
> 0x25 .
> Should I add checks to warn when these line types are used without a proper 
> label that can be
> elevation data?
>
> 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

[mkgmap-dev] Contour lines without elevation. What shoul mkgmap do?

[Gerd Petermann]

Hi all,

in a private mail I was informed that mkgmap crashes when polish input contains 
no label for types which are considered as contour line data like this
[POLYLINE]
Type=0x20
Data0=(51.5300781,-0.0988259), (51.5305501,-0.0989852), (51.5311576,-0.0992174)
[END]
 
The same data was handled without problem before r4907. 
As a quick hack I've added a null check to restore the old behaviour, but I 
wonder if it would be better to stop with an error message
or maybe ignore contour line data when no elevation is given in the label?

I guess the same problem can happen with OSM data when a style uses the line 
types  0x20 .. 0x25 .
Should I add checks to warn when these line types are used without a proper 
label that can be elevation data? 

Gerd
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Compiling INFO.XML file

[Gerd Petermann]

Hi Diego,

maybe you use the options in the wrong order or maybe you are looking at the 
wrong xml file?
I just tried with these options
java -jar dist\mkgmap.jar --overview-mapname=xyz --series-name=myseries 
--family-name=gerd --family-id=1234 --gmapi 
d:\mkgmap\bin\resources\in\osm\is-in-samples.osm
and I get a folder
\gerd.gmap
containing the attached info.xml file.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 10. Oktober 2023 18:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Compiling INFO.XML file

Hi Diego

If you use the --gmapi mkgmap option it will make the folder (named with 
--family_name option) and contents, including Info.xml

Ticker


On Tue, 2023-10-10 at 15:15 +, helter skelter wrote:
Hello guys
When I create the map for Basecamp, I get a folder under 
ProgramData\Garmin\Maps with a INFO.XML file inside.
There are many fields, but I am able to fill only some of them.
Could you please tell me what options I need to use in Mkgmap to fill these 
fields ?

 OSM map
 100
 Original
...

 series name
...
 osmmap
...


Are they really important for Basecamp map or for the Garmin one ?

Here are the options I am actually using:

--mapname=
--family-id=
--copyright-file=
--country-name=
--index
--series-name=
--description=
--overview-mapname=
--style-file=
--style=
--keep-going
--output-dir=
--nsis
--tdbfile
--remove-short-arcs
--merge-lines
--draw-priority=
--show-profiles=
--gmapsupp
--gmapi
-c

Many thanks
Cheers
Diego



Da: mkgmap-dev  per conto di 
mkgmap-dev-requ...@lists.mkgmap.org.uk 
Inviato: domenica 8 ottobre 2023 11:00
A: mkgmap-dev@lists.mkgmap.org.uk 
Oggetto: mkgmap-dev Digest, Vol 183, Issue 7

Send mkgmap-dev mailing list submissions to
mkgmap-dev@lists.mkgmap.org.uk

To subscribe or unsubscribe via the World Wide Web, visit
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
or, via email, send a message with subject or body 'help' to
mkgmap-dev-requ...@lists.mkgmap.org.uk

You can reach the person managing the list at
mkgmap-dev-ow...@lists.mkgmap.org.uk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mkgmap-dev digest..."
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


http://www.garmin.com/xmlschemas/MapProduct/v1;>
 gerd
 100
 Original
 1234

 myseries
 1
 xyz
 xyz.tdb
 Product1

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Michael,

please try new version r4914 which fixes the large gap in your example and 
probably some more issues like that.

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Dienstag, 26. September 2023 19:44
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hello Gerd,

here is the area: https://www.openstreetmap.org/#map=19/48.57117/13.96920 I
understand that it is necessary to make rounding. If a point of two surfaces
is equal in OSM, the point should also be equal in Garmin.

Thank you!

Best regards,
Michael


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Ticker,

I did some tests and your patch really seems to solve the problem without 
introducing new ones :)

Just one remark: Please try to avoid terms like "+ve" in javadoc. I had to read 
this
two times to understand that it means positive ;)

So, if you don't find furher things to change I would be happy to commit the 
patch, although I don't yet understand
why it also fixes the MP gaps issue.

Gerd




Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Freitag, 6. Oktober 2023 17:22
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi Gerd

Sorry - bit hasty in my reply

I need to look at the other places that use DELTA_SHIFT and check their 
arithmetic/rounding etc
is consistent with the corrected highPrecCoord and uniform in rounding 
behaviour.

Ticker

On Fri, 2023-10-06 at 16:15 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> My change to toMapUnit should be almost undetectable. Imagining mapUnits [x] 
> as degrees over
> the
> real range -2.5 .. +2.5, the original implementation resulted in:
>
> -2.5 <  [-2] <= -1.5 <  [-1] <= -0.5 <  [0] <  -0.5 <= [1] <  +1.5 <= [2] <  
> +2.5
>
> I've changed it to give:
>
> -2.5 <= [-2] <  -1.5 <- [-1] <  -0.5 <= [0] <  -0.5 <= [1] <  +1.5 <= [2] <  
> +2.5
>
> The change to highPrecCoord is so that 64 highPrecCoords are exactly within 
> the appropriate
> mapUnit, with deltas of -31..+32 according to the existing delta calculations.
>
> Ticker
>
> On Fri, 2023-10-06 at 14:34 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > your patch rounds the problematic point to a different position, the same 
> > that is assigned
> > to
> > the new Coord instance that is derived from the cutOutInnerPolygons() method
> > which involves singularAreaToPoints() and thus another place where rounding 
> > happens:
> > int latHp = (int)Math.round(res[1] * 
> > (1< > int lonHp = (int)Math.round(res[0] * 
> > (1< >
> > I think we have to check all nodes which are part of an inner and change 
> > position because of
> > your different rounding method, right? I wouldn't be surprised to find 
> > cases where a gap
> > occurs
> > with (just) your patch. I'll try to find an example...
> > If I can't we may just use your patch, although it's much harder to 
> > understand compared to
> > the
> > original code.
> >
> > 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

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Ticker,

your patch rounds the problematic point to a different position, the same that 
is assigned to the new Coord instance that is derived from the 
cutOutInnerPolygons() method
which involves singularAreaToPoints() and thus another place where rounding 
happens:
int latHp = (int)Math.round(res[1] * 
(1< im Auftrag von Ticker 
Berkin 
Gesendet: Freitag, 6. Oktober 2023 16:19
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi Gerd

I've now looked at your example (mp-gap2.osm). With my toMapUnit/toHighPrec 
patch the problem
almost disappears. I don't see any significant difference when I also apply 
your mp-cut-coord-
pool.patch.

I can't see a way of fixing these gaps/overlaps without disabling a lot of 
filter point-removal,
maybe by setting Coord.preserved() and ensuring added points for polygon 
cutting are on both the
inner and outer polygon, which I thought they were, with the algorithm cutting 
through the
complete structure and then bits being merged later if possible.

Ticker

On Thu, 2023-10-05 at 16:37 +0100, Ticker Berkin wrote:
> Hi Gerd
>
> I've changed the way mapUnit and highPrec Coords are calculated slightly so 
> that the exact 1/2
> unit boundary values are consistent between negative and positive. This gets 
> rid of my couple
> of
> abnormalities with a -32 delta. The old method added or subtracted 1/2 to 
> make ((int)double)
> do
> rounding, which assigns the exact 1/2 to the larger abs value.
>
> toHighPrec(), as in yesterdays change, keeps its bounds consistent with the 
> mapUnit it is
> splitting up but is now coded in a similar way to toMapUnit.
>
> I think rounding to get MapUnits is a mistake but changing it now could have 
> drastic
> consequences, it should have been floorToNegInfinity, giving the nice cyclic 
> scale -128..+127
> <<
> 24. As it is, we get -128..+128 << 24.
>
> Equator & Grenwhich Meridian behave well, but I've always had doubts about 
> behaviour around
> 128
>
> Hope this makes sense - patch attached
>
> Sorry, haven't thought about the actual problem with the gaps yet.
>
> Ticker
>
> On Thu, 2023-10-05 at 07:30 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > reg. the change in toHighPrec() :  I must confess that I never doubted why 
> > positive values
> > should be rounded differently to negative values.
> > This is also done in Utils.toMapUnit() and I just adapted that code. If you 
> > still want to
> > change that I think Math.rint() would get you closer to the original 
> > implementation.
> > Question is if or why this difference in rounding is/was needed. There 
> > should be visible
> > effects near equator and at Greenwhich or at 180°.
> >
> > Anyhow, I don't think this is the solution for the gap problem which is 
> > caused by further
> > conversions from highprec int to double and back.
> > An alternative solution for that problem would be the attached patch which 
> > makes use of the
> > coord pool.
> > No idea which one has more effects on performance.
> >
> > Gerd
> >
> >
> >
> >
> > 
> > Von: mkgmap-dev  im Auftrag von 
> > Ticker Berkin
> > 
> > Gesendet: Mittwoch, 4. Oktober 2023 15:57
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] Gaps in surfaces
> >
> > Hi Gerd
> >
> > I've been thinking about how to stop the small ranges of decimal degrees 
> > from generating
> > MapUnit/delta=+32 and MapUnit+1/delta=-32.
> >
> > Without changing the MapUnit value, but truncating the highPrec calc, eg, 
> > in Coord.java
> >
> > private static int toHighPrec(double degrees) {
> > final double CVT_HP = ((double)(1 << HIGH_PREC_BITS)) / 360;
> > return (int)Math.floor(degrees * CVT_HP);
> > }
> >
> > this problem almost goes away, with deltas between -31 .. +32 except for 2 
> > instances of
> > delta
> > of
> > -32 I get while building the Britain-and-ireland.osm.pbf. I need to work 
> > out why these are
> > happening.
> >
> > Although it is unnatural to have this range rather than -32..+31, it 
> > doesn't matter. It
> > probably
> > could be fixed by using Math.ceil instead or reversing where the delta goes.
> > getAlternativePositions() will generated delta values approx -48..+48.
> >
> > I don't get failures from LineClipperTest with this change.
> > I do get failures from GmapsuppTest, SimpleRouteTest & SortTest, but

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Ticker,

reg. the change in toHighPrec() :  I must confess that I never doubted why 
positive values should be rounded differently to negative values.
This is also done in Utils.toMapUnit() and I just adapted that code. If you 
still want to change that I think Math.rint() would get you closer to the 
original implementation.
Question is if or why this difference in rounding is/was needed. There should 
be visible effects near equator and at Greenwhich or at 180°.

Anyhow, I don't think this is the solution for the gap problem which is caused 
by further conversions from highprec int to double and back.
An alternative solution for that problem would be the attached patch which 
makes use of the coord pool.
No idea which one has more effects on performance.

Gerd





Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 4. Oktober 2023 15:57
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi Gerd

I've been thinking about how to stop the small ranges of decimal degrees from 
generating
MapUnit/delta=+32 and MapUnit+1/delta=-32.

Without changing the MapUnit value, but truncating the highPrec calc, eg, in 
Coord.java

private static int toHighPrec(double degrees) {
final double CVT_HP = ((double)(1 << HIGH_PREC_BITS)) / 360;
return (int)Math.floor(degrees * CVT_HP);
}

this problem almost goes away, with deltas between -31 .. +32 except for 2 
instances of delta of
-32 I get while building the Britain-and-ireland.osm.pbf. I need to work out 
why these are
happening.

Although it is unnatural to have this range rather than -32..+31, it doesn't 
matter. It probably
could be fixed by using Math.ceil instead or reversing where the delta goes.
getAlternativePositions() will generated delta values approx -48..+48.

I don't get failures from LineClipperTest with this change.
I do get failures from GmapsuppTest, SimpleRouteTest & SortTest, but I think 
these are not
significant to this issue.

As far as the gap between areas is concerned, I haven't looked at this yet but 
I'll see if my
change has similar effects to your patch to Coord.

Ticker

On Wed, 2023-10-04 at 08:16 +0000, Gerd Petermann wrote:
> Hi Ticker,
>
> I've uploaded the test case: https://files.mkgmap.org.uk/detail/564
> I had to modify the data a bit since the default style doesn't render 
> natural=heath
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von Gerd 
> Petermann
> 
> Gesendet: Montag, 2. Oktober 2023 16:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Gaps in surfaces
>
> Hi Ticker,
>
> the word overflow might be confusing. The problem is that we want to use only 
> 6 bits for the
> delta, but we store values from -32 .. 32.
> The special case with Michael example is that one coord with such an extreme 
> delta is used
> (after converting to double) in Area.subtract() and the returned coord is 
> converted back but
> get's the other extreme. In the end, only the 24 bit value is written to the 
> map, and that
> causes the gap.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von 
> Ticker Berkin
> 
> Gesendet: Montag, 2. Oktober 2023 15:55
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Gaps in surfaces
>
> Hi Gerd
>
> Considering no_hp-overflow_alpha.patch:
>
> It seems wrong to change a 24bit coordinate. Utils.toMapUnit() is well 
> defined to do the
> expected rounding with the conversion.
>
> The actual deltas are local to Coord.java and, apart from their use by
> getAlternativePositions,
> are just used to get back to the highPrec coord value.
>
> The deltas are stored as byte, so the value of +32 causes no arithmetic 
> problems generally.
>
> getAlternativePositions(), however, should handle any complications with the 
> +32, but it looks
> like it mostly does, bumping up or down the 24bit coord if the abs(deltas) 
> are > 16. It it
> really possible that modLxxDelta can overflow a byte here?
>
> Haven't looked at LineClipperTest yet.
>
> Ticker
>
> On Fri, 2023-09-29 at 06:57 +, Gerd Petermann wrote:
> > Hi all,
> >
> > I've found out that this problem is caused by a flaw in the "high 
> > precision" code. Under
> > special conditions, two points with almost identical coordinates are 
> > internally represented
> > with very different values. There is a possible overflow in the delta 
> > values, the value +32
> > should not occur as it cannot be represented with 6 bits, but the 
> > calculations produce this
> > value.
> > I think I have an ugly fix for this but the resulting map still shows 
> >

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Ticker,

I've uploaded the test case: https://files.mkgmap.org.uk/detail/564
I had to modify the data a bit since the default style doesn't render 
natural=heath

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 2. Oktober 2023 16:58
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi Ticker,

the word overflow might be confusing. The problem is that we want to use only 6 
bits for the delta, but we store values from -32 .. 32.
The special case with Michael example is that one coord with such an extreme 
delta is used (after converting to double) in Area.subtract() and the returned 
coord is converted back but get's the other extreme. In the end, only the 24 
bit value is written to the map, and that causes the gap.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 2. Oktober 2023 15:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi Gerd

Considering no_hp-overflow_alpha.patch:

It seems wrong to change a 24bit coordinate. Utils.toMapUnit() is well defined 
to do the
expected rounding with the conversion.

The actual deltas are local to Coord.java and, apart from their use by 
getAlternativePositions,
are just used to get back to the highPrec coord value.

The deltas are stored as byte, so the value of +32 causes no arithmetic 
problems generally.

getAlternativePositions(), however, should handle any complications with the 
+32, but it looks
like it mostly does, bumping up or down the 24bit coord if the abs(deltas) are 
> 16. It it
really possible that modLxxDelta can overflow a byte here?

Haven't looked at LineClipperTest yet.

Ticker

On Fri, 2023-09-29 at 06:57 +0000, Gerd Petermann wrote:
> Hi all,
>
> I've found out that this problem is caused by a flaw in the "high precision" 
> code. Under
> special conditions, two points with almost identical coordinates are 
> internally represented
> with very different values. There is a possible overflow in the delta values, 
> the value +32
> should not occur as it cannot be represented with 6 bits, but the 
> calculations produce this
> value.
> I think I have an ugly fix for this but the resulting map still shows 
> (smaller) gaps and a
> unit test needs corrections, so there is more to do.
> Attached is a patch that checks for this overflow. Work in progress and maybe 
> causes trouble
> in other areas, e.g. in South America where we have negative lat/lon values.
>
> @Ticker: The unit test für LineClipperTest fails. I am not sure if only the 
> test has to be
> changed (how) or if the code in LineClipper can be improved. I seem to 
> remember that you
> suggested to use
> the code in ShapeSplitter instead.
>

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Ticker,

the word overflow might be confusing. The problem is that we want to use only 6 
bits for the delta, but we store values from -32 .. 32.
The special case with Michael example is that one coord with such an extreme 
delta is used (after converting to double) in Area.subtract() and the returned 
coord is converted back but get's the other extreme. In the end, only the 24 
bit value is written to the map, and that causes the gap.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 2. Oktober 2023 15:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi Gerd

Considering no_hp-overflow_alpha.patch:

It seems wrong to change a 24bit coordinate. Utils.toMapUnit() is well defined 
to do the
expected rounding with the conversion.

The actual deltas are local to Coord.java and, apart from their use by 
getAlternativePositions,
are just used to get back to the highPrec coord value.

The deltas are stored as byte, so the value of +32 causes no arithmetic 
problems generally.

getAlternativePositions(), however, should handle any complications with the 
+32, but it looks
like it mostly does, bumping up or down the 24bit coord if the abs(deltas) are 
> 16. It it
really possible that modLxxDelta can overflow a byte here?

Haven't looked at LineClipperTest yet.

Ticker

On Fri, 2023-09-29 at 06:57 +0000, Gerd Petermann wrote:
> Hi all,
>
> I've found out that this problem is caused by a flaw in the "high precision" 
> code. Under
> special conditions, two points with almost identical coordinates are 
> internally represented
> with very different values. There is a possible overflow in the delta values, 
> the value +32
> should not occur as it cannot be represented with 6 bits, but the 
> calculations produce this
> value.
> I think I have an ugly fix for this but the resulting map still shows 
> (smaller) gaps and a
> unit test needs corrections, so there is more to do.
> Attached is a patch that checks for this overflow. Work in progress and maybe 
> causes trouble
> in other areas, e.g. in South America where we have negative lat/lon values.
>
> @Ticker: The unit test für LineClipperTest fails. I am not sure if only the 
> test has to be
> changed (how) or if the code in LineClipper can be improved. I seem to 
> remember that you
> suggested to use
> the code in ShapeSplitter instead.
>

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Ticker,

no problem, I think this is a very old error ;)
I think the remaining gaps (at res 24) are produced by the MultipolygonCutter. 
It sometimes cuts the outer and produces new points and these new points are 
not added to the inner rings, only to the outer.
I have to find out if this can be fixed by avoiding these cuts or by modifying 
the inner rings.

Gerd



Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Freitag, 29. September 2023 11:03
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi

I was thinking that gaps like this could often happen when adjacent polygons 
share the points
along the common boundary, but, during the various point-removal optimisations, 
esp. Douglas
Peucker, different points along this boundary are chosen to represent the 2 
polygons.

Regarding LineClipperTest, I don't have the facilities to look at this until 
next week.

Ticker

On Fri, 2023-09-29 at 06:57 +, Gerd Petermann wrote:
> Hi all,
>
> I've found out that this problem is caused by a flaw in the "high precision" 
> code. Under
> special conditions, two points with almost identical coordinates are 
> internally represented
> with very different values. There is a possible overflow in the delta values, 
> the value +32
> should not occur as it cannot be represented with 6 bits, but the 
> calculations produce this
> value.
> I think I have an ugly fix for this but the resulting map still shows 
> (smaller) gaps and a
> unit test needs corrections, so there is more to do.
> Attached is a patch that checks for this overflow. Work in progress and maybe 
> causes trouble
> in other areas, e.g. in South America where we have negative lat/lon values.
>
> @Ticker: The unit test für LineClipperTest fails. I am not sure if only the 
> test has to be
> changed (how) or if the code in LineClipper can be improved. I seem to 
> remember that you
> suggested to use
> the code in ShapeSplitter instead.
>
> 
> Von: mkgmap-dev  im Auftrag von Gerd 
> Petermann
> 
> Gesendet: Dienstag, 26. September 2023 19:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Gaps in surfaces
>
> Hi Michael,
>
> okay, I can reproduce the problem. I assume it is caused by the code which 
> subtracts the inner
> area from the multipolygon area.
> No idea if this can be fixed easily.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von 
> Forstner Michael
> 
> Gesendet: Dienstag, 26. September 2023 19:44
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] Gaps in surfaces
>
> Hello Gerd,
>
> here is the area: https://www.openstreetmap.org/#map=19/48.57117/13.96920 I
> understand that it is necessary to make rounding. If a point of two surfaces
> is equal in OSM, the point should also be equal in Garmin.
>
> Thank you!
>
> Best regards,
> Michael
>
>
> ___
> 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

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi all,

I've found out that this problem is caused by a flaw in the "high precision" 
code. Under special conditions, two points with almost identical coordinates 
are internally represented
with very different values. There is a possible overflow in the delta values, 
the value +32 should not occur as it cannot be represented with 6 bits, but the 
calculations produce this value.
I think I have an ugly fix for this but the resulting map still shows (smaller) 
gaps and a unit test needs corrections, so there is more to do.
Attached is a patch that checks for this overflow. Work in progress and maybe 
causes trouble in other areas, e.g. in South America where we have negative 
lat/lon values.

@Ticker: The unit test für LineClipperTest fails. I am not sure if only the 
test has to be changed (how) or if the code in LineClipper can be improved. I 
seem to remember that you suggested to use
the code in ShapeSplitter instead.


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Dienstag, 26. September 2023 19:58
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hi Michael,

okay, I can reproduce the problem. I assume it is caused by the code which 
subtracts the inner area from the multipolygon area.
No idea if this can be fixed easily.

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Dienstag, 26. September 2023 19:44
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hello Gerd,

here is the area: https://www.openstreetmap.org/#map=19/48.57117/13.96920 I
understand that it is necessary to make rounding. If a point of two surfaces
is equal in OSM, the point should also be equal in Garmin.

Thank you!

Best regards,
Michael


___
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
Index: src/uk/me/parabola/imgfmt/app/Coord.java
===
--- src/uk/me/parabola/imgfmt/app/Coord.java(revision 4912)
+++ src/uk/me/parabola/imgfmt/app/Coord.java(working copy)
@@ -56,6 +56,7 @@
private static final int HIGH_PREC_BITS = 30;
public static final int DELTA_SHIFT = HIGH_PREC_BITS - 24; 
private static final int MAX_DELTA = 1 << (DELTA_SHIFT - 2); // max 
delta abs value that is considered okay
+   private static final int HIGH_DELTA = 1 << (DELTA_SHIFT - 1); // 
positive delta that doesn't fit into 6 bits
private static final long FACTOR_HP = 1L << HIGH_PREC_BITS;
private static final int HIGH_PREC_UNUSED_BITS = Integer.SIZE - 
HIGH_PREC_BITS;

@@ -83,24 +84,39 @@
}
 
/**
-* Construct from regular latitude and longitude.
+* Construct from regular latitude and longitude given in degrees.
 * @param latitude The latitude in degrees.
 * @param longitude The longitude in degrees.
 */
public Coord(double latitude, double longitude) {
-   this.latitude = Utils.toMapUnit(latitude);
-   this.longitude = Utils.toMapUnit(longitude);
+   int lat24 = Utils.toMapUnit(latitude);
+   int lon24 = Utils.toMapUnit(longitude);
int latHighPrec = toHighPrec(latitude);
int lonHighPrec = toHighPrec(longitude);
-   this.latDelta = (byte) ((this.latitude << DELTA_SHIFT) - 
latHighPrec); 
-   this.lonDelta = (byte) ((this.longitude << DELTA_SHIFT) - 
lonHighPrec);
-
+   byte dLat = (byte) ((lat24 << DELTA_SHIFT) - latHighPrec);
+   byte dLon = (byte) ((lon24 << DELTA_SHIFT) - lonHighPrec);
+   
+   // correct possible overflow in delta value 
+   if (dLat == HIGH_DELTA) {
+   dLat = -HIGH_DELTA;
+   lat24--;
+   }
+   if (dLon == HIGH_DELTA) {
+   dLon = -HIGH_DELTA;
+   lon24--;
+   }
+   
+   this.latitude = lat24;
+   this.longitude = lon24;
+   this.latDelta = dLat;
+   this.lonDelta = dLon;
+   
// verify math
assert (this.latitude << DELTA_SHIFT) - (int) latDelta == 
latHighPrec;
assert (this.longitude << DELTA_SHIFT) - (int) lonDelta == 
lonHighPrec;
}

-   private Coord (int lat, int lon, byte latDelta, byte lonDelta){
+   private Coord(int lat, int lon, byte latDelta, byte lonDelta) {
this.latitude = lat;
this.longitude = 

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Michael,

okay, I can reproduce the problem. I assume it is caused by the code which 
subtracts the inner area from the multipolygon area.
No idea if this can be fixed easily.

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Dienstag, 26. September 2023 19:44
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Gaps in surfaces

Hello Gerd,

here is the area: https://www.openstreetmap.org/#map=19/48.57117/13.96920 I
understand that it is necessary to make rounding. If a point of two surfaces
is equal in OSM, the point should also be equal in Garmin.

Thank you!

Best regards,
Michael


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with address search

[Gerd Petermann]

Hi Michael,

I think if you don't enter a housenumber Garmin shows only n Objects near the 
middle of the screen. I think you can increase the number in the options.

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Samstag, 23. September 2023 15:38
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev]  Problem with address search

Hello,

not all buildings are found during the search. I used the address Gräfinghausen 
10 as an example. You cannot find this address in the list on the right side. 
It could be that my style files have a problem. Maybe someone could try to see 
if the same error occurs with their style.

Thank you!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Gaps in surfaces

[Gerd Petermann]

Hi Michael,

the Garmin format always requires rounding. Please share a link to one of the 
OSM objects, so that I can have a closer look.

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Donnerstag, 14. September 2023 12:20
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] Gaps in surfaces

Hello,

in some areas, gaps may appear (see attachment). In OSM, however, the surfaces 
are connected and the nodes have the same coordinates. There should be no 
rounding errors. It will therefore be a bug in mkgmap. I ask for correction.

Thank you!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

I see. It probably works where roads have nearby houses with addresses since 
you always assign a road label in that case with your version of code in 
HousenumberRoad.java
Try without --housenumbers and you'll see different results.
In some cases highways have different addr:place along the road, maybe even on 
the left and right side. The displayed name is probably unpredictable in that 
case
and possibly wrong for many numbers.
Try e.g. the area around https://www.osm.org/way/495902638
(I am not sure if the road name "Visbeker Straße" is correct there, I have to 
verify that, but addresses for Holzhausen and Thölstedt are surveyed)
So I think it's a very special solution for a minor problem and not always 
working, right?

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Samstag, 23. September 2023 10:44
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

It is unclear to me what BaseCamp is doing. In any case, the street names
are there...

-Ursprüngliche Nachricht-
Von: mkgmap-dev  Im Auftrag von Gerd
Petermann
Gesendet: Samstag, 23. September 2023 10:09
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] House numbers

Hi Michael,

I guess that means that you see no street names in the routing directions
even when roads have names?
(In German it's the tab Wegbeschreibung für Routen) when you open a route.

Gerd


Von: mkgmap-dev  im Auftrag von
Forstner Michael 
Gesendet: Samstag, 23. September 2023 09:43
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

in my map I basically have two line levels. The first lines are used to
display streets, paths, etc. with names. But you cannot navigate here. The
second level is invisible and is used for navigation. No street names are
used here. Therefore, the patch is used to name the streets in the invisible
level after the houses. The address will then be displayed correctly in
BaseCamp.

Thank you!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

I guess that means that you see no street names in the routing directions even 
when roads have names?
(In German it's the tab Wegbeschreibung für Routen) when you open a route.

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Samstag, 23. September 2023 09:43
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

in my map I basically have two line levels. The first lines are used to
display streets, paths, etc. with names. But you cannot navigate here. The
second level is invisible and is used for navigation. No street names are
used here. Therefore, the patch is used to name the streets in the invisible
level after the houses. The address will then be displayed correctly in
BaseCamp.

Thank you!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

please post a patch so that we can verify whether your change is of general use.
Regarding the address search problem:
Yes, please start a new thread and try to upload a complete combination of test 
data, options and style so that we can reproduce the poblem
to https://files.mkgmap.org.uk/

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Donnerstag, 21. September 2023 19:08
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

I have now adapted the code. The results can be seen in the image in the
attachment. It performs exactly what I wanted. The question is whether to
make a release.

But I found another problem in the search. Not all addresses are displayed.
Should I open an own ticket here?

Thank you!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

a road can have up to 4 labels, in your case the first label is an empty string 
and the second label is the name of the place.
In the Garmin IMG format the housenumbers are stored as intervals along road 
segments. Typical roads in Germany have odd numbers on one side and even 
numbers on the other.
Such information is stored with the road data so that Garmin software can 
interpolate the position of e.g number 6 or 17 in such a road.
With addr:place numbers there is typically no such order, numbers often appear 
to be random. Therefore mkgmap often places an interval with equal start and 
end number at the position of the
addr:place node.

Reg. your problem: Basecmp displays (only) the first label, this is the empty 
string.

I've not compiled the suggested patch sofar because I've learned that mgkmap 
often adds unexpected labels to unnamed roads. This is done to handle unnamed 
service roads but also happens for other unnamed roads. I've got to find out 
how to improve that, as it really sometimes produces wrong results when you 
search for addresses.

BTW: When you search for an address with an addr:place with the address search, 
Basecamp displays a list of hits. If you click on that list Basecamp shows the 
target with the place name. I think that's what you want?

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Sonntag, 17. September 2023 15:24
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

I can try contacting Garmin but that will not be easy. But what I need to
know beforehand is why only the house number is displayed in BaseCamp and on
the Garmin devices. This has to be put on the road by mkgmap. Can you
explain that better.
Have you already compiled the new source code? Where can I download this?

Thank you!

Best regards,
Michael

-Ursprüngliche Nachricht-
Von: mkgmap-dev  Im Auftrag von Gerd
Petermann
Gesendet: Sonntag, 17. September 2023 15:03
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] House numbers

Hi Micheal,

I've no idea how to force the rendering of further labels in Basecamp. Maybe
you can ask Garmin why they don't display the other labels?
There might even be a special label to force that, but I have no idea what
that would be.

Another altervative could be that there is a special character which could
be added to the 1st label so that it is not rendered on the map but shown
with the address info.

The question is if Garmin will tell us such a trick...

Gerd


Von: mkgmap-dev  im Auftrag von
Forstner Michael 
Gesendet: Sonntag, 17. September 2023 14:45
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello,

however, with the current implementation we have the problem that the street
name only gets the house number (see attachment). From my point of view,
that is not okay. BaseCamp simply needs a street name to display this
correctly. In OSM, the street names can remain unchanged or unnamed.

Thank you!

Best regards,
Michael

-Ursprüngliche Nachricht-
Von: mkgmap-dev  Im Auftrag von 7770
Gesendet: Sonntag, 17. September 2023 14:34
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] House numbers

Hi.
I have misunderstood.
What i really wanted to say is that i dont think a change is needed.
If there is no roadname, there is none.
Searching for an address with help of the place name (entered as a street
name on garmin device) + the number will find the correct location anyway.

Regards
Karl

On söndag 17 september 2023 13:51:14 CEST Gerd Petermann wrote:
> Hi Karl,
>
> does that also mean you would also want to render the place name on
> all the unnamed roads which have a nearby addr:place address?
>
> In my area there are lots of small places and someone mapped them
> using addr:street= and also name= on various
> roads. I found that very irritating since I knew that these roads
> don't
have names.
> It took a lot of time to change the tagging to addr:place and remove
> the wrong road names since I had to visit all of them to make sure
> that there really was no sign stating the name. I can't think of any
> reason to display a wrong road name. What am I missing here?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von 7770 <7...@foskan.eu> Gesendet: Sonntag, 17. September 2023 09:46
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] House numbers
>
> Hi.
>
> I tend to agree with Michel.
> I can only look to Sweden and Poland where small locations have a name
> of the place (addr:place), no streets/roads names but all houses on
> all those streets have different numbers related to that place, rather
> than the normal relation to a street/road.
>
> Regards
> Karl
>
> On söndag 17 september 2023 09:15:21 CES

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Micheal,

I've no idea how to force the rendering of further labels in Basecamp. Maybe 
you can ask Garmin why they don't display the other labels?
There might even be a special label to force that, but I have no idea what that 
would be.

Another altervative could be that there is a special character which could be 
added to the 1st label so that it is not rendered on the map but shown with the 
address info.

The question is if Garmin will tell us such a trick...

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Sonntag, 17. September 2023 14:45
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello,

however, with the current implementation we have the problem that the street
name only gets the house number (see attachment). From my point of view,
that is not okay. BaseCamp simply needs a street name to display this
correctly. In OSM, the street names can remain unchanged or unnamed.

Thank you!

Best regards,
Michael

-Ursprüngliche Nachricht-
Von: mkgmap-dev  Im Auftrag von 7770
Gesendet: Sonntag, 17. September 2023 14:34
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] House numbers

Hi.
I have misunderstood.
What i really wanted to say is that i dont think a change is needed.
If there is no roadname, there is none.
Searching for an address with help of the place name (entered as a street
name on garmin device) + the number will find the correct location anyway.

Regards
Karl

On söndag 17 september 2023 13:51:14 CEST Gerd Petermann wrote:
> Hi Karl,
>
> does that also mean you would also want to render the place name on
> all the unnamed roads which have a nearby addr:place address?
>
> In my area there are lots of small places and someone mapped them
> using addr:street= and also name= on various
> roads. I found that very irritating since I knew that these roads don't
have names.
> It took a lot of time to change the tagging to addr:place and remove
> the wrong road names since I had to visit all of them to make sure
> that there really was no sign stating the name. I can't think of any
> reason to display a wrong road name. What am I missing here?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von 7770 <7...@foskan.eu> Gesendet: Sonntag, 17. September 2023 09:46
> An: 'Development list for mkgmap'
> Betreff: Re: [mkgmap-dev] House numbers
>
> Hi.
>
> I tend to agree with Michel.
> I can only look to Sweden and Poland where small locations have a name
> of the place (addr:place), no streets/roads names but all houses on
> all those streets have different numbers related to that place, rather
> than the normal relation to a street/road.
>
> Regards
> Karl
>
> On söndag 17 september 2023 09:15:21 CEST Forstner Michael wrote:
> > Hello Gerd,
> >
> > I hope that you in OSM do not remove the street names when there are
> > houses with addr:street nearby. That would be wrong. With addr:place
> > the streets should not have a name.
> >
> > I thought the process was not that easy. Changing the logic could
> > solve the problem. But maybe it has other side effects and so we
> > should try it. Have you perhaps already compiled the change?
> >
> > Thank you!
> >
> > Best regards
> > Michael
> >
> >
> > ___
> > 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




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Karl,

does that also mean you would also want to render the place name on all the 
unnamed roads which have a nearby addr:place address?

In my area there are lots of small places and someone mapped them using 
addr:street= and also name= on various roads. I found 
that very irritating since I knew that these roads don't have names. It took a 
lot of time to change the tagging to addr:place and remove the wrong road names 
since I had to visit all of them to make sure that there really was no sign 
stating the name.
I can't think of any reason to display a wrong road name. What am I missing 
here?

Gerd


Von: mkgmap-dev  im Auftrag von 7770 
<7...@foskan.eu>
Gesendet: Sonntag, 17. September 2023 09:46
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hi.

I tend to agree with Michel.
I can only look to Sweden and Poland where small locations have a name of the
place (addr:place), no streets/roads names but all houses on all those streets
have different numbers related to that place, rather than the normal relation
to a street/road.

Regards
Karl


On söndag 17 september 2023 09:15:21 CEST Forstner Michael wrote:
> Hello Gerd,
>
> I hope that you in OSM do not remove the street names when there are houses
> with addr:street nearby. That would be wrong. With addr:place the streets
> should not have a name.
>
> I thought the process was not that easy. Changing the logic could solve the
> problem. But maybe it has other side effects and so we should try it. Have
> you perhaps already compiled the change?
>
> Thank you!
>
> Best regards
> Michael
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

I think it would be possible to change the code in mkgmap, but it would be 
difficult. I still don't see any good reason to display an unnamed road with a 
name. In fact, I've invested a lot of time in my area to fix OSM data where 
mappers decided to name roads after the adddress of nearby houses.

Why would it be difficult to implement this?
The current implementation adds the label after the style rules were processed, 
so the style decides what ways are routable and what labels are added to them. 
The code tries to avoid adding address data to footways or cycleways.
You suggest to parse the data first, check every possible line with highway=*, 
but at that stage mkgmap doesn't know if the style will add a routable line for 
that road.

It would be much easier to change the logic which adds a label for the 
addr:place numbers. The code is in HousenumberRoad.java and
it looks like this
if (!found){
if (labels[0] == null){
// add empty label so that the address search 
name doesn't appear in the map
// when the original road did not have any label
labels[0] = "";
}
for (int i = 1; i < labels.length; i++){
if (labels[i] == null){
labels[i] = streetName;
log.info("added 
label",streetName,"for",road,"Labels are now:",Arrays.toString(labels));
found = true;
break;
}
}
}

So, if you really want to display wrong road names you just have to remove the 
block which adds an empty label and change the for loop to start with 0 instead 
of 1.

I would add an option to do that if you or someone else can convince me that 
this is a good idea. I think it would be plain wrong and very confusing.

ciao,
Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Donnerstag, 14. September 2023 12:08
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

I tried the system with POI and it works now. But this is just a workaround,
which should not actually be necessary.
Is it really not possible to name unnamed streets after an addr:place
beforehand and then let the further process go through. OSM's work is then
taken over when a street name is taken over by a nearby building with
addr:place.
I think a similar command is necessary: set mkgmap:label:1='${addr:place}'
But it is unclear to me where this should be applied. I do not want to dig
around too much in the source code. You will probably know a lot better
about the source code.

Thank you!

Best regards
Michael


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

the difference is visible when you click on a POI to see its property. Is has 
no effect on the road names.
The news text might be confusing. It works as designed because address search 
works for addr:place, and yes, it adds the name to road, but you have to 
understand that the Garmin format allows up to four names (labels) for one 
road. All four can be used for the address search, but Basecamp only renders 
the first name. The logic for addr:place doesn't set the first label, it sets 
the 2nd, so that address search works and
and the road is still correctly displayed as nameless.
Attached screen shots show the POI generated for 
https://www.osm.org/way/690060365
when --add-pois-to-areas is used and my additional rules 
addr:housenumber=* & addr:street=* { name '${addr:housenumber} ${name}' | 
'${addr:housenumber}' }[0x3200 resolution 24]
addr:housenumber=* & addr:street!=* & addr:place=* { name 
'pl-${addr:housenumber}' }[0x3200 resolution 24]  
are added in the points file right after(!) the line
addr:housenumber=* {set mkgmap:execute_finalize_rules=true} 

I hope it's clear now?

Gerd

Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Sonntag, 10. September 2023 10:38
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

I have now tried the POI with and without a patch. Attached are screenshots
from BaseCamp. I cannot notice a difference. Maybe the patch will do
something else. Do you have an explanation for this?

I found some news on your website (see attachment). The highlighted area
should do exactly what I would like. An unnamed street should be named if
there is a house nearby that has addr:place. However, this does not happen.
Has the function been removed? This does not need to be done with
addr:street because there has to be a named street there anyway.
The option --housenumbers is activated.

Thank you!

Best regards
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

the patch changes the displayed data for a POI that doesn't have mkgmap:street 
set but addr:place.
It has no effect on the road data and I don't see a good solution for that 
unless you really want to use the value from addr:place
nodes to set the 1st label of the road.

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Samstag, 9. September 2023 20:52
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

apologies for the late reply. I tried the patch you made. But I do not see
any difference in BaseCamp. Can you please explain in more detail what
should change in BaseCamp?

Thank you!

Best regards
Michael

-Ursprüngliche Nachricht-
Von: mkgmap-dev  Im Auftrag von Gerd
Petermann
Gesendet: Montag, 4. September 2023 14:47
An: Development list for mkgmap 
Betreff: Re: [mkgmap-dev] House numbers

Hi Michael,

see here for the binary: https://files.mkgmap.org.uk/detail/562

I use the following rules in points in the style that I use when I cycle for
mapping:
addr:housenumber=* & addr:street=* { name '${addr:housenumber} ${name}' |
'${addr:housenumber}' }[0x3200 resolution 24]
addr:housenumber=* & addr:street!=* & addr:place=* { name
'pl-${addr:housenumber}' }[0x3200 resolution 24]

Helps me to find unmapped addresses.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd
Petermann 
Gesendet: Montag, 4. September 2023 13:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hi Michael,

the patch would not change this and I found no way to tell Basecamp to show
the 2nd-4th labels of the road where filled. Other software does that.
The problem is that the IMG data format connects the address infomation to
the road. So, either mkgmap could calculate a likely name using the nearby
addr:place values (it does that already) and add the name as 1st label
instead of 2nd-4th or you may render the nodes with the house numbers as
POI. Only for this alternative the patch helps to fill the street field of
the POI with the addr:place value if mkgmap:street is empty.
I can compile an mkgmap.jar for you if you want to try that.

Gerd


Von: mkgmap-dev  im Auftrag von
Michael Forstner 
Gesendet: Montag, 4. September 2023 11:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

I am not sure what to do with the hack from the attachment. Can you help me
here.

I would like to make the problem even clearer. I hope you can see the
pictures. In the first picture you can see the address with addr:street.
Everything is displayed correctly here.

The second picture shows addr:place. The window here is weird. The name of
the village is missing here. It is unusual that only the house number is
displayed.

I have tried the following settings with no success:

mkgmap:street!=* & addr:place=* { set mkgmap:street='${addr:place}' }
-> With this the search function will be destroyed. This seems to confuse
the software.

mkgmap:place!=* & addr:place=* { set mkgmap:place='${addr:place}' }
-> This also has no function because mkgmap:place does not seem to be used.

# mkgmap:street!=* & addr:street=* { set mkgmap:street='${addr:street}' } #
mkgmap:street!=* & addr:housename=* { set mkgmap:street='${addr:housename}'
} # mkgmap:housenumber!=* & addr:housenumber=* { set
mkgmap:housenumber='${addr:housenumber}' }
-> Everything is commented out here. But I get the same results as shown in
the pictures. It seems as if the evaluation for addr:street and addr:place
are hardcoded.

Do you maybe have a solution for this? Thank you!

Best regards
Michael

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

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

Steve has fixed the problem, please try again.

ciao
Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 4. September 2023 19:19
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hi Michael,

I tried again but the same error message is displayed. I'll try to contact 
Steve Ratcliffe...

Gerd


Von: mkgmap-dev  im Auftrag von Michael 
Forstner 
Gesendet: Montag, 4. September 2023 18:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

sorry but the link is broken: 
https://files.mkgmap.org.uk/download/562/mkgmap.jar

Please upload the file agin.

Thanks!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

I tried again but the same error message is displayed. I'll try to contact 
Steve Ratcliffe...

Gerd


Von: mkgmap-dev  im Auftrag von Michael 
Forstner 
Gesendet: Montag, 4. September 2023 18:55
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

sorry but the link is broken: 
https://files.mkgmap.org.uk/download/562/mkgmap.jar

Please upload the file agin.

Thanks!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

see here for the binary: https://files.mkgmap.org.uk/detail/562

I use the following rules in points in the style that I use when I cycle for 
mapping:
addr:housenumber=* & addr:street=* { name '${addr:housenumber} ${name}' | 
'${addr:housenumber}' }[0x3200 resolution 24]
addr:housenumber=* & addr:street!=* & addr:place=* { name 
'pl-${addr:housenumber}' }[0x3200 resolution 24]

Helps me to find unmapped addresses.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 4. September 2023 13:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hi Michael,

the patch would not change this and I found no way to tell Basecamp to show the 
2nd-4th labels of the road where filled. Other software does that.
The problem is that the IMG data format connects the address infomation to the 
road. So, either mkgmap could calculate a likely name using the nearby 
addr:place values (it does that already) and add the name as 1st label instead 
of 2nd-4th or you may render the nodes with the house numbers as POI. Only for 
this alternative the patch helps to fill the street field of the POI with the 
addr:place value if mkgmap:street is empty.
I can compile an mkgmap.jar for you if you want to try that.

Gerd


Von: mkgmap-dev  im Auftrag von Michael 
Forstner 
Gesendet: Montag, 4. September 2023 11:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

I am not sure what to do with the hack from the attachment. Can you help me 
here.

I would like to make the problem even clearer. I hope you can see the pictures. 
In the first picture you can see the address with addr:street. Everything is 
displayed correctly here.

The second picture shows addr:place. The window here is weird. The name of the 
village is missing here. It is unusual that only the house number is displayed.

I have tried the following settings with no success:

mkgmap:street!=* & addr:place=* { set mkgmap:street='${addr:place}' }
-> With this the search function will be destroyed. This seems to confuse the 
software.

mkgmap:place!=* & addr:place=* { set mkgmap:place='${addr:place}' }
-> This also has no function because mkgmap:place does not seem to be used.

# mkgmap:street!=* & addr:street=* { set mkgmap:street='${addr:street}' }
# mkgmap:street!=* & addr:housename=* { set mkgmap:street='${addr:housename}' }
# mkgmap:housenumber!=* & addr:housenumber=* { set 
mkgmap:housenumber='${addr:housenumber}' }
-> Everything is commented out here. But I get the same results as shown in the 
pictures. It seems as if the evaluation for addr:street and addr:place are 
hardcoded.

Do you maybe have a solution for this? Thank you!

Best regards
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

the patch would not change this and I found no way to tell Basecamp to show the 
2nd-4th labels of the road where filled. Other software does that.
The problem is that the IMG data format connects the address infomation to the 
road. So, either mkgmap could calculate a likely name using the nearby 
addr:place values (it does that already) and add the name as 1st label instead 
of 2nd-4th or you may render the nodes with the house numbers as POI. Only for 
this alternative the patch helps to fill the street field of the POI with the 
addr:place value if mkgmap:street is empty.
I can compile an mkgmap.jar for you if you want to try that.

Gerd


Von: mkgmap-dev  im Auftrag von Michael 
Forstner 
Gesendet: Montag, 4. September 2023 11:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

I am not sure what to do with the hack from the attachment. Can you help me 
here.

I would like to make the problem even clearer. I hope you can see the pictures. 
In the first picture you can see the address with addr:street. Everything is 
displayed correctly here.

The second picture shows addr:place. The window here is weird. The name of the 
village is missing here. It is unusual that only the house number is displayed.

I have tried the following settings with no success:

mkgmap:street!=* & addr:place=* { set mkgmap:street='${addr:place}' }
-> With this the search function will be destroyed. This seems to confuse the 
software.

mkgmap:place!=* & addr:place=* { set mkgmap:place='${addr:place}' }
-> This also has no function because mkgmap:place does not seem to be used.

# mkgmap:street!=* & addr:street=* { set mkgmap:street='${addr:street}' }
# mkgmap:street!=* & addr:housename=* { set mkgmap:street='${addr:housename}' }
# mkgmap:housenumber!=* & addr:housenumber=* { set 
mkgmap:housenumber='${addr:housenumber}' }
-> Everything is commented out here. But I get the same results as shown in the 
pictures. It seems as if the evaluation for addr:street and addr:place are 
hardcoded.

Do you maybe have a solution for this? Thank you!

Best regards
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

I am not sure if I understand what you are trying to achive. Do you think the 
map should
show the name of the place as the name of the road? That would be very 
misleading when that
name is not signed anywhere, also sometimes difficult where the road is used to 
reach different
addr:place addresses (e.g. one the left and right side)
Or do you want to see the name of the place (or the full address) when you 
click on a building?
This can be done, maybe with an additional patch like the attached (which is 
just a quick hack)
and seems to be a good idea, maybe with a new tag mkgmap:place.
Your idea with
{ set mkgmap:street='${addr:place}' }
is more or less doing the same but might confuse the code that calculates the 
data for the address
search.

I think the important thing is that you can find the address in Basecamp with 
the address search.
I don't know why Basecamp doesn't show the other labels of the road, I think my 
Oregon does.

Gerd



Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Samstag, 2. September 2023 22:36
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] House numbers

Hello Gerd,

the behaviour is to be expected that only the house number is displayed for
the street if the street has no name. But this behaviour is not nice. Is
there a setting or command to bypass this? Anyway, what does not work is
this:
mkgmap:street!=* & addr:place=* { set mkgmap:street='${addr:place}' }

The problem are the rules of OSM. Streets may not be named outside of a
town. If there is a house here, it can only be named with addr:place instead
of addr:street.

Thanks!

Best regards,
Michael


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java
===
--- src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (revision 4909)
+++ src/uk/me/parabola/mkgmap/osmstyle/StyledConverter.java (working copy)
@@ -1381,7 +1381,10 @@
  
if(zip != null)
ms.setZip(zip);
- 
+
+   if (street == null)  
+   street = element.getTag("addr:place");
+   
if(street != null)
ms.setStreet(street);
 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] House numbers

[Gerd Petermann]

Hi Michael,

the expected behaviour is that mkgmap adds the name from addr:place as the 2nd 
label of the road. The first label should be empty (because the road has no 
name).

Does that anwer your question?

Gerd


Von: mkgmap-dev  im Auftrag von 
Forstner Michael 
Gesendet: Samstag, 2. September 2023 20:41
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] House numbers

Hello,

basically, the address search in BaseCamp works. But there is only a problem 
with street names if I click on a street. Often only the house number is 
displayed here.

There are the following cases:
1. addr:street is defined for a building. When using this parameter, the 
highway in the near must have the same name as addr:street. If I click on a 
highway in BaseCamp this will be shown: addr:street addr:housenumber. This 
works beautifully.

2. However, when using addr:place on a building, there is usually no nearby 
highway with the same name. Then only addr:housenumber is displayed for the 
highway. This is not correct.

There are the following settings:
mkgmap:street!=* & addr:street=* { set mkgmap:street='${addr:street}' }
mkgmap:housenumber!=* & addr:housenumber=* { set 
mkgmap:housenumber='${addr:housenumber}' }

Is this a bug or I am doing something wrong?

I ask for support! Thank you!

Best regards,
Michael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] IndexOutOfBoundsException

[Gerd Petermann]

Hi Thomas,

the error occurs while reading one of the *.o5m files. The message doesn't say 
which one, but maybe you can
find out looking at the *.img files which were written.

Maybe splitter crashed while writing the output files and you didn't notice?

Gerd


Von: mkgmap-dev  im Auftrag von 
tomtom9309 
Gesendet: Dienstag, 8. August 2023 13:39
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] IndexOutOfBoundsException

Hi all,

i am trying to import an osm europe map into Garmins Basecamp.

I downloaded the europe-latest.osm.pbf from Geofabrik. Then i used the
splitter with the following command.

``` java -Xmx20g -jar splitter-r653/splitter.jar --output=o5m
--max-areas=4096 europe-latest.osm.pbf ```

It finished after writing a series of 2105 .o5m files. By creating the
gmapi directory with the following command, i got an Index Out of Bounds
Exception.

``` java -Xmx20g -jar mkgmap-r4910/mkgmap.jar --index --improve-overview
--gmapi -c template.args ```

Here the Stack trace:



Mkgmap version 4910
Time started: Tue Aug 08 12:39:45 CEST 2023
WARNING (global): Setting max-jobs to 20
SEVERE (global): Unexpected error
java.lang.IndexOutOfBoundsException
 at
java.base/java.io.BufferedInputStream.implRead(BufferedInputStream.java:375)
 at
java.base/java.io.BufferedInputStream.read(BufferedInputStream.java:361)
 at
uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.readFile(O5mBinHandler.java:148)
 at
uk.me.parabola.mkgmap.reader.osm.o5m.O5mBinHandler.parse(O5mBinHandler.java:116)
 at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.parse(OsmMapDataSource.java:167)
 at
uk.me.parabola.mkgmap.reader.osm.OsmMapDataSource.load(OsmMapDataSource.java:142)
 at
uk.me.parabola.mkgmap.main.MapMaker.loadFromFile(MapMaker.java:165)
 at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:58)
 at
uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:291)
 at
java.base/java.util.concurrent.FutureTask.run(FutureTask.java:317)
 at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:513)
 at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
 at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:147)
 at uk.me.parabola.mkgmap.main.Main.main(Main.java:118)
SEVERE (global): Exiting due to unexpected error
Number of ExitExceptions: 1
Time finished: Tue Aug 08 12:39:47 CEST 2023
Total time taken: 1 second

```

I assume the problem occures because of the huge template.args file
(~6000 lines), but i'm not that much into java to deterrmine the exact
cause. Any ideas?

Cheers,

Thomas


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Garmin Tread img file issues with Place icons

[Gerd Petermann]

Hi Joao,

mkgmap can create a map with all (?) possible POI. See 
https://wiki.openstreetmap.org/wiki/DE:Mkgmap/help/usage#Test_map
Maybe this helps to find out what you need.

Gerd



Von: mkgmap-dev  im Auftrag von Joao 
Almeida 
Gesendet: Samstag, 5. August 2023 23:35
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Garmin Tread img file issues with Place icons

On 5/08/2023 12:53 am, osm wrote:
> Garmin default customizable pois

Thank you Nick, do you have a list of the "default garmin" Customizable
pois?

I'm struggling to find info because POIS normally refer to Map points
added manually as additional points on the map. While what I'm looking
for is the actual map points added during compilation from OSM.

Cheers
Joao

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Rounding off population

[Gerd Petermann]

Hi Nick,

sorry for the late response.
I think this problem can and should be solved in the style. If you want to 
tolerate wrong values like this you can use a rule like
population=* {set population='${population|subst:,=>}'}
to remove the comma before before evaluating it further in other rules.

ciao,
Gerd


Von: mkgmap-dev  im Auftrag von osm 

Gesendet: Donnerstag, 15. Juni 2023 08:13
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Rounding off population

Hi

I  have a feeling mkgmap rounds off population when a comma has been
inserted thinking it is a 'continental decimal comma'

In my style I have

place=village & population < 30 {set place=hamlet;echotags "village to
hamlet"}

The following place node gets flagged up as it has been given a
population of 1

https://www.openstreetmap.org/node/271408#map=18/50.82664/-1.70104

When I look at the osm tags it contains:

population:1,350

Perhaps we should not round off population data?

Just a thought.

Nick

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Trouble with merging IMG files (for Garmin)

[Gerd Petermann]

Hi all,

OK, seems I was wrong. Felix Herwegh contacted me in a private mail and he has 
an example where mkgmap is able to merge two gmapsupp.img files. With his 
examples mkgmap just writes some warnings about duplicated files:
WARNUNG (global): Could not copy MAKEGMAP.MPS 
uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists
WARNUNG (global): Could not copy MAKEGMAP.MPS 
uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists
WARNUNG (global): Could not copy SAMEORDE.TYP 
uk.me.parabola.imgfmt.FileExistsException: File SAMEORDE.TYP already exists

So, yes, there is code to read the content of a gmapsupp and copy it to the 
output gmapsupp, but this code only seems to work well when the last file in 
the input gmapsupp is the special file MAKEMAP.MPS
I am not sure if this is wanted or just a flaw in the implementation. I am also 
not sure how well the result really works, and there are also other problems, 
e.g. the option --index doesn't work.
The code was added in 2009 with r1443: 
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=1443

Attached quick hack shows that it is very easy to change the code in mkgmap to 
be more tolerant regarding the oder of the files within the gmapsupp, but I 
have no idea about the restrictions that apply and how to handle the case that 
the input gmapsupp files contain equally named TYP files with different content 
or indexes etc.

So, not sure what to do here. Looks like a can of worms...

Gerd




Von: Gerd Petermann 
Gesendet: Donnerstag, 13. Juli 2023 22:41
An: Development list for mkgmap
Betreff: AW: [mkgmap-dev] Trouble with merging IMG files (for Garmin)

What you try is not implement.
You simply have to understand that mkgmap cannot read data in gmapsupp format. 
All the mentioned files are in gmapsupp format.
So, either use a different tool or maybe split the gmapsupp files first, e.g. 
with gmaptool.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Donnerstag, 13. Juli 2023 22:19
An: Tamas Gal
Cc: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Trouble with merging IMG files (for Garmin)

Hi,

> so I tried combining [opentopomap] Hungary and Slovenia but then I get again 
> a small 2.5KB file

Same here. My test were on simple maps without routing and DEM only; maybe its 
that. Sorry.

//Felix
Index: src/uk/me/parabola/mkgmap/combiners/FileInfo.java
===
--- src/uk/me/parabola/mkgmap/combiners/FileInfo.java   (revision 4909)
+++ src/uk/me/parabola/mkgmap/combiners/FileInfo.java   (working copy)
@@ -355,7 +355,8 @@
}
 
protected void setKind(FileKind kind) {
-   this.kind = kind;
+   if (this.kind != GMAPSUPP_KIND)
+   this.kind = kind;
}
 
public FileKind getKind() {
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Trouble with merging IMG files (for Garmin)

[Gerd Petermann]

What you try is not implement.
You simply have to understand that mkgmap cannot read data in gmapsupp format. 
All the mentioned files are in gmapsupp format.
So, either use a different tool or maybe split the gmapsupp files first, e.g. 
with gmaptool.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Donnerstag, 13. Juli 2023 22:19
An: Tamas Gal
Cc: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Trouble with merging IMG files (for Garmin)

Hi,

> so I tried combining [opentopomap] Hungary and Slovenia but then I get again 
> a small 2.5KB file

Same here. My test were on simple maps without routing and DEM only; maybe its 
that. Sorry.

//Felix
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Trouble with merging IMG files (for Garmin)

[Gerd Petermann]

From the names of the two input files I guess that you try to merge to files 
which are already in gmapsupp format. This can't be done with mkgmap.

Gerd


Von: mkgmap-dev  im Auftrag von Tamas 
Gal 
Gesendet: Donnerstag, 13. Juli 2023 17:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Trouble with merging IMG files (for Garmin)

> java -jar mkgmap.jar --gmapsupp otm-hungary.img otm-slovenia.img

I tried that but the resulting file is only 2.5KB small:

░ tamasgal@silentbox:~/opt/mkgmap-r4909
░ 17:35:23 > java -jar mkgmap.jar --gmapsupp otm-hungary.img otm-slovenia.img
Mkgmap version 4909
Time started: Thu Jul 13 17:35:36 CEST 2023
Number of MapFailedExceptions: 0
Number of ExitExceptions: 0
Time finished: Thu Jul 13 17:35:36 CEST 2023
Total time taken: 267 ms

░ tamasgal@silentbox:~/opt/mkgmap-r4909
░ 17:35:36 > ls -alh
total 1563104
drwxrwxr-x@ 15 tamasgal  staff   480B Jul 13 17:35 .
drwxr-xr-x   9 tamasgal  staff   288B Jul 13 16:17 ..
-rw-rw-r--@  1 tamasgal  staff18K Jun  5 10:29 LICENCE
-rw-rw-r--@  1 tamasgal  staff   2.7K Jun  5 10:29 README
drwxrwxr-x@ 10 tamasgal  staff   320B Jun  5 10:31 doc
drwxrwxr-x@ 10 tamasgal  staff   320B Jun  5 10:29 examples
-rw-r--r--   1 tamasgal  staff   2.5K Jul 13 17:35 gmapsupp.img
drwxrwxr-x@  5 tamasgal  staff   160B Jun  5 10:29 lib
-rw-rw-r--@  1 tamasgal  staff   2.3M Jun  5 10:29 mkgmap.jar
-rw-r--r--   1 tamasgal  staff   5.0K Jul 13 17:35 osmmap.img
-rw-r--r--   1 tamasgal  staff   155B Jul 13 17:35 osmmap.tdb
-rw-r--r--@  1 tamasgal  staff   126M Jul 13 16:24 otm-germany-contours.img
-rw-r--r--@  1 tamasgal  staff43M Jul 13 16:28 otm-hungary-contours.img
-rw-r--r--@  1 tamasgal  staff   346M Jul 13 16:28 otm-hungary.img
-rw-r--r--@  1 tamasgal  staff   246M Jul 13 16:29 otm-slovenia.img

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Meaning of some mkgmap output messages

[Gerd Petermann]

Hi Carlos,

the 2nd msg was introduced with r3679, I hope the svn log entry helps:
https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=%2F=3679

Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Donnerstag, 8. Juni 2023 18:43
An: Development list for mkgmap
Betreff: [mkgmap-dev] Meaning of some mkgmap output messages

Hello all

I receive two types of messages when compiling some maps which I don't
know how to interpret and if I should take any action to avoid them.

First is of the form "(Area): 31177007.o5m: Area.split 1669081 4757504
1670337 4759552 res 11 can't 2 1" which is produced for tile 31177007:
1548288,4409344 to 1673216,4911104 from split file. In some cases the
end is "1 2" instead of "2 1".

The other one is of the form "Tile selection (0x4a) polygon for tile
25171101 cannot be written in level 0 resolution 20, using 18 instead"
and is produced for tile with bounding box 1753088,-8343552 to
3555328,-5726208 from split file.


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error processing tile

[Gerd Petermann]

Hi Ticker,

okay, it will probably always be hard to understand that part of the code. So 
let's see what comes next...

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 5. Juni 2023 12:39
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Error processing tile

Hi Gerd

The added comments are helpful but overall I think the readability is
worse; it takes careful reading to see where the dp filter is placed.
If other tweaks to different orderings between normal and parallel
chains are necessary it will become even more confusing.

Ticker

On Mon, 2023-06-05 at 09:41 +, Gerd Petermann wrote:
> Hi Ticker,
>
> thanks, I've committed the patch with r4909. What do you think about
> the attached patch to improve readability?
>
> 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

Re: [mkgmap-dev] Error processing tile

[Gerd Petermann]

Hi Ticker,

thanks, I've committed the patch with r4909. What do you think about the 
attached patch to improve readability?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 5. Juni 2023 09:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Error processing tile

Hi Gerd

Yes. MapSplitter enforces all the subDivision limits (#items and
#pointsInItems) before the filtering has happened. A Polyline might
need to be split into many lines if it has a large number of points,
but, at a given resolution, many points might be discarded. Using this
fact it can estimate the worst-case number of line splits to use in the
subDivision line count limit. This logic makes the most significant
difference at low resolutions but, in Carlos's data, there must have
been roads with multiple points in res24 squares.

Ticker

On Mon, 2023-06-05 at 06:48 +, Gerd Petermann wrote:
> Hi Ticker,
>
> okay, after some more debugging I think I understand. The problem
> is/was that the code in PredictFilterPoints assumes that the obsolete
> point removal happens before line splitting,
> but the actual order in MapBuilder is/was different (and wrong).
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Montag, 5. Juni 2023 08:14
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error processing tile
>
> Hi Ticker,
>
> The fix helps with the data from Carlos and it also seems to improve
> the img size.
> So far so good.
> I don't understand if this patch really fixes the error or if just
> changes "something" which prevents the error.
> Or in other words: How does it prevent the overflow of the counter?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Sonntag, 4. Juni 2023 10:15
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Error processing tile
>
> Hi Gerd
>
> Realising that something is increasing the number of lines in a
> subdivision and I wasn't getting the problem with my build I
> remembered
> I'd noticed that this could happen due to changes made to the line
> filtering in the low-res-opt branch work and supplied
> filterOrderLowRes.patch to restore some of the vital orderings - see
> forwarded email.
>
> The vital part is relating to MapSplitter/Area predicting the maximum
> number of splits to a line after RoundCoords & RemoveObsoletePoints
> have done their work.
>
> Attached is patch of the code I've been using appropriate to trunk.
>
> Ticker
>
>  Forwarded Message 
> From: Ticker Berkin 
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Problems with sea in overview map
> Date: Fri, 21 May 2021 17:10:07 +0100
>
> Hi Gerd
>
> I'd been doing some investigation of filters ordering (based on
> trunk).
> I'd also done the pre-filtering of lines & shapes by minRes.
>
> My conclusions are:
>
> Shapes:
> It is better to run SizeFilter after RemoveObsoleteFilter.
> It is more efficient to run DP filter after both of these.
>
> Lines:
> LineSplitterFilter should be run after everything that can remove
> points.
> It is more efficient to run DP after RemoveObsoleteFilter.
>
> I've adapted my changes into a patch for the low-res-opt branch,
> along
> with removal of some resolution tests that are now redundant.
>
> For the contourFilters, I've left DP as the first filter but moved
> ___
> 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
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (revision 4909)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -1243,34 +1243,35 @@
config.setLevel(div.getZoom().getLevel());
config.setHasNet(hasNet);
 
-   LayerFilterChain normalFilters = new LayerFilterChain(config);
-   LayerFilterChain keepParallelFilters = new 
LayerFilterChain(config);
+   List activeFilters = new ArrayList<>();
DouglasPeuckerFilter dp = null;
if (enableLineCleanFilters && (res < 24)) {
-   

Re: [mkgmap-dev] Error processing tile

[Gerd Petermann]

Hi Ticker,

okay, after some more debugging I think I understand. The problem is/was that 
the code in PredictFilterPoints assumes that the obsolete point removal happens 
before line splitting,
but the actual order in MapBuilder is/was different (and wrong).

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 5. Juni 2023 08:14
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Error processing tile

Hi Ticker,

The fix helps with the data from Carlos and it also seems to improve the img 
size.
So far so good.
I don't understand if this patch really fixes the error or if just changes 
"something" which prevents the error.
Or in other words: How does it prevent the overflow of the counter?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Sonntag, 4. Juni 2023 10:15
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Error processing tile

Hi Gerd

Realising that something is increasing the number of lines in a
subdivision and I wasn't getting the problem with my build I remembered
I'd noticed that this could happen due to changes made to the line
filtering in the low-res-opt branch work and supplied
filterOrderLowRes.patch to restore some of the vital orderings - see
forwarded email.

The vital part is relating to MapSplitter/Area predicting the maximum
number of splits to a line after RoundCoords & RemoveObsoletePoints
have done their work.

Attached is patch of the code I've been using appropriate to trunk.

Ticker

 Forwarded Message 
From: Ticker Berkin 
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Problems with sea in overview map
Date: Fri, 21 May 2021 17:10:07 +0100

Hi Gerd

I'd been doing some investigation of filters ordering (based on trunk).
I'd also done the pre-filtering of lines & shapes by minRes.

My conclusions are:

Shapes:
It is better to run SizeFilter after RemoveObsoleteFilter.
It is more efficient to run DP filter after both of these.

Lines:
LineSplitterFilter should be run after everything that can remove
points.
It is more efficient to run DP after RemoveObsoleteFilter.

I've adapted my changes into a patch for the low-res-opt branch, along
with removal of some resolution tests that are now redundant.

For the contourFilters, I've left DP as the first filter but moved
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error processing tile

[Gerd Petermann]

Hi Ticker,

The fix helps with the data from Carlos and it also seems to improve the img 
size.
So far so good.
I don't understand if this patch really fixes the error or if just changes 
"something" which prevents the error.
Or in other words: How does it prevent the overflow of the counter?

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Sonntag, 4. Juni 2023 10:15
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Error processing tile

Hi Gerd

Realising that something is increasing the number of lines in a
subdivision and I wasn't getting the problem with my build I remembered
I'd noticed that this could happen due to changes made to the line
filtering in the low-res-opt branch work and supplied
filterOrderLowRes.patch to restore some of the vital orderings - see
forwarded email.

The vital part is relating to MapSplitter/Area predicting the maximum
number of splits to a line after RoundCoords & RemoveObsoletePoints
have done their work.

Attached is patch of the code I've been using appropriate to trunk.

Ticker

 Forwarded Message 
From: Ticker Berkin 
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Problems with sea in overview map
Date: Fri, 21 May 2021 17:10:07 +0100

Hi Gerd

I'd been doing some investigation of filters ordering (based on trunk).
I'd also done the pre-filtering of lines & shapes by minRes.

My conclusions are:

Shapes:
It is better to run SizeFilter after RemoveObsoleteFilter.
It is more efficient to run DP filter after both of these.

Lines:
LineSplitterFilter should be run after everything that can remove
points.
It is more efficient to run DP after RemoveObsoleteFilter.

I've adapted my changes into a patch for the low-res-opt branch, along
with removal of some resolution tests that are now redundant.

For the contourFilters, I've left DP as the first filter but moved
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error processing tile

[Gerd Petermann]

Hi Ticker,

thanks for the patch. Some unit tests need changes. Please check if my changes 
are plausible. Something might be wrong on my system because SimpleRouteTest 
failed also without your patch.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Freitag, 2. Juni 2023 17:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Error processing tile

Hi Gerd & Carlos

I've found the problem and attach a patch which reduces the Subdivision
line limit to 254.

Subdivisions/areas have a set of limits, one of which was <= 255 lines.
These lines can be of any type including roads. When --route, a
reference to each line/road part is created, but these are numbered
from 1, so the 255th line in a SubDivision is numbered 256 as a road
segment and this can't be represented as a byte in the NET structures.

It looks like this problem has always been there, but is most likely to
manifest itself in areas with mostly roads.

Ticker

Index: src/uk/me/parabola/mkgmap/build/MapSplitter.java
===
--- src/uk/me/parabola/mkgmap/build/MapSplitter.java(revision 4907)
+++ src/uk/me/parabola/mkgmap/build/MapSplitter.java(working copy)
@@ -48,7 +48,7 @@
 
// The maximum number of lines. NET points to lines in subdivision
// using bytes.
-   public static final int MAX_NUM_LINES = 0xff;
+   public static final int MAX_NUM_LINES = 0xff-1;  // 
Subdivision/RoadDef/RoadIndex number from 1
 
public static final int MAX_NUM_POINTS = 0xff;
 
Index: test/func/SimpleTest.java
===
--- test/func/SimpleTest.java   (revision 4907)
+++ test/func/SimpleTest.java   (working copy)
@@ -69,7 +69,7 @@
assertEquals("number of points at level 0", 204, list.size());
 
List list1 = mr.linesForLevel(0);
-   assertEquals("number of lines at level 0", 3289, list1.size());
+   assertEquals("number of lines at level 0", 3290, list1.size());
}
 
@Test
Index: test/func/route/SimpleRouteTest.java
===
--- test/func/route/SimpleRouteTest.java(revision 4907)
+++ test/func/route/SimpleRouteTest.java(working copy)
@@ -58,7 +58,7 @@
count++;
System.out.println("TRE size " + size);
// Size varies depending on svn modified status
-   assertThat("TRE size", size, new 
RangeMatcher(1414, 2));
+   assertThat("TRE size", size, new 
RangeMatcher(1426, 2));
break;
case "LBL":
count++;
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 177, Issue 11

[Gerd Petermann]

Hi Diego,

I still cannot believe that it is important to have a HIGHER or LOWER value in 
the mapid for a certain mapset. AFAIK it is only important to have different 
ids. Maybe you have another mapset on your device with conflicting ids?

Gerd


Von: mkgmap-dev  im Auftrag von helter 
skelter 
Gesendet: Samstag, 29. April 2023 18:40
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] R: mkgmap-dev Digest, Vol 177, Issue 11

Hello everybody
after a couple of sleepless nights, i finally managed to understand and fix the 
problem and I want to share the solution, hoping to help someone.
It was nothing dealing with the quality of contour lines, but just with... map 
IDs !!.
I was splitting my contours with a lower MAPID than the one used to split the 
map:

step 1:
java -Xmx16384m -ea -jar C:\OSM\splitter\splitter.jar --mapid=13377300 
--output-dir=C:\CONTOURS --max-nodes=160 --keep-complete=false --output=o5m 
"CONTOURS.PBF"

step 2:
java -Xmx16384m -ea -jar C:\OSM\splitter\splitter.jar --mapid=13724300  
--output-dir=C:\MAPDATA --max-nodes=160 --keep-complete=false --output=o5m 
"MAPDATA.PBF"

step 3:
mkgmap to merge contours + mapdata

I don't know why, but this cause the countour lines to be recognized as 
"clickable" objects by the device and the others (areas, streets, paths, POIs 
etc.) are not. It only happens with the Garmin unit, not on Basecamp.

I changed the mapid for contours and made it HIGHER than the one for map data, 
and now it perfectly works !!! Contour lines are not clickable, while I can do 
it with all the other objects in the map and I get informations simply passing 
the cursor over them !

I have another question, less imoprtant: I am using a Copyright file with 
MKGMAP  and I see that all the text is changed to UPPERCASE. Could this be 
changed to normal text, so that I can see exactly the text of my file ?

Thanks everybody and have a great weekend !
cheers,
Diego



Da: mkgmap-dev  per conto di 
mkgmap-dev-requ...@lists.mkgmap.org.uk 
Inviato: mercoledì 26 aprile 2023 20:40
A: mkgmap-dev@lists.mkgmap.org.uk 
Oggetto: mkgmap-dev Digest, Vol 177, Issue 11

Send mkgmap-dev mailing list submissions to
mkgmap-dev@lists.mkgmap.org.uk

To subscribe or unsubscribe via the World Wide Web, visit
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
or, via email, send a message with subject or body 'help' to
mkgmap-dev-requ...@lists.mkgmap.org.uk

You can reach the person managing the list at
mkgmap-dev-ow...@lists.mkgmap.org.uk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mkgmap-dev digest..."
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] mkgmap-dev Digest, Vol 177, Issue 11

[Gerd Petermann]

Hi Diego,

reg. copyright data in UPPERCASE: Your commands don't show the use of a 
--codepage.
Try if --code-page=1252 helps.

Gerd




Von: mkgmap-dev  im Auftrag von helter 
skelter 
Gesendet: Samstag, 29. April 2023 18:40
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] R: mkgmap-dev Digest, Vol 177, Issue 11

Hello everybody
after a couple of sleepless nights, i finally managed to understand and fix the 
problem and I want to share the solution, hoping to help someone.
It was nothing dealing with the quality of contour lines, but just with... map 
IDs !!.
I was splitting my contours with a lower MAPID than the one used to split the 
map:

step 1:
java -Xmx16384m -ea -jar C:\OSM\splitter\splitter.jar --mapid=13377300 
--output-dir=C:\CONTOURS --max-nodes=160 --keep-complete=false --output=o5m 
"CONTOURS.PBF"

step 2:
java -Xmx16384m -ea -jar C:\OSM\splitter\splitter.jar --mapid=13724300  
--output-dir=C:\MAPDATA --max-nodes=160 --keep-complete=false --output=o5m 
"MAPDATA.PBF"

step 3:
mkgmap to merge contours + mapdata

I don't know why, but this cause the countour lines to be recognized as 
"clickable" objects by the device and the others (areas, streets, paths, POIs 
etc.) are not. It only happens with the Garmin unit, not on Basecamp.

I changed the mapid for contours and made it HIGHER than the one for map data, 
and now it perfectly works !!! Contour lines are not clickable, while I can do 
it with all the other objects in the map and I get informations simply passing 
the cursor over them !

I have another question, less imoprtant: I am using a Copyright file with 
MKGMAP  and I see that all the text is changed to UPPERCASE. Could this be 
changed to normal text, so that I can see exactly the text of my file ?

Thanks everybody and have a great weekend !
cheers,
Diego



Da: mkgmap-dev  per conto di 
mkgmap-dev-requ...@lists.mkgmap.org.uk 
Inviato: mercoledì 26 aprile 2023 20:40
A: mkgmap-dev@lists.mkgmap.org.uk 
Oggetto: mkgmap-dev Digest, Vol 177, Issue 11

Send mkgmap-dev mailing list submissions to
mkgmap-dev@lists.mkgmap.org.uk

To subscribe or unsubscribe via the World Wide Web, visit
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
or, via email, send a message with subject or body 'help' to
mkgmap-dev-requ...@lists.mkgmap.org.uk

You can reach the person managing the list at
mkgmap-dev-ow...@lists.mkgmap.org.uk

When replying, please edit your Subject line so it is more specific
than "Re: Contents of mkgmap-dev digest..."
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Garmin eTrex10 Map - POIs

[Gerd Petermann]

Hi Neil,

reg. POIs: You wrote yourself that the list is generated by the device. I think 
that's correct and thus it doesn't have an influence on the map size.

Gerd


Von: mkgmap-dev  im Auftrag von Neil 
Romig 
Gesendet: Sonntag, 16. April 2023 14:12
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Garmin eTrex10 Map - POIs

Gerd,

Thanks for tip, I'll try that out. As for the POIs it is because I have tried 
to keep file size to a minimum (below 2MB) I have very few entries in my 
"points" file so the POI list is an assortment of offshore islands and some 
ponds scattered across a 300km radius. Not very useful. I have remedied this by 
not having anything except towns, village and cities in the "points" file. I 
decided ti share my UK map file at sites.google.com.view/etrex10 if anyone's 
interested.

Neil.

On Sat, 2023-04-15 at 11:18 +, Gerd Petermann wrote:

Hi Neil,


ABC is the default value for the country abbreviation. You can use option 
--country-abbr

to change the default, see https://www.mkgmap.org.uk/doc/options for details, 
there are a lot more options

similar to this.


I have no idea why you want to get rid of the generated lists, and I don't know 
if that's possible on the device.


Gerd




Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Neil Romig mailto:n...@sixtythree.me.uk>>

Gesendet: Samstag, 15. April 2023 11:40

An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>

Betreff: [mkgmap-dev] Garmin eTrex10 Map - POIs


Hi,


I am new to mapping and Garmin, so bear with me if I ask stupid questions!


I have made a UK map from OSM data for my new eTrex10 which I am happy with - 
one level at resolution 18 with a pared down styling giving me a file of 1.7MB.

What puzzles me is the eTrex10 has a "Where To?" page showing  "Cities" and 
"All POIs" (among others) which have 50 entries each:


"Cities" has a list of local towns and villages in distance order and all 
suffixed with ", ABC".

"All POIs"  is likewise distance sorted, an assortment of mostly small islets & 
islands, water features, which probably relate to my very reduced set of map 
features.


It looks like the eTrex10 is producing these lists itself.


Two questions:


1) Why do the towns have "ABC" suffixed?


2) Can I get rid of the map-derived POI list? I have tried using 
"--poi-excl-index=0x0100-0x0b00,0x650c,0x6603,0x1f00,0x3000-0x5f00" without 
success.


I ask here because I suppose I won't get much help from Garmin - having 
replaced their built-in map!


Neil.

___

mkgmap-dev mailing list

mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>

https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Garmin eTrex10 Map - POIs

[Gerd Petermann]

Hi Neil,

ABC is the default value for the country abbreviation. You can use option 
--country-abbr
to change the default, see https://www.mkgmap.org.uk/doc/options for details, 
there are a lot more options
similar to this.

I have no idea why you want to get rid of the generated lists, and I don't know 
if that's possible on the device.

Gerd


Von: mkgmap-dev  im Auftrag von Neil 
Romig 
Gesendet: Samstag, 15. April 2023 11:40
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Garmin eTrex10 Map - POIs

Hi,

I am new to mapping and Garmin, so bear with me if I ask stupid questions!

I have made a UK map from OSM data for my new eTrex10 which I am happy with - 
one level at resolution 18 with a pared down styling giving me a file of 1.7MB.
What puzzles me is the eTrex10 has a "Where To?" page showing  "Cities" and 
"All POIs" (among others) which have 50 entries each:

"Cities" has a list of local towns and villages in distance order and all 
suffixed with ", ABC".
"All POIs"  is likewise distance sorted, an assortment of mostly small islets & 
islands, water features, which probably relate to my very reduced set of map 
features.

It looks like the eTrex10 is producing these lists itself.

Two questions:

1) Why do the towns have "ABC" suffixed?

2) Can I get rid of the map-derived POI list? I have tried using 
"--poi-excl-index=0x0100-0x0b00,0x650c,0x6603,0x1f00,0x3000-0x5f00" without 
success.

I ask here because I suppose I won't get much help from Garmin - having 
replaced their built-in map!

Neil.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Strange behavior of contour lines for different resolutions

[Gerd Petermann]

Hi Daniel,

I don't know for sure but I think you may have to set option --levels or 
--overview-levels to the values that you want.
There is a hard-coded default for --levels in mkgmap:
public static final String DEFAULT_LEVELS = "0:24, 1:22, 2:20, 3:18, 4:16";
and the options file in the default style overwrites this:
levels = 0:24, 1:22, 2:20, 3:18
overview-levels = 4:17, 5:16, 6:15, 7:14, 8:13
So, you have different places to check.

Gerd


Von: mkgmap-dev  im Auftrag von Daniel 
Vogelbacher 
Gesendet: Samstag, 18. März 2023 07:36
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Strange behavior of contour lines for different   
resolutions

Hi all,

I want to generate an overlay map with contour lines. The following
style works as expected:

contour=elevation & contour_ext=elevation_minor  & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x20 resolution 24]
contour=elevation & contour_ext=elevation_medium & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x21 resolution 20]
contour=elevation & contour_ext=elevation_major  & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x22 resolution 17]


Major lines are visible up from resolution 17, medium from resolution 20
and minor on highest resolution (24).

If I change the style to:

contour=elevation & contour_ext=elevation_minor  & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x20 resolution 24]
contour=elevation & contour_ext=elevation_medium & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x21 resolution 21]
contour=elevation & contour_ext=elevation_major  & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x22 resolution 17]


Major lines are visible up from resolution 17, but together with medium
lines, minor lines are visible starting from resolution 21, too.
Same effect for choosing resolution 22 or 23 for medium lines. Medium
and minor lines are visible always together for medium-resolutions >= 21.

As the effect is the same on QMapShack and GPSMap 66s, I assume the
problem is in the map.

Any ideas what can cause the problem? What I finally want to build is:

contour=elevation & contour_ext=elevation_major  & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x20 resolution 18-21 continue]

contour=elevation & contour_ext=elevation_minor  & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x20 resolution 24]
contour=elevation & contour_ext=elevation_medium & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x21 resolution 23]
contour=elevation & contour_ext=elevation_major  & (ele > 0 | ele < 0) {
name '${ele|conv:m=>ft}'; }   [0x22 resolution 22]


I've reduced this to the styles above to isolate the problem.

mkgmap r4907 here. Tried r4900 as well.

java -jar
fzk-mde-garmin/Freizeitkarte-Entwicklung/tools/mkgmap/mkgmap.jar
--copyright-message="Sonny DEM" --series-name="DEM Europe 10m"
--description="DEM for Europe v17 10m 250m/50m" --family-name="DEM
Europe" --country-name=Europe --country-abbr=EU --area-name=EU
--product-version="202303" --reduce-point-density=0.2
--reduce-point-density-polygon=0.2 --min-size-polygon=1
--name-tag-list=name,place_name,loc_name --order-by-decreasing-area
--style-file=contourmap/style/ --latin1 --transparent --no-poi-address
--gmapsupp -c contourmap/mkgmap.europe.cfg -c
/workbench/main/osm/splitter/contours_v17_10m_250_50/template.args
contourmap/typ/contours.txt



--
Best regards / Mit freundlichen Grüßen
Daniel Vogelbacher

--
Best regards / Mit freundlichen Grüßen
Daniel Vogelbacher

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP files does not work

[Gerd Petermann]

Hi all,

OK, I see no problems to change this method  in GType.java:
public static boolean isContourLine(MapLine line) {
return line.getType() >= 0x20 && line.getType() <= 0x22 && 
!(line instanceof MapShape);
}

All I have to do is to change 0x22 to 0x25, right?

Gerd


Von: mkgmap-dev  im Auftrag von Vadim 
Karpov 
Gesendet: Donnerstag, 2. März 2023 14:38
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP 
files does not work

Hi

Yes.

Types 0x23.0x24.0x25 are used to create bathymetric maps.

Information from the MPCTypes.txt file (TypViewer application):

0x02000=Contour Lines/MINOR_CONTOUR/Minor land-based contour line/Non NT
0x02100=Contour Lines/INT_CONTOUR/Intermediate contour (should be used for 
about every 5th contour line)/Non NT
0x02200=Contour Lines/MAJOR_CONTOUR/Major contour (should be used for about 
every 10th contour line)/Non NT

0x02300=Contour Lines/MINOR_BATHY_CONTOUR/Minor bathymetric, or depth, 
contour/Non NT
0x02400=Contour Lines/INT_BATHY_CONTOUR/Intermediate bathymetric, or depth, 
contour (should be used for about every 5th contour line)/Non NT
0x02500=Contour Lines/MAJOR_BATHY_CONTOUR/Major bathymetric, or depth, contour 
(should be used for about every 10th contour line)/Non NT

Четверг, 2 марта 2023, 12:01 +03:00 от Ticker Berkin :

Hi

My understanding of the default Garmin usage is that
 0x20..0x22 are land/height contours (Minor to Major)
 0x23..0x25 are sea/depth " "

Ticker

On Thu, 2023-03-02 at 08:52 +, Gerd Petermann wrote:
> Hi Vadim,
>
> I see code in mkgmap to handle the statement with Elevation=m or
> Elevation=M, but it is only used for the line types 0x20 .. 0x22.
> Do you have a good reason to use line type 0x25 instead?
>
> Gerd
>
>
> 
> Von: mkgmap-dev 
> >
>  im Auftrag
> von Vadim Karpov >
> Gesendet: Mittwoch, 1. März 2023 13:00
> An: 
> mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] The "Elevation=M" in the header of the polish
> .MP files does not work
>
> Good afternoon !
>
> I am using the latest version of MkGMap and trying to create a depth
> chart with isolines (types 0x24, 0x25).
>
> The problem is that the compiler interprets the depth specified in
> Meters as in Feet.
> The result is independent of the presence or value of the
> "Elevation=M" parameter.
>
> And I didn't find an alternative command line option. :(
>
> So how can I tell the compiler to treat all numerical depth and
> height values in an .MP file as meters and not feet?
>
> Thanks for the advice.
>
> PS: cGpsMapper works fine with "Elevation=M" of course.
> PPS: Example of polylyne defs:
>
> [POLYLINE]
> Type=0x02500
> Label=21
> EndLevel=3
> Data0=(47.13926351703,-122.560520313), ...
> [END]
>
> [POLYLINE]
> Type=0x02500
> Label=12
> EndLevel=3
> Data0=(47.12784640003,-122.562501059), ...
> [END]
>
> --
> Vadim Karpov
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Vadim Karpov
Отправлено из Почты Mail.ru<https://trk.mail.ru/c/zzm979>

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Remove accentiuation

[Gerd Petermann]

Hi Karl,

sorry, I have no idea what you try to do. My understanding so far was that the 
apostrophe is added by transliteration which happens after style processing.
Please give us an OSM object that contains the name with the problematic 
characters.

I don't think that you can remove a single apostrophe with the subst statement, 
the current implementation doesn't seem to allow this special character.

Gerd


Von: mkgmap-dev  im Auftrag von 7770 
<7...@foskan.eu>
Gesendet: Sonntag, 26. Februar 2023 18:02
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Remove accentiuation

Hi.
For some reason it seems i am not able to perform this type of change in the
finalize section.

I get:
Error in style: Error: (points:427): Unrecognised command '='

The lines in points finalize style looks like:

name=* {name '${name}'}
# next line to remove ' from names.
name=* {set name='${name|subst:"'=>"}'}
include 'inc/address';

Is this how it is supposed to look?

Regards
Karl


On söndag 1 januari 2023 19:34:19 CET you wrote:
> You can try in stylefile this addidional  line : {set name='${name
>
> |subst:'=>}'} . This action shoult remove the apostrophe.
>
> thomas
>
> Am 01.01.2023 um 18:37 schrieb 7770:
> > Hi and with wishes of a Happy new year.
> >
> > When preparing maps i use the setting
> > --latin1   (same as --code-page=1252)
> >
> > This is good most of the time, since most language specific characters are
> > replaced with plain latin characters. Cyrillic is transliterated to latin.
> >
> > In Ukraininan there is a softening letter (ь), when this is present in a
> > name, it is transliteradet to ' (apostrophe).
> >
> > For example the city Львів becomes L'viv. This in turn makes searches more
> > difficult since one not familar with the language may not know where the
> > accentuation is placed. As a forigner i would not know if it is Lviv or
> > L'viv.
> >
> > Is there some better code page to use to start with (still performing
> > transliteration) or some way to ask mkgmap to remove the apostrophe from
> > the text?
> >
> >
> > Regards
> > Karl
> >
> >
> >
> > ___
> > mkgmap-dev mailing list
> > mkgmap-dev@lists.mkgmap.org.uk
> > https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP files does not work

[Gerd Petermann]

Hi Vadim,

I see code in mkgmap to handle the statement with Elevation=m or Elevation=M, 
but it is only used for the line types 0x20 .. 0x22.
Do you have a good reason to use line type 0x25 instead?

Gerd



Von: mkgmap-dev  im Auftrag von Vadim 
Karpov 
Gesendet: Mittwoch, 1. März 2023 13:00
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] The "Elevation=M" in the header of the polish .MP files 
does not work

Good afternoon !

I am using the latest version of MkGMap and trying to create a depth chart with 
isolines (types 0x24, 0x25).

The problem is that the compiler interprets the depth specified in Meters as in 
Feet.
The result is independent of the presence or value of the "Elevation=M" 
parameter.

And I didn't find an alternative command line option. :(

So how can I tell the compiler to treat all numerical depth and height values 
in an .MP file as meters and not feet?

Thanks for the advice.

PS: cGpsMapper works fine with "Elevation=M" of course.
PPS: Example of polylyne defs:

[POLYLINE]
Type=0x02500
Label=21
EndLevel=3
Data0=(47.13926351703,-122.560520313), ...
[END]

[POLYLINE]
Type=0x02500
Label=12
EndLevel=3
Data0=(47.12784640003,-122.562501059), ...
[END]

--
Vadim Karpov
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] NSIS option for Basecamp

[Gerd Petermann]

Hi Diego,

not sure how you transfer small parts of the map to the device. If you do that 
with Basecamp please make sure that you use the latest version.
See here for more details: 
https://forum.openstreetmap.org/viewtopic.php?id=62468

If this doesn't help please describe more detailed what you try to do, what you 
expect and what you get instead.

Gerd


Von: mkgmap-dev  im Auftrag von skelter 
helter 
Gesendet: Dienstag, 31. Januar 2023 20:51
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] NSIS option for Basecamp

Hello
I need help with the NSIS option. I use it to create an installer of my map for 
Basecamp. It works, but I am not able to load small parts of the map to my 
device: I can only load the full map, not the single tiles or a selection of 
them.
My map is complete with DEM and contours and it works good both on Basecamp and 
on the device (just a little slow when loading).
Can anybody help me please?
Many thanks !

Diego
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] URLs on https://www.mkgmap.org.uk/download/mkgmap.html needs adjustement

[Gerd Petermann]

Hi Thorsten,

I've changed the URLs.

Gerd


Von: mkgmap-dev  im Auftrag von 
Thorsten Kukuk 
Gesendet: Montag, 9. Januar 2023 13:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] URLs on https://www.mkgmap.org.uk/download/mkgmap.html 
needs adjustement


Hi,

can whoever has access to the html code change the URLs for the
bounds-latest.zip and sea-latest.zip on 
https://www.mkgmap.org.uk/download/mkgmap.html?
google chrome makes quite some problems with the http redirects, while
it works fine with firefox.

The URLs which should be used are:
https://www.thkukuk.de/osm/data/bounds-latest.zip
https://www.thkukuk.de/osm/data/sea-latest.zip

  Thanks,
 Thorsten

--
Thorsten Kukuk, Distinguished Engineer, Senior Architect, Future Technologies
SUSE Software Solutions Germany GmbH, Frankenstraße 146, 90461 Nuernberg, 
Germany
Managing Director: Ivo Totev, Andrew Myers, Andrew McDonald, Martje Boudien 
Moerman
(HRB 36809, AG Nürnberg)
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] DEM data from gmapsuppp not showing on BaseCamp

[Gerd Petermann]

Hi Carlos,

I don't know the exact reason for the problem. I guess Garmin software needs 
DEM tiles with the same layout,
but maybe only one corner has to match.
I think the only solution is to use the same split file as long as possible so 
that you can reuse the precompiled DEM tiles.
If mkgmap fails to render a tile because it has too much data you would split 
that specific tile into smaller pieces,
modify the global split file to contain the new tiles and render the needed DEM 
tiles.
Quite some work to do when this should happen automatically with scripts.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos 
Dávila 
Gesendet: Montag, 2. Januar 2023 18:45
An: Development list for mkgmap
Betreff: [mkgmap-dev] DEM data from gmapsuppp not showing on BaseCamp

Happy New Year to all!

One user of my maps has reported that when he loads a gmapsupp with DEM
in BaseCamp, it doesn't show shaded relief, while if he loads gmap
version of the same map it does. I have confirmed the issue with a
couple of maps and also that BaseCamp reads height information from
gmapsupp, as it is displayed in the status bar along with coordinates.
gmap version of the same maps does show both shaded relief and height
info at all zoom levels.

My DEM maps are generated with options below, just combining precompiled
map data (51*.img) and DEM data (63*.img) tiles.

gmapi command: java -ea -Xmx27G -jar mkgmap.jar --dem=hgt/ALOS
--dem-poly=polygons/$mapa.poly --overview-dem-dist=128000
--gmapi-minimal${GMAPI_MINIMAL} --show-profiles=1
--road-name-config=${CONFIG} tmp/51${FID}*.img curvas/63${FID}*.img
tmp/${ABR}5${FID}.txt

gmapsupp command: java -Xmx27G -ea -jar mkgmap.jar --gmapsupp
--road-name-config=${CONFIG} --route tmp/51${FID}*.img
curvas/63${FID}*.img tmp/${ABR}5${FID}.typ --description="OSM $MAPA DEM"
--no-tdbfile

I then tried splitting map data with the same areas.list used to
generate DEM tiles, so that both groups of tiles share the same bounding
box, but it didn't work either. Only if map and DEM data are all
compiled in the same run of mkgmap, gmapsupp shows shaded relief in
BaseCamp.

Does anybody know a way to get shaded relief from gmapsupp when using
precompiled tiles?



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Remove accentiuation

[Gerd Petermann]

Hi Karl,

I am not sure if I understand the problem. If you don't want to use utf8 you 
may try to change the data in mkgmap\resources\chars\latin1

Gerd


Von: mkgmap-dev  im Auftrag von 7770 
<7...@foskan.eu>
Gesendet: Sonntag, 1. Januar 2023 18:37
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Remove accentiuation

Hi and with wishes of a Happy new year.

When preparing maps i use the setting
--latin1   (same as --code-page=1252)

This is good most of the time, since most language specific characters are
replaced with plain latin characters. Cyrillic is transliterated to latin.

In Ukraininan there is a softening letter (ь), when this is present in a name,
it is transliteradet to ' (apostrophe).

For example the city Львів becomes L'viv. This in turn makes searches more
difficult since one not familar with the language may not know where the
accentuation is placed. As a forigner i would not know if it is Lviv or L'viv.

Is there some better code page to use to start with (still performing
transliteration) or some way to ask mkgmap to remove the apostrophe from the
text?


Regards
Karl



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Deathloop on splitting file created by splitter if using argentina.poly --polygon-file

[Gerd Petermann]

Hi Felix,

cannot reproduce the loop here. Maybe the content of the current argentina.poly 
differs from yours?

BTW: I see much better runtime with just java -jar -Xmx4G 
d:\splitter\dist\splitter.jar
instead of java  -XX:+AggressiveHeap -Xms5000M -Xmx4m -jar 
d:\splitter\dist\splitter.jar using openjdk version "11.0.15" 2022-04-19

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Samstag, 17. Dezember 2022 07:30
An: Development list for mkgmap
Betreff: [mkgmap-dev] Deathloop on splitting file created by splitter if using 
argentina.poly --polygon-file

Hi,

I tried resplitting a file that was too big for the map creation using splitter 
- and if I use the boundary file splitter.jar is getting stuck finding a 
solution (until killed).

Command:
start /belownormal /b /wait java -XX:+AggressiveHeap -Xms5000M -Xmx4m -jar 
C:\openmtbmap\splitter.jar --max-nodes=140 --output=o5m 
--geonames-file=E:\openmtbmap\osmpbf_geofabrik\cities5000.zip 
--polygon-file=E:\OpenMTBMap\osmpbf_geofabrik\argentina.poly 
--description=argentina --mapid=64700017 "64700010.o5m"

If leaving out the polygon-file it works without problems to resplit it again.

Command used to create the file that fails to be splitted again:
C:\openmtbmap\splitter.jar 
"--precomp-sea=E:\OpenMTBMap\osmpbf_geofabrik\sea.zip" 
--polygon-file=E:\OpenMTBMap\osmpbf_geofabrik\argentina.poly 
--max-nodes=280 --max-threads=11 --search-limit=100 --output=o5m 
"--keep-complete" 
--route-rel-values=mtb,bicycle,foot,hiking,road,mountainbike,ferry,shuttle_train,subway,train,tram,river,canal,ski,piste,walking
 --max-areas=4000  
--geonames-file=E:\OpenMTBMap\osmpbf_geofabrik\cities5000.zip  
--description=argentina --mapid=6470 
E:\OpenMTBMap\osmpbf_geofabrik\argentina.o5m  1>NUL

However I also uploaded the file for debug:
https://openmtbmap.org/64700010.o5m

I don't think there is a problem in general with splitting a file splitted by 
spliter.jar again using smaller max-nodes and using polygon-file option. 
Something is special here that it fails (happened already one week ago with a 7 
day older geofabrik extract)

--
Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] multipolygon relation, water

[Gerd Petermann]

Hi Brad,

your additional rule is not a good idea, it adds a polygon feature to unclosed 
lines.
I loaded the relation into JOSM and it complains "Multipolygon outer way shares 
segment with other ring"
so the relation is invalid and mkgmap probably doesn't render it.
The problem is between these nodes:
https://www.openstreetmap.org/node/8977585639
https://www.openstreetmap.org/node/8977553197

I think this way https://www.openstreetmap.org/way/970139137
should not be a member of the relation.

Gerd


Von: mkgmap-dev  im Auftrag von brad 

Gesendet: Donnerstag, 1. Dezember 2022 02:09
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] multipolygon relation, water

This water relation doesn't show up on my map.

https://www.openstreetmap.org/relation/370015

I added this to my relations file

type=multipolygon & natural=water
{
apply {
set natural=water;
set name='${name}';
}
 }

But still doesn't work.

I have a bunch of natural=water lines in my polygons file for various
sizes & other natural=water ways work just fine.
Any help appreciated.

thx
Brad
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Why does the default typ not render cycleways?

[Gerd Petermann]

Hi ael,

the "default typ" is the one that comes with the firmware of the Garmin device.
On my Oregon 600 the type 0x11 is also not rendered very well, maybe it is
rendered as white line or not at all, not sure what it is.

Gerd


Von: mkgmap-dev  im Auftrag von ael 

Gesendet: Sonntag, 27. November 2022 16:23
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Why does the default typ not render cycleways?

Just a quick question: when I compile with default style and typ,
cycleways are not rendered.

I need to use, say, mapnik.txt to see them.

So far as my very limited understanding reaches, the default style has

highway=cycleway [0x11 road_class=0 road_speed=1 resolution 23]
garmin type 0x11. So far so good (and mapnik picks that up).

But the default typ seems to ignore 0x11, although I cannot find that
specification just now.

Have I missed something? Why don't the defaults render things so
significant as cycleways? This seems to have been the case for at
least a year.

ael

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Combining img files to a single map

[Gerd Petermann]

Hi Harri,

I don't understand why you want to combine the different gmapsupp files. What 
would be the
advantage compared to having multiple files?
I have four or five different gmapsupp on my device, I can enable/disable each 
and I can update
each one separately. Why would I want to combine them into one large file?

Gerd


Von: mkgmap-dev  im Auftrag von Harri 
Suomalainen 
Gesendet: Mittwoch, 2. November 2022 15:44
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Combining img files to a single map

Yes, I've been trying to combine multiple gmapsupp files. I have a
workflow that makes uses mkgmap to make several files from the same
splitted files using "mkgmap -gmapsupp ..."

How does one combine tiles when there are multiple styles used with same
source tiles? Compile without -gmapsupp option and then combine multiple
.img -files? (Are there restrictions like should they be same family or
whatever, as long as different mapname/id?)

At the moment I have tiles, use mkgmap with some style and then run
mkgmap with another style to make overlay like arrows for oneway streets
and I need to combine that kind of results.



On 1.11.2022 20.11, Gerd Petermann wrote:
> Hi Harri,
>
> you seem to try to combine different gmapsupp files? I think this is not 
> supported by mkgmap.
> Why don't you combine the wanted tiles instead?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von Harri 
> Suomalainen 
> Gesendet: Dienstag, 1. November 2022 14:09
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] Combining img files to a single map
>
> I'm had problems combining different maps to a single file with mkgmap
> (latest version but this has been a long term problem)
>
> What are the requirements for combining? I seem to not find any
> documentation about it other than that mapname should be different on files.
>
> I'm generating multiple files, all with different family-id, product-id,
> mapname and map description. They all use different typ-files matching
> the file family/product-id of the compiled map.
>
> Combining with gmaptool (command-line on linux) has been successful with
> "./gmt -jo gmapsupp.img basemap.img fixme.img oneway.img". (Using a very
> old 2015 version, just because I have had it installed)
>
> Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp
> basemap.img fixme.img oneway.img" give very small files and I get
> warnings like "WARNING (global): Could not copy MAKEGMAP.MPS
> uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists"
>
> What is the correct way to go? (Only my basemap has routing information,
> other files are overlay info like fixme marking, oneway arrows and similar)
>
> Chears, Harri
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Combining img files to a single map

[Gerd Petermann]

Hi Harri,

you seem to try to combine different gmapsupp files? I think this is not 
supported by mkgmap.
Why don't you combine the wanted tiles instead?

Gerd


Von: mkgmap-dev  im Auftrag von Harri 
Suomalainen 
Gesendet: Dienstag, 1. November 2022 14:09
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Combining img files to a single map

I'm had problems combining different maps to a single file with mkgmap
(latest version but this has been a long term problem)

What are the requirements for combining? I seem to not find any
documentation about it other than that mapname should be different on files.

I'm generating multiple files, all with different family-id, product-id,
mapname and map description. They all use different typ-files matching
the file family/product-id of the compiled map.

Combining with gmaptool (command-line on linux) has been successful with
"./gmt -jo gmapsupp.img basemap.img fixme.img oneway.img". (Using a very
old 2015 version, just because I have had it installed)

Combine attempts with like "java -jar mkgmap/mkgmap.jar --gmapsupp
basemap.img fixme.img oneway.img" give very small files and I get
warnings like "WARNING (global): Could not copy MAKEGMAP.MPS
uk.me.parabola.imgfmt.FileExistsException: File MAKEGMAP.MPS already exists"

What is the correct way to go? (Only my basemap has routing information,
other files are overlay info like fixme marking, oneway arrows and similar)

Chears, Harri
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Suggestion: Add option to remove area after convert to poi

[Gerd Petermann]

Hi Ke,

not sure if I understand what you try to achive. If you don't want lines or 
areas in your map, just remove the rule files for polygons and lines.

Gerd



Von: mkgmap-dev  im Auftrag von Ke 

Gesendet: Dienstag, 11. Oktober 2022 12:38
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Suggestion: Add option to remove area after convert to
poi

Hi,

The --add-pois-to-areas option is very useful to create maps. However, in 
certain cases I wish to have a clear poi file in addition to the garmin NT 
navigation file, so that can use the feature like speed limit and "garmin real 
directions". Thus an option such like --poi-only that removes all non-poi data 
at end of the process would be great.

Thanks,
Ke
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Andrzej,

I guess that works but Piotrs data is different. It has e.g.
Numbers1=0,O,7,11,E,12,18
Numbers2=1,O,21,29,E,20,24
Numbers3=2,B,31,31,E,28,38
Numbers4=3,N,-1,-1,E,40,48
CityName=Teresin@Granice

The doc shows that you can have up to three cities, and I've no idea how to 
decide which numbers belong to which city.
I assume that the "multiple cities" stuff forces the GMP format, but I didn't 
try this. I just verified that my version of cGPSMapper
also writes the GMP format for Piotrs input file. Maybe someone can analyse 
that in detail.
The good thing is that we have a *.mp file and a GMP output. This should help 
to understand the GMP format.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Sonntag, 23. Oktober 2022 00:13
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

Hi Gerd,

 > I thought that mkgmap can handle roads with multiple cities but you
 > seem to be right that this only works when the cities are encoded with
 > the house numbers.

Actually in mp format you can encode void house numbers with 2 cities.
Doesn't it work in mkgmap? I mean statement like:

Numbers1=0,N,-1,-1,N,-1,-1,Płońsk,-1,-1,Skarżyn,-1,-1

--
Best regards,
Andrzej

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

reg. multipile cities: I'm sorry, it seems I no longer understand the code in 
mkgmap :(
In fact it seems I somehow lost my ability to understand and handle complex 
problems, probably it's time for me to stop doing this.

My first patch works as intended but doesn't change the output as expected.
I thought that mkgmap can handle roads with multiple cities but you seem to be 
right that this only works when the cities are encoded with the house numbers.
I've no idea what mkgmap should write for your input and our tools to analyse 
the GMP format are too poor as well.
Maybe cgpsmapper creates fake house numbers for the additional cities?

Reg. [Sign]: I might look at this again in the winter. Right now I prefer to 
cycle and do some OSM mapping.



ciao,
Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Dienstag, 18. Oktober 2022 09:34
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

Hi Piotr,

it seems I already worked on the [Sign] stuff in 2016, see 
https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q1/024703.html

I have no idea why I stopped at that time, but it means that I was wrong when I 
wrote that we already know how to write
the [Sign] data. I've confused that with the method how we write destination 
hints.

I'll start again to look at the data from Andrzej.

Reg. multiple cities for one road:
My patch only handles the @ in city names. The manual shows that this trick can 
also be used for RegionName.
I have to add some more code to handle this in the way documented in the manual.

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Montag, 17. Oktober 2022 16:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

pon., 17 paź 2022 o 15:50 Gerd Petermann
 napisał(a):
> well, GPSMapEdit says it is NT format, and for the existence of the sub type 
> GMP means NT format.

Well, it might be alike from index point of view, but I am sure that
the whole NT, have never been decoded.

> Anyhow, I might find a way to work around that.

That could be awesome, if you need any additional data, please let me
know, I will try to prepare specific data if you wish.

> Do you know what the data starting with HLevel0 is about? I cannot find that 
> in the cGPSmapper
> manual version 2.5

You can ignore it, it is extension from navitel, and it is used in the
source code for bridges depiction. In general it shows level: -1 mean
tunel, +1 etc mean above surface.

> I've also noticed that mkgmap ignores the key Routeparam because it expects 
> RouteParam.
> I guess it should ignore case as with some other key words?

Yes, mkgmap ignores Routparam, but it is not an issue at all, as I am
preprocessing source for mkgmap. It might be that cgpmapper is not
case sensitive at all, but I would need to check it. Should I?
Routeparam is a result of another software, that prepares mp for
cgpamapper. It creates routing data (nodes), restrictions, signs and
balances routing classes. But apparently cgpamapper accepts Routeparam
as well.
Piotr
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

it seems I already worked on the [Sign] stuff in 2016, see 
https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2016q1/024703.html

I have no idea why I stopped at that time, but it means that I was wrong when I 
wrote that we already know how to write
the [Sign] data. I've confused that with the method how we write destination 
hints.

I'll start again to look at the data from Andrzej.

Reg. multiple cities for one road:
My patch only handles the @ in city names. The manual shows that this trick can 
also be used for RegionName.
I have to add some more code to handle this in the way documented in the manual.

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Montag, 17. Oktober 2022 16:11
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

pon., 17 paź 2022 o 15:50 Gerd Petermann
 napisał(a):
> well, GPSMapEdit says it is NT format, and for the existence of the sub type 
> GMP means NT format.

Well, it might be alike from index point of view, but I am sure that
the whole NT, have never been decoded.

> Anyhow, I might find a way to work around that.

That could be awesome, if you need any additional data, please let me
know, I will try to prepare specific data if you wish.

> Do you know what the data starting with HLevel0 is about? I cannot find that 
> in the cGPSmapper
> manual version 2.5

You can ignore it, it is extension from navitel, and it is used in the
source code for bridges depiction. In general it shows level: -1 mean
tunel, +1 etc mean above surface.

> I've also noticed that mkgmap ignores the key Routeparam because it expects 
> RouteParam.
> I guess it should ignore case as with some other key words?

Yes, mkgmap ignores Routparam, but it is not an issue at all, as I am
preprocessing source for mkgmap. It might be that cgpmapper is not
case sensitive at all, but I would need to check it. Should I?
Routeparam is a result of another software, that prepares mp for
cgpamapper. It creates routing data (nodes), restrictions, signs and
balances routing classes. But apparently cgpamapper accepts Routeparam
as well.
Piotr
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

the attached patch solves the indexing city problem. Rather ugly but I think it 
works. Please try.
A patched binary is here:

https://files.mkgmap.org.uk/download/559/mkgmap.jar

The [SIGN] part will take more time...

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Montag, 17. Oktober 2022 15:50
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

Hi Piotr,

well, GPSMapEdit says it is NT format, and for the existence of the sub type 
GMP means NT format.

Anyhow, I might find a way to work around that.
Do you know what the data starting with HLevel0 is about? I cannot find that in 
the cGPSmapper
manual version 2.5

I've also noticed that mkgmap ignores the key Routeparam because it expects 
RouteParam.
I guess it should ignore case as with some other key words?

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Montag, 17. Oktober 2022 14:53
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

pon., 17 paź 2022 o 14:46 Gerd Petermann
 napisał(a):
>
> Hi Piotr,
>
> I am a bit confused. The map file 48240001.img is in NT format. Can you 
> really create that with cgpsmapper?
> If you are able to create that in the older IMG format please do that. It 
> will help me to understand what mkgmap
> has to write, but note that mkgmap cannot write NT format.

Hi Gerd,
AFAIR it is not NT format, but rather NI format - sort of new index
format. As I understood Stanisław Kozicki emails from many years ago,
real NT format had never been decoded by him, but he introduced new
indexes format or something I am not entirely sure. It was really
created with cgpamapper.
Take care
Piotr
___
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
Index: src/uk/me/parabola/mkgmap/build/MapBuilder.java
===
--- src/uk/me/parabola/mkgmap/build/MapBuilder.java (revision 4905)
+++ src/uk/me/parabola/mkgmap/build/MapBuilder.java (working copy)
@@ -113,6 +113,7 @@
 import uk.me.parabola.mkgmap.reader.osm.MultiPolygonRelation;
 import uk.me.parabola.mkgmap.reader.osm.Way;
 import uk.me.parabola.mkgmap.reader.overview.OverviewMapDataSource;
+import uk.me.parabola.mkgmap.reader.polish.PolishMapDataSource;
 import uk.me.parabola.util.Configurable;
 import uk.me.parabola.util.EnhancedProperties;
 import uk.me.parabola.util.Java2DConverter;
@@ -556,11 +557,20 @@
 
MapRoad road = (MapRoad) line;
road.resetImgData();
-
-   City roadCity = calcCity(lbl, cityName, cityRegionName, 
cityCountryName);
-   if (roadCity != null)
-   road.addRoadCity(roadCity);
-
+   // handle special case in polish (mp) format: multiple 
city names may be separated by @
+   boolean splitCityNames = cityName != null && (src 
instanceof PolishMapDataSource);
+   if (splitCityNames) {
+   String[] cityNames = cityName.split("@");
+   for (String cn : cityNames) {
+   City roadCity = calcCity(lbl, cn, 
cityRegionName, cityCountryName);
+   if (roadCity != null)
+   road.addRoadCity(roadCity);
+   }
+   } else {
+   City roadCity = calcCity(lbl, cityName, 
cityRegionName, cityCountryName);
+   if (roadCity != null)
+   road.addRoadCity(roadCity);
+   }
if (zipStr != null) {
road.addRoadZip(lbl.createZip(zipStr));
}
Index: src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
===
--- src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
(revision 4905)
+++ src/uk/me/parabola/mkgmap/reader/polish/PolishMapDataSource.java
(working copy)
@@ -475,7 +475,7 @@
roadHelper.setRoadId(Integer.parseInt(value));
} else if (name.startsWith("Nod")) {
roadHelper.addNode(value);
-   } else if ("RouteParam".equals(name) || 
"RouteParams".equals(name)) {
+   } else if ("RouteParam".equalsIgnoreCase(name) || 
"R

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

well, GPSMapEdit says it is NT format, and for the existence of the sub type 
GMP means NT format.

Anyhow, I might find a way to work around that.
Do you know what the data starting with HLevel0 is about? I cannot find that in 
the cGPSmapper
manual version 2.5

I've also noticed that mkgmap ignores the key Routeparam because it expects 
RouteParam.
I guess it should ignore case as with some other key words?

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Montag, 17. Oktober 2022 14:53
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

pon., 17 paź 2022 o 14:46 Gerd Petermann
 napisał(a):
>
> Hi Piotr,
>
> I am a bit confused. The map file 48240001.img is in NT format. Can you 
> really create that with cgpsmapper?
> If you are able to create that in the older IMG format please do that. It 
> will help me to understand what mkgmap
> has to write, but note that mkgmap cannot write NT format.

Hi Gerd,
AFAIR it is not NT format, but rather NI format - sort of new index
format. As I understood Stanisław Kozicki emails from many years ago,
real NT format had never been decoded by him, but he introduced new
indexes format or something I am not entirely sure. It was really
created with cgpamapper.
Take care
Piotr
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

I am a bit confused. The map file 48240001.img is in NT format. Can you really 
create that with cgpsmapper?
If you are able to create that in the older IMG format please do that. It will 
help me to understand what mkgmap
has to write, but note that mkgmap cannot write NT format.

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Sonntag, 16. Oktober 2022 19:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

niedz., 16 paź 2022 o 17:56 Gerd Petermann
 napisał(a):
>
> Hi Piotr,
>
> I've downloaded the file. I'll have a closer look during the next days.

Hi Gerd,
Thanks a lot. Just for information. Regarding [SIGN], theoretically
SignParam should decide wheter the info is Toward (if it starts from
T,). Exit (if it starts from E.) or onto (if it starts from O,), but
for unknown for me reason cgpamapper generates only Toward message.
Cheers
Piotr
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

I've downloaded the file. I'll have a closer look during the next days.

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Sonntag, 16. Oktober 2022 13:26
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

sob., 15 paź 2022 o 16:00 Gerd Petermann
 napisał(a):
>
> Hi Piotr,
>
> reg. [SIGN]: I think we support this with OSM files, so there should be code 
> to write the data,
> but the current code ignores [SIGN] in *.mp input. So, yes, would be good to 
> have a working example.
> Please make it small, just a few cities, not a full map of Poland ;) I think 
> I just need the *.img file,
> but you can also provide all the output from cgpsmapper.

Files uploaded
https://files.mkgmap.org.uk/detail/558
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Test if POI is part of a line

[Gerd Petermann]

Hi Felix,

I do understand that one would want to avoid rendering gates which are not on 
highways, but I don't understand why you care about
the effect on routing. That's a completely different story and I think mkgmap 
handles this very well with the --link-pois-to-ways option.
Or maybe you mean something else?

A barrier node should never be connected to more than one way, else it is a 
mapping error and mkgmap reports this in the log (if enabled).
It should be a rare case and thus I see no need to add lots of logic to avoid 
the rendering.
The corresponding nodes should be fixed in OSM.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Samstag, 15. Oktober 2022 18:36
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

> I would only like to display barrier/highway=gate point icons if they are 
> part of a (best routable) line.

Since I try to declutter my maps as best as possible I too had "remove 
non-relevant gates" on my to do list and followed up on that today.
Accounting for points mapped on or between ways and access restrictions 
optionally stemming from point and/or way I was able, to already thin out my 
gates significantly. The include file is just "re-used" from my lines 
processing.

# NoAccess gates on relevant highways
# only works w/ mkgmap option --add-pois-to-lines
if (mkgmap:from-node:barrier ~ '.*(gate)' & highway=*) then
# gate on highway
   include "../inc/RaceSurf";
   # tagging of (preselected) elements w/ hgh:surface=(Race|noRace)
   # depending on quality in regard to race (and gravel) bike use

  if (hgh:surface=Race) then
   (mkgmap:from-node:access ~ 'no|private
& !(mkgmap:from-node:bicycle ~ 'yes|permissive')
...)
  # relevant access restricted by point
 |
   (access ~ 'no|private'
& !(bicycle ~ 'yes|permissive')
...)
 # relevant access restricted by road segment

 [...]
  end
end

But I was not able, to solve the probably most interesting situation:
If a (gate) point is part of two (or more) consecutive ways, it is processed 
multiple times from --add-pois-to-lines, but one would need the tags of all 
ways involved at the same time to make the final decision on whether or not to 
render this point. (That is -for starters-, if not at least two ways were 
deemed interesting, the gate might not be rendered although from one way alone, 
it would).

Is there a concept, allowing to do that?

The only idea I came up with would be, to use the mkgmap:line2poitype tag to 
flag these POIs somehow and finally delete all, if not at least 2 of those 
where placed at the exact same location. Somewhat similar to deleting identical 
POIs at the same location as documented for the nearby-poi-rules. In the latter 
case (>2), delete all but one...

Cheers, Felix
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

reg. [SIGN]: I think we support this with OSM files, so there should be code to 
write the data,
but the current code ignores [SIGN] in *.mp input. So, yes, would be good to 
have a working example.
Please make it small, just a few cities, not a full map of Poland ;) I think I 
just need the *.img file,
but you can also provide all the output from cgpsmapper.

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Freitag, 14. Oktober 2022 22:13
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

pt., 14 paź 2022 o 20:24 Gerd Petermann
 napisał(a):
> Hi Piotr,
> yes, with *.mp files this should be easier. Please provide a sample input and 
> desccribe the expected result
> and also attach the output from cgpsmapper.
> You can upload a zipp here: https://files.mkgmap.org.uk/

That could be possible. What is enough for you, just an img file, or
all files required by Mapsource/Basecamp? Additionally, cgpsmapper
will also include data for [SIGN] sections that allows to control what
is printed on the top bar of garmin devices (eg, Exit 2 toward XXX). I
wonder how difficult would it be to support this feature as well.
Piotr
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Indexing street belonging to two cities

[Gerd Petermann]

Hi Piotr,

yes, with *.mp files this should be easier. Please provide a sample input and 
desccribe the expected result
and also attach the output from cgpsmapper.
You can upload a zipp here: https://files.mkgmap.org.uk/

Gerd


Von: mkgmap-dev  im Auftrag von Piotr 
Wawrzyniak 
Gesendet: Freitag, 14. Oktober 2022 20:02
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Indexing street belonging to two cities

pt., 14 paź 2022 o 15:31  napisał(a):
> this probem exists probably around the world. Some mappers split OSM ways at 
> boundaries
> to solve this.

Hi Gerd,
So if I understood correctly it is mainly a data problem not a
compiler problem itself. I am using mkgmap for compiling mp files, so
streets location is clear. As I said cgpsmapper supports this type of
street sharing using @ within cityname. Presently I am compiling
source with cgpsmapper, but I would like to use mkgmap for this
purpose, as for new Garmin receivers there are better voice commands
(especially keep right/left works as it should). I know that mkgmap is
mainly for osm sources, but do you think it would be possible add this
feature for mp files?

Cheers
Piotr
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Test if POI is part of a line

[Gerd Petermann]

Hi (another) Felix,

yes, you can omit the clause mkgmap:line2poi=true.
I've only added this check to make clearer that the rule only works with the 
--add-pois-to-lines option.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Herwegh 
Gesendet: Montag, 10. Oktober 2022 21:39
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

Hey,

I'm new here (Hello!), so please be patient if I'm missing points ;-)

@ Felix

> ...so I will put useless [] symbols into the map - as there is no way to 
> check whether or not it is attached to a routable line.

But couldn't you check whether the line the point is attached to later on would 
become a routable line? Basically, because the points inherit all tags from the 
lines when using --add-poi-to-lines, by running through the same decision tree 
that (later on) is used in the lines file already in the points file? Optimally 
from some clever include file to avoid redundancy?

@ Gerd

> mkgmap:line2poi=true & highway=* & mkgmap:from-node:barrier=gate [...]

Why is "mkgmap:line2poi=true" required? Shouldn't only acting on 
mkgmap:from-node:barrier=gate in conjunction with the lines tag suffice here?

Cheers

another Felix


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Test if POI is part of a line

[Gerd Petermann]

Hi Eric,

the option --add-pois-to-lines is operates on the nodes of the ways before any 
style rules were executed. So,
whatever you do in the lines rules has no effect on the generated points.

Gerd


Von: mkgmap-dev  im Auftrag von 
ankeric@gmail.com 
Gesendet: Montag, 10. Oktober 2022 12:59
An: 'Development list for mkgmap'
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

Hi Gerd,

I also have a - similar? - issue implementing poi2line.
I cannot Add or Delete poi2line nodes.

Perhaps (as you said):
"One problem with your suggested solution is that the current implementation in 
mkgmap processes (tagged) nodes before lines".

In 'lines' this is working OK:

access:conditional = 'no @ sunset-sunrise'  { delete access:conditional }
access:conditional = 'no @ sunset - sunrise'{ delete access:conditional }
access:conditional = 'no @ (sunset-sunrise)'{ delete access:conditional }
access:conditional = 'no @ (sunset - sunrise)'  { delete access:conditional }

opening_hours  = '24/7'{ delete 
opening_hours }
opening_hours  = '(24/7)' { delete 
opening_hours }

and 50 more lines of script because these tags are useless and/or polluting the 
map and/or default and/or needless. IMO!

But once I add 'omsid()=...' to mkgmap it doesn't work anymore to remove 
line2poi.

highway=unclassified & osmid()=912437951 {delete smoothness; delete 
opening_hours}

In next example I delete all tags (don't want to render this highway), highway 
is deleted (not rendered) but line2poi is still rendered.

highway=cycleway & osmid()=1011546906 {deletealltags}

I also cannot ADD a line2poi tag:

highway=unclassified & osmid()=176775241 {set opening_hours="may be closed 
during sport events"}

I want to add private tags (line2poi), IMO tags, subjective tags, 'necessary' 
tags (IMO) that are not allowed on OSM (f.i.: bicycle=dismount, scenic=yes, 
which are only 'allowed' if a (traffic)sign is 'on the ground' to confirm 
dismount/scenic).

AnkEric

-Original Message-
From: mkgmap-dev  On Behalf Of Gerd 
Petermann
Sent: maandag 10 oktober 2022 12:49
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Test if POI is part of a line

Hi Felix,

the current implementation of the link-pois-to-ways doesn't transfer the access 
tag(s) to the way. It just creates a route restriction which tells Garmin that 
it must not route the given vehicles through the barrier. Older implementations 
created a short stub close to the barrier node.

Gerd



Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 10. Oktober 2022 12:13
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

Also I don't like using --link-pois-to-ways to put an access=private onto a 
road - and then remove this road. Because in the case of a park - the 
footways/pathes on both sides of the gate do exist. So an access=private does 
not actually apply to the road. So it's correct to show the road, and show the 
gate that is blocking the road. I think this is better that deleting that road 
because of the gate.

On Mon, 10 Oct 2022 at 11:47, Felix Hartmann 
mailto:extremecar...@gmail.com>> wrote:
Hi Gerd,

No  --add-poi-to-lines creates points from a line that has certain tags. What I 
try to achieve is actually to remove points that are NOT part of a line / or  
part of a line that is not rendered in the map. There is no reason to show a 
gate if you don't have a line/road.So essentially for me there is no sense to 
show a gate for me if it is not part of a routable line.
However points created by add-pois-to-lines are also not what I want - because 
it would show the gate in an incorrect position.

So the clutch of using --link-pois-to-ways  to get the access tags onto the 
line - then never show an actual barrier=gate/highway=gate but only show one 
created by the --add-poi-to-line command?  The logical solution is to really 
only show a gate where it is tagged, but only if the map is creating a routable 
line for it and remove all other barrier=* / highway=gate / entrance=yes POI.


If this is too much work to implement - then drop it. But as far as I 
understand right now there is no good solution by mkgmap for this. The same 
would be for traffic lights - if you remove a road because your map does not 
show private roads - but a private road has a traffic light - this traffic 
light should not be in the map either. And yes I know the dilemma - we need 
points to be looked at pre lines for --link-pois-to-ways to work, but for some 
other things we would need to look at them later again. So this would need to 
be some kind of seond_finalize rules in the points file that is executed after 
the lines file - and removes points from the map again. It's not a big problem 
- but right now this really makes it i

Re: [mkgmap-dev] Test if POI is part of a line

[Gerd Petermann]

Hi Felix,

please check the docu for special tag mkgmap:from-node:attname . I think this 
allows to filter a barrier node which on a highway.
A rule in points like this should work with option --add-pois-to-line:

mkgmap:line2poi=true & highway=* & mkgmap:from-node:barrier=gate [...]

I didn't try it but this should only render the generated points from ways with 
highway=* and a tag barrier=gate on the node.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 10. Oktober 2022 11:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

Hi Gerd,

No  --add-poi-to-lines creates points from a line that has certain tags. What I 
try to achieve is actually to remove points that are NOT part of a line / or  
part of a line that is not rendered in the map. There is no reason to show a 
gate if you don't have a line/road.So essentially for me there is no sense to 
show a gate for me if it is not part of a routable line.
However points created by add-pois-to-lines are also not what I want - because 
it would show the gate in an incorrect position.

So the clutch of using --link-pois-to-ways  to get the access tags onto the 
line - then never show an actual barrier=gate/highway=gate but only show one 
created by the --add-poi-to-line command?  The logical solution is to really 
only show a gate where it is tagged, but only if the map is creating a routable 
line for it and remove all other barrier=* / highway=gate / entrance=yes POI.


If this is too much work to implement - then drop it. But as far as I 
understand right now there is no good solution by mkgmap for this. The same 
would be for traffic lights - if you remove a road because your map does not 
show private roads - but a private road has a traffic light - this traffic 
light should not be in the map either. And yes I know the dilemma - we need 
points to be looked at pre lines for --link-pois-to-ways to work, but for some 
other things we would need to look at them later again. So this would need to 
be some kind of seond_finalize rules in the points file that is executed after 
the lines file - and removes points from the map again. It's not a big problem 
- but right now this really makes it inconvenient to put gates into your map - 
as 75% of gates are just cluttering up the map without providing any 
information to the user (except if you want to create a cataster type of map 
showing everything). Leaving gates out completely on the other hand makes it 
very ha
 rd to show for example with parks where people can enter and where not. As 
very often there are service entries to parks not open to public - so these are 
the main ones that we want to show in a map.

On Mon, 10 Oct 2022 at 08:35, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

my first thought was that --add-poi-to-lines is all that you need, but maybe 
I've missed something?

One problem with your suggested solution is that the current implementation in 
mkgmap processes
(tagged) nodes before lines. I can't remember exactly why but a change probably 
causes side effects.

Gerd



Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Freitag, 7. Oktober 2022 23:12
An: Development list for mkgmap
Betreff: [mkgmap-dev] Test if POI is part of a line

I read through the old
poi-tagged-v3.patch

is_in()function for point on line discussion - but what I want is actually 
different and should be much easier?

Could there be a solution to check if a point is a single point vs if it is 
part of a open/closed line?
Why?

I would only like to display barrier/highway=gate point icons if they are part 
of a (best routable) line. Especially for gates  most are just useless clutter 
because they are tagged on private houses and similar.

If there was a way to delete afterwards/or create only in first place those 
points that are part of a line would be good, best would be if they are only 
shown if part of a routable line (so after the lines stye-file is processed).

--
Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Test if POI is part of a line

[Gerd Petermann]

Hi Felix,

the current implementation of the link-pois-to-ways doesn't transfer the access 
tag(s) to the way. It just creates a route restriction which tells Garmin
that it must not route the given vehicles through the barrier. Older 
implementations created a short stub close to the barrier node.

Gerd



Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 10. Oktober 2022 12:13
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Test if POI is part of a line

Also I don't like using --link-pois-to-ways to put an access=private onto a 
road - and then remove this road. Because in the case of a park - the 
footways/pathes on both sides of the gate do exist. So an access=private does 
not actually apply to the road. So it's correct to show the road, and show the 
gate that is blocking the road. I think this is better that deleting that road 
because of the gate.

On Mon, 10 Oct 2022 at 11:47, Felix Hartmann 
mailto:extremecar...@gmail.com>> wrote:
Hi Gerd,

No  --add-poi-to-lines creates points from a line that has certain tags. What I 
try to achieve is actually to remove points that are NOT part of a line / or  
part of a line that is not rendered in the map. There is no reason to show a 
gate if you don't have a line/road.So essentially for me there is no sense to 
show a gate for me if it is not part of a routable line.
However points created by add-pois-to-lines are also not what I want - because 
it would show the gate in an incorrect position.

So the clutch of using --link-pois-to-ways  to get the access tags onto the 
line - then never show an actual barrier=gate/highway=gate but only show one 
created by the --add-poi-to-line command?  The logical solution is to really 
only show a gate where it is tagged, but only if the map is creating a routable 
line for it and remove all other barrier=* / highway=gate / entrance=yes POI.


If this is too much work to implement - then drop it. But as far as I 
understand right now there is no good solution by mkgmap for this. The same 
would be for traffic lights - if you remove a road because your map does not 
show private roads - but a private road has a traffic light - this traffic 
light should not be in the map either. And yes I know the dilemma - we need 
points to be looked at pre lines for --link-pois-to-ways to work, but for some 
other things we would need to look at them later again. So this would need to 
be some kind of seond_finalize rules in the points file that is executed after 
the lines file - and removes points from the map again. It's not a big problem 
- but right now this really makes it inconvenient to put gates into your map - 
as 75% of gates are just cluttering up the map without providing any 
information to the user (except if you want to create a cataster type of map 
showing everything). Leaving gates out completely on the other hand makes it 
very ha
 rd to show for example with parks where people can enter and where not. As 
very often there are service entries to parks not open to public - so these are 
the main ones that we want to show in a map.

On Mon, 10 Oct 2022 at 08:35, Gerd Petermann 
mailto:gpetermann_muenc...@hotmail.com>> wrote:
Hi Felix,

my first thought was that --add-poi-to-lines is all that you need, but maybe 
I've missed something?

One problem with your suggested solution is that the current implementation in 
mkgmap processes
(tagged) nodes before lines. I can't remember exactly why but a change probably 
causes side effects.

Gerd



Von: mkgmap-dev 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com>>
Gesendet: Freitag, 7. Oktober 2022 23:12
An: Development list for mkgmap
Betreff: [mkgmap-dev] Test if POI is part of a line

I read through the old
poi-tagged-v3.patch

is_in()function for point on line discussion - but what I want is actually 
different and should be much easier?

Could there be a solution to check if a point is a single point vs if it is 
part of a open/closed line?
Why?

I would only like to display barrier/highway=gate point icons if they are part 
of a (best routable) line. Especially for gates  most are just useless clutter 
because they are tagged on private houses and similar.

If there was a way to delete afterwards/or create only in first place those 
points that are part of a line would be good, best would be if they are only 
shown if part of a routable line (so after the lines stye-file is processed).

--
Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


--
Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org



--
Felix Hartman - Outdoorm

Re: [mkgmap-dev] Test if POI is part of a line

[Gerd Petermann]

Hi Felix,

my first thought was that --add-poi-to-lines is all that you need, but maybe 
I've missed something?

One problem with your suggested solution is that the current implementation in 
mkgmap processes
(tagged) nodes before lines. I can't remember exactly why but a change probably 
causes side effects.

Gerd



Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Freitag, 7. Oktober 2022 23:12
An: Development list for mkgmap
Betreff: [mkgmap-dev] Test if POI is part of a line

I read through the old
poi-tagged-v3.patch

is_in()function for point on line discussion - but what I want is actually 
different and should be much easier?

Could there be a solution to check if a point is a single point vs if it is 
part of a open/closed line?
Why?

I would only like to display barrier/highway=gate point icons if they are part 
of a (best routable) line. Especially for gates  most are just useless clutter 
because they are tagged on private houses and similar.

If there was a way to delete afterwards/or create only in first place those 
points that are part of a line would be good, best would be if they are only 
shown if part of a routable line (so after the lines stye-file is processed).

--
Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Error: Node ids are not sorted.

[Gerd Petermann]

Hi Arndt,

I guess this was related to the SRTM data?

Gerd


Von: mkgmap-dev  im Auftrag von Arndt 
Röhrig 
Gesendet: Mittwoch, 14. September 2022 15:25
An: Development list for mkgmap
Betreff: [mkgmap-dev] Error: Node ids are not sorted.

HI @all,


Splitter recently reports the following error:
Error: Node ids are not sorted. Use e.g. osmosis to sort the input data.

I use the OSM-Data from Geofabrik. Older OSM Data from there works fine. Is 
that a temporally problem from Geofabrik or did they change anything?

Greetz
Arndt
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Too many icons from tourism=information & information=route_marker

[Gerd Petermann]

Hi all,

recently someone mapped lots of nodes like this: 
https://www.osm.org/node/9842107614
in my area. With the default style they are rendered as an info icon and the 
text from the operater tag "Wiehengebirgsverband Weser-Ems e.V."
which is really useless info.

The actual marker is a maybe 10*5 cm black sticker with a white "J", no further 
information. 
I think we should change the rule 
tourism=information [0x4c00 resolution 24]
to
tourism=information & information!=route_marker [0x4c00 resolution 24]
so that these markers are not rendered.
Or maybe set mkgmap:label1 to the ref so that they are less prominent?

Gerd

Gerd

 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Outlines of states/provinces

[Gerd Petermann]

Hi Steven,

in addition to Tickers reply there are these lines in the relations file
# Names of administrative boundaries.
# We could want to sort the relations in ascending order of admin_level
# and alphabetically by name first.
# Currently, the matching relations will be processed and the names
# appended to the boundary lines in an arbitrary order.

(type=boundary | type=multipolygon) & boundary=administrative & name=*
{ apply
  {
set mkgmap:boundary_name='$(mkgmap:boundary_name)/${name}' | '${name}';
  }

Note that many (most?) ways with type=boundary are members in two or more 
relations. See e.g. https://www.openstreetmap.org/way/78508178
The above rule collects the names with the separator / between.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Montag, 8. August 2022 10:12
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Outlines of states/provinces

Hi Steve

Assuming you haven't overridden the default style, these boundary lines
are triggered by:

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]
boundary=national [0x1e resolution 17]
boundary=political [0x1c resolution 19]

which you can see in file {mkgmap}\examples\styles\default\lines around
line 245

Ticker

On Sun, 2022-08-07 at 21:07 +, Steven Miller wrote:
> I’m new to mkgmap and am still learning the basics. Having said that,
> I’ve downloaded the US-South sub-region from geofabrik.de and I can
> see a country dividing line or boundary between the state of Texas
> and Mexico. It’s a thin grey line. I’d like to know how to create
> these boundaries. Can anyone provide a brief overview of how to go
> about this? I know this question demonstrates a real lack of
> knowledge about how this whole thing works, but I’m learning as I go.
>
> Thanks a bunch, for anyone willing to tackle this ;-)
>
> Steve
>
> Steven Miller
> srm...@hotmail.com
> (717) 562-2879
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Multiple pass cleanup possible with style?

[Gerd Petermann]

It is possible and my understanding is that the special tags work well.

Please give an example (link to the OSM way that your style doesn't convert to 
a routable line)
and a link to the OSM way(s) that mkgmap doesn't change because of the setting 
in tag
mkgmap:set_unconnected_type or mkgmap:set_semi_connected_type.
Describe exactly what you expect to happen and what happens instead.

Something like
My style adds the tag mkgmap:set_semi_connected_type=none to way 12345678
and the way should only be connected to 4711 but
mkgmap still add's it to the map with the type 0x07.

Gerd


Von: mkgmap-dev  im Auftrag von blc 

Gesendet: Samstag, 23. Juli 2022 01:48
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Multiple pass cleanup possible with style?

I'm not sure the issue is clear.

The problem is I delete objects that once was fully connected (both ends
are connected but meets other criteria for deletion) but after deleting
that object, the remaining objects now have a different status - and these
now need to be cleaned up based by my rules ... which as I understand
would require a second pass through the style (which is problematic of
course, but that's another issue).  This is because a way that used to be
fully connected is could now only connected on one end, and some ways that
were only connected on one end is now connected on neither end.

The OSM-ways I want to delete may not have met the requirements on the
first pass, but now do after the initial pruning.

If this is simply not possible, that's all I need to know.  Sounds like
this is the case.


On Fri, 22 Jul 2022, Gerd Petermann wrote:

> Date: Fri, 22 Jul 2022 19:24:48 +
> From: Gerd Petermann 
> Reply-To: Development list for mkgmap 
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Multiple pass cleanup possible with style?
>
> I am pretty sure that you don't understand the meaning of the special tags.
> Your style tells mkgmap which ways are roads. So, only after passing all
> OSM ways through your style mkgmap can calculate the road network and
> only at this time it is possible to detect unconnected or "semi-connected" 
> roads
> and use the value of the special tags to decide what to do with special cases.
>
> My understanding of your text is that you expect the special tags to contain 
> an
> information like "this OSM way is connected to the road network" but that's 
> not the
> case. The program mkgmap reads the variables, it doesn't set them.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von blc 
> 
> Gesendet: Freitag, 22. Juli 2022 21:00
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Multiple pass cleanup possible with style?
>
> I've used the mkgmap:set_unconnected_type and
> mkgmap:set_semi_connected_type to delete already one- and no-connnect ways
> in the OSM data, and that has been helpful, but sometimes I delete ways
> that are connected both ends, with the implication that something now
> that used to be connected on both ends is connected only on one end now,
> and something else that was connected on one end may now be not connected
> on either end.
>
> I think a specific use case is that I find a 2-connect low priority way
> (like service=driveway) that passes through a private building or is very
> short.  Ideally I would like to simply delete all of them but this is
> just a heuristic to reduce file sizes.  Anyway, I delete that way, but
> that way continues on connected to something else, but now that way is
> newly 1- or 0-connect, and I want that removed too.  Of course there are
> two halves left when removing a 2-connect way, but it should be easy
> enough to determine the lower class way (another driveway) is the one that
> should also be trimmed.
>
> (One exact issue is that someone has a loop driveway with both ends
> connected to a residential road, and the loop driveway has an offshoot.
> Removing the driveway would leave the offshoot dangling -- originally one
> connect, now zero connect due to deletion of the loop -- and that I would
> also like to remove.)
>
> Is something like this possible?

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Multiple pass cleanup possible with style?

[Gerd Petermann]

I am pretty sure that you don't understand the meaning of the special tags.
Your style tells mkgmap which ways are roads. So, only after passing all
OSM ways through your style mkgmap can calculate the road network and
only at this time it is possible to detect unconnected or "semi-connected" roads
and use the value of the special tags to decide what to do with special cases.

My understanding of your text is that you expect the special tags to contain an
information like "this OSM way is connected to the road network" but that's not 
the
case. The program mkgmap reads the variables, it doesn't set them.

Gerd


Von: mkgmap-dev  im Auftrag von blc 

Gesendet: Freitag, 22. Juli 2022 21:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Multiple pass cleanup possible with style?

I've used the mkgmap:set_unconnected_type and
mkgmap:set_semi_connected_type to delete already one- and no-connnect ways
in the OSM data, and that has been helpful, but sometimes I delete ways
that are connected both ends, with the implication that something now
that used to be connected on both ends is connected only on one end now,
and something else that was connected on one end may now be not connected
on either end.

I think a specific use case is that I find a 2-connect low priority way
(like service=driveway) that passes through a private building or is very
short.  Ideally I would like to simply delete all of them but this is
just a heuristic to reduce file sizes.  Anyway, I delete that way, but
that way continues on connected to something else, but now that way is
newly 1- or 0-connect, and I want that removed too.  Of course there are
two halves left when removing a 2-connect way, but it should be easy
enough to determine the lower class way (another driveway) is the one that
should also be trimmed.

(One exact issue is that someone has a loop driveway with both ends
connected to a residential road, and the loop driveway has an offshoot.
Removing the driveway would leave the offshoot dangling -- originally one
connect, now zero connect due to deletion of the loop -- and that I would
also like to remove.)

Is something like this possible?

On Fri, 22 Jul 2022, Gerd Petermann wrote:

> Date: Fri, 22 Jul 2022 15:35:43 +
> From: Gerd Petermann 
> Reply-To: Development list for mkgmap 
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Multiple pass cleanup possible with style?
>
> Hi,
>
> not sure what exactly you want to do, but I think the special tags 
> mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type
> help to solve your problem.
>
> With thoe you can define that a road should be removed or just be rendered as 
> a non-routable line if it is not connected to other roads or
> only connected to one other road.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von blc 
> 
> Gesendet: Freitag, 22. Juli 2022 16:26
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] Multiple pass cleanup possible with style?
>
> Is it possible to run through certain parts of the style more than once?
>
> Use model:
>
> To reduce sizes I {deletealltags} of some small objects that I deem not
> important.  However this sometimes ends up leaving some orphan
> ways that are no longer connected to anything.  I'd like to delete these
> ways too, but seems like it does everything in one pass so these get left
> despite having a rule to remove them.
>
> How would one do something like this?  I don't think I want to do this
> more than a few times but cleaning up the self-inflicted orphaned ways
> would be helpful.
>
> Thanks!
> ___
> 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
>

WARNING: All HTML emails get auto deleted.  DO NOT SEND HTML MAIL.
WARNING: Emails with large typo counts/spelling errors will also be deleted.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Multiple pass cleanup possible with style?

[Gerd Petermann]

Hi,

not sure what exactly you want to do, but I think the special tags 
mkgmap:set_unconnected_type and mkgmap:set_semi_connected_type
help to solve your problem.

With thoe you can define that a road should be removed or just be rendered as a 
non-routable line if it is not connected to other roads or
only connected to one other road.

Gerd


Von: mkgmap-dev  im Auftrag von blc 

Gesendet: Freitag, 22. Juli 2022 16:26
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Multiple pass cleanup possible with style?

Is it possible to run through certain parts of the style more than once?

Use model:

To reduce sizes I {deletealltags} of some small objects that I deem not
important.  However this sometimes ends up leaving some orphan
ways that are no longer connected to anything.  I'd like to delete these
ways too, but seems like it does everything in one pass so these get left
despite having a rule to remove them.

How would one do something like this?  I don't think I want to do this
more than a few times but cleaning up the self-inflicted orphaned ways
would be helpful.

Thanks!
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Re: Showing labels next to POIs on Garmin Map

[Gerd Petermann]

Hi Raphael,

I think it's up to the firmware how certain POI types are rendered at a given 
zoom level.
So, maybe you just have to use the same type as the default style?

Gerd


Von: mkgmap-dev  im Auftrag von Raphael 
Viol 
Gesendet: Freitag, 22. Juli 2022 10:12
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev]  Re:  Showing labels next to POIs on Garmin Map

Hi Ticker,

I'm not sure if I can attach images here, so I could show you this evening what 
I'm talking about.
I don't understand so far why it works for some POIs already like hotels and 
peaks but shops and restaurants still don't show the name in the map directly.

But I will try your hint later.
Am 22.07.22, 10:09 schrieb Ticker Berkin :
Hello Raphael

I'm not quite sure what you mean but the variable mkgmap:label:1 put
the label information into the map. This can be set directly and the
name command also sets it

The default style has, in the  section of
points/lines/polygons, the command:

name=* {name '${name}'}

Ticker

On Thu, 2022-07-21 at 21:23 +0200, vio...@web.de wrote:
> Hey everyone,
>
> if I am using the default style files of mkgmap (e.g. from 4905) I am
> having the names of the different POIs (like shops, doctors,
> parkings, ...) next to the POI directly on the map.
> I cannot figure out which command it is, so I can also have it on my
> own style files, can someone help?
>
> Thanks in advance!
> Best regards,
> Raphael
> ___
> 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