Re: [mkgmap-dev] Help with registry for Basecamp

[Felix Hartmann]

If you use gmapi format there are however also many disadvantages. Cannot
quickly create a gmapsupp.img with mkgmap. Export of gmapsupp.img with
MapInstall is slower while some other things are just different. It's more
complicated to find bugs with multiple maps (if for example you do not move
them by hand but by Garmin Mapinstall - and then some maps are in user and
some in general folder. There are actually several folders that are
possible to be used).
I personally really prefer the old format and using registry vs and
info.xml and gmapi format. Best of both would be if you could .img format
together with info.xml instead of registry. Sadly that isn't possible.

On Mon, 27 Feb 2023 at 01:04, Dave Jackman  wrote:

> Hi Diego,
>
> Rather than having to edit the registry use the –gmapi option in mkgmap
> which will create a folder with a .gmap extension. Copy or move this folder
> to C:\ProgramData\Garmin\Maps and the map will be visible to Basecamp. Note
> ProgramData is a hidden folder.
>
> This avoids having to edit the registry or create reg files.
>
> Cheers
> Dave
>
>
>
> *From:* dd...@gmx.de
> *Sent:* 26 February 2023 18:54
> *To:* mkgmap-dev@lists.mkgmap.org.uk
> *Reply to:* mkgmap-dev@lists.mkgmap.org.uk
> *Subject:* Re: [mkgmap-dev] Help with registry for Basecamp
>
> Hi all
>
> for all registration stuff concerning mapinstallation for mapsource and
> therefore also for Basecamp i use a programm called MapsetToolkit.
>
> Its working on all Windows Versions 10 and 11 since i use maps created by
> mkgmap
>
>
> Am 26.02.2023 um 17:21 schrieb skelter helter:
>
> Hello
> I need some help with this email from Eric sent here on the list some
> weeks ago:
>
> *If you are creating mkgmap tiles and you do not need to distribute your
> map to others, then the NSIS installer is not required.*
>
> *Initial installation requires importing registration data (.reg file).*
>
> *Creating an NSIS installer takes time and then installing
> setup.exe  also takes time.*
>
>
>
> *For instance:*
>
>
>
> *Windows Registry Editor Version 5.00*
>
>
>
>
> *[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Garmin\MapSource\Families\BIKE_Benelux]*
>
> *"ID"=hex:4a,9c*
>
> *"IDX"="G:\\BaseCamp\\BIKE_Benelux\\4001.mdx "*
>
> *"MDR"="G:\\BaseCamp\\BIKE_Benelux\\4001_mdr.img "*
>
> *"TYP"="G:\\BaseCamp\\BIKE_Benelux\\40010.TYP "*
>
>
>
>
> *[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Garmin\MapSource\Families\BIKE_Benelux\1]*
>
> *"BMAP"="G:\\BaseCamp\\BIKE_Benelux\\4001.img "*
>
> *"LOC"="G:\\BaseCamp\\BIKE_Benelux"*
>
> *"TDB"="G:\\BaseCamp\\BIKE_Benelux\\4001.tdb "*
>
>
> Is there a way to create the REG file with Mkgmap, or do I have to create
> it by myself after generating the map ? If so, what is the meaning of the
> ID value and how do I choose the right one ?
>
> Thank you !!
> Diego
> --
> *Da:* mkgmap-dev 
>  per conto di
> mkgmap-dev-requ...@lists.mkgmap.org.uk
> 
> 
> *Inviato:* giovedì 2 febbraio 2023 12:00
> *A:* mkgmap-dev@lists.mkgmap.org.uk 
> 
> *Oggetto:* mkgmap-dev Digest, Vol 175, Issue 3
>
> Send mkgmap-dev mailing list submissions to
> mkgmap-dev@lists.mkgmap.org.uk
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
> or, via email, send a message with subject or body 'help' to
> mkgmap-dev-requ...@lists.mkgmap.org.uk
>
> You can reach the person managing the list at
> mkgmap-dev-ow...@lists.mkgmap.org.uk
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of mkgmap-dev digest..."
>
> ___
> mkgmap-dev mailing 
> listmkgmap-...@lists.mkgmap.org.ukhttps://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
>


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

[mkgmap-dev] Farsi conversion/codepage - Iran 1256 v 1256 extended

[Felix Hartmann]

In Iran there are a few characters that are super common but not in
codepage 1256. It's characters that belong to ARABIC LETTER FARSI YEH

Below is an example
https://r12a.github.io/app-analysestring/?chars=%D9%86%DB%8C%D8%A7%D8%B4
نیایش

character: U+06CC 

But I don't really know if there is a better solution for Iran outside of
unicode than 1256...
Found this character also discussed here:
https://stackoverflow.com/questions/8863422/cp1256-converts-persian-yeh-to-arabic-yeh

I think there is also an extended version of 1256 - could mkgmap change to
1256 extended? I think this is what is mentioned on here:
https://en.wikipedia.org/wiki/Windows-1256
I guess 06CC is part of the extended 1256 and some other arabic countries
are affected too.


Not sure if there is something that can be done or not. But right now for
Iran non unicode maps read quite badly - especially due to 06CC.
-- 
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] Deathloop on splitting file created by splitter if using argentina.poly --polygon-file

[Felix Hartmann]

Hi Gerd,

well it got stuck for at least 30 hours on a Ryzen 5 3600 - so not sure it
ever finds a solution. Is it ever helpful to use a polygon for resplitting
tiles? I guess for resplitting the polygon is not helpful anyhow so I just
resplit without polygon-file in general.
Thanks for looking into it.

Felix

On Sun, 18 Dec 2022 at 21:47, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> I am not yet sure what goes wrong. Maybe it is not an endless loop but a
> very slow one which tries again and again similar
> bad splits.
>
> Problem is the polygon which contains large, almost empty areas. I think
> you should never use it when you re-split.
>
> Gerd
>
> ____
> Von: Felix Hartmann 
> Gesendet: Sonntag, 18. Dezember 2022 12:14
> An: Gerd Petermann
> Betreff: Re: [mkgmap-dev] Deathloop on splitting file created by splitter
> if using argentina.poly --polygon-file
>
> Well hope you can find the problem, i think it's the second time I have
> this kind of problem but cannot remember right now on which other country
> it happened.
>
> On Sun, 18 Dec 2022, 17:36 Gerd Petermann  <mailto:gpetermann_muenc...@hotmail.com>> wrote:
> Hi Felix,
>
> seems I used version 651 instead of 652. I can reproduce your results now.
>
> Gerd
>
> 
> Von: Felix Hartmann  extremecar...@gmail.com>>
> Gesendet: Samstag, 17. Dezember 2022 15:48
> An: gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> >
> Betreff: Re: [mkgmap-dev] Deathloop on splitting file created by splitter
> if using argentina.poly --polygon-file
>
> I used the most up to date argentia.poly - That*s very strange. For me
> it*s getting stuck on calculating areas forever (using next to 0 CPU and
> RAM).
> I'm using oracle java and not openjdk however - can that make a
> difference? I just updated to oracle Java SDK 17.05 from 16.01. but it
> stays the same.
>
> Here is the start of my output:
> D:\openmtbmap\maps>start /belownormal /b /wait java -Xmx4000m -jar
> C:\openmtbmap\splitter.jar --max-nodes=140 --max-threads=11
> --search-limit=100 --output=o5m
> --geonames-file=E:\openmtbmap\osmpbf_geofabrik\cities5000.zip
> --polygon-file=E:\OpenMTBMap\osmpbf_geofabrik\argentina.poly
> --description=argentina --mapid=64700017 "64700010.o5m"
> Splitter version 652 compiled 2022-06-17T08:25:16+0100
> boundary-tags=use-exclude-list
> cache=
> description=argentina
> geonames-file=E:\openmtbmap\osmpbf_geofabrik\cities5000.zip
> handle-element-version=remove
> ignore-osm-bounds=false
> keep-complete=true
> mapid=64700017
> max-areas=2048
> max-nodes=140
> max-threads=11
> mixed=false
> no-trim=false
> num-tiles=
> output=o5m
> output-dir=
> overlap=auto
> polygon-desc-file=
> polygon-file=E:\OpenMTBMap\osmpbf_geofabrik\argentina.poly
> precomp-sea=
> problem-file=
> problem-report=
> resolution=13
> route-rel-values=
> search-limit=100
> split-file=
> status-freq=120
> stop-after=dist
> wanted-admin-level=5
> write-kml=
> Elapsed time: 0s   Memory: Current 1024MB (4MB used, 1020MB free) Max
> 4000MB
> Time started: Sat Dec 17 15:45:59 CET 2022
> Warning: Bounding polygon is complex. Splitter might not be able to fit
> all tiles into the polygon!
> Map is being split for resolution 13:
>  - area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
>  - areas are multiples of 0x800 map units wide and high
> Processing 64700010.o5m
> Bounding box -59.89746090006 -35.1123046 -56.73339840006 -34.453125
> Fill-densities-map pass took 203 ms
> Exact map coverage read from input file(s) is
> (-35.1123046875,-59.8974609375) to (-34.453125,-56.7333984375)
> Exact map coverage after applying bounding box of polygon-file is
> (-35.1123046875,-59.8974609375) to (-34.453125,-56.7333984375)
> Rounded map coverage is (-35.1123046875,-59.8974609375) to
> (-34.453125,-56.7333984375)
> Splitting nodes into areas containing a maximum of 1 400 000 nodes each...
> splitting none
> Highest node count in a single grid element is 98 584
> Highest node count in a single grid element within the bounding polygon is
> 98 584
> Splitting tile (-35.1123046875,-57.83203125) to
> (-34.4970703125,-57.744140625) with 3 972 nodes, goal is to get near 1 tiles
> S2 FULL: step 1 goal: 1 tiles, now: 1 tile(s). The smallest node count is
> 3972 (0 %), cache size 0
> S2 FULL goal was 1 tiles, solver finished with : 1 tile(s). The smallest
> node count is 3972 (0 %)
> Solution is not nice. Can't find a better solution with search-limit
> 100: 1 tile(s). The smallest node co

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

[Felix Hartmann]

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] Test if POI is part of a line

[Felix Hartmann]

Not sure which Felix you meant. For me it was not about that poi
influencing the routing, but the opposite. If mkgmap created a reputable
line only then display the gate.

E.g. if excluded using semi-connected marker, then also remove the gate.
Typical scenario a highway=path entering a residence garden and the
highway=gate tag on the path.
What I want are gates for say a public garden or theme park, or similar.

On Sun, 16 Oct 2022, 23:18 Felix Herwegh  wrote:

> Hi Gerd,
>
> the quote ("best routable") was from Felix Hartmanns opening post. I just
> try to render my maps as focussed and decluttered as possible for keeping a
> bike rolling without loosing too much attention on the map while not using
> routing. But as far as I understand I see similarities in identifying
> objects to omit.
>
> In my question I was addressing situations similar to the example from the 
> Wikis
> barrier=gate section
>  (either with or
> without an additional barrier=fence or the like crossing), a barrier node
> being part of two ways hence being processed from both by
> --add-pois-to-lines.
>
> *Based on the location below, the gate node should be the end of a way. A
> new way starts with the gate node and it should have the access set to
> private if the access is restricted. *
>
> *x--x--Oxx
> *
>
>
>- *x** = node*
> - *O** = node with barrier=gate*
>- *--** default way*
>- *+** way with access=private*
>
> For example
>
> *Punkt: 17848298*
> *  Datensatz: 230db4cd*
> *  ...*
> *  Merkmale: *
> *"access"="private"*
> *"barrier"="gate"*
> *  Koordinaten: 54.1016042, 11.5995597*
> *  ...*
> *  Teil von: *
> *Linie: Dünenstraße (3629239)*
> *Linie: 546855848*
> *Linie: 81154811*
>
> Hence, having a gate between a bad track (later on not rendered due to
> quality, already filtered from the RaceSurf include) and an acces=no road
> (later on not rendered for just that) could have rendered an isolated gate
> from the latter road segment.
> That's where I took the problematic turn, trying to make a decision on all
> possible ways connecting a gate, instead of more consequently filtering all
> roads before having points derived from them in the first place. So another
> RelevantRoads include file for dual use in points and lines it will be.
>
> But:
> For my sample above, the gate then still will be rendered from the
> "Dünenstraße", although not needed, since "Dünenstraße" will just end there
> in my map because neither of lines 546855848 or 81154811 will be rendered.
> Honestly, I was additionally flirting with trying to use different icons
> for gates with and without a barrier line (fence), since those without and
> on suitable roads occasionally could just void nice shortcuts for a bike...
> :-)
>
> >I see no need to add lots of logic...
>
> Sorry, that was not my intention. I'm still searching my way into OSM and
> mkgmap and only wanted to make shure, not to miss an existing concept as
> more than once before. I should better have omitted that raw idea of mine,
> thought it might help understand my train of thought.
>
> Cheers, Felix
> --
> *From:* Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com
> ]
> *Sent:* Sunday, October 16, 2022 at 10:35 AM
> *To:* Development list for mkgmap
> *Subject:* [mkgmap-dev] Test if POI is part of a line
>
> 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

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

[Felix Hartmann]

I won't be able to test anything the next 2 weeks however. Traveling in
Nepal

On Tue, 1 Nov 2022, 15:29 Felix Hartmann  wrote:

> Not sure which Felix you meant. For me it was not about that poi
> influencing the routing, but the opposite. If mkgmap created a reputable
> line only then display the gate.
>
> E.g. if excluded using semi-connected marker, then also remove the gate.
> Typical scenario a highway=path entering a residence garden and the
> highway=gate tag on the path.
> What I want are gates for say a public garden or theme park, or similar.
>
> On Sun, 16 Oct 2022, 23:18 Felix Herwegh  wrote:
>
>> Hi Gerd,
>>
>> the quote ("best routable") was from Felix Hartmanns opening post. I just
>> try to render my maps as focussed and decluttered as possible for keeping a
>> bike rolling without loosing too much attention on the map while not using
>> routing. But as far as I understand I see similarities in identifying
>> objects to omit.
>>
>> In my question I was addressing situations similar to the example from
>> the Wikis barrier=gate section
>> <https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dgate> (either with or
>> without an additional barrier=fence or the like crossing), a barrier node
>> being part of two ways hence being processed from both by
>> --add-pois-to-lines.
>>
>> *Based on the location below, the gate node should be the end of a way. A
>> new way starts with the gate node and it should have the access set to
>> private if the access is restricted. *
>>
>> *x--x--Oxx
>> *
>>
>>
>>- *x** = node*
>> - *O** = node with barrier=gate*
>>- *--** default way*
>>- *+** way with access=private*
>>
>> For example
>>
>> *Punkt: 17848298*
>> *  Datensatz: 230db4cd*
>> *  ...*
>> *  Merkmale: *
>> *"access"="private"*
>> *"barrier"="gate"*
>> *  Koordinaten: 54.1016042, 11.5995597*
>> *  ...*
>> *  Teil von: *
>> *Linie: Dünenstraße (3629239)*
>> *Linie: 546855848*
>> *Linie: 81154811*
>>
>> Hence, having a gate between a bad track (later on not rendered due to
>> quality, already filtered from the RaceSurf include) and an acces=no road
>> (later on not rendered for just that) could have rendered an isolated gate
>> from the latter road segment.
>> That's where I took the problematic turn, trying to make a decision on
>> all possible ways connecting a gate, instead of more consequently filtering
>> all roads before having points derived from them in the first place. So
>> another RelevantRoads include file for dual use in points and lines it will
>> be.
>>
>> But:
>> For my sample above, the gate then still will be rendered from the
>> "Dünenstraße", although not needed, since "Dünenstraße" will just end there
>> in my map because neither of lines 546855848 or 81154811 will be rendered.
>> Honestly, I was additionally flirting with trying to use different icons
>> for gates with and without a barrier line (fence), since those without and
>> on suitable roads occasionally could just void nice shortcuts for a bike...
>> :-)
>>
>> >I see no need to add lots of logic...
>>
>> Sorry, that was not my intention. I'm still searching my way into OSM and
>> mkgmap and only wanted to make shure, not to miss an existing concept as
>> more than once before. I should better have omitted that raw idea of mine,
>> thought it might help understand my train of thought.
>>
>> Cheers, Felix
>> --
>> *From:* Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com
>> ]
>> *Sent:* Sunday, October 16, 2022 at 10:35 AM
>> *To:* Development list for mkgmap
>> *Subject:* [mkgmap-dev] Test if POI is part of a line
>>
>> 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
>>

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

[Felix Hartmann]

On Mon, 10 Oct 2022 at 22:05, ael  wrote:

> On Mon, Oct 10, 2022 at 09:39:11PM +0200, Felix Herwegh wrote:
>
>
> I have mapped gates in a fence/wall which are not on routable lines.
> These are very important if you are to find your way out of an enclosure
> or field. I am thinking of just such a place on a rugged hillside where
> the location of the gate can not be seen until quite close.
>

Are you sure this is correct tagging? I think this would merit a
highway=path - maybe with low visibility (key visibility)


>
> I want my OSM/garmin map to show me this sort of thing.
>
I'm not proposing this for the default style - any style is different and
everyone wants to filter different things. We cannot show even half of the
data that is inside OSM without ending up with a useless map - so every map
needs to filter according to it's use case. Most maps don't even show
barrier=gate / highway=gate in first place.

>
> ael
>
> ___
> mkgmap-dev mailing list
> 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

[Felix Hartmann]

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

--- I will give this a try. Is this implemented in the main branch? I
thought this tag was related to patch poi-tagged-v3.patch
and never accepted.

I had not fully understood how it worked however. Will try this out and see
if it can work (then if it works, instead of higwhay=* insert the list of
conditions that delete a road)

On Mon, 10 Oct 2022 at 14:45, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> 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 <
> gpetermann_muenc...@hotmail.com<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  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<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 the

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

[Felix Hartmann]

Ah okay thanks for the clarification - well okay then those ways are not
removed - except if they already have themselves an access=private on them.
However I cannot check this from the points file - so I will put useless
gate symbols into the map - as there is no way to check whether or not it
is attached to a routable line.

On Mon, 10 Oct 2022 at 12:48, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> 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 <
> gpetermann_muenc...@hotmail.com<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  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<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 solu

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

[Felix Hartmann]

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 
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 hard 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 <
> 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  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
>>
>
>
> --
> Felix Hartman - Outdoormaps LTD - Openmtbmap.org & VeloMap.org
>
>

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

[Felix Hartmann]

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


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

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

[Felix Hartmann]

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] Building display.jar fails

[Felix Hartmann]

yes I also don't see a need for the route relation name in the search - but
I do see it as a need to see the route names on tooltip for all routes that
use a way. That's why I mean I would like to add them into non searchable
labels.
Even though for certain ways - I would like them included - e.g.
Donauradweg - because quite often you would like to know where is the
nearest point of the Donauradweg or other international/famous routes - but
not for local ones.

Locally you would often say let's meet on the Donauradweg at the
intersection with X or restaurant XY on Donauradweg - not in a city like
Vienna, but in mid sized cities. Everyone knows then what is meant - and
that kinda should be searchable via address search. No-one locally knows
the actual street names (if they exist). So in case there is no street name
label, using a route name instead makes sense too.

On Mon, 13 Dec 2021 at 13:10, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> I still don't see a use case for the route names in road labels. I've
> never felt the need to find a route relation.
>
> I am pretty sure that it can produce all kinds of confusion when you
> search for an address and the result
> contains lots of unrelated stuff because there is a route relation that
> has a word in its name which starts
> with the same word.
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 13. Dezember 2021 12:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> okay - well I should try to find a way to put more content into the label
> 2-4 instead of 1 then. The cutoff is still good. Some routes have very long
> names.
>
> On Mon, 13 Dec 2021 at 12:43, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> the labels which are shown in MapSource / Basecamp search are those which
> are stored in MDR 15.
> We change them already with the --mdr7-del option but that doesn't help
> for the names of route relations.
> mkgmap reads the full labels from the LBL file in each map tile and
> calculates the string for MDR15.
> Still, MDR15 is not used with the device, so this only effects the PC
> programs.
> Roads have 4 labels, other objects have only 1. With roads, the
> first label is rendered, other labels are shown when you click on the road.
> All labels are indexed, and the --housenumber code sometimes adds labels
> so that addresses can be found.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Montag, 13. Dezember 2021 12:29
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> I tried a couple of places that are cut down to 170 characters - and some
> I can find in Mapsource or Basecamp, Others I cannot. So 170 is definitely
> too much for the search index. Is there a way to have separate label for
> search vs the label on tooltip/printed out on the label? For search it
> clearly should be less (both Mapsurce and Basecamp).
> In general it would be good to have a separation between name for search
> and name for the label. I know we have 4 labels, but I haven*t really
> understood which label is for what and where which label shows up.
>
> On Mon, 13 Dec 2021 at 11:46, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi Felix,
>
> okay, I've committed the changes with r4836.
> It would be good to know if these long strings cause trouble in MapSource.
> I wouldn't be surprised to find that they cause buffer overflows if Garmin
> doesn't expect more than N bytes, and that again can cause all kinds of
> trouble.
> Will try to reproduce the problem with a modified default style ...
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk> mkgmap-dev-boun...@lists.mkgmap.org.uk mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>
> Gesendet: Montag, 13. Dezember 2021 11:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> it's working fine for me too. But I haven't got around to testing if the
> length s

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

okay - well I should try to find a way to put more content into the label
2-4 instead of 1 then. The cutoff is still good. Some routes have very long
names.

On Mon, 13 Dec 2021 at 12:43, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> the labels which are shown in MapSource / Basecamp search are those which
> are stored in MDR 15.
> We change them already with the --mdr7-del option but that doesn't help
> for the names of route relations.
> mkgmap reads the full labels from the LBL file in each map tile and
> calculates the string for MDR15.
> Still, MDR15 is not used with the device, so this only effects the PC
> programs.
> Roads have 4 labels, other objects have only 1. With roads, the
> first label is rendered, other labels are shown when you click on the road.
> All labels are indexed, and the --housenumber code sometimes adds labels
> so that addresses can be found.
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 13. Dezember 2021 12:29
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> I tried a couple of places that are cut down to 170 characters - and some
> I can find in Mapsource or Basecamp, Others I cannot. So 170 is definitely
> too much for the search index. Is there a way to have separate label for
> search vs the label on tooltip/printed out on the label? For search it
> clearly should be less (both Mapsurce and Basecamp).
> In general it would be good to have a separation between name for search
> and name for the label. I know we have 4 labels, but I haven*t really
> understood which label is for what and where which label shows up.
>
> On Mon, 13 Dec 2021 at 11:46, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> okay, I've committed the changes with r4836.
> It would be good to know if these long strings cause trouble in MapSource.
> I wouldn't be surprised to find that they cause buffer overflows if Garmin
> doesn't expect more than N bytes, and that again can cause all kinds of
> trouble.
> Will try to reproduce the problem with a modified default style ...
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Montag, 13. Dezember 2021 11:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> it's working fine for me too. But I haven't got around to testing if the
> length should even be shorter related to search.function. Clearly anything
> over 170 is not useful. Maybe it should be even shorter, but apart from the
> value it works well
>
> On Mon, 13 Dec 2021 at 10:28, Ticker Berkin  <mailto:rwb-mkg...@jagit.co.uk><mailto:rwb-mkg...@jagit.co.uk rwb-mkg...@jagit.co.uk>>> wrote:
> Hi Gerd
>
> I don't have any problem with it
>
> Ticker
>
> On Mon, 2021-12-13 at 09:02 +, Gerd Petermann wrote:
> > Hi all,
> >
> > I got no feedback on the patch label_len170.patch. Any comments?
> >
> > Gerd
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk
> ><mailto:mkgmap-dev@lists.mkgmap.org.uk mkgmap-dev@lists.mkgmap.org.uk>>
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>
>
> --
> Felix Hartman - 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 - Openmtbmap.org & VeloMap.org
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] Building display.jar fails

[Felix Hartmann]

I tried a couple of places that are cut down to 170 characters - and some I
can find in Mapsource or Basecamp, Others I cannot. So 170 is definitely
too much for the search index. Is there a way to have separate label for
search vs the label on tooltip/printed out on the label? For search it
clearly should be less (both Mapsurce and Basecamp).
In general it would be good to have a separation between name for
search and name for the label. I know we have 4 labels, but I haven*t
really understood which label is for what and where which label shows up.

On Mon, 13 Dec 2021 at 11:46, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> okay, I've committed the changes with r4836.
> It would be good to know if these long strings cause trouble in MapSource.
> I wouldn't be surprised to find that they cause buffer overflows if Garmin
> doesn't expect more than N bytes, and that again can cause all kinds of
> trouble.
> Will try to reproduce the problem with a modified default style ...
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 13. Dezember 2021 11:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> it's working fine for me too. But I haven't got around to testing if the
> length should even be shorter related to search.function. Clearly anything
> over 170 is not useful. Maybe it should be even shorter, but apart from the
> value it works well
>
> On Mon, 13 Dec 2021 at 10:28, Ticker Berkin  <mailto:rwb-mkg...@jagit.co.uk>> wrote:
> Hi Gerd
>
> I don't have any problem with it
>
> Ticker
>
> On Mon, 2021-12-13 at 09:02 +, Gerd Petermann wrote:
> > Hi all,
> >
> > I got no feedback on the patch label_len170.patch. Any comments?
> >
> > Gerd
>
>
> ___
> 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 - Openmtbmap.org & VeloMap.org
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] Building display.jar fails

[Felix Hartmann]

it's working fine for me too. But I haven't got around to testing if the
length should even be shorter related to search.function. Clearly anything
over 170 is not useful. Maybe it should be even shorter, but apart from the
value it works well

On Mon, 13 Dec 2021 at 10:28, Ticker Berkin  wrote:

> Hi Gerd
>
> I don't have any problem with it
>
> Ticker
>
> On Mon, 2021-12-13 at 09:02 +, Gerd Petermann wrote:
> > Hi all,
> >
> > I got no feedback on the patch label_len170.patch. Any comments?
> >
> > Gerd
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] Exception in thread "main" java.lang.ArithmeticException: / by zero

[Felix Hartmann]

Hi Gerd,
I removed the overflow patch v2, as well as updated to the latest version
on svn - and now it compiled fine (not sure which of these changes made the
difference)

thanks for the support.
Felix

On Fri, 10 Dec 2021 at 16:10, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> There are various problems with large (> 2GB) MDR files.
> I don't know if this is a special problem with the index or with one of
> the routines that copies the data.
>
> I see e.g. a *_mdr.img file > 2G that looks not bad but the corresponding
> gmapi folder shows a file with 0 bytes.
>
> Just starting to understand that part of the program ...
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Freitag, 10. Dezember 2021 13:10
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.ArithmeticException: / by zero
>
> okay - I will remove the patch again. Yes I was still using it. Still I
> will need to wait for tomorrow to start analysing it again.
>
> On Fri, 10 Dec 2021 at 12:57, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> I think a lot of things can go wrong when sizes reach the 2G barrier.
> Don't use the overflow2.patch, it might be part of this problem.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Freitag, 10. Dezember 2021 12:35
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.ArithmeticException: / by zero
>
> Ah okay, it's about gmapsupp.img - right now my server is busy, but I will
> see if I can find an offending tile or if there are some size limits. And
> yeah the data again is pretty big. But RAM should not matter if there is no
> Index I thought.
>
> I will check it tomorrow - at least i know a bit what to look for.
>
> On Fri, 10 Dec 2021, 09:37 Gerd Petermann  <mailto:gpetermann_muenc...@hotmail.com> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>>
> wrote:
> Hi Felix,
>
> I try to reproduce the problem with the block calculation by adding
> nonsense strings to Mdr 15.
> Maybe this helps to find out what's wrong in a reasonable time without
> crashing my own disk ;)
>
> I probably cannot reproduce real size problems because I have only 8G real
> memory in my PC.
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk> mkgmap-dev-boun...@lists.mkgmap.org.uk mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>>
> Gesendet: Freitag, 10. Dezember 2021 08:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread   "main"
> java.lang.ArithmeticException: / by zero
>
> Hi Felix,
>
> looks like another problem with the calculation of blocksizes, this time a
> value of 0 is returned instead of a negative one.
> The error occurs while the gmapsupp.img is written, the routine that fails
> is called for each sub file.
> Is it possible to share the input data and style?
> If not I can try to add logging statements.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk> mkgmap-dev-boun...@lists.mkgmap.org.uk mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>>
> Gesendet: Donnerstag, 9. Dezember 2021 16:31
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Exception in thread "main"
> java.lang.ArithmeticException: / by zero
>
> Any idea what is going wrong here?
> I think the result is actually okay...
>
> Command:
> C:\openmtbmap\maps>start /belownormal /b /wait java -jar
> -XX:+AggressiveHeap -XX:StringTableSize=103 -Xmx43000M
> C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
> --code-page=65001 "--style-file=C:\openmtbmap\buildings_style"
> --lower-case --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
> --ignore-turn-restrictions --merge-lines --allow-reverse-merge
> --transparent --draw

Re: [mkgmap-dev] Exception in thread "main" java.lang.ArithmeticException: / by zero

[Felix Hartmann]

okay - I will remove the patch again. Yes I was still using it. Still I
will need to wait for tomorrow to start analysing it again.

On Fri, 10 Dec 2021 at 12:57, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> I think a lot of things can go wrong when sizes reach the 2G barrier.
> Don't use the overflow2.patch, it might be part of this problem.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Freitag, 10. Dezember 2021 12:35
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.ArithmeticException: / by zero
>
> Ah okay, it's about gmapsupp.img - right now my server is busy, but I will
> see if I can find an offending tile or if there are some size limits. And
> yeah the data again is pretty big. But RAM should not matter if there is no
> Index I thought.
>
> I will check it tomorrow - at least i know a bit what to look for.
>
> On Fri, 10 Dec 2021, 09:37 Gerd Petermann  <mailto:gpetermann_muenc...@hotmail.com>> wrote:
> Hi Felix,
>
> I try to reproduce the problem with the block calculation by adding
> nonsense strings to Mdr 15.
> Maybe this helps to find out what's wrong in a reasonable time without
> crashing my own disk ;)
>
> I probably cannot reproduce real size problems because I have only 8G real
> memory in my PC.
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> Gesendet: Freitag, 10. Dezember 2021 08:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread   "main"
> java.lang.ArithmeticException: / by zero
>
> Hi Felix,
>
> looks like another problem with the calculation of blocksizes, this time a
> value of 0 is returned instead of a negative one.
> The error occurs while the gmapsupp.img is written, the routine that fails
> is called for each sub file.
> Is it possible to share the input data and style?
> If not I can try to add logging statements.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Donnerstag, 9. Dezember 2021 16:31
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Exception in thread "main"
> java.lang.ArithmeticException: / by zero
>
> Any idea what is going wrong here?
> I think the result is actually okay...
>
> Command:
> C:\openmtbmap\maps>start /belownormal /b /wait java -jar
> -XX:+AggressiveHeap -XX:StringTableSize=103 -Xmx43000M
> C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
> --code-page=65001 "--style-file=C:\openmtbmap\buildings_style"
> --lower-case --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
> --ignore-turn-restrictions --merge-lines --allow-reverse-merge
> --transparent --draw-priority=28 --remove-ovm-work-files=true
> --add-pois-to-areas --simplify-polygons=23:4,22:7,21:8
> --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
> --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
> --add-boundary-nodes-at-admin-boundaries=2
> --poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
> --polygon-size-limits="24:16, 23:14, 22:12, 21:11"
> --ignore-turn-restrictions --description=velobuildings_eu
> --remove-ovm-work-files= --country-abbr=eu --country-name=europe
> --mapname=86900310 --family-id=8690 --product-id=1
> --series-name="buildings_europe_09.12.2021_UC_LOCAL
>  " --keep-going --family-name="velobuildings_eu_09.12.2021_UC_LOCAL"
> --tdbfile --x-gmapi-minimal --gmapsupp --overview-mapname=mapsetb
> --area-name="europe_09.12.2021_UC_LOCAL_buildings" -c
> D:\openmtbmap\maps\template.europeb1 8690*.img buildeu.typ  1>NUL
>
>
> Mkgmap version 4827M
> Time started: Thu Dec 09 12:50:49 CET 2021
> Number of MapFailedExceptions: 0
> SEVERE (OverviewBuilder): Tile selection (0x4a) polygon for tile 8690
> cannot be written in level 0 resolution 21, using 19 instead
>
> 
> skipped here
> ...
>
> gmapi-minimal: Skipping file 86900308.img
> gmapi-minimal: Skipping file 86900309.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\86900310.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\86900311.img
> Exception in thread "main" java.lan

Re: [mkgmap-dev] Exception in thread "main" java.lang.ArithmeticException: / by zero

[Felix Hartmann]

Ah okay, it's about gmapsupp.img - right now my server is busy, but I will
see if I can find an offending tile or if there are some size limits. And
yeah the data again is pretty big. But RAM should not matter if there is no
Index I thought.

I will check it tomorrow - at least i know a bit what to look for.

On Fri, 10 Dec 2021, 09:37 Gerd Petermann 
wrote:

> Hi Felix,
>
> I try to reproduce the problem with the block calculation by adding
> nonsense strings to Mdr 15.
> Maybe this helps to find out what's wrong in a reasonable time without
> crashing my own disk ;)
>
> I probably cannot reproduce real size problems because I have only 8G real
> memory in my PC.
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Gerd Petermann 
> Gesendet: Freitag, 10. Dezember 2021 08:38
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread   "main"
> java.lang.ArithmeticException: / by zero
>
> Hi Felix,
>
> looks like another problem with the calculation of blocksizes, this time a
> value of 0 is returned instead of a negative one.
> The error occurs while the gmapsupp.img is written, the routine that fails
> is called for each sub file.
> Is it possible to share the input data and style?
> If not I can try to add logging statements.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 9. Dezember 2021 16:31
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Exception in thread "main"
> java.lang.ArithmeticException: / by zero
>
> Any idea what is going wrong here?
> I think the result is actually okay...
>
> Command:
> C:\openmtbmap\maps>start /belownormal /b /wait java -jar
> -XX:+AggressiveHeap -XX:StringTableSize=103 -Xmx43000M
> C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
> --code-page=65001 "--style-file=C:\openmtbmap\buildings_style"
> --lower-case --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
> --ignore-turn-restrictions --merge-lines --allow-reverse-merge
> --transparent --draw-priority=28 --remove-ovm-work-files=true
> --add-pois-to-areas --simplify-polygons=23:4,22:7,21:8
> --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
> --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
> --add-boundary-nodes-at-admin-boundaries=2
> --poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
> --polygon-size-limits="24:16, 23:14, 22:12, 21:11"
> --ignore-turn-restrictions --description=velobuildings_eu
> --remove-ovm-work-files= --country-abbr=eu --country-name=europe
> --mapname=86900310 --family-id=8690 --product-id=1
> --series-name="buildings_europe_09.12.2021_UC_LOCAL
>  " --keep-going --family-name="velobuildings_eu_09.12.2021_UC_LOCAL"
> --tdbfile --x-gmapi-minimal --gmapsupp --overview-mapname=mapsetb
> --area-name="europe_09.12.2021_UC_LOCAL_buildings" -c
> D:\openmtbmap\maps\template.europeb1 8690*.img buildeu.typ  1>NUL
>
>
> Mkgmap version 4827M
> Time started: Thu Dec 09 12:50:49 CET 2021
> Number of MapFailedExceptions: 0
> SEVERE (OverviewBuilder): Tile selection (0x4a) polygon for tile 8690
> cannot be written in level 0 resolution 21, using 19 instead
>
> 
> skipped here
> ...
>
> gmapi-minimal: Skipping file 86900308.img
> gmapi-minimal: Skipping file 86900309.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\86900310.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\86900311.img
> Exception in thread "main" java.lang.ArithmeticException: / by zero
> at uk.me.parabola.imgfmt.sys.FileNode.write(FileNode.java:239)
> at
> uk.me.parabola.imgfmt.app.BufferedImgFileWriter.sync(BufferedImgFileWriter.java:77)
> at
> uk.me.parabola.imgfmt.app.BufferedImgFileWriter.close(BufferedImgFileWriter.java:106)
> at uk.me.parabola.imgfmt.sys.FileNode.close(FileNode.java:107)
> at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:253)
> at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:325)
> at uk.me.parabola.imgfmt.Utils.closeFile(Utils.java:191)
> at
> uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:187)
> at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
> 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)
>
> --
> Felix Hartman - Openmtbma

[mkgmap-dev] Exception in thread "main" java.lang.ArithmeticException: / by zero

[Felix Hartmann]

Any idea what is going wrong here?
I think the result is actually okay...

Command:
C:\openmtbmap\maps>start /belownormal /b /wait java -jar
-XX:+AggressiveHeap -XX:StringTableSize=103 -Xmx43000M
C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
--code-page=65001 "--style-file=C:\openmtbmap\buildings_style"
 --lower-case --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
--ignore-turn-restrictions --merge-lines --allow-reverse-merge
--transparent --draw-priority=28 --remove-ovm-work-files=true
--add-pois-to-areas --simplify-polygons=23:4,22:7,21:8
--copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
--license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
--add-boundary-nodes-at-admin-boundaries=2
--poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
--polygon-size-limits="24:16, 23:14, 22:12, 21:11"
--ignore-turn-restrictions --description=velobuildings_eu
--remove-ovm-work-files= --country-abbr=eu --country-name=europe
--mapname=86900310 --family-id=8690 --product-id=1
--series-name="buildings_europe_09.12.2021_UC_LOCAL" --keep-going
--family-name="velobuildings_eu_09.12.2021_UC_LOCAL" --tdbfile
--x-gmapi-minimal --gmapsupp --overview-mapname=mapsetb
--area-name="europe_09.12.2021_UC_LOCAL_buildings" -c
D:\openmtbmap\maps\template.europeb1 8690*.img buildeu.typ  1>NUL


Mkgmap version 4827M
Time started: Thu Dec 09 12:50:49 CET 2021
Number of MapFailedExceptions: 0
SEVERE (OverviewBuilder): Tile selection (0x4a) polygon for tile 8690
cannot be written in level 0 resolution 21, using 19 instead


skipped here
...

gmapi-minimal: Skipping file 86900308.img
gmapi-minimal: Skipping file 86900309.img
gmapi-minimal: Writing freshly compiled file
C:\openmtbmap\maps\.\86900310.img
gmapi-minimal: Writing freshly compiled file
C:\openmtbmap\maps\.\86900311.img
Exception in thread "main" java.lang.ArithmeticException: / by zero
at uk.me.parabola.imgfmt.sys.FileNode.write(FileNode.java:239)
at
uk.me.parabola.imgfmt.app.BufferedImgFileWriter.sync(BufferedImgFileWriter.java:77)
at
uk.me.parabola.imgfmt.app.BufferedImgFileWriter.close(BufferedImgFileWriter.java:106)
at uk.me.parabola.imgfmt.sys.FileNode.close(FileNode.java:107)
at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:253)
at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:325)
at uk.me.parabola.imgfmt.Utils.closeFile(Utils.java:191)
at
uk.me.parabola.mkgmap.combiners.GmapsuppBuilder.onFinish(GmapsuppBuilder.java:187)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
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)

-- 
Felix Hartman - 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] PATCH reduce index size

[Felix Hartmann]

ah okay - too bad the entry itself cannot be removed completely.

On Sun, 5 Dec 2021 at 16:32, Gerd Petermann 
wrote:

> Hi Felix,
>
> yes, I think it works as documented. Those entries can come from labels
> which start with M0. , so it's not an additional entry produced by the
> --split-name-index option. I also tried to remove the full entry but then
> the search didn't work any more.
>
> Check what happens when you remove the clause "st.getNameOffset() > 0 && "
> .
>
> Gerd
>
> ________
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Sonntag, 5. Dezember 2021 15:57
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] PATCH reduce index size
>
> are you sure this works fully?
> I still have some strings in the display.jar output.
> I updated the gmapsupp.img here: https://openmtbmap.org/gmapsupp.img
>
> The log file from display.jar decreased by around 15% in size - but there
> are still entries like:
> 00036727 | 00300e | 4d 30 2e 20 | [1082] str: M0.
> 0003672b | 003012 | eb 28   | Index?  10475
> 0003672d | 003014 | 4d 31 2e 20 | [1083] str: M1.
> 00036731 | 003018 | ec 28   | Index?  10476
> 00036733 | 00301a | 4d 32 2e 20 | [1084] str: M2.
> 00036737 | 00301e | ed 28   | Index?  10477
> 00036739 | 003020 | 4d 33 2e 20 | [1085] str: M3.
> 0003673d | 003024 | ee 28   | Index?  10478
> 0003673f | 003026 | 4d 34 2e 20 | [1086] str: M4.
>
>
> Another thing which could be optimized - no number only entries. I don*t
> know any country where you would have an address with the street consisting
> of numbers only. Maybe this should be optional with another switch?
> I know addresses without a street name at all - it*s just name of the
> place plus a number. But I do not know streets with only number as name.
> Maybe some countries have that? Most definitely do no.
> Even one letter and numbers is a bit strange. I think most streets have
> ref and name (e.g. B11 myname) - not sure if some searches for say B11
> housenumber instead of myname housenumber. Maybe they would search for B11
> myname housenumber.
>
> On Sun, 5 Dec 2021 at 11:24, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi all,
>
> as a result of the discussion with Felix in this thread
> https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2021q4/033394.html
> I've created a rather small patch to change the meaning of the --mdr7-del
> option.
>
> With this patch the option has one more effect:
> If --split-name-idex is in use, any additional entry produced by that
> option which starts with a string that appears in the given list is
> skipped.
>
> I think this is probably wanted by all users and it should not cause
> trouble with existing scripts.
>
> For Felix sample with a single tile the PC index size decreases from
> 449.536 bytes to 409.600,
> index in gmapsupp it's about 31kb bytes smaller.
>
> With the default style the change should be much smaller.
>
> Gerd
>
>
>
> ___
> 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 - Openmtbmap.org & VeloMap.org
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] PATCH reduce index size

[Felix Hartmann]

are you sure this works fully?
I still have some strings in the display.jar output.
I updated the gmapsupp.img here: https://openmtbmap.org/gmapsupp.img

The log file from display.jar decreased by around 15% in size - but there
are still entries like:
00036727 | 00300e | 4d 30 2e 20 | [1082] str: M0.
0003672b | 003012 | eb 28   | Index?  10475
0003672d | 003014 | 4d 31 2e 20 | [1083] str: M1.
00036731 | 003018 | ec 28   | Index?  10476
00036733 | 00301a | 4d 32 2e 20 | [1084] str: M2.
00036737 | 00301e | ed 28   | Index?  10477
00036739 | 003020 | 4d 33 2e 20 | [1085] str: M3.
0003673d | 003024 | ee 28   | Index?  10478
0003673f | 003026 | 4d 34 2e 20 | [1086] str: M4.


Another thing which could be optimized - no number only entries. I don*t
know any country where you would have an address with the street consisting
of numbers only. Maybe this should be optional with another switch?
I know addresses without a street name at all - it*s just name of the place
plus a number. But I do not know streets with only number as name. Maybe
some countries have that? Most definitely do no.
Even one letter and numbers is a bit strange. I think most streets have ref
and name (e.g. B11 myname) - not sure if some searches for say B11
housenumber instead of myname housenumber. Maybe they would search for B11
myname housenumber.

On Sun, 5 Dec 2021 at 11:24, Gerd Petermann 
wrote:

> Hi all,
>
> as a result of the discussion with Felix in this thread
> https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2021q4/033394.html
> I've created a rather small patch to change the meaning of the --mdr7-del
> option.
>
> With this patch the option has one more effect:
> If --split-name-idex is in use, any additional entry produced by that
> option which starts with a string that appears in the given list is
> skipped.
>
> I think this is probably wanted by all users and it should not cause
> trouble with existing scripts.
>
> For Felix sample with a single tile the PC index size decreases from
> 449.536 bytes to 409.600,
> index in gmapsupp it's about 31kb bytes smaller.
>
> With the default style the change should be much smaller.
>
> Gerd
>
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



-- 
Felix Hartman - 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] Building display.jar fails

[Felix Hartmann]

Hi Gerd,
Okay - I counted through a lot of entries - and there is no absolute number
- because it depends a bit on the letters and spacing. However the max
amount of characters (incuding blanks) I could count was 162. So we should
hard cap the name label at 170 characters. In general with latin I got
145-160 characters in Basecamp per label.
Another option would be to split into the next label if one is free after
XXX characters - however I think that is not a good option - Mapsource
cannot display close to that many letters - and the devices also cannot and
it kinda depends on each device. Just clipping at 170 characters will
remove some wasted space.

And thanks for the patch. on the new thread.

On Sun, 5 Dec 2021 at 10:58, Felix Hartmann  wrote:

> I simply add all route names to the name. Actually mkgmap should cut after
> XX characters.
>
> I will count the max for Basecamp and mapsource, devices cannot even show
> that long names. It is around 100 but I will check again.
>
> Yes there is no reason to put that long names.
>
> On Sun, 5 Dec 2021, 09:32 Gerd Petermann 
> wrote:
>
>> Hi Felix,
>>
>> I think the names that you see come from names like "PHILOSOPHENWEG G1
>> TRK LWN 156 GAENGLESEE"
>> in combination with --split-name-index.
>> I really wonder how you calculate road names like these:
>> 'TRK LWN 105 TRIESENBERG - ROTABODA-SAMIA - SCHLOSS VADUZ - VADUZ + 106
>> GAFLEI - ROTABODA - TRIESENBERG + 141 TRIESENBERG - BAHOLZ - VADUZ'
>> 'BERGWALD G1 TRK LWN 121 MAUREN - RUGGELL + 123 BENDERN - ST. CORNELI (A)
>> + 120 BENDERN - MAUREN + 35 MAUREN - BUEELKAPPILI - VORDERER SCHELLENBERG'
>> In what situation are they usefull? Which device is able to display such
>> a name? Some have a length > 250.
>>
>> Anyway, I see two ways to reduce the noise in mkgmap:
>> - add code to avoid that --split-name-index adds index entries for name
>> parts which are listed in mdr7-del (should have done this anyway)
>> - add a new option which tells mkgmap that --mdr7-del should remove all
>> substrings, not only suffixes (the effect will be rather small, looking at
>> those long names)
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> Felix Hartmann 
>> Gesendet: Samstag, 4. Dezember 2021 22:12
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Building display.jar fails
>>
>> Sorry, the slash at the end should not be there:
>> https://openmtbmap.org/gmapsupp.img
>>
>> On Sat, 4 Dec 2021, 19:16 Gerd Petermann > <mailto:gpetermann_muenc...@hotmail.com>> wrote:
>> Hi Felix,
>>
>> the link doesn't work.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev > mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
>> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
>> Gesendet: Samstag, 4. Dezember 2021 17:25
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Building display.jar fails
>>
>> oh sorry, I forgot --index on the gmapsupp.img creation in that case and
>> did not notice it.
>> However when I go through the gmapsupp.img - there are for example ways
>> with string: TRK
>> even though I have trk on the mdr7 delete and exclude list. Same for some
>> other terms - but yeah it's only one left - so never TRK XXX
>> (XXX for a second term) - so they are reduced to one instead of
>> disappearing copletely from the index.
>>
>> gmapsupp can be downloaded here: https://openmtbmap.org/gmapsupp.img/
>>
>>
>> - I create the gmapsupp.img with the following exclusions:
>> --mdr7-del=pri,sec,ter,cw,min,unsf,uncl,living,pdstrn,trk,pth,ft,fp,brdlw,rd,byw,ser,cw,mrt,crt,Bklane,Bktrk,opp,Opptrk,g0,g1,g2,g3,g4,g5,g6,t1,t2,t3,t4,t5,t6,xbk,cr,mr,hr,mr0,mr1,mr2,mr3,mr4,mr5,mr0.,mr1.,mr2.,mr3.,mr4.,mr5.,mr6.,mr00,mr01,mr02,mr03,mr04,mr05,mr06,mr11,mr12,mr13,mr14,mr15,mr16,mr20,mr21,mr22,mr23,mr24,mr25,mr26,mr30,mr31,mr32,mr33,mr34,mr35,mr35,mr40,mr41,mr41,mr43,mr44,mr45,mr46,mr50,mr51,mr52,mr53,mr54,mr55,mr56,mr60,mr61,mr62,mr63,mr64,mr65,mr66,m0,m1,m2,m3,m4,m5,m0.,m1.,m2.,m3.,m4.,m5.,m6.,m00,m01,m02,m03,m04,m05,m06,m11,m12,m13,m14,m15,m16,m20,m21,m22,m23,m24,m25,m26,m30,m31,m32,m33,m34,m35,m35,m40,m41,m41,m43,m44,m45,m46,m50,m51,m52,m53,m54,m55,m56,m60,m61,m62,m63,m64,m65,m66,mr.0,mr.1,mr.2,mr.3,mr.4,mr.5,mr.6,m.0,m.1,m.2,m.3,m.4,m.5,m.6,m1.,m2.,m3.,m4.,m5.,m6.,lmr,mrx0,mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mx0,mx1,mx2,mx3,mx4,mx5,mx6,bridge,swing,aqueduct,viaduct,"ntnl
>> bndry",admin_lv=4,"ntnl
>> park",weir,dam,waterfall,rapi

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

I simply add all route names to the name. Actually mkgmap should cut after
XX characters.

I will count the max for Basecamp and mapsource, devices cannot even show
that long names. It is around 100 but I will check again.

Yes there is no reason to put that long names.

On Sun, 5 Dec 2021, 09:32 Gerd Petermann 
wrote:

> Hi Felix,
>
> I think the names that you see come from names like "PHILOSOPHENWEG G1 TRK
> LWN 156 GAENGLESEE"
> in combination with --split-name-index.
> I really wonder how you calculate road names like these:
> 'TRK LWN 105 TRIESENBERG - ROTABODA-SAMIA - SCHLOSS VADUZ - VADUZ + 106
> GAFLEI - ROTABODA - TRIESENBERG + 141 TRIESENBERG - BAHOLZ - VADUZ'
> 'BERGWALD G1 TRK LWN 121 MAUREN - RUGGELL + 123 BENDERN - ST. CORNELI (A)
> + 120 BENDERN - MAUREN + 35 MAUREN - BUEELKAPPILI - VORDERER SCHELLENBERG'
> In what situation are they usefull? Which device is able to display such a
> name? Some have a length > 250.
>
> Anyway, I see two ways to reduce the noise in mkgmap:
> - add code to avoid that --split-name-index adds index entries for name
> parts which are listed in mdr7-del (should have done this anyway)
> - add a new option which tells mkgmap that --mdr7-del should remove all
> substrings, not only suffixes (the effect will be rather small, looking at
> those long names)
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Samstag, 4. Dezember 2021 22:12
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> Sorry, the slash at the end should not be there:
> https://openmtbmap.org/gmapsupp.img
>
> On Sat, 4 Dec 2021, 19:16 Gerd Petermann  <mailto:gpetermann_muenc...@hotmail.com>> wrote:
> Hi Felix,
>
> the link doesn't work.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Samstag, 4. Dezember 2021 17:25
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> oh sorry, I forgot --index on the gmapsupp.img creation in that case and
> did not notice it.
> However when I go through the gmapsupp.img - there are for example ways
> with string: TRK
> even though I have trk on the mdr7 delete and exclude list. Same for some
> other terms - but yeah it's only one left - so never TRK XXX
> (XXX for a second term) - so they are reduced to one instead of
> disappearing copletely from the index.
>
> gmapsupp can be downloaded here: https://openmtbmap.org/gmapsupp.img/
>
>
> - I create the gmapsupp.img with the following exclusions:
> --mdr7-del=pri,sec,ter,cw,min,unsf,uncl,living,pdstrn,trk,pth,ft,fp,brdlw,rd,byw,ser,cw,mrt,crt,Bklane,Bktrk,opp,Opptrk,g0,g1,g2,g3,g4,g5,g6,t1,t2,t3,t4,t5,t6,xbk,cr,mr,hr,mr0,mr1,mr2,mr3,mr4,mr5,mr0.,mr1.,mr2.,mr3.,mr4.,mr5.,mr6.,mr00,mr01,mr02,mr03,mr04,mr05,mr06,mr11,mr12,mr13,mr14,mr15,mr16,mr20,mr21,mr22,mr23,mr24,mr25,mr26,mr30,mr31,mr32,mr33,mr34,mr35,mr35,mr40,mr41,mr41,mr43,mr44,mr45,mr46,mr50,mr51,mr52,mr53,mr54,mr55,mr56,mr60,mr61,mr62,mr63,mr64,mr65,mr66,m0,m1,m2,m3,m4,m5,m0.,m1.,m2.,m3.,m4.,m5.,m6.,m00,m01,m02,m03,m04,m05,m06,m11,m12,m13,m14,m15,m16,m20,m21,m22,m23,m24,m25,m26,m30,m31,m32,m33,m34,m35,m35,m40,m41,m41,m43,m44,m45,m46,m50,m51,m52,m53,m54,m55,m56,m60,m61,m62,m63,m64,m65,m66,mr.0,mr.1,mr.2,mr.3,mr.4,mr.5,mr.6,m.0,m.1,m.2,m.3,m.4,m.5,m.6,m1.,m2.,m3.,m4.,m5.,m6.,lmr,mrx0,mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mx0,mx1,mx2,mx3,mx4,mx5,mx6,bridge,swing,aqueduct,viaduct,"ntnl
> bndry",admin_lv=4,"ntnl
> park",weir,dam,waterfall,rapids,stream,river,drain,ditch,"huge river","huge
>  st river","medium river","small river","wide river","hugest canal","huge
> canal","medium canal","small canal","big
> canal",canal,snowpark,Skitour-descent,Skipiste,Skislope,illuminated,Nordic-Skiing,skitour,platter,ropetow,tbar,chairlift,goods_lift,runway,taxiway,apron,VFS0,VFS1,VFS2,VFS3,VFS4,VFS5,VFS6,VFS7,usf,cstrn,steps,parking_aisle,res,cob,cobstn,public_footway,public_footpath,hr,mr,iwn,nwn,rwn,lwn,wn,cn,ferry,xcn,xwn,water,gondola,train,cablecar,s1,s2,s3,s4,s5,ucl--mdr7-excl=pri,sec,ter,cw,min,unsf,uncl,living,pdstrn,trk,pth,ft,fp,brdlw,rd,byw,ser,cw,mrt,crt,Bklane,Bktrk,opp,Opptrk,g0,g1,g2,g3,g4,g5,g6,t1,t2,t3,t4,t5,t6,xbk,cr,mr,hr,mr0,mr1,mr2,mr3,mr4,mr5,mr0.,mr1.,mr2.,mr3.,mr4.,mr5.,mr6.,mr00,mr01,mr02,mr03,mr04,mr05,mr06,mr11,mr12,mr13,mr14,mr15,mr16,mr20,mr21,mr22,mr23,mr24,mr25,mr26,mr30,mr31,mr32,mr33,mr34,mr35,mr35,mr40,mr41,mr41,mr43,mr44,mr45,mr46,mr50,mr51,mr52,mr53,mr54,mr55,

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

Sorry, the slash at the end should not be there:
https://openmtbmap.org/gmapsupp.img

On Sat, 4 Dec 2021, 19:16 Gerd Petermann 
wrote:

> Hi Felix,
>
> the link doesn't work.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Samstag, 4. Dezember 2021 17:25
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> oh sorry, I forgot --index on the gmapsupp.img creation in that case and
> did not notice it.
> However when I go through the gmapsupp.img - there are for example ways
> with string: TRK
> even though I have trk on the mdr7 delete and exclude list. Same for some
> other terms - but yeah it's only one left - so never TRK XXX
> (XXX for a second term) - so they are reduced to one instead of
> disappearing copletely from the index.
>
> gmapsupp can be downloaded here: https://openmtbmap.org/gmapsupp.img/
>
>
> - I create the gmapsupp.img with the following exclusions:
> --mdr7-del=pri,sec,ter,cw,min,unsf,uncl,living,pdstrn,trk,pth,ft,fp,brdlw,rd,byw,ser,cw,mrt,crt,Bklane,Bktrk,opp,Opptrk,g0,g1,g2,g3,g4,g5,g6,t1,t2,t3,t4,t5,t6,xbk,cr,mr,hr,mr0,mr1,mr2,mr3,mr4,mr5,mr0.,mr1.,mr2.,mr3.,mr4.,mr5.,mr6.,mr00,mr01,mr02,mr03,mr04,mr05,mr06,mr11,mr12,mr13,mr14,mr15,mr16,mr20,mr21,mr22,mr23,mr24,mr25,mr26,mr30,mr31,mr32,mr33,mr34,mr35,mr35,mr40,mr41,mr41,mr43,mr44,mr45,mr46,mr50,mr51,mr52,mr53,mr54,mr55,mr56,mr60,mr61,mr62,mr63,mr64,mr65,mr66,m0,m1,m2,m3,m4,m5,m0.,m1.,m2.,m3.,m4.,m5.,m6.,m00,m01,m02,m03,m04,m05,m06,m11,m12,m13,m14,m15,m16,m20,m21,m22,m23,m24,m25,m26,m30,m31,m32,m33,m34,m35,m35,m40,m41,m41,m43,m44,m45,m46,m50,m51,m52,m53,m54,m55,m56,m60,m61,m62,m63,m64,m65,m66,mr.0,mr.1,mr.2,mr.3,mr.4,mr.5,mr.6,m.0,m.1,m.2,m.3,m.4,m.5,m.6,m1.,m2.,m3.,m4.,m5.,m6.,lmr,mrx0,mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mx0,mx1,mx2,mx3,mx4,mx5,mx6,bridge,swing,aqueduct,viaduct,"ntnl
> bndry",admin_lv=4,"ntnl
> park",weir,dam,waterfall,rapids,stream,river,drain,ditch,"huge river","huge
>  st river","medium river","small river","wide river","hugest canal","huge
> canal","medium canal","small canal","big
> canal",canal,snowpark,Skitour-descent,Skipiste,Skislope,illuminated,Nordic-Skiing,skitour,platter,ropetow,tbar,chairlift,goods_lift,runway,taxiway,apron,VFS0,VFS1,VFS2,VFS3,VFS4,VFS5,VFS6,VFS7,usf,cstrn,steps,parking_aisle,res,cob,cobstn,public_footway,public_footpath,hr,mr,iwn,nwn,rwn,lwn,wn,cn,ferry,xcn,xwn,water,gondola,train,cablecar,s1,s2,s3,s4,s5,ucl--mdr7-excl=pri,sec,ter,cw,min,unsf,uncl,living,pdstrn,trk,pth,ft,fp,brdlw,rd,byw,ser,cw,mrt,crt,Bklane,Bktrk,opp,Opptrk,g0,g1,g2,g3,g4,g5,g6,t1,t2,t3,t4,t5,t6,xbk,cr,mr,hr,mr0,mr1,mr2,mr3,mr4,mr5,mr0.,mr1.,mr2.,mr3.,mr4.,mr5.,mr6.,mr00,mr01,mr02,mr03,mr04,mr05,mr06,mr11,mr12,mr13,mr14,mr15,mr16,mr20,mr21,mr22,mr23,mr24,mr25,mr26,mr30,mr31,mr32,mr33,mr34,mr35,mr35,mr40,mr41,mr41,mr43,mr44,mr45,mr46,mr50,mr51,mr52,mr53,mr54,mr55,mr56,mr60,mr61,mr62,mr63,mr64,mr65,mr66,m0,m1,m2,m3,m4,m5,m0.,m1.,m2.,m3.,m4.,m5.,m6.,m00,m01
>  
> ,m02,m03,m04,m05,m06,m11,m12,m13,m14,m15,m16,m20,m21,m22,m23,m24,m25,m26,m30,m31,m32,m33,m34,m35,m35,m40,m41,m41,m43,m44,m45,m46,m50,m51,m52,m53,m54,m55,m56,m60,m61,m62,m63,m64,m65,m66,mr.0,mr.1,mr.2,mr.3,mr.4,mr.5,mr.6,m.0,m.1,m.2,m.3,m.4,m.5,m.6,m1.,m2.,m3.,m4.,m5.,m6.,lmr,mrx0,mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mx0,mx1,mx2,mx3,mx4,mx5,mx6,bridge,swing,aqueduct,viaduct,"ntnl
> bndry",admin_lv=4,"ntnl
> park",weir,dam,waterfall,rapids,stream,river,drain,ditch,"huge
> river","hugest river","medium river","small river","wide river","hugest
> canal","huge canal","medium canal","small canal","big
> canal",canal,snowpark,Skitour-descent,Skipiste,Skislope,illuminated,Nordic-Skiing,skitour,platter,ropetow,tbar,chairlift,goods_lift,runway,taxiway,apron,VFS0,VFS1,VFS2,VFS3,VFS4,VFS5,VFS6,VFS7,usf,cstrn,steps,parking_aisle,res,cob,cobstn,public_footway,public_footpath,hr,mr,iwn,nwn,rwn,lwn,wn,cn,ferry,xcn,xwn,water,gondola,train,cablecar,s1,s2,s3,s4,s5,ucl
>
> And quite a few of those terms end up single as name
> e.g;
> 0003e0cb | 002ff6 | 54 52 4b 20 | [1058] str: TRK
> 0003e0cf | 002ffa | fd 2e   | Index?  12029
> or
> 0003e20f | 00313a | 4d 31 2e 20 | [1112] str: M1.
> 0003e213 | 00313e | 8e 2f   | Index?  12174
>
>
> On Sat, 4 Dec 2021 at 16:10, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> no idea why display tool has a problem with a gmapsupp that was created by
> mkgmap. Please post a link to a small one that shows t

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

oh sorry, I forgot --index on the gmapsupp.img creation in that case and
did not notice it.
However when I go through the gmapsupp.img - there are for example ways
with string: TRK
even though I have trk on the mdr7 delete and exclude list. Same for some
other terms - but yeah it's only one left - so never TRK XXX
(XXX for a second term) - so they are reduced to one instead of
disappearing copletely from the index.

gmapsupp can be downloaded here: https://openmtbmap.org/gmapsupp.img/


- I create the gmapsupp.img with the following exclusions:
--mdr7-del=pri,sec,ter,cw,min,unsf,uncl,living,pdstrn,trk,pth,ft,fp,brdlw,rd,byw,ser,cw,mrt,crt,Bklane,Bktrk,opp,Opptrk,g0,g1,g2,g3,g4,g5,g6,t1,t2,t3,t4,t5,t6,xbk,cr,mr,hr,mr0,mr1,mr2,mr3,mr4,mr5,mr0.,mr1.,mr2.,mr3.,mr4.,mr5.,mr6.,mr00,mr01,mr02,mr03,mr04,mr05,mr06,mr11,mr12,mr13,mr14,mr15,mr16,mr20,mr21,mr22,mr23,mr24,mr25,mr26,mr30,mr31,mr32,mr33,mr34,mr35,mr35,mr40,mr41,mr41,mr43,mr44,mr45,mr46,mr50,mr51,mr52,mr53,mr54,mr55,mr56,mr60,mr61,mr62,mr63,mr64,mr65,mr66,m0,m1,m2,m3,m4,m5,m0.,m1.,m2.,m3.,m4.,m5.,m6.,m00,m01,m02,m03,m04,m05,m06,m11,m12,m13,m14,m15,m16,m20,m21,m22,m23,m24,m25,m26,m30,m31,m32,m33,m34,m35,m35,m40,m41,m41,m43,m44,m45,m46,m50,m51,m52,m53,m54,m55,m56,m60,m61,m62,m63,m64,m65,m66,mr.0,mr.1,mr.2,mr.3,mr.4,mr.5,mr.6,m.0,m.1,m.2,m.3,m.4,m.5,m.6,m1.,m2.,m3.,m4.,m5.,m6.,lmr,mrx0,mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mx0,mx1,mx2,mx3,mx4,mx5,mx6,bridge,swing,aqueduct,viaduct,"ntnl
bndry",admin_lv=4,"ntnl
park",weir,dam,waterfall,rapids,stream,river,drain,ditch,"huge
river","hugest river","medium river","small river","wide river","hugest
canal","huge canal","medium canal","small canal","big
canal",canal,snowpark,Skitour-descent,Skipiste,Skislope,illuminated,Nordic-Skiing,skitour,platter,ropetow,tbar,chairlift,goods_lift,runway,taxiway,apron,VFS0,VFS1,VFS2,VFS3,VFS4,VFS5,VFS6,VFS7,usf,cstrn,steps,parking_aisle,res,cob,cobstn,public_footway,public_footpath,hr,mr,iwn,nwn,rwn,lwn,wn,cn,ferry,xcn,xwn,water,gondola,train,cablecar,s1,s2,s3,s4,s5,ucl--mdr7-excl=pri,sec,ter,cw,min,unsf,uncl,living,pdstrn,trk,pth,ft,fp,brdlw,rd,byw,ser,cw,mrt,crt,Bklane,Bktrk,opp,Opptrk,g0,g1,g2,g3,g4,g5,g6,t1,t2,t3,t4,t5,t6,xbk,cr,mr,hr,mr0,mr1,mr2,mr3,mr4,mr5,mr0.,mr1.,mr2.,mr3.,mr4.,mr5.,mr6.,mr00,mr01,mr02,mr03,mr04,mr05,mr06,mr11,mr12,mr13,mr14,mr15,mr16,mr20,mr21,mr22,mr23,mr24,mr25,mr26,mr30,mr31,mr32,mr33,mr34,mr35,mr35,mr40,mr41,mr41,mr43,mr44,mr45,mr46,mr50,mr51,mr52,mr53,mr54,mr55,mr56,mr60,mr61,mr62,mr63,mr64,mr65,mr66,m0,m1,m2,m3,m4,m5,m0.,m1.,m2.,m3.,m4.,m5.,m6.,m00,m01,m02,m03,m04,m05,m06,m11,m12,m13,m14,m15,m16,m20,m21,m22,m23,m24,m25,m26,m30,m31,m32,m33,m34,m35,m35,m40,m41,m41,m43,m44,m45,m46,m50,m51,m52,m53,m54,m55,m56,m60,m61,m62,m63,m64,m65,m66,mr.0,mr.1,mr.2,mr.3,mr.4,mr.5,mr.6,m.0,m.1,m.2,m.3,m.4,m.5,m.6,m1.,m2.,m3.,m4.,m5.,m6.,lmr,mrx0,mrx1,mrx2,mrx3,mrx4,mrx5,mrx6,mx0,mx1,mx2,mx3,mx4,mx5,mx6,bridge,swing,aqueduct,viaduct,"ntnl
bndry",admin_lv=4,"ntnl
park",weir,dam,waterfall,rapids,stream,river,drain,ditch,"huge
river","hugest river","medium river","small river","wide river","hugest
canal","huge canal","medium canal","small canal","big
canal",canal,snowpark,Skitour-descent,Skipiste,Skislope,illuminated,Nordic-Skiing,skitour,platter,ropetow,tbar,chairlift,goods_lift,runway,taxiway,apron,VFS0,VFS1,VFS2,VFS3,VFS4,VFS5,VFS6,VFS7,usf,cstrn,steps,parking_aisle,res,cob,cobstn,public_footway,public_footpath,hr,mr,iwn,nwn,rwn,lwn,wn,cn,ferry,xcn,xwn,water,gondola,train,cablecar,s1,s2,s3,s4,s5,ucl

And quite a few of those terms end up single as name
e.g;
0003e0cb | 002ff6 | 54 52 4b 20 | [1058] str: TRK
0003e0cf | 002ffa | fd 2e   | Index?  12029
or
0003e20f | 00313a | 4d 31 2e 20 | [1112] str: M1.
0003e213 | 00313e | 8e 2f   | Index?  12174


On Sat, 4 Dec 2021 at 16:10, Gerd Petermann 
wrote:

> Hi Felix,
>
> no idea why display tool has a problem with a gmapsupp that was created by
> mkgmap. Please post a link to a small one that shows this problem. Or does
> it only happen with very large files?
>
> The name "T3 pth" should not appear in Mdr 7 if both t3 and pth are given
> in --mdr7-del. In my test that worked well.
> If the string "T3 pth" appears in Mdr 15 you have a POI with that name.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Freitag, 3. Dezember 2021 16:58
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> Hi Gerd,
> gmapsupp.img created by Mapsource or my MapInstall work fine - those
> created by mkgmap (on my server) do not work - even though address search
> on 

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

Hi Gerd,
gmapsupp.img created by Mapsource or my MapInstall work fine - those
created by mkgmap (on my server) do not work - even though address search
on device works the same (or at least mostly the same - didn*t find a
difference).

But yeah I found out my list was more or less complete - just the problem
that they are not removed if it is only called say "T3 pth".
Another improvement - it would be great if the display tool could say file
does not exist vs could not open file. Right now the message is always
could not open file.

On Thu, 2 Dec 2021 at 20:41, Gerd Petermann 
wrote:

> Hi Felix,
>
> the message "Could not open file: gmapsupp.img" comes from display tool,
> so at least the program was started.
> MdrDisplay tries to open the MDR sub file in the gmapsupp. If that fails
> you may not have such a file in your gmapsupp.img (no index) or the file
> itself is corrupted or doesn't exist in the directory where you executed
> the command.
>
> My understanding is that you want to print the string table (Mdr 15), this
> doesn't exist in the gmapsupp, only in the *mdr.img for the PC.
>
> I think you have to use parameter --print=15 for this section, it is
> ommitted by default.
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. Dezember 2021 19:44
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> thanks - but I still seem to be unable  - I copied your command and
> changed the pathes.:
>
> C:\openmtbmap>java -ea -Xmx6800m -cp display.jar;mkgmap.jar
> test.display.MdrDisplay gmapsupp.img
> Could not open file: gmapsupp.img
>
> other tries:
>
> C:\openmtbmap>java -ea -jar -Xmx6800m -cp display.jar;mkgmap.jar
> gmapsupp.img
> Error: Invalid or corrupt jarfile gmapsupp.img
>
> C:\openmtbmap>java -ea -Xmx6800m -cp display.jar;mkgmap.jar gmapsupp.img
> Error: Could not find or load main class gmapsupp.img
> Caused by: java.lang.ClassNotFoundException: gmapsupp.img
>
> On Thu, 2 Dec 2021 at 17:50, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> display tool always needs mkgmap.jar for execution:
> my command line looks like this:
> java -ea  -Xmx6800m -cp
> d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar
> test.display.MdrDisplay gmapsupp.img
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Donnerstag, 2. Dezember 2021 17:46
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> still the same problem if I don't link the build folder of mkgmap_trunk
> but instead the mkgmap.jar in the basefolder:
>
> C:\openmtbmap\mkgmap_display>ant dist
> Buildfile: C:\openmtbmap\mkgmap_display\build.xml
>
> prepare:
> [mkdir] Created dir: C:\openmtbmap\mkgmap_display\build\classes
>
> ivy-availability:
>
> download-ivy:
>
> init-ivy:
> [ivy:configure] :: Apache Ivy 2.5.0 - 20191020104435 ::
> https://ant.apache.org/ivy/ ::
> [ivy:configure] :: loading settings :: file =
> C:\openmtbmap\mkgmap_display\ivysettings.xml
>
> resolve-compile:
>
> compile:
> [javac] Compiling 76 source files to
> C:\openmtbmap\mkgmap_display\build\classes
> [javac]
> C:\openmtbmap\mkgmap_display\src\test\check\CommonCheck.java:141: warning:
> [deprecation] newInstance() in Class has been deprecated
> [javac] CommonCheck check =
> cls.newInstance();
> [javac]^
> [javac]   where T is a type-variable:
> [javac] T extends Object declared in class Class
> [javac]
> C:\openmtbmap\mkgmap_display\src\test\display\SrtDisplay.java:470: warning:
> [rawtypes] found raw type: Comparable
> [javac] private class CharPosition implements Comparable {
> [javac]   ^
> [javac]   missing type arguments for generic class Comparable
> [javac]   where T is a type-variable:
> [javac] T extends Object declared in interface Comparable
> [javac]
> C:\openmtbmap\mkgmap_display\src\test\display\SrtDisplay.java:502: warning:
> [removal] Integer(int) in Integer has been deprecated and marked for removal
> [javac] return new
> Integer(val).compareTo(c2.val);
> [javac]^
> [javac] 3 warnings
>
> build:
>
> dist:

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

thanks - but I still seem to be unable  - I copied your command and changed
the pathes.:

C:\openmtbmap>java -ea -Xmx6800m -cp display.jar;mkgmap.jar
test.display.MdrDisplay gmapsupp.img
Could not open file: gmapsupp.img

other tries:

C:\openmtbmap>java -ea -jar -Xmx6800m -cp display.jar;mkgmap.jar
gmapsupp.img
Error: Invalid or corrupt jarfile gmapsupp.img

C:\openmtbmap>java -ea -Xmx6800m -cp display.jar;mkgmap.jar gmapsupp.img
Error: Could not find or load main class gmapsupp.img
Caused by: java.lang.ClassNotFoundException: gmapsupp.img

On Thu, 2 Dec 2021 at 17:50, Gerd Petermann 
wrote:

> Hi Felix,
>
> display tool always needs mkgmap.jar for execution:
> my command line looks like this:
> java -ea  -Xmx6800m -cp
> d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar
> test.display.MdrDisplay gmapsupp.img
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. Dezember 2021 17:46
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> still the same problem if I don't link the build folder of mkgmap_trunk
> but instead the mkgmap.jar in the basefolder:
>
> C:\openmtbmap\mkgmap_display>ant dist
> Buildfile: C:\openmtbmap\mkgmap_display\build.xml
>
> prepare:
> [mkdir] Created dir: C:\openmtbmap\mkgmap_display\build\classes
>
> ivy-availability:
>
> download-ivy:
>
> init-ivy:
> [ivy:configure] :: Apache Ivy 2.5.0 - 20191020104435 ::
> https://ant.apache.org/ivy/ ::
> [ivy:configure] :: loading settings :: file =
> C:\openmtbmap\mkgmap_display\ivysettings.xml
>
> resolve-compile:
>
> compile:
> [javac] Compiling 76 source files to
> C:\openmtbmap\mkgmap_display\build\classes
> [javac]
> C:\openmtbmap\mkgmap_display\src\test\check\CommonCheck.java:141: warning:
> [deprecation] newInstance() in Class has been deprecated
> [javac] CommonCheck check =
> cls.newInstance();
> [javac]^
> [javac]   where T is a type-variable:
> [javac] T extends Object declared in class Class
> [javac]
> C:\openmtbmap\mkgmap_display\src\test\display\SrtDisplay.java:470: warning:
> [rawtypes] found raw type: Comparable
> [javac] private class CharPosition implements Comparable {
> [javac]   ^
> [javac]   missing type arguments for generic class Comparable
> [javac]   where T is a type-variable:
> [javac] T extends Object declared in interface Comparable
> [javac]
> C:\openmtbmap\mkgmap_display\src\test\display\SrtDisplay.java:502: warning:
> [removal] Integer(int) in Integer has been deprecated and marked for removal
> [javac] return new
> Integer(val).compareTo(c2.val);
> [javac]^
> [javac] 3 warnings
>
> build:
>
> dist:
>   [jar] Building jar: C:\openmtbmap\mkgmap_display\dist\display.jar
>
> BUILD SUCCESSFUL
> Total time: 6 seconds
>
> it compiles but then on use it complains:
>
> C:\openmtbmap\mkgmap_display>start /normal /b /wait java -jar
> C:\openmtbmap\display.jar c:\openmtbmap\gmapsupp.img
> no main manifest attribute, in C:\openmtbmap\display.jar
>
> On Thu, 2 Dec 2021 at 17:33, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> please try
> ant clean dist > log
> and post a link to the file log
>
> I did this:
> checkout: svn co https://svn.mkgmap.org.uk/mkgmap/display/trunk display
> copy mkgmap.jar into display\lib\compile
> execute ant dist
> Compile works with one warning.
> ant -version says
> Apache Ant(TM) version 1.10.8 compiled on May 10 2020
> javac -versio says
> javac 1.8.0_272
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Donnerstag, 2. Dezember 2021 17:26
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> then it does not find anything anymore.
>
> like this:
>
> ompile:
> [javac] Compiling 589 source files to
> C:\openmtbmap\mkgmap_display\build\classes
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\Coord.java:23:
> error: package it.unimi.dsi.fastutil.longs does not exist
> [javac] import it.unimi.dsi.fastutil.longs.Long2ObjectOpenHashMap;
> [javac]   ^
> [javac

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

still the same problem if I don't link the build folder of mkgmap_trunk but
instead the mkgmap.jar in the basefolder:

C:\openmtbmap\mkgmap_display>ant dist
Buildfile: C:\openmtbmap\mkgmap_display\build.xml

prepare:
[mkdir] Created dir: C:\openmtbmap\mkgmap_display\build\classes

ivy-availability:

download-ivy:

init-ivy:
[ivy:configure] :: Apache Ivy 2.5.0 - 20191020104435 ::
https://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
C:\openmtbmap\mkgmap_display\ivysettings.xml

resolve-compile:

compile:
[javac] Compiling 76 source files to
C:\openmtbmap\mkgmap_display\build\classes
[javac]
C:\openmtbmap\mkgmap_display\src\test\check\CommonCheck.java:141: warning:
[deprecation] newInstance() in Class has been deprecated
[javac] CommonCheck check =
cls.newInstance();
[javac]^
[javac]   where T is a type-variable:
[javac] T extends Object declared in class Class
[javac]
C:\openmtbmap\mkgmap_display\src\test\display\SrtDisplay.java:470: warning:
[rawtypes] found raw type: Comparable
[javac] private class CharPosition implements Comparable {
[javac]   ^
[javac]   missing type arguments for generic class Comparable
[javac]   where T is a type-variable:
[javac] T extends Object declared in interface Comparable
[javac]
C:\openmtbmap\mkgmap_display\src\test\display\SrtDisplay.java:502: warning:
[removal] Integer(int) in Integer has been deprecated and marked for removal
[javac] return new
Integer(val).compareTo(c2.val);
[javac]^
[javac] 3 warnings

build:

dist:
  [jar] Building jar: C:\openmtbmap\mkgmap_display\dist\display.jar

BUILD SUCCESSFUL
Total time: 6 seconds

*it compiles but then on use it complains:*

C:\openmtbmap\mkgmap_display>start /normal /b /wait java -jar
C:\openmtbmap\display.jar c:\openmtbmap\gmapsupp.img
*no main manifest attribute, in C:\openmtbmap\display.jar*

On Thu, 2 Dec 2021 at 17:33, Gerd Petermann 
wrote:

> Hi Felix,
>
> please try
> ant clean dist > log
> and post a link to the file log
>
> I did this:
> checkout: svn co https://svn.mkgmap.org.uk/mkgmap/display/trunk display
> copy mkgmap.jar into display\lib\compile
> execute ant dist
> Compile works with one warning.
> ant -version says
> Apache Ant(TM) version 1.10.8 compiled on May 10 2020
> javac -versio says
> javac 1.8.0_272
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. Dezember 2021 17:26
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Building display.jar fails
>
> then it does not find anything anymore.
>
> like this:
>
> ompile:
> [javac] Compiling 589 source files to
> C:\openmtbmap\mkgmap_display\build\classes
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\Coord.java:23:
> error: package it.unimi.dsi.fastutil.longs does not exist
> [javac] import it.unimi.dsi.fastutil.longs.Long2ObjectOpenHashMap;
> [javac]   ^
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\Coord.java:124:
> error: cannot find symbol
> [javac] public static Coord makeHighPrecCoord(int latHp, int
> lonHp, Long2ObjectOpenHashMap coordPool) {
> [javac]
>  ^
> [javac]   symbol:   class Long2ObjectOpenHashMap
> [javac]   location: class Coord
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\lbl\LBLFileReader.java:21:
> error: package it.unimi.dsi.fastutil.ints does not exist
> [javac] import it.unimi.dsi.fastutil.ints.Int2ObjectOpenHashMap;
> [javac]  ^
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\net\RouteNode.java:25:
> error: package it.unimi.dsi.fastutil.ints does not exist
> [javac] import it.unimi.dsi.fastutil.ints.IntArrayList;
> [javac]  ^
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\reader\osm\TagDict.java:18:
> error: package it.unimi.dsi.fastutil.shorts does not exist
> [javac] import it.unimi.dsi.fastutil.shorts.ShortArrayList;
> [javac]^
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\reader\osm\TagDict.java:98:
> error: cannot find symbol
> [javac] public static ShortArrayList compileTags(String ...keys) {
> [javac]   ^
> [javac]   symbol:   class ShortArrayList
> [javac]   location: class TagDict
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\

Re: [mkgmap-dev] Building display.jar fails

[Felix Hartmann]

then it does not find anything anymore.

like this:

ompile:
[javac] Compiling 589 source files to
C:\openmtbmap\mkgmap_display\build\classes
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\Coord.java:23:
error: package it.unimi.dsi.fastutil.longs does not exist
[javac] import it.unimi.dsi.fastutil.longs.Long2ObjectOpenHashMap;
[javac]   ^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\Coord.java:124:
error: cannot find symbol
[javac] public static Coord makeHighPrecCoord(int latHp, int lonHp,
Long2ObjectOpenHashMap coordPool) {
[javac]
^
[javac]   symbol:   class Long2ObjectOpenHashMap
[javac]   location: class Coord
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\lbl\LBLFileReader.java:21:
error: package it.unimi.dsi.fastutil.ints does not exist
[javac] import it.unimi.dsi.fastutil.ints.Int2ObjectOpenHashMap;
[javac]  ^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\net\RouteNode.java:25:
error: package it.unimi.dsi.fastutil.ints does not exist
[javac] import it.unimi.dsi.fastutil.ints.IntArrayList;
[javac]  ^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\reader\osm\TagDict.java:18:
error: package it.unimi.dsi.fastutil.shorts does not exist
[javac] import it.unimi.dsi.fastutil.shorts.ShortArrayList;
[javac]^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\reader\osm\TagDict.java:98:
error: cannot find symbol
[javac] public static ShortArrayList compileTags(String ...keys) {
[javac]   ^
[javac]   symbol:   class ShortArrayList
[javac]   location: class TagDict
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\imgfmt\app\lbl\LBLFileReader.java:54:
error: cannot find symbol
[javac] private final Int2ObjectOpenHashMap labels = new
Int2ObjectOpenHashMap<>();
[javac]   ^

On Thu, 2 Dec 2021 at 16:54, Gerd Petermann 
wrote:

> Hi Felix,
>
> please try svn up.
> Maybe the change in
> https://www.mkgmap.org.uk/websvn/revision.php?repname=display&rev=565
> helps.
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. Dezember 2021 16:49
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Building display.jar fails
>
> I can actually avoid it by placing mkgmap.jar into the display tool folder
> - however then the display.jar is not working and ends with the notice:
> "no main manifest attribute, in C:\openmtbmap\display.jar"
>
>
>
>
> I get the following error I don't know how to solve when building the
> display.jar display tool - with the mkgmap folder inserted into the
> build.xml:
>
> Buildfile: C:\openmtbmap\mkgmap_display\build.xml
>
> prepare:
> [mkdir] Created dir: C:\openmtbmap\mkgmap_display\build\classes
>
> ivy-availability:
>
> download-ivy:
> [mkdir] Created dir: C:\openmtbmap\mkgmap_display\lib\build
>   [get] Getting:
> https://repo1.maven.org/maven2/org/apache/ivy/ivy/2.5.0/ivy-2.5.0.jar
>   [get] To: C:\openmtbmap\mkgmap_display\lib\build\ivy-2.5.0.jar
>
> init-ivy:
> [ivy:configure] :: Apache Ivy 2.5.0 - 20191020104435 ::
> https://ant.apache.org/ivy/ ::
> [ivy:configure] :: loading settings :: file =
> C:\openmtbmap\mkgmap_display\ivysettings.xml
>
> resolve-compile:
>
> compile:
> [javac] Compiling 589 source files to
> C:\openmtbmap\mkgmap_display\build\classes
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
> error: unclosed character literal
> [javac] if (ch == 'ª' || (Character.isLetter(ch)
> && (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
> [javac]   ^
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
> error: unclosed character literal
> [javac] if (ch == 'ª' || (Character.isLetter(ch)
> && (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
> [javac]  ^
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
> error: not a statement
> [javac] if (ch == 'ª' || (Character.isLetter(ch)
> && (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
> [javac] ^
> [javac]
> C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
&g

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

I mean either make it possible to run the mdr7 on any positions - be it
suffix or prefix or the only part of the name - or for it being the only
part of the name - make it possible to set something for that case only in
the lines file to exclude those lines from address index - e.g.
mkgmap:noaddress=yes/1

On Thu, 2 Dec 2021 at 16:49, Gerd Petermann 
wrote:

> Hi Felix,
>
> don't understand what you mean. What mdr7 code could be adapted?
> Strings in MDR15 are deduplicated.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. Dezember 2021 16:42
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> ah okay - well I think the best would be either to adapt the mdr7 code -
> or to be able to set something in the lines/relations file that certain
> lines are never added to the address search. similar to the G3 Trk case I'm
> also thinking about lines that are duplicated - but it really would be
> enough if one of those lines is in the address index.
> Internally in my style I already have something where I probe for name=*
> DO whatever before attributes are added to the name - in order to treat
> lines which do not actually have a name different (e.g. house numbers -
> else house numbers are added e.g. to cycle lanes and cycle tracks)
>
> On Thu, 2 Dec 2021 at 14:30, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> sorry, I was wrong. a label "G3 TRK" or "T2 PTH" is completely ignored.
> Problem with prefixes remains.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> Gesendet: Donnerstag, 2. Dezember 2021 14:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Hi Felix,
>
> the logic for the mdr7-del probably doesn't work well for your style. It
> was meant to remove suffixes from names.
>
> A name like "M0. BOGENHOFWEG XBK XBK G2 TRK" is changed to "M0.
> BOGENHOFWEG", M0. is not a suffix.
>
> A road name like "G3 TRK" is not changed at alll because g3 and trk are
> both in your list and thus the algo finds no part that should be kept and
> stops.
> Maybe not the best idea.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Donnerstag, 2. Dezember 2021 13:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Thanks for all the debugging/help. I guess in 1 year or so the default
> style used with split-name-index will then also hit those limits on the
> Europe continent extract. Seems to be around 2GB. I will still have a look
> with the display tool for useless entries in the mdr index.
>
> On Thu, 2 Dec 2021 at 13:51, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi Felix,
>
> you can compile the display tool like mkgmap. svn repo is at
> https://svn.mkgmap.org.uk/mkgmap/display
> You need mkgmap to compile it. See mkgmap.dir in the build.xml.
>
> I have the sources in
> d:\display
> and
> d:\mkgmap
> and I just have to compile mkgmap before I can compile display tool.
>
> Gerd
>
> 
> Von: Gerd Petermann  gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com
> <mailto:gpetermann_muenc...@hotmail.com>>>
> Gesendet: Donnerstag, 2. Dezember 2021 13:45
> An: Development list for mkgmap
> Betreff: AW: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Hi Felix,
>
> I also wondered if the strings are case-sensitive, that's how I found out
> that your options don't work ;)
>
> The match is done ignoring the case. I'll add this to the dok.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk> mkgmap-dev-boun...@lists.mkgmap.

[mkgmap-dev] Building display.jar fails

[Felix Hartmann]

I can actually avoid it by placing mkgmap.jar into the display tool folder
- however then the display.jar is not working and ends with the notice:
"no main manifest attribute, in C:\openmtbmap\display.jar"




I get the following error I don't know how to solve when building the
display.jar display tool - with the mkgmap folder inserted into the
build.xml:

Buildfile: C:\openmtbmap\mkgmap_display\build.xml

prepare:
[mkdir] Created dir: C:\openmtbmap\mkgmap_display\build\classes

ivy-availability:

download-ivy:
[mkdir] Created dir: C:\openmtbmap\mkgmap_display\lib\build
  [get] Getting:
https://repo1.maven.org/maven2/org/apache/ivy/ivy/2.5.0/ivy-2.5.0.jar
  [get] To: C:\openmtbmap\mkgmap_display\lib\build\ivy-2.5.0.jar

init-ivy:
[ivy:configure] :: Apache Ivy 2.5.0 - 20191020104435 ::
https://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file =
C:\openmtbmap\mkgmap_display\ivysettings.xml

resolve-compile:

compile:
[javac] Compiling 589 source files to
C:\openmtbmap\mkgmap_display\build\classes
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
error: unclosed character literal
[javac] if (ch == 'ª' || (Character.isLetter(ch)
&& (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
[javac]   ^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
error: unclosed character literal
[javac] if (ch == 'ª' || (Character.isLetter(ch)
&& (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
[javac]  ^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
error: not a statement
[javac] if (ch == 'ª' || (Character.isLetter(ch)
&& (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
[javac] ^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
error: not a statement
[javac] if (ch == 'ª' || (Character.isLetter(ch)
&& (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
[javac]   ^
[javac]
C:\openmtbmap\mkgmap_display\src\uk\me\parabola\mkgmap\srt\SrtTextReader.java:416:
error: ';' expected
[javac] if (ch == 'ª' || (Character.isLetter(ch)
&& (Character.getType(ch) & Character.MODIFIER_LETTER) == 0))
[javac]
 ^
[javac] 5 errors





-- 
Felix Hartman - 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] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

ah okay - well I think the best would be either to adapt the mdr7 code - or
to be able to set something in the lines/relations file that certain lines
are never added to the address search. similar to the G3 Trk case I'm also
thinking about lines that are duplicated - but it really would be enough if
one of those lines is in the address index.
Internally in my style I already have something where I probe for name=* DO
whatever before attributes are added to the name - in order to treat lines
which do not actually have a name different (e.g. house numbers - else
house numbers are added e.g. to cycle lanes and cycle tracks)

On Thu, 2 Dec 2021 at 14:30, Gerd Petermann 
wrote:

> Hi Felix,
>
> sorry, I was wrong. a label "G3 TRK" or "T2 PTH" is completely ignored.
> Problem with prefixes remains.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Gerd Petermann 
> Gesendet: Donnerstag, 2. Dezember 2021 14:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Hi Felix,
>
> the logic for the mdr7-del probably doesn't work well for your style. It
> was meant to remove suffixes from names.
>
> A name like "M0. BOGENHOFWEG XBK XBK G2 TRK" is changed to "M0.
> BOGENHOFWEG", M0. is not a suffix.
>
> A road name like "G3 TRK" is not changed at alll because g3 and trk are
> both in your list and thus the algo finds no part that should be kept and
> stops.
> Maybe not the best idea.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. Dezember 2021 13:56
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Thanks for all the debugging/help. I guess in 1 year or so the default
> style used with split-name-index will then also hit those limits on the
> Europe continent extract. Seems to be around 2GB. I will still have a look
> with the display tool for useless entries in the mdr index.
>
> On Thu, 2 Dec 2021 at 13:51, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> you can compile the display tool like mkgmap. svn repo is at
> https://svn.mkgmap.org.uk/mkgmap/display
> You need mkgmap to compile it. See mkgmap.dir in the build.xml.
>
> I have the sources in
> d:\display
> and
> d:\mkgmap
> and I just have to compile mkgmap before I can compile display tool.
>
> Gerd
>
> 
> Von: Gerd Petermann  gpetermann_muenc...@hotmail.com>>
> Gesendet: Donnerstag, 2. Dezember 2021 13:45
> An: Development list for mkgmap
> Betreff: AW: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Hi Felix,
>
> I also wondered if the strings are case-sensitive, that's how I found out
> that your options don't work ;)
>
> The match is done ignoring the case. I'll add this to the dok.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Donnerstag, 2. Dezember 2021 13:27
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Oh yes, thanks you were right. Somehow I used semicolon instead of comma.
> It is still breaking however - difference being the temp file is 2.09GB
> instead of 2.33GB.
> BTW is the mdr7-del case insensitive if used together with lower-case? I
> hope it is.
>
> I cannot download the display tool - the link from here is not working:
> https://files.mkgmap.org.uk/detail/472
>
> (same for the older link).
>
> On Thu, 2 Dec 2021 at 11:53, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi Felix,
>
> I've noticed that your arguments in --mdr7-del are not comma separated.
> They probably have no effect.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk> mkgmap-dev-boun...@lists.mkgmap.org.uk mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpeterma

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

Thanks for all the debugging/help. I guess in 1 year or so the default
style used with split-name-index will then also hit those limits on the
Europe continent extract. Seems to be around 2GB. I will still have a look
with the display tool for useless entries in the mdr index.

On Thu, 2 Dec 2021 at 13:51, Gerd Petermann 
wrote:

> Hi Felix,
>
> you can compile the display tool like mkgmap. svn repo is at
> https://svn.mkgmap.org.uk/mkgmap/display
> You need mkgmap to compile it. See mkgmap.dir in the build.xml.
>
> I have the sources in
> d:\display
> and
> d:\mkgmap
> and I just have to compile mkgmap before I can compile display tool.
>
> Gerd
>
> 
> Von: Gerd Petermann 
> Gesendet: Donnerstag, 2. Dezember 2021 13:45
> An: Development list for mkgmap
> Betreff: AW: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Hi Felix,
>
> I also wondered if the strings are case-sensitive, that's how I found out
> that your options don't work ;)
>
> The match is done ignoring the case. I'll add this to the dok.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. Dezember 2021 13:27
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Oh yes, thanks you were right. Somehow I used semicolon instead of comma.
> It is still breaking however - difference being the temp file is 2.09GB
> instead of 2.33GB.
> BTW is the mdr7-del case insensitive if used together with lower-case? I
> hope it is.
>
> I cannot download the display tool - the link from here is not working:
> https://files.mkgmap.org.uk/detail/472
>
> (same for the older link).
>
> On Thu, 2 Dec 2021 at 11:53, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> I've noticed that your arguments in --mdr7-del are not comma separated.
> They probably have no effect.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> Gesendet: Mittwoch, 1. Dezember 2021 17:59
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Hi Felix,
>
> both --mdr7-del and --mdr7-excl are only evaluated when the global index
> is created. They have no effect on the tiles.
> You can use MdrDisplay with a smaller sample map to check what is written
> to the index.
>
> Garmin uses a compressed format for the string table (Mdr 15) but we don't
> know how the compression works.
> I guess we could add code to omit the string table. It's probably not
> mandantory. On the other hand I see no need for a detailed map
> of whole Europe anyway.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Mittwoch, 1. Dezember 2021 17:44
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> yes it is some sort of overflow - if I do the map in two runs (1500 tiles
> approx)
> with 65500*
> and 65501*
> it compiles fine.
> That's why I use a pretty long exclusion list - but this is not enough.
> The index without split-name-index is about half the size. I think the
> first list of options only matters on the actual mkgmap creation run - and
> does not change anything anymore on the second step of creating the address
> index. Maybe I missed a couple - but most should be excluded.
>
> --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

Oh yes, thanks you were right. Somehow I used semicolon instead of comma.
It is still breaking however - difference being the temp file is 2.09GB
instead of 2.33GB.
BTW is the mdr7-del case insensitive if used together with lower-case? I
hope it is.

I cannot download the display tool - the link from here is not working:
https://files.mkgmap.org.uk/detail/472

(same for the older link).

On Thu, 2 Dec 2021 at 11:53, Gerd Petermann 
wrote:

> Hi Felix,
>
> I've noticed that your arguments in --mdr7-del are not comma separated.
> They probably have no effect.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Gerd Petermann 
> Gesendet: Mittwoch, 1. Dezember 2021 17:59
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Hi Felix,
>
> both --mdr7-del and --mdr7-excl are only evaluated when the global index
> is created. They have no effect on the tiles.
> You can use MdrDisplay with a smaller sample map to check what is written
> to the index.
>
> Garmin uses a compressed format for the string table (Mdr 15) but we don't
> know how the compression works.
> I guess we could add code to omit the string table. It's probably not
> mandantory. On the other hand I see no need for a detailed map
> of whole Europe anyway.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Mittwoch, 1. Dezember 2021 17:44
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> yes it is some sort of overflow - if I do the map in two runs (1500 tiles
> approx)
> with 65500*
> and 65501*
> it compiles fine.
> That's why I use a pretty long exclusion list - but this is not enough.
> The index without split-name-index is about half the size. I think the
> first list of options only matters on the actual mkgmap creation run - and
> does not change anything anymore on the second step of creating the address
> index. Maybe I missed a couple - but most should be excluded.
>
> --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl
> bndry";admin_lv=4;"ntnl
> park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge
> river";"hugest river";"medium river";"small river";"wide river";"hugest
> canal";"huge canal";"medium canal";"small canal";"big
> canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath
> --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl
> bndry"
>
> On Wed, 1 Dec 2021 at 17:39, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> your index is probably s

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

Oh yeah the best solution would be if mkgmap kinda could create 4 maps of
Europe from all the Europe .img tiles with polygons/boxes created
manually/then provided as input file..

Splitting before and creating those 4 maps from scratch takes a lot more of
compilation time than the full Europe map alone.

On Wed, 1 Dec 2021 at 18:07, Felix Hartmann  wrote:

> It's still crashing also with patch v2.
> The full map of Europe serves one need - it is simpler than say creating 5
> maps of Europe with an Overlap. But yes I will simply create the continent
> maps of Europe and Asia without split-name-index (Asia has not crashed yet
> - but is its growing quickly).
>
> On Wed, 1 Dec 2021 at 17:44, Felix Hartmann 
> wrote:
>
>> yes it is some sort of overflow - if I do the map in two runs (1500 tiles
>> approx)
>> with 65500*
>> and 65501*
>> it compiles fine.
>> That's why I use a pretty long exclusion list - but this is not enough.
>> The index without split-name-index is about half the size. I think the
>> first list of options only matters on the actual mkgmap creation run - and
>> does not change anything anymore on the second step of creating the address
>> index. Maybe I missed a couple - but most should be excluded.
>>
>> --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl
>> bndry";admin_lv=4;"ntnl
>> park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge
>> river";"hugest river";"medium river";"small river";"wide river";"hugest
>> canal";"huge canal";"medium canal";"small canal";"big
>> canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath
>> --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl
>> bndry"
>>
>> On Wed, 1 Dec 2021 at 17:39, Gerd Petermann <
>> gpetermann_muenc...@hotmail.com> wrote:
>>
>>> Hi Felix,
>>>
>>> your index is probably simply too large (> 2GB).
>>> The attached patch fixes another possible overflow, but I am not sure if
>>> such a file size is allowed for the index.
>>>
>>> Maybe try to remove specific items from the index (see --mdr7-excl,
>>> --mdr7-del)
>>> I think the reason for the huge size is your style which combines a lot
>>> of information in the road name, e.g. "102 Thw-Göttinger Weg T2 Pth
>>> Zentralalpenweg 02 Hr"
>>> or "137 Mindener Jubiläumsweg T2 Pth Mindener Jubiläumsweg Hr"
>>> (found these in omtb_austria_13.05.2021)
>>> All this information is stored in the PC index (a string table), and
>>> with --split-name-index lots of entries are produced for strings like "Pth"
>>> or "T2" or "Hr"
>>>
>>> Gerd
>>>
>>> 
>>> Von: mkgmap-dev  im A

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

It's still crashing also with patch v2.
The full map of Europe serves one need - it is simpler than say creating 5
maps of Europe with an Overlap. But yes I will simply create the continent
maps of Europe and Asia without split-name-index (Asia has not crashed yet
- but is its growing quickly).

On Wed, 1 Dec 2021 at 17:44, Felix Hartmann  wrote:

> yes it is some sort of overflow - if I do the map in two runs (1500 tiles
> approx)
> with 65500*
> and 65501*
> it compiles fine.
> That's why I use a pretty long exclusion list - but this is not enough.
> The index without split-name-index is about half the size. I think the
> first list of options only matters on the actual mkgmap creation run - and
> does not change anything anymore on the second step of creating the address
> index. Maybe I missed a couple - but most should be excluded.
>
> --mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl
> bndry";admin_lv=4;"ntnl
> park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge
> river";"hugest river";"medium river";"small river";"wide river";"hugest
> canal";"huge canal";"medium canal";"small canal";"big
> canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath
> --mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl
> bndry"
>
> On Wed, 1 Dec 2021 at 17:39, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Felix,
>>
>> your index is probably simply too large (> 2GB).
>> The attached patch fixes another possible overflow, but I am not sure if
>> such a file size is allowed for the index.
>>
>> Maybe try to remove specific items from the index (see --mdr7-excl,
>> --mdr7-del)
>> I think the reason for the huge size is your style which combines a lot
>> of information in the road name, e.g. "102 Thw-Göttinger Weg T2 Pth
>> Zentralalpenweg 02 Hr"
>> or "137 Mindener Jubiläumsweg T2 Pth Mindener Jubiläumsweg Hr"
>> (found these in omtb_austria_13.05.2021)
>> All this information is stored in the PC index (a string table), and with
>> --split-name-index lots of entries are produced for strings like "Pth" or
>> "T2" or "Hr"
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> Felix Hartmann 
>> Gesendet: Mittwoch, 1. Dezember 2021 17:16
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Exception in thread "main"
>> java.lang.IllegalArgumentException . on Europe extract
>>
>> I found out that if I remove --split-name-index then it compiles fine.
>> I'm just trying a minimal setup option wise and could look if it's a
>> special .img tile or not.
>> I could upload all map tiles somewhere for further analysis - or try some
>> more t

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

yes it is some sort of overflow - if I do the map in two runs (1500 tiles
approx)
with 65500*
and 65501*
it compiles fine.
That's why I use a pretty long exclusion list - but this is not enough. The
index without split-name-index is about half the size. I think the first
list of options only matters on the actual mkgmap creation run - and  does
not change anything anymore on the second step of creating the address
index. Maybe I missed a couple - but most should be excluded.

--mdr7-del=pri;sec;ter;cw;min;unsf,uncl;living;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;bridge;swing;aqueduct;viaduct;"ntnl
bndry";admin_lv=4;"ntnl
park";weir;dam;waterfall;rapids;stream;river;drain;ditch;"huge
river";"hugest river";"medium river";"small river";"wide river";"hugest
canal";"huge canal";"medium canal";"small canal";"big
canal";canal;snowpark;Skitour-descent;Skipiste;Skislope;illuminated;Nordic-Skiing;skitour;platter;ropetow;tbar;chairlift;goods_lift;runway;taxiway;apron;VFS0;VFS1;VFS2;VFS3;VFS4;VFS5;VFS6;VFS7;usf;cstrn;steps;parking_aisle;res;cob;cobstn;public_footway;public_footpath
--mdr7-excl=pri;sec;ter;cw;min;unsf,uncl;pdstrn;trk;pth;ft;fp;brdlw;rd;byw;ser;cw;mrt;crt;Bklane;Bktrk;opp;Opptrk;g0;g1;g2;g3;g4;g5;g6;t1;t2;t3;t4;t5;t6;xbk;cr;mr;hr;mr0;mr1;mr2;mr3;mr4;mr5;mr0.;mr1.;mr2.;mr3.;mr4.;mr5.;mr6.;mr00;mr01;mr02;mr03;mr04;mr05;mr06;mr11;mr12;mr13;mr14;mr15;mr16;mr20;mr21;mr22;mr23;mr24;mr25;mr26;mr30;mr31;mr32;mr33;mr34;mr35;mr35;mr40;mr41;mr41;mr43;mr44;mr45;mr46;mr50;mr51;mr52;mr53;mr54;mr55;mr56;mr60;mr61;mr62;mr63;mr64;mr65;mr66;m0;m1;m2;m3;m4;m5;m0.;m1.;m2.;m3.;m4.;m5.;m6.;m00;m01;m02;m03;m04;m05;m06;m11;m12;m13;m14;m15;m16;m20;m21;m22;m23;m24;m25;m26;m30;m31;m32;m33;m34;m35;m35;m40;m41;m41;m43;m44;m45;m46;m50;m51;m52;m53;m54;m55;m56;m60;m61;m62;m63;m64;m65;m66;mr.0;mr.1;mr.2;mr.3;mr.4;mr.5;mr.6;m.0;m.1;m.2;m.3;m.4;m.5;m.6;m1.;m2.;m3.;m4.;m5.;m6.;lmr;mrx0;mrx1;mrx2;mrx3;mrx4;mrx5;mrx6;mx0;mx1;mx2;mx3;mx4;mx5;mx6;"ntnl
bndry"

On Wed, 1 Dec 2021 at 17:39, Gerd Petermann 
wrote:

> Hi Felix,
>
> your index is probably simply too large (> 2GB).
> The attached patch fixes another possible overflow, but I am not sure if
> such a file size is allowed for the index.
>
> Maybe try to remove specific items from the index (see --mdr7-excl,
> --mdr7-del)
> I think the reason for the huge size is your style which combines a lot of
> information in the road name, e.g. "102 Thw-Göttinger Weg T2 Pth
> Zentralalpenweg 02 Hr"
> or "137 Mindener Jubiläumsweg T2 Pth Mindener Jubiläumsweg Hr"
> (found these in omtb_austria_13.05.2021)
> All this information is stored in the PC index (a string table), and with
> --split-name-index lots of entries are produced for strings like "Pth" or
> "T2" or "Hr"
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Mittwoch, 1. Dezember 2021 17:16
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> I found out that if I remove --split-name-index then it compiles fine. I'm
> just trying a minimal setup option wise and could look if it's a special
> .img tile or not.
> I could upload all map tiles somewhere for further analysis - or try some
> more things before doing that (12GB data or so).
>
> On Wed, 1 Dec 2021 at 13:08, Felix Hartmann  <mailto:extremecar...@gmail.com>> wrote:
> Hi Gerd,
>
> here is the log - hope you can find out something with it - but I think it
> is missing the problem - there are only 3 lines before the crash - all else
> is many minutes before.
>
> 2021/12/01 12:55:08 INFO (ImgFS): bs=512, whole size=-1789952000,
> hb=-14501, fb=-3481499, blocks=-3496000
>
> 2021/12/01 12:55:08 INFO (ImgFS): bs=1024, whole size=-1786235904,
> hb=-3623, fb=-1740748, blocks=-1744371
>
> 2021/12/01 12:55:08 INFO (I

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

I found out that if I remove *--split-name-index* then it compiles fine.
I'm just trying a minimal setup option wise and could look if it's a
special .img tile or not.
I could upload all map tiles somewhere for further analysis - or try some
more things before doing that (12GB data or so).

On Wed, 1 Dec 2021 at 13:08, Felix Hartmann  wrote:

> Hi Gerd,
>
> here is the log - hope you can find out something with it - but I think it
> is missing the problem - there are only 3 lines before the crash - all else
> is many minutes before.
>
> 2021/12/01 12:55:08 INFO (ImgFS): bs=512, whole size=-1789952000,
> hb=-14501, fb=-3481499, blocks=-3496000
>
> 2021/12/01 12:55:08 INFO (ImgFS): bs=1024, whole size=-1786235904,
> hb=-3623, fb=-1740748, blocks=-1744371
>
> 2021/12/01 12:55:08 INFO (ImgFS): Best block size: 512
> sizeInBlocks=-3496000, reserved=-14501
>
>
> On Wed, 1 Dec 2021 at 08:57, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Felix,
>>
>> hm, in that case one of the two factors is already negative.
>> You can enable logging and run the combiner step again (no need to
>> compile the tiles again)
>> Add this to the log config:
>> uk.me.parabola.imgfmt.sys.ImgFS.level=FINE
>>
>> BTW: The index contains not only address search data, also POI.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> Felix Hartmann 
>> Gesendet: Mittwoch, 1. Dezember 2021 02:27
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] Exception in thread "main"
>> java.lang.IllegalArgumentException . on Europe extract
>>
>> Hi Gerd,
>>
>> thanks for the quick response. Any other way I can try to get more debug
>> information?
>>
>> I tried with the patch but I still get:
>> gmapi-minimal: Skipping file
>> E:\OpenMTBMap\contourlines20\europe\75500448.img
>> Exception in thread "main" java.lang.IllegalArgumentException
>> at java.base/sun.nio.ch
>> .FileChannelImpl.position(FileChannelImpl.java:355)
>> at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:249)
>> at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:325)
>> at
>> uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:334)
>> at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
>> 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)
>>
>> On Tue, 30 Nov 2021 at 14:48, Gerd Petermann <
>> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
>> wrote:
>> Hi Felix,
>>
>> might be an overflow. The code line is
>> file.position(param.getReservedDirectoryBlocks() * param.getBlockSize());
>>
>> so two ints are multiplied.
>>
>> Please try if the attached patch changes something.
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev > mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
>> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
>> Gesendet: Dienstag, 30. November 2021 13:23
>> An: Development list for mkgmap
>> Betreff: [mkgmap-dev] Exception in thread "main"
>> java.lang.IllegalArgumentException . on Europe extract
>>
>> Using mkgmap version 4808 - when compiling Europe. It went through fine
>> on all geofabrik country extracts.
>> I then upgraded to mkgmap 4819 and yesterday downloaded a new europe
>> extract (4 days newer) from geofabrik to see if I can reproduce it again -
>> and the error message is identical.
>> I'm going to run with default style now again - to see if it makes a
>> difference.
>>
>> C:\openmtbmap\mkgmap.jar --max-jobs=11 --order-by-decreasing-area
>> "--generate-sea" --code-page=65001
>> "--precomp-sea=E:\OpenMTBMap\osmpbf_geofabrik\sea.zip"
>> "--style-file=C:\openmtbmap\openmtbmap_style"
>> --add-boundary-nodes-at-admin-boundaries --fix-roundabout-direction
>> --improve-overview --drive-on=detect --allow-reverse-merge --lower-case
>> --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18"
>> --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12"
>> --add-pois-to-areas
>> --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
>> --simplify-lines=23:2.6

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

Hi Gerd,

thanks for the quick response. Any other way I can try to get more debug
information?

I tried with the patch but I still get:
gmapi-minimal: Skipping file
E:\OpenMTBMap\contourlines20\europe\75500448.img
Exception in thread "main" java.lang.IllegalArgumentException
at
java.base/sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:355)
at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:249)
at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:325)
at
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:334)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
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)

On Tue, 30 Nov 2021 at 14:48, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> might be an overflow. The code line is
> file.position(param.getReservedDirectoryBlocks() * param.getBlockSize());
>
> so two ints are multiplied.
>
> Please try if the attached patch changes something.
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Dienstag, 30. November 2021 13:23
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] Exception in thread "main"
> java.lang.IllegalArgumentException . on Europe extract
>
> Using mkgmap version 4808 - when compiling Europe. It went through fine on
> all geofabrik country extracts.
> I then upgraded to mkgmap 4819 and yesterday downloaded a new europe
> extract (4 days newer) from geofabrik to see if I can reproduce it again -
> and the error message is identical.
> I'm going to run with default style now again - to see if it makes a
> difference.
>
> C:\openmtbmap\mkgmap.jar --max-jobs=11 --order-by-decreasing-area
> "--generate-sea" --code-page=65001
> "--precomp-sea=E:\OpenMTBMap\osmpbf_geofabrik\sea.zip"
> "--style-file=C:\openmtbmap\openmtbmap_style"
> --add-boundary-nodes-at-admin-boundaries --fix-roundabout-direction
> --improve-overview --drive-on=detect --allow-reverse-merge --lower-case
> --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18"
> --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12"
> --add-pois-to-areas
> --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
> --simplify-lines=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:4.5,16:5,15:5,14:6
> --simplify-polygons=23:3.6,22:7,21:6,20:9,17:5.4
> --add-boundary-nodes-at-admin-boundaries=2 --cycle-map
> --ignore-fixme-values --housenumbers
> --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt
> --split-name-index --link-pois-to-ways --ignore-turn-restrictions
> --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20,
> 17:20, 16:20, 15:20, 14:20, 13:25" --description=omtb_eu --show-profiles=1
> --location-autofill=bounds,is_in,nearest
> --bounds=E:\OpenMTBMap\osmpbf_geofabrik\bounds.zip --route
> --country-abbr=eu --country-name=europe --mapname=6550 --family-id=6550
> --product-id=1 --series-name=omtb_europe_29.11.2021_UC_LOCAL
> --family-name=mtb_eu_29.11.2021_UC_LOCAL --tdbfile --x-gmapi-minimal
> --overview-mapname=mapsetc --keep-going
> --area-name="europe_29.11.2021_UC_LOCAL_omtb" -c
> D:\openmtbmap\maps\template.europe
> E:\OpenMTBMap\contourlines20\europe\7*.img typeu.TYP  1>NUL
>
>
> Number of MapFailedExceptions: 0
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6550.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6551.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6552.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6553.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6554.img
> 
> skipped
> .
> long list of contourline files:
> .
> gmapi-minimal: Skipping file
> E:\OpenMTBMap\contourlines20\europe\75500447.img
> WARNING (global): Input file
> E:\OpenMTBMap\contourlines20\europe\75500448.img has different code page
> 1252
> WARNING (global): Input file
> E:\OpenMTBMap\contourlines20\europe\75500448.img has different charset type
> 10
> WARNING (global): Input files have different code pages
> gmapi-minimal: Skipping file
> E:\OpenMTBMap\contourlines20\europe\75500448.img
>  448 is the highest number contourlines file
>
> And here comes the error
> it happens on writing the address index 

Re: [mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

With the default style the error does not pop up. Any solution on what I
can do to analyse this? I cannot ever remember a style-dependant bug on the
address index creation - that also only shows up very sporadically (of
virtually all geofabrik extracts - it only happens on Europe continent).

On Tue, 30 Nov 2021 at 13:23, Felix Hartmann 
wrote:

> Using mkgmap version 4808 - when compiling Europe. It went through fine on
> all geofabrik country extracts.
> I then upgraded to mkgmap 4819 and yesterday downloaded a new europe
> extract (4 days newer) from geofabrik to see if I can reproduce it again -
> and the error message is identical.
> I'm going to run with default style now again - to see if it makes a
> difference.
>
> C:\openmtbmap\mkgmap.jar --max-jobs=11 --order-by-decreasing-area
>  "--generate-sea" --code-page=65001
> "--precomp-sea=E:\OpenMTBMap\osmpbf_geofabrik\sea.zip"
> "--style-file=C:\openmtbmap\openmtbmap_style"
> --add-boundary-nodes-at-admin-boundaries --fix-roundabout-direction
> --improve-overview --drive-on=detect --allow-reverse-merge --lower-case
> --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18"
> --overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12"
> --add-pois-to-areas
> --pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
> --simplify-lines=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:4.5,16:5,15:5,14:6
>  --simplify-polygons=23:3.6,22:7,21:6,20:9,17:5.4
> --add-boundary-nodes-at-admin-boundaries=2 --cycle-map
> --ignore-fixme-values --housenumbers
> --road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt
> --split-name-index --link-pois-to-ways --ignore-turn-restrictions
> --polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20,
> 17:20, 16:20, 15:20, 14:20, 13:25" --description=omtb_eu --show-profiles=1
>  --location-autofill=bounds,is_in,nearest
> --bounds=E:\OpenMTBMap\osmpbf_geofabrik\bounds.zip --route
> --country-abbr=eu --country-name=europe --mapname=6550 --family-id=6550
> --product-id=1 --series-name=omtb_europe_29.11.2021_UC_LOCAL
> --family-name=mtb_eu_29.11.2021_UC_LOCAL --tdbfile --x-gmapi-minimal
> --overview-mapname=mapsetc --keep-going
> --area-name="europe_29.11.2021_UC_LOCAL_omtb" -c
> D:\openmtbmap\maps\template.europe
> E:\OpenMTBMap\contourlines20\europe\7*.img typeu.TYP  1>NUL
>
>
> Number of MapFailedExceptions: 0
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6550.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6551.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6552.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6553.img
> gmapi-minimal: Writing freshly compiled file
> C:\openmtbmap\maps\.\6554.img
> 
> skipped
> .
> long list of contourline files:
> .
> gmapi-minimal: Skipping file
> E:\OpenMTBMap\contourlines20\europe\75500447.img
> WARNING (global): Input file
> E:\OpenMTBMap\contourlines20\europe\75500448.img has different code page
> 1252
> WARNING (global): Input file
> E:\OpenMTBMap\contourlines20\europe\75500448.img has different charset type
> 10
> WARNING (global): Input files have different code pages
> gmapi-minimal: Skipping file
> E:\OpenMTBMap\contourlines20\europe\75500448.img
>  448 is the highest number contourlines file
>
> *And here comes the error*
> it happens on writing the address index mdr file - mapset.img and
> mapset.tdb have already been created.
>
> Exception in thread "main" java.lang.IllegalArgumentException
> at
> java.base/sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:355)
> at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:249)
> at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:325)
> at
> uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:334)
> at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
> 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)
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>

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

[mkgmap-dev] Exception in thread "main" java.lang.IllegalArgumentException . on Europe extract

[Felix Hartmann]

Using mkgmap version 4808 - when compiling Europe. It went through fine on
all geofabrik country extracts.
I then upgraded to mkgmap 4819 and yesterday downloaded a new europe
extract (4 days newer) from geofabrik to see if I can reproduce it again -
and the error message is identical.
I'm going to run with default style now again - to see if it makes a
difference.

C:\openmtbmap\mkgmap.jar --max-jobs=11 --order-by-decreasing-area
 "--generate-sea" --code-page=65001
"--precomp-sea=E:\OpenMTBMap\osmpbf_geofabrik\sea.zip"
"--style-file=C:\openmtbmap\openmtbmap_style"
--add-boundary-nodes-at-admin-boundaries --fix-roundabout-direction
--improve-overview --drive-on=detect --allow-reverse-merge --lower-case
--nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18"
--overview-levels="7:17, 8:16, 9:15, 10:14, 11:13, 12:12"
--add-pois-to-areas
--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
--simplify-lines=23:2.6,22:4.2,21:5.4,20:6,19:7,18:7.5,17:4.5,16:5,15:5,14:6
 --simplify-polygons=23:3.6,22:7,21:6,20:9,17:5.4
--add-boundary-nodes-at-admin-boundaries=2 --cycle-map
--ignore-fixme-values --housenumbers
--road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt
--split-name-index --link-pois-to-ways --ignore-turn-restrictions
--polygon-size-limits="24:12, 23:14, 22:14, 21:20, 20:20, 19:20, 18:20,
17:20, 16:20, 15:20, 14:20, 13:25" --description=omtb_eu --show-profiles=1
 --location-autofill=bounds,is_in,nearest
--bounds=E:\OpenMTBMap\osmpbf_geofabrik\bounds.zip --route
--country-abbr=eu --country-name=europe --mapname=6550 --family-id=6550
--product-id=1 --series-name=omtb_europe_29.11.2021_UC_LOCAL
--family-name=mtb_eu_29.11.2021_UC_LOCAL --tdbfile --x-gmapi-minimal
--overview-mapname=mapsetc --keep-going
--area-name="europe_29.11.2021_UC_LOCAL_omtb" -c
D:\openmtbmap\maps\template.europe
E:\OpenMTBMap\contourlines20\europe\7*.img typeu.TYP  1>NUL


Number of MapFailedExceptions: 0
gmapi-minimal: Writing freshly compiled file
C:\openmtbmap\maps\.\6550.img
gmapi-minimal: Writing freshly compiled file
C:\openmtbmap\maps\.\6551.img
gmapi-minimal: Writing freshly compiled file
C:\openmtbmap\maps\.\6552.img
gmapi-minimal: Writing freshly compiled file
C:\openmtbmap\maps\.\6553.img
gmapi-minimal: Writing freshly compiled file
C:\openmtbmap\maps\.\6554.img

skipped
.
long list of contourline files:
.
gmapi-minimal: Skipping file
E:\OpenMTBMap\contourlines20\europe\75500447.img
WARNING (global): Input file
E:\OpenMTBMap\contourlines20\europe\75500448.img has different code page
1252
WARNING (global): Input file
E:\OpenMTBMap\contourlines20\europe\75500448.img has different charset type
10
WARNING (global): Input files have different code pages
gmapi-minimal: Skipping file
E:\OpenMTBMap\contourlines20\europe\75500448.img
 448 is the highest number contourlines file

*And here comes the error*
it happens on writing the address index mdr file - mapset.img and
mapset.tdb have already been created.

Exception in thread "main" java.lang.IllegalArgumentException
at
java.base/sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:355)
at uk.me.parabola.imgfmt.sys.ImgFS.sync(ImgFS.java:249)
at uk.me.parabola.imgfmt.sys.ImgFS.close(ImgFS.java:325)
at
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:334)
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
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)



-- 
Felix Hartman - 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] Failure to understand apply logic in relations - or failure in the logic

[Felix Hartmann]

Ah sorry - I missed the entry about that point in the style manual Now
I understand it.

On Thu, 25 Nov 2021 at 18:00, Felix Hartmann 
wrote:

> Oh sorry - no my mistake was different - I used the wrong brackets.
> However I could not find anywhere where this is documented.
> working:
> set route_name_hiking1 = '$*(route_name_hiking1)* + ${name|not-contained:
> + :route_name_hiking1}' | 'IWN ${name}' | *'$(route_name_hiking1)*' |
> 'IWN'
>
> not working:
> set route_name_hiking1 = '$*{route_name_hiking1}* + ${name|not-contained:
> + :route_name_hiking1}' | 'IWN ${name}' | *'${route_name_hiking1}*' |
> 'IWN'
>
> Why do we have to use standard brackets when referencing a value inside
> the apply action? Usually for referencing a value we need to use curly {}
> brackets...
>
> On Thu, 25 Nov 2021 at 16:17, Felix Hartmann 
> wrote:
>
>> I think there is a bug in mkgmap.
>>
>> This line works as intended:
>> set route_name_hiking1 = '${route_name_hiking1} + ${name|not-contained: +
>> :route_name_hiking1}' | 'IWN ${name}' | '${route_name_hiking1}' | 'IWN'
>> while this line in the relations file fails to work as expected - the
>> part after the + is not added - or at least not visible (strangely the map
>> size is pretty similar).
>> set route_name_hiking1 = '${route_name_hiking1} + ${name}' | 'IWN
>> ${name}' | '${route_name_hiking1}' | 'IWN'
>>
>>
>> So only by including the not-contained filter ithe relations file is
>> actually adding the names of the routes after each other - while they are
>> not added without such a filter.
>>
>> On Wed, 24 Nov 2021 at 10:45, Felix Hartmann 
>> wrote:
>>
>>> I will try your example to see where it goes wrong. Apply_once is about
>>> forward and backward relations. It should not matter:
>>> https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/006268.html
>>>
>>> On Tue, 23 Nov 2021, 19:32 Mike Baggaley  wrote:
>>>
>>>> Hi Felix,
>>>>
>>>>
>>>>
>>>> This is what I have in my relations file for routes:
>>>>
>>>>
>>>>
>>>> type=route & state!=proposed & route~'.*bicycle.*' & network~'.*ncn.*'
>>>> & ref~'\d*' { apply_once { set nationalbicycleroute=yes; set rn='$(rn)
>>>> & ${ref|not-contained: & :rn}' | '$(rn)' | '${ref}'; set nrn='$(nrn) &
>>>> ${ref|not-contained: & :nrn}' | '$(nrn)' | '${ref}'; } }
>>>>
>>>> type=route & state!=proposed & route~'.*bicycle.*' & network~'.*rcn.*'
>>>> & ref~'\d*' { apply_once { set regionalbicycleroute=yes; set rn='$(rn)
>>>> & ${ref|not-contained: & :rn}' | '$(rn)' | '${ref}'; } }
>>>>
>>>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*')
>>>> & network~'.*[nr]wn.*' & name~".*\(.*\)" { set name='${name|subst
>>>> :"\(.*\)~>"}'}
>>>>
>>>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*')
>>>> & network~'.*nwn.*' & name=* { apply_once { set nationalhikingroute=yes;
>>>> set rn='$(rn) & ${name|not-contained: & :rn}' | '$(rn)' | '${name}';
>>>> set nrn='$(nrn) & ${name|not-contained: & :nrn}' | '$(nrn)' |
>>>> '${name}'; set nwrn='$(nwrn) & ${name|not-contained: & :nwrn}' | '$(
>>>> nwrn)' | '${name}'; } }
>>>>
>>>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*')
>>>> & network~'.*rwn.*' & name=* { apply_once { set regionalhikingroute=yes;
>>>> set rn='$(rn) & ${name|not-contained: & :rn}' | '$(rn)' | '${name}'; }
>>>> }
>>>>
>>>>
>>>>
>>>> The most significant difference is that I have apply_once rather than
>>>> apply.
>>>>
>>>>
>>>>
>>>> Hope this helps,
>>>>
>>>> Mike
>>>>
>>>>
>>>>
>>>> *From:* Felix Hartmann [mailto:extremecar...@gmail.com]
>>>> *Sent:* 23 November 2021 13:31
>>>> *To:* Development list for mkgmap 
>>>> *Subject:* [mkgmap-dev] Failure to understand apply logic in relations
>>>> - or failure in the logic
>>>>
>>>>
>>>>
>>>> route=hiking { apply { set route=hiking; set route_name =
>>>> '${route_name} & ${name}' | '${name}'; add route_ref = '${ref}'; } }
>>>>
>>>>
>>>>
>>>> I would expect that this rule if several relations are matching one
>>>> line, adds all names of route=hiking relations to the route_name variable
>>>> separated by "&". However it is only adding the first found.
>>>>
>>>>
>>>>
>>>> Where is my mistake?
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>>>
>>>>
>>>>
>>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>
>>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>

-- 
Felix Hartman - 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] Failure to understand apply logic in relations - or failure in the logic

[Felix Hartmann]

Oh sorry - no my mistake was different - I used the wrong brackets. However
I could not find anywhere where this is documented.
working:
set route_name_hiking1 = '$*(route_name_hiking1)* + ${name|not-contained: +
:route_name_hiking1}' | 'IWN ${name}' | *'$(route_name_hiking1)*' | 'IWN'

not working:
set route_name_hiking1 = '$*{route_name_hiking1}* + ${name|not-contained: +
:route_name_hiking1}' | 'IWN ${name}' | *'${route_name_hiking1}*' | 'IWN'

Why do we have to use standard brackets when referencing a value inside the
apply action? Usually for referencing a value we need to use curly {}
brackets...

On Thu, 25 Nov 2021 at 16:17, Felix Hartmann 
wrote:

> I think there is a bug in mkgmap.
>
> This line works as intended:
> set route_name_hiking1 = '${route_name_hiking1} + ${name|not-contained: +
> :route_name_hiking1}' | 'IWN ${name}' | '${route_name_hiking1}' | 'IWN'
> while this line in the relations file fails to work as expected - the part
> after the + is not added - or at least not visible (strangely the map size
> is pretty similar).
> set route_name_hiking1 = '${route_name_hiking1} + ${name}' | 'IWN ${name}'
> | '${route_name_hiking1}' | 'IWN'
>
>
> So only by including the not-contained filter ithe relations file is
> actually adding the names of the routes after each other - while they are
> not added without such a filter.
>
> On Wed, 24 Nov 2021 at 10:45, Felix Hartmann 
> wrote:
>
>> I will try your example to see where it goes wrong. Apply_once is about
>> forward and backward relations. It should not matter:
>> https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/006268.html
>>
>> On Tue, 23 Nov 2021, 19:32 Mike Baggaley  wrote:
>>
>>> Hi Felix,
>>>
>>>
>>>
>>> This is what I have in my relations file for routes:
>>>
>>>
>>>
>>> type=route & state!=proposed & route~'.*bicycle.*' & network~'.*ncn.*'
>>> & ref~'\d*' { apply_once { set nationalbicycleroute=yes; set rn='$(rn)
>>> & ${ref|not-contained: & :rn}' | '$(rn)' | '${ref}'; set nrn='$(nrn) &
>>> ${ref|not-contained: & :nrn}' | '$(nrn)' | '${ref}'; } }
>>>
>>> type=route & state!=proposed & route~'.*bicycle.*' & network~'.*rcn.*'
>>> & ref~'\d*' { apply_once { set regionalbicycleroute=yes; set rn='$(rn)
>>> & ${ref|not-contained: & :rn}' | '$(rn)' | '${ref}'; } }
>>>
>>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*') &
>>> network~'.*[nr]wn.*' & name~".*\(.*\)" { set name='${name|subst
>>> :"\(.*\)~>"}'}
>>>
>>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*') &
>>> network~'.*nwn.*' & name=* { apply_once { set nationalhikingroute=yes;
>>> set rn='$(rn) & ${name|not-contained: & :rn}' | '$(rn)' | '${name}';
>>> set nrn='$(nrn) & ${name|not-contained: & :nrn}' | '$(nrn)' |
>>> '${name}'; set nwrn='$(nwrn) & ${name|not-contained: & :nwrn}' | '$(nwrn)'
>>> | '${name}'; } }
>>>
>>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*') &
>>> network~'.*rwn.*' & name=* { apply_once { set regionalhikingroute=yes;
>>> set rn='$(rn) & ${name|not-contained: & :rn}' | '$(rn)' | '${name}'; } }
>>>
>>>
>>>
>>> The most significant difference is that I have apply_once rather than
>>> apply.
>>>
>>>
>>>
>>> Hope this helps,
>>>
>>> Mike
>>>
>>>
>>>
>>> *From:* Felix Hartmann [mailto:extremecar...@gmail.com]
>>> *Sent:* 23 November 2021 13:31
>>> *To:* Development list for mkgmap 
>>> *Subject:* [mkgmap-dev] Failure to understand apply logic in relations
>>> - or failure in the logic
>>>
>>>
>>>
>>> route=hiking { apply { set route=hiking; set route_name = '${route_name}
>>> & ${name}' | '${name}'; add route_ref = '${ref}'; } }
>>>
>>>
>>>
>>> I would expect that this rule if several relations are matching one
>>> line, adds all names of route=hiking relations to the route_name variable
>>> separated by "&". However it is only adding the first found.
>>>
>>>
>>>
>>> Where is my mistake?
>>>
>>>
>>>
>>> --
>>>
>>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>>
>>>
>>>
>>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>

-- 
Felix Hartman - 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] Failure to understand apply logic in relations - or failure in the logic

[Felix Hartmann]

I think there is a bug in mkgmap.

This line works as intended:
set route_name_hiking1 = '${route_name_hiking1} + ${name|not-contained: +
:route_name_hiking1}' | 'IWN ${name}' | '${route_name_hiking1}' | 'IWN'
while this line in the relations file fails to work as expected - the part
after the + is not added - or at least not visible (strangely the map size
is pretty similar).
set route_name_hiking1 = '${route_name_hiking1} + ${name}' | 'IWN ${name}'
| '${route_name_hiking1}' | 'IWN'


So only by including the not-contained filter ithe relations file is
actually adding the names of the routes after each other - while they are
not added without such a filter.

On Wed, 24 Nov 2021 at 10:45, Felix Hartmann 
wrote:

> I will try your example to see where it goes wrong. Apply_once is about
> forward and backward relations. It should not matter:
> https://www.mkgmap.org.uk/pipermail/mkgmap-dev/2010q1/006268.html
>
> On Tue, 23 Nov 2021, 19:32 Mike Baggaley  wrote:
>
>> Hi Felix,
>>
>>
>>
>> This is what I have in my relations file for routes:
>>
>>
>>
>> type=route & state!=proposed & route~'.*bicycle.*' & network~'.*ncn.*' &
>> ref~'\d*' { apply_once { set nationalbicycleroute=yes; set rn='$(rn) & ${
>> ref|not-contained: & :rn}' | '$(rn)' | '${ref}'; set nrn='$(nrn) & ${
>> ref|not-contained: & :nrn}' | '$(nrn)' | '${ref}'; } }
>>
>> type=route & state!=proposed & route~'.*bicycle.*' & network~'.*rcn.*' &
>> ref~'\d*' { apply_once { set regionalbicycleroute=yes; set rn='$(rn) & ${
>> ref|not-contained: & :rn}' | '$(rn)' | '${ref}'; } }
>>
>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*') &
>> network~'.*[nr]wn.*' & name~".*\(.*\)" { set name='${name|subst
>> :"\(.*\)~>"}'}
>>
>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*') &
>> network~'.*nwn.*' & name=* { apply_once { set nationalhikingroute=yes;
>> set rn='$(rn) & ${name|not-contained: & :rn}' | '$(rn)' | '${name}'; set
>> nrn='$(nrn) & ${name|not-contained: & :nrn}' | '$(nrn)' | '${name}'; set
>> nwrn='$(nwrn) & ${name|not-contained: & :nwrn}' | '$(nwrn)' | '${name}';
>> } }
>>
>> type=route & state!=proposed & (route~'.*foot.*' | route~'.*hiking.*') &
>> network~'.*rwn.*' & name=* { apply_once { set regionalhikingroute=yes;
>> set rn='$(rn) & ${name|not-contained: & :rn}' | '$(rn)' | '${name}'; } }
>>
>>
>>
>> The most significant difference is that I have apply_once rather than
>> apply.
>>
>>
>>
>> Hope this helps,
>>
>> Mike
>>
>>
>>
>> *From:* Felix Hartmann [mailto:extremecar...@gmail.com]
>> *Sent:* 23 November 2021 13:31
>> *To:* Development list for mkgmap 
>> *Subject:* [mkgmap-dev] Failure to understand apply logic in relations -
>> or failure in the logic
>>
>>
>>
>> route=hiking { apply { set route=hiking; set route_name = '${route_name}
>> & ${name}' | '${name}'; add route_ref = '${ref}'; } }
>>
>>
>>
>> I would expect that this rule if several relations are matching one line,
>> adds all names of route=hiking relations to the route_name variable
>> separated by "&". However it is only adding the first found.
>>
>>
>>
>> Where is my mistake?
>>
>>
>>
>> --
>>
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>
>>
>>
>

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

[mkgmap-dev] Failure to understand apply logic in relations - or failure in the logic

[Felix Hartmann]

route=hiking { apply { set route=hiking; set route_name = '${route_name} &
${name}' | '${name}'; add route_ref = '${ref}'; } }

I would expect that this rule if several relations are matching one line,
adds all names of route=hiking relations to the route_name variable
separated by "&". However it is only adding the first found.

Where is my mistake?

-- 
Felix Hartman - 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] New assertion, now with code-page=632 and Japan tile

[Felix Hartmann]

O5m is always faster, but needs more disk space. Converting geofabrik
osm.pbf to o5m makes sense however (especially if you can write to Ramdisk
or slow Harddisk)

On Wed, 10 Nov 2021, 17:38 Carlos Dávila 
wrote:

> I'm aware of the supposed advantages of pbf, but I did some tests in the
> past and I found o5m to be quite faster than pbf, but I'll test again.
>
> El 10/11/21 a las 9:43, Gerd Petermann escribió:
> > Hi Carlos,
> >
> > I'll try to debug this.
> >
> > BTW: I see you use *.o5m for the tiles (output from splitter). I think
> this is no longer a good choice, pbf is a lot smaller and almost as fast.
> Esp. when it comes to the goal of reducing disk I/O (as with
> --gmapi-minimal)
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag von
> Carlos Dávila 
> > Gesendet: Dienstag, 9. November 2021 22:54
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] New assertion,now with code-page=632
> and Japan tile
> >
> > Hi Ticker
> >
> > Not sure if relevant, but note in this case assertion occurs while
> > compiling the tile, not the index. In fact, --index is not included in
> > the command.
> >
> > El 9/11/21 a las 21:55, Ticker Berkin escribió:
> >> Hi
> >>
> >> I think this assertion could be removed from the code.
> >>
> >> Looking through the definition of Shift-JIS, I read it as saying the
> >> second byte shouldn't be zero, so I don't know why this happens.
> >>
> >> As with the Chinese code-pages, mkgmap has places where multi-byte
> >> encodings are not handled correctly in the --index generation and
> >> unknown meanings of flags to the Garmin software.
> >>
> >> Ticker
> >>
> >>
> >>
> >> On 09/11/2021 19:43, Carlos Dávila wrote:
> >>> code-page=932, sorry for the typo.
> >>>
> >>> El 9/11/21 a las 20:36, Carlos Dávila escribió:
>  The command below produces an assertion while compiling this tile
>   from Japan.
>  Process continues with remaining tiles and finishes without "Number
>  of MapFailedExceptions: 1" as expected. This is with r4813, but I
>  also tried with an old version of mkgmap with the same result.
> 
>  java -Xmx27G -ea -jar mkgmap.jar--code-page=632 31191025.o5m
>  Mkgmap version 4813
>  Time started: Tue Nov 09 20:18:16 CET 2021
>  WARNING (global): Setting max-jobs to 8
>  Exception in thread "main" java.lang.AssertionError: found trailing
>  0 in chars
>   at
> 
> uk.me.parabola.imgfmt.app.labelenc.EncodedText.(EncodedText.java:39)
> 
>   at
> 
> uk.me.parabola.imgfmt.app.labelenc.AnyCharsetEncoder.encodeText(AnyCharsetEncoder.java:112)
> 
>   at
>  uk.me.parabola.imgfmt.app.lbl.LBLFile.newLabel(LBLFile.java:132)
>   at
> 
> uk.me.parabola.imgfmt.app.lbl.PlacesFile.createPOI(PlacesFile.java:253)
>   at
>  uk.me.parabola.imgfmt.app.lbl.LBLFile.createPOI(LBLFile.java:172)
>   at
> 
> uk.me.parabola.mkgmap.build.MapBuilder.processPOIs(MapBuilder.java:670)
>   at
>  uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:325)
>   at
>  uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114)
>   at
>  uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:62)
>   at
> 
> uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:291)
>   at
>  java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at
> 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> 
>   at
> 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 
> 
>  ___
>  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
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
__

Re: [mkgmap-dev] New assertion, now with code-page=632 and Japan tile

[Felix Hartmann]

Only as input for splitter it changes a lot. As input for mkgmap it's very
little difference.

On Wed, 10 Nov 2021, 17:38 Carlos Dávila 
wrote:

> I'm aware of the supposed advantages of pbf, but I did some tests in the
> past and I found o5m to be quite faster than pbf, but I'll test again.
>
> El 10/11/21 a las 9:43, Gerd Petermann escribió:
> > Hi Carlos,
> >
> > I'll try to debug this.
> >
> > BTW: I see you use *.o5m for the tiles (output from splitter). I think
> this is no longer a good choice, pbf is a lot smaller and almost as fast.
> Esp. when it comes to the goal of reducing disk I/O (as with
> --gmapi-minimal)
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag von
> Carlos Dávila 
> > Gesendet: Dienstag, 9. November 2021 22:54
> > An: mkgmap-dev@lists.mkgmap.org.uk
> > Betreff: Re: [mkgmap-dev] New assertion,now with code-page=632
> and Japan tile
> >
> > Hi Ticker
> >
> > Not sure if relevant, but note in this case assertion occurs while
> > compiling the tile, not the index. In fact, --index is not included in
> > the command.
> >
> > El 9/11/21 a las 21:55, Ticker Berkin escribió:
> >> Hi
> >>
> >> I think this assertion could be removed from the code.
> >>
> >> Looking through the definition of Shift-JIS, I read it as saying the
> >> second byte shouldn't be zero, so I don't know why this happens.
> >>
> >> As with the Chinese code-pages, mkgmap has places where multi-byte
> >> encodings are not handled correctly in the --index generation and
> >> unknown meanings of flags to the Garmin software.
> >>
> >> Ticker
> >>
> >>
> >>
> >> On 09/11/2021 19:43, Carlos Dávila wrote:
> >>> code-page=932, sorry for the typo.
> >>>
> >>> El 9/11/21 a las 20:36, Carlos Dávila escribió:
>  The command below produces an assertion while compiling this tile
>   from Japan.
>  Process continues with remaining tiles and finishes without "Number
>  of MapFailedExceptions: 1" as expected. This is with r4813, but I
>  also tried with an old version of mkgmap with the same result.
> 
>  java -Xmx27G -ea -jar mkgmap.jar--code-page=632 31191025.o5m
>  Mkgmap version 4813
>  Time started: Tue Nov 09 20:18:16 CET 2021
>  WARNING (global): Setting max-jobs to 8
>  Exception in thread "main" java.lang.AssertionError: found trailing
>  0 in chars
>   at
> 
> uk.me.parabola.imgfmt.app.labelenc.EncodedText.(EncodedText.java:39)
> 
>   at
> 
> uk.me.parabola.imgfmt.app.labelenc.AnyCharsetEncoder.encodeText(AnyCharsetEncoder.java:112)
> 
>   at
>  uk.me.parabola.imgfmt.app.lbl.LBLFile.newLabel(LBLFile.java:132)
>   at
> 
> uk.me.parabola.imgfmt.app.lbl.PlacesFile.createPOI(PlacesFile.java:253)
>   at
>  uk.me.parabola.imgfmt.app.lbl.LBLFile.createPOI(LBLFile.java:172)
>   at
> 
> uk.me.parabola.mkgmap.build.MapBuilder.processPOIs(MapBuilder.java:670)
>   at
>  uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:325)
>   at
>  uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114)
>   at
>  uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:62)
>   at
> 
> uk.me.parabola.mkgmap.main.Main.lambda$processFilename$1(Main.java:291)
>   at
>  java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at
> 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> 
>   at
> 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> 
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 
> 
>  ___
>  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
>
> ___
> 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
http

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

The current version is perfect. Avoids all those unnecessary writes and no
need to go crazy on symbolic links anymore for preventing them. Files that
should be overwritten - are overwritten.

On Sun, 19 Sept 2021 at 15:03, Felix Hartmann 
wrote:

> first of all I need all info.xml files - because I want different versions
> of a map possible. And yes second those files are tiny - just rename/Move
> them away before running mkgmap again. That is trivial on any system. (much
> easier than moving away all those folder and linking them back was was
> needed before this patch).
>
> On Sun, 19 Sept 2021 at 12:39, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi ael,
>>
>> >It seems to be profligate in its use of disk cycles.
>> Any further prove for this despite the gmapi directory?
>> While I do agree that the whole tool chain (download complete *.osm.pbf,
>> maybe convert to *.o5m, maybe mix with contour data, splitter, and finally
>> compile with mkgmap) is very I/O intensive I really don't see much room for
>> improvements in mgmap. The program keeps most of the data in memory before
>> writing the final result, only data for the global index files which are
>> likely to grow very large are written to tempory files.
>>
>> Gerd
>>
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> ael 
>> Gesendet: Mittwoch, 8. September 2021 13:31
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
>> to disk if used with --gmapi option
>>
>> On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote:
>> >
>> > Yes on an nvme disk you barely notice the conversion - it's really
>> quick.
>> > BUT it is not needed if you have the files and even more - it burns your
>> > NVME SSD disk.
>>
>> +1. I always use an old spinning rust disk when using mkgmap to save ssd
>> write cycles, even without contours and such. It seems to be profligate
>> in its use of disk cycles. I did try using RAM disk, but even with 16GB
>> on a laptop, that was soon exhausted.
>>
>> 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
>>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>

-- 
Felix Hartman - 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] The x prepended to the *.typ file

[Felix Hartmann]

I think - modify source file if .typ is in the output directory. Do not
modify but write a new typfile (same name) if not in output directory. For
me that makes most sense.
But anything is fine - also the current behaviour.

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

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

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

first of all I need all info.xml files - because I want different versions
of a map possible. And yes second those files are tiny - just rename/Move
them away before running mkgmap again. That is trivial on any system. (much
easier than moving away all those folder and linking them back was was
needed before this patch).

On Sun, 19 Sept 2021 at 12:39, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi ael,
>
> >It seems to be profligate in its use of disk cycles.
> Any further prove for this despite the gmapi directory?
> While I do agree that the whole tool chain (download complete *.osm.pbf,
> maybe convert to *.o5m, maybe mix with contour data, splitter, and finally
> compile with mkgmap) is very I/O intensive I really don't see much room for
> improvements in mgmap. The program keeps most of the data in memory before
> writing the final result, only data for the global index files which are
> likely to grow very large are written to tempory files.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> ael 
> Gesendet: Mittwoch, 8. September 2021 13:31
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote:
> >
> > Yes on an nvme disk you barely notice the conversion - it's really quick.
> > BUT it is not needed if you have the files and even more - it burns your
> > NVME SSD disk.
>
> +1. I always use an old spinning rust disk when using mkgmap to save ssd
> write cycles, even without contours and such. It seems to be profligate
> in its use of disk cycles. I did try using RAM disk, but even with 16GB
> on a laptop, that was soon exhausted.
>
> 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
>


-- 
Felix Hartman - 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] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

Hi Gerd,
maybe I've misread Thomas, but he said exclude not include list. No worries
an include list makes sense  - while an exclude list really doesn't (at
least I cannot think of a use for an exclude list). So definitely add an
include list if you like. Include as in including .img that should be
converted. All osm/o5m should be converted without being on the include
list anyhow.´(because they would not be on that list if the .img existed
already)

As for the linking - yes please - do not check if the gmapi files exist
(the .img have to exist anyway else we cannot build the mapset files). That
way I could throw away the gmapi contourlines on the render server - and
only keep them on the download server already zipped (for all files that
one decides to take out of the main download to make it smaller. E.g. for
Asia continent 20m contourlines are like 5x the size of the map or so - so
better the user on update can download the map files only without the
contourlines). Essentially it's like 350GB just lying around to be linked
but no other sense for me.
So you only need a copy of the .img files - not another copy of the gmapi
files for rendering the maps (and you do not need to create 0byte files to
link so they cannot be overwritten as an alternative).

On Thu, 16 Sept 2021 at 15:19, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> what do you mean with exclude list? I suggested a possible include-list to
> specify more files which are overwritten even if they already exist.
> Regarding linking: OK, you just want a new tdb file containing all listed
> input files? No check if the output file really exists?
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 16. September 2021 14:11
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> I would prefer if I don't even need to link anything, just the concept
> that only o5m and osm.pbf input is converted. I can keep the converted
> contour lines on the server too, but it would be nicer if I don't even need
> to have them for all maps where I have them as separate download.
>
> If that is working all is perfect. I don't see a usecase for an exclude
> list.
>
> On Thu, 16 Sep 2021, 11:11 Gerd Petermann  <mailto:gpetermann_muenc...@hotmail.com>> wrote:
> Hi all,
>
> OK, I think I can add code to detect the img files which were compiled in
> the same call of mkgmap. So, with option --gmapi-minimal
> - Files in this list always need to be written. It should be possible to
> evaluate a parameter list that specifies additional file patterns.
> - Files which don't yet exist in the gmapi folder are also written.
> - other files in the Product subfolder would not be touched
> - the Info.xml will contain all files listed as input
>
> So, either just --gmapi-minimal or --gmapi-minimal[= which should overwritten>]
>
> Would that work well for all?
>
> Gerd
>
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Montag, 13. September 2021 20:44
> An: Thomas Morgenstern; Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> .img files are always reused and never rewritten - it's only about the
> gmapi files (a gmapsupp.img has to be generated in one go anyhow - so it is
> not in question here). So I do not see the sense of making it more
> complicated? It would be fine with me too that way - but I think it's
> simpler to just assume all .img files already have the converted files -
> because you could do it when generating those .img files. The problem with
> your approach is - that when you have a long list of tiles that were
> crashing due to too little maxnodes - then regenerating it - will make it
> very complicated. It's much easier to assume that all .img files are
> already converted. All other input not. If you need to convert .img files
> too - then you just use the normal --gmapi option instead.
>
> On Mon, 13 Sept 2021 at 18:58, Thomas Morgenstern  <mailto:webmas...@img2ms.de><mailto:webmas...@img2ms.de webmas...@img2ms.de>>> wrote:
> I suggest the new option should be named reuse= files, wildcards enabled>. exampel  reuse=4001.img, 40005*.img. If this
> option is used, then mkgmap should not overwrite the listed folders in the
> gmap. Naturally mkgmap should write a new tdb, preview.img, mdr and
> idx. In most cases th

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

I would prefer if I don't even need to link anything, just the concept that
only o5m and osm.pbf input is converted. I can keep the converted contour
lines on the server too, but it would be nicer if I don't even need to have
them for all maps where I have them as separate download.

If that is working all is perfect. I don't see a usecase for an exclude
list.

On Thu, 16 Sep 2021, 11:11 Gerd Petermann 
wrote:

> Hi all,
>
> OK, I think I can add code to detect the img files which were compiled in
> the same call of mkgmap. So, with option --gmapi-minimal
> - Files in this list always need to be written. It should be possible to
> evaluate a parameter list that specifies additional file patterns.
> - Files which don't yet exist in the gmapi folder are also written.
> - other files in the Product subfolder would not be touched
> - the Info.xml will contain all files listed as input
>
> So, either just --gmapi-minimal or --gmapi-minimal[= which should overwritten>]
>
> Would that work well for all?
>
> Gerd
>
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 13. September 2021 20:44
> An: Thomas Morgenstern; Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> .img files are always reused and never rewritten - it's only about the
> gmapi files (a gmapsupp.img has to be generated in one go anyhow - so it is
> not in question here). So I do not see the sense of making it more
> complicated? It would be fine with me too that way - but I think it's
> simpler to just assume all .img files already have the converted files -
> because you could do it when generating those .img files. The problem with
> your approach is - that when you have a long list of tiles that were
> crashing due to too little maxnodes - then regenerating it - will make it
> very complicated. It's much easier to assume that all .img files are
> already converted. All other input not. If you need to convert .img files
> too - then you just use the normal --gmapi option instead.
>
> On Mon, 13 Sept 2021 at 18:58, Thomas Morgenstern  <mailto:webmas...@img2ms.de>> wrote:
> I suggest the new option should be named reuse= files, wildcards enabled>. exampel  reuse=4001.img, 40005*.img. If this
> option is used, then mkgmap should not overwrite the listed folders in the
> gmap. Naturally mkgmap should write a new tdb, preview.img, mdr and
> idx. In most cases the reuse folders contains Contourlines or other static
> content.
>
> Thomas
>
> Am 13.09.2021 um 15:38 schrieb Felix Hartmann:
> Hi Gerd, yes exactly. I have a large collection of .img files of
> contourlines. When I realized that I trash my NVME disk very fast if I
> continue the way I did I got into thinking and analysing what happens. It
> was clear that it all comes down to the --gmapi option. I had believed that
> if I run several passes with .o5m and .img files as input - only the .o5m
> input is converted into new .gmapi folders - while the existing ones are
> not overwritten. Then I checked the created date/last modified date
> (because windows has in my eyes a bug that if you replace a file with a
> near identical file - it just shows a new modified date - but keeps the
> original created date - even though it was a full overwrite).
>
> That got me thinking that in order to save writes - I have to find a way
> to not only not recalculate the .img files - but also create a static set
> of .gmapi folders. Those I just mklink into the directory name that will be
> used on the next run of mkgmap.jar - I managed to do this by uncommenting
> this one line. Because I noticed that the symlinked (by mklink) files are
> not rewritten I changed my scripts to move them away and symlink them back.
> Then at the end delete all symlinks - and move the files back (or to the
> location that I will use for compressing). This step is a bit stupid if
> mkgmap could just have a --gmapi-minimal mode in which only those files are
> converted - that are also written out as .img files (if given --tdb-file
> option).
>
> I know that many people keep a static set of contourlines .img files (also
> containing DEM). You just add the show-profiles=1 option in case you
> include contourlines - and leave it out if not. But actually it does not
> matter if the contourlines files contain DEM or not.
> I think the easiest way is the principle - --gmapi-minimal only converts
> those files, it would write out as .img files if --tdb-files option were
> given (or is given). --gmapi on the other hand should convert the all input
> files to .gmapi format. Then mgkmap does not even nee

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

[Felix Hartmann]

Well as the new Garmin devices have 15k tiles and still fat32 the problem
will disappear for them at least.

If you manage to get every tile on average to 10MB those with 4096 tiles
are fine too.

Those with 2048 tiles at least postponed a bit...this and same FID is like
the most annoying problem that users face, because both are very hard to
identify

On Tue, 14 Sep 2021, 16:28 Gerd Petermann 
wrote:

> Hi Felix,
>
> yes, the more exotic the OSM data gets the more likely it is that you can
> increase --max-nodes. Another reason might be the many optimizations during
> the last years which achieved smaller file sizes.
>
> Your approach probably works, but I doubt that you can solve the original
> problem that users install too many maps (tiles). You just postpone it a
> few years.
>
> Gerd
>
>
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Dienstag, 14. September 2021 12:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke
> "String.endsWith(String)" because the return value of
> "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
>
> Hi Gerd,
>
> The reason for this is - many garmin GPS devices have a max tile limit of
> 2048, 4096 or some newer devices 15k. Except those with 15k tiles limit -
> users may break the 2048 or 4096 tile limit on their device if the tiles
> are not very big. For some countries I can double the max-nodes and only
> get one tile that is too big. Then I just resplit that tile and compile the
> output again. However as those tiles are not static - and it doesn't happen
> all the time - I just prefer not to bother about that - and set a rather
> high --max-nodes value which will at some extracts lead to failed tiles.
>
> With 32GB sd Cards being virtually same price as 8GB or smaller - and
> users not reading instructions of not installing too many maps to slow down
> their device - they from time to time complain about missing maps on their
> device. It's very tedious to find out that the reason for this is the tile
> limit. because the maps all show up in the map setup list on the Garmin GPS
> device - just some will not display (I actually do not know which will not
> display - I think the newly added ones - it could be also the ones with the
> higher map-id or whatever). Therefore I try to maximise the --max-nodes
> value as good as possible. Only if my scripts can automatically resplit
> those failed tiles and run mkgamp.jar easily again without starting from
> scratch this approach makes sense. Else I have to fallback to much smaller
> max-nodes values.
>
> So actually the optimum is likely somewhere around 3% of tiles with
> resplit.  If done well this will only result in maybe 5% longer compile
> times on your server - but half the number of tiles created. You could even
> write a script to analyze the splits - and each time no tile fails you
> increase the max-nodes value by X and each time more than 3% of tiles fail
> you decrease it again.
>
> Well a bit theoretic with the no more compile time - because if you have
> less tiles than threads on your render server - it takes more time to
> compile because mgkmap.jar cannot run so many threads in parallel.
>
>
> In general I noticed that over time as OSM grows there is more and more
> data in OSM which will not end up in my maps - so over time to slowly have
> to increase max-nodes else your .img tiles get smaller and smaller. I had
> been using the same --max-nodes values for years (with lower values if a
> country failed) and noticed I could double, sometimes tripple them without
> any failed tiles.
>
> On Tue, 14 Sept 2021 at 12:09, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> I still don't understand the concept of resplitting. Is it meant to fix
> problems until you find time to look at the server or should it work in
> long terms? If you resplit more and more tiles I don't see how it will
> improve the map or the resource usage.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Dienstag, 14. September 2021 11:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke
> "String.endsWith(String)" because the return value of
> "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
>
> yeah that makes resplits easier. You do not nee

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

[Felix Hartmann]

Hi Gerd,

The reason for this is - many garmin GPS devices have a max tile limit of
2048, 4096 or some newer devices 15k. Except those with 15k tiles limit -
users may break the 2048 or 4096 tile limit on their device if the tiles
are not very big. For some countries I can double the max-nodes and only
get one tile that is too big. Then I just resplit that tile and compile the
output again. However as those tiles are not static - and it doesn't happen
all the time - I just prefer not to bother about that - and set a rather
high --max-nodes value which will at some extracts lead to failed tiles.

With 32GB sd Cards being virtually same price as 8GB or smaller - and users
not reading instructions of not installing too many maps to slow down their
device - they from time to time complain about missing maps on their
device. It's very tedious to find out that the reason for this is the tile
limit. because the maps all show up in the map setup list on the Garmin GPS
device - just some will not display (I actually do not know which will not
display - I think the newly added ones - it could be also the ones with the
higher map-id or whatever). Therefore I try to maximise the --max-nodes
value as good as possible. Only if my scripts can automatically resplit
those failed tiles and run mkgamp.jar easily again without starting from
scratch this approach makes sense. Else I have to fallback to much smaller
max-nodes values.

So actually the optimum is likely somewhere around 3% of tiles with
resplit.  If done well this will only result in maybe 5% longer compile
times on your server - but half the number of tiles created. You could even
write a script to analyze the splits - and each time no tile fails you
increase the max-nodes value by X and each time more than 3% of tiles fail
you decrease it again.

Well a bit theoretic with the no more compile time - because if you have
less tiles than threads on your render server - it takes more time to
compile because mgkmap.jar cannot run so many threads in parallel.


In general I noticed that over time as OSM grows there is more and more
data in OSM which will not end up in my maps - so over time to slowly have
to increase max-nodes else your .img tiles get smaller and smaller. I had
been using the same --max-nodes values for years (with lower values if a
country failed) and noticed I could double, sometimes tripple them without
any failed tiles.

On Tue, 14 Sept 2021 at 12:09, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> I still don't understand the concept of resplitting. Is it meant to fix
> problems until you find time to look at the server or should it work in
> long terms? If you resplit more and more tiles I don't see how it will
> improve the map or the resource usage.
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Dienstag, 14. September 2021 11:01
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke
> "String.endsWith(String)" because the return value of
> "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
>
> yeah that makes resplits easier. You do not need to go into the
> template.args file anymore and comment out missing tiles. So it's enough to
> just delete those input tiles that were too big.
>
> On Tue, 14 Sept 2021 at 11:46, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> I've added a null check with r4807.
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Donnerstag, 2. September 2021 01:45
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke
> "String.endsWith(String)" because the return value of
> "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
>
> Okay - this error can be solved by removing the "Input that do not exist
> from the template.args input file. - e.g. if 85610002.o5m does not exist
> need to remove the line
> input-file: 85610002.o5m
> from the template.args file.
>
> On Tue, 31 Aug 2021 at 21:11, Felix Hartmann  <mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com extremecar...@gmail.com>>> wrote:
> Partly related to the other problem - if I run mkgmap on the splitted
> files - I get this error. All .img files seem to be fine, but the
> gmpsupp.img is created with 0 bit size.
>
> This is not happening every time I resplit tiles. In this case two tiles
> were joined 

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

[Felix Hartmann]

yeah that makes resplits easier. You do not need to go into the
template.args file anymore and comment out missing tiles. So it's enough to
just delete those input tiles that were too big.

On Tue, 14 Sept 2021 at 11:46, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> I've added a null check with r4807.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Donnerstag, 2. September 2021 01:45
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke
> "String.endsWith(String)" because the return value of
> "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
>
> Okay - this error can be solved by removing the "Input that do not exist
> from the template.args input file. - e.g. if 85610002.o5m does not exist
> need to remove the line
> input-file: 85610002.o5m
> from the template.args file.
>
> On Tue, 31 Aug 2021 at 21:11, Felix Hartmann  <mailto:extremecar...@gmail.com>> wrote:
> Partly related to the other problem - if I run mkgmap on the splitted
> files - I get this error. All .img files seem to be fine, but the
> gmpsupp.img is created with 0 bit size.
>
> This is not happening every time I resplit tiles. In this case two tiles
> were joined by osmconvert - and splitter splits it into three tiles. Then
> all .img files are created correctly, but the mapset.tdb / mapset.img files
> are not created - and the gmapsupp.img has 0 size, the gmapi files is also
> not created.
>
> I guess this happens because splitter somehow made a melange of the two
> input files into three?
>
> I really think the only thing missing in resplitting the too big tiles
> from mkgmap is an appropriate keep-complete mode - that keeps each input
> tile complete - but does not join input tiles. So osmconvert merging the
> input tiles is a bad idea even though it mostly works.
>
> C:\openmtbmap\maps>start /belownormal /b /wait java -jar
> -XX:+AggressiveHeap -XX:StringTableSize=103 -Xms5000M -Xmx43000M
> C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
> --code-page=1251 "--style-file=C:\openmtbmap\buildings_style"
>  --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
> --ignore-turn-restrictions --merge-lines --allow-reverse-merge
> --transparent --draw-priority=28 --add-pois-to-areas
> --simplify-polygons=23:4,22:7,21:8
> --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
> --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
> --add-boundary-nodes-at-admin-boundaries=2
> --poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
> --polygon-size-limits="24:16, 23:14, 22:12, 21:11"
> --ignore-turn-restrictions --description=buildings_ru --country-abbr=ru
> --country-name=russia --mapname=8580 --family-id=8580 --product-id=1
> --series-name="buildings_russia_31.08.2021_NU_Local"
> --family-name="buildings_ru_31.08.2021_NU_Local" --tdbfile
>  --gmapi --gmapsupp --overview-mapname=mapsetb --keep-going
> --area-name="russia_31.08.2021_NU_Local_buildings" -c
> D:\openmtbmap\maps\template.russiab buildru.typ
> [0.005s][warning][gc,ergo] NewSize was set larger than initial heap size,
> will use initial heap size.
> Mkgmap version 4806M
> Time started: Tue Aug 31 21:00:52 CEST 2021
> SEVERE (Main): D:\openmtbmap\maps\85800012.o5m: input file
> 'D:\openmtbmap\maps\85800012.o5m' doesn't exist
> SEVERE (Main): D:\openmtbmap\maps\85800024.o5m: input file
> 'D:\openmtbmap\maps\85800024.o5m' doesn't exist
> Number of MapFailedExceptions: 0
> Exception in thread "main" java.lang.NullPointerException: Cannot invoke
> "String.endsWith(String)" because the return value of
> "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
> at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620)
> at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
> at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:146)
> at uk.me.parabola.mkgmap.main.Main.main(Main.java:117)
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] mkgmap doing excessive writing

[Felix Hartmann]

I just answered in the old topic - but it would make it very complicated if
you had some tiles that you need to split again. I feel --gmapi converts
everything - while --gmapi-minimal only converts input given in
.o5m/osm.pbf/osm is the much better approach. The first time you use
--gmapi - all subsequent times you use --gmapi-minimal. Otherwise it would
not only need to be fine with asterisk, but also like reuse=<4134.img
Sorry but I really don't see why any .img files should be converted again.
Do it the first time you generate them - or just use --gmapi. I do not see
the workflow where a reuse= whatever makes sense. While any o5m / osm /
osm.pbf input would be strange to already exist as gmapi format but not as
img format. Even more as mkgmap so far can use .img as input, but cannot
use gmapi folders as input. If gmapi was possible as input as well - then
your reuse list would make sense. But I do not have a use case for gmapi
input.
And if gmapi input was possible  then the correct approach would be to
write the input like this:
123400??.img gmapi/123400?? 1234002?.o5m
In that case as we passed the map in img and gmapi format up to 19 as input
- those shall not be written either as .img nor as gmapi.
However then
gmapi/123400?? 1234002?.05m would need to write out all .img files
(overwrite those already present) and write the o5m files in both gmapi and
img format. Mkgmap would then need to be able to convert into both
directions and people who only need gmapi files would not need the .img
files. So the call here should be - are there any people using mkgmap
consistently and only need gmapi but not .img output? But I think that
would be way too much work. Because so far mkgmap is simply converting to
gmapi - not writing gmapi in first place from input data without writing
.img files.

On Mon, 13 Sept 2021 at 19:46, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Thomas,
>
> yes, I also thought about something like that. I still have to learn some
> details of the gmapi format and the generated files and dependencies
> between them.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Thomas Morgenstern 
> Gesendet: Montag, 13. September 2021 18:01
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] mkgmap doing excessive writing
>
> I suggest the new option should be named reuse= files, wildcards enabled>. exampel  reuse=4001.img, 40005*.img. If this
> option is used, then mkgmap should not overwrite the listed folders in the
> gmap. Naturally mkgmap should write a new tdb, preview.img, mdr and
> idx. In most cases the reuse folders contains Contourlines or other static
> content.
>
> Thomas
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

.img files are always reused and never rewritten - it's only about the
gmapi files (a gmapsupp.img has to be generated in one go anyhow - so it is
not in question here). So I do not see the sense of making it more
complicated? It would be fine with me too that way - but I think it's
simpler to just assume all .img files already have the converted files -
because you could do it when generating those .img files. The problem with
your approach is - that when you have a long list of tiles that were
crashing due to too little maxnodes - then regenerating it - will make it
very complicated. It's much easier to assume that all .img files are
already converted. All other input not. If you need to convert .img files
too - then you just use the normal --gmapi option instead.

On Mon, 13 Sept 2021 at 18:58, Thomas Morgenstern 
wrote:

> I suggest the new option should be named *reuse= files, wildcards enabled>. *exampel  *reuse=4001.img, 40005*.img. *If
> this option is used, then mkgmap should not overwrite the listed folders
> in the gmap. Naturally mkgmap should write a new tdb, preview.img,
> mdr and idx. In most cases the *reuse folders *contains Contourlines or
> other static content.
>
> Thomas
>
> Am 13.09.2021 um 15:38 schrieb Felix Hartmann:
>
> Hi Gerd, yes exactly. I have a large collection of .img files of
> contourlines. When I realized that I trash my NVME disk very fast if I
> continue the way I did I got into thinking and analysing what happens. It
> was clear that it all comes down to the --gmapi option. I had believed that
> if I run several passes with .o5m and .img files as input - only the .o5m
> input is converted into new .gmapi folders - while the existing ones are
> not overwritten. Then I checked the created date/last modified date
> (because windows has in my eyes a bug that if you replace a file with a
> near identical file - it just shows a new modified date - but keeps the
> original created date - even though it was a full overwrite).
>
> That got me thinking that in order to save writes - I have to find a way
> to not only not recalculate the .img files - but also create a static set
> of .gmapi folders. Those I just mklink into the directory name that will be
> used on the next run of mkgmap.jar - I managed to do this by uncommenting
> this one line. Because I noticed that the symlinked (by mklink) files are
> not rewritten I changed my scripts to move them away and symlink them back.
> Then at the end delete all symlinks - and move the files back (or to the
> location that I will use for compressing). This step is a bit stupid if
> mkgmap could just have a --gmapi-minimal mode in which only those files are
> converted - that are also written out as .img files (if given --tdb-file
> option).
>
> I know that many people keep a static set of contourlines .img files (also
> containing DEM). You just add the show-profiles=1 option in case you
> include contourlines - and leave it out if not. But actually it does not
> matter if the contourlines files contain DEM or not.
> *I think the easiest way is the principle - --gmapi-minimal only converts
> those files, it would write out as .img files if --tdb-files option were
> given (or is given). --gmapi on the other hand should convert the all input
> files to .gmapi format.* Then mgkmap does not even need to test if those
> files are there or not. This not only saves a lot of writes - but also a
> lot of compile time.
>
> Because essentially if you only provide .img input files (including of
> course the ovm-img for the overview map if you want) you only create a new
> set of mapset files. The exception to this is the toolchain in which when a
> tile failed to compile - you resplit the input files - and parse them again
> with the same arguments so you have input of new o5m files and old .img
> files. But the principle stays the same. If on the rerun of the failed
> tiles now newy split with higher map-id you give --gmapi-minimal and
> tdb-file - only those new tiles are written - while the old .img and old
> ovm.img are supplied to create the correct mapset files. With this
> procedure you don't even need to put a symlink for the contourlines into
> the gmap folder. As the input data to create the contourlines rarely change
> - you can offer the contourlines as a separate download.
> Makes it much easier and faster.
>
> On the map compilation server you then do not even need to have a copy of
> the .gmapi contourlines files. You just need the new input data and the
> static contourlines .img files. Thomas Morgenstern for example had also not
> realized that he is writing the contourlines .gmapi files each time without
> any need. I think many/most providers of garmin maps who offer many
> regions/worldwide coverage put the 

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

 so on. Also, I want to find a solution that works for all
> users, not just you.
>
> So, I expect that you have one step that compiles frequently changing OSM
> data and other steps which are used to compile static data like
> contourlines or DEM. I don't know if you do the latter for each country /
> continent or once for planet and I don't care as long as it works for you.
> My understanding is that you have a large collection of *.img files at
> some stage and that you run mkgmap multiple times with different
> combinations of those *.img files as input to produce different zip-files
> with gmapi format or gmapsupp format.
> I think that's the normal way to do it, so I try to support that way.
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 13. September 2021 12:28
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> I move away the info.xml - and use a different name for the mapset files
> and then just have mkgmap any file that is input in osm.pbf / osm / o5m
> format. Gmapi-minimal should not convert any file that is supplied as .img
> - as it can be assumed that those exist already (if they do not - then
> create them with --gmapi). That is in my opinion the best approach. So
> mkgmap does not even try to convert them.
>
> Afterwards I distribute a gmapi folder that includes all the data - and by
> replacing the info.xml you can enable or disable contourlines. For big
> countries the contourlines would be a separate download anyhow - so the
> user only needs to download the maps (including mapset files) but not
> redownload the contourlines.  Same principle as in offering the
> contourlines as a separate gmapsupp.img file. so you have maps.img
> contourlines10m.img contourlines20m.img buildings.img 
>
>
> On Mon, 13 Sept 2021 at 13:17, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> sorry, the Data Deduplication as implemented in Windows Server would not
> help here. It works after data was written.
>
> And yes, files which are not just copies of the *.img are written as
> before. My understanding is that you have different product directories in
> the gmapi folder and that you write protect those files which should be
> kept.
> If you have a script to zip the gmapi directory you have to exclude the
> unwanted folders.
> Didn't try it. Does it make sense?
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Montag, 13. September 2021 12:09
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> Oh - but data was certainly written - A rename will not show as data
> written in both Task manager on Windows, as well as in the smart data (I'm
> using Windows 10 pro not Windows server however - maybe that functionality
> is limited to windows server?)
>
> On Mon, 13 Sept 2021 at 13:06, Felix Hartmann  <mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com extremecar...@gmail.com>>> wrote:
> Not sure if it makes it possible to use read only attribute instead of
> moving and mklink. Maybe yes - because that was not possible before. So it
> then would be set read only - instead of of move & mklink - and at the end
> remove read only instead of moving back.
>
> On Mon, 13 Sept 2021 at 12:59, Felix Hartmann  <mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com extremecar...@gmail.com>>> wrote:
> Thanks Gerd,
>
> but that is just removing the warning if it cannot overwrite, correct?
> If it can overwrite the gmap file it will still overwrite it as I see.. So
> in essence just a bit more intelligent then my disabling that line.
>
> I think it should not overwrite at all if present and --x-gmapi-minimal
> (then you don't have to move away the files and link them back to the
> original folder).
>
> On Mon, 13 Sept 2021 at 10:43, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi all,
>
> attached is a quick patch that implements experimaltal option
> --x-gmapi-minimal.
>
> If used instead of --gmapi mkgmap will not fail if a write-protected
> output file exists in the g

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

I move away the info.xml - and use a different name for the mapset files
and then just have mkgmap any file that is input in osm.pbf / osm / o5m
format. Gmapi-minimal should not convert any file that is supplied as .img
- as it can be assumed that those exist already (if they do not - then
create them with --gmapi). That is in my opinion the best approach. So
mkgmap does not even try to convert them.

Afterwards I distribute a gmapi folder that includes all the data - and by
replacing the info.xml you can enable or disable contourlines. For big
countries the contourlines would be a separate download anyhow - so the
user only needs to download the maps (including mapset files) but not
redownload the contourlines.  Same principle as in offering the
contourlines as a separate gmapsupp.img file. so you have maps.img
contourlines10m.img contourlines20m.img buildings.img 


On Mon, 13 Sept 2021 at 13:17, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> sorry, the Data Deduplication as implemented in Windows Server would not
> help here. It works after data was written.
>
> And yes, files which are not just copies of the *.img are written as
> before. My understanding is that you have different product directories in
> the gmapi folder and that you write protect those files which should be
> kept.
> If you have a script to zip the gmapi directory you have to exclude the
> unwanted folders.
> Didn't try it. Does it make sense?
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Montag, 13. September 2021 12:09
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> Oh - but data was certainly written - A rename will not show as data
> written in both Task manager on Windows, as well as in the smart data (I'm
> using Windows 10 pro not Windows server however - maybe that functionality
> is limited to windows server?)
>
> On Mon, 13 Sept 2021 at 13:06, Felix Hartmann  <mailto:extremecar...@gmail.com>> wrote:
> Not sure if it makes it possible to use read only attribute instead of
> moving and mklink. Maybe yes - because that was not possible before. So it
> then would be set read only - instead of of move & mklink - and at the end
> remove read only instead of moving back.
>
> On Mon, 13 Sept 2021 at 12:59, Felix Hartmann  <mailto:extremecar...@gmail.com>> wrote:
> Thanks Gerd,
>
> but that is just removing the warning if it cannot overwrite, correct?
> If it can overwrite the gmap file it will still overwrite it as I see.. So
> in essence just a bit more intelligent then my disabling that line.
>
> I think it should not overwrite at all if present and --x-gmapi-minimal
> (then you don't have to move away the files and link them back to the
> original folder).
>
> On Mon, 13 Sept 2021 at 10:43, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi all,
>
> attached is a quick patch that implements experimaltal option
> --x-gmapi-minimal.
>
> If used instead of --gmapi mkgmap will not fail if a write-protected
> output file exists in the gmapi output folder and mkgmap copies data from
> *.img. It should still crash when other files like Info.xml are written.
>
> BTW: no conversion is done when those files are written. I think mkgmap
> simply copies data from sub files in *.img into single files. So, the same
> sequence of Bytes exists two or more times on the Computer. Windows Server
> seems to support automatic data deduplication (1). I am sure Linux offers
> similar support. No idea how effective or reliable it is, but it might be
> worth trying.
>
> Gerd
> (1)
>
> https://docs.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Carlos Dávila <
> car...@alternativaslibres.org<mailto:car...@alternativaslibres.org>>
> Gesendet: Sonntag, 12. September 2021 22:45
> An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> I think it's a good idea if mkgmap checks the required files are present.
>
> El 12/9/21 a las 21:16, Gerd Petermann escribió:
> > Hi Felix,
> >
> > so you just want a new option so that mkgmap doesn't fail if it cannot
> overwrite (write-protected) files in the output directory, right? No need
> to verify the content of the exiting file(s)

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

Oh - but data was certainly written - A rename will not show as data
written in both Task manager on Windows, as well as in the smart data (I'm
using Windows 10 pro not Windows server however - maybe that functionality
is limited to windows server?)

On Mon, 13 Sept 2021 at 13:06, Felix Hartmann 
wrote:

> Not sure if it makes it possible to use read only attribute instead of
> moving and mklink. Maybe yes - because that was not possible before. So it
> then would be set read only - instead of of move & mklink - and at the end
> remove read only instead of moving back.
>
> On Mon, 13 Sept 2021 at 12:59, Felix Hartmann 
> wrote:
>
>> Thanks Gerd,
>>
>> but that is just removing the warning if it cannot overwrite, correct?
>> If it can overwrite the gmap file it will still overwrite it as I see..
>> So in essence just a bit more intelligent then my disabling that line.
>>
>> I think it should not overwrite at all if present and --x-gmapi-minimal
>> (then you don't have to move away the files and link them back to the
>> original folder).
>>
>> On Mon, 13 Sept 2021 at 10:43, Gerd Petermann <
>> gpetermann_muenc...@hotmail.com> wrote:
>>
>>> Hi all,
>>>
>>> attached is a quick patch that implements experimaltal option
>>> --x-gmapi-minimal.
>>>
>>> If used instead of --gmapi mkgmap will not fail if a write-protected
>>> output file exists in the gmapi output folder and mkgmap copies data from
>>> *.img. It should still crash when other files like Info.xml are written.
>>>
>>> BTW: no conversion is done when those files are written. I think mkgmap
>>> simply copies data from sub files in *.img into single files. So, the same
>>> sequence of Bytes exists two or more times on the Computer. Windows Server
>>> seems to support automatic data deduplication (1). I am sure Linux offers
>>> similar support. No idea how effective or reliable it is, but it might be
>>> worth trying.
>>>
>>> Gerd
>>> (1)
>>>
>>> https://docs.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable
>>>
>>> 
>>> Von: mkgmap-dev  im Auftrag von
>>> Carlos Dávila 
>>> Gesendet: Sonntag, 12. September 2021 22:45
>>> An: mkgmap-dev@lists.mkgmap.org.uk
>>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
>>> to disk if used with --gmapi option
>>>
>>> I think it's a good idea if mkgmap checks the required files are present.
>>>
>>> El 12/9/21 a las 21:16, Gerd Petermann escribió:
>>> > Hi Felix,
>>> >
>>> > so you just want a new option so that mkgmap doesn't fail if it cannot
>>> overwrite (write-protected) files in the output directory, right? No need
>>> to verify the content of the exiting file(s)?
>>> >
>>> > Gerd
>>> >
>>> > 
>>> > Von: mkgmap-dev  im Auftrag
>>> von Felix Hartmann 
>>> > Gesendet: Sonntag, 12. September 2021 19:10
>>> > An: Development list for mkgmap
>>> > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and
>>> converting to disk if used with --gmapi option
>>> >
>>> > And well - it is burning SSD for the contourlines currently even if
>>> not calling multiple times. 130GB minimum per worldwide map update for all
>>> geofabrik extracts at 20m equidistance. 260GB at 10m. With calling multiple
>>> times and 10m and 20m I had about 2TB of useless writes per weekly map
>>> update. I've got rid of all of them with my uncommenting the line, plus
>>> saved about 500GB of writes by now doing all the gmapsupp.img and gmap
>>> stuff in Ramdisk So now instead of 4TB of disk writes per map update I'm
>>> down to 1TB.. (and yeah the resplitting of tiles added another 5TB of
>>> writes - but that could have been fixed easily by changing order of
>>> commands too).
>>> >
>>> > On Sun, 12 Sept 2021 at 20:04, Felix Hartmann >> <mailto:extremecar...@gmail.com>> wrote:
>>> > because you need to do it if you want to show contourlines. Now
>>> compiling the worldwide contourlines each time again - would burn SSD as
>>> well - besides taking longer than just compiling the maps. So everyone who
>>> offers maps for many countries as download puts the contourlines separate.
>>> If you want to offer the choice of showing contourlines

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

Not sure if it makes it possible to use read only attribute instead of
moving and mklink. Maybe yes - because that was not possible before. So it
then would be set read only - instead of of move & mklink - and at the end
remove read only instead of moving back.

On Mon, 13 Sept 2021 at 12:59, Felix Hartmann 
wrote:

> Thanks Gerd,
>
> but that is just removing the warning if it cannot overwrite, correct?
> If it can overwrite the gmap file it will still overwrite it as I see.. So
> in essence just a bit more intelligent then my disabling that line.
>
> I think it should not overwrite at all if present and --x-gmapi-minimal
> (then you don't have to move away the files and link them back to the
> original folder).
>
> On Mon, 13 Sept 2021 at 10:43, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi all,
>>
>> attached is a quick patch that implements experimaltal option
>> --x-gmapi-minimal.
>>
>> If used instead of --gmapi mkgmap will not fail if a write-protected
>> output file exists in the gmapi output folder and mkgmap copies data from
>> *.img. It should still crash when other files like Info.xml are written.
>>
>> BTW: no conversion is done when those files are written. I think mkgmap
>> simply copies data from sub files in *.img into single files. So, the same
>> sequence of Bytes exists two or more times on the Computer. Windows Server
>> seems to support automatic data deduplication (1). I am sure Linux offers
>> similar support. No idea how effective or reliable it is, but it might be
>> worth trying.
>>
>> Gerd
>> (1)
>>
>> https://docs.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> Carlos Dávila 
>> Gesendet: Sonntag, 12. September 2021 22:45
>> An: mkgmap-dev@lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
>> to disk if used with --gmapi option
>>
>> I think it's a good idea if mkgmap checks the required files are present.
>>
>> El 12/9/21 a las 21:16, Gerd Petermann escribió:
>> > Hi Felix,
>> >
>> > so you just want a new option so that mkgmap doesn't fail if it cannot
>> overwrite (write-protected) files in the output directory, right? No need
>> to verify the content of the exiting file(s)?
>> >
>> > Gerd
>> >
>> > 
>> > Von: mkgmap-dev  im Auftrag
>> von Felix Hartmann 
>> > Gesendet: Sonntag, 12. September 2021 19:10
>> > An: Development list for mkgmap
>> > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
>> to disk if used with --gmapi option
>> >
>> > And well - it is burning SSD for the contourlines currently even if not
>> calling multiple times. 130GB minimum per worldwide map update for all
>> geofabrik extracts at 20m equidistance. 260GB at 10m. With calling multiple
>> times and 10m and 20m I had about 2TB of useless writes per weekly map
>> update. I've got rid of all of them with my uncommenting the line, plus
>> saved about 500GB of writes by now doing all the gmapsupp.img and gmap
>> stuff in Ramdisk So now instead of 4TB of disk writes per map update I'm
>> down to 1TB.. (and yeah the resplitting of tiles added another 5TB of
>> writes - but that could have been fixed easily by changing order of
>> commands too).
>> >
>> > On Sun, 12 Sept 2021 at 20:04, Felix Hartmann > <mailto:extremecar...@gmail.com>> wrote:
>> > because you need to do it if you want to show contourlines. Now
>> compiling the worldwide contourlines each time again - would burn SSD as
>> well - besides taking longer than just compiling the maps. So everyone who
>> offers maps for many countries as download puts the contourlines separate.
>> If you want to offer the choice of showing contourlines or not - mkmgap
>> will write the gmap contourlines once not needed, and once the maps not
>> needed. If you don't want to offer that option - it's only the contourlines
>> being written without need. Contourlines for all geofabrik extracts 20m
>> equidistance are about 130GB, 10m would be 260GB.
>> > If you offer 10m and 20m it will be even more not needed writes.
>> >
>> > The only solution is to go for a Ramdisk instead - However you likely
>> will need 128GB of RAM to do that - because for Asia or Europe you need a
>> 64GB Ramdisk. Same for North America extract (but few people of

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

Thanks Gerd,

but that is just removing the warning if it cannot overwrite, correct?
If it can overwrite the gmap file it will still overwrite it as I see.. So
in essence just a bit more intelligent then my disabling that line.

I think it should not overwrite at all if present and --x-gmapi-minimal
(then you don't have to move away the files and link them back to the
original folder).

On Mon, 13 Sept 2021 at 10:43, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi all,
>
> attached is a quick patch that implements experimaltal option
> --x-gmapi-minimal.
>
> If used instead of --gmapi mkgmap will not fail if a write-protected
> output file exists in the gmapi output folder and mkgmap copies data from
> *.img. It should still crash when other files like Info.xml are written.
>
> BTW: no conversion is done when those files are written. I think mkgmap
> simply copies data from sub files in *.img into single files. So, the same
> sequence of Bytes exists two or more times on the Computer. Windows Server
> seems to support automatic data deduplication (1). I am sure Linux offers
> similar support. No idea how effective or reliable it is, but it might be
> worth trying.
>
> Gerd
> (1)
>
> https://docs.microsoft.com/en-us/windows-server/storage/data-deduplication/install-enable
>
> 
> Von: mkgmap-dev  im Auftrag von
> Carlos Dávila 
> Gesendet: Sonntag, 12. September 2021 22:45
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> I think it's a good idea if mkgmap checks the required files are present.
>
> El 12/9/21 a las 21:16, Gerd Petermann escribió:
> > Hi Felix,
> >
> > so you just want a new option so that mkgmap doesn't fail if it cannot
> overwrite (write-protected) files in the output directory, right? No need
> to verify the content of the exiting file(s)?
> >
> > Gerd
> >
> > 
> > Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> > Gesendet: Sonntag, 12. September 2021 19:10
> > An: Development list for mkgmap
> > Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
> to disk if used with --gmapi option
> >
> > And well - it is burning SSD for the contourlines currently even if not
> calling multiple times. 130GB minimum per worldwide map update for all
> geofabrik extracts at 20m equidistance. 260GB at 10m. With calling multiple
> times and 10m and 20m I had about 2TB of useless writes per weekly map
> update. I've got rid of all of them with my uncommenting the line, plus
> saved about 500GB of writes by now doing all the gmapsupp.img and gmap
> stuff in Ramdisk So now instead of 4TB of disk writes per map update I'm
> down to 1TB.. (and yeah the resplitting of tiles added another 5TB of
> writes - but that could have been fixed easily by changing order of
> commands too).
> >
> > On Sun, 12 Sept 2021 at 20:04, Felix Hartmann  <mailto:extremecar...@gmail.com>> wrote:
> > because you need to do it if you want to show contourlines. Now
> compiling the worldwide contourlines each time again - would burn SSD as
> well - besides taking longer than just compiling the maps. So everyone who
> offers maps for many countries as download puts the contourlines separate.
> If you want to offer the choice of showing contourlines or not - mkmgap
> will write the gmap contourlines once not needed, and once the maps not
> needed. If you don't want to offer that option - it's only the contourlines
> being written without need. Contourlines for all geofabrik extracts 20m
> equidistance are about 130GB, 10m would be 260GB.
> > If you offer 10m and 20m it will be even more not needed writes.
> >
> > The only solution is to go for a Ramdisk instead - However you likely
> will need 128GB of RAM to do that - because for Asia or Europe you need a
> 64GB Ramdisk. Same for North America extract (but few people offer that and
> just have Canada and the US divided into the 4-5 zones). For other maps you
> will get by with a 15-20GB Ramdisk (which I have resorted to now for all
> but the windows installers because I don't want to let the server wait for
> ages for the single thread NSIS wrapping up the data and instead start the
> next country in parallel). And yes going RAMDISK already using my patch and
> symlinking those files so mkgmap cannot overwrite them (would still be
> faster if mkgmap didn't try in first place I think). If you want to write
> out the contourlines as well besides the additional time - for Asia
> continent you may then go for a 90

Re: [mkgmap-dev] How to create an empty overview map (for transparent maps)

[Felix Hartmann]

I think just remove the warning. I could not notice any problem due to it (
and if there would be problems, by now at least one user of my maps should
have complained)

On Mon, 13 Sept 2021 at 12:09, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi,
>
> yes, I think that message makes no sense in this situation. I am not sure
> why I decided to log this as an error.
> See https://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap&rev=3679
>
> I've attached a patch to suppress the message if the input file is a
> ovm_*.img.
> I could also simply reduce severity to warning or remove it for good.
>
> Gerd
>
>
>
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Mittwoch, 1. September 2021 12:18
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] How to create an empty overview map (for
> transparent  maps)
>
> If you create a separate map for buildings or contourlines only - usually
> there is no need for an overview map - or better no need for any content in
> the overview map - or am I missing something?
>
> Because those maps sometimes may have very large tiles, but very few
> levels (maybe only 24) - mkgmap creates an overview map at the next
> resolution - and will then often throw warnings such as:
>
> SEVERE (OverviewBuilder): Tile selection (0x4a) polygon for tile 8490
> cannot be written in level 0 resolution 21, using 20 instead
>
>
> There is still a need for an empty overview map - as without it you cannot
> show the map in Basecamp/Mapsource - or transfer it with MapInstall.
> I know the overview map is only empty 0x4a polygons - just wondered if
> there is a better solution...
>
> --overview-levels=
> is not given.
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



-- 
Felix Hartman - 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] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

And well - it is burning SSD for the contourlines currently even if not
calling multiple times. 130GB minimum per worldwide map update for all
geofabrik extracts at 20m equidistance. 260GB at 10m. With calling multiple
times and 10m and 20m I had about 2TB of useless writes per weekly map
update. I've got rid of all of them with my uncommenting the line, plus
saved about 500GB of writes by now doing all the gmapsupp.img and gmap
stuff in Ramdisk So now instead of 4TB of disk writes per map update I'm
down to 1TB.. (and yeah the resplitting of tiles added another 5TB of
writes - but that could have been fixed easily by changing order of
commands too).

On Sun, 12 Sept 2021 at 20:04, Felix Hartmann 
wrote:

> because you need to do it if you want to show contourlines. Now compiling
> the worldwide contourlines each time again - would burn SSD as well -
> besides taking longer than just compiling the maps. So everyone who offers
> maps for many countries as download puts the contourlines separate. If you
> want to offer the choice of showing contourlines or not - mkmgap will write
> the gmap contourlines once not needed, and once the maps not needed. If you
> don't want to offer that option - it's only the contourlines being written
> without need. Contourlines for all geofabrik extracts 20m equidistance are
> about 130GB, 10m would be 260GB.
> If you offer 10m and 20m it will be even more not needed writes.
>
> The only solution is to go for a Ramdisk instead - However you likely will
> need 128GB of RAM to do that - because for Asia or Europe you need a 64GB
> Ramdisk. Same for North America extract (but few people offer that and just
> have Canada and the US divided into the 4-5 zones). For other maps you will
> get by with a 15-20GB Ramdisk (which I have resorted to now for all but the
> windows installers because I don't want to let the server wait for ages for
> the single thread NSIS wrapping up the data and instead start the next
> country in parallel). And yes going RAMDISK already using my patch and
> symlinking those files so mkgmap cannot overwrite them (would still be
> faster if mkgmap didn't try in first place I think). If you want to write
> out the contourlines as well besides the additional time - for Asia
> continent you may then go for a 90GB Ramdisk minimum if offering windows
> and gmap installers. In this case gmapsupp.img donwnloads aren't possible
> anyhow due to the huge data amounts. For smaller countries I have them
> too
>
> I coded around this now by using symlinks - but yeah that will be quite a
> lot of work and is prone to break - while I guess it's only 10 lines or so
> to add to mkgmap code to have a mode that does not write them out if they
> are present - or if you tell on commandline they are present already. For
> .img files they aren't overwritten either...
>
> On Sun, 12 Sept 2021 at 18:40, Gerd Petermann <
> gpetermann_muenc...@hotmail.com> wrote:
>
>> Hi Felix,
>>
>> did not read all the posts in detail. I understand that mkgmap is neither
>> burning SSDs nor doing any excessive writing unless you call it multiple
>> times for the same input files. So the question is: Why do you do that?
>>
>> Gerd
>>
>> 
>> Von: mkgmap-dev  im Auftrag von
>> Felix Hartmann 
>> Gesendet: Freitag, 10. September 2021 00:02
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting
>> to disk if used with --gmapi option
>>
>> Well I think the .tmp files are just building up - and the renamed. So
>> they are not causing any actual excessive write.
>> As for the gmap - it would be cool if there is a mode to not write them.
>>
>> Actually it would be great if mkgmap could write all in one go. Because
>> the thing that takes so much time - is the address search - and that is
>> always the same. The differences are tiny (just because MapInstall is
>> crashing when files are missing) you need to compile them separately.
>>
>> but maybe there could be a mode where mkgamp writes all in one go.
>> So family-name / family-name1 / family-name2
>> description / description1 / description2
>> input input1 input2
>> family-name..
>> show-profiles
>> overview-mapname
>> product-id
>> (and maybe I missed some options are those that would need to be given
>> for each set of input tiles. And then just an option where you tell mkgmap
>> files starting with which first 4 numbers are relevant for address search.
>> No need to analyze if those other supplied .img (e.g. buildings or
>> contourlines) need to be added to address search

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

because you need to do it if you want to show contourlines. Now compiling
the worldwide contourlines each time again - would burn SSD as well -
besides taking longer than just compiling the maps. So everyone who offers
maps for many countries as download puts the contourlines separate. If you
want to offer the choice of showing contourlines or not - mkmgap will write
the gmap contourlines once not needed, and once the maps not needed. If you
don't want to offer that option - it's only the contourlines being written
without need. Contourlines for all geofabrik extracts 20m equidistance are
about 130GB, 10m would be 260GB.
If you offer 10m and 20m it will be even more not needed writes.

The only solution is to go for a Ramdisk instead - However you likely will
need 128GB of RAM to do that - because for Asia or Europe you need a 64GB
Ramdisk. Same for North America extract (but few people offer that and just
have Canada and the US divided into the 4-5 zones). For other maps you will
get by with a 15-20GB Ramdisk (which I have resorted to now for all but the
windows installers because I don't want to let the server wait for ages for
the single thread NSIS wrapping up the data and instead start the next
country in parallel). And yes going RAMDISK already using my patch and
symlinking those files so mkgmap cannot overwrite them (would still be
faster if mkgmap didn't try in first place I think). If you want to write
out the contourlines as well besides the additional time - for Asia
continent you may then go for a 90GB Ramdisk minimum if offering windows
and gmap installers. In this case gmapsupp.img donwnloads aren't possible
anyhow due to the huge data amounts. For smaller countries I have them
too

I coded around this now by using symlinks - but yeah that will be quite a
lot of work and is prone to break - while I guess it's only 10 lines or so
to add to mkgmap code to have a mode that does not write them out if they
are present - or if you tell on commandline they are present already. For
.img files they aren't overwritten either...

On Sun, 12 Sept 2021 at 18:40, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> did not read all the posts in detail. I understand that mkgmap is neither
> burning SSDs nor doing any excessive writing unless you call it multiple
> times for the same input files. So the question is: Why do you do that?
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Freitag, 10. September 2021 00:02
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] mkgmap doing excessive writing and converting to
> disk if used with --gmapi option
>
> Well I think the .tmp files are just building up - and the renamed. So
> they are not causing any actual excessive write.
> As for the gmap - it would be cool if there is a mode to not write them.
>
> Actually it would be great if mkgmap could write all in one go. Because
> the thing that takes so much time - is the address search - and that is
> always the same. The differences are tiny (just because MapInstall is
> crashing when files are missing) you need to compile them separately.
>
> but maybe there could be a mode where mkgamp writes all in one go.
> So family-name / family-name1 / family-name2
> description / description1 / description2
> input input1 input2
> family-name..
> show-profiles
> overview-mapname
> product-id
> (and maybe I missed some options are those that would need to be given for
> each set of input tiles. And then just an option where you tell mkgmap
> files starting with which first 4 numbers are relevant for address search.
> No need to analyze if those other supplied .img (e.g. buildings or
> contourlines) need to be added to address search.). I know coded around the
> problem of the gmap files causing excessive writes. But yeah that is
> actually really complicated be it on windows or linux...
>
> On Wed, 8 Sept 2021 at 17:07, Felix Hartmann  <mailto:extremecar...@gmail.com>> wrote:
> Well I could give it 20 GB ram disk, maybe 32 but then I need to render on
> less than 12 processes 64GB ram available). But that is not enough for Asia
> continent map, and I guess super tight for Europe...
>
> Mkgmap could definitely keep those .tmp files in memory. But the important
> bit is the gmap files not needeed to be written Also would save quite
> some CPU time.
>
> On Wed, 8 Sep 2021, 14:31 ael  witwa...@disroot.org>> wrote:
> On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote:
> >
> > Yes on an nvme disk you barely notice the conversion - it's really quick.
> > BUT it is not needed if you have the files and even more - it burns your
> > NVME SSD disk.
>
> +1. I always

Re: [mkgmap-dev] custom style

[Felix Hartmann]

Check with gpsmapedit

On Sun, 12 Sep 2021, 08:56 7770 <7...@foskan.eu> wrote:

> Hi.
>
> As a test i once once added a specific condition for fuels so that the
> points
> style file contains these two rows:
> (amenity=fuel & fuel:e85=yes) [0x4401 resolution 22]
> amenity=fuel [0x2f01 resolution 22]
>
> If i add an image in the TYP file 0x4401 will show just fine in gmapshack
> and on
> a unit (GPSMAP 66st).
>
> in the finalize and include section of the style i have the following to
> add
> information about avaialble fues at fuel stations:
>
> (amenity=fuel &
> (fuel:octane_95=yes|fuel:diesel=yes|fuel:e85=yes|fuel:cng=yes|
> fuel:biogas=yes|fuel:adblue=yes) )
>   {set mkgmap:phone='${mkgmap:phone} Fuel: ' | 'Fuel: '}
> (amenity=fuel & fuel:octane_95=yes) {set mkgmap:phone='${mkgmap:phone}
> B95'}
> (amenity=fuel & fuel:diesel=yes) {set mkgmap:phone='${mkgmap:phone} DI'}
> (amenity=fuel & fuel:e85=yes) {set mkgmap:phone='${mkgmap:phone} E85'}
> (amenity=fuel & (fuel:cng=yes | fuel:biogas=yes)) {set mkgmap:phone='$
> {mkgmap:phone} CNG/BNG'}
> (amenity=fuel & fuel:lpg=yes) {set mkgmap:phone='${mkgmap:phone} LPG'}
> (amenity=fuel & fuel:adblue=yes) {set mkgmap:phone='${mkgmap:phone}
> ADBLUE'}
>
>
> What i observe now on the GPS unit is that the fuel stations tagged 0x4401
> will not have the fuel details added, but 0x2f01 will. (qmapshack doesn't
> seem
> to show any details about points).
>
> To me it looks like both points will and should match at least some of the
> conditions from the include section.
> Is it because 0x4401 is a too high number of types and mkgmap does not
> allow
> the phone information to be set?
> Do i need to write the include section differently?
> Is it simply the garmin device which does not show as much information for
> 0x4401 as for 0x2f01?
>
> 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] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

Well I think the .tmp files are just building up - and the renamed. So they
are not causing any actual excessive write.
As for the gmap - it would be cool if there is a mode to not write them.

Actually it would be great if mkgmap could write all in one go. Because the
thing that takes so much time - is the address search - and that is always
the same. The differences are tiny (just because MapInstall is crashing
when files are missing) you need to compile them separately.

but maybe there could be a mode where mkgamp writes all in one go.
So family-name / family-name1 / family-name2
description / description1 / description2
input input1 input2
family-name..
show-profiles
overview-mapname
product-id
(and maybe I missed some options are those that would need to be given for
each set of input tiles. And then just an option where you tell mkgmap
files starting with which first 4 numbers are relevant for address search.
No need to analyze if those other supplied .img (e.g. buildings or
contourlines) need to be added to address search.). I know coded around the
problem of the gmap files causing excessive writes. But yeah that is
actually really complicated be it on windows or linux...

On Wed, 8 Sept 2021 at 17:07, Felix Hartmann 
wrote:

> Well I could give it 20 GB ram disk, maybe 32 but then I need to render on
> less than 12 processes 64GB ram available). But that is not enough for Asia
> continent map, and I guess super tight for Europe...
>
> Mkgmap could definitely keep those .tmp files in memory. But the important
> bit is the gmap files not needeed to be written Also would save quite
> some CPU time.
>
> On Wed, 8 Sep 2021, 14:31 ael  wrote:
>
>> On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote:
>> >
>> > Yes on an nvme disk you barely notice the conversion - it's really
>> quick.
>> > BUT it is not needed if you have the files and even more - it burns your
>> > NVME SSD disk.
>>
>> +1. I always use an old spinning rust disk when using mkgmap to save ssd
>> write cycles, even without contours and such. It seems to be profligate
>> in its use of disk cycles. I did try using RAM disk, but even with 16GB
>> on a laptop, that was soon exhausted.
>>
>> ael
>>
>>
>> ___
>> mkgmap-dev mailing list
>> mkgmap-dev@lists.mkgmap.org.uk
>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>

-- 
Felix Hartman - 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] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

oh sorry - made a typo at the first number. (there was no error in the
SMART data I just somehow wrote 3 instead of 6. Those 30TB of writes did
not suddenly disappear).

On Wed, 8 Sept 2021 at 22:36, Felix Hartmann 
wrote:

> so continued..
> 33659 GB
> After Step 1:
> new 33663 GB
> now set all files in Product1 folder to read only. Only applies to files
> not to the actual folder...
> attrib +r C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1\6* /s /d
> attrib -r C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1 /d
>
> Step2:
> Time started: Wed Sep 08 20:54:20 CEST 2021
> Number of MapFailedExceptions: 0
> SEVERE (global): Cannot write file java.nio.file.AccessDeniedException:
> .\mtb_alp_08.09.2021.gmap\Product1\6528\6528.RGN
> Number of ExitExceptions: 1
> Time finished: Wed Sep 08 20:54:22 CEST 2021
> Total time taken: 1 second
>
>
> so this is not working bad idea
> lets try moving the files to a temp directory on the same drive (so it's
> actually just a rename) and then run mkgmap again:
> Starting with 33663GB
> do Step 1 and move the files - and symlink them back...
>
> -- for /D %%f in
> (C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1\6*) do move %%f
> C:\openmtbmap\maps\temp >NUL
> SET SrcRoot=C:\openmtbmap\maps\temp\
> SET TargetRoot=C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1\
>
> FOR /D %%A IN ("%SrcRoot%\*") DO (
> MKLINK /D "%TargetRoot%\%%~NA" "%%~A" ) 1>NUL 2>NUL
> FOR %%A IN ("%SrcRoot%\*") DO (
> MKLINK "%TargetRoot%\%%~NXA" "%%~A" ) 1>NUL 2>NUL
>
> After Step 1
> 33668 GB
>
> After step 2
> 33669 GB
>
> After step 3
> 33669 GB
>
> After step 4:
> 33671 GB
>
> So now we're down to 8GB for actual 7GB of maps created. Bingo we have
> found a solution but it's really a lot of scripting to go there. I don't
> know why setting files to read only does not work - but creating symlinks
> does work with the tiny patch to mkgmap. I do think it would be in
> everyones interest to implement a better strategy for mkgmap... And with
> the loads of memory mkmap is taking up (25GB for me) - writing those .tmp
> files concerning the address search into memory instead of to disk would
> gain back the last ~1GB.
>
>
> The alternative being of course to write everything to RAMDISK - if you
> have loads of RAM - say 128GB this will even work for Europe or Asia
> continent map (and I guess in this scenario ECC RAM really makes sense?) -
> if you have 64GB you could try for all but Asia and Europe. Actually it
> will work for Asia using my above hacks of symlinking the contourlines.
> Because Asia alone is like 10GB contourlines on 20m. So if they are out of
> the way - the rest will do on the RAMDISK. Again would be much easier if
> those symlinks are not needed because mkgmap behaves SSD friendly and does
> not write those files in first place. I have come down from 14GB to 8GB of
> writes for the Alps. Maybe only 7.5GB (sound more plausible).
>
>
> On Wed, 8 Sept 2021 at 21:44, Felix Hartmann 
> wrote:
>
>> Uncommenting line 102  from /combiners/gmapibuilder.java and then messing
>> by making folder read only works (even though this is really like using
>> crutches while being healthy)! And yeah it's great mkgmap code is so
>> cleanly written that even someone at a loss with java can write a
>> workaround. I really just believe no-one ever really noticed or minded
>> enough to write here. There was a lot of optimization in making mkgmap
>> faster or use less memory - but no developper so far cared for hdd/ssd
>> writes. Actually I am pretty sure not writing those temp files or
>> attempting to write the gmap files if they exist will be an easy speed up
>> for mkgmap. Thanks Gerd and everyone else of the developper for writing
>> such great software"
>>
>> as in the following example.
>>
>>>   } catch (IOException e) {
>>> // throw new ExitException("Error saving gmapi data", e);
>>> }
>>
>>
>>
>> So let's detail the writes on Alps step by step - I guess the best
>> solution is to use a Ram Disk if mkgmap cannot be optimized - and then only
>> write Asia and Europe Continent maps to NVME disk because I cannot create a
>> big enough Ram Disk for them
>>
>> So the log is only in full GB - so here it what happens:
>> start at: 63648GB written to C:
>> *1.* 7*.img are the 20m contourlines. They and the 9*.img contourlines
>> are already present in gmap format and in the relavant gmap folder
>> mkgmap.jar is patched as abov

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

so continued..
33659 GB
After Step 1:
new 33663 GB
now set all files in Product1 folder to read only. Only applies to files
not to the actual folder...
attrib +r C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1\6* /s /d
attrib -r C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1 /d

Step2:
Time started: Wed Sep 08 20:54:20 CEST 2021
Number of MapFailedExceptions: 0
SEVERE (global): Cannot write file java.nio.file.AccessDeniedException:
.\mtb_alp_08.09.2021.gmap\Product1\6528\6528.RGN
Number of ExitExceptions: 1
Time finished: Wed Sep 08 20:54:22 CEST 2021
Total time taken: 1 second


so this is not working bad idea
lets try moving the files to a temp directory on the same drive (so it's
actually just a rename) and then run mkgmap again:
Starting with 33663GB
do Step 1 and move the files - and symlink them back...

-- for /D %%f in
(C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1\6*) do move %%f
C:\openmtbmap\maps\temp >NUL
SET SrcRoot=C:\openmtbmap\maps\temp\
SET TargetRoot=C:\openmtbmap\maps\mtb_%abr%_%date1%%IDT%.gmap\Product1\

FOR /D %%A IN ("%SrcRoot%\*") DO (
MKLINK /D "%TargetRoot%\%%~NA" "%%~A" ) 1>NUL 2>NUL
FOR %%A IN ("%SrcRoot%\*") DO (
MKLINK "%TargetRoot%\%%~NXA" "%%~A" ) 1>NUL 2>NUL

After Step 1
33668 GB

After step 2
33669 GB

After step 3
33669 GB

After step 4:
33671 GB

So now we're down to 8GB for actual 7GB of maps created. Bingo we have
found a solution but it's really a lot of scripting to go there. I don't
know why setting files to read only does not work - but creating symlinks
does work with the tiny patch to mkgmap. I do think it would be in
everyones interest to implement a better strategy for mkgmap... And with
the loads of memory mkmap is taking up (25GB for me) - writing those .tmp
files concerning the address search into memory instead of to disk would
gain back the last ~1GB.


The alternative being of course to write everything to RAMDISK - if you
have loads of RAM - say 128GB this will even work for Europe or Asia
continent map (and I guess in this scenario ECC RAM really makes sense?) -
if you have 64GB you could try for all but Asia and Europe. Actually it
will work for Asia using my above hacks of symlinking the contourlines.
Because Asia alone is like 10GB contourlines on 20m. So if they are out of
the way - the rest will do on the RAMDISK. Again would be much easier if
those symlinks are not needed because mkgmap behaves SSD friendly and does
not write those files in first place. I have come down from 14GB to 8GB of
writes for the Alps. Maybe only 7.5GB (sound more plausible).


On Wed, 8 Sept 2021 at 21:44, Felix Hartmann 
wrote:

> Uncommenting line 102  from /combiners/gmapibuilder.java and then messing
> by making folder read only works (even though this is really like using
> crutches while being healthy)! And yeah it's great mkgmap code is so
> cleanly written that even someone at a loss with java can write a
> workaround. I really just believe no-one ever really noticed or minded
> enough to write here. There was a lot of optimization in making mkgmap
> faster or use less memory - but no developper so far cared for hdd/ssd
> writes. Actually I am pretty sure not writing those temp files or
> attempting to write the gmap files if they exist will be an easy speed up
> for mkgmap. Thanks Gerd and everyone else of the developper for writing
> such great software"
>
> as in the following example.
>
>>   } catch (IOException e) {
>> // throw new ExitException("Error saving gmapi data", e);
>> }
>
>
>
> So let's detail the writes on Alps step by step - I guess the best
> solution is to use a Ram Disk if mkgmap cannot be optimized - and then only
> write Asia and Europe Continent maps to NVME disk because I cannot create a
> big enough Ram Disk for them
>
> So the log is only in full GB - so here it what happens:
> start at: 63648GB written to C:
> *1.* 7*.img are the 20m contourlines. They and the 9*.img contourlines
> are already present in gmap format and in the relavant gmap folder
> mkgmap.jar is patched as above in order to not stop when it cannot write
> the 7* and 9* folders as they are read only. I'm thinking of making the 6*
> folder read only for the further steps?
> start /belownormal /b /wait java -jar -XX:+AggressiveHeap
> -XX:StringTableSize=103 -Xmx43000m C:\openmtbmap\mkgmap.jar
> --max-jobs=12 --order-by-decreasing-area  "--generate-sea" --code-page=1252
> "--precomp-sea=E:\OpenMTBMap\osmpbf_geofabrik\sea.zip"
> "--style-file=C:\openmtbmap\openmtbmap_style"
> --add-boundary-nodes-at-admin-boundaries --fix-roundabout-direction
> --improve-overview --drive-on=detect --allow-reverse-merge
> --line-types-with-directi

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

ex --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18"
--overview-levels="7:17, 8:16, 9:15, 10:14, 11:13" --add-pois-to-areas
--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
--road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt
--split-name-index --housenumbers --description=omtb_alp --show-profiles=0
--location-autofill=bounds,is_in,nearest
--bounds=E:\OpenMTBMap\osmpbf_geofabrik\bounds.zip --route
--poi-excl-index=0x6405,0x4316,0x2f00 --cycle-map
--copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
--license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
--country-abbr=alp --country-name=alps --mapname=6528 --family-id=6528
--product-id=1 --series-name=omtb_alps_08.09.2021
--family-name=mtb_alp_08.09.2021 --tdbfile --gmapi
--overview-mapname=mapsetx --keep-going --area-name="alps_08.09.2021_omtb"
6528*.img typalp.TYP  1>NUL 2>NUL

Time taken - 30 seconds or so
Written 460MB (twice 230MB for each mapset_mdr file)
However new counter:
63655GB
Waste - minimum 2GB. maybe 3GB..

3.
C:\openmtbmap\maps>start /belownormal /b /wait java -jar
-XX:+AggressiveHeap -XX:StringTableSize=103 -Xmx43000m
C:\openmtbmap\mkgmap.jar --max-jobs=12 "--generate-sea" --code-page=1252
"--precomp-sea=E:\OpenMTBMap\osmpbf_geofabrik\sea.zip"
"--style-file=C:\openmtbmap\openmtbmap_style"
--add-boundary-nodes-at-admin-boundaries --fix-roundabout-direction
--improve-overview --drive-on=detect --allow-reverse-merge
--line-types-with-direction=0x18,0x1f,0x10016,0x10101,0x10105,0x10401,0x10403,0x10405,0x10408,0x10409,0x1040b,0x1040d,0x1040e,0x10500,0x10501,0x10502,0x10503,0x10504,0x10505,0x10506,0x10507,0x10607,0x10609,0x1060b,0x10702,0x10703,0x10704,0x10705,0x10706,0x10707,0x10a00,0x10a02,0x10a04,0x10a05,0x10e1e,0x10e0f,0x10e0e,0x10e1e,0x10f0a,0x10f1c,0x10e1d
 --nsis --index --levels="0:24, 1:23, 2:22, 3:21, 4:20, 5:19, 6:18"
--overview-levels="7:17, 8:16, 9:15, 10:14, 11:13" --add-pois-to-areas
--pois-to-areas-placement=entrance=main;entrance=yes;building=entrance;barrier=entrance
--road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt
--split-name-index --housenumbers --description=omtb_alp --show-profiles=1
--location-autofill=bounds,is_in,nearest
--bounds=E:\OpenMTBMap\osmpbf_geofabrik\bounds.zip --route
--poi-excl-index=0x6405,0x4316,0x2f00 --cycle-map
--copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
--license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
--country-abbr=alp --country-name=alps --mapname=6528 --family-id=6528
--product-id=1 --series-name=omtb_alps_08.09.2021
--family-name=mtb_alp_08.09.2021 --tdbfile --gmapi
--overview-mapname=mapset10 --keep-going --area-name="alps_08.09.2021_omtb"
6528*.img typalp.TYP E:\OpenMTBMap\contourlines10\alps\9*.img  1>NUL 2>NUL

Time taken 1 minute or so
Written 460M (same as above)
However new counter:
33657 GB
(I guess the waste is the same as above - it cannot write the 9*.img - so
each time around 2GB of wasted Write commands)

4.
Let's create the gmapsupp.img - there is no more wasted writes here
start /belownormal /b /wait java -jar -XX:+AggressiveHeap
-XX:StringTableSize=103 -Xmx43000m C:\openmtbmap\mkgmap.jar
--max-jobs=12 --hide-gmapsupp-on-pc
--copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
--road-name-config=C:\openmtbmap\openmtbmap_svn\roadNameConfig.txt
--license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
--code-page=1252 --family-id=6528  --housenumbers
--description="mtb_alp_08.09.2021" --series-name=mtbmap_alps_08.09.2021
--family-name=mtb_alp_08.09.2021 --product-id=1 --gmapsupp 6528*.img
C:\openmtbmap\maps\widealp.TYP  1>NUL 2>NUL
New counter:
33659 GB

Overall summing it up:
2.57GB of .img mapdata supposed to write. 1.87GB for the gmapsupp.img ,
2.53GB for the gmap folder containing everything written (i moved the
mapset files and the info.xml into subdirectories).
So 7GB of actual mapdata needed 11GB of writes. And I already saved 2GB of
writes by making the contourline gmapi folder read only... Before this I
had an additional 2GB of writes.


--

So let's try something new - we move the gmap 6* folder after the first
compile and put a hardlink (mklink) back so mkgmap cannot fuss around with
them anymore. Yeah we're using croutches so to say. I will post again the
results if I can improve by moving stuff and putting symlinks or by setting
read only attribute.


On Wed, 8 Sept 2021 at 14:10, Felix Hartmann 
wrote:

> Quite a few people do not compile the contourlines each time they update a
> map, but reuse the old contourlines. This works fine if you insert them as
> say 1234*img (and they are named 1234.img 12340001.img and so on).
>
> However this does not work whe

Re: [mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

Well I could give it 20 GB ram disk, maybe 32 but then I need to render on
less than 12 processes 64GB ram available). But that is not enough for Asia
continent map, and I guess super tight for Europe...

Mkgmap could definitely keep those .tmp files in memory. But the important
bit is the gmap files not needeed to be written Also would save quite
some CPU time.

On Wed, 8 Sep 2021, 14:31 ael  wrote:

> On Wed, Sep 08, 2021 at 02:10:52PM +0300, Felix Hartmann wrote:
> >
> > Yes on an nvme disk you barely notice the conversion - it's really quick.
> > BUT it is not needed if you have the files and even more - it burns your
> > NVME SSD disk.
>
> +1. I always use an old spinning rust disk when using mkgmap to save ssd
> write cycles, even without contours and such. It seems to be profligate
> in its use of disk cycles. I did try using RAM disk, but even with 16GB
> on a laptop, that was soon exhausted.
>
> 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

[mkgmap-dev] mkgmap doing excessive writing and converting to disk if used with --gmapi option

[Felix Hartmann]

Quite a few people do not compile the contourlines each time they update a
map, but reuse the old contourlines. This works fine if you insert them as
say 1234*img (and they are named 1234.img 12340001.img and so on).

However this does not work when providing the --gmapi option. Actually
mkgmap tries to rewrite all those files again/convert them.


Could it please be possible for mkgmap to change this?
There could be the status quo with --gmapi
and there could be a new mode called
--gmapiminimal that only converts files input as .o5m or .osm.pbf or .osm
but not as .img

--gpapiminimal would then work the same way as it does with .img files.
This has two use cases.

a) if you have to resplit a tile because some tiles were breaking - and
directly gave the --gmapiminimal option - no need to redo the whole .gmap
file.

b) you symlink all gmap folders with the contourlines (or other layers you
do not recreate on each update) into the gmap folder and mkgmap only writes
out the new stuff.


Yes on an nvme disk you barely notice the conversion - it's really quick.
BUT it is not needed if you have the files and even more - it burns your
NVME SSD disk.

To my horror I noticed that one worldwide update of maps wrote 5TB of data
to my disk (thanks to NVME SSD and fast processor this all took 28 hours).
At that rate even datacenter NVME ssd disks are quickly turned into trash.,
consumer grade NVME disk will not make it half a year for me... In general
maybe mkgmap could have an option to write temporary files to another disk?
Then you use a RAMDisk for those files. Or mkgmap should keep them in
memory. Modern servers often have 64 or 128GB of RAM so enough RAM for
mkgmap not to waste writes to disk...
Yes mkgmap uses quite a lot of RAM, but RAM is much cheaper than
continous SSD writes


Write now mkgmap crashes if you symlink already converted files to it:
e.g. message:
Number of MapFailedExceptions: 0
SEVERE (global): Error saving gmapi data
java.nio.file.FileAlreadyExistsException:
.\mtb_alp_08.09.2021.gmap\Product1\7528

While if it would be allowed to write out the data it would overwrite
existing files (which is fine or should do so - but same way as for .img
files)



For my worldwide maps 10m contourlines are 200GB, 20m contourlines are
100GB in size. Rendering the map in two styles and each time needing to
convert them even though I already have them converted creates 600GB of
useless writes per update (as well as useless time spend converting those
300GB at least twice) - and that is only if I use the --gmapi option as a
separate step. If I give bot --tdb-file and --gmapi it gets worse if a tile
failed to write - and I just parse it again.

And that is only for the contourlines. As I need three sets of mapset files
- once without contourlines, once with 10m contourlines, and once with 20m
contourlines the actual map gmapi folders are written three times instead
of once... Well over 1TB of useless conversion time and useless data
written to disk (but I do not know another way to create the needed
mapset_mdr.img, mapset.img and mapset.tdb files)

I don't know how to change that myself, but I hope this is not much work to
change.


-- 
Felix Hartman - 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 when running splitter with several input files, could there be keep-complete=single mode?

[Felix Hartmann]

In general I now got it fully working - the problem is if those merged
tiles are split - and not split in "pairs" but say from two tiles that
failed - which are not adjacent - 3 tiles are created (or 5) there
sometimes will be a tile spanning another tile. This works as far as I can
see in Basecamp/MapInstall/Mapsource - but gives strange impression when
selecting the tiles in MapInstall/Mapsource.
Have not yet tested it on device.

So if there is no possibility for splitter to implement a multiple single
input tile mode - I will have to resort to writing a big for loop calling
splitter separately for each crashed tile on mkgmap.jar processing. It
often can be prevented by using exactly 50% maxnodes size on resplit - but
that is not reliable of course. Basically for each tile that is 0 byte, you
need to split the original o5m, remove the mention to the input-file from
the template.args file, after each run check for a new highest mapid (or if
splitting with 50% maxnodes just add 3), always delete all 0byte files -
and after all tiles are split run mkgmap.jar again (either on the existing
.img files plus the new templates.args file (from joining all the
templates.args now newly created - also required quite a bit of logic).
It's scriptable - but really requires a lot of work. Would be great if
splitter.jar has a multiple tile input method (even more if it could
multithread that one as usual). If not the multithreading of course can be
achieved by piping each of these broken tiles into a separate process for
splitting.

On Tue, 31 Aug 2021 at 12:23, Felix Hartmann 
wrote:

> That step is very easy.
>
> You feed %FID% (if you use fid for first 4 numbers of mapid) and the new
> template.args to mkgmap.jar. No need to recreate the .img files that are
> okay. The broken ones - all 0byte ones - just delete them. If you wanna run
> mkgmap again on the same o5m input files - you join the template.args file
> from both runs - I always replace mapname with #notused so the
> template.args only contains description and the actual input file. It
> throws a warning that input files are missing - but that is allright. Of
> course you need to add in your script to delete those input files that were
> resplit.
>
> I don't know what your "app" does - but the process is pretty simple. As
> long as splitter can handle the several input files with --keep-complete
> (and just runs keep-complete on each input file but not on the totality of
> input files, plus does not try to join data from two files). And yes as
> said - if you want to run splitter on each input file separately, that
> creates loads of work - I don't know how to script that efficiently. Oh
> yeah - and your script needs to read the highest number of the maps created
> - add 1, and run mkgmap again with that number.  But yeah - scripting this
> takes some time. But it is understandable that mkgmap cannot call
> splitter.jar on it's ownThe main thing in this is getting to run
> splitter on several input files with keep-complete valid for each tile on
> it's own.
> But yeah I think osmconvert 100.o5m 11.o5m 100010.o5m
> -o=inputfile.o5m
> and then calling mkgmap with the higher mapid, and *already_created.img
> inputfile.o5m would suffice. So far I cannot see problems (as long as using
> keep-complete=true)  - you can even do a third pass. You cannot do a third
> pass if you use keep-complete=false overlap=2000
> because the overlap would create a huge mess (or better objects ending up
> twice in your map)
>
> On Tue, 31 Aug 2021 at 11:33, Eric Internet  wrote:
>
>> Also do not understand and on vacation now, so my options for
>> understanding are very limited.
>>
>> But fwiw...
>>
>> Mkgmap should read files collection from contents files. One o5m file
>> missing or 1 file extra (having different FID) is a show stopper. (Missing
>> files is not tested, assumption only).
>>
>> I create 2-6 different maps each overnight from same dataset by simply:
>> - Rename all o5m files by FID
>> - Rename Reference in two content files by filename (changed by FID).
>> This procedure takes seconds to run.
>>
>> All scripts (power management, splitter, OsmConvert, mkgmap, NSI) are
>> executed by shell.run from within a "wrapper application".
>> VB exe is: flexible, configurable, unlimited procedures and language
>> elements.
>>
>> App UI checkboxes will select which datasets to download.
>> App UI checkboxes will select which maps to be created.
>> UI settings are saved in iNI file for Unattended execution.
>> App will decide which datasets need to be merged by OsmConvert.
>> App will check preconditions.
>> App will run preprocess procedures (f.i. Rename by FID).

Re: [mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

[Felix Hartmann]

Okay - this error can be solved by removing the "Input that do not exist
from the template.args input file. - e.g. if 85610002.o5m does not exist
need to remove the line
input-file: 85610002.o5m
from the template.args file.

On Tue, 31 Aug 2021 at 21:11, Felix Hartmann 
wrote:

> Partly related to the other problem - if I run mkgmap on the splitted
> files - I get this error. All .img files seem to be fine, but the
> gmpsupp.img is created with 0 bit size.
>
> This is not happening every time I resplit tiles. In this case two tiles
> were joined by osmconvert - and splitter splits it into three tiles. Then
> all .img files are created correctly, but the mapset.tdb / mapset.img files
> are not created - and the gmapsupp.img has 0 size, the gmapi files is also
> not created.
>
> I guess this happens because splitter somehow made a melange of the two
> input files into three?
>
> I really think the only thing missing in resplitting the too big tiles
> from mkgmap is an appropriate keep-complete mode - that keeps each input
> tile complete - but does not join input tiles. So osmconvert merging the
> input tiles is a bad idea even though it mostly works.
>
> C:\openmtbmap\maps>start /belownormal /b /wait java -jar
> -XX:+AggressiveHeap -XX:StringTableSize=103 -Xms5000M -Xmx43000M
> C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
> --code-page=1251 "--style-file=C:\openmtbmap\buildings_style"
>  --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
> --ignore-turn-restrictions --merge-lines --allow-reverse-merge
> --transparent --draw-priority=28 --add-pois-to-areas
> --simplify-polygons=23:4,22:7,21:8
> --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
> --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
> --add-boundary-nodes-at-admin-boundaries=2
> --poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
> --polygon-size-limits="24:16, 23:14, 22:12, 21:11"
> --ignore-turn-restrictions --description=buildings_ru --country-abbr=ru
> --country-name=russia --mapname=8580 --family-id=8580 --product-id=1
> --series-name="buildings_russia_31.08.2021_NU_Local"
> --family-name="buildings_ru_31.08.2021_NU_Local" --tdbfile --gmapi
> --gmapsupp --overview-mapname=mapsetb --keep-going
> --area-name="russia_31.08.2021_NU_Local_buildings" -c
> D:\openmtbmap\maps\template.russiab buildru.typ
> [0.005s][warning][gc,ergo] NewSize was set larger than initial heap size,
> will use initial heap size.
> Mkgmap version 4806M
> Time started: Tue Aug 31 21:00:52 CEST 2021
> SEVERE (Main): D:\openmtbmap\maps\85800012.o5m: input file
> 'D:\openmtbmap\maps\85800012.o5m' doesn't exist
> SEVERE (Main): D:\openmtbmap\maps\85800024.o5m: input file
> 'D:\openmtbmap\maps\85800024.o5m' doesn't exist
> Number of MapFailedExceptions: 0
> Exception in thread "main" java.lang.NullPointerException: Cannot invoke
> "String.endsWith(String)" because the return value of
> "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
> at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620)
> at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
> at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:146)
> at uk.me.parabola.mkgmap.main.Main.main(Main.java:117)
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>

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

[mkgmap-dev] How to create an empty overview map (for transparent maps)

[Felix Hartmann]

If you create a separate map for buildings or contourlines only - usually
there is no need for an overview map - or better no need for any content in
the overview map - or am I missing something?

Because those maps sometimes may have very large tiles, but very few levels
(maybe only 24) - mkgmap creates an overview map at the next resolution -
and will then often throw warnings such as:

SEVERE (OverviewBuilder): Tile selection (0x4a) polygon for tile 8490
cannot be written in level 0 resolution 21, using 20 instead


There is still a need for an empty overview map - as without it you cannot
show the map in Basecamp/Mapsource - or transfer it with MapInstall.
I know the overview map is only empty 0x4a polygons - just wondered if
there is a better solution...

--overview-levels=
is not given.

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

[mkgmap-dev] Creating gmapsupp.img fails with: Cannot invoke "String.endsWith(String)" because the return value of "uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null

[Felix Hartmann]

Partly related to the other problem - if I run mkgmap on the splitted files
- I get this error. All .img files seem to be fine, but the gmpsupp.img is
created with 0 bit size.

This is not happening every time I resplit tiles. In this case two tiles
were joined by osmconvert - and splitter splits it into three tiles. Then
all .img files are created correctly, but the mapset.tdb / mapset.img files
are not created - and the gmapsupp.img has 0 size, the gmapi files is also
not created.

I guess this happens because splitter somehow made a melange of the two
input files into three?

I really think the only thing missing in resplitting the too big tiles from
mkgmap is an appropriate keep-complete mode - that keeps each input tile
complete - but does not join input tiles. So osmconvert merging the input
tiles is a bad idea even though it mostly works.

C:\openmtbmap\maps>start /belownormal /b /wait java -jar
-XX:+AggressiveHeap -XX:StringTableSize=103 -Xms5000M -Xmx43000M
C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
--code-page=1251 "--style-file=C:\openmtbmap\buildings_style"
 --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
--ignore-turn-restrictions --merge-lines --allow-reverse-merge
--transparent --draw-priority=28 --add-pois-to-areas
--simplify-polygons=23:4,22:7,21:8
--copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
--license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
--add-boundary-nodes-at-admin-boundaries=2
--poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
--polygon-size-limits="24:16, 23:14, 22:12, 21:11"
--ignore-turn-restrictions --description=buildings_ru --country-abbr=ru
--country-name=russia --mapname=8580 --family-id=8580 --product-id=1
--series-name="buildings_russia_31.08.2021_NU_Local"
--family-name="buildings_ru_31.08.2021_NU_Local" --tdbfile --gmapi
--gmapsupp --overview-mapname=mapsetb --keep-going
--area-name="russia_31.08.2021_NU_Local_buildings" -c
D:\openmtbmap\maps\template.russiab buildru.typ
[0.005s][warning][gc,ergo] NewSize was set larger than initial heap size,
will use initial heap size.
Mkgmap version 4806M
Time started: Tue Aug 31 21:00:52 CEST 2021
SEVERE (Main): D:\openmtbmap\maps\85800012.o5m: input file
'D:\openmtbmap\maps\85800012.o5m' doesn't exist
SEVERE (Main): D:\openmtbmap\maps\85800024.o5m: input file
'D:\openmtbmap\maps\85800024.o5m' doesn't exist
Number of MapFailedExceptions: 0
Exception in thread "main" java.lang.NullPointerException: Cannot invoke
"String.endsWith(String)" because the return value of
"uk.me.parabola.mkgmap.main.Main$FilenameTask.getFilename()" is null
at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:620)
at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126)
at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:146)
at uk.me.parabola.mkgmap.main.Main.main(Main.java:117)

-- 
Felix Hartman - 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 when running splitter with several input files, could there be keep-complete=single mode?

[Felix Hartmann]

That step is very easy.

You feed %FID% (if you use fid for first 4 numbers of mapid) and the new
template.args to mkgmap.jar. No need to recreate the .img files that are
okay. The broken ones - all 0byte ones - just delete them. If you wanna run
mkgmap again on the same o5m input files - you join the template.args file
from both runs - I always replace mapname with #notused so the
template.args only contains description and the actual input file. It
throws a warning that input files are missing - but that is allright. Of
course you need to add in your script to delete those input files that were
resplit.

I don't know what your "app" does - but the process is pretty simple. As
long as splitter can handle the several input files with --keep-complete
(and just runs keep-complete on each input file but not on the totality of
input files, plus does not try to join data from two files). And yes as
said - if you want to run splitter on each input file separately, that
creates loads of work - I don't know how to script that efficiently. Oh
yeah - and your script needs to read the highest number of the maps created
- add 1, and run mkgmap again with that number.  But yeah - scripting this
takes some time. But it is understandable that mkgmap cannot call
splitter.jar on it's ownThe main thing in this is getting to run
splitter on several input files with keep-complete valid for each tile on
it's own.
But yeah I think osmconvert 100.o5m 11.o5m 100010.o5m
-o=inputfile.o5m
and then calling mkgmap with the higher mapid, and *already_created.img
inputfile.o5m would suffice. So far I cannot see problems (as long as using
keep-complete=true)  - you can even do a third pass. You cannot do a third
pass if you use keep-complete=false overlap=2000
because the overlap would create a huge mess (or better objects ending up
twice in your map)

On Tue, 31 Aug 2021 at 11:33, Eric Internet  wrote:

> Also do not understand and on vacation now, so my options for
> understanding are very limited.
>
> But fwiw...
>
> Mkgmap should read files collection from contents files. One o5m file
> missing or 1 file extra (having different FID) is a show stopper. (Missing
> files is not tested, assumption only).
>
> I create 2-6 different maps each overnight from same dataset by simply:
> - Rename all o5m files by FID
> - Rename Reference in two content files by filename (changed by FID).
> This procedure takes seconds to run.
>
> All scripts (power management, splitter, OsmConvert, mkgmap, NSI) are
> executed by shell.run from within a "wrapper application".
> VB exe is: flexible, configurable, unlimited procedures and language
> elements.
>
> App UI checkboxes will select which datasets to download.
> App UI checkboxes will select which maps to be created.
> UI settings are saved in iNI file for Unattended execution.
> App will decide which datasets need to be merged by OsmConvert.
> App will check preconditions.
> App will run preprocess procedures (f.i. Rename by FID).
> App will wait for recent "latest" dataset.
> App will retry a failed download for n-times.
> App will decide what to do if a dataset is missing or outdated.
> App will verify each step to be successful (or not).
> App will install correctly created maps (read log files) into BaseCamp.
> Installer exe files and log files will be renamed by date (history,
> back-up and review options).
> App will run by Windows Scheduled Tasks.
>
> Recreating a specific map (because of style change) is as simple as
> clicking checkboxes.
>
> Time investment for mkgmap and Mapillary: one weekend development.
> Payback period in 2021 is already passed. Not by lead time (although
> Rename is faster than Merge) but most impressive by needed attention time.
> Don't shut down PC and tomorrow my new maps have been created somewhere
> between 06:00 and 09:00 AM or they failed.
>
> A one time problem is resolved by a new procedure for next occurrence.
> One time problems don't exist 😝
>
> AnkEric (Eric)
>
> On Tue, Aug 31, 2021, 10:15 Felix Hartmann 
> wrote:
>
>> yes - exactly what Ticker wrote is my intention. It seems fine using o5m
>> and merging with osmconvert however for right now If it's only a single
>> tile no problems, but if its 2-X files - then you can only use
>> keep-complete=false - or instead of using osm.pbf output in splitter o5m,
>> and then merge the failed o5m tiles into a new input2.o5m and process that
>> one again with splitter and lower max-nodes value. Instead if several input
>> files are given and keep-complete=true (or default which is true) - then
>> use keep-complete for each input file only.
>>
>> I do run into another problem there on the huge tiles, will have to check
>

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

[Felix Hartmann]

yes - exactly what Ticker wrote is my intention. It seems fine using o5m
and merging with osmconvert however for right now If it's only a single
tile no problems, but if its 2-X files - then you can only use
keep-complete=false - or instead of using osm.pbf output in splitter o5m,
and then merge the failed o5m tiles into a new input2.o5m and process that
one again with splitter and lower max-nodes value. Instead if several input
files are given and keep-complete=true (or default which is true) - then
use keep-complete for each input file only.

I do run into another problem there on the huge tiles, will have to check
on that later. Seems to be general about maps with very large tiles and not
related to splitter.

On Tue, 31 Aug 2021 at 09:52, Ticker Berkin  wrote:

> Hi
>
> My understanding of Felix's problem and a possible enhancement to solve
> it:
>
> Splitting a country... into a number of .osm.pfb files. Almost all of
> these are processable by mkgmap to produce tiles, but one or two exceed
> some .img limits.
>
> Rather that resplitting the whole country with a lower --max-nodes and
> trying again:
>
> Run the splitter again using the --split-file=area.list from the
> previous run (maybe with the good tiles deleted) and a new option that
> forces generation of 2 .osm.pbf files for each area. Probably just
> split in half, with some appropriate mapname augmentation. mkgmap
> should now be able to produce pairs of tiles to fill in the holes where
> the first run failed.
>
> Ticker
>
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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 when running splitter with several input files, could there be keep-complete=single mode?

[Felix Hartmann]

Sorry - the last error was a bug in my script. I actually chose the mapid
for splitter too low and while mkgmap did overwrite the .img file without
warning, it did not overwrite the gmapi files without warning (due to a bug
in finding out the highest number of tiles created). So with o5m input this
all works fine. Seems I have to beef up my server by another NVME disk to
accommodate for the larger o5m vs osm.pbf files.
I need to store all splitter created files - because I run mkgmap several
times... Just convenience.

On Mon, 30 Aug 2021 at 12:50, Felix Hartmann 
wrote:

> Well I'm not fully sure this works as intended - though at first glance I
> cannot find a problem - but running mkgmap on the split files gives an:
>
> C:\openmtbmap\maps>start /belownormal /b /wait java -jar
> -XX:+AggressiveHeap -XX:StringTableSize=103 -Xms5000M -Xmx43000M
> C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
> --code-page=1252 "--style-file=C:\openmtbmap\buildings_style"
>  --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
> --ignore-turn-restrictions --merge-lines --allow-reverse-merge
> --transparent --draw-priority=28 --add-pois-to-areas
> --simplify-polygons=23:4,22:7,21:8
> --copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
> --license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
> --add-boundary-nodes-at-admin-boundaries=2
> --poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
> --polygon-size-limits="24:16, 23:14, 22:12, 21:11"
> --ignore-turn-restrictions --description=buildings_fr --country-abbr=fr
> --country-name=france --mapname=83910046 --family-id=8391 --product-id=1
> --series-name="buildings_france_30.08.2021" --keep-going
> --family-name="buildings_fr_30.08.2021" --tdbfile --gmapi --gmapsupp
> --overview-mapname=mapsetb --area-name="france_30.08.2021_buildings" -c
> D:\openmtbmap\maps\template.franceb1 8391*.img buildfr.typ  1>NUL
> Mkgmap version 4806M
> Time started: Mon Aug 30 12:34:48 CEST 2021
> Number of MapFailedExceptions: 0
> WARNING (global): Could not copy 83910046.RGN
> uk.me.parabola.imgfmt.FileExistsException: File 83910046.RGN already exists
> WARNING (global): Could not copy 83910046.TRE
> uk.me.parabola.imgfmt.FileExistsException: File 83910046.TRE already exists
> WARNING (global): Could not copy 83910046.LBL
> uk.me.parabola.imgfmt.FileExistsException: File 83910046.LBL already exists
> Number of ExitExceptions: 0
> Time finished: Mon Aug 30 12:35:28 CEST 2021
> Total time taken: 39 seconds
>
>
> Now of course there has been no file at all called 83910046* in the
> directory except 83910046.o5m (referenced via
> D:\openmtbmap\maps\template.franceb1 input file option). Google spits out
> no mention at all concerning this error. I would guess there is an error in
> the --gmapi file?
>
> On Mon, 30 Aug 2021 at 12:38, Felix Hartmann 
> wrote:
>
>> okay - well the only working solution to this problem is to use o5m
>> output format with mkgmap, and then use osmconvert to join the files before
>> splitting them again.
>> Would it be possible for mkgmap to have a mode to split the files one by
>> one without the detour via osmconvert?
>>
>> o5m uses a lot more hdd space, and mkgmap.jar is only marginally faster
>> with 05m input vs osm.pbf (splitter works quite a lot faster on big o5m
>> files vs osm.pbf - but small input files make not much time difference)...
>>
>> On Mon, 30 Aug 2021 at 02:25, Felix Hartmann 
>> wrote:
>>
>>> I split france.osm.pbf with D:\openmtbmap\maps>if france == legend start
>>> /belownormal /b /wait java -jar -XX:+AggressiveHeap -Xms1000m -Xmx3800m
>>> C:\openmtbmap\splitter.jar --max-nodes=960  --max-threads=12
>>> --search-limit=100 --output=pbf "--keep-complete" --max-areas=1024
>>> --geonames-file=D:\openmtbmap\osmpbf_geofabrik\cities5000.zip
>>> --description=france --mapid=8391 france.osm  1>NUL
>>>
>>> Then I compiled the map using mgkamp.jar - and want to resplit all
>>> remaining files that did not compile with smaller max-nodes value. However
>>> splitter.jar chokes if I pass several files... Is there any way to have
>>> splitter just working with several files without trying to merge them? I
>>> just need the files split to the new max-nodes value and incrementing the
>>> map id. If I pass only one file at a time, it is a PITA to script this (is
>>> already hard enough figuring out the new map-id and creating a list of the
>>> tiles).
>>>
>>> D:\openmtbmap\maps>if yes EQU yes start /belownormal /b /wait java
>>&g

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

[Felix Hartmann]

Well I'm not fully sure this works as intended - though at first glance I
cannot find a problem - but running mkgmap on the split files gives an:

C:\openmtbmap\maps>start /belownormal /b /wait java -jar
-XX:+AggressiveHeap -XX:StringTableSize=103 -Xms5000M -Xmx43000M
C:\openmtbmap\mkgmap.jar --max-jobs=12 --order-by-decreasing-area
--code-page=1252 "--style-file=C:\openmtbmap\buildings_style"
 --levels="0:24, 1:23, 2:22, 3:21" --ignore-osm-bounds
--ignore-turn-restrictions --merge-lines --allow-reverse-merge
--transparent --draw-priority=28 --add-pois-to-areas
--simplify-polygons=23:4,22:7,21:8
--copyright-file="C:\openmtbmap\openmtbmap_svn\copyrightopm.txt"
--license-file="C:\openmtbmap\openmtbmap_svn\licenseopm.txt"
--add-boundary-nodes-at-admin-boundaries=2
--poi-excl-index=0x6405,0x4316,0x2f00 --ignore-fixme-values
--polygon-size-limits="24:16, 23:14, 22:12, 21:11"
--ignore-turn-restrictions --description=buildings_fr --country-abbr=fr
--country-name=france --mapname=83910046 --family-id=8391 --product-id=1
--series-name="buildings_france_30.08.2021" --keep-going
--family-name="buildings_fr_30.08.2021" --tdbfile --gmapi --gmapsupp
--overview-mapname=mapsetb --area-name="france_30.08.2021_buildings" -c
D:\openmtbmap\maps\template.franceb1 8391*.img buildfr.typ  1>NUL
Mkgmap version 4806M
Time started: Mon Aug 30 12:34:48 CEST 2021
Number of MapFailedExceptions: 0
WARNING (global): Could not copy 83910046.RGN
uk.me.parabola.imgfmt.FileExistsException: File 83910046.RGN already exists
WARNING (global): Could not copy 83910046.TRE
uk.me.parabola.imgfmt.FileExistsException: File 83910046.TRE already exists
WARNING (global): Could not copy 83910046.LBL
uk.me.parabola.imgfmt.FileExistsException: File 83910046.LBL already exists
Number of ExitExceptions: 0
Time finished: Mon Aug 30 12:35:28 CEST 2021
Total time taken: 39 seconds


Now of course there has been no file at all called 83910046* in the
directory except 83910046.o5m (referenced via
D:\openmtbmap\maps\template.franceb1 input file option). Google spits out
no mention at all concerning this error. I would guess there is an error in
the --gmapi file?

On Mon, 30 Aug 2021 at 12:38, Felix Hartmann 
wrote:

> okay - well the only working solution to this problem is to use o5m output
> format with mkgmap, and then use osmconvert to join the files before
> splitting them again.
> Would it be possible for mkgmap to have a mode to split the files one by
> one without the detour via osmconvert?
>
> o5m uses a lot more hdd space, and mkgmap.jar is only marginally faster
> with 05m input vs osm.pbf (splitter works quite a lot faster on big o5m
> files vs osm.pbf - but small input files make not much time difference)...
>
> On Mon, 30 Aug 2021 at 02:25, Felix Hartmann 
> wrote:
>
>> I split france.osm.pbf with D:\openmtbmap\maps>if france == legend start
>> /belownormal /b /wait java -jar -XX:+AggressiveHeap -Xms1000m -Xmx3800m
>> C:\openmtbmap\splitter.jar --max-nodes=960  --max-threads=12
>> --search-limit=100 --output=pbf "--keep-complete" --max-areas=1024
>> --geonames-file=D:\openmtbmap\osmpbf_geofabrik\cities5000.zip
>> --description=france --mapid=8391 france.osm  1>NUL
>>
>> Then I compiled the map using mgkamp.jar - and want to resplit all
>> remaining files that did not compile with smaller max-nodes value. However
>> splitter.jar chokes if I pass several files... Is there any way to have
>> splitter just working with several files without trying to merge them? I
>> just need the files split to the new max-nodes value and incrementing the
>> map id. If I pass only one file at a time, it is a PITA to script this (is
>> already hard enough figuring out the new map-id and creating a list of the
>> tiles).
>>
>> D:\openmtbmap\maps>if yes EQU yes start /belownormal /b /wait java
>> -XX:+AggressiveHeap -Xms5000M -Xmx54000M -jar C:\openmtbmap\splitter.jar
>> --max-nodes=480 --max-threads=12 --search-limit=100 --output=pbf
>> --geonames-file=D:\openmtbmap\osmpbf_geofabrik\cities5000.zip
>> --description=france --mapid=83910046  "83910015.osm.pbf"
>> "83910025.osm.pbf" "83910026.osm.pbf" "83910042.osm.pbf"1>NUL
>> Warning: --keep-complete is only used for the first input file. Further
>> files must use higher ids.
>> Error: Node ids are not sorted. Use e.g. osmosis to sort the input data.
>> This is not supported with keep-complete=true or --problem-list
>> uk.me.parabola.splitter.SplitFailedException: Node ids are not sorted
>> at
>> uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:497)
>> at
>> uk.me.p

Re: [mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

[Felix Hartmann]

okay - well the only working solution to this problem is to use o5m output
format with mkgmap, and then use osmconvert to join the files before
splitting them again.
Would it be possible for mkgmap to have a mode to split the files one by
one without the detour via osmconvert?

o5m uses a lot more hdd space, and mkgmap.jar is only marginally faster
with 05m input vs osm.pbf (splitter works quite a lot faster on big o5m
files vs osm.pbf - but small input files make not much time difference)...

On Mon, 30 Aug 2021 at 02:25, Felix Hartmann 
wrote:

> I split france.osm.pbf with D:\openmtbmap\maps>if france == legend start
> /belownormal /b /wait java -jar -XX:+AggressiveHeap -Xms1000m -Xmx3800m
> C:\openmtbmap\splitter.jar --max-nodes=960  --max-threads=12
> --search-limit=100 --output=pbf "--keep-complete" --max-areas=1024
> --geonames-file=D:\openmtbmap\osmpbf_geofabrik\cities5000.zip
> --description=france --mapid=8391 france.osm  1>NUL
>
> Then I compiled the map using mgkamp.jar - and want to resplit all
> remaining files that did not compile with smaller max-nodes value. However
> splitter.jar chokes if I pass several files... Is there any way to have
> splitter just working with several files without trying to merge them? I
> just need the files split to the new max-nodes value and incrementing the
> map id. If I pass only one file at a time, it is a PITA to script this (is
> already hard enough figuring out the new map-id and creating a list of the
> tiles).
>
> D:\openmtbmap\maps>if yes EQU yes start /belownormal /b /wait java
> -XX:+AggressiveHeap -Xms5000M -Xmx54000M -jar C:\openmtbmap\splitter.jar
> --max-nodes=480 --max-threads=12 --search-limit=100 --output=pbf
> --geonames-file=D:\openmtbmap\osmpbf_geofabrik\cities5000.zip
> --description=france --mapid=83910046  "83910015.osm.pbf"
> "83910025.osm.pbf" "83910026.osm.pbf" "83910042.osm.pbf"1>NUL
> Warning: --keep-complete is only used for the first input file. Further
> files must use higher ids.
> Error: Node ids are not sorted. Use e.g. osmosis to sort the input data.
> This is not supported with keep-complete=true or --problem-list
> uk.me.parabola.splitter.SplitFailedException: Node ids are not sorted
> at
> uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:497)
> at
> uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:126)
> at
> uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:82)
> at
> uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:157)
> at
> uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)
> at uk.me.parabola.splitter.Main.useProblemLists(Main.java:503)
> at uk.me.parabola.splitter.Main.start(Main.java:127)
> at uk.me.parabola.splitter.Main.main(Main.java:81)
>
>
> The option to first join the files with osmconvert - is a PITA - as you
> cannot parse several osm.pbf files to osmconvert (it only supports joining
> osm or o5m files).
> The option to supply splitter.jar with each file on it's own - is also a
> PITA that would require horrendous for loops because after each split you
> need to check which new map-id to use for the next file!
>
> So it would be great to have a keep-complete option that for each input
> file, but not for all input files, uses keep-complete. Actually I think
> this should be the default mode when supplying several input files. Even if
> mkgmap actually cannot run this in parallel / multithreading it would be
> way better than parsing each file on it's own...
> Or am I dumbstruck in finding a way to resplit too big input files?
>
> --
> Felix Hartman - Openmtbmap.org & VeloMap.org
>
>

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

[mkgmap-dev] Error when running splitter with several input files, could there be keep-complete=single mode?

[Felix Hartmann]

I split france.osm.pbf with D:\openmtbmap\maps>if france == legend start
/belownormal /b /wait java -jar -XX:+AggressiveHeap -Xms1000m -Xmx3800m
C:\openmtbmap\splitter.jar --max-nodes=960  --max-threads=12
--search-limit=100 --output=pbf "--keep-complete" --max-areas=1024
--geonames-file=D:\openmtbmap\osmpbf_geofabrik\cities5000.zip
--description=france --mapid=8391 france.osm  1>NUL

Then I compiled the map using mgkamp.jar - and want to resplit all
remaining files that did not compile with smaller max-nodes value. However
splitter.jar chokes if I pass several files... Is there any way to have
splitter just working with several files without trying to merge them? I
just need the files split to the new max-nodes value and incrementing the
map id. If I pass only one file at a time, it is a PITA to script this (is
already hard enough figuring out the new map-id and creating a list of the
tiles).

D:\openmtbmap\maps>if yes EQU yes start /belownormal /b /wait java
-XX:+AggressiveHeap -Xms5000M -Xmx54000M -jar C:\openmtbmap\splitter.jar
--max-nodes=480 --max-threads=12 --search-limit=100 --output=pbf
--geonames-file=D:\openmtbmap\osmpbf_geofabrik\cities5000.zip
--description=france --mapid=83910046  "83910015.osm.pbf"
"83910025.osm.pbf" "83910026.osm.pbf" "83910042.osm.pbf"1>NUL
Warning: --keep-complete is only used for the first input file. Further
files must use higher ids.
Error: Node ids are not sorted. Use e.g. osmosis to sort the input data.
This is not supported with keep-complete=true or --problem-list
uk.me.parabola.splitter.SplitFailedException: Node ids are not sorted
at
uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:497)
at
uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:126)
at
uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:82)
at
uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:157)
at
uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)
at uk.me.parabola.splitter.Main.useProblemLists(Main.java:503)
at uk.me.parabola.splitter.Main.start(Main.java:127)
at uk.me.parabola.splitter.Main.main(Main.java:81)


The option to first join the files with osmconvert - is a PITA - as you
cannot parse several osm.pbf files to osmconvert (it only supports joining
osm or o5m files).
The option to supply splitter.jar with each file on it's own - is also a
PITA that would require horrendous for loops because after each split you
need to check which new map-id to use for the next file!

So it would be great to have a keep-complete option that for each input
file, but not for all input files, uses keep-complete. Actually I think
this should be the default mode when supplying several input files. Even if
mkgmap actually cannot run this in parallel / multithreading it would be
way better than parsing each file on it's own...
Or am I dumbstruck in finding a way to resplit too big input files?

-- 
Felix Hartman - 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] signed maps / new device

[Felix Hartmann]

Just make a map of Cyprus and check if you get greek in the South, and
Turkish special characters in the north. The Latin alphabet without special
characters like ö or accents is covered in nearly all codepages.

On Wed, 4 Aug 2021, 07:15 7770 <7...@foskan.eu> wrote:

> Hi.
> i have made maps using the --code-page=65001  option.
> Maps are read just fine by GPSMAP 66st with all firmwares i have had (at
> least
> since 4.xx up till 7.60).
>
> Could there be something overriding this setting and not making the map
> unicode, is there a way to check what the map really is?
>
> i use map data from geofabrik.de.
>
> regards
> Karl
>
>
> On tisdag 3 augusti 2021 kl. 17:59:15 CEST Andrzej Popowski wrote:
> > Hi Marek,
> >
> > I have tested on 66st firmware 7.20. Unicode maps compiled with mkgmap
> > are rejected, the same message as you have found on issue 26 - "Cannot
> > authenticate maps".
>
>
>
>
> ___
> 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] signed maps / new device

[Felix Hartmann]

of course - any new device needs hacked firmware or non unicode maps. 1251
or whatever works however. I explained it above - tested that many times.
If we cannot come up how to digitally sign a map (maybe any code signing
certificate would be fine? but I have no clue how they signed the maps and
which parts are signed) it's that way


On Tue, 3 Aug 2021 at 17:59, Andrzej Popowski  wrote:

> Hi Marek,
>
> I have tested on 66st firmware 7.20. Unicode maps compiled with mkgmap
> are rejected, the same message as you have found on issue 26 - "Cannot
> authenticate maps".
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] Improper transliteration of Bulgarian text

[Felix Hartmann]

The transliteration is never good. So either use cyrillic codepage or
Unicode without transliteration. Do not transliterate at all - that*s the
best solution.

Essentially you have 4 options:
local codepage - no transliteration using name key - transliterate other
letters into cyrillic
unicode using name
unicode using name:en, name:int and so on and name only if other tags do
not exist so less needs to be transliterated
latin - transliterate name tag from cyrillic into latin. and use name only
if name:en and so on does not exist.

On Mon, 2 Aug 2021 at 12:14,  wrote:

> HI Gerd,
>
> I'm writing from a different email since the mail.bg one seems to add ads
> on
> the end of the message which I've removed from the bottom of this message.
>
> According to a user on the forum the issue is about improper
> transliteration
> of Cyrillic text that could be caused by this program.  My question is if
> there is only name on a given object and no other names but the person who
> runs this software wants his map to be in English, will mkgmap try to
> change
> the name? If so could you send a link to the file where associations for
> each letter are made (ex: Cyrillic letter Д to be changed with Latin letter
> D, Cyrillic letter С to be changed with Latin letter S etc.).
>
> Dimitar
>
> -Original Message-
> From: mkgmap-dev  On Behalf Of
> Gerd
> Petermann
> Sent: 02 август 2021 г. 12:13
> To: Development list for mkgmap 
> Subject: Re: [mkgmap-dev] Improper transliteration of Bulgarian text
>
> Hi Dimitar,
>
> not sure what you try to achive. Several options have an influence here,
> most important are --name-tag-list and --codepage See
> https://www.mkgmap.org.uk/doc/options
>
> I am not sure if --code-page=1257 or --code-page=65001 (unicode) should be
> used.
>
> Does that help?
>
> Gerd
>
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> osm_dimitar...@mail.bg 
> Gesendet: Montag, 2. August 2021 09:58
> An: mkgmap-dev@lists.mkgmap.org.uk
> Betreff: [mkgmap-dev] Improper transliteration of Bulgarian text
>
> Hello all,
>
> There has been a post on the Bulgarian section of the OSM forum that
> Bulgarian names are not correctly transliterated
> (https://forum.openstreetmap.org/viewtopic.php?id=73331). According to
> these
> users, names show as question marks or if they show up the transliteration
> is incorrect. Here are some examples:
> Драгоман - Draghoman instead of Dragoman Драговищица - Dragovishchica
> instead of Dragovishticha Петърч - Pet?rch instead of Petarch
>
> I've found a document that shows what the correct transliteration of each
> letter is. It is complient with the transliteration act as of its last
> change in 2019. Note that it only applies to the Bulgarian language. Other
> languages may have different rules
>
> https://assets.publishing.service.gov.uk/government/uploads/system/uploads/a
> ttachment_data/file/811509/ROMANIZATION_OF_BULGARIAN.pdf
> 
>
> Is it possible to fix this issue without causing issues for other Slavic
> languages? I haven't investigated how your software works, but a possible
> solution could be to have a different set of rules for each country.
>
> Regards,
> Dimitar
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



-- 
Felix Hartman - 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] signed maps / new device

[Felix Hartmann]

If you have a code signing certificate, would it be possible to add that
digital signature to Unicode maps?
Every codepage works on the newer devices - as long as the codepage is
supported by the device - even codepages like Simplified or Tradition
chinese Characters. For some languages however no codepage exists (very
few) while they are covered by Unicode).

On Sat, 31 Jul 2021 at 16:18, Andrzej Popowski  wrote:

> Hi,
>
> I think different models of GPS react differently. Most common is that
> new devices require digital signature for Unicode maps. Maps with CP1252
> usually work. At least handheld GPS, more problems could be with nuvi.
>
> --
> Best regards,
> Andrzej
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>


-- 
Felix Hartman - 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] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

[Felix Hartmann]

For gmapsupp.img downloads under Mac OS X there is without gmaptool no easy
way to exchange the .typ file. So would be nice to have a replacement for
gmaptool not being 64 bit.

On Mon, 26 Jul 2021, 11:22 Gerd Petermann 
wrote:

> Hi Felix,
>
> I don't understand fully the purpose. I know that your installation
> routine allows to choose a typ file. Do you plan to distribute mkgmap and a
> full JRE with each installation package?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Sonntag, 25. Juli 2021 18:59
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x
> 11  or newer?
>
> @ andrzej, could you maybe add  that functionality to mkgmap?
>
> It would be great to have
>
> On Sun, 25 Jul 2021, 15:37 Andrzej Popowski  po...@poczta.onet.pl>> wrote:
> Hi,
>
> actually gmaptool doesn't split and merge img, when replacing typ. It
> overwrites old data with a new one. If new typ is longer then the old
> one, gmaptool has to search for free sectors in img or increase img size.
>
> --
> Best regards,
> Andrzej
> ___
> 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
>
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

[Felix Hartmann]

@ andrzej, could you maybe add  that functionality to mkgmap?

It would be great to have

On Sun, 25 Jul 2021, 15:37 Andrzej Popowski  wrote:

> Hi,
>
> actually gmaptool doesn't split and merge img, when replacing typ. It
> overwrites old data with a new one. If new typ is longer then the old
> one, gmaptool has to search for free sectors in img or increase img size.
>
> --
> 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] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

[Felix Hartmann]

oh - well compared to gmt which does it in a second that's a big
difference...

On Fri, 23 Jul 2021 at 20:35, Ticker Berkin  wrote:

> Hi Felix
>
> For my 1G map it takes just over a minute to extract and about the same
> to rebuild. The components are not altered/rebuilt.
>
> Ticker
>
> On Fri, 2021-07-23 at 19:24 +0300, Felix Hartmann wrote:
> > Hi Ticker,
> >
> > thanks for your answer
> > If the gmapsupp.img is 2GB - will this be kinda instant or will it
> > rewrite the full gmapsupp.img from scratch?
> >
> > It would be great if the standard mkgamp.jar could include that typ
> >  change functionality (I guess this could be easy to add - as mkgmap
> > knows how to build the gmapsupp.img - maybe Andrez could help/add
> > here ot have the most needed functionality of gmt for end users
> > available for Mac?
> >
> > On Fri, 23 Jul 2021 at 19:06, Ticker Berkin 
> > wrote:
> > > Hi
> > >
> > > The mkgmap / display tool has a function to extract all the
> > > components
> > > from a gmapsupp.img and another function to take components and
> > > build a
> > > composite image.
> > >
> > > You'll need to get the sources from svn - see:
> > >
> > > https://www.mkgmap.org.uk/mkgmap/display
> > >
> > > and build it.
> > >
> > > In an empty directory, my unix command to extract is
> > >
> > > $ java -Xmx1540M -ea -classpath \
> > > /myMkgmap/display/trunk/build/classes:\
> > > /myMkgmap/svn/trunk/build/classes:\
> > > /myMkgmap/svn/trunk/lib/compile/fastutil-6.5.15-mkg.1b.jar:\
> > > /myMkgmap/svn/trunk/lib/compile/osmpbf-1.3.3.jar:\
> > > /myMkgmap/svn/trunk/lib/compile/protobuf-java-2.5.0.jar \
> > >  test.ExtractFile ../gmapsupp.img
> > >
> > > Adjust paths as necessary to reference the display build and your
> > > standard mkgmap build.
> > >
> > > To reconstitute, adjust the contents of the folder to have the new
> > > TYP,
> > > then use the same command as above but replace the last line with,
> > > eg:
> > >  test.ZipFile ../newgmap.img *
> > >
> > > This will probably change the order of the components and I've no
> > > idea
> > > if this matters, but, if it does, give an explicit list, derived
> > > from
> > > the output of ExtractFile, instead of *
> > >
> > > Ticker
> > >
> > > On Fri, 2021-07-23 at 16:08 +0300, Felix Hartmann wrote:
> > > > Hi - is there any tool available to change the .typ-file in a
> > > > gmapsupp.img on the Mac OS X Big Sur or newer?
> > > >
> > > > As gmt_osx is not gonna be updated to x64 - I wonder if there is
> > > an
> > > > alternative.
> > > > Or maybe could this function be added to mkgmap?
> > > >
> > > > I would imagine a call java mkgmap.jar --change-typ gmapsupp.img
> > > > newtyp.typ
> > > > (so remove all existing .typfiles in the gmapsupp.img and replace
> > > > them with newtyp.typ - for gmapsupp.img consisting of several
> > > maps
> > > > this would be more complicated - I do not feel that is needed).
> > > >
> > > > Plus maybe the option to join several gmapsupp.img files into a
> > > new
> > > > bigger one (only important for very old devices).
> > > >
> > > > --
> > > > Felix Hartman - Openmtbmap.org & VeloMap.org
> > > >
> > > > ___
> > > > 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
> > >
> >
> > --
> > Felix Hartman - Openmtbmap.org & VeloMap.org
> >
> > ___
> > 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
>


-- 
Felix Hartman - 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] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

[Felix Hartmann]

Hi Ticker,

thanks for your answer
If the gmapsupp.img is 2GB - will this be kinda instant or will it rewrite
the full gmapsupp.img from scratch?

It would be great if the standard mkgamp.jar could include that typ change
functionality (I guess this could be easy to add - as mkgmap knows how to
build the gmapsupp.img - maybe Andrez could help/add here ot have the most
needed functionality of gmt for end users available for Mac?

On Fri, 23 Jul 2021 at 19:06, Ticker Berkin  wrote:

> Hi
>
> The mkgmap / display tool has a function to extract all the components
> from a gmapsupp.img and another function to take components and build a
> composite image.
>
> You'll need to get the sources from svn - see:
>
> https://www.mkgmap.org.uk/mkgmap/display
>
> and build it.
>
> In an empty directory, my unix command to extract is
>
> $ java -Xmx1540M -ea -classpath \
> /myMkgmap/display/trunk/build/classes:\
> /myMkgmap/svn/trunk/build/classes:\
> /myMkgmap/svn/trunk/lib/compile/fastutil-6.5.15-mkg.1b.jar:\
> /myMkgmap/svn/trunk/lib/compile/osmpbf-1.3.3.jar:\
> /myMkgmap/svn/trunk/lib/compile/protobuf-java-2.5.0.jar \
>  test.ExtractFile ../gmapsupp.img
>
> Adjust paths as necessary to reference the display build and your
> standard mkgmap build.
>
> To reconstitute, adjust the contents of the folder to have the new TYP,
> then use the same command as above but replace the last line with, eg:
>  test.ZipFile ../newgmap.img *
>
> This will probably change the order of the components and I've no idea
> if this matters, but, if it does, give an explicit list, derived from
> the output of ExtractFile, instead of *
>
> Ticker
>
> On Fri, 2021-07-23 at 16:08 +0300, Felix Hartmann wrote:
> > Hi - is there any tool available to change the .typ-file in a
> > gmapsupp.img on the Mac OS X Big Sur or newer?
> >
> > As gmt_osx is not gonna be updated to x64 - I wonder if there is an
> > alternative.
> > Or maybe could this function be added to mkgmap?
> >
> > I would imagine a call java mkgmap.jar --change-typ gmapsupp.img
> > newtyp.typ
> > (so remove all existing .typfiles in the gmapsupp.img and replace
> > them with newtyp.typ - for gmapsupp.img consisting of several maps
> > this would be more complicated - I do not feel that is needed).
> >
> > Plus maybe the option to join several gmapsupp.img files into a new
> > bigger one (only important for very old devices).
> >
> > --
> > Felix Hartman - Openmtbmap.org & VeloMap.org
> >
> > ___
> > 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
>


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

[mkgmap-dev] Echange .typ-file in gmapsupp.img on Mac OS x 11 or newer?

[Felix Hartmann]

Hi - is there any tool available to change the .typ-file in a gmapsupp.img
on the Mac OS X Big Sur or newer?

As gmt_osx is not gonna be updated to x64 - I wonder if there is an
alternative.
Or maybe could this function be added to mkgmap?

I would imagine a call java mkgmap.jar --change-typ gmapsupp.img newtyp.typ
(so remove all existing .typfiles in the gmapsupp.img and replace them with
newtyp.typ - for gmapsupp.img consisting of several maps this would be more
complicated - I do not feel that is needed).

Plus maybe the option to join several gmapsupp.img files into a new bigger
one (only important for very old devices).

-- 
Felix Hartman - 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] Change in Garmin IMG format?

[Felix Hartmann]

well change 0x10200 to 0x11200 or whatever. You can look into the kmtf file
for seeing what it does. And no high-contrast is rubbish not great. If you
want high contrast just create a high-contrast .typ-file.

On Mon, 19 Jul 2021 at 17:05, Craig Durkin  wrote:

> Hi Felix -- can you give me an example of what you mean by "changing the
> types"? Having the option to use the high-contrast maps would be great,
> even though it's not my first choice..
>
> Thanks,
> Craig
>
> On Mon, Jul 19, 2021 at 4:30 AM Felix Hartmann 
> wrote:
>
>> The .typ-file does not matter - you need to change the types if you want
>> to use the high-contrast rubbish...
>>
>> On Mon, 19 Jul 2021 at 06:05, Craig Durkin  wrote:
>>
>>> Has anyone had to make changes to their TYP file to make things look
>>> better with the high-contrast map? I make maps where I draw a bunch of red
>>> lines on roads, they appear very muted and gray in the high-contrast map.
>>>
>>> Thanks,
>>> Craig
>>> ___
>>> mkgmap-dev mailing list
>>> mkgmap-dev@lists.mkgmap.org.uk
>>> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
>>
>>
>>
>> --
>> Felix Hartman - Openmtbmap.org & VeloMap.org
>>
>> ___
>> 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



-- 
Felix Hartman - 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] Change in Garmin IMG format?

[Felix Hartmann]

The .typ-file does not matter - you need to change the types if you want to
use the high-contrast rubbish...

On Mon, 19 Jul 2021 at 06:05, Craig Durkin  wrote:

> Has anyone had to make changes to their TYP file to make things look
> better with the high-contrast map? I make maps where I draw a bunch of red
> lines on roads, they appear very muted and gray in the high-contrast map.
>
> Thanks,
> Craig
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



-- 
Felix Hartman - 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] Change in Garmin IMG format?

[Felix Hartmann]

No they haven't changed the img format, what they did is that for years
they designed the maps in layout for desktop size displays, and finally
discovered maps should be much higher contrast on small displays. So they
introduced (already sind 2-3 years) a high contrast layout that is more and
more independent of the .typ-file layout. Since the newest update this is
even more noticeable.

It can be deactivated by selecting classic map design or similar. While
high contrast or mountainbike or whatever will use the new layout.

On Tue, 13 Jul 2021 at 04:44, ET Commands  wrote:

> I'm not sure if my message is relevant to this discussion list or not.
>
> I own an Edge 1030 and I use mkgmap to make custom maps for it. Recently
> Garmin provided a firmware update for the 1030 (ver. 12.0).  After I
> installed it none of my custom POI symbols appear on the map.  In
> addition, the default Garmin POI symbols have been updated by Garmin.
> All my custom line and polygon symbols still display.  I saw comments
> from some users in the Garmin forums that TOPO maps will no longer work
> with the firmware update either.
>
> It appears Garmin may have revised the format of their IMG files, if
> only slightly.  I don't know if this affects all Garmin models or only
> certain ones.
>
>
> Mark
>
> ___
> mkgmap-dev mailing list
> mkgmap-dev@lists.mkgmap.org.uk
> https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



-- 
Felix Hartman - 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] new splitter branch solve-parallel

[Felix Hartmann]

Hi Gerd,
well setting initial search limit to 100 solves already loads of bad
solutions and is still quite fast. Albeit using v 408 it was the best
universal value I felt. Not much slower but in many cases getting better
results. Going for much bigger initial value actually then caused also
worse splits. I do not know how right now it determines the max value. but
maybe increasing it would be good. And I feel it should increase/wait if
the split obviously is not good. If it is good (all tiles except one within
80% of maxnodes) or very good (all except one 85%) it could stop earlier in
order not to waste resources.
I do not know how easy such a solution is to be implemented however. So far
most bad splits are really realy bad (e.g. Norway 210 vs 135 tiles - in
such cases a much longer time taken to find a good split is reasonable.
Also as mkgmap will run faster if the split is better, compressing the maps
will produce a smaller overall size if the split is better.

On Thu, 1 Jul 2021 at 11:54, Ticker Berkin  wrote:

> Hi Gerd
>
> Is this of any relevance -
>
> https://en.wikipedia.org/wiki/Branch_and_bound
>
> Ticker
>
> On Wed, 2021-06-30 at 16:08 +, Gerd Petermann wrote:
> > Hi all,
> >
> > I've started this branch to further improve the split results.
> > Splitter has two different algorithms to find good splits.
> > 1) Algo FULL tries first to split in the middle and then continues
> > with the next positions (mid+1, mid-1, mid+2, mid-2, ...)
> > The resulting parts are split again recursively. This should find the
> > best possible split but can take very long when the only good split
> > starts far from the middle.
> >
> > 2) Algo SOME uses some heuristics to test only some of the possible
> > splits. This is typically much faster but sometimes doesn't find any
> > solution and sometimes the FULL algo finds a better solution.
> >
> > The trunk version tries first the one that is more promising and - if
> > that fails to find a good split - tries the other. So, sometimes the
> > FULL algo works for 2 minutes and then SOME finds a good result in a
> > few seconds.
> >
> > This branch executes both algorithms in parallel and uses the better
> > result.
> >
> > One of the open problems is to decide under what conditions the
> > execution should stop.
> > If the SOME algo finds a good solution within 20 secs should we still
> > continue the FULL algo to find the best solution? If yes, how long?
> > I'm playing with this, any input is welcome.
> >
> > 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
>


-- 
Felix Hartman - 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] splitter r609 released

[Felix Hartmann]

Well here are the results for 615:
If you would like the log files for any of those runs - tell me.
Significantly better with polygon file are Norway, Russia,
Australia-Oceania and Asia. This version has much less problem countries
like 614. It would be too big to attach all of them here. If you like all
of them then I can upload them to my server.

South America is really bad using polygon-file.

"for netherlands use polygon-file - cnt1 = 89 cnt0 = 88"
"for great-britain use polygon-file - cnt1 = 111 cnt0 = 110"
"for germany use polygon-file - cnt1 = 258 cnt0 = 257"
"for liechtenstein do not use polygon-file - cnt1 = 1 cnt0 = 6"
"for monaco do not use polygon-file - cnt1 = 1 cnt0 = 2"
"for slovenia do not use polygon-file - cnt1 = 27 cnt0 = 28"
"for ukraine use polygon-file - cnt1 = 62 cnt0 = 61"
*"for norway use polygon-file - cnt1 = 129 cnt0 = 119" *
"for switzerland do not use polygon-file - cnt1 = 29 cnt0 = 30"
"for poland use polygon-file - cnt1 = 132 cnt0 = 128"
"for sweden use polygon-file - cnt1 = 60 cnt0 = 54"
"for finland do not use polygon-file - cnt1 = 65 cnt0 = 84"
"for denmark use polygon-file - cnt1 = 33 cnt0 = 32"
"for andorra do not use polygon-file - cnt1 = 1 cnt0 = 4"
"for estonia use polygon-file - cnt1 = 9 cnt0 = 8"
"for saarland do not use polygon-file - cnt1 = 4 cnt0 = 17"
"for hamburg do not use polygon-file - cnt1 = 3 cnt0 = 12"
"for hessen do not use polygon-file - cnt1 = 17 cnt0 = 18"
"for bayern do not use polygon-file - cnt1 = 47 cnt0 = 48"
"for berlin do not use polygon-file - cnt1 = 5 cnt0 = 13"
*"for australia-oceania use polygon-file - cnt1 = 131 cnt0 = 109" *
"for south-america do not use polygon-file - cnt1 = 334 cnt0 = 463"
"for africa use polygon-file - cnt1 = 665 cnt0 = 663"
*"for asia use polygon-file - cnt1 = 1592 cnt0 = 1549" *
*"for russia use polygon-file - cnt1 = 426 cnt0 = 408" *
"for central-america use polygon-file - cnt1 = 61 cnt0 = 58"
"for morocco do not use polygon-file - cnt1 = 19 cnt0 = 27"
"for tanzania use polygon-file - cnt1 = 75 cnt0 = 74"
"for mozambique use polygon-file - cnt1 = 24 cnt0 = 23"
"for azerbaijan do not use polygon-file - cnt1 = 3 cnt0 = 4"
"for iran use polygon-file - cnt1 = 16 cnt0 = 15"
"for malaysia-singapore-brunei do not use polygon-file - cnt1 = 16 cnt0 =
17"
"for china use polygon-file - cnt1 = 106 cnt0 = 101"
"for india do not use polygon-file - cnt1 = 109 cnt0 = 112"
"for indonesia do not use polygon-file - cnt1 = 191 cnt0 = 200"
"for philippines use polygon-file - cnt1 = 52 cnt0 = 51"
"for afghanistan do not use polygon-file - cnt1 = 11 cnt0 = 20"
"for australia use polygon-file - cnt1 = 67 cnt0 = 66"
"for argentina use polygon-file - cnt1 = 32 cnt0 = 27"
"for brazil use polygon-file - cnt1 = 177 cnt0 = 172"
"for chile do not use polygon-file - cnt1 = 31 cnt0 = 33"
"for paraguay use polygon-file - cnt1 = 17 cnt0 = 16"
"for canada use polygon-file - cnt1 = 274 cnt0 = 272"
"for us-northeast do not use polygon-file - cnt1 = 109 cnt0 = 110"
"for us-pacific use polygon-file - cnt1 = 21 cnt0 = 18"
"for us-south use polygon-file - cnt1 = 262 cnt0 = 261"
"for us-west use polygon-file - cnt1 = 229 cnt0 = 227"
"for greenland use polygon-file - cnt1 = 4 cnt0 = 2"
"for mexico use polygon-file - cnt1 = 44 cnt0 = 42"
"for reunion do not use polygon-file - cnt1 = 3 cnt0 = 5"

On Wed, 30 Jun 2021 at 12:30, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> I've released r615 to fix the problems with Saarland (now 17 tiles with
> polygon instead of crash, 4 tiles without) and Norway (121 with polygon,
> 128 without)
> Numbers for max-nodes=140
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Mittwoch, 30. Juni 2021 10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] splitter r609 released
>
> well yeah by now my list is down to very few countries (different then
> with older splitter.jar) that profit from --polygon-file.
> I feel like I will only use polygon-file for Asia continent map and for
> Russia - they fit your description of spanning over 180° and needing
> polygon-file to be split into less tiles. They pretty consistently split
> better with polygon-file on several splitter versions.
>
> Then maybe retest a year later.
>
> On Wed, 30 Jun 2021 at 11:25, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc.

Re: [mkgmap-dev] new splitter branch solve-parallel

[Felix Hartmann]

I feel of all tiles are 85 percent of max then stop. If 5percent of tiles
are less the 75 percent max then maybe stop after 30 seconds. If more then
10 percent AND more then 10 tiles are less then 75 percent continue.

On Wed, 30 Jun 2021, 19:09 Gerd Petermann 
wrote:

> Hi all,
>
> I've started this branch to further improve the split results.
> Splitter has two different algorithms to find good splits.
> 1) Algo FULL tries first to split in the middle and then continues with
> the next positions (mid+1, mid-1, mid+2, mid-2, ...)
> The resulting parts are split again recursively. This should find the best
> possible split but can take very long when the only good split starts far
> from the middle.
>
> 2) Algo SOME uses some heuristics to test only some of the possible
> splits. This is typically much faster but sometimes doesn't find any
> solution and sometimes the FULL algo finds a better solution.
>
> The trunk version tries first the one that is more promising and - if that
> fails to find a good split - tries the other. So, sometimes the FULL algo
> works for 2 minutes and then SOME finds a good result in a few seconds.
>
> This branch executes both algorithms in parallel and uses the better
> result.
>
> One of the open problems is to decide under what conditions the execution
> should stop.
> If the SOME algo finds a good solution within 20 secs should we still
> continue the FULL algo to find the best solution? If yes, how long?
> I'm playing with this, any input is welcome.
>
> 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] splitter r609 released

[Felix Hartmann]

well yeah by now my list is down to very few countries (different then with
older splitter.jar) that profit from --polygon-file.
I feel like I will only use polygon-file for Asia continent map and for
Russia - they fit your description of spanning over 180° and needing
polygon-file to be split into less tiles. They pretty consistently split
better with polygon-file on several splitter versions.

Then maybe retest a year later.

On Wed, 30 Jun 2021 at 11:25, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> sure, it's not good if splitter fails to split correct data. Still, an
> automated process should check the return code of the program. If splitter
> returns a values !=  0 you can be sure that something is wrong (same with
> mkgmap)
>
> It's okay to split small files like Liechtenstein, no problem with that.
> Just don't expect to always get fewer tiles when you use a polygon-file ;)
>
> Gerd
>
> ____
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Mittwoch, 30. Juni 2021 10:10
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] splitter r609 released
>
> yes my script only counts the produced tiles. And if it's 0 that's very
> bad for any automated process. 0 should only happen if the input data is
> broken (yes then it should happen).
> (and why do I split countries like Liechtenstein - well first I do not
> know if the extract would fit into one tile without splitting, second if
> the download is broken for some reason - then splitter rightfully cannot
> split it - and the old maps on the server will not be overwritten by maps
> based on a broken extract from geofabrik).
>
> On Wed, 30 Jun 2021 at 11:03, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> I can now reproduce the poor result with norway when I use both
> --polygon-file and --precomp-sea.
> Problem seems to be that splitter decides to try the slower algo first.
> After a while it gives up and tries the alternative faster algo and that
> would find a good solution soon but splitter gives up too early, so this is
> really not an improvement.
> Without the polygon the slower algo finds a good solution.
>
> I am working on a new solution which executes both algos in parallel and
> selects the better result. This works much better for this test case but
> sometimes worse when option --num-tiles is used.
>
> reg. Saarland with polygon: r614 stops with an error message (and returns
> 1 to signal a bad split). Your scripts seems to ignore this and just counts
> the number of written tiles?
> I'll try to find a fix so that splitter doesn't try to fit the tiles into
> the polygon when this happens...
>
> Gerd
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Mittwoch, 30. Juni 2021 08:55
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] splitter r609 released
>
> okay yeah I think I misunderstood the polygon-file a bit. But why is the
> split for Norway so much worse now? Before it was possible to get it down
> to 115 tiles (using the polygon-file option) now its 168 instead. Not using
> polygon-file no change. (guess the 1 tile more is maybe added data
> somewhere).
>
> On Wed, 30 Jun 2021 at 07:59, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com
> ><mailto:gpetermann_muenc...@hotmail.com gpetermann_muenc...@hotmail.com>>> wrote:
> Hi Felix,
>
> reg. Saarland: I'll try to reproduce. Looks like an error.
> reg. Liechtenstein:
> I think we still have different ideas what the polygon-file option is
> about.
> The documentation is a bit outdated since r433 (see
> https://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=433 )
> but the basic idea was that splitter should try to produce tiles which
> don't overlap the given polygon too much. This sometimes means that it
> produces more and smaller tiles.
> Splitter should be able to find good splits for geofabrik downloads
> without a polygon-file, but there are use cases: If the user only wants a
> part of a download in the map they can use the corresponding polygon.
>
> You seem to suggest that splitter should just use the polygon to be able
> to ignore data that is in the input file but not in the polygon and never
> try to fit the tiles into the polygon?
>
> Gerd
>
>
>
>
>
>
>
> 
> Von: mkgmap-

Re: [mkgmap-dev] splitter r609 released

[Felix Hartmann]

yes my script only counts the produced tiles. And if it's 0 that's very bad
for any automated process. 0 should only happen if the input data is broken
(yes then it should happen).
(and why do I split countries like Liechtenstein - well first I do not know
if the extract would fit into one tile without splitting, second if the
download is broken for some reason - then splitter rightfully cannot split
it - and the old maps on the server will not be overwritten by maps based
on a broken extract from geofabrik).

On Wed, 30 Jun 2021 at 11:03, Gerd Petermann <
gpetermann_muenc...@hotmail.com> wrote:

> Hi Felix,
>
> I can now reproduce the poor result with norway when I use both
> --polygon-file and --precomp-sea.
> Problem seems to be that splitter decides to try the slower algo first.
> After a while it gives up and tries the alternative faster algo and that
> would find a good solution soon but splitter gives up too early, so this is
> really not an improvement.
> Without the polygon the slower algo finds a good solution.
>
> I am working on a new solution which executes both algos in parallel and
> selects the better result. This works much better for this test case but
> sometimes worse when option --num-tiles is used.
>
> reg. Saarland with polygon: r614 stops with an error message (and returns
> 1 to signal a bad split). Your scripts seems to ignore this and just counts
> the number of written tiles?
> I'll try to find a fix so that splitter doesn't try to fit the tiles into
> the polygon when this happens...
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag von
> Felix Hartmann 
> Gesendet: Mittwoch, 30. Juni 2021 08:55
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] splitter r609 released
>
> okay yeah I think I misunderstood the polygon-file a bit. But why is the
> split for Norway so much worse now? Before it was possible to get it down
> to 115 tiles (using the polygon-file option) now its 168 instead. Not using
> polygon-file no change. (guess the 1 tile more is maybe added data
> somewhere).
>
> On Wed, 30 Jun 2021 at 07:59, Gerd Petermann <
> gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>>
> wrote:
> Hi Felix,
>
> reg. Saarland: I'll try to reproduce. Looks like an error.
> reg. Liechtenstein:
> I think we still have different ideas what the polygon-file option is
> about.
> The documentation is a bit outdated since r433 (see
> https://www.mkgmap.org.uk/websvn/revision.php?repname=splitter&rev=433 )
> but the basic idea was that splitter should try to produce tiles which
> don't overlap the given polygon too much. This sometimes means that it
> produces more and smaller tiles.
> Splitter should be able to find good splits for geofabrik downloads
> without a polygon-file, but there are use cases: If the user only wants a
> part of a download in the map they can use the corresponding polygon.
>
> You seem to suggest that splitter should just use the polygon to be able
> to ignore data that is in the input file but not in the polygon and never
> try to fit the tiles into the polygon?
>
> Gerd
>
>
>
>
>
>
>
> 
> Von: mkgmap-dev  mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Felix Hartmann <
> extremecar...@gmail.com<mailto:extremecar...@gmail.com>>
> Gesendet: Dienstag, 29. Juni 2021 23:04
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] splitter r609 released
>
> I found (server) time to run my test again - using splitter v614 - search
> limit 100
> Problem cases in bold. I also added the number of tiles that splitter v602
> needed (well on one week older geofabrik extract - but that should not make
> such a difference for Norway or South America). I feel 602 with
> search-limit 100 was producing more consistent results.
>
> "for netherlands use polygon-file - cnt1 = 93 cnt0 = 88"
> "for alps do not use polygon-file - cnt1 = 225 cnt0 = 226"
> "for liechtenstein do not use polygon-file - cnt1 = 1 cnt0 = 6"
> I thought that the new version fixes the splitting if it is not actually
> needed.
>
> "for monaco do not use polygon-file - cnt1 = 1 cnt0 = 2"
> "for slovenia do not use polygon-file - cnt1 = 27 cnt0 = 28"
> "for ukraine use polygon-file - cnt1 = 62 cnt0 = 61"
> "for norway do not use polygon-file - cnt1 = 129 cnt0 = 168"
> Big degradation here - with the older splitter it was: "for norway use
> polygon-file - cnt1 = 128 cnt0 = 115" (also using 100 search limit)
>
> "for switzerland do not use polygon-file - cnt1 = 29 cn