Re: [mkgmap-dev] Commit r4918: add surface=chipseal to group of surfaces which means paved

[Carlos Dávila]

This group sets mkgmap:unpaved=0 for all surface types included

El 6/3/24 a las 13:22, Felix Herwegh escribió:

group of surfaces which means paved

What would be the role of this group / how could this group be used?

Auto-setting mkgmap:unpaved?

Thanks  Felix


 Original Message 
From: svn commit 
Sent: March 6, 2024 8:03:28 AM GMT+01:00
To: mkgmap-...@lists.mkgmap.org.uk, mkgmap-dev@lists.mkgmap.org.uk
Subject: [mkgmap-dev] Commit r4918: add surface=chipseal to group of surfaces 
which means paved

Version mkgmap-r4918 was committed by gerd on Wed, 06 Mar 2024

add surface=chipseal to group of surfaces which means paved
Patch chipseal.diff by Carlos Dávila


http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4918
___
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] Missing surface=chipseal in default style

[Carlos Dávila]

Hello all

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


Carlos
Index: resources/styles/default/lines
===
--- resources/styles/default/lines	(revisión: 4912)
+++ resources/styles/default/lines	(copia de trabajo)
@@ -71,7 +71,7 @@
 highway=* & (surface=asphalt | surface=paved | surface=sett |
 surface=concrete | surface=concrete:lanes | surface=concrete:plates |
 surface=paving_stones | surface=cobblestone |
-surface=cobblestone:flattened | surface=metal | surface=wood)
+surface=cobblestone:flattened | surface=metal | surface=wood | surface=chipseal)
 {set mkgmap:unpaved=0}
 highway=* & tracktype=grade1 & surface!=* {set mkgmap:unpaved=0}
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Splitter feature request

[Carlos Dávila]

Hi Gerd,

As this new feature would be for areas.list passed to splitter, I 
thought it could assign objects to tiles (inlcuding L-shaped ones) in 
one step, assuming it can do so once it knows the area of each tile, but 
I'm probably wrong, as I don't really know how splitter works internally.


Right/left hand drive side driving is quite difficult to solve in land 
borders, but L-shaped tiles can help avoiding the need of tiny tiles in 
those areas. For areas with a lot of islands, where some drive on the 
right and others on the left, L-shaped tiles would really help.


El 6/12/23 a las 12:23, Gerd Petermann escribió:

Hi Carlos,

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

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

ciao
Gerd



Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Sonntag, 3. Dezember 2023 12:26
An: Development list for mkgmap
Betreff: [mkgmap-dev] Splitter feature request

Hi all

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

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

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

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

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

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


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

[mkgmap-dev] Splitter feature request

[Carlos Dávila]

Hi all

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


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

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

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

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

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

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

[Carlos Dávila]

Try this:

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

El 13/7/23 a las 16:35, Tamas Gal escribió:

Hi all,

maybe I got that wrong but I thought I can merge multiple IMG files into a 
single one with Mkgmap. My problem is that I need a bunch of maps and my Garmin 
64s only shows 12 in the map selection. A simple solution to this limitation is 
merging maps ;)

Anyways, I gave Mkgmap a try but I get an error which I don't know how to 
interpret, since it's missing the input files but they are definitely in the 
folder. Do I maybe need the original OSM files as input files? In that case, 
the error message is probably wrong.

Here is an example where I try to merge the Hungarian and German map into a 
single IMG:

░ tamasgal@silentbox:~/opt/mkgmap-r4909
░ 16:29:24 > ls -alh *.img
-rw-r--r--@ 1 tamasgal  staff   126M Jul 13 16:24 otm-germany-contours.img
-rw-r--r--@ 1 tamasgal  staff43M Jul 13 16:28 otm-hungary-contours.img
-rw-r--r--@ 1 tamasgal  staff   346M Jul 13 16:28 otm-hungary.img
-rw-r--r--@ 1 tamasgal  staff   246M Jul 13 16:29 otm-slovenia.img

░ tamasgal@silentbox:~/opt/mkgmap-r4909
░ 16:29:32 > java -jar mkgmap.jar --input-file otm-hungary.img --input-file 
otm-slovenia.img --gmapsupp
Mkgmap version 4909
Time started: Thu Jul 13 16:29:45 CEST 2023
SEVERE (Main): : input file '' doesn't exist
WARNING (global): Setting max-jobs to 1
SEVERE (Main): : input file '' doesn't exist
Number of MapFailedExceptions: 0
WARNING (global): To reduce the run time, consider increasing the amnount of 
memory available for use by mkgmap by using the Java -Xmx flag to set the 
memory to more than 32800 MB, providing this is less than the amount of 
physical memory installed.
SEVERE (global): Exiting - if you want to carry on regardless, use the 
--keep-going option
Number of ExitExceptions: 1
Time finished: Thu Jul 13 16:29:45 CEST 2023
Total time taken: 182 ms

Any ideas?

Thanks in advance,
Tom
___
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] Meaning of some mkgmap output messages

[Carlos Dávila]

Hello all

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


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


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



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

Re: [mkgmap-dev] Error processing tile

[Carlos Dávila]

Thanks for investigating it.

This is my java environment:
openjdk version "11.0.18" 2023-01-17
OpenJDK Runtime Environment (build 11.0.18+10-post-Debian-1deb11u1)
OpenJDK 64-Bit Server VM (build 11.0.18+10-post-Debian-1deb11u1, mixed 
mode, sharing)



El 1/6/23 a las 11:28, Ticker Berkin escribió:

Hi Carlos

I've tried this on my latest build which is r4907 + quite a few other
changes and I don't get the problem, but using an older, downloaded,
version I can reproduce it.

My changes don't look relevant to this issue; mainly character set
issues and some line/polygon filter reordering. The other difference I
have is building with Java 17 on a unix machine.

I'll investigate further. The problem is related to a road with >255
line segments.

NB: need option -ea for the exception to happen.

Ticker

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

[mkgmap-dev] Error processing tile

[Carlos Dávila]

Hello list

I'm getting the error below processing a tile from Vietnam:

Exception in thread "main" java.lang.AssertionError
   at uk.me.parabola.imgfmt.app.net.RoadIndex.write(RoadIndex.java:45)
   at 
uk.me.parabola.imgfmt.app.net.RoadDef.writeLevelDivs(RoadDef.java:356)
   at 
uk.me.parabola.imgfmt.app.net.RoadDef.writeNet1(RoadDef.java:237)

   at uk.me.parabola.imgfmt.app.net.NETFile.write(NETFile.java:68)
   at 
uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:355)

   at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:114)
   at uk.me.parabola.mkgmap.main.MapMaker.makeMap(MapMaker.java:70)
   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(ThreadPoolExecuto

r.java:628)
   at java.base/java.lang.Thread.run(Thread.java:829)

The simplest command triggering the error is: java -jar mkgmap.jar 
--route 51120021.o5m


Tile can be downloaded from https://alternativaslibres.org/tmp/51120021.o5m

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

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

[Carlos Dávila]

Hi Gerd

Thanks for your reply. I had already tried using the same split file, 
but it didn't work. I think it isn't worth generating DEM data each time 
a map is updated, given gmap version of all maps is also available in my 
site if anyone wants to have DEM in BaseCamp.


Carlos

El 3/1/23 a las 7:40, Gerd Petermann escribió:

Hi Carlos,

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

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 2. Januar 2023 18:45
An: Development list for mkgmap
Betreff: [mkgmap-dev] DEM data from gmapsuppp not showing on BaseCamp

Happy New Year to all!

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

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

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

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

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

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



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


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

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

[Carlos Dávila]

Happy New Year to all!

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


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


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


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


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


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




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

Re: [mkgmap-dev] Compile error

[Carlos Dávila]

Failing tile should be 0 bytes size. Regarding this question, in the 
past mkgmap showed the tile that was failing to compile, but this 
feature was removed some time ago. I use a patched version which 
re-implements it (see attached patch).


El 2/5/22 a las 20:02, Dave Swarthout escribió:


Another list member told me to look for the offending tile in order to 
manually split it, however, all the tiles look alike to me in terms of 
size. How would I tell which tile is the "bad one" that's causing this 
RGN error?Index: src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java
===
--- src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java	(revisión: 4827)
+++ src/uk/me/parabola/imgfmt/app/BufferedImgFileWriter.java	(copia de trabajo)
@@ -273,7 +273,9 @@
 bufferSize += GROW_SIZE;
 			if (bufferSize > maxAllowedSize) {
 throw new MapTooBigException(maxAllowedSize,
-		"The " + subfile + " section of the map or tile is too big.",
+		"The " + subfile + " section of the map or tile ("
+			+ log.threadTag()
+			+ ") is too big.",
 		"Try splitting the map into smaller tiles or reducing the amount of information included in the map.");
 			}
 			ByteBuffer newb = ByteBuffer.allocate(bufferSize);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
https://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] some findings about NT format

[Carlos Dávila]

But also a lot already learnt. Good job!!

El 7/4/22 a las 10:15, Gerd Petermann escribió:

Still  a lot to learn...


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

Re: [mkgmap-dev] Code to read locked maps

[Carlos Dávila]

That sounds promising, great!!

Le 26/1/22 à 13:01, Gerd Petermann a écrit :

Hi all,

The source code [1] for GPXSee [2] contains a routine demangle() which 
"unlocks" a locked TRE file.
I was aware that there are tools which can do that but never saw open source so 
far.
It's easy to add this in TREFileReader. I've already patches for mkgmap and 
display tool
which allow to read e.g. Adria Topo with e.g. RgnDisplay or NetDisplay.
Newer maps with Huffman encoded labels (in GMP file) do not yet work, I only 
managed to extract some labels
from LBL so far.

I don't plan to add support in mkgmap to write locked maps, but maybe mkgmap 
will be able to write NT maps
sometimes.

Gerd

[1] https://github.com/tumic0/GPXSee/blob/master/src/map/IMG/trefile.cpp
[2] https://www.gpxsee.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

Re: [mkgmap-dev] Polygon deformation

[Carlos Dávila]

What options/values have you used? Specially 
--reduce-point-density-polygon, --simplify-polygons and map levels


Le 21/1/22 à 8:52, Alexis Lecanu a écrit :
Hello, I'm contacting you because I can't understand why my polygons 
are deformed, I tried to find the options that could be the cause but 
nothing affects the polygons.

Is it wanted directly in the algo?
I see that simple shapes like a rectangle can become a triangle or a 
more complex polygon, it's a shame for the readability.


Thank you in advance for your answer.




Alexis LECANU

https://www.facebook.com/Garmin-Connect-App-Alexis-Lecanu-395326794312827

If you want to pay me a beer to thank me:
https://ko-fi.com/alexislecanu





___
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] Please help

[Carlos Dávila]

Could you provide display.jar binary? I can't find it in the web, sorry.

El 28/12/21 a las 15:55, Gerd Petermann escribió:

Hi all,

those who have original garmin maps for the PC and know how to compile display 
tool:
Update to r575 or higher.
Please execute the program MdrDisplay on the global index of the map (e.g 
mdrmap.img) like this:
java -ea  -Xmx6800m -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar 
test.display.MdrDisplay MDRMAP.img   --print=16 > mdr16.txt

(fix the paths to the two jar files, replace the ; by : on linux)

The expected result is a rather small text file (~32k) or a crash.
Please reply with your results, possibly zipped. I am esp. interested in 
crashes, but good data also might help to understand a few missing bits.

This is about a compression algorithm that is used in some old Garmin maps and 
I plan to implement that in mkgmap
to reduce file size of the global index file.

I've attached a sample output for the Adria Topo 2.4 map.

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] Problem using profiles with OSM based maps

[Carlos Dávila]

Thanks Gerd for the hint, I didn't know about --custom option. But 
according to mkgmap help, it is for marine maps, maybe using it as 
default could break more than fix?


El 20/12/21 a las 10:18, Gerd Petermann escribió:

Hi Carlos,

I don't understand all of this but the mentioned change from 17 (0x11) to 23  
(0x17)  is
done when the --custom option is given.

Gerd



Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 20. Dezember 2021 09:55
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem using profiles with OSM based maps

An user of my maps has reported the following problem when using OSM
based maps. He uses profiles in a GPSMAP 65s mainly to enable/disable
different sets of maps associated to each profile. When he has several
OSM based maps in the SD card (not only mines, also from other sources,
witch I guess are also built with mkgmap), switching between profiles
automatically enables all OSM maps, even if they were previously
disabled in a given profile. It seems to be related to some parameters
in the TRE subfile, as reported in this thread:
https://www.gpsrchive.com/Discussion/viewtopic.php?t=1571=6e0edd3239fb36f34c4b5d8df4f9f036


___
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] Problem using profiles with OSM based maps

[Carlos Dávila]

An user of my maps has reported the following problem when using OSM 
based maps. He uses profiles in a GPSMAP 65s mainly to enable/disable 
different sets of maps associated to each profile. When he has several 
OSM based maps in the SD card (not only mines, also from other sources, 
witch I guess are also built with mkgmap), switching between profiles 
automatically enables all OSM maps, even if they were previously 
disabled in a given profile. It seems to be related to some parameters 
in the TRE subfile, as reported in this thread: 
https://www.gpsrchive.com/Discussion/viewtopic.php?t=1571=6e0edd3239fb36f34c4b5d8df4f9f036



___
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

[Carlos Dávila]

Following are the results processing Portugal:


Size
osmupdate
split into o5m
split into pbf
mkgmap
portugal.o5m
713 MB
0:00:36
0:00:38
0:00:46
o5m: 0:01:25
portugal.pbf
410 MB
0:01:02
0:02:09
0:02:20
pbf: 0:01:27

With these figures the only reasonable option for me would be to output 
pbf from splitter to reduce disk I/O. Time penalty for the other steps 
is too high for me. Currently my server is working some 12 hours/day 
updating maps.


El 10/11/21 a las 22:59, Felix Hartmann escribió:
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 
mailto:car...@alternativaslibres.org>> 
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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von
Carlos Dávila mailto:car...@alternativaslibres.org>>
> Gesendet: Dienstag, 9. November 2021 22:54
> An: mkgmap-dev@lists.mkgmap.org.uk
<mailto: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
>>>> <https://files.mkgmap.org.uk/download/526/31191025.o5m
<https://files.mkgmap.org.uk/download/526/31191025.o5m>> 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

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

[Carlos Dávila]

I don't use Geofabrik extracts but my own ones. I keep country.o5m files 
that are updated with osmupdate as a first step for map updates.


El 10/11/21 a las 22:59, Felix Hartmann escribió:
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 
mailto:car...@alternativaslibres.org>> 
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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von
Carlos Dávila mailto:car...@alternativaslibres.org>>
> Gesendet: Dienstag, 9. November 2021 22:54
> An: mkgmap-dev@lists.mkgmap.org.uk
<mailto: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
>>>> <https://files.mkgmap.org.uk/download/526/31191025.o5m
<https://files.mkgmap.org.uk/download/526/31191025.o5m>> 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.ThreadPoolExec

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

[Carlos Dávila]

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
<https://files.mkgmap.org.uk/download/526/31191025.o5m> 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

[Carlos Dávila]

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 
<https://files.mkgmap.org.uk/download/526/31191025.o5m> 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

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

[Carlos Dávila]

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 
<https://files.mkgmap.org.uk/download/526/31191025.o5m> 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] New assertion, now with code-page=632 and Japan tile

[Carlos Dávila]

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

Re: [mkgmap-dev] Failure splitting USA

[Carlos Dávila]

I have realized the problem occurs since I updated my old version of 
splitter to r642. Currently splitting with r641, it has already passed 
the crashing point.


https://files.mkgmap.org.uk/download/525/densities-out.txt

El 4/11/21 a las 16:52, Gerd Petermann escribió:

Hi Carlos,

please try the branch version 
https://www.mkgmap.org.uk/download/splitter-solve-parallel-r641.zip
I never found the time to complete the work on this.
Would also be good to have the densities-out.txt file.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 4. November 2021 16:48
An: Development list for mkgmap
Betreff: [mkgmap-dev] Failure splitting USA

Since a couple of weeks or so I'm unable to split USA. I have tried with
my own extract and also with the one from Geofabrik
<https://download.geofabrik.de/north-america/us-latest.osm.pbf>.
Splitter crashes trying to find a nice split. I have tried different
--max-nodes values, from 40 to 180, with no success. Version
used is 642.

Exact map coverage read from input file(s) is
(15.920970439910889,-180.0) to (72.98844337463379,180.0)
Rounded map coverage is (15.908203125,-180.0) to (72.9931640625,180.0)
Splitting nodes into areas containing a maximum of 1,600,000 nodes each...
Highest node count in a single grid element is 423,372
Solving partition (15.908203125,-180.0) to (71.806640625,-9.5361328125)
with 1,036,376,610 nodes
Trying to find nice split for (15.908203125,-180.0) to
(71.806640625,-9.5361328125) with 1,036,376,610 nodes
searching for split with min-nodes 8, learned 0 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 13540 good partial
solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 18542 good partial
solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 21915 good partial
solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 26044 good partial
solutions
Elapsed time: 6m 0s   Memory: Current 2996MB (406MB used, 2590MB free)
Max 27648MB
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 38395 good partial
solutions
No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 83498 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 83595 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 84812 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 84886 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 84941 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 85011 good partial solutions
Still no good solution found, trying alternative algorithm
searching for split with min-nodes 8, learned 85011 good partial
solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 85012 good partial
solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 85020 good partial
solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 85020 good partial
solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 85494 good partial
solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 87541 good partial
solutions
No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 88954 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 88989 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 89006 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 90462 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 93165 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 94259 good partial solutions
Warning: No solution found for partition (15.908203125,-180.0) to
(71.806640625,-9.5361328125) with 1,036,376,610

[mkgmap-dev] Failure splitting USA

[Carlos Dávila]

Since a couple of weeks or so I'm unable to split USA. I have tried with 
my own extract and also with the one from Geofabrik 
. 
Splitter crashes trying to find a nice split. I have tried different 
--max-nodes values, from 40 to 180, with no success. Version 
used is 642.


Exact map coverage read from input file(s) is 
(15.920970439910889,-180.0) to (72.98844337463379,180.0)

Rounded map coverage is (15.908203125,-180.0) to (72.9931640625,180.0)
Splitting nodes into areas containing a maximum of 1,600,000 nodes each...
Highest node count in a single grid element is 423,372
Solving partition (15.908203125,-180.0) to (71.806640625,-9.5361328125) 
with 1,036,376,610 nodes
Trying to find nice split for (15.908203125,-180.0) to 
(71.806640625,-9.5361328125) with 1,036,376,610 nodes

searching for split with min-nodes 8, learned 0 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 13540 good partial 
solutions

No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 18542 good partial 
solutions

No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 21915 good partial 
solutions

No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 26044 good partial 
solutions
Elapsed time: 6m 0s   Memory: Current 2996MB (406MB used, 2590MB free) 
Max 27648MB

No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 38395 good partial 
solutions

No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 83498 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 83595 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 84812 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 84886 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 84941 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 85011 good partial solutions
Still no good solution found, trying alternative algorithm
searching for split with min-nodes 8, learned 85011 good partial 
solutions

No good solution found, duplicated search-limit to 40
searching for split with min-nodes 8, learned 85012 good partial 
solutions

No good solution found, duplicated search-limit to 80
searching for split with min-nodes 8, learned 85020 good partial 
solutions

No good solution found, duplicated search-limit to 160
searching for split with min-nodes 8, learned 85020 good partial 
solutions

No good solution found, duplicated search-limit to 320
searching for split with min-nodes 8, learned 85494 good partial 
solutions

No good solution found, duplicated search-limit to 640
searching for split with min-nodes 8, learned 87541 good partial 
solutions

No good solution found, trying to find one accepting anything
searching for split with min-nodes 1, learned 88954 good partial solutions
No good solution found, duplicated search-limit to 40
searching for split with min-nodes 1, learned 88989 good partial solutions
No good solution found, duplicated search-limit to 80
searching for split with min-nodes 1, learned 89006 good partial solutions
No good solution found, duplicated search-limit to 160
searching for split with min-nodes 1, learned 90462 good partial solutions
No good solution found, duplicated search-limit to 320
searching for split with min-nodes 1, learned 93165 good partial solutions
No good solution found, duplicated search-limit to 640
searching for split with min-nodes 1, learned 94259 good partial solutions
Warning: No solution found for partition (15.908203125,-180.0) to 
(71.806640625,-9.5361328125) with 1,036,376,610 nodes

uk.me.parabola.splitter.SplitFailedException: Failed to find a correct split
    at 
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:162)
    at 
uk.me.parabola.splitter.solver.SplittableDensityArea.split(SplittableDensityArea.java:211)
    at 
uk.me.parabola.splitter.solver.AreasCalculator.calcAreas(AreasCalculator.java:226)

    at uk.me.parabola.splitter.Main.split(Main.java:227)
    at uk.me.parabola.splitter.Main.start(Main.java:121)
    at uk.me.parabola.splitter.Main.main(Main.java:81)


___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk

Re: [mkgmap-dev] Commit r4809: fix java.lang.AssertionError while building index from unicode tiles

[Carlos Dávila]

The reason for using code-pages other than 65001 is that many Garmin 
devices fail to load non original unicode maps. See Felix explanation 
here: 
https://openmtbmap.org/download/odbl/#Compatibility_-_Unicode_vs_Non_Unicode_cannot_authenticate_maps


El 24/10/21 a las 18:14, Ticker Berkin escribió:

Hi Carlos

When mkgmap doesn't have a resources/sort for the given code page, it
defaults the sort to cp1252 (Western European).

As part of building the the various indexes, it sorts counties,
regions, cities, streets etc using this sort, but any characters that
don't have a defined sort order are ignored in the ordering. The result
of this is that, using cp1252 on Chinese, all names seem the same.

I suspect that indexes are mostly empty and find is ignoring them.

There is some logic that is differentiating the names in these
structures on exact naming, and this inconsistency causes the assertion
crash.

The actual output in the map image is cp836, which Basecamp and
Mapsource appear to handle. I don't know how well it is supported by
Garmin devices.

Is there a reason for using cp836 rather than cp65001/unicode?

Ticker

On Sun, 2021-10-24 at 16:22 +0200, Carlos Dávila wrote:

using copy from JOSM/paste into BaseCamp, I could test address
searches
and they seem to work.

El 23/10/21 a las 23:50, Ticker Berkin escribió:

Hi Carlos

mkgmap doesn't have a resources/sort for code-page 936 (Microsoft's
character encoding for simplified Chinese). I was surprised it
doesn't
give any warning about this. I'll look more closely tomorrow to see
what happens when it doesn't find the resource file.

I presume this didn't crash before, but did the index work?

I suspect this will have many of the same problems as unicode sort
had
for unspecified characters.

I'll also investigate the other change relating to collation
strength.

Ticker

On Sat, 2021-10-23 at 22:26 +0200, Carlos Dávila wrote:

Hi devs.

With this new version I get a new crash, but now with --code-
page=936,
not with unicode:

Exception in thread "main" java.lang.AssertionError: mdr20 value
changed
f=5174 t=5180 count=2995
   at
uk.me.parabola.imgfmt.app.mdr.Mdr5Record.setMdr20(Mdr5Record.java
:134
)
   at
uk.me.parabola.imgfmt.app.mdr.Mdr20.buildFromStreets(Mdr20.java:8
4)
   at
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:
335)
   at
uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:270)
   at
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.ja
va:3
31)
   at
uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
   at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReade
r.ja
va:126)
   at
uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:147)
   at uk.me.parabola.mkgmap.main.Main.main(Main.java:118)

mkgmap command: java -ea -jar mkgmap-r4809.jar --index
--bounds=bounds.zip --housenumbers --code-page=936 31177013.o5m

https://files.mkgmap.org.uk/download/524/31177013.o5m

El 22/10/21 a las 9:42, svn commit escribió:

Version mkgmap-r4809 was committed by gerd on Fri, 22 Oct 2021

fix java.lang.AssertionError while building index from unicode
tiles
mdrUnicode_v2.patch by Ticker Berkin

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4809
___
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] Commit r4809: fix java.lang.AssertionError while building index from unicode tiles

[Carlos Dávila]

As you thought, it didn't crash. I can't type Chinese characters, but 
using copy from JOSM/paste into BaseCamp, I could test address searches 
and they seem to work.


El 23/10/21 a las 23:50, Ticker Berkin escribió:

Hi Carlos

mkgmap doesn't have a resources/sort for code-page 936 (Microsoft's
character encoding for simplified Chinese). I was surprised it doesn't
give any warning about this. I'll look more closely tomorrow to see
what happens when it doesn't find the resource file.

I presume this didn't crash before, but did the index work?

I suspect this will have many of the same problems as unicode sort had
for unspecified characters.

I'll also investigate the other change relating to collation strength.

Ticker

On Sat, 2021-10-23 at 22:26 +0200, Carlos Dávila wrote:

Hi devs.

With this new version I get a new crash, but now with --code-
page=936,
not with unicode:

Exception in thread "main" java.lang.AssertionError: mdr20 value
changed
f=5174 t=5180 count=2995
  at
uk.me.parabola.imgfmt.app.mdr.Mdr5Record.setMdr20(Mdr5Record.java:134
)
  at
uk.me.parabola.imgfmt.app.mdr.Mdr20.buildFromStreets(Mdr20.java:84)
  at
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:335)
  at
uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:270)
  at
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:3
31)
  at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:690)
  at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja
va:126)
  at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:147)
  at uk.me.parabola.mkgmap.main.Main.main(Main.java:118)

mkgmap command: java -ea -jar mkgmap-r4809.jar --index
--bounds=bounds.zip --housenumbers --code-page=936 31177013.o5m

https://files.mkgmap.org.uk/download/524/31177013.o5m

El 22/10/21 a las 9:42, svn commit escribió:

Version mkgmap-r4809 was committed by gerd on Fri, 22 Oct 2021

fix java.lang.AssertionError while building index from unicode
tiles
mdrUnicode_v2.patch by Ticker Berkin

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4809
___
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] Commit r4809: fix java.lang.AssertionError while building index from unicode tiles

[Carlos Dávila]

Hi devs.

With this new version I get a new crash, but now with --code-page=936, 
not with unicode:


Exception in thread "main" java.lang.AssertionError: mdr20 value changed 
f=5174 t=5180 count=2995
    at 
uk.me.parabola.imgfmt.app.mdr.Mdr5Record.setMdr20(Mdr5Record.java:134)
    at 
uk.me.parabola.imgfmt.app.mdr.Mdr20.buildFromStreets(Mdr20.java:84)
    at 
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:335)

    at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:270)
    at 
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:331)

    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)

mkgmap command: java -ea -jar mkgmap-r4809.jar --index 
--bounds=bounds.zip --housenumbers --code-page=936 31177013.o5m


https://files.mkgmap.org.uk/download/524/31177013.o5m

El 22/10/21 a las 9:42, svn commit escribió:

Version mkgmap-r4809 was committed by gerd on Fri, 22 Oct 2021

fix java.lang.AssertionError while building index from unicode tiles
mdrUnicode_v2.patch by Ticker Berkin

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4809
___
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] java.lang.AssertionError while building index from unicode tiles

[Carlos Dávila]

In that case, it seems estrange that only 2 of 67 tiles of China map 
cause problems, doesn't it?


El 17/10/21 a las 12:16, Ticker Berkin escribió:

Hi

It is most likely that this problem is because Chinese requires 2 
UTF16 chars to encode many of its characters - see


https://softwareengineering.stackexchange.com/questions/102205/should-utf-16-be-considered-harmful 



I think it is only  --index processing where this is a problem mkgmap.

I'll investigate  more

Ticker



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


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

[mkgmap-dev] java.lang.AssertionError while building index from unicode tiles

[Carlos Dávila]

Hi all

I'm getting error below while building index from this tile: 
https://files.mkgmap.org.uk/download/523/31177029.o5m. Minimum mkgmap 
options triggering the error are: java -jar mkgmap-trunk.jar 
--bounds=bounds.zip --index --unicode 31177029.o5m


Another tile from the same splitter run also fails but all other 65 of 
67 build fine. With --code-page=936 they all build fine.


Command output:

Exception in thread "main" java.lang.AssertionError: 10586
    at 
uk.me.parabola.imgfmt.app.FileBackedImgFileWriter.putNu(FileBackedImgFileWriter.java:215)

    at uk.me.parabola.imgfmt.app.mdr.Mdr29.writeSectData(Mdr29.java:94)
    at 
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSection(MDRFile.java:424)
    at 
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:388)

    at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:270)
    at 
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:331)

    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)


___
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

[Carlos Dávila]

Hi Felix

Thank you very much for your hints.

I also vote for adding gmapi-minimal to trunk (v5 patch)

El 11/10/21 a las 12:01, Felix Hartmann escribió:
If it's only about nvme/SSD writes, then you could write to Ramdisk. I 
do this for all geofabrik extracts except Europe/Asia continent.
The above patches for not writing again gmap files that exist already 
are still important, as it saves on Ramdisk size and is faster as it 
is not needed.
Also make sure 7zip or whatever you use for packing uses Ramdisk for 
temporary files.


Note however, that this slows down the map compilation process Vs nvme 
drives. Ramdisk used much more CPU than nvme for reading/writing, 
while only being 2-4 times as fast (Vs Samsung 980 pro). As CPU time 
for me is more important than write/read speeds, using Ramdisk Vs nvme 
is slowing down map compilation time by around 5percent for me (using 
imdisk, dataram Ramdisk even 10 percent). I still do it to save nvme 
writes.


Actually I think the gmapi-minimal patch v4 could be pushed to trunk. 
It is working stable and not changing anything for those not using it. 
For me it results in the whole map compilation process being 10% 
faster, while also saving all excessive writes.
And while it's convenient to distribute gmapi maps to windows users, I 
think .img is far superior.

a) you cannot create gmapsupp.img with mkgmap/gmaptool from gmap files.
b) the performance in basecamp is slightly better for .img maps
c) exporting maps with mapinstall is faster for .img maps
it's still a mystery for me why garmin decided to use the gmap format 
on mac and now PC too. They could have just added the info.xml for 
.img files too (yes registry is the disadvantage to .img files)


distributing as as gmapsupp.img only is the slowest option for desktop 
use (needs to be converted first or read in painfully slow from 
external memory). gmaptool not available on mac osx anymore making 
this even worse




On Mon, 11 Oct 2021, 11:35 Gerd Petermann 
<mailto:gpetermann_muenc...@hotmail.com>> wrote:


Hi Carlos,

there is no way to omit the writing of *.img files so far. The
*.img files are used in the combiners.
So, mkgmap first creates the *.img files and then reads them again
to produce the index and *.tdb  and finally the other files.
I don't know how much work it would be to skip the writing of
.img. I also think that gmapsupp contains a collection of *.img
files, but maybe those could be created on the fly...

Gerd


Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von
    Carlos Dávila mailto:car...@alternativaslibres.org>>
Gesendet: Samstag, 9. Oktober 2021 11:17
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

Sorry, not sure what you mean by "simply update zipped files". I
create
new zip files in a temporary directory and then replace online old
ones.
Note some maps are several GB in size. If someone is downloading
such a
map while I'm writing it ,download while fail and user will have to
restart download, which may be annoying especially with low speed
connections. Writing new zip files in a different location and then
replacing downloadable files reduces the risk of the above problem.

If you could find the way to build working MapSource/BaseCamp maps and
also gmapsupp from tiles subfiles that would help me a lot reducing
required disk space, but I can manage it if not. I missed one of your
comments in a previous mail. I use nsis installer, but only to unzip
*.gmap folder, so really no need to write single *.img files provided
*.gmap and gmapsupp can be created from subfiles. By the way, is there
currently an option in mkgmap to omit single *.img creation?

El 8/10/21 a las 10:07, Gerd Petermann escribió:
> Hi Carlos,
>
> can't you simply update the zipped files?
>
> I've learned that I was wrong. There is no code yet in mkgmap to
process a single subfile, we have that only in display tool. I
guess it is simple enough to implement this, but I don't know that
part of the code very well.
>
> Gerd
>
> 
> Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von
Carlos Dávila mailto:car...@alternativaslibres.org>>
> Gesendet: Montag, 4. Oktober 2021 23:22
> 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'll try to explain my (current) workflow. For each map I
compile *.

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

[Carlos Dávila]

un...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>
 im Auftrag von Felix Hartmann 
mailto:extremecar...@gmail.com><mailto: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<mailto:extremecar...@gmail.com>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<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><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com>><mailto:extremecar...@gmail.com<mailto:extremecar...@gmail.com><mailto:extremecar...@gmail.com<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 
mailto:gpetermann_muenc...@hotmail.com><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>><mailto:gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com><mailto: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 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk><mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>>>
 im Auftrag von Carlos Dávila 
mailto:car...@alternativaslibres.org><mailto:car...@alternativaslibres.org<mailto:car...@alternativaslibres.org>><mailto:car...@alternativaslibres.org<mailto:car...@alternativaslibres.org><mailto: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><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk>><mailto:mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk><mailto: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)?

Gerd


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

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

[Carlos Dávila]

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 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 sm
  aller 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 
mailto: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 
mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im 
Auftrag von Felix Hartmann mailto:extremecar...@gmail.com>>
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 

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

[Carlos Dávila]

I share the same issue exposed by Felix, but not only for contour lines 
but also for DEM, which I have precompiled as *.img for many countries 
and just combine with the updated OSM tiles.


El 12/9/21 a las 19:10, Felix Hartmann escribió:
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
mailto: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 mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag
von Felix Hartmann mailto:extremecar...@gmail.com>>
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

Re: [mkgmap-dev] Deletion of unneeded hgt files

[Carlos Dávila]

No OSM data, only maritime admin boundary.

El 4/4/21 a las 11:26, Gerd Petermann escribió:

Hi Carlos,

reg. N64W180.hgt:
I've not recorded where I got my files from, but yes, it's a 3'' file and I got 
most of them from viewfinderpanoramas.
I'll triple check if OSM contains any data for this area or did you do this 
already?

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Sonntag, 4. April 2021 11:21
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Deletion of unneeded hgt files


El 3/4/21 a las 15:06, Gerd Petermann escribió:

Hi Carlos,

please double check:
I don't have files for N60E157, N72E057 and N77E083

Correct

I have a N64W180.hgt with a few non-zero values.

According to Google satellite imagery, this tile is all sea. Where did
you get it from? I can only find 3 arcsec tile from viewfinderpanoramas
for this tile, no 1 arcsec in VFP, SRTM or ALOS.

Results are in new patch.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 3. April 2021 13:27
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Deletion of unneeded hgt files

Regarding tiles covering Caspian Sea (N37E051 to N44E049), I thought
it's height would be 0, but if the real height is -29m then they should
not be removed from known-hgt.txt. But they are no longer available from
SRTM or ALOS.

The other tiles removed in my patch are in open sea areas, so their
height should be 0 and can be IMHO safely removed.

El 3/4/21 a las 10:04, Gerd Petermann escribió:

Hi Carlos,

not sure what to do with this. Seems your patch removes the files which are 
listed here:
https://www.opentopodata.org/notes/invalid-srtm-zips/

My SRTM directory contains the listed files and they show a constant height of 
-29m as stated in the linked page.

My understanding is that you don't have those files, but you should have. A 
non-existing file is treated like a file with height 0.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 3. April 2021 09:45
An: Development list for mkgmap
Betreff: [mkgmap-dev] Deletion of unneeded hgt files

Attached patch deletes some hgt files which correspond to ocean areas
from known-hgt.txt file. They just lead to confusing warnings when
running mkgmap to generate a map with DEM.

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

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

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

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


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

Re: [mkgmap-dev] Deletion of unneeded hgt files

[Carlos Dávila]

El 3/4/21 a las 15:06, Gerd Petermann escribió:

Hi Carlos,

please double check:
I don't have files for N60E157, N72E057 and N77E083

Correct

I have a N64W180.hgt with a few non-zero values.
According to Google satellite imagery, this tile is all sea. Where did 
you get it from? I can only find 3 arcsec tile from viewfinderpanoramas 
for this tile, no 1 arcsec in VFP, SRTM or ALOS.


Results are in new patch.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 3. April 2021 13:27
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Deletion of unneeded hgt files

Regarding tiles covering Caspian Sea (N37E051 to N44E049), I thought
it's height would be 0, but if the real height is -29m then they should
not be removed from known-hgt.txt. But they are no longer available from
SRTM or ALOS.

The other tiles removed in my patch are in open sea areas, so their
height should be 0 and can be IMHO safely removed.

El 3/4/21 a las 10:04, Gerd Petermann escribió:

Hi Carlos,

not sure what to do with this. Seems your patch removes the files which are 
listed here:
https://www.opentopodata.org/notes/invalid-srtm-zips/

My SRTM directory contains the listed files and they show a constant height of 
-29m as stated in the linked page.

My understanding is that you don't have those files, but you should have. A 
non-existing file is treated like a file with height 0.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 3. April 2021 09:45
An: Development list for mkgmap
Betreff: [mkgmap-dev] Deletion of unneeded hgt files

Attached patch deletes some hgt files which correspond to ocean areas
from known-hgt.txt file. They just lead to confusing warnings when
running mkgmap to generate a map with DEM.

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

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

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


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

Re: [mkgmap-dev] Deletion of unneeded hgt files

[Carlos Dávila]

Regarding tiles covering Caspian Sea (N37E051 to N44E049), I thought 
it's height would be 0, but if the real height is -29m then they should 
not be removed from known-hgt.txt. But they are no longer available from 
SRTM or ALOS.


The other tiles removed in my patch are in open sea areas, so their 
height should be 0 and can be IMHO safely removed.


El 3/4/21 a las 10:04, Gerd Petermann escribió:

Hi Carlos,

not sure what to do with this. Seems your patch removes the files which are 
listed here:
https://www.opentopodata.org/notes/invalid-srtm-zips/

My SRTM directory contains the listed files and they show a constant height of 
-29m as stated in the linked page.

My understanding is that you don't have those files, but you should have. A 
non-existing file is treated like a file with height 0.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 3. April 2021 09:45
An: Development list for mkgmap
Betreff: [mkgmap-dev] Deletion of unneeded hgt files

Attached patch deletes some hgt files which correspond to ocean areas
from known-hgt.txt file. They just lead to confusing warnings when
running mkgmap to generate a map with DEM.

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


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

Re: [mkgmap-dev] Deletion of unneeded hgt files

[Carlos Dávila]

Updated patch with typo

El 3/4/21 a las 9:45, Carlos Dávila escribió:
Attached patch deletes some hgt files which correspond to ocean areas 
from known-hgt.txt file. They just lead to confusing warnings when 
running mkgmap to generate a map with DEM.



___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: resources/known-hgt.txt
===
--- resources/known-hgt.txt	(revisión: 4605)
+++ resources/known-hgt.txt	(copia de trabajo)
@@ -1,4 +1,4 @@
-# HGT files (SRTM) is not avalaible for areas in the ocean.
+# HGT files (SRTM) are not avalaible for areas in the ocean.
 # This is a list of all hgt files
 # to compile it use 
 # java -cp mkgmap.jar uk.me.parabola.mkgmap.reader.hgt.HGTList compile known-hgt.txt   
@@ -5262,8 +5262,6 @@
 N37E048 
 N37E049 
 N37E050 
-N37E051 
-N37E052 
 N37E053 
 N37E054 
 N37E055 
@@ -5448,9 +5446,6 @@
 N38E047 
 N38E048 
 N38E049 
-N38E050 
-N38E051 
-N38E052 
 N38E053 
 N38E054 
 N38E055 
@@ -5632,8 +5627,6 @@
 N39E047 
 N39E048 
 N39E049 
-N39E050 
-N39E051 
 N39E052 
 N39E053 
 N39E054 
@@ -5822,7 +5815,6 @@
 N40E048 
 N40E049 
 N40E050 
-N40E051 
 N40E052 
 N40E053 
 N40E054 
@@ -6010,8 +6002,6 @@
 N41E047 
 N41E048 
 N41E049 
-N41E050 
-N41E051 
 N41E052 
 N41E053 
 N41E054 
@@ -6198,8 +6188,6 @@
 N42E046 
 N42E047 
 N42E048 
-N42E049 
-N42E050 
 N42E051 
 N42E052 
 N42E053 
@@ -6393,8 +6381,6 @@
 N43E045 
 N43E046 
 N43E047 
-N43E048 
-N43E049 
 N43E050 
 N43E051 
 N43E052 
@@ -6604,8 +6590,6 @@
 N44E045 
 N44E046 
 N44E047 
-N44E048 
-N44E049 
 N44E050 
 N44E051 
 N44E052 
@@ -10392,7 +10376,6 @@
 N60E154 
 N60E155 
 N60E156 
-N60E157 
 N60E159 
 N60E160 
 N60E161 
@@ -11669,7 +11652,6 @@
 N64W174 
 N64W175 
 N64W176 
-N64W180 
 N65E010 
 N65E011 
 N65E012 
@@ -13627,7 +13609,6 @@
 N72E054 
 N72E055 
 N72E056 
-N72E057 
 N72E068 
 N72E069 
 N72E070 
@@ -14403,7 +14384,6 @@
 N77E025 
 N77E067 
 N77E082 
-N77E083 
 N77E088 
 N77E089 
 N77E090 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Deletion of unneeded hgt files

[Carlos Dávila]

Attached patch deletes some hgt files which correspond to ocean areas 
from known-hgt.txt file. They just lead to confusing warnings when 
running mkgmap to generate a map with DEM.


Index: resources/known-hgt.txt
===
--- resources/known-hgt.txt	(revisión: 4605)
+++ resources/known-hgt.txt	(copia de trabajo)
@@ -5262,8 +5262,6 @@
 N37E048 
 N37E049 
 N37E050 
-N37E051 
-N37E052 
 N37E053 
 N37E054 
 N37E055 
@@ -5448,9 +5446,6 @@
 N38E047 
 N38E048 
 N38E049 
-N38E050 
-N38E051 
-N38E052 
 N38E053 
 N38E054 
 N38E055 
@@ -5632,8 +5627,6 @@
 N39E047 
 N39E048 
 N39E049 
-N39E050 
-N39E051 
 N39E052 
 N39E053 
 N39E054 
@@ -5822,7 +5815,6 @@
 N40E048 
 N40E049 
 N40E050 
-N40E051 
 N40E052 
 N40E053 
 N40E054 
@@ -6010,8 +6002,6 @@
 N41E047 
 N41E048 
 N41E049 
-N41E050 
-N41E051 
 N41E052 
 N41E053 
 N41E054 
@@ -6198,8 +6188,6 @@
 N42E046 
 N42E047 
 N42E048 
-N42E049 
-N42E050 
 N42E051 
 N42E052 
 N42E053 
@@ -6393,8 +6381,6 @@
 N43E045 
 N43E046 
 N43E047 
-N43E048 
-N43E049 
 N43E050 
 N43E051 
 N43E052 
@@ -6604,8 +6590,6 @@
 N44E045 
 N44E046 
 N44E047 
-N44E048 
-N44E049 
 N44E050 
 N44E051 
 N44E052 
@@ -10392,7 +10376,6 @@
 N60E154 
 N60E155 
 N60E156 
-N60E157 
 N60E159 
 N60E160 
 N60E161 
@@ -11669,7 +11652,6 @@
 N64W174 
 N64W175 
 N64W176 
-N64W180 
 N65E010 
 N65E011 
 N65E012 
@@ -13627,7 +13609,6 @@
 N72E054 
 N72E055 
 N72E056 
-N72E057 
 N72E068 
 N72E069 
 N72E070 
@@ -14403,7 +14384,6 @@
 N77E025 
 N77E067 
 N77E082 
-N77E083 
 N77E088 
 N77E089 
 N77E090 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Behavior of overview options

[Carlos Dávila]

I can't remember either why this was set as default. Attached is a patch 
that documents it.


El 31/3/21 a las 15:24, Gerd Petermann escribió:

Hi Carlos,

the tricky part here is that -tdbfile is enabled by default. I don't remember 
why this was done, and I don't know why it is not documented, but you can use 
--no-tdbfile to overwrite the default.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Mittwoch, 31. März 2021 15:18
An: Development list for mkgmap
Betreff: [mkgmap-dev] Behavior of overview options

According to options file,  --overview-mapname and --overview-mapnumber
parameters should only have an effect "If --tdbfile is enabled...", but
they seem to be always taken into account regardless of --tdbfile, as
can be checked with command: java -jar mkgmap.jar --gmapsupp
--overview-mapname=test --overview-mapnumber=001 test.osm

Additionally, overview files (osmmap.img, osmmap.tdb and ovm_XXX.img)
are created when only --gmapsupp is passed to mkgmap (no --tdb-file), as
in the command below:

java -jar mkgmap.jar --gmapsupp test.osm

I think if you just want to create a gmapsupp file, overview files are
not needed at all and they should not be created.




___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: resources/help/en/options
===
--- resources/help/en/options	(revisión: 4605)
+++ resources/help/en/options	(copia de trabajo)
@@ -312,11 +312,11 @@
 === Overview map options ===
 
 --overview-mapname=name
-If --tdbfile is enabled, this gives the name of the overview .img and .tdb
+If --tdbfile is enabled (default), this gives the name of the overview .img and .tdb
 files. The default map name is osmmap.
 
 --overview-mapnumber=8 digit number
-If --tdbfile is enabled, this gives the internal 8 digit number used in the
+If --tdbfile is enabled (default), this gives the internal 8 digit number used in the
 overview map and tdb file. The default number is 6324.
 
 --overview-levels=level:resolution[,level:resolution...]
@@ -920,8 +920,9 @@
 "(?i)fix[ _]?+me".
 
 --tdbfile
-Write files that are essential to running with BaseCamp; a .tdb file and an
-overview map. The options --nsis and --gmapi imply --tdbfile.
+Write files that are essential to running with BaseCamp: a .tdb file and an
+overview map. This option is enabled by default; additionally, options 
+--nsis and --gmapi imply --tdbfile.
 
 --show-profiles=1
 Sets a flag in the tdb file. The meaning depends on the availability of DEM
Index: doc/options.txt
===
--- doc/options.txt	(revisión: 4605)
+++ doc/options.txt	(copia de trabajo)
@@ -316,11 +316,11 @@
 === Overview map options ===
 
 ;--overview-mapname=name
-: 	If --tdbfile is enabled, this gives the name of the overview
+: 	If --tdbfile is enabled (default), this gives the name of the overview
 .img and .tdb files. The default map name is osmmap.
 
 ;--overview-mapnumber=8 digit number
-: 	If --tdbfile is enabled, this gives the internal 8 digit
+: 	If --tdbfile is enabled (default), this gives the internal 8 digit
 number used in the overview map and tdb file.  The default
 number is 6324.
 
@@ -936,8 +936,9 @@
 : 	Ignore all tags for which the value matches the regular expression pattern "(?i)fix[ _]?+me".	
 
 ;--tdbfile
-: 	Write files that are essential to running with BaseCamp; a .tdb file and
-an overview map. The options --nsis and --gmapi imply --tdbfile.
+: 	Write files that are essential to running with BaseCamp: a .tdb file and
+an overview map. This option is enabled by default; additionally, options --nsis and 
+--gmapi imply --tdbfile.
 
 ;--show-profiles=1
 : 	Sets a flag in the tdb file. The meaning depends on the availability of DEM
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Behavior of overview options

[Carlos Dávila]

According to options file,  --overview-mapname and --overview-mapnumber 
parameters should only have an effect "If --tdbfile is enabled...", but 
they seem to be always taken into account regardless of --tdbfile, as 
can be checked with command: java -jar mkgmap.jar --gmapsupp 
--overview-mapname=test --overview-mapnumber=001 test.osm


Additionally, overview files (osmmap.img, osmmap.tdb and ovm_XXX.img) 
are created when only --gmapsupp is passed to mkgmap (no --tdb-file), as 
in the command below:


java -jar mkgmap.jar --gmapsupp test.osm

I think if you just want to create a gmapsupp file, overview files are 
not needed at all and they should not be created.





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

Re: [mkgmap-dev] Error writing overviewmap - continue at failure

[Carlos Dávila]

Don't you have sea in your map? If yes, what do you need coastline for?

El 28/2/21 a las 17:47, Mike Baggaley escribió:

I have coastline in my overview of the UK down to the lowest level. At the 
lowest level, my overview contains just coastline, country boundaries, major 
cities and motorways. For an island, I would suggest the coastline is the most 
important thing to have in the overview.

Cheers,
Mike

-Original Message-
From: Ticker Berkin [mailto:rwb-mkg...@jagit.co.uk]
Sent: 28 February 2021 10:51
To: Development list for mkgmap 
Subject: Re: [mkgmap-dev] Error writing overviewmap - continue at failure

Hi

The default style has 5 levels of overview map! This seems excessive.
I'd have thought 2 or 3 would be acceptable and save a lot of space

The only contents is larger and larger cities, fast trunk roads and
motorways, some boundaries, sea and, at 3 of the 5 levels, coastline.

I don't think coastline adds anything useful to a typical map,
certainly not an overview, so dropping this would save space.

Ticker




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

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

Re: [mkgmap-dev] internal error: found no housenumber road

[Carlos Dávila]

Thanks for investigating it. I've been using those two rules for several 
years, it's strange the problem didn't arise till now.


El 26/2/21 a las 15:36, Gerd Petermann escribió:

Hi Carlos,


I didn't find a fix for the problem so far. I see what's going wrong but not 
why it only happens in this special situation.
Your points file contains these two rules:
highway=traffic_signals { add mkgmap:road-speed = '-1'; add 
mkgmap:road-speed-min = '1' }
highway=crossing { add mkgmap:road-speed = '-1'; add mkgmap:road-speed-min = 
'1' }

When I copy them to the default style I see the same error. Because of the 
extra rules and --link-poi-to-ways the OSM way 573320541 is split into smaller 
parts and somehow mkgmap fails to find the right part for the numbers generated 
by the addr:interpolation way.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Freitag, 26. Februar 2021 08:00
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] internal error: found no housenumber road

Hi Carlos,

OK, I can now reproduce with
java -Xmx4G -ea -jar d:\mkgmap\dist\mkgmap.jar --route --housenumbers  
--link-pois-to-ways  --style-option=language=non_latin --style-file=..\mio 
51690125.o5m

Also with a smaller extract. It seems your style in combination with 
--link-pois-to-ways triggers this...

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 25. Februar 2021 23:06
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] internal error: found no housenumber road

Removing --road-name-config didn't fix the problem. Error can be
reproduced with command:

java -Xmx27G -ea -jar mkgmap.jar -c opciones_comunes -c opciones_teselas
--latin1 --family-id=51169 --overview-mapname=OCE1169
--overview-mapnumber=51169000 --name-tag-list=int_name,name:en,name
--report-similar-arcs --report-dead-ends=2 --drive-on=detect,right
--check-roundabouts --check-roundabout-flares --license-file=license_OSM
--copyright-file=copyright  --style-option=language=non_latin
--style=mio 51690125.o5m

You can get all (I hope) needed files at
https://alternativaslibres.org/tmp/no_housenumber.zip

El 25/2/21 a las 22:34, Carlos Dávila escribió:

According to your comment, I think it may be caused by the line below
passed by  --road-name-config parameter. Testing now...

suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", "
Gate", " Grove", " Lane", " Mews", " Parade", " Place", " Road", "
Square", " Street", " Terrace", " View", " Way"


El 25/2/21 a las 20:53, Gerd Petermann escribió:

Hi Carlos,

I cannot reproduce this with the default style. The error message
means that mkgmap found a matching road at some time and later it
didn't. This should not happen, but maybe it depends on the style or
other options. I downloaded the small area and tried with
java -jar dist\mkgmap.jar --bounds=bounds.zip --route --housenumbers
--index d:\OSM\addr-inter.osm

Please let me know how to reproduce.

Gerd



Von: mkgmap-dev  im Auftrag
von Carlos Dávila 
Gesendet: Donnerstag, 25. Februar 2021 20:33
An: Development list for mkgmap
Betreff: [mkgmap-dev] internal error: found no housenumber road

While processing Australia I get several warnings of the form:

SEVERE (HousenumberGenerator): 51690125.o5m: internal error: found no
housenumber road for interpolated house
http://www.openstreetmap.org/?mlat=-37.782001=144.959382=17

Looking at that area in JOSM, I see addr:interpolation lines next to a
footway without a name, connecting houses with addr:street=Royal Parede,
and a primary road named Royal Parede some 20 m away from the
addr:interpolation lines. I guess mkgmap searches for street name in the
footway (which doesn't have a name) instead of in the Royal Parade road,
and thus it fails to assign housenumbers.

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

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

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

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

Re: [mkgmap-dev] internal error: found no housenumber road

[Carlos Dávila]

Removing --road-name-config didn't fix the problem. Error can be 
reproduced with command:


java -Xmx27G -ea -jar mkgmap.jar -c opciones_comunes -c opciones_teselas 
--latin1 --family-id=51169 --overview-mapname=OCE1169 
--overview-mapnumber=51169000 --name-tag-list=int_name,name:en,name 
--report-similar-arcs --report-dead-ends=2 --drive-on=detect,right 
--check-roundabouts --check-roundabout-flares --license-file=license_OSM 
--copyright-file=copyright  --style-option=language=non_latin 
--style=mio 51690125.o5m


You can get all (I hope) needed files at 
https://alternativaslibres.org/tmp/no_housenumber.zip


El 25/2/21 a las 22:34, Carlos Dávila escribió:
According to your comment, I think it may be caused by the line below 
passed by  --road-name-config parameter. Testing now...


suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", " 
Gate", " Grove", " Lane", " Mews", " Parade", " Place", " Road", " 
Square", " Street", " Terrace", " View", " Way"



El 25/2/21 a las 20:53, Gerd Petermann escribió:

Hi Carlos,

I cannot reproduce this with the default style. The error message 
means that mkgmap found a matching road at some time and later it 
didn't. This should not happen, but maybe it depends on the style or 
other options. I downloaded the small area and tried with
java -jar dist\mkgmap.jar --bounds=bounds.zip --route --housenumbers 
--index d:\OSM\addr-inter.osm


Please let me know how to reproduce.

Gerd



Von: mkgmap-dev  im Auftrag 
von Carlos Dávila 

Gesendet: Donnerstag, 25. Februar 2021 20:33
An: Development list for mkgmap
Betreff: [mkgmap-dev] internal error: found no housenumber road

While processing Australia I get several warnings of the form:

SEVERE (HousenumberGenerator): 51690125.o5m: internal error: found no
housenumber road for interpolated house
http://www.openstreetmap.org/?mlat=-37.782001=144.959382=17

Looking at that area in JOSM, I see addr:interpolation lines next to a
footway without a name, connecting houses with addr:street=Royal Parede,
and a primary road named Royal Parede some 20 m away from the
addr:interpolation lines. I guess mkgmap searches for street name in the
footway (which doesn't have a name) instead of in the Royal Parade road,
and thus it fails to assign housenumbers.

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

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

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

Re: [mkgmap-dev] internal error: found no housenumber road

[Carlos Dávila]

According to your comment, I think it may be caused by the line below 
passed by  --road-name-config parameter. Testing now...


suffix:en = " Avenue", " Close", " Court", " Crescent", " Drive", " 
Gate", " Grove", " Lane", " Mews", " Parade", " Place", " Road", " 
Square", " Street", " Terrace", " View", " Way"



El 25/2/21 a las 20:53, Gerd Petermann escribió:

Hi Carlos,

I cannot reproduce this with the default style. The error message means that 
mkgmap found a matching road at some time and later it didn't. This should not 
happen, but maybe it depends on the style or other options. I downloaded the 
small area and tried with
java -jar dist\mkgmap.jar --bounds=bounds.zip --route --housenumbers --index 
d:\OSM\addr-inter.osm

Please let me know how to reproduce.

Gerd



Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 25. Februar 2021 20:33
An: Development list for mkgmap
Betreff: [mkgmap-dev] internal error: found no housenumber road

While processing Australia I get several warnings of the form:

SEVERE (HousenumberGenerator): 51690125.o5m: internal error: found no
housenumber road for interpolated house
http://www.openstreetmap.org/?mlat=-37.782001=144.959382=17

Looking at that area in JOSM, I see addr:interpolation lines next to a
footway without a name, connecting houses with addr:street=Royal Parede,
and a primary road named Royal Parede some 20 m away from the
addr:interpolation lines. I guess mkgmap searches for street name in the
footway (which doesn't have a name) instead of in the Royal Parade road,
and thus it fails to assign housenumbers.

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

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

[mkgmap-dev] internal error: found no housenumber road

[Carlos Dávila]

While processing Australia I get several warnings of the form:

SEVERE (HousenumberGenerator): 51690125.o5m: internal error: found no 
housenumber road for interpolated house 
http://www.openstreetmap.org/?mlat=-37.782001=144.959382=17


Looking at that area in JOSM, I see addr:interpolation lines next to a 
footway without a name, connecting houses with addr:street=Royal Parede, 
and a primary road named Royal Parede some 20 m away from the 
addr:interpolation lines. I guess mkgmap searches for street name in the 
footway (which doesn't have a name) instead of in the Royal Parade road, 
and thus it fails to assign housenumbers.


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

Re: [mkgmap-dev] Pending changes

[Carlos Dávila]

HI all

I agree with Ticker default style is a good source of ideas for both new 
and experienced users (at least it is to me) and as such, more is 
better, but I also see Gerd's point about new users getting blocked by 
too many or complicated rules. I think comments about those complicated 
rules, as Ticker adds in some cases, may help circumvent that problem, 
or may be some kind of  tagging.


El 17/2/21 a las 11:02, Gerd Petermann escribió:

Hi Ticker,

I agree that the default style is a starting point and because of that I think "less 
is better":
1) The more stuff we put into the default style the less likely it becomes that 
a newbe will try to understand it. I think it is more likely that users will 
try to add a rule for something that they miss instead of working through 
hundredts of complicated rules to find out what can be (hast to be) removed 
without risking to loose anything important.
2) The screens of many (most?) Garmin devices are too small for lots of 
details, the details are simply confusing anyone who's not interested in OSM 
but just wants a routable map for free.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker Berkin 

Gesendet: Mittwoch, 17. Februar 2021 10:47
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Pending changes

Hi Gerd

My views on this.

For most of mkgmap /resources/ (styles, typ-files, documentation,
roadNameConfig.txt, sample.cfg) you don't need to decide if the change
is good or bad, and, almost by definition, it is all cosmetic.

Change requests go through this forum for discussion. After any
refinements necessary, the changes can be incorporated into trunk. It
is very unlikely that this will cause Map generation will become
'broken'. Mostly, it seems, no one much cares because they use their
own styles, TYP files etc.

I view the default style (and the other resources) as a starting point
for new users and a source of ideas for existing users.

It is the ideal place to put rules/comments on any sort of issue that
can be addressed by a style. Generally, more is better; it is easy for
a new user to start with lots and gradually comment out elements they
don't want.

Whenever I notice something that could be improved on my maps, or a
good idea floating around the forum, I incorporated it into my files
and try it. Every now and again, I try to get what I consider
improvements into mkgmap. This isn't for my benefit but, I hope, other
people might benefit from it.

Similarly, mapnik.txt is a good place to put element translations (it
would be nice if we came up with a mechanism where this translation
effort could be shared by any TYP file).

The core/java code is a different matter and I'm very grateful for your
amazing work on "keeping it all together"

Ticker

On Fri, 2021-02-12 at 09:51 +, Gerd Petermann wrote:

Hi all,

I have no idea what to do with patches for default style or typ
files. I can decide if I like a patch when I understand what's wrong
with the unpatched version, but I don't want to spent my time on
cosmetic changes. I simply don't know how to decide if a patch is
good or bad unless someone has a good example that shows a problem
with the unpatched version (only one problem if possible).

I see two ways to handle this:
1) Steve gives Ticker and /or Joris the right to commit changes to
trunk or
2) Ticker and Joris create their own branch(es), either in the mkgmap
svn repo or somewhere else.

ciao,
Gerd



Von: mkgmap-dev  im Auftrag
von Ticker Berkin 
Gesendet: Freitag, 12. Februar 2021 10:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Pending changes

Hi Carlos

Some bridges are a bit of a strange case. There are a lot of areas
where I walk that are crossed by many small streams and no formal
paths, but, here and there, there are foot bridges over the streams.
These are normally mapped as [highway=path/footway, bridge=yes] and
mostly don't connect to anything, but sometime to another bridge or a
short section of unconnecting path.

I want to see these on the map, but the little bits of highway will
just cause a routing error if they are picked up as the start or end
of
a route; hence my changes.

The only problem I see is if the bridge/highway is connected to the
highway network at one end only and you want to generate a route with
the start or end your of your journey the other side of bridge, then
the routing algo might find another, closer start/end point.

I could change it to be just 'set_unconnected_type' but I considered
the benefits and frequency of fixing paired isolated highway bits
outweighed an incorrect start/end point, which can be overcome by
simply starting the journey in the sensible way and the device will
recalculate or looking at the end-point route and, seeing it is
stupid,
choosing a better end-point.

Ticker

On Thu, 2021-02-11 at 18:05 +0100, Carlos Dávila wrote:

Regarding your extra 

Re: [mkgmap-dev] Pending changes

[Carlos Dávila]

Regarding your extra comment on #3, would it be really the case for 
bridges? What about any connected highway=* + bridge=yes?


No objection for new additional changes

El 11/2/21 a las 15:57, Ticker Berkin escribió:

Hi all

I've re-made this set of changes, along with a few improvements that
I've gathered over the last 6 months. Following list numbering is the
same as original patch, but include some [extra] notes + new items at
the end.

Relevant threads:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html

1/ Sometimes charges for using a pedestrian highway are expressed as a
fee rather than a toll, so pick this up in mkgmap:toll.

2/ Show bridges using type 0x10107. With the mapnik addition, these
look good for narrow highways, but might not show for wide
representations like motorways.

3/ Where it is likely that bits of highway might not be connected to
the road/path system, use mkgmap:set_unconnected_type and
mkgmap:set_semi_connected_type to stop the NET/NOD rather than relying
on NETnoNOD (now disabled) and --check-routing-island-len=+ve, which is
being suspected of causing problems on some devices and BaseCamp.

[extra] In all cases where unconnected/semi-connected changes are
mentioned, this only applies to lines not derived from an original/OSM
standard highway.

4/ Quote some filter subst strings that contain spaces - no actual
effect but clearer and safer.

5/ Have line for leisure=track even if area.

6/ Change the type for tracks/raceways etc from 0x30, which doesn't
show on BaseCamp or MapSource, to 0x2a.

7/ For piers, if 'unconnecting', use marine type 0x1040c (Obstruction:
Pier or Jetty) instead of footway.

8/ Change type for the various barriers from 0x17, which doesn't show
on BaseCamp to 0x2b, see:
http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html

9/ Consider natural=cliff a barrier.

10/ Add motorway[_link] roundabouts (yes, some do exist).

11/ Unquote some numbers - no actual effect.

12/ Tweak some road speeds.
[extra] A few more tweaked.

13/ Use 0x09 (high-speed ramp) for road class 4 links

14/ Add footway around car parks if 'connecting'.
[extra] This change is disabled.

15/ Disable coastline. For a long time the tag was suppressed by the
Sea processing and it adds little to the map.

16/ Improve railway platform names and suppress footway if not
'connecting'.

17/ Show disused:railway in the same way as railway=disused.

18/ Have cable_car, gondola, funicular as routable, by default with a
toll and pedestrian only.

19/ Show "Course of old Railway", unless a highway has taken over the
way (for you Eric, but I like it as well).
[extra] This change is disabled

20/ Speed up car ferries.

21/ A few other layout/space fixes.

Additional changes:

22/ motorroad=yes just sets mkgmap:fast_road, which generally increases
the speed/class of the highway and decreases the resolution

23/ natural=landslide like other barriers (eg cliff)

24/ Don't generate (routable) line for highway=unclassified & area=yes;
there are many instances in OSM where this is used to draw a polygon
around a complex junction.

25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)

26/ For ferry/platform/aerialway, blank out address fields to prevent
it getting into the Address index

27/ Add comment about colour pallet to mapnik.txt

Patch attached

Ticker

On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:

On [1] Ticker proposed a set of changes to default style lines file.
There was a long discussion about point #14, which ended without a
consensus. Other changes didn't get any objection, but they didn't
get
into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7
and 16, but for unconnected ways only, see #3.

2: more codes could be added for wider highways and their
corresponding
entries in mapnik.txt

3: not sure about this one, specially about semi-connected ways,
which I
think should remain as routable (also applies for 7, 16).

[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html

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

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

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

[mkgmap-dev] Pending changes

[Carlos Dávila]

On [1] Ticker proposed a set of changes to default style lines file. 
There was a long discussion about point #14, which ended without a 
consensus. Other changes didn't get any objection, but they didn't get 
into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also with 7 
and 16, but for unconnected ways only, see #3.


2: more codes could be added for wider highways and their corresponding 
entries in mapnik.txt


3: not sure about this one, specially about semi-connected ways, which I 
think should remain as routable (also applies for 7, 16).


[1] http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html

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

Re: [mkgmap-dev] Splitter download broken

[Carlos Dávila]

You can update it with the attached (minor) patch

El 1/2/21 a las 22:24, Steve Ratcliffe escribió:

Hi


Download for splitter r597 (and all older versions) is broken.
Please check.


Thanks for reporting, I have rebuild the latest release.

It was removed because it is over a year old!

Best wishes
Steve
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Index: src/uk/me/parabola/splitter/ProblemLists.java
===
--- src/uk/me/parabola/splitter/ProblemLists.java	(revisión: 592)
+++ src/uk/me/parabola/splitter/ProblemLists.java	(copia de trabajo)
@@ -53,7 +53,7 @@
 		long startProblemListGenerator = System.currentTimeMillis();
 		ArrayList distinctAreas = getNonOverlappingAreas(realAreas);
 		if (distinctAreas.size() > realAreas.size()) {
-			System.err.println("Waring: The areas given in --split-file are overlapping.");
+			System.err.println("Warning: The areas given in --split-file are overlapping.");
 			Set overlappingTiles = new TreeSet<>();
 			for (int i = 0; i < realAreas.size(); i++) {
 Area a1 = realAreas.get(i);
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

I have compiled Australia with mkgmap r4600, with dem and without 
--no-order-by-decreasing-area at the end of command line and all tiles 
seem to display correctly. Overview size is 4.5 GB. What size is 
expected to cause trouble?


El 24/1/21 a las 8:59, Gerd Petermann escribió:

Hi Ticker,

my concern was not about the number of additional bytes on the disk, but the 
size limits in IMG format. Anyway, since nobody else commented we probably only 
find out when someone hits that limit, so I've committed the patch (first v5, 
than changes from v6, sorry for that) with  r4599.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker Berkin 

Gesendet: Samstag, 23. Januar 2021 19:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

Hi Gerd

Given that the overview map is for use on computers with 100s of G of
disk space and the main map will be a G or so, can an extra few 10K or
so in the overview map really be a problem for anyone?

Building British-and-ireland, with default style and just --gmapsupp
(ie no index or routing) gmapsupp.img is 542M and osmmap.img is 220k.
With --order-by-decreasing-area they increase to 603M (11.3%) and 228k
(3.6%).

With routing, indexing, code page 1252 and other typical options,
gmapsupp.imp might be double the size and so the percentage increase
would be a lot less but not significantly different for osmmap.img.

Ticker

On Sat, 2021-01-23 at 11:29 +, Gerd Petermann wrote:

Hi Ticker,

outch, sorry! It seems I created my patch without any testing :(
I'm still not happy with the handling of the --order-by-decreasing
-area option. I wonder why nobody else comments on this. Either
nobody cares about the size of the overview map or nobody else tried
any of the patches. Since this is a major change I hoped for more
feedback.

Gerd

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

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

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

I'm sorry for not giving feedback. I'll try to test updated mkgmap in 
the following days and report any issue. I suppose best way to detect 
overview map size problems is processing a big map, such as Europe or Asia.


El 24/1/21 a las 8:59, Gerd Petermann escribió:

Hi Ticker,

my concern was not about the number of additional bytes on the disk, but the 
size limits in IMG format. Anyway, since nobody else commented we probably only 
find out when someone hits that limit, so I've committed the patch (first v5, 
than changes from v6, sorry for that) with  r4599.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker Berkin 

Gesendet: Samstag, 23. Januar 2021 19:54
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

Hi Gerd

Given that the overview map is for use on computers with 100s of G of
disk space and the main map will be a G or so, can an extra few 10K or
so in the overview map really be a problem for anyone?

Building British-and-ireland, with default style and just --gmapsupp
(ie no index or routing) gmapsupp.img is 542M and osmmap.img is 220k.
With --order-by-decreasing-area they increase to 603M (11.3%) and 228k
(3.6%).

With routing, indexing, code page 1252 and other typical options,
gmapsupp.imp might be double the size and so the percentage increase
would be a lot less but not significantly different for osmmap.img.

Ticker

On Sat, 2021-01-23 at 11:29 +, Gerd Petermann wrote:

Hi Ticker,

outch, sorry! It seems I created my patch without any testing :(
I'm still not happy with the handling of the --order-by-decreasing
-area option. I wonder why nobody else comments on this. Either
nobody cares about the size of the overview map or nobody else tried
any of the patches. Since this is a major change I hoped for more
feedback.

Gerd

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

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

Re: [mkgmap-dev] Garmin Topo Europe map

[Carlos Dávila]

If you want the accuracy of resolution 24, you need resolution 24. But 
you can remove any undesired element from the style used to generate 
your map.


El 28/12/20 a las 19:21, Pierre Brico escribió:


Yes:
- there is no building anymore
- address search is still working

Is it possible to restore the accuracy of resolution 24 while keeping 
other parameters identical (I mean no building, no POI, ...)?




On Mon, Dec 28, 2020 at 5:20 PM Gerd Petermann 
> wrote:


Hi Pierre,

yes, it is possible and expected. Resolution 23 means a raster of
~4.8 m. I assume the Garmin map contains no buildings. Does it
allow address search?

Gerd



Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von
Pierre Brico mailto:pierre.br...@gmail.com>>
Gesendet: Montag, 28. Dezember 2020 17:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Garmin Topo Europe map

Hi Gerd, Karl,

Thanks for your interesting information.

@Gerd,
I've tried to generate a map with a resolution of 23. During the
processing, I've received a lot of messages like "SEVERE
(TypeReader): 63430028.osm.pbf: Type 0x07 min-res:24 will not be
written with level 0 at resolution 23 in style file lines, line
215 -> routing may not work".
This was due to some rules in the "lines" file of the default
style. I modified them from "resolution 24" to "resolution 23" as
my goal was to keep all ways and to obtain a routable map. The
issue was solved.
Looking at the result, I can see that details (useless for me like
buildings, POI, ...) have disappeared and the map size is now
142MB instead of 242MB for Belgium. Excellent !!
The strange thing is that the result seems less accurate. It looks
like some nodes have been removed. For example, a roundabout is
drawn as a triangle. Is it possible?


@Karl,
Here is a description of the TopoActive map (West part):
TopoActive Europe 2020.20 South West 2.92 GB (3,139,764,224 bytes)
Andorra, Belgium, France, Iceland, Ireland, Italy, Liechtenstein,
Luxembourg, Malta, Monaco, Netherlands, Portugal, San Marino,
Spain, Switzerland, United Kingdom, Vatican City, Albania, Bosnia
and Herzegovina, Croatia, Greece, Kosovo , Macedonia, Montenegro,
Serbia, Slovenia
If I take all these countries in Geofabrik, the total size is
10,4GB. So the ratio is 3.56. From my example of Belgium above,
the ratio was 2.8 but I need to examine what can still be removed
to gain some more space.
Anyway, I'm interested in your 'optimized' style.

Thanks again,
Pierre


On Sun, Dec 27, 2020 at 9:00 PM 7770 <7...@foskan.eu
>> wrote:
Hi.
A few observations about the TopoActive europe map. (i have it on
a GPSMAP
66st).

The map is rendered slower than most custom made maps.
Updates occur 2 times per year, but even at those times many
changes to OSM
are not present. Perhaps they only update some parts yearly.
Points lack all kind of additional information which other mappers add
(opening hours, region, phone numbers, etc.).
One nice thing is colour marked national parks and reserves.
Being an outdoor map, it lacks some information about shelters in the
wilderness.
Routing is possible only for outdoor activities (cycle, walk,
hike, direct),
automotive routing (car, motorcycle) is disabled.

I have tried creating a minimal style. This lowers the data to
about 75 % or
my normal set up. But i did not change the level, which i will try :-)
Currently I am no way near the compression which TopoActive achieves.
Using input data which is about 6,7 GB in pbf format, creates a
gmapsupp just
below 4 GB for normal and around 3 GB for minimal style. These
numbers feels
similar to getting France into 1.9 GB from 3.7 GB pbf (geofabrik).


The minimal set up is not very fancy at all, it disables things
not wanted.
Buildings, shops, most of parkings, and a bit more.

Today i cannot send off any style, but in case that would be of
interest let me
know and i can share it in a few days (guessing Wednesday or
Thursday).


Regards
Karl

On söndag 27 december 2020 kl. 20:08:10 CET Gerd Petermann wrote:
> Hi Pierre,
>
> my first guess would be that the level 0 is at resolution 23
instead of 24.
>
> Gerd
>
> 
> Von: mkgmap-dev mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>>> im Auftrag von
> Pierre Brico mailto:pierre.br...@gmail.com>>> Gesendet: 

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

El 27/12/20 a las 19:13, Gerd Petermann escribió:

Hi Carlos,

most of the options can be prefixed with no- since many years.

I didn't remember that

Just to make sure: My suggestion was to keep --order-by-decreasing-area for the 
tiles and add --no-order-by-decreasing-area at the end for the combiners, esp. 
the overview map.

I had understood. I built Australia map that way and worked fine, thanks.


Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Sonntag, 27. Dezember 2020 19:07
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

I had removed --order-by-decreasing-area from my command for DEM maps,
but --no-order-by-decreasing-area seems to fix the problem by now. By
the way, this option is not documented in options file and I can't find
it in the code. Is --no a general switch for all options or is it a
particular case for order-by-decreasing-area? I don't remember having
seen it before.

El 27/12/20 a las 10:36, Gerd Petermann escribió:

Hi Carlos,

I agree that --order-by-decreasing-area is to blame. This option seems to 
disturb the calculation of the overview map, and maybe the extreme size of the 
tile plays another role here.

I hope Ticker can help here, I think the option supresses the merging of 
shapes, and this is probably not a good idea for the 0x4a shapes.

As a work-around for you:
Add option --no-order-by-decreasing-area at the end(!) of the parameter list so 
that the overview map is created without this option. This seems to fix the 
problem on my machine.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Sonntag, 27. Dezember 2020 09:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

Hi Carlos,

reg. the routing data: You can run display tool to check yourself, but the 
error is either in mkgmap or in display tool. My command looks like this :
java -ea -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar 
test.check.NodCheck  -vv --tab-zero=0 51145001.img > nodcheck.51145001.img 2> 
crash_nod
It would be easier if you would post a link to your style.

I am now able to reproduce the display error using this command
java -Xmx6G -ea -jar d:\mkgmap\dist\mkgmap.jar --dem=f:\srtm3 
--dem-poly=e:\carlos\australia.poly  --overview-dem-dist=276160 --gmapi --show-profiles=1 
--bounds=f:\osm\bounds.zip --precomp-sea=f:\osm\sea.zip --route --reduce-point-density=4 
--polygon-size-limits="24:12, 18:10, 16:0" --order-by-decreasing-area 
--location-autofill=is_in,nearest --drive-on=detect,left 
--road-name-config=d:\mkgmap\resources\roadNameConfig.txt  e:\carlos\51145001.o5m

and the overview map has the same amount of 0x4a and 0x4b polygons as yours 
from 11-error.zip.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 26. Dezember 2020 19:12
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

I'm sorry for the late response and for breaking the thread, but I
didn't receive Gerd's last message, so I've had to copy it from mailing
list archive. Reply inline.

OK, I think I understand what problem you see. I used JaVaWa
MapConverter to install the map in 11-error.zip and 12-OK.zip played
with it. With 11-error.zip only the data from the overview map is
displayed when I zoom to e.g. S21.71088 E114.92708, while 12-OK.zip
shows more details (this is with MapSource, in Basecamp I see details in
both maps).

Yes, everything to the North of approx. S32.39125 is missing.

I tried to analyse your files and I see three suspicious things so far:

1) The routing data seems to be wrong, NodCheck reports "Could not find
node for road 38a61 nod2=124c8 " for both tiles. I don't see such an
error with the default style.

How can I check that? If both tiles are affected, probably this is not
related with current issue, but other maps produced with the same style
will also be wrong regarding routing.

2) The bad overview map contains a lot more 0x4a polygons. This is
probably caused by the --order-by-decreasing-area, and I am not sure why
this happens.

Do you think the problem is in the overview map or may be in tile map?
If I open tile in MapEdit++ the number of non polygon elements is almost
the same in wrong and correct maps. For example, number of roads is
exactly the same. It seems as if something is masking part of the tile
in MapSource (also in BaseCamp in my case); elements are there, but you
can't see them.

3) You use a special version of mkgmap, so please try also with the
latest version.

With latest mkgmap and default style problem persists.

My first guess was that the bad NOD file may cause this but the problem
doesn't disappear when I remove the file 51145001.NOD, so this is
probably not to blame. Same for the 51145001.DEM file.

I tried to reproduce the possible problem with the 0x4a til

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

I had removed --order-by-decreasing-area from my command for DEM maps, 
but --no-order-by-decreasing-area seems to fix the problem by now. By 
the way, this option is not documented in options file and I can't find 
it in the code. Is --no a general switch for all options or is it a 
particular case for order-by-decreasing-area? I don't remember having 
seen it before.


El 27/12/20 a las 10:36, Gerd Petermann escribió:

Hi Carlos,

I agree that --order-by-decreasing-area is to blame. This option seems to 
disturb the calculation of the overview map, and maybe the extreme size of the 
tile plays another role here.

I hope Ticker can help here, I think the option supresses the merging of 
shapes, and this is probably not a good idea for the 0x4a shapes.

As a work-around for you:
Add option --no-order-by-decreasing-area at the end(!) of the parameter list so 
that the overview map is created without this option. This seems to fix the 
problem on my machine.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Sonntag, 27. Dezember 2020 09:36
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

Hi Carlos,

reg. the routing data: You can run display tool to check yourself, but the 
error is either in mkgmap or in display tool. My command looks like this :
java -ea -cp d:\display\dist\display.jar;d:\mkgmap\dist\mkgmap.jar 
test.check.NodCheck  -vv --tab-zero=0 51145001.img > nodcheck.51145001.img 2> 
crash_nod
It would be easier if you would post a link to your style.

I am now able to reproduce the display error using this command
java -Xmx6G -ea -jar d:\mkgmap\dist\mkgmap.jar --dem=f:\srtm3 
--dem-poly=e:\carlos\australia.poly  --overview-dem-dist=276160 --gmapi --show-profiles=1 
--bounds=f:\osm\bounds.zip --precomp-sea=f:\osm\sea.zip --route --reduce-point-density=4 
--polygon-size-limits="24:12, 18:10, 16:0" --order-by-decreasing-area 
--location-autofill=is_in,nearest --drive-on=detect,left 
--road-name-config=d:\mkgmap\resources\roadNameConfig.txt  e:\carlos\51145001.o5m

and the overview map has the same amount of 0x4a and 0x4b polygons as yours 
from 11-error.zip.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 26. Dezember 2020 19:12
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

I'm sorry for the late response and for breaking the thread, but I
didn't receive Gerd's last message, so I've had to copy it from mailing
list archive. Reply inline.

OK, I think I understand what problem you see. I used JaVaWa
MapConverter to install the map in 11-error.zip and 12-OK.zip played
with it. With 11-error.zip only the data from the overview map is
displayed when I zoom to e.g. S21.71088 E114.92708, while 12-OK.zip
shows more details (this is with MapSource, in Basecamp I see details in
both maps).

Yes, everything to the North of approx. S32.39125 is missing.

I tried to analyse your files and I see three suspicious things so far:

1) The routing data seems to be wrong, NodCheck reports "Could not find
node for road 38a61 nod2=124c8 " for both tiles. I don't see such an
error with the default style.

How can I check that? If both tiles are affected, probably this is not
related with current issue, but other maps produced with the same style
will also be wrong regarding routing.

2) The bad overview map contains a lot more 0x4a polygons. This is
probably caused by the --order-by-decreasing-area, and I am not sure why
this happens.

Do you think the problem is in the overview map or may be in tile map?
If I open tile in MapEdit++ the number of non polygon elements is almost
the same in wrong and correct maps. For example, number of roads is
exactly the same. It seems as if something is masking part of the tile
in MapSource (also in BaseCamp in my case); elements are there, but you
can't see them.

3) You use a special version of mkgmap, so please try also with the
latest version.

With latest mkgmap and default style problem persists.

My first guess was that the bad NOD file may cause this but the problem
doesn't disappear when I remove the file 51145001.NOD, so this is
probably not to blame. Same for the 51145001.DEM file.

I tried to reproduce the possible problem with the 0x4a tiles using the
default style with this command java -Xmx4G -jar map.jar --route --gmapi
--bounds=f:\osm\bounds.zip --precomp-sea=f:\osm\sea.zip
--reduce-point-density=4 --polygon-size-limits="24:12, 18:10, 16:0"
--order-by-decreasing-area --location-autofill=is_in,nearest
f:\dwnload\temp\51145001.o5m but my overview map contains the same
number of 0x4a tiles as your good map.

I cannot reproduce your DEM data because I don't know the polygon file
(polygons/$pais.poly). Maybe I can reproduce the 0x4a problem when you
create the test files again without --remove-ovm-work-files=true.

You can do

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

I'm sorry for the late response and for breaking the thread, but I 
didn't receive Gerd's last message, so I've had to copy it from mailing 
list archive. Reply inline.


OK, I think I understand what problem you see. I used JaVaWa 
MapConverter to install the map in 11-error.zip and 12-OK.zip played 
with it. With 11-error.zip only the data from the overview map is 
displayed when I zoom to e.g. S21.71088 E114.92708, while 12-OK.zip 
shows more details (this is with MapSource, in Basecamp I see details in 
both maps).


Yes, everything to the North of approx. S32.39125 is missing.

I tried to analyse your files and I see three suspicious things so far:

1) The routing data seems to be wrong, NodCheck reports "Could not find 
node for road 38a61 nod2=124c8 " for both tiles. I don't see such an 
error with the default style.


How can I check that? If both tiles are affected, probably this is not 
related with current issue, but other maps produced with the same style 
will also be wrong regarding routing.


2) The bad overview map contains a lot more 0x4a polygons. This is 
probably caused by the --order-by-decreasing-area, and I am not sure why 
this happens.


Do you think the problem is in the overview map or may be in tile map? 
If I open tile in MapEdit++ the number of non polygon elements is almost 
the same in wrong and correct maps. For example, number of roads is 
exactly the same. It seems as if something is masking part of the tile 
in MapSource (also in BaseCamp in my case); elements are there, but you 
can't see them.


3) You use a special version of mkgmap, so please try also with the 
latest version.


With latest mkgmap and default style problem persists.

My first guess was that the bad NOD file may cause this but the problem 
doesn't disappear when I remove the file 51145001.NOD, so this is 
probably not to blame. Same for the 51145001.DEM file.


I tried to reproduce the possible problem with the 0x4a tiles using the 
default style with this command java -Xmx4G -jar map.jar --route --gmapi 
--bounds=f:\osm\bounds.zip --precomp-sea=f:\osm\sea.zip 
--reduce-point-density=4 --polygon-size-limits="24:12, 18:10, 16:0" 
--order-by-decreasing-area --location-autofill=is_in,nearest 
f:\dwnload\temp\51145001.o5m but my overview map contains the same 
number of 0x4a tiles as your good map.


I cannot reproduce your DEM data because I don't know the polygon file 
(polygons/$pais.poly). Maybe I can reproduce the 0x4a problem when you 
create the test files again without --remove-ovm-work-files=true.


You can download polygon file from here 
<https://alternativaslibres.org/tmp/australia.poly> and ovm from here 
<https://alternativaslibres.org/tmp/ovm_51145001.img>.


El 22/12/20 a las 18:05, Carlos Dávila escribió:

I'm sorry, probably I didn't explain well enough.

Overview is always correct, the problem affects only tiles. As you saw 
in the screenshots of my first mail, they are different in size, but 
they are generated from the same input files, so they should have the 
same size. If you zoom in to an area that should be included in a 
tile, only overview map is shown, no detailed map. Even more, when you 
zoom in, at the given point where detailed map appears, tile boundary 
jumps to the correct size, but nothing but overview is displayed 
outside the "pruned" tile.


You can download correct and wrong files from the links below and play 
with them to get a better idea of the problem. They correspond to 
first tile of Australia as shown in my screenshots.


https://alternativaslibres.org/tmp/11-error.zip

https://alternativaslibres.org/tmp/12-OK.zip

Error was generated with java -Xmx27G -ea 
-Dlog.config=logging.properties -jar mkgmap.jar 
--dem=hgt/LIDAR-Sonny,hgt/ALOS,hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt 
--dem-poly=polygons/$pais.poly --overview-dem-dist=276160 -c 
opciones_comunes $CODEPAGE --gmapi --show-profiles=1 
--bounds=bounds.zip --precomp-sea=sea.zip --route --family-name="OSM 
$MAPA DEM" --family-id=5${FID} --overview-mapname=${ABR}5${FID} 
--overview-mapnumber=${GRUPO}5${FID}000 --reduce-point-density=4 
--polygon-size-limits="24:12, 18:10, 16:0" --order-by-decreasing-area 
--location-autofill=is_in,nearest --drive-on=detect,$DRIVEON $LANGUAGE 
--road-name-config=${CONFIG} --style=mio --remove-ovm-work-files=true 
51145001.o5m tmp/${ABR}5${FID}.txt


OK was generated with java -Xmx27G -ea -Dlog.config=logging.properties 
-jar mkgmap.jar 
--dem=hgt/LIDAR-Sonny,hgt/ALOS,hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt 
--dem-poly=polygons/$pais.poly --overview-dem-dist=276160 -c 
opciones_comunes $CODEPAGE --gmapi --show-profiles=1 
--bounds=bounds.zip --precomp-sea=sea.zip --route --family-name="OSM 
$MAPA DEM" --family-id=5${FID} --overview-mapname=${ABR}5${FID} 
--overview-mapnumber=${GRUPO}5${FID}000 --reduce-point-density=4 
--polygon-size-limits="24:12, 18:10, 16:0" 
--location-autofi

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

I'm sorry, probably I didn't explain well enough.

Overview is always correct, the problem affects only tiles. As you saw 
in the screenshots of my first mail, they are different in size, but 
they are generated from the same input files, so they should have the 
same size. If you zoom in to an area that should be included in a tile, 
only overview map is shown, no detailed map. Even more, when you zoom 
in, at the given point where detailed map appears, tile boundary jumps 
to the correct size, but nothing but overview is displayed outside the 
"pruned" tile.


You can download correct and wrong files from the links below and play 
with them to get a better idea of the problem. They correspond to first 
tile of Australia as shown in my screenshots.


https://alternativaslibres.org/tmp/11-error.zip

https://alternativaslibres.org/tmp/12-OK.zip

Error was generated with java -Xmx27G -ea 
-Dlog.config=logging.properties -jar mkgmap.jar 
--dem=hgt/LIDAR-Sonny,hgt/ALOS,hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt 
--dem-poly=polygons/$pais.poly --overview-dem-dist=276160 -c 
opciones_comunes $CODEPAGE --gmapi --show-profiles=1 --bounds=bounds.zip 
--precomp-sea=sea.zip --route --family-name="OSM $MAPA DEM" 
--family-id=5${FID} --overview-mapname=${ABR}5${FID} 
--overview-mapnumber=${GRUPO}5${FID}000 --reduce-point-density=4 
--polygon-size-limits="24:12, 18:10, 16:0" --order-by-decreasing-area 
--location-autofill=is_in,nearest --drive-on=detect,$DRIVEON $LANGUAGE 
--road-name-config=${CONFIG} --style=mio --remove-ovm-work-files=true 
51145001.o5m tmp/${ABR}5${FID}.txt


OK was generated with java -Xmx27G -ea -Dlog.config=logging.properties 
-jar mkgmap.jar 
--dem=hgt/LIDAR-Sonny,hgt/ALOS,hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt 
--dem-poly=polygons/$pais.poly --overview-dem-dist=276160 -c 
opciones_comunes $CODEPAGE --gmapi --show-profiles=1 --bounds=bounds.zip 
--precomp-sea=sea.zip --route --family-name="OSM $MAPA DEM" 
--family-id=5${FID} --overview-mapname=${ABR}5${FID} 
--overview-mapnumber=${GRUPO}5${FID}000 --reduce-point-density=4 
--polygon-size-limits="24:12, 18:10, 16:0" 
--location-autofill=is_in,nearest --drive-on=detect,$DRIVEON $LANGUAGE 
--road-name-config=${CONFIG} --style=mio --remove-ovm-work-files=true 
51145001.o5m tmp/${ABR}5${FID}.txt


Although removing --overview-dem-dist solved the issue in my first test 
(see command below, correct output), after a lot of tests removing 
options one by one from the original command, finally it seems the 
problem is caused by option --order-by-decreasing-area (or the 
combination of both).


java -Xmx27G -ea -Dlog.config=logging.properties -jar mkgmap.jar 
--dem=hgt/LIDAR-Sonny,hgt/ALOS,hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt 
--dem-poly=polygons/$pais.poly -c opciones_comunes $CODEPAGE --gmapi 
--show-profiles=1 --bounds=bounds.zip --precomp-sea=sea.zip --route 
--country-name=$PAIS --country-abbr=${ABR} --area-name="$MAPA" 
--family-name="OSM $MAPA DEM" --family-id=5${FID} 
--product-version=$VERSION --series-name="OSM-$MAPA-DEM" 
--overview-mapname=${ABR}5${FID} --overview-mapnumber=${GRUPO}5${FID}000 
--name-tag-list=$NAMETAG --process-destination --process-exits 
--housenumbers --reduce-point-density=4 --polygon-size-limits="24:12, 
18:10, 16:0" --order-by-decreasing-area --add-pois-to-areas 
--link-pois-to-ways --location-autofill=is_in,nearest 
--drive-on=detect,$DRIVEON --check-roundabouts --check-roundabout-flares 
--license-file=license_OSM_${HGT} --copyright-file=copyright $LANGUAGE 
--road-name-config=${CONFIG} --style=mio --remove-ovm-work-files=true 
51145001.o5m tmp/${ABR}5${FID}.txt


El 22/12/20 a las 10:15, Gerd Petermann escribió:

Hi Carlos,

It seems I still don't understand what the problem is or how to reproduce it.
I tried this command and the overview map looks OK:
java -Xmx4G -jar d:\mkgmap\dist\mkgmap.jar --dem=f:\srtm3 
--overview-dem-dist=128000 --show-profiles=1 --gmapi 
f:\dwnload\temp\51145001.o5m

If it is related to the DEM data I probably cannot help much. You may try a 
slightly different value for the --overview-dem-dist option or a modified 
polygon
given with the --dem-poly option.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 21. Dezember 2020 22:09
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map

The problem seems to be caused by overview DEM. If I remove
--overview-dem-dist option tile is complete in MapSource. The issue can
be reproduced with this tile
<https://alternativaslibres.org/tmp/51145001.o5m> and HGT from
vierfinderpanoramas3

El 18/12/20 a las 11:48, Gerd Petermann escribió:

Hi Carlos,

not sure if I understand what the problem is. The two screenshots show 
completely different tile boundaries, so they were not created from the same 
splitter output.

Gerd

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

The problem seems to be caused by overview DEM. If I remove 
--overview-dem-dist option tile is complete in MapSource. The issue can 
be reproduced with this tile 
<https://alternativaslibres.org/tmp/51145001.o5m> and HGT from 
vierfinderpanoramas3


El 18/12/20 a las 11:48, Gerd Petermann escribió:

Hi Carlos,

not sure if I understand what the problem is. The two screenshots show 
completely different tile boundaries, so they were not created from the same 
splitter output.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 17. Dezember 2020 23:44
An: Development list for mkgmap
Betreff: [mkgmap-dev] Tiles pruned in DEM map

I build several types of map (OSM, OSM+contour lines, maps for trucks
and OSM+DEM) for the same area, using same input files. I split
country.o5m with splitter and then use the same template.args output by
splitter for all maps, just changing mapname for the different types of
map. Given that, all resulting mapsets should have the same tiles, but
tiles in DEM map are smaller than in the other types. They share part of
the boundaries (usually two of them) with other types, but other
boundaries are moved in, reducing displayed tile size. See attached
screenshots. However, file size is the same (discounting *.DEM) for each
tile in *.gmap subfolders.

Command is quite similar for OSM and OSM+DEM maps:

java -Xmx27G -ea -Dlog.config=logging.properties -jar mkgmap.jar -c
opciones_comunes $CODEPAGE --gmapi --bounds=bounds.zip
--precomp-sea=sea.zip --route --country-name=$PAIS --country-abbr=${ABR}
--area-name=$MAPA --family-name="OpenStreetMap $MAPA"
--family-id=1${FID} --product-version=$VERSION --series-name="OSM-$MAPA"
--overview-mapname=${ABR}1${FID} --overview-mapnumber=${GRUPO}1${FID}000
--name-tag-list=$NAMETAG --process-destination --process-exits
--housenumbers --reduce-point-density=4 --polygon-size-limits="24:12,
18:10, 16:0" --order-by-decreasing-area --add-pois-to-areas
--report-similar-arcs --report-dead-ends=2 --link-pois-to-ways
--location-autofill=is_in,nearest --drive-on=detect,$DRIVEON
--check-roundabouts --check-roundabout-flares --license-file=license_OSM
--copyright-file=copyright $LANGUAGE --road-name-config=${CONFIG}
--style=mio --check-styles -c $pais.args tmp/${ABR}1${FID}.txt

java --Xmx27G -ea -Dlog.config=logging.properties -jar mkgmap.jar
--dem=hgt/LIDAR,hgt/ALOS,hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt
--dem-poly=polygons/$pais.poly --dem-dists=3312,6624,9936,13248,26512
--overview-dem-dist=128000 -c opciones_comunes $CODEPAGE --gmapi
--show-profiles=1 --bounds=bounds.zip --precomp-sea=sea.zip --route
--country-name=$PAIS --country-abbr=${ABR} --area-name="$MAPA"
--family-name="OSM $MAPA DEM" --family-id=5${FID}
--product-version=$VERSION --series-name="OSM-$MAPA-DEM"
--overview-mapname=${ABR}5${FID} --overview-mapnumber=${GRUPO}5${FID}000
--name-tag-list=$NAMETAG --process-destination --process-exits
--housenumbers --reduce-point-density=4 --polygon-size-limits="24:12,
18:10, 16:0" --order-by-decreasing-area --add-pois-to-areas
--link-pois-to-ways --location-autofill=is_in,nearest
--drive-on=detect,$DRIVEON --check-roundabouts --check-roundabout-flares
--license-file=license_OSM_${HGT} --copyright-file=copyright $LANGUAGE
--road-name-config=${CONFIG} --style=mio --remove-ovm-work-files=true -c
${pais}-DEM.args tmp/${ABR}5${FID}.txt

Both OSM and OSM+DEM maps can be downloaded from
https://alternativaslibres.org/en/downloads.php#Oceania

Any idea why this happens?

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

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

Re: [mkgmap-dev] Tiles pruned in DEM map

[Carlos Dávila]

In theory, they are created from same splitter output, that's the problem.

El 18/12/20 a las 11:48, Gerd Petermann escribió:

Hi Carlos,

not sure if I understand what the problem is. The two screenshots show 
completely different tile boundaries, so they were not created from the same 
splitter output.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 17. Dezember 2020 23:44
An: Development list for mkgmap
Betreff: [mkgmap-dev] Tiles pruned in DEM map

I build several types of map (OSM, OSM+contour lines, maps for trucks
and OSM+DEM) for the same area, using same input files. I split
country.o5m with splitter and then use the same template.args output by
splitter for all maps, just changing mapname for the different types of
map. Given that, all resulting mapsets should have the same tiles, but
tiles in DEM map are smaller than in the other types. They share part of
the boundaries (usually two of them) with other types, but other
boundaries are moved in, reducing displayed tile size. See attached
screenshots. However, file size is the same (discounting *.DEM) for each
tile in *.gmap subfolders.

Command is quite similar for OSM and OSM+DEM maps:

java -Xmx27G -ea -Dlog.config=logging.properties -jar mkgmap.jar -c
opciones_comunes $CODEPAGE --gmapi --bounds=bounds.zip
--precomp-sea=sea.zip --route --country-name=$PAIS --country-abbr=${ABR}
--area-name=$MAPA --family-name="OpenStreetMap $MAPA"
--family-id=1${FID} --product-version=$VERSION --series-name="OSM-$MAPA"
--overview-mapname=${ABR}1${FID} --overview-mapnumber=${GRUPO}1${FID}000
--name-tag-list=$NAMETAG --process-destination --process-exits
--housenumbers --reduce-point-density=4 --polygon-size-limits="24:12,
18:10, 16:0" --order-by-decreasing-area --add-pois-to-areas
--report-similar-arcs --report-dead-ends=2 --link-pois-to-ways
--location-autofill=is_in,nearest --drive-on=detect,$DRIVEON
--check-roundabouts --check-roundabout-flares --license-file=license_OSM
--copyright-file=copyright $LANGUAGE --road-name-config=${CONFIG}
--style=mio --check-styles -c $pais.args tmp/${ABR}1${FID}.txt

java --Xmx27G -ea -Dlog.config=logging.properties -jar mkgmap.jar
--dem=hgt/LIDAR,hgt/ALOS,hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt
--dem-poly=polygons/$pais.poly --dem-dists=3312,6624,9936,13248,26512
--overview-dem-dist=128000 -c opciones_comunes $CODEPAGE --gmapi
--show-profiles=1 --bounds=bounds.zip --precomp-sea=sea.zip --route
--country-name=$PAIS --country-abbr=${ABR} --area-name="$MAPA"
--family-name="OSM $MAPA DEM" --family-id=5${FID}
--product-version=$VERSION --series-name="OSM-$MAPA-DEM"
--overview-mapname=${ABR}5${FID} --overview-mapnumber=${GRUPO}5${FID}000
--name-tag-list=$NAMETAG --process-destination --process-exits
--housenumbers --reduce-point-density=4 --polygon-size-limits="24:12,
18:10, 16:0" --order-by-decreasing-area --add-pois-to-areas
--link-pois-to-ways --location-autofill=is_in,nearest
--drive-on=detect,$DRIVEON --check-roundabouts --check-roundabout-flares
--license-file=license_OSM_${HGT} --copyright-file=copyright $LANGUAGE
--road-name-config=${CONFIG} --style=mio --remove-ovm-work-files=true -c
${pais}-DEM.args tmp/${ABR}5${FID}.txt

Both OSM and OSM+DEM maps can be downloaded from
https://alternativaslibres.org/en/downloads.php#Oceania

Any idea why this happens?

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

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

Re: [mkgmap-dev] Split gmapsupp.img

[Carlos Dávila]

El 19/10/20 a las 0:30, Andrzej Popowski escribió:

Hi Carlos,

splitting could be useful, when you'd like to create img in one step. 
Other option is to install map on PC and then use MapInstall to create 
img. MapInstall does splitting for big maps.



Hi Andrej

I know I can use MapSource/MapInstall to send parts of a map to device, 
but many people have problems using this method, so I would like to have 
way to provide ready to use gmapsupp files of my maps


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

Re: [mkgmap-dev] Split gmapsupp.img

[Carlos Dávila]

I'll have a look at that thread later. I can process large files in my 
server if needed.


El 18/10/20 a las 9:50, Gerd Petermann escribió:

Hi Carlos,

see 
http://gis.19327.n8.nabble.com/Split-gmapsupp-img-files-over-4GB-tc5967656.html

I tried to code this at that time but got stuck because I didn't have the time 
to create such a large map to find out where MapInstall places the other files 
(e.g. MDR, TYP and if any other file or flag is needed.
Maybe I'll give it another try with a download of Europe made in 2019. Splitter 
will stress my PC for quite a while ...

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Sonntag, 18. Oktober 2020 09:14
An: Development list for mkgmap
Betreff: [mkgmap-dev] Split gmapsupp.img

As far a I know, mkgmap is able to produce unlimited size gmapsupp
files, but SD cards and internal device memories have a limit of 4 GB in
a single file. To overcome that limit, recent versions of Garmin City
Navigator maps are split into several gmapsupp that work as a single one
in devices which include them. Would it be possible to add an option to
mkgmap, so that it automatically splits gmapsupp when you process a map
that is larger than 4 GB?

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



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

[mkgmap-dev] Split gmapsupp.img

[Carlos Dávila]

As far a I know, mkgmap is able to produce unlimited size gmapsupp 
files, but SD cards and internal device memories have a limit of 4 GB in 
a single file. To overcome that limit, recent versions of Garmin City 
Navigator maps are split into several gmapsupp that work as a single one 
in devices which include them. Would it be possible to add an option to 
mkgmap, so that it automatically splits gmapsupp when you process a map 
that is larger than 4 GB?


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

[mkgmap-dev] mapnik.txt Spanish translation

[Carlos Dávila]

I'm working on Spanish translation of mapnik.txt file. It's still a work 
in progress, but in order to avoid conflicts with changes announced by 
Karl (7770) I send a diff with current state. I've chosen String5 for 
Spanish, as it was the first unused number.


Index: resources/typ-files/mapnik.txt
===
--- resources/typ-files/mapnik.txt	(revisión: 4431)
+++ resources/typ-files/mapnik.txt	(copia de trabajo)
@@ -83,6 +83,7 @@
 String1=0x01,Résidentiel
 String2=0x02,Wohngebiet
 String4=0x03,Bebouwing
+String5=0x08,Zona habitada
 String7=0x15,Obszar mieszkalny
 String8=0x10,Residencial
 String9=0x05,Area residenziale
@@ -99,6 +100,7 @@
 String1=0x01,Résidentiel
 String2=0x02,Wohngebiet
 String4=0x03,Bebouwing
+String5=0x08,Zona habitada
 String7=0x15,Obszar mieszkalny
 String8=0x10,Residencial
 String9=0x05,Area residenziale
@@ -115,6 +117,7 @@
 String1=0x01,Domaine militaire
 String2=0x02,Militärisches Sperrgebiet
 String4=0x03,Militair domein
+String5=0x08,Terreno militar
 String7=0x15,Teren wojskowy
 String8=0x10,Militar
 String9=0x05,Area militare
@@ -183,6 +186,7 @@
 String2=0x02,Garagen
 String3=0x04,Parking
 String4=0x03,Garages
+String5=0x08,Aparcamiento (cubierto)
 String7=0x15,Garaże
 String8=0x10,Garagem
 String9=0x05,Garage
@@ -199,6 +203,7 @@
 String1=0x01,Aéroport
 String2=0x02,Flughafen
 String4=0x03,Vliegveld
+String5=0x08,Aeropuerto
 String7=0x15,Lotnisko
 String8=0x10,Aeroporto
 String9=0x05,Aerodromo
@@ -215,6 +220,7 @@
 String1=0x01,Zone commerciale
 String2=0x02,Gewerbegebiet
 String4=0x03,Commercieel gebied
+String5=0x08,Cafetería/Tiendas
 String7=0x15,Obszar handlowy
 String8=0x10,Área comercial
 String9=0x05,Area commerciale
@@ -232,6 +238,7 @@
 String2=0x02,Schwimmbad
 String3=0x04,Water Park
 String4=0x03,Zwembad
+String5=0x08,Marina/Parque acuático
 String7=0x15,Basen
 String8=0x10,Piscina
 String9=0x05,Piscina
@@ -249,6 +256,7 @@
 String2=0x02,Schule
 String3=0x04,Education
 String4=0x03,School
+String5=0x08,Enseñanza
 String7=0x15,Edukacja
 String8=0x10,Escola
 String9=0x05,Scuola
@@ -265,6 +273,7 @@
 String1=0x01,Hôpital
 String2=0x02,Krankenhaus
 String4=0x03,Ziekenhuis
+String5=0x08,Hospital
 String7=0x15,Szpital
 String8=0x10,Hospital
 String9=0x05,Ospedale
@@ -282,6 +291,7 @@
 String2=0x02,Industriegebiet
 String3=0x04,Industrial area
 String4=0x03,Industriegebied
+String5=0x08,Polígono industrial
 String7=0x15,Obszar przemysłowy
 String8=0x10,Área industrial
 String9=0x05,Area industriale
@@ -1198,6 +1208,7 @@
 String1=0x01,Autoroute
 String2=0x02,Autobahn
 String4=0x03,Snelweg
+String5=0x08,Autopista
 String7=0x15,Autostrada
 String8=0x10,Autoestrada
 String9=0x05,Autostrada
@@ -1218,6 +1229,7 @@
 String1=0x01,Voie rapide
 String2=0x02,Schnellstraße
 String4=0x03,Autoweg
+String5=0x08,Carretera troncal
 String7=0x15,Droga szybkiego ruchu
 String8=0x10,Via expressa
 String9=0x05,Superstrada
@@ -1238,6 +1250,7 @@
 String1=0x01,Route primaire
 String2=0x02,Bundesstraße
 String4=0x03,Primair
+String5=0x08,Carretera primaria
 String7=0x15,Droga krajowa
 String8=0x10,Via primária
 String9=0x05,Strada principale
@@ -1258,6 +1271,7 @@
 String1=0x01,Route secondaire
 String2=0x02,Bundesstraße
 String4=0x03,Secundair
+String5=0x08,Carretera secundaria
 String7=0x15,Droga wojewódzka
 String8=0x10,Via secundária
 String9=0x05,Strada principale
@@ -1278,6 +1292,7 @@
 String1=0x01,Route tertiaire
 String2=0x02,Straße
 String4=0x03,Tertiair
+String5=0x08,Carretera terciaria
 String7=0x15,Droga powiatowa
 String8=0x10,Via terciária
 String9=0x05,Strada
@@ -1298,6 +1313,7 @@
 String1=0x01,Rue
 String2=0x02,Straße
 String4=0x03,Weg
+String5=0x08,Vía urbana
 String7=0x15,Droga
 String8=0x10,Residencial
 String9=0x05,Strada residenziale
@@ -1318,6 +1334,7 @@
 String1=0x01,Rue
 String2=0x02,Straße
 String4=0x03,Straat
+String5=0x08,Vía de servicio
 String7=0x15,Ulica
 String8=0x10,Rua
 String9=0x05,Strada
@@ -1339,6 +1356,7 @@
 String1=0x01,Voie d’accès
 String2=0x02,Bundesstraße (Verbindung)
 String4=0x03,Secundair (Verbinding)
+String5=0x08,Enlace de via menor
 String7=0x15,Droga wojewódzka (łącznik)
 String8=0x10,Ligação de via secundária
 String9=0x05,Strada principale (collegamento)
@@ -1359,6 +1377,7 @@
 String1=0x01,Voie d’accès
 String2=0x02,Schnellstraße (verbindung)
 String4=0x03,Autoweg (Verbinding)
+String5=0x08,Enlace de vía principal
 String7=0x15,Droga szybkiego ruchu  (łącznik)
 String8=0x10,Ligação de via expressa
 String9=0x05,Superstrada (collegamento)
@@ -1381,6 +1400,7 @@
 String2=0x02,Unbefestigt
 String3=0x04,Track (Grade unknown)
 String4=0x03,Veldweg (Onbekend)
+String5=0x08,Pista sin pavimento
 String7=0x15,Droga gruntowa (klasa nieznana)
 String8=0x10,Estrada agrícola
 String9=0x05,Sentiero carrabile
@@ -1401,6 +1421,7 @@
 String1=0x01,Voie d’accès
 String2=0x02,Schnellstraße (verbindung)
 String4=0x03,Autoweg (Verbinding)
+String5=0x08,Enlace de vía
 String7=0x15,Droga szybkiego ruchu  (łącznik)
 

Re: [mkgmap-dev] question about output-dir and indexing

[Carlos Dávila]

mapname and description are taken from template.args. Try removing those 
parameters from your command line.
Regarding index, in order to get right addresses you need to supply 
bounds file (--bounds). You can get it from 
http://osm.thkukuk.de/data/bounds-latest.zip


El 5/10/20 a las 19:32, 7700 escribió:

Hi.
I am very new to making maps so therefor in case i am asking something obvious
it is because i don't know better yet.

I am trying to generate a map for a country (trying sweden) and observe a
strange thing with --output-dir for mkgmap (r4585).
Files are written to other directories than to the --output-dir


Starting at a base directory i have created this structure:

├── gmapsupp
└── se
 ├── splitted
 └── tiles

The idea is that for sweden i will store splitted pbf files in a separate
directory and tiles in a separate.

at first i download data to the ./se/ directory:
wget https://download.geofabrik.de/europe/sweden-latest.osm.pbf

then split the data, adding the --output-dir=se/splitted/
this works fine.

now i want to generate the *.img tiles from the splitted files. Doing this from
the base directory.

java -jar ../mkgmap/mkgmap-r4585/mkgmap.jar
--read-config=se/splitted/template.args
--remove-short-arcs
--family-name="NORDIC"
--country-name="Sweden"
--country-abbr="SWE"
--description="Sweden routable."
--mapname=7771
--family-id=770
--latin1
--net --route --index --split-name-index
--output-dir=se/tiles/
se/splitted/*.osm.pbf



When i run this from the base directory
numbered *.img files and ovm_*.img files are first written to the base directory
and then last to the target directory.
After the program finishes there are files both in base directory from where i
executed the program, as well as the directory given in output-dir.
The files in the output-dir directory are larger than the ones in the base
directory. Is this an error or should i take care of both sets of files?



Trying to use --index to create a searchable index or street names, for this,
do i need to add a separate file/style to make it work?
if yes, are there examples which you can point to?


Regards
Karl



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



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

Re: [mkgmap-dev] Fwd: Re: "Small" SRTM1 files and DEM maps

[Carlos Dávila]

Thanks!!

El 5/10/20 a las 8:13, Gerd Petermann escribió:

Hi Carlos,

sorry, no idea what went wrong with the communication. I've now committed the 
patch with r4586.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Mittwoch, 24. Juni 2020 19:12
An: Development list for mkgmap
Betreff: [mkgmap-dev] Fwd: Re:  "Small" SRTM1 files and DEM maps

Hi Gerd

I replied to your patch a couple of months ago, but I have now realized
it didn't arrive to the list (it seems I used and old address). I was
surprised you didn't say anything, but didn't want to bother...

I used your binary for my test. Today I have tried to apply your patch,
but it seems to be generated against a different version of files in trunk.



 Mensaje reenviado 
Asunto: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps
Fecha:  Tue, 21 Apr 2020 17:38:19 +0200
De: Carlos Dávila 
Para:   mkgmap-dev@lists.mkgmap.org.uk



Hi Gerd
I have tested it in an area of 4x10 degrees, in the North of China, and
it worked fine.

El 21/4/20 a las 14:40, Gerd Petermann escribió:

Hi Carlos,

please try the attached patch or this binary based on r4483:
http://files.mkgmap.org.uk/download/468/mkgmap.jar
I hope I found all the places that need to be changed. I've only
tested with a map around the point N50 E118.

Gerd


Von: mkgmap-dev  im Auftrag
von Carlos Dávila 
Gesendet: Dienstag, 21. April 2020 11:27
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Great new!! Thanks for your support

El 21/4/20 a las 11:19, Gerd Petermann escribió:

Hi Carlos,

yes, I see that the source code handles this format. I finally found
https://dds.cr.usgs.gov/srtm/version2_1/Documentation/MIL-PDF-89020B.pdf
I think "TABLE I. Matrix intervals for DTED Level 0."
shows how to interpret the data. It seems there are a few more
variants...
For now I'll try to support also the 1801 * 3601 * 2 format

Gerd

____
Von: mkgmap-dev  im Auftrag
von Carlos Dávila 
Gesendet: Donnerstag, 16. April 2020 17:41
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

HI Gerd
I don't think conversion is wrong. If input geotiff file is 24MB, output
hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB
I use this command on Linux:
for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i
`basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml
BTW, gdal is also able to deal with small SRTM files

El 16/4/20 a las 11:31, Gerd Petermann escribió:

Hi Carlos,

so your conversion routine is wrong. The file size is 12.970.802
bytes. There is no integer n for which 2 * n^2 results in this value.

Gerd

________
Von: mkgmap-dev  im Auftrag
von Carlos Dávila 
Gesendet: Donnerstag, 16. April 2020 11:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
Forgot to mention files are downloaded as geotiff, but I then convert
them to hgt, sorry.
You can download a sample one from
https://alternativaslibres.org/tmp/N50E118.hgt

El 16/4/20 a las 9:18, Gerd Petermann escribió:

Hi Carlos,

are you talking about geotiff format? I think someone documented
how that format can be converted to *.hgt.
Can you post a link to such a file?

Gerd



________
Von: mkgmap-dev  im Auftrag
von Carlos Dávila 
Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
||    if srtmVersion == 2.1:||
||    return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
||    elif srtmVersion == 3.0:||
||    if resolution == 1:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
||    elif resolution == 3:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
||    return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not
compressed. Do you know from where these 12.4 MB files came from?

Gerd


Von: mkgmap-dev  im
Auftrag von Carlos Dávila 
Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1

Re: [mkgmap-dev] Another AssertionError

[Carlos Dávila]

Hi Gerd
FileInfo didn't help very much, but the new version of mkgmap helped 
locate two corrupted img files that were causing the problem.


El 23/9/20 a las 9:08, Gerd Petermann escribió:

Hi Carlos,

this is a different problem. Seems you have a corrupted *.img file in one of 
the two input directories.
Enable logging with to find more information about the file that is corrupted:
uk.me.parabola.mkgmap.combiners.FileInfo.level=INFO

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Dienstag, 22. September 2020 22:54
An: Development list for mkgmap
Betreff: [mkgmap-dev] Another AssertionError

I get the error reproduced below when I combine osm and contour lines
precompiled tiles for the map of all Asia. Command line used is:

java -Xmx27G -ea -jar mkgmap_trunk.jar --gmapi --max-jobs --index
--latin1 --code-page=1252 --description="OSM-$MAPA-Topo"
--family-name="OSM $MAPA Topo" --family-id=3$FID --product-id=1
--product-version=$VERSION --series-name="OSM-$MAPA-Topo"
--area-name="$MAPA" --overview-mapname=$ABR-3$FID
--overview-mapnumber=653${FID}000 --road-name-config=$CONFIG
--x-mdr7-del=GRADE0,GRADE1,GRADE2,GRADE3,GRADE4,GRADE5,GRADE6,GRADE7,UNNAMED
--show-profiles=1 tmp/551${FID}*.img curvas/602${FID}*.img
typ/$ABR-3${FID}.TYP

Exception in thread "main" java.lang.AssertionError
  at
uk.me.parabola.imgfmt.app.trergn.TREHeader.readFileHeader(TREHeader.java:107)
  at
uk.me.parabola.imgfmt.app.CommonHeader.readHeader(CommonHeader.java:95)
  at
uk.me.parabola.imgfmt.app.trergn.TREFileReader.(TREFileReader.java:56)
  at
uk.me.parabola.mkgmap.combiners.FileInfo.treInfo(FileInfo.java:300)
  at
uk.me.parabola.mkgmap.combiners.FileInfo.imgInfo(FileInfo.java:283)
  at
uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:156)
  at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:612)
  at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125)
  at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144)
  at uk.me.parabola.mkgmap.main.Main.main(Main.java:115)

I use the same command for many other maps, including big ones like
Europe or North America without problems, only Asia fails. I can provide
all input files if necessary, but they sum several GB.

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



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

[mkgmap-dev] Another AssertionError

[Carlos Dávila]

I get the error reproduced below when I combine osm and contour lines 
precompiled tiles for the map of all Asia. Command line used is:


java -Xmx27G -ea -jar mkgmap_trunk.jar --gmapi --max-jobs --index 
--latin1 --code-page=1252 --description="OSM-$MAPA-Topo" 
--family-name="OSM $MAPA Topo" --family-id=3$FID --product-id=1 
--product-version=$VERSION --series-name="OSM-$MAPA-Topo" 
--area-name="$MAPA" --overview-mapname=$ABR-3$FID 
--overview-mapnumber=653${FID}000 --road-name-config=$CONFIG 
--x-mdr7-del=GRADE0,GRADE1,GRADE2,GRADE3,GRADE4,GRADE5,GRADE6,GRADE7,UNNAMED 
--show-profiles=1 tmp/551${FID}*.img curvas/602${FID}*.img 
typ/$ABR-3${FID}.TYP


Exception in thread "main" java.lang.AssertionError
    at 
uk.me.parabola.imgfmt.app.trergn.TREHeader.readFileHeader(TREHeader.java:107)
    at 
uk.me.parabola.imgfmt.app.CommonHeader.readHeader(CommonHeader.java:95)
    at 
uk.me.parabola.imgfmt.app.trergn.TREFileReader.(TREFileReader.java:56)
    at 
uk.me.parabola.mkgmap.combiners.FileInfo.treInfo(FileInfo.java:300)
    at 
uk.me.parabola.mkgmap.combiners.FileInfo.imgInfo(FileInfo.java:283)
    at 
uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:156)

    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:612)
    at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125)

    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144)
    at uk.me.parabola.mkgmap.main.Main.main(Main.java:115)

I use the same command for many other maps, including big ones like 
Europe or North America without problems, only Asia fails. I can provide 
all input files if necessary, but they sum several GB.


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

Re: [mkgmap-dev] Unable to build unicode map with index

[Carlos Dávila]

It works now, thanks!

El 22/9/20 a las 12:14, Gerd Petermann escribió:

Hi Carlos,

no idea why this didn't pop up before..
The program tries to write an index section (MDR12) which cannot work with 
unicode characters.
In fact I doubt that this section is of any use but mkgmap still writes it 
because it requires almost no space and maybe some old devices need it.

With r4584 this should be fixed.

Gerd






Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Dienstag, 22. September 2020 10:45
An: Development list for mkgmap
Betreff: [mkgmap-dev] Unable to build unicode map with index

Hello all

I am trying to build an unicode map of Israel or Greece but they always
fail with java.lang.AssertionError as soon as I add --index to command
line. I have tried both my own style and default one. Only if I use an
small osm file as input it succeeds. The simplest command line that
throws the error is:

java -Xmx3G -ea -jar mkgmap_trunk.jar --bounds=bounds.zip --route
--unicode --family-name="Test" --family-id=190 --product-id=1
--description="Test" --series-name="Test" --overview-mapname=5519
--mapname=5519 --index --style=default --remove-ovm-work-files=true
51178007.o5m
Time started: Tue Sep 22 10:37:47 CEST 2020
Number of MapFailedExceptions: 0
Exception in thread "main" java.lang.AssertionError: 914
  at
uk.me.parabola.imgfmt.app.FileBackedImgFileWriter.put1u(FileBackedImgFileWriter.java:166)
  at uk.me.parabola.imgfmt.app.mdr.Mdr8.writeSectData(Mdr8.java:45)
  at
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSection(MDRFile.java:421)
  at
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:373)
  at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:269)
  at
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:334)
  at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:675)
  at
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125)
  at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144)
  at uk.me.parabola.mkgmap.main.Main.main(Main.java:115)

Test files can be found are 51178007.o5m
<https://alternativaslibres.org/tmp/51178007.o5m> and jerusalem.o5m
<https://alternativaslibres.org/tmp/jerusalem.o5m>

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



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

[mkgmap-dev] Unable to build unicode map with index

[Carlos Dávila]

Hello all

I am trying to build an unicode map of Israel or Greece but they always 
fail with java.lang.AssertionError as soon as I add --index to command 
line. I have tried both my own style and default one. Only if I use an 
small osm file as input it succeeds. The simplest command line that 
throws the error is:


java -Xmx3G -ea -jar mkgmap_trunk.jar --bounds=bounds.zip --route 
--unicode --family-name="Test" --family-id=190 --product-id=1 
--description="Test" --series-name="Test" --overview-mapname=5519 
--mapname=5519 --index --style=default --remove-ovm-work-files=true 
51178007.o5m

Time started: Tue Sep 22 10:37:47 CEST 2020
Number of MapFailedExceptions: 0
Exception in thread "main" java.lang.AssertionError: 914
    at 
uk.me.parabola.imgfmt.app.FileBackedImgFileWriter.put1u(FileBackedImgFileWriter.java:166)

    at uk.me.parabola.imgfmt.app.mdr.Mdr8.writeSectData(Mdr8.java:45)
    at 
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSection(MDRFile.java:421)
    at 
uk.me.parabola.imgfmt.app.mdr.MDRFile.writeSections(MDRFile.java:373)

    at uk.me.parabola.imgfmt.app.mdr.MDRFile.write(MDRFile.java:269)
    at 
uk.me.parabola.mkgmap.combiners.MdrBuilder.onFinish(MdrBuilder.java:334)

    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:675)
    at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:125)

    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144)
    at uk.me.parabola.mkgmap.main.Main.main(Main.java:115)

Test files can be found are 51178007.o5m 
 and jerusalem.o5m 



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

Re: [mkgmap-dev] DEM display level.

[Carlos Dávila]

Are you sure BaseCamp doesn't also show DEM at 30 km-20 km zoom level in 
Mongolia map and 3000 km in Europe map?


El 14/9/20 a las 5:12, Joao Almeida escribió:

Hi,

I have a question about the behavior of mkgmap.
If I build 2 different maps using the same exact settings I get 2 
different outputs for DEM display.


Let me try to explain.

my settings for DEM :
--overview-dem-dist=8
--dem-dists=9942

If I build a map, let's say Mongolia, I have DEM rendering from zoom 
level 3000km in basecamp... obviously not very useful but it is there.


If I build another map, let's say of europe, the DEM rendering only 
occurs at zoomlevel 30km and below to 20m.


Does anyone know why?

Thank you
Joao

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



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

Re: [mkgmap-dev] precomp sea test environment

[Carlos Dávila]

I also face wrong sea from time to time. I agree a pre-check would be 
much useful. Also your sea-check style+empty tiles, thanks Gerd.


El 10/9/20 a las 11:27, Joris Bo escribió:

Hi Gerd

I recently (24-8-2020) had the same problem. The bad sea.zip was about 14Mb 
smaller then usual.
A pre-check and warning would be great.

Kind Regards
Joris

-Oorspronkelijk bericht-
Van: mkgmap-dev  Namens Gerd Petermann
Verzonden: donderdag 10 september 2020 11:16
Aan: mkgmap-dev@lists.mkgmap.org.uk
Onderwerp: [mkgmap-dev] precomp sea test environment

Hi all,

today I stumbled over a bad sea.zip file that was created in 2019-11-08. Most 
of the two Americas was flooded.
I wondered if I should add some code to mkgmap to detect this case?  Eg. mkgmap 
could check some points which are clearly inside continents.

Besides that it is rather simple to produce a test style for the sea which just 
creates an overview map. I've created some empty tiles which cover full planet 
and used them to create an overview map containing only sea polygons. This 
compilation takes ~1 minute. A quick glance at osmmap.img should show the 
familiar shapes of the continents, if not something is wrong and that probably 
means that the precomp-sea data is bad.
I've attached this, maybe it is of some help.

Gerd




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



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

Re: [mkgmap-dev] DEM There is not enough room in a single garmin map for all the input data

[Carlos Dávila]

El 1/9/20 a las 1:39, Joao Almeida escribió:


There is however a different behaviour, this only happens if I try to 
include different polygon areas, if I just try the same are by it self 
it does not throw the message about map too big.


Could you explain this a little bit further?

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

Re: [mkgmap-dev] DEM file options do not work

[Carlos Dávila]

Thanks Felix, I'll try it. I just preferred to have separate DEM/contour 
lines tiles, but combining them will be OK.


El 30/8/20 a las 18:02, Felix Hartmann escribió:
it's fine as long as you don't use empty maps. Just make a DEM 
contourlines layer. Not an DEM layer and a contourlines layer.


On Sun, 30 Aug 2020 at 16:15, Carlos Dávila 
mailto:car...@alternativaslibres.org>> 
wrote:


Hi Gerd
Does it mean it is imperative DEM tiles have the same bounding box
that
tiles containing OSM data? I ask because I have recently tried
building
DEM img's with no OSM data (empty style) and then combining them with
OSM tiles, in the same way I do with contour lines tiles, but
MapSource
crashes as soon as I click on "Show route profile" button. I would
like
to be able to reuse DEM tiles, so that it is not necessary to
build them
each time I update a map. This approach works fine for contour lines,
but I didn't succeed for DEM.
Regards,
Carlos

El 29/8/20 a las 7:48, Gerd Petermann escribió:
> Hi Bernard,
> AFAIK the only good solution is to have the DEM data in the tile
that
> contains the road data (NET,NOD). No idea why Garmin doesn't
support
> your approach.
>
> Ciao, Gerd
>
>
>
>  Bernard Mai schrieb 
>
> Dear Joris and Gerd,
>
> thanks for your elaborate answers.
>
> I think I have figured it out. Main problem was my misunderstanding
> where to put the dem-options. If I put them correctly into the
batch
> file which I use to generate the elevation .img files I get a nice
> hillshading in Garmin Basecamp. Still missing is the possibility to
> generate elevation profiles in Basecamp (using tracks generated in
> Basecamp) and to see the "height" on any position using the
> mousepointer. For this I have to puzzle harder or does somebody
have
> any idea?
>
> Here I include my working command line as it might be
interesting for
> the community. This results in a collection of .img files
containing
> elevation contour lines and hill shading:
>
> java -Xmx2000M -jar [...path to mkgmap ...]\mkgmap.jar
> --show-profiles=1 --dem=[...path to hgt file folder ...]
> --dem-interpolation=auto --dem-dists=3312,3312,13248,26512,53024
> --style-file=[...path to mkgmap style...] --transparent
> --draw-priority=20 --family-id=30 --mapname=9031 [...path to
> collection of splitted elevation data files ...]\9030*.osm.pbf
>
>
> Regards,
> Bernard

___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk <mailto:mkgmap-dev@lists.mkgmap.org.uk>
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev



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


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



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

Re: [mkgmap-dev] DEM file options do not work

[Carlos Dávila]

Hi Gerd
Does it mean it is imperative DEM tiles have the same bounding box that 
tiles containing OSM data? I ask because I have recently tried building 
DEM img's with no OSM data (empty style) and then combining them with 
OSM tiles, in the same way I do with contour lines tiles, but MapSource 
crashes as soon as I click on "Show route profile" button. I would like 
to be able to reuse DEM tiles, so that it is not necessary to build them 
each time I update a map. This approach works fine for contour lines, 
but I didn't succeed for DEM.

Regards,
Carlos

El 29/8/20 a las 7:48, Gerd Petermann escribió:

Hi Bernard,
AFAIK the only good solution is to have the DEM data in the tile that 
contains the road data (NET,NOD). No idea why Garmin doesn't support 
your approach.


Ciao, Gerd



 Bernard Mai schrieb 

Dear Joris and Gerd,

thanks for your elaborate answers.

I think I have figured it out. Main problem was my misunderstanding 
where to put the dem-options. If I put them correctly into the batch 
file which I use to generate the elevation .img files I get a nice 
hillshading in Garmin Basecamp. Still missing is the possibility to 
generate elevation profiles in Basecamp (using tracks generated in 
Basecamp) and to see the "height" on any position using the 
mousepointer. For this I have to puzzle harder or does somebody have 
any idea?


Here I include my working command line as it might be interesting for 
the community. This results in a collection of .img files containing 
elevation contour lines and hill shading:


java -Xmx2000M -jar [...path to mkgmap ...]\mkgmap.jar 
--show-profiles=1 --dem=[...path to hgt file folder ...] 
--dem-interpolation=auto --dem-dists=3312,3312,13248,26512,53024 
--style-file=[...path to mkgmap style...] --transparent 
--draw-priority=20 --family-id=30 --mapname=9031 [...path to 
collection of splitted elevation data files ...]\9030*.osm.pbf



Regards,
Bernard


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

[mkgmap-dev] Fwd: Re: "Small" SRTM1 files and DEM maps

[Carlos Dávila]

Hi Gerd

I replied to your patch a couple of months ago, but I have now realized 
it didn't arrive to the list (it seems I used and old address). I was 
surprised you didn't say anything, but didn't want to bother...


I used your binary for my test. Today I have tried to apply your patch, 
but it seems to be generated against a different version of files in trunk.




 Mensaje reenviado 
Asunto: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps
Fecha:  Tue, 21 Apr 2020 17:38:19 +0200
De:     Carlos Dávila 
Para:   mkgmap-dev@lists.mkgmap.org.uk



Hi Gerd
I have tested it in an area of 4x10 degrees, in the North of China, and 
it worked fine.


El 21/4/20 a las 14:40, Gerd Petermann escribió:

Hi Carlos,

please try the attached patch or this binary based on r4483:
http://files.mkgmap.org.uk/download/468/mkgmap.jar
I hope I found all the places that need to be changed. I've only 
tested with a map around the point N50 E118.


Gerd


Von: mkgmap-dev  im Auftrag 
von Carlos Dávila 

Gesendet: Dienstag, 21. April 2020 11:27
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Great new!! Thanks for your support

El 21/4/20 a las 11:19, Gerd Petermann escribió:

Hi Carlos,

yes, I see that the source code handles this format. I finally found
https://dds.cr.usgs.gov/srtm/version2_1/Documentation/MIL-PDF-89020B.pdf
I think "TABLE I. Matrix intervals for DTED Level 0."
shows how to interpret the data. It seems there are a few more 
variants...

For now I'll try to support also the 1801 * 3601 * 2 format

Gerd


Von: mkgmap-dev  im Auftrag 
von Carlos Dávila 

Gesendet: Donnerstag, 16. April 2020 17:41
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

HI Gerd
I don't think conversion is wrong. If input geotiff file is 24MB, output
hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB
I use this command on Linux:
for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i
`basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml
BTW, gdal is also able to deal with small SRTM files

El 16/4/20 a las 11:31, Gerd Petermann escribió:

Hi Carlos,

so your conversion routine is wrong. The file size is 12.970.802 
bytes. There is no integer n for which 2 * n^2 results in this value.


Gerd

____
Von: mkgmap-dev  im Auftrag 
von Carlos Dávila 

Gesendet: Donnerstag, 16. April 2020 11:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
Forgot to mention files are downloaded as geotiff, but I then convert
them to hgt, sorry.
You can download a sample one from
https://alternativaslibres.org/tmp/N50E118.hgt

El 16/4/20 a las 9:18, Gerd Petermann escribió:

Hi Carlos,

are you talking about geotiff format? I think someone documented 
how that format can be converted to *.hgt.

Can you post a link to such a file?

Gerd



________
Von: mkgmap-dev  im Auftrag 
von Carlos Dávila 

Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
||    if srtmVersion == 2.1:||
||    return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
||    elif srtmVersion == 3.0:||
||    if resolution == 1:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
||    elif resolution == 3:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
||    return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page 
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not 
compressed. Do you know from where these 12.4 MB files came from?


Gerd

____
Von: mkgmap-dev  im 
Auftrag von Carlos Dávila 

Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and report them as
missing. Would it be possible to get support fo

Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

[Carlos Dávila]

Great new!! Thanks for your support

El 21/4/20 a las 11:19, Gerd Petermann escribió:

Hi Carlos,

yes, I see that the source code handles this format. I finally found
https://dds.cr.usgs.gov/srtm/version2_1/Documentation/MIL-PDF-89020B.pdf
I think "TABLE I.  Matrix intervals for DTED Level 0."
shows how to interpret the data. It seems there are a few more variants...
For now I'll try to support also the 1801 * 3601 * 2 format

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 16. April 2020 17:41
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

HI Gerd
I don't think conversion is wrong. If input geotiff file is 24MB, output
hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB
I use this command on Linux:
for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i
`basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml
BTW, gdal is also able to deal with small SRTM files

El 16/4/20 a las 11:31, Gerd Petermann escribió:

Hi Carlos,

so your conversion routine is wrong. The file size is 12.970.802 bytes. There 
is no integer n for which 2 * n^2 results in this value.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 16. April 2020 11:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
Forgot to mention files are downloaded as geotiff, but I then convert
them to hgt, sorry.
You can download a sample one from
https://alternativaslibres.org/tmp/N50E118.hgt

El 16/4/20 a las 9:18, Gerd Petermann escribió:

Hi Carlos,

are you talking about geotiff format? I think someone documented how that 
format can be converted to *.hgt.
Can you post a link to such a file?

Gerd




Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
||    if srtmVersion == 2.1:||
||    return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
||    elif srtmVersion == 3.0:||
||    if resolution == 1:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
||    elif resolution == 3:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
||    return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page 
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not compressed. Do you 
know from where these 12.4 MB files came from?

Gerd

________
Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and report them as
missing. Would it be possible to get support for such files in mkgmap?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___

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

Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

[Carlos Dávila]

HI Gerd
I don't think conversion is wrong. If input geotiff file is 24MB, output 
hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB

I use this command on Linux:
for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i 
`basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml

BTW, gdal is also able to deal with small SRTM files

El 16/4/20 a las 11:31, Gerd Petermann escribió:

Hi Carlos,

so your conversion routine is wrong. The file size is 12.970.802 bytes. There 
is no integer n for which 2 * n^2 results in this value.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 16. April 2020 11:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
Forgot to mention files are downloaded as geotiff, but I then convert
them to hgt, sorry.
You can download a sample one from
https://alternativaslibres.org/tmp/N50E118.hgt

El 16/4/20 a las 9:18, Gerd Petermann escribió:

Hi Carlos,

are you talking about geotiff format? I think someone documented how that 
format can be converted to *.hgt.
Can you post a link to such a file?

Gerd




Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
||    if srtmVersion == 2.1:||
||    return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
||    elif srtmVersion == 3.0:||
||    if resolution == 1:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
||    elif resolution == 3:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
||    return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page 
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not compressed. Do you 
know from where these 12.4 MB files came from?

Gerd

____
Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and report them as
missing. Would it be possible to get support for such files in mkgmap?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___

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



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

Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

[Carlos Dávila]

This is what I have received by now:

The file with half size have probably width=1801 at higher latitudes 
(60deg I believe)


GDAL SRTMHGT driver source code at

https://github.com/OSGeo/gdal/blob/master/gdal/frmts/srtmhgt/srtmhgtdataset.cpp


I'm also awaiting for a reply from Earthexplorer...

El 17/4/20 a las 10:43, Gerd Petermann escribió:

Hi Carlos,

maybe you can ask the developers of gdal_translate?

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Freitag, 17. April 2020 10:32
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I also searched for info about this format before posting to the list,
but could not find anything either:-(

El 17/4/20 a las 6:19, Gerd Petermann escribió:

Hi all,

I could not find any information about this special format. Would be great if 
someone could point me to a detailed documentation.

Gerd


Von: Gerd Petermann 
Gesendet: Donnerstag, 16. April 2020 18:06
An: Carlos Dávila
Betreff: AW: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Carlos,

the hgt files are very simple. They contain an array of n * n 16-bit values, 
nothing else. The 16-bit value gives the elevation, and the file name gives the 
position of the southwest corner, see 
https://stackoverflow.com/questions/357415/how-to-read-nasa-hgt-binary-files
Maybe the 12.4 MB files use 8-bit values for the elevation, but 12.970.802 / 
3601 gives 3602, so there is probably an extra byte giving a delta value.
Coud not find a desription of this format so far. I'll try to find out more.

Gerd

________
Von: Carlos Dávila 
Gesendet: Donnerstag, 16. April 2020 17:39
An: Gerd Petermann
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

HI Gerd
I don't think conversion is wrong. If input geotiff file is 24MB, output
hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB
I use this command on Linux:
for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i
`basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml
BTW, gdal is also able to deal with small SRTM files

El 16/4/20 a las 11:31, Gerd Petermann escribió:

Hi Carlos,

so your conversion routine is wrong. The file size is 12.970.802 bytes. There 
is no integer n for which 2 * n^2 results in this value.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 16. April 2020 11:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
Forgot to mention files are downloaded as geotiff, but I then convert
them to hgt, sorry.
You can download a sample one from
https://alternativaslibres.org/tmp/N50E118.hgt

El 16/4/20 a las 9:18, Gerd Petermann escribió:

Hi Carlos,

are you talking about geotiff format? I think someone documented how that 
format can be converted to *.hgt.
Can you post a link to such a file?

Gerd



____
Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
||    if srtmVersion == 2.1:||
||    return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
||    elif srtmVersion == 3.0:||
||    if resolution == 1:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
||    elif resolution == 3:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
||    return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page 
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not compressed. Do you 
know from where these 12.4 MB files came from?

Gerd

________
Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and repo

Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

[Carlos Dávila]

I also searched for info about this format before posting to the list, 
but could not find anything either:-(


El 17/4/20 a las 6:19, Gerd Petermann escribió:

Hi all,

I could not find any information about this special format. Would be great if 
someone could point me to a detailed documentation.

Gerd


Von: Gerd Petermann 
Gesendet: Donnerstag, 16. April 2020 18:06
An: Carlos Dávila
Betreff: AW: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Carlos,

the hgt files are very simple. They contain an array of n * n 16-bit values, 
nothing else. The 16-bit value gives the elevation, and the file name gives the 
position of the southwest corner, see 
https://stackoverflow.com/questions/357415/how-to-read-nasa-hgt-binary-files
Maybe the 12.4 MB files use 8-bit values for the elevation, but 12.970.802 / 
3601 gives 3602, so there is probably an extra byte giving a delta value.
Coud not find a desription of this format so far. I'll try to find out more.

Gerd


Von: Carlos Dávila 
Gesendet: Donnerstag, 16. April 2020 17:39
An: Gerd Petermann
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

HI Gerd
I don't think conversion is wrong. If input geotiff file is 24MB, output
hgt file is 24 MB, if input tiff is 12MB, output hgt is 12MB
I use this command on Linux:
for i in *.tif ; do gdal_translate -strict -q -eco -of SRTMHGT $i
`basename $i tif`hgt ; done ; rm -f *.hgt.aux.xml
BTW, gdal is also able to deal with small SRTM files

El 16/4/20 a las 11:31, Gerd Petermann escribió:

Hi Carlos,

so your conversion routine is wrong. The file size is 12.970.802 bytes. There 
is no integer n for which 2 * n^2 results in this value.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 16. April 2020 11:19
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
Forgot to mention files are downloaded as geotiff, but I then convert
them to hgt, sorry.
You can download a sample one from
https://alternativaslibres.org/tmp/N50E118.hgt

El 16/4/20 a las 9:18, Gerd Petermann escribió:

Hi Carlos,

are you talking about geotiff format? I think someone documented how that 
format can be converted to *.hgt.
Can you post a link to such a file?

Gerd




Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
||    if srtmVersion == 2.1:||
||    return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
||    elif srtmVersion == 3.0:||
||    if resolution == 1:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
||    elif resolution == 3:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
||    return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page 
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not compressed. Do you 
know from where these 12.4 MB files came from?

Gerd

________
Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and report them as
missing. Would it be possible to get support for such files in mkgmap?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___

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



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

Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

[Carlos Dávila]

Hi Gerd
Forgot to mention files are downloaded as geotiff, but I then convert 
them to hgt, sorry.
You can download a sample one from 
https://alternativaslibres.org/tmp/N50E118.hgt


El 16/4/20 a las 9:18, Gerd Petermann escribió:

Hi Carlos,

are you talking about geotiff format? I think someone documented how that 
format can be converted to *.hgt.
Can you post a link to such a file?

Gerd




Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 13. April 2020 14:08
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into
phyghtmap files:
|def getSRTMFileServer(self, resolution, srtmVersion):||
||    if srtmVersion == 2.1:||
||    return
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||
||    elif srtmVersion == 3.0:||
||    if resolution == 1:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||
||    elif resolution == 3:||
||    urlRe =
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||
||    return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page 
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not compressed. Do you 
know from where these 12.4 MB files came from?

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and report them as
missing. Would it be possible to get support for such files in mkgmap?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___


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

Re: [mkgmap-dev] "Small" SRTM1 files and DEM maps

[Carlos Dávila]

Hi Gerd
They are downloaded by phyghtmap. This is what I found digging into 
phyghtmap files:

|def getSRTMFileServer(self, resolution, srtmVersion):||
||        if srtmVersion == 2.1:||
||            return 
"https://dds.cr.usgs.gov/srtm/version2_1/SRTM{0:d}".format(resolution)||

||        elif srtmVersion == 3.0:||
||            if resolution == 1:||
||                urlRe = 
"https://earthexplorer.usgs.gov/download/8360/SRTM1{:s}V3/GEOTIFF/EE;||

||            elif resolution == 3:||
||                urlRe = 
"https://earthexplorer.usgs.gov/download/4960/SRTM3{:s}V2/GEOTIFF3/EE;||

||            return urlRe|
They should come from the second URL above.

El 13/4/20 a las 8:24, Gerd Petermann escribió:

Hi Carlos,

sorry for the late response. I found no hint on the phyghtmap page 
http://katze.tfiu.de/projects/phyghtmap/
regarding a new format for srtm data. The hgt format is not compressed. Do you 
know from where these 12.4 MB files came from?

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Samstag, 11. April 2020 17:09
An: Development list for mkgmap
Betreff: [mkgmap-dev] "Small" SRTM1 files and DEM maps

I use phyghtmap to build contour lines and also to download hgt data
that I then use to build DEM maps with mkgmap. For a long time, SRTM1
files (and also VFP1) have all been ~24.7 MB in size, but lately (I
don't remember since when) SRTM1 are also served as 12.4 MB files.
phyghtmap is able to generate contour lines from those small files, as
they seem to contain the same information but with a different
compression ratio, but mkgmap fails to read them, and report them as
missing. Would it be possible to get support for such files in mkgmap?
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


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

[mkgmap-dev] "Small" SRTM1 files and DEM maps

[Carlos Dávila]

I use phyghtmap to build contour lines and also to download hgt data 
that I then use to build DEM maps with mkgmap. For a long time, SRTM1 
files (and also VFP1) have all been ~24.7 MB in size, but lately (I 
don't remember since when) SRTM1 are also served as 12.4 MB files. 
phyghtmap is able to generate contour lines from those small files, as 
they seem to contain the same information but with a different 
compression ratio, but mkgmap fails to read them, and report them as 
missing. Would it be possible to get support for such files in mkgmap?

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

Re: [mkgmap-dev] Problem with drive-on

[Carlos Dávila]

I agree it seems admin_level value is wrong. I've added a comment on 
changeset aobut it. A warning as you suggest may be useful to detect 
such cases.


El 6/12/19 a las 8:19, Gerd Petermann escribió:

Hi Carlos,

see https://www.openstreetmap.org/way/303677783 and 
https://www.openstreetmap.org/way/303677781
I guess the admin_level of those two ways is wrong. There are more ways in this 
area with admin_level=2.

To find them I've added
highway=* {echotags "c"}
as last line in the lines file to check what values the roads have in 
mkgmap:admin_level2 and mkgmap:country

Maybe I should add code in the boundary generator to warn when it stores a name 
for mkgmap:admin_level2 which doesn't
show up in LocatorConfig.xml?

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Donnerstag, 5. Dezember 2019 20:08
An: Carlos Dávila; mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with drive-on

Hi Carlos,

seems my file was even older. I can reproduce the problem with the bounds file 
created 2019-11-29.
I'll have a closer look tomorrow.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Donnerstag, 5. Dezember 2019 19:58
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Problem with drive-on

I have just realized my bounds.zip file is more than one year old (it
should be automatically updated every week=-O). I'll try with a new one.

El 5/12/19 a las 15:13, Gerd Petermann escribió:

Hi Carlos,

I just tried to reproduce the problem. I've downloaded the area in your bbox (a 
bit larger) to file in.osm.pbf
and used splitter to cut out your area with
java -jar splitter.jar --split-file=areas.list in.osm.pbf
Then I used
java -jar mkgmap.jar --drive-on=detect --bounds=bounds.zip --route 
63240001.osm.pbf
I don't see the message.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 4. Dezember 2019 21:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with drive-on

Hi Carlos,

My understanding is that your style (or the bounds file) sets at least two 
different mkgmap:country values for the tile.
Maybe you can post a link to that tile?

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Mittwoch, 4. Dezember 2019 12:15
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with drive-on

I am preparing an  areas.list file to split Oceania, so that each tile
contains only roads driven on the same side. I have found a tile where
all roads should be driven on left side, as it all lies within
Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695)
and drive-on-right roads (57)". I have reduced tile size to narrow down
the problem. These are its coordinates: -288768,6178816 to
-210944,6219776. It includes two islands, right one is detected by
mkgmap as right side driven, but it is left driven (to my knowledge).
Any idea why this happens?





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

Re: [mkgmap-dev] Problem with drive-on

[Carlos Dávila]

I have just realized my bounds.zip file is more than one year old (it 
should be automatically updated every week=-O). I'll try with a new one.


El 5/12/19 a las 15:13, Gerd Petermann escribió:

Hi Carlos,

I just tried to reproduce the problem. I've downloaded the area in your bbox (a 
bit larger) to file in.osm.pbf
and used splitter to cut out your area with
java -jar splitter.jar --split-file=areas.list in.osm.pbf
Then I used
java -jar mkgmap.jar --drive-on=detect --bounds=bounds.zip --route 
63240001.osm.pbf
I don't see the message.

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 4. Dezember 2019 21:16
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Problem with drive-on

Hi Carlos,

My understanding is that your style (or the bounds file) sets at least two 
different mkgmap:country values for the tile.
Maybe you can post a link to that tile?

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Mittwoch, 4. Dezember 2019 12:15
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with drive-on

I am preparing an  areas.list file to split Oceania, so that each tile
contains only roads driven on the same side. I have found a tile where
all roads should be driven on left side, as it all lies within
Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695)
and drive-on-right roads (57)". I have reduced tile size to narrow down
the problem. These are its coordinates: -288768,6178816 to
-210944,6219776. It includes two islands, right one is detected by
mkgmap as right side driven, but it is left driven (to my knowledge).
Any idea why this happens?


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


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

[mkgmap-dev] Problem with drive-on

[Carlos Dávila]

I am preparing an  areas.list file to split Oceania, so that each tile 
contains only roads driven on the same side. I have found a tile where 
all roads should be driven on left side, as it all lies within 
Indonesia, but mkgmap reports "Tile contains both drive-on-left (2695) 
and drive-on-right roads (57)". I have reduced tile size to narrow down 
the problem. These are its coordinates: -288768,6178816 to 
-210944,6219776. It includes two islands, right one is detected by 
mkgmap as right side driven, but it is left driven (to my knowledge). 
Any idea why this happens?



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

[mkgmap-dev] Building map with Hebrew characters

[Carlos Dávila]

I'm trying to build a map of Israel with Hebrew characters, but using 
--code-page=1255 a get the following assertion:


at uk.me.parabola.imgfmt.app.srt.SRTFile.writeWeights(SRTFile.java:117)
    at 
uk.me.parabola.imgfmt.app.srt.SRTFile.writeSrt4Chars(SRTFile.java:99)

    at uk.me.parabola.imgfmt.app.srt.SRTFile.write(SRTFile.java:63)
    at 
uk.me.parabola.mkgmap.combiners.MdrBuilder.init(MdrBuilder.java:117)

    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:605)
    at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)

    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143)
    at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)

With --unicode I also get an assertion:
Exception in thread "main" java.lang.AssertionError: -125
    at 
uk.me.parabola.imgfmt.app.BufferedImgFileWriter.put1u(BufferedImgFileWriter.java:154)
    at 
uk.me.parabola.imgfmt.app.SectionWriter.put1u(SectionWriter.java:78)
    at 
uk.me.parabola.imgfmt.app.srt.SRTFile.writeWeights(SRTFile.java:113)
    at 
uk.me.parabola.imgfmt.app.srt.SRTFile.writeSrt8(SRTFile.java:166)

    at uk.me.parabola.imgfmt.app.srt.SRTFile.write(SRTFile.java:68)
    at 
uk.me.parabola.mkgmap.combiners.MdrBuilder.init(MdrBuilder.java:117)

    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:605)
    at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)

    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143)
    at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)

Probably I'm missing something obvious, but I always used 
--code-page=1251 and have no idea what it may be


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

[mkgmap-dev] Problem sending maps to device with latest versions of BaseCamp

[Carlos Dávila]

Hi all

In the last two months or so I have received several complains from 
users of my maps reporting when they send map to device via BaseCamp, 
although process is completed successfully, map is not loaded in device 
or only partially. 4.6.2 seems to be last version sending maps 
correctly. Is it a bug in BaseCamp (or something intended by Garmin) or 
may be a problem in mkgmap generated maps?


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

Re: [mkgmap-dev] Commit r4244: Reduce number of includes in default style

[Carlos Dávila]

Sorry, I was looking at my own style, which I thought was like default 
in this part.


El 25/9/18 a las 7:54, Gerd Petermann escribió:

Hi Carlos,

both rules exist in the points file, the include duplicated them.

Gerd


Von: mkgmap-dev  im Auftrag von Carlos Dávila 

Gesendet: Montag, 24. September 2018 23:11
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Commit r4244: Reduce number of includes in default 
style

El 24/9/18 a las 9:37, svn commit escribió:

Version mkgmap-r4244 was committed by gerd on Mon, 24 Sep 2018

Reduce number of includes in default style

The removed includes were only included in one file and some rules were 
repeated.
unIncDefault.patch by Ticker Berkin





I've noticed this commit removes the rules
landuse=military [0x640b resolution 24]
landuse=village_green & name=* [0x2c06 resolution 24]

from landuse_points,

but doesn't add the same lines to points file. Is it intended?



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

Re: [mkgmap-dev] Commit r4244: Reduce number of includes in default style

[Carlos Dávila]

El 24/9/18 a las 9:37, svn commit escribió:

Version mkgmap-r4244 was committed by gerd on Mon, 24 Sep 2018

Reduce number of includes in default style

The removed includes were only included in one file and some rules were 
repeated.
unIncDefault.patch by Ticker Berkin





I've noticed this commit removes the rules
landuse=military [0x640b resolution 24]
landuse=village_green & name=* [0x2c06 resolution 24]

from landuse_points,

but doesn't add the same lines to points file. Is it intended?

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

Re: [mkgmap-dev] osmconvert64

[Carlos Dávila]

El 17/05/18 a las 14:35, Manfred Haiduk escribió:
I've played again with my map creation because i discovered a new 
phenomenom (only at map source or base camp, not on my GPSMAP276Cx). 
At the attached picture you see two icons at the place of a waterfall, 
the right one and curiosly an aircraft symbol. To find out whats 
happening, i deleted the aircraft symbol from my style and all 
requests in the style files to disply this icon. But mapsource and 
base camp do still display the wrong aircraft icon.Any thoughts, where 
i can search ? 
I'm suffering a similar problem since a couple of months or more. 
Estrange icons are displayed on MapSource, even icons I do not have in 
my TYP. I thought it could be related to using MapSource under wine on 
Linux, but now I see I'm not the only one with this issue

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

[mkgmap-dev] Unspecific warning

[Carlos Dávila]

What the meaning of this kind of warnings? What data should be fixed to 
avoid them?


(ExtNumbers): 55171060.o5m: can't change intervals, road has already 250 
points



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

[mkgmap-dev] Current state of --dem-reuse option

[Carlos Dávila]

Hi Gerd
Have you done any further development of option --x-dem-reuse mentioned 
at http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2018q1/027951.html ?


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

[mkgmap-dev] LocatorConfig patch

[Carlos Dávila]

Attached patch fixes a " Tile contains both drive-on-left and 
drive-on-right roads" warning compiling map of Cyprus island
Index: resources/LocatorConfig.xml
===
--- resources/LocatorConfig.xml	(revisión: 4127)
+++ resources/LocatorConfig.xml	(copia de trabajo)
@@ -156,6 +156,9 @@
 		IO
 		IOT
 	
+	
+		SBA
+	
 	
 		BN
 		BRN
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Change splitter Total time taken format the same than mkgmap

[Carlos Dávila]

Attached is a patch that sets the same time format that was recently 
changed for mkgmap. I just copied the changes from mkgmap (I'm not a 
developer), so please check if it's correct before commit.
Index: src/uk/me/parabola/splitter/Main.java
===
--- src/uk/me/parabola/splitter/Main.java	(revisión: 590)
+++ src/uk/me/parabola/splitter/Main.java	(copia de trabajo)
@@ -15,6 +15,8 @@
 
 import java.io.File;
 import java.io.IOException;
+import java.time.Duration;
+import java.time.Instant;
 import java.util.Arrays;
 import java.util.Date;
 import java.util.List;
@@ -101,7 +103,7 @@
 			healthMonitor.start();
 		}
 
-		long start = System.currentTimeMillis();
+		Instant start = Instant.now();
 		System.out.println("Time started: " + new Date());
 		try {
 			// configure the input file handler
@@ -149,7 +151,20 @@
 			return 1;
 		}
 		System.out.println("Time finished: " + new Date());
-		System.out.println("Total time taken: " + (System.currentTimeMillis() - start) / 1000 + 's');
+		Duration duration = Duration.between(start, Instant.now());
+		long seconds = duration.getSeconds();
+		if (seconds > 0) {
+			long hours = seconds / 3600;
+			seconds -= hours * 3600;
+			long minutes = seconds / 60;
+			seconds -= minutes * 60;
+			System.out.println("Total time taken: " + 
+	(hours > 0 ? hours + (hours > 1 ? " hours " : " hour ") : "") +
+	(minutes > 0 ? minutes + (minutes > 1 ? " minutes " : " minute ") : "") +
+	(seconds > 0 ? seconds + (seconds > 1 ? " seconds" : " second") : ""));
+}
+		else
+			System.out.println("Total time taken: " + duration.getNano() / 100 + " ms");
 		return rc;
 	}
 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

[mkgmap-dev] Error building DEM map

[Carlos Dávila]

I'm facing an error compiling Algeria map with DEM, using SRTM1 hgt 
files. In a first run I use splitter as follows: java -Xmx6G -jar 
splitter.jar --max-nodes=200 
--geonames-file=geonames/cities15000_$ABR.zip --mapid=551${FID}001 
--output=o5m algeria.o5m
It gives 5 tiles and when I run mkgmap on them [1], it takes a very long 
time and finally it fails with "Number of MapFailedExceptions: 1" and a 
huge (+7GB) log file I could not read.
I have manually split problematic tile to a half its original size and 
then both resulting tiles fail to compile. After dividing them /2, 3 of 
the 4 tiles fail, but then mkgmap gives the following error:

Exception in thread "main" java.lang.NegativeArraySizeException
    at 
uk.me.parabola.mkgmap.reader.hgt.HGTConverter.(HGTConverter.java:85)

    at uk.me.parabola.imgfmt.app.dem.DEMFile.calc(DEMFile.java:76)
    at 
uk.me.parabola.mkgmap.build.MapBuilder.makeMap(MapBuilder.java:341)
    at 
uk.me.parabola.mkgmap.combiners.OverviewBuilder.writeOverviewMap(OverviewBuilder.java:191)
    at 
uk.me.parabola.mkgmap.combiners.OverviewBuilder.onFinish(OverviewBuilder.java:104)

    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:679)
    at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)

    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143)
    at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)
And log contains over 10⁷ lines like this: WARNING (HGTConverter): 
55129161.o5m: height interpolation returns void at 30.837045,2.094557

After 2 more /2 divisions I could build all tiles.
The smallest failing tile can be downloaded from 
http://alternativaslibres.org/tmp/55129083.o5m


[1] java -Xmx4500m -ea -Dlog.config=logging.properties -jar mkgmap.jar 
--block-size=2048 --dem=hgt/VIEW1,hgt/SRTM1,hgt/EU-DEM,hgt/VIEW3,hgt 
--dem-poly=polygons/$pais.poly --dem-dists=3312,6624,9936,13248,26512 
--overview-dem-dist=128000 --output-dir=./tmp --gmapi --show-profiles=1 
--bounds=bounds.zip --precomp-sea=sea.zip --max-jobs --route --latin1 
--code-page=1252 --country-name=$PAIS --country-abbr=$ABR 
--area-name=$MAPA --family-name="OSM $MAPA DEM" --family-id=5$FID 
--product-id=1 --product-version=$VERSION --series-name="OSM-$MAPA-DEM" 
--overview-mapname=$ABR-5$FID --overview-mapnumber=555${FID}000 
--name-tag-list=$NAMETAG --index --process-destination --process-exits 
--housenumbers --reduce-point-density=4 --polygon-size-limits="24:12, 
18:10, 16:0" --add-pois-to-areas --link-pois-to-ways 
--location-autofill=is_in,nearest --drive-on=detect,$DRIVEON 
--check-roundabouts --check-roundabout-flares 
--license-file=license_OSM_${HGT} --copyright-file=copyright $LANGUAGE 
--road-name-config=$CONFIG 
--x-mdr7-del=GRADE0,GRADE1,GRADE2,GRADE3,GRADE4,GRADE5,GRADE6,GRADE7,UNNAMED 
--style=mio --remove-ovm-work-files=true -c ${pais}-DEM.args


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

[mkgmap-dev] Maps aspect ratio

[Carlos Dávila]

One user of my maps has commented that in my maps longitude looks much 
shorter than latitude. Comparing the same area in three maps 
(CityNavigator, OpenFiestMap and my maps) they all show different aspect 
ratio [1]. Do you know reason for that? Any way to control it?

[1] |http://files.mkgmap.org.uk/download/423/Screenshots.zip|
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Commit r4124: slightly modified maxjobs-v6.patch by Mike Baggaley

[Carlos Dávila]

El 19/02/18 a las 14:53, svn commit escribió:

Version mkgmap-r4124 was committed by gerd on Mon, 19 Feb 2018

slightly modified maxjobs-v6.patch by Mike Baggaley

-- if max-jobs option is not set, try to find a reasonable value
-- further improve documentation of options
-- report run time in hours, minutes and seconds instead of ms

http://www.mkgmap.org.uk/websvn/revision.php?repname=mkgmap=4124


I get an error with this build when combining contour lines with OSM map:
java -ea -Xmx4500M -jar mkgmap.jar --output-dir=./tmp --gmapi --tdbfile 
--latin1 --code-page=1252 --description="OSM+$CURVAS-$MAPA" 
--country-name=$PAIS --country-abbr=$ABR --family-name="OSM+$CURVAS 
$MAPA" --family-id=3$FID --product-id=1 --product-version=$VERSION 
--series-name="OSM+$CURVAS $MAPA" --area-name="$MAPA" 
--overview-mapname=$ABR-3$FID --overview-mapnumber=653${FID}000 --index 
--road-name-config=$CONFIG 
--x-mdr7-del=GRADE0,GRADE1,GRADE2,GRADE3,GRADE4,GRADE5,GRADE6,GRADE7,UNNAMED 
--show-profiles=1 tmp/551${FID}*.img curvas/602${FID}*.img 
typ/$ABR-3${FID}.TYP

Time started: Mon Feb 19 18:09:18 CET 2018
Exception in thread "main" java.lang.ArithmeticException: / by zero
    at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:513)
    at 
uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:128)

    at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:143)
    at uk.me.parabola.mkgmap.main.Main.main(Main.java:114)
It happens with all maps with the same command
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Please test r4116

[Carlos Dávila]

El 14/02/18 a las 15:44, Gerd Petermann escribió:

Hi all,

Please try r4116 [1] with normal splitter. I hope you don't see any more crashes in 
MapSource with the "Show Profile..." button
or corresponding empty "Graphs"  in Basecamp, even if you hgt files contain 
voids or if you use --dem-poly option.

I also did not see any problems with routing, so I hope that the description 
for field at offset 0x3f in the wiki [2] is simply wrong.

Gerd

[1] http://www.mkgmap.org.uk/download/mkgmap-dem-tdb-r4116.zip
[2] https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/TRE_Subfile_Format



No crashes here either
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Problem with gmapi-builder

[Carlos Dávila]

Hi Gerd
When mkgmap added --gmapi option I did some test and found that mkgmap 
(without --gmapi)+gmapi-builder was a little faster than mkgmap with 
--gmapi, that's why I continued using gmapi-builder. Perhaps it's time 
to change my toolchain (I alredy did for DEM maps)


El 09/02/18 a las 19:43, Gerd Petermann escribió:

Hi Carlos,

maybe gmapi-builder.py cannot handle block sizes <> 512?
Why do you that tool and not the --gmapi option ?

Gerd


Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila 
<cdavi...@orangecorreo.es>
Gesendet: Freitag, 9. Februar 2018 19:40
An: Development list for mkgmap
Betreff: [mkgmap-dev] Problem with gmapi-builder

Since mkgmap r4092 I get errors like "Missing part: 0 of GARMIN .RGN in
IMG-file" or "Missing part: 0 of ~�?�.�� in IMG-file" when I use
gmapi-builder.py to transform maps to gmap format. r4091 works fine with
gmapi-builder.
Resulting *.gmapi folder is almost empty with r4092 and above.



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

[mkgmap-dev] Problem with gmapi-builder

[Carlos Dávila]

Since mkgmap r4092 I get errors like "Missing part: 0 of GARMIN .RGN in 
IMG-file" or "Missing part: 0 of ~�?�.�� in IMG-file" when I use 
gmapi-builder.py to transform maps to gmap format. r4091 works fine with 
gmapi-builder.

Resulting *.gmapi folder is almost empty with r4092 and above.
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev