Re: [mkgmap-dev] Tiles pruned in DEM map
Hi I compiled europe.osm.pdf with r4600 and did not encounter any errors. + Merged DEM from Freizeitkarte + Contourlines + Routing 1884 IMG files, 15.8Gb an Overviewmap of 29.684 kB and the index is 757Mb Thanks a lot Gr Joris Met vriendelijke groeten, Joris Bo jori...@hotmail.com -Oorspronkelijk bericht- Van: mkgmap-dev Namens Gerd Petermann Verzonden: dinsdag 26 januari 2021 18:37 Aan: Development list for mkgmap Onderwerp: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Carlos, I assume you meant 4.5 MB. I am not sure about the limits, is it 16MB for a single sub file (RGN, DEM etc) or 16MB for one *.img? Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Dienstag, 26. Januar 2021 15:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map 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 ___ 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
Hi Carlos, I assume you meant 4.5 MB. I am not sure about the limits, is it 16MB for a single sub file (RGN, DEM etc) or 16MB for one *.img? Gerd Von: mkgmap-dev im Auftrag von Carlos Dávila Gesendet: Dienstag, 26. Januar 2021 15:52 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map 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 ___ 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
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
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] Tiles pruned in DEM map
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
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
Re: [mkgmap-dev] Tiles pruned in DEM map
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 Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 23. Januar 2021 12:04 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd I hadn't rebuilt after taking your patch. You had removed a declaration of bounds, exposing a different one. Patch attached. Ticker On Sat, 2021-01-23 at 10:27 +, Gerd Petermann wrote: > Hi Ticker, > > I used mkgmap r4597 patched with overview-v5.patch on the output of > splitter with Rankos split command: > E:\rj-mp-split>java -jar d:\mkgmap\dist\mkgmap.jar 8014.osm.pbf > Time started: Sat Jan 23 11:23:51 CET 2021 > Number of MapFailedExceptions: 0 > Exception in thread "main" java.lang.NullPointerException: Cannot > invoke "uk.me.parabola.imgfmt.app.Area.getMaxDimension()" because > "detailTileBounds" is null > at > uk.me.parabola.mkgmap.combiners.OverviewBuilder.checkFixRes(OverviewB > uilder.java:146) > at > uk.me.parabola.mkgmap.combiners.OverviewBuilder.addMapCoverageArea(Ov > erviewBuilder.java:397) > at > uk.me.parabola.mkgmap.combiners.OverviewBuilder.readFileIntoOverview( > OverviewBuilder.java:264) > at > uk.me.parabola.mkgmap.combiners.OverviewBuilder.onMapEnd(OverviewBuil > der.java:89) > at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:649) > at > uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja > va:125) > at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144) > at uk.me.parabola.mkgmap.main.Main.main(Main.java:115) > > > No such exception with unpatched mkgmap. > > Gerd > > ____ > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Samstag, 23. Januar 2021 11:20 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I've just tried this and don't get a problem (with or without -ea) > > I used Ranko's osm.pbf, splitter-r595 and my development mkgmap which > is trunk + overview patch + couple of trivial changes. > > Where were you getting the exception? > > Ticker > > > On Sat, 2021-01-23 at 07:18 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I just got a NullPointerException looking at the example from > > Ranko. > > Happens when I create a map without any option, just > > java -jar mkgmap.jar 8014.osm.pbf > > > > 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
Hi Gerd
I hadn't rebuilt after taking your patch. You had removed a declaration
of bounds, exposing a different one.
Patch attached.
Ticker
On Sat, 2021-01-23 at 10:27 +, Gerd Petermann wrote:
> Hi Ticker,
>
> I used mkgmap r4597 patched with overview-v5.patch on the output of
> splitter with Rankos split command:
> E:\rj-mp-split>java -jar d:\mkgmap\dist\mkgmap.jar 8014.osm.pbf
> Time started: Sat Jan 23 11:23:51 CET 2021
> Number of MapFailedExceptions: 0
> Exception in thread "main" java.lang.NullPointerException: Cannot
> invoke "uk.me.parabola.imgfmt.app.Area.getMaxDimension()" because
> "detailTileBounds" is null
> at
> uk.me.parabola.mkgmap.combiners.OverviewBuilder.checkFixRes(OverviewB
> uilder.java:146)
> at
> uk.me.parabola.mkgmap.combiners.OverviewBuilder.addMapCoverageArea(Ov
> erviewBuilder.java:397)
> at
> uk.me.parabola.mkgmap.combiners.OverviewBuilder.readFileIntoOverview(
> OverviewBuilder.java:264)
> at
> uk.me.parabola.mkgmap.combiners.OverviewBuilder.onMapEnd(OverviewBuil
> der.java:89)
> at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:649)
> at
> uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.ja
> va:125)
> at uk.me.parabola.mkgmap.main.Main.mainStart(Main.java:144)
> at uk.me.parabola.mkgmap.main.Main.main(Main.java:115)
>
>
> No such exception with unpatched mkgmap.
>
> Gerd
>
>
> Von: mkgmap-dev im Auftrag
> von Ticker Berkin
> Gesendet: Samstag, 23. Januar 2021 11:20
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
>
> Hi Gerd
>
> I've just tried this and don't get a problem (with or without -ea)
>
> I used Ranko's osm.pbf, splitter-r595 and my development mkgmap which
> is trunk + overview patch + couple of trivial changes.
>
> Where were you getting the exception?
>
> Ticker
>
>
> On Sat, 2021-01-23 at 07:18 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > I just got a NullPointerException looking at the example from
> > Ranko.
> > Happens when I create a map without any option, just
> > java -jar mkgmap.jar 8014.osm.pbf
> >
> > 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-devIndex: src/uk/me/parabola/imgfmt/app/map/Map.java
===
--- src/uk/me/parabola/imgfmt/app/map/Map.java (revision 4597)
+++ src/uk/me/parabola/imgfmt/app/map/Map.java (working copy)
@@ -70,6 +70,7 @@
private NETFile netFile;
private NODFile nodFile;
private DEMFile demFile;
+ private boolean isOverviewCombined;
// Use createMap() or loadMap() instead of creating a map directly.
private Map() {
@@ -89,7 +90,7 @@
* @throws FileNotWritableException If the file cannot
* be opened for write.
*/
- public static Map createMap(String mapname, String outputdir, FileSystemParam params, String mapnumber, Sort sort)
+ public static Map createMap(String mapname, String outputdir, FileSystemParam params, String mapnumber, Sort sort, boolean overviewCombined)
throws FileExistsException, FileNotWritableException
{
Map m = new Map();
@@ -103,6 +104,7 @@
m.rgnFile = new RGNFile(m.fileSystem.create(mapnumber + ".RGN"));
m.treFile = new TREFile(m.fileSystem.create(mapnumber + ".TRE"));
m.lblFile = new LBLFile(m.fileSystem.create(mapnumber + ".LBL"), sort);
+ m.isOverviewCombined = overviewCombined;
int mapid;
try {
@@ -118,8 +120,9 @@
}
public void config(EnhancedProperties props) {
+ boolean isOverviewComponent = OverviewBuilder.isOverviewImg(mapName);
// we don't want routing info in the overview map (for now)
- if (!OverviewBuilder.isOverviewImg(mapName)){
+ if (!isOverviewComponent && !isOverviewCombined) {
try {
if (props.containsKey("route") || props.containsKey("net") || props.containsKey("housenumbers")) {
addNet();
@@ -130,6 +133,11 @@
} catch (FileExistsException e) {
log.warn("Could not add NET and/or NOD sections");
}
+ // this sets things like draw-priority/transparent/custom
+ // and not relevant to overview maps
+ treFile.config(props);
+ }
+ if (!isOverviewComponent) { // allow dem on final overview but not in the ovm_
if (props.containsKey("dem")) {
try {
addDem();
@@ -138,7 +1
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, I used mkgmap r4597 patched with overview-v5.patch on the output of splitter with Rankos split command: E:\rj-mp-split>java -jar d:\mkgmap\dist\mkgmap.jar 8014.osm.pbf Time started: Sat Jan 23 11:23:51 CET 2021 Number of MapFailedExceptions: 0 Exception in thread "main" java.lang.NullPointerException: Cannot invoke "uk.me.parabola.imgfmt.app.Area.getMaxDimension()" because "detailTileBounds" is null at uk.me.parabola.mkgmap.combiners.OverviewBuilder.checkFixRes(OverviewBuilder.java:146) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.addMapCoverageArea(OverviewBuilder.java:397) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.readFileIntoOverview(OverviewBuilder.java:264) at uk.me.parabola.mkgmap.combiners.OverviewBuilder.onMapEnd(OverviewBuilder.java:89) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:649) 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) No such exception with unpatched mkgmap. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Samstag, 23. Januar 2021 11:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd I've just tried this and don't get a problem (with or without -ea) I used Ranko's osm.pbf, splitter-r595 and my development mkgmap which is trunk + overview patch + couple of trivial changes. Where were you getting the exception? Ticker On Sat, 2021-01-23 at 07:18 +, Gerd Petermann wrote: > Hi Ticker, > > I just got a NullPointerException looking at the example from Ranko. > Happens when I create a map without any option, just > java -jar mkgmap.jar 8014.osm.pbf > > 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] Tiles pruned in DEM map
Hi Gerd I've just tried this and don't get a problem (with or without -ea) I used Ranko's osm.pbf, splitter-r595 and my development mkgmap which is trunk + overview patch + couple of trivial changes. Where were you getting the exception? Ticker On Sat, 2021-01-23 at 07:18 +, Gerd Petermann wrote: > Hi Ticker, > > I just got a NullPointerException looking at the example from Ranko. > Happens when I create a map without any option, just > java -jar mkgmap.jar 8014.osm.pbf > > Gerd ___ 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
Hi Ticker, seems you are right regarding the 0x4a polygons. The (unpatched) code doesn't work as I expected. I must confess that I don't know for sure how it is expected to work, though. We have code in the polish reader to use 0x4a polygons "as is" and that seems to work, but it is meant for overview maps in *.mp format, not for single tiles. I thought we have code to translate 0x4b polygons in the *.mp file to an 0x4a polygon in the overview map, but I can't find that, not even in svn history of trunk. Maybe it was something that I tried only in a branch. Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Samstag, 23. Januar 2021 08:18 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Ticker, I just got a NullPointerException looking at the example from Ranko. Happens when I create a map without any option, just java -jar mkgmap.jar 8014.osm.pbf Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 21. Januar 2021 18:45 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd This hasn't changed. For each input ovm_ img it gets an Area from FileInfo.getBounds() then makes a 0x4a polygon from this, setting it's name to the tile "Descriptions \n Mapname". I've not found anything in recent versions that do anything different, including suppressing the above if it finds an existing 0x4a in the input. Ticker On Thu, 2021-01-21 at 15:45 +, Gerd Petermann wrote: > Hi Ticker, > > oops, I wanted to remove the foreach loop. Anyway, my understanding > is that the new code doesn't allow non-rectangular 0x4a shapes in the > overview map while the old code did, at least when a *.mp file > contains a non-rectangular 0x4a polygon. So, if the ovm_* file > contains a 0x4a polygon we should use that. > I just looked at the overview map for the Adria demo map and it has > non-rectangular 0x4a polygons (close to the country boundaries ) > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 21. Januar 2021 16:28 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Each 0x4a polygon generated by the OverviewBuilder corresponds to a > detail tile and I avoided changing anything relating to this except > stopping them getting chopped up into SubDivisions by the --order-by > logic (the initial reason for this thread) and outputting them before > the other polygons in the detail tile area. > > If the detail tiles are transparent (implemented as none of the input > tiles having a 0x4b polygon), OverviewBuilder adds one. It is > generated > as a rectangle covering all the detail tiles rather than the shape of > all the tiles. I've not changed this apart from outputting it first. > > A shape that matches all the detail tiles is generated for use by the > DEM overview and could, maybe, be used for the 0x4b. I don't think > this > is worth doing as part of this change. > > I haven't made any changes to existing polygons that are input into > OverviewBuilder (from whatever source); all, including 0x4a and 0x4b > are passed on. It is unlikely that a user defined 0x4a polygon would > be > correctly set up, and, as seen by Carlos in his Australia map, > getting > it wrong has very strange effects as you zoom in and out of the > overview. > > I've attached a slightly updated patch - it looks like there was a > for > loop that should have been deleted when replaced by a forEach in > OverviewBuilder::addMapCoverageArea > > Ticker > > On Thu, 2021-01-21 at 06:48 +, Gerd Petermann wrote: > > Hi Ticker, > > > > sorry for the delay, I started a very time consuming mapping in my > > area to unglue landuse areas from highways > > > > I looked at overview-v3.patch in more detail. I don't understand > > the > > changes regarding 0x4a polygons. I am not sure but I think it is a > > step in the wrong direction. I think one goal is to allow arbitrary > > polygons with 0x4 with OSM input (similar to the --dem-polygon) as > > we > > already do with polish (*.mp) format. So, you should not assume > > that > > the 0x4a polygon is a rectangle. I might be confusing this with > > 0x4b > > though. > > Besides that I changed a few things to improve readability. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 13. Januar 2021 11:01 > > An: Devel
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, I just got a NullPointerException looking at the example from Ranko. Happens when I create a map without any option, just java -jar mkgmap.jar 8014.osm.pbf Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 21. Januar 2021 18:45 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd This hasn't changed. For each input ovm_ img it gets an Area from FileInfo.getBounds() then makes a 0x4a polygon from this, setting it's name to the tile "Descriptions \n Mapname". I've not found anything in recent versions that do anything different, including suppressing the above if it finds an existing 0x4a in the input. Ticker On Thu, 2021-01-21 at 15:45 +, Gerd Petermann wrote: > Hi Ticker, > > oops, I wanted to remove the foreach loop. Anyway, my understanding > is that the new code doesn't allow non-rectangular 0x4a shapes in the > overview map while the old code did, at least when a *.mp file > contains a non-rectangular 0x4a polygon. So, if the ovm_* file > contains a 0x4a polygon we should use that. > I just looked at the overview map for the Adria demo map and it has > non-rectangular 0x4a polygons (close to the country boundaries ) > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 21. Januar 2021 16:28 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Each 0x4a polygon generated by the OverviewBuilder corresponds to a > detail tile and I avoided changing anything relating to this except > stopping them getting chopped up into SubDivisions by the --order-by > logic (the initial reason for this thread) and outputting them before > the other polygons in the detail tile area. > > If the detail tiles are transparent (implemented as none of the input > tiles having a 0x4b polygon), OverviewBuilder adds one. It is > generated > as a rectangle covering all the detail tiles rather than the shape of > all the tiles. I've not changed this apart from outputting it first. > > A shape that matches all the detail tiles is generated for use by the > DEM overview and could, maybe, be used for the 0x4b. I don't think > this > is worth doing as part of this change. > > I haven't made any changes to existing polygons that are input into > OverviewBuilder (from whatever source); all, including 0x4a and 0x4b > are passed on. It is unlikely that a user defined 0x4a polygon would > be > correctly set up, and, as seen by Carlos in his Australia map, > getting > it wrong has very strange effects as you zoom in and out of the > overview. > > I've attached a slightly updated patch - it looks like there was a > for > loop that should have been deleted when replaced by a forEach in > OverviewBuilder::addMapCoverageArea > > Ticker > > On Thu, 2021-01-21 at 06:48 +, Gerd Petermann wrote: > > Hi Ticker, > > > > sorry for the delay, I started a very time consuming mapping in my > > area to unglue landuse areas from highways > > > > I looked at overview-v3.patch in more detail. I don't understand > > the > > changes regarding 0x4a polygons. I am not sure but I think it is a > > step in the wrong direction. I think one goal is to allow arbitrary > > polygons with 0x4 with OSM input (similar to the --dem-polygon) as > > we > > already do with polish (*.mp) format. So, you should not assume > > that > > the 0x4a polygon is a rectangle. I might be confusing this with > > 0x4b > > though. > > Besides that I changed a few things to improve readability. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 13. Januar 2021 11:01 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > My understanding of the overview map was that it was for BaseCamp > > and > > MapSource, and it is used instead of the detail tiles as you zoom > > out. > > I had also assumed that it shares the same TYP as the detail tiles. > > For > > --order-by, this TYP will have equal [_drawOrder]. So the overview > > map, > > to display correctly, must also output polygons in the display > > order. > > > > Ticker > > > > On Wed, 2021-01-13 at 09:46 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > I fear I don't get it. If --order-by option is only improving the > > &
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd This hasn't changed. For each input ovm_ img it gets an Area from FileInfo.getBounds() then makes a 0x4a polygon from this, setting it's name to the tile "Descriptions \n Mapname". I've not found anything in recent versions that do anything different, including suppressing the above if it finds an existing 0x4a in the input. Ticker On Thu, 2021-01-21 at 15:45 +, Gerd Petermann wrote: > Hi Ticker, > > oops, I wanted to remove the foreach loop. Anyway, my understanding > is that the new code doesn't allow non-rectangular 0x4a shapes in the > overview map while the old code did, at least when a *.mp file > contains a non-rectangular 0x4a polygon. So, if the ovm_* file > contains a 0x4a polygon we should use that. > I just looked at the overview map for the Adria demo map and it has > non-rectangular 0x4a polygons (close to the country boundaries ) > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Donnerstag, 21. Januar 2021 16:28 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Each 0x4a polygon generated by the OverviewBuilder corresponds to a > detail tile and I avoided changing anything relating to this except > stopping them getting chopped up into SubDivisions by the --order-by > logic (the initial reason for this thread) and outputting them before > the other polygons in the detail tile area. > > If the detail tiles are transparent (implemented as none of the input > tiles having a 0x4b polygon), OverviewBuilder adds one. It is > generated > as a rectangle covering all the detail tiles rather than the shape of > all the tiles. I've not changed this apart from outputting it first. > > A shape that matches all the detail tiles is generated for use by the > DEM overview and could, maybe, be used for the 0x4b. I don't think > this > is worth doing as part of this change. > > I haven't made any changes to existing polygons that are input into > OverviewBuilder (from whatever source); all, including 0x4a and 0x4b > are passed on. It is unlikely that a user defined 0x4a polygon would > be > correctly set up, and, as seen by Carlos in his Australia map, > getting > it wrong has very strange effects as you zoom in and out of the > overview. > > I've attached a slightly updated patch - it looks like there was a > for > loop that should have been deleted when replaced by a forEach in > OverviewBuilder::addMapCoverageArea > > Ticker > > On Thu, 2021-01-21 at 06:48 +, Gerd Petermann wrote: > > Hi Ticker, > > > > sorry for the delay, I started a very time consuming mapping in my > > area to unglue landuse areas from highways > > > > I looked at overview-v3.patch in more detail. I don't understand > > the > > changes regarding 0x4a polygons. I am not sure but I think it is a > > step in the wrong direction. I think one goal is to allow arbitrary > > polygons with 0x4 with OSM input (similar to the --dem-polygon) as > > we > > already do with polish (*.mp) format. So, you should not assume > > that > > the 0x4a polygon is a rectangle. I might be confusing this with > > 0x4b > > though. > > Besides that I changed a few things to improve readability. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 13. Januar 2021 11:01 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > My understanding of the overview map was that it was for BaseCamp > > and > > MapSource, and it is used instead of the detail tiles as you zoom > > out. > > I had also assumed that it shares the same TYP as the detail tiles. > > For > > --order-by, this TYP will have equal [_drawOrder]. So the overview > > map, > > to display correctly, must also output polygons in the display > > order. > > > > Ticker > > > > On Wed, 2021-01-13 at 09:46 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > I fear I don't get it. If --order-by option is only improving the > > > map > > > on the device I see no need to use it for a map that is not used > > > on > > > the device, esp. not when it has negative effects. > > > > > > Gerd > > > > > > > > > Von: mkgmap-dev im > > > Auftrag > > > von Ticker Berkin &g
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, oops, I wanted to remove the foreach loop. Anyway, my understanding is that the new code doesn't allow non-rectangular 0x4a shapes in the overview map while the old code did, at least when a *.mp file contains a non-rectangular 0x4a polygon. So, if the ovm_* file contains a 0x4a polygon we should use that. I just looked at the overview map for the Adria demo map and it has non-rectangular 0x4a polygons (close to the country boundaries ) Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Donnerstag, 21. Januar 2021 16:28 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd Each 0x4a polygon generated by the OverviewBuilder corresponds to a detail tile and I avoided changing anything relating to this except stopping them getting chopped up into SubDivisions by the --order-by logic (the initial reason for this thread) and outputting them before the other polygons in the detail tile area. If the detail tiles are transparent (implemented as none of the input tiles having a 0x4b polygon), OverviewBuilder adds one. It is generated as a rectangle covering all the detail tiles rather than the shape of all the tiles. I've not changed this apart from outputting it first. A shape that matches all the detail tiles is generated for use by the DEM overview and could, maybe, be used for the 0x4b. I don't think this is worth doing as part of this change. I haven't made any changes to existing polygons that are input into OverviewBuilder (from whatever source); all, including 0x4a and 0x4b are passed on. It is unlikely that a user defined 0x4a polygon would be correctly set up, and, as seen by Carlos in his Australia map, getting it wrong has very strange effects as you zoom in and out of the overview. I've attached a slightly updated patch - it looks like there was a for loop that should have been deleted when replaced by a forEach in OverviewBuilder::addMapCoverageArea Ticker On Thu, 2021-01-21 at 06:48 +, Gerd Petermann wrote: > Hi Ticker, > > sorry for the delay, I started a very time consuming mapping in my > area to unglue landuse areas from highways > > I looked at overview-v3.patch in more detail. I don't understand the > changes regarding 0x4a polygons. I am not sure but I think it is a > step in the wrong direction. I think one goal is to allow arbitrary > polygons with 0x4 with OSM input (similar to the --dem-polygon) as we > already do with polish (*.mp) format. So, you should not assume that > the 0x4a polygon is a rectangle. I might be confusing this with 0x4b > though. > Besides that I changed a few things to improve readability. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 13. Januar 2021 11:01 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > My understanding of the overview map was that it was for BaseCamp and > MapSource, and it is used instead of the detail tiles as you zoom > out. > I had also assumed that it shares the same TYP as the detail tiles. > For > --order-by, this TYP will have equal [_drawOrder]. So the overview > map, > to display correctly, must also output polygons in the display order. > > Ticker > > On Wed, 2021-01-13 at 09:46 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I fear I don't get it. If --order-by option is only improving the > > map > > on the device I see no need to use it for a map that is not used on > > the device, esp. not when it has negative effects. > > > > Gerd > > > > ____________________ > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 13. Januar 2021 10:41 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > I don't think this is the point of the patch. > > > > --order-by is known to increase the size of the main map. This is > > accepted by users who consider the benefit worthwhile. The overview > > map, needing to operate in the same environment, has to keep to the > > same principals and this can lead to a size increase and the effect > > you > > mention of a label being off-center, because the named area has > > been > > split and the display software labels one part and suppress the > > label > > on the other. > > > > A good example depends on finding overlayed polygons that either: > > > > a/ conflict with a given TYP [_drawOrder] - for example, using > > mapnik.txt, you won't see any land features within Amenity/0x23, > &g
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd Each 0x4a polygon generated by the OverviewBuilder corresponds to a detail tile and I avoided changing anything relating to this except stopping them getting chopped up into SubDivisions by the --order-by logic (the initial reason for this thread) and outputting them before the other polygons in the detail tile area. If the detail tiles are transparent (implemented as none of the input tiles having a 0x4b polygon), OverviewBuilder adds one. It is generated as a rectangle covering all the detail tiles rather than the shape of all the tiles. I've not changed this apart from outputting it first. A shape that matches all the detail tiles is generated for use by the DEM overview and could, maybe, be used for the 0x4b. I don't think this is worth doing as part of this change. I haven't made any changes to existing polygons that are input into OverviewBuilder (from whatever source); all, including 0x4a and 0x4b are passed on. It is unlikely that a user defined 0x4a polygon would be correctly set up, and, as seen by Carlos in his Australia map, getting it wrong has very strange effects as you zoom in and out of the overview. I've attached a slightly updated patch - it looks like there was a for loop that should have been deleted when replaced by a forEach in OverviewBuilder::addMapCoverageArea Ticker On Thu, 2021-01-21 at 06:48 +, Gerd Petermann wrote: > Hi Ticker, > > sorry for the delay, I started a very time consuming mapping in my > area to unglue landuse areas from highways > > I looked at overview-v3.patch in more detail. I don't understand the > changes regarding 0x4a polygons. I am not sure but I think it is a > step in the wrong direction. I think one goal is to allow arbitrary > polygons with 0x4 with OSM input (similar to the --dem-polygon) as we > already do with polish (*.mp) format. So, you should not assume that > the 0x4a polygon is a rectangle. I might be confusing this with 0x4b > though. > Besides that I changed a few things to improve readability. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 13. Januar 2021 11:01 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > My understanding of the overview map was that it was for BaseCamp and > MapSource, and it is used instead of the detail tiles as you zoom > out. > I had also assumed that it shares the same TYP as the detail tiles. > For > --order-by, this TYP will have equal [_drawOrder]. So the overview > map, > to display correctly, must also output polygons in the display order. > > Ticker > > On Wed, 2021-01-13 at 09:46 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I fear I don't get it. If --order-by option is only improving the > > map > > on the device I see no need to use it for a map that is not used on > > the device, esp. not when it has negative effects. > > > > Gerd > > > > ________________________ > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 13. Januar 2021 10:41 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > I don't think this is the point of the patch. > > > > --order-by is known to increase the size of the main map. This is > > accepted by users who consider the benefit worthwhile. The overview > > map, needing to operate in the same environment, has to keep to the > > same principals and this can lead to a size increase and the effect > > you > > mention of a label being off-center, because the named area has > > been > > split and the display software labels one part and suppress the > > label > > on the other. > > > > A good example depends on finding overlayed polygons that either: > > > > a/ conflict with a given TYP [_drawOrder] - for example, using > > mapnik.txt, you won't see any land features within Amenity/0x23, > > Parking/0x05, Industrial/0x0c > > > > b/ have equal [_drawOrder], ie most landuse areas etc, where what > > will > > be displayed depends mostly on the internal logic of mkgmap, and, > > slightly by OSM extract ordering and the original object > > complexity. > > > > Finding these examples would be tedious. I originally noticed these > > types of problems because the eTrex HCx starts displaying as soon > > as > > possible, and I'd see interesting features disappear from the > > display > > as it worked through everything that should be on the screen. > > > > Ticker
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, patch was missing... Gerd Von: mkgmap-dev im Auftrag von Gerd Petermann Gesendet: Donnerstag, 21. Januar 2021 07:48 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Ticker, sorry for the delay, I started a very time consuming mapping in my area to unglue landuse areas from highways I looked at overview-v3.patch in more detail. I don't understand the changes regarding 0x4a polygons. I am not sure but I think it is a step in the wrong direction. I think one goal is to allow arbitrary polygons with 0x4 with OSM input (similar to the --dem-polygon) as we already do with polish (*.mp) format. So, you should not assume that the 0x4a polygon is a rectangle. I might be confusing this with 0x4b though. Besides that I changed a few things to improve readability. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 13. Januar 2021 11:01 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd My understanding of the overview map was that it was for BaseCamp and MapSource, and it is used instead of the detail tiles as you zoom out. I had also assumed that it shares the same TYP as the detail tiles. For --order-by, this TYP will have equal [_drawOrder]. So the overview map, to display correctly, must also output polygons in the display order. Ticker On Wed, 2021-01-13 at 09:46 +, Gerd Petermann wrote: > Hi Ticker, > > I fear I don't get it. If --order-by option is only improving the map > on the device I see no need to use it for a map that is not used on > the device, esp. not when it has negative effects. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 13. Januar 2021 10:41 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I don't think this is the point of the patch. > > --order-by is known to increase the size of the main map. This is > accepted by users who consider the benefit worthwhile. The overview > map, needing to operate in the same environment, has to keep to the > same principals and this can lead to a size increase and the effect > you > mention of a label being off-center, because the named area has been > split and the display software labels one part and suppress the label > on the other. > > A good example depends on finding overlayed polygons that either: > > a/ conflict with a given TYP [_drawOrder] - for example, using > mapnik.txt, you won't see any land features within Amenity/0x23, > Parking/0x05, Industrial/0x0c > > b/ have equal [_drawOrder], ie most landuse areas etc, where what > will > be displayed depends mostly on the internal logic of mkgmap, and, > slightly by OSM extract ordering and the original object complexity. > > Finding these examples would be tedious. I originally noticed these > types of problems because the eTrex HCx starts displaying as soon as > possible, and I'd see interesting features disappear from the display > as it worked through everything that should be on the screen. > > Ticker > > > On Wed, 2021-01-13 at 08:21 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I've hoped for a good example that shows how --order-by... really > > improves the overview map. I gave an example where the only visible > > difference is a label that is slightly off (so the patch worsens > > the > > map). > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Montag, 11. Januar 2021 12:39 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > Here is an updated patch with the naming changes. > > > > Ticker > > > > On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > OK regarding the naming. > > > I think what I tried to point out is that the overview map > > > probably > > > never suffers the problem that should be solved with the order-by > > > stuff, but on the other hand we really want to keep that map as > > > small > > > as possible to allow continent or maybe even planet wide overview > > > maps. So, I really prefer to enable the shape merging for the > > > overview map. > > > A possible work around might be to merge the shapes before > > > MapSplitter is executed. The number of points is rather small, so > > > performance shouldn't be a
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, sorry for the delay, I started a very time consuming mapping in my area to unglue landuse areas from highways I looked at overview-v3.patch in more detail. I don't understand the changes regarding 0x4a polygons. I am not sure but I think it is a step in the wrong direction. I think one goal is to allow arbitrary polygons with 0x4 with OSM input (similar to the --dem-polygon) as we already do with polish (*.mp) format. So, you should not assume that the 0x4a polygon is a rectangle. I might be confusing this with 0x4b though. Besides that I changed a few things to improve readability. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 13. Januar 2021 11:01 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd My understanding of the overview map was that it was for BaseCamp and MapSource, and it is used instead of the detail tiles as you zoom out. I had also assumed that it shares the same TYP as the detail tiles. For --order-by, this TYP will have equal [_drawOrder]. So the overview map, to display correctly, must also output polygons in the display order. Ticker On Wed, 2021-01-13 at 09:46 +, Gerd Petermann wrote: > Hi Ticker, > > I fear I don't get it. If --order-by option is only improving the map > on the device I see no need to use it for a map that is not used on > the device, esp. not when it has negative effects. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 13. Januar 2021 10:41 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I don't think this is the point of the patch. > > --order-by is known to increase the size of the main map. This is > accepted by users who consider the benefit worthwhile. The overview > map, needing to operate in the same environment, has to keep to the > same principals and this can lead to a size increase and the effect > you > mention of a label being off-center, because the named area has been > split and the display software labels one part and suppress the label > on the other. > > A good example depends on finding overlayed polygons that either: > > a/ conflict with a given TYP [_drawOrder] - for example, using > mapnik.txt, you won't see any land features within Amenity/0x23, > Parking/0x05, Industrial/0x0c > > b/ have equal [_drawOrder], ie most landuse areas etc, where what > will > be displayed depends mostly on the internal logic of mkgmap, and, > slightly by OSM extract ordering and the original object complexity. > > Finding these examples would be tedious. I originally noticed these > types of problems because the eTrex HCx starts displaying as soon as > possible, and I'd see interesting features disappear from the display > as it worked through everything that should be on the screen. > > Ticker > > > On Wed, 2021-01-13 at 08:21 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I've hoped for a good example that shows how --order-by... really > > improves the overview map. I gave an example where the only visible > > difference is a label that is slightly off (so the patch worsens > > the > > map). > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Montag, 11. Januar 2021 12:39 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > Here is an updated patch with the naming changes. > > > > Ticker > > > > On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > OK regarding the naming. > > > I think what I tried to point out is that the overview map > > > probably > > > never suffers the problem that should be solved with the order-by > > > stuff, but on the other hand we really want to keep that map as > > > small > > > as possible to allow continent or maybe even planet wide overview > > > maps. So, I really prefer to enable the shape merging for the > > > overview map. > > > A possible work around might be to merge the shapes before > > > MapSplitter is executed. The number of points is rather small, so > > > performance shouldn't be a problem as it is with real OSM data. > > > We > > > might even use java.awt.area for that. > > > Another question is if the --order-by could/should be disabled > > > for > > > the ovm_ maps. > > > >
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd My understanding of the overview map was that it was for BaseCamp and MapSource, and it is used instead of the detail tiles as you zoom out. I had also assumed that it shares the same TYP as the detail tiles. For --order-by, this TYP will have equal [_drawOrder]. So the overview map, to display correctly, must also output polygons in the display order. Ticker On Wed, 2021-01-13 at 09:46 +, Gerd Petermann wrote: > Hi Ticker, > > I fear I don't get it. If --order-by option is only improving the map > on the device I see no need to use it for a map that is not used on > the device, esp. not when it has negative effects. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 13. Januar 2021 10:41 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I don't think this is the point of the patch. > > --order-by is known to increase the size of the main map. This is > accepted by users who consider the benefit worthwhile. The overview > map, needing to operate in the same environment, has to keep to the > same principals and this can lead to a size increase and the effect > you > mention of a label being off-center, because the named area has been > split and the display software labels one part and suppress the label > on the other. > > A good example depends on finding overlayed polygons that either: > > a/ conflict with a given TYP [_drawOrder] - for example, using > mapnik.txt, you won't see any land features within Amenity/0x23, > Parking/0x05, Industrial/0x0c > > b/ have equal [_drawOrder], ie most landuse areas etc, where what > will > be displayed depends mostly on the internal logic of mkgmap, and, > slightly by OSM extract ordering and the original object complexity. > > Finding these examples would be tedious. I originally noticed these > types of problems because the eTrex HCx starts displaying as soon as > possible, and I'd see interesting features disappear from the display > as it worked through everything that should be on the screen. > > Ticker > > > On Wed, 2021-01-13 at 08:21 +, Gerd Petermann wrote: > > Hi Ticker, > > > > I've hoped for a good example that shows how --order-by... really > > improves the overview map. I gave an example where the only visible > > difference is a label that is slightly off (so the patch worsens > > the > > map). > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Montag, 11. Januar 2021 12:39 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > Here is an updated patch with the naming changes. > > > > Ticker > > > > On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > OK regarding the naming. > > > I think what I tried to point out is that the overview map > > > probably > > > never suffers the problem that should be solved with the order-by > > > stuff, but on the other hand we really want to keep that map as > > > small > > > as possible to allow continent or maybe even planet wide overview > > > maps. So, I really prefer to enable the shape merging for the > > > overview map. > > > A possible work around might be to merge the shapes before > > > MapSplitter is executed. The number of points is rather small, so > > > performance shouldn't be a problem as it is with real OSM data. > > > We > > > might even use java.awt.area for that. > > > Another question is if the --order-by could/should be disabled > > > for > > > the ovm_ maps. > > > > > > Gerd > > > > > > > > > Von: mkgmap-dev im > > > Auftrag > > > von Ticker Berkin > > > Gesendet: Mittwoch, 6. Januar 2021 10:19 > > > An: Development list for mkgmap > > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > > > Hi Gerd > > > > > > Sorry about overview-dem-dists. > > > > > > I'd prefer the Map variable to be called IsOverviewComponent to > > > make > > > clear the distinction between the 2 types of overview and to be > > > consistent with the names used in MapBuilder. I can do a patch to > > > this > > > effect. > > > > > > --ord
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, I fear I don't get it. If --order-by option is only improving the map on the device I see no need to use it for a map that is not used on the device, esp. not when it has negative effects. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 13. Januar 2021 10:41 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd I don't think this is the point of the patch. --order-by is known to increase the size of the main map. This is accepted by users who consider the benefit worthwhile. The overview map, needing to operate in the same environment, has to keep to the same principals and this can lead to a size increase and the effect you mention of a label being off-center, because the named area has been split and the display software labels one part and suppress the label on the other. A good example depends on finding overlayed polygons that either: a/ conflict with a given TYP [_drawOrder] - for example, using mapnik.txt, you won't see any land features within Amenity/0x23, Parking/0x05, Industrial/0x0c b/ have equal [_drawOrder], ie most landuse areas etc, where what will be displayed depends mostly on the internal logic of mkgmap, and, slightly by OSM extract ordering and the original object complexity. Finding these examples would be tedious. I originally noticed these types of problems because the eTrex HCx starts displaying as soon as possible, and I'd see interesting features disappear from the display as it worked through everything that should be on the screen. Ticker On Wed, 2021-01-13 at 08:21 +, Gerd Petermann wrote: > Hi Ticker, > > I've hoped for a good example that shows how --order-by... really > improves the overview map. I gave an example where the only visible > difference is a label that is slightly off (so the patch worsens the > map). > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Montag, 11. Januar 2021 12:39 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Here is an updated patch with the naming changes. > > Ticker > > On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > > Hi Ticker, > > > > OK regarding the naming. > > I think what I tried to point out is that the overview map probably > > never suffers the problem that should be solved with the order-by > > stuff, but on the other hand we really want to keep that map as > > small > > as possible to allow continent or maybe even planet wide overview > > maps. So, I really prefer to enable the shape merging for the > > overview map. > > A possible work around might be to merge the shapes before > > MapSplitter is executed. The number of points is rather small, so > > performance shouldn't be a problem as it is with real OSM data. We > > might even use java.awt.area for that. > > Another question is if the --order-by could/should be disabled for > > the ovm_ maps. > > > > Gerd > > > > ____________ > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 6. Januar 2021 10:19 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > Sorry about overview-dem-dists. > > > > I'd prefer the Map variable to be called IsOverviewComponent to > > make > > clear the distinction between the 2 types of overview and to be > > consistent with the names used in MapBuilder. I can do a patch to > > this > > effect. > > > > --order-by is expected to increase the map size a bit; extra > > polygon > > splitting (in the ovm_ and carried into the composite) is performed > > so > > that all polygons at any given point are in the same subdivision > > and > > some merges (in both the ovm_ and the composite) are inhibited. > > > > An overview map is unlikely to have multiple overlayed polygons so > > probably there won't be any cases where a fixed _drawOrder couldn't > > be > > defined correctly, but it exists with the detail tiles that need a > > TYP > > where all _drawOrders are equal. > > > > Ticker > > > > On Tue, 2021-01-05 at 15:35 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > there is a typo in the patch, overview-dem-dists instead of > > > overview > > > -dem-dist. My rather small overview map got 20MB instead of 181K > > > ;) > > > I also didn't like the idea that the overview
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd I don't think this is the point of the patch. --order-by is known to increase the size of the main map. This is accepted by users who consider the benefit worthwhile. The overview map, needing to operate in the same environment, has to keep to the same principals and this can lead to a size increase and the effect you mention of a label being off-center, because the named area has been split and the display software labels one part and suppress the label on the other. A good example depends on finding overlayed polygons that either: a/ conflict with a given TYP [_drawOrder] - for example, using mapnik.txt, you won't see any land features within Amenity/0x23, Parking/0x05, Industrial/0x0c b/ have equal [_drawOrder], ie most landuse areas etc, where what will be displayed depends mostly on the internal logic of mkgmap, and, slightly by OSM extract ordering and the original object complexity. Finding these examples would be tedious. I originally noticed these types of problems because the eTrex HCx starts displaying as soon as possible, and I'd see interesting features disappear from the display as it worked through everything that should be on the screen. Ticker On Wed, 2021-01-13 at 08:21 +, Gerd Petermann wrote: > Hi Ticker, > > I've hoped for a good example that shows how --order-by... really > improves the overview map. I gave an example where the only visible > difference is a label that is slightly off (so the patch worsens the > map). > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Montag, 11. Januar 2021 12:39 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Here is an updated patch with the naming changes. > > Ticker > > On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > > Hi Ticker, > > > > OK regarding the naming. > > I think what I tried to point out is that the overview map probably > > never suffers the problem that should be solved with the order-by > > stuff, but on the other hand we really want to keep that map as > > small > > as possible to allow continent or maybe even planet wide overview > > maps. So, I really prefer to enable the shape merging for the > > overview map. > > A possible work around might be to merge the shapes before > > MapSplitter is executed. The number of points is rather small, so > > performance shouldn't be a problem as it is with real OSM data. We > > might even use java.awt.area for that. > > Another question is if the --order-by could/should be disabled for > > the ovm_ maps. > > > > Gerd > > > > ____________ > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Mittwoch, 6. Januar 2021 10:19 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > Sorry about overview-dem-dists. > > > > I'd prefer the Map variable to be called IsOverviewComponent to > > make > > clear the distinction between the 2 types of overview and to be > > consistent with the names used in MapBuilder. I can do a patch to > > this > > effect. > > > > --order-by is expected to increase the map size a bit; extra > > polygon > > splitting (in the ovm_ and carried into the composite) is performed > > so > > that all polygons at any given point are in the same subdivision > > and > > some merges (in both the ovm_ and the composite) are inhibited. > > > > An overview map is unlikely to have multiple overlayed polygons so > > probably there won't be any cases where a fixed _drawOrder couldn't > > be > > defined correctly, but it exists with the detail tiles that need a > > TYP > > where all _drawOrders are equal. > > > > Ticker > > > > On Tue, 2021-01-05 at 15:35 +, Gerd Petermann wrote: > > > Hi Ticker, > > > > > > there is a typo in the patch, overview-dem-dists instead of > > > overview > > > -dem-dist. My rather small overview map got 20MB instead of 181K > > > ;) > > > I also didn't like the idea that the overview map is recognized > > > by > > > the name. That can lead to strange effects with test maps, so I > > > added > > > a parameter. > > > > > > With the corrections the size increases by only by 5K, but I have > > > no > > > idea how these 5K improve the map. > > > I see one small difference where a label of a lake (1) is placed > >
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, I've hoped for a good example that shows how --order-by... really improves the overview map. I gave an example where the only visible difference is a label that is slightly off (so the patch worsens the map). Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 11. Januar 2021 12:39 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd Here is an updated patch with the naming changes. Ticker On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > Hi Ticker, > > OK regarding the naming. > I think what I tried to point out is that the overview map probably > never suffers the problem that should be solved with the order-by > stuff, but on the other hand we really want to keep that map as small > as possible to allow continent or maybe even planet wide overview > maps. So, I really prefer to enable the shape merging for the > overview map. > A possible work around might be to merge the shapes before > MapSplitter is executed. The number of points is rather small, so > performance shouldn't be a problem as it is with real OSM data. We > might even use java.awt.area for that. > Another question is if the --order-by could/should be disabled for > the ovm_ maps. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 6. Januar 2021 10:19 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Sorry about overview-dem-dists. > > I'd prefer the Map variable to be called IsOverviewComponent to make > clear the distinction between the 2 types of overview and to be > consistent with the names used in MapBuilder. I can do a patch to > this > effect. > > --order-by is expected to increase the map size a bit; extra polygon > splitting (in the ovm_ and carried into the composite) is performed > so > that all polygons at any given point are in the same subdivision and > some merges (in both the ovm_ and the composite) are inhibited. > > An overview map is unlikely to have multiple overlayed polygons so > probably there won't be any cases where a fixed _drawOrder couldn't > be > defined correctly, but it exists with the detail tiles that need a > TYP > where all _drawOrders are equal. > > Ticker > > On Tue, 2021-01-05 at 15:35 +, Gerd Petermann wrote: > > Hi Ticker, > > > > there is a typo in the patch, overview-dem-dists instead of > > overview > > -dem-dist. My rather small overview map got 20MB instead of 181K ;) > > I also didn't like the idea that the overview map is recognized by > > the name. That can lead to strange effects with test maps, so I > > added > > a parameter. > > > > With the corrections the size increases by only by 5K, but I have > > no > > idea how these 5K improve the map. > > I see one small difference where a label of a lake (1) is placed a > > bit of the center. The "patched" map contains two polygons for this > > lake, I assume the Garmin software avoids to render its name twice > > but uses a different algo to calculate the position. These are the > > results for my own style, a variant of Minkos OpenFietsMap Light > > style. > > Will try again with default style and type file sameOrder.txt. > > > > Gerd > > (1) > > https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.19 > > 91 > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Dienstag, 5. Januar 2021 10:58 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > shapeMergeFilter.merge() sorts the shapes according to typ, > > skipSize, > > fullArea and name. For --order-by to work for the overview, this > > must > > not happen; the order in the ovm_ files must be used. This is the > > same > > idea as when the more than 1 detail tiles are displayed on a > > device. > > > > The size of osmmap.img for my test area, with the patch, is: > > 9216 --no-order-by-decreasing-area throughout > > 10752 --order-by-decreasing-area throughout > > 9219 --order-by-decreasing-area at start, > > --no-order-by-decreasing-area for the combiners > > So, there is a slight increase, as expected, it really isn't of any > > significance. > > > > --order-by-decreasing-area needs to be applied to both phases for > > it > > to > > work correctly. > > > > I
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd Here is an updated patch with the naming changes. Ticker On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > Hi Ticker, > > OK regarding the naming. > I think what I tried to point out is that the overview map probably > never suffers the problem that should be solved with the order-by > stuff, but on the other hand we really want to keep that map as small > as possible to allow continent or maybe even planet wide overview > maps. So, I really prefer to enable the shape merging for the > overview map. > A possible work around might be to merge the shapes before > MapSplitter is executed. The number of points is rather small, so > performance shouldn't be a problem as it is with real OSM data. We > might even use java.awt.area for that. > Another question is if the --order-by could/should be disabled for > the ovm_ maps. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 6. Januar 2021 10:19 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Sorry about overview-dem-dists. > > I'd prefer the Map variable to be called IsOverviewComponent to make > clear the distinction between the 2 types of overview and to be > consistent with the names used in MapBuilder. I can do a patch to > this > effect. > > --order-by is expected to increase the map size a bit; extra polygon > splitting (in the ovm_ and carried into the composite) is performed > so > that all polygons at any given point are in the same subdivision and > some merges (in both the ovm_ and the composite) are inhibited. > > An overview map is unlikely to have multiple overlayed polygons so > probably there won't be any cases where a fixed _drawOrder couldn't > be > defined correctly, but it exists with the detail tiles that need a > TYP > where all _drawOrders are equal. > > Ticker > > On Tue, 2021-01-05 at 15:35 +, Gerd Petermann wrote: > > Hi Ticker, > > > > there is a typo in the patch, overview-dem-dists instead of > > overview > > -dem-dist. My rather small overview map got 20MB instead of 181K ;) > > I also didn't like the idea that the overview map is recognized by > > the name. That can lead to strange effects with test maps, so I > > added > > a parameter. > > > > With the corrections the size increases by only by 5K, but I have > > no > > idea how these 5K improve the map. > > I see one small difference where a label of a lake (1) is placed a > > bit of the center. The "patched" map contains two polygons for this > > lake, I assume the Garmin software avoids to render its name twice > > but uses a different algo to calculate the position. These are the > > results for my own style, a variant of Minkos OpenFietsMap Light > > style. > > Will try again with default style and type file sameOrder.txt. > > > > Gerd > > (1) > > https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.19 > > 91 > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Dienstag, 5. Januar 2021 10:58 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd > > > > shapeMergeFilter.merge() sorts the shapes according to typ, > > skipSize, > > fullArea and name. For --order-by to work for the overview, this > > must > > not happen; the order in the ovm_ files must be used. This is the > > same > > idea as when the more than 1 detail tiles are displayed on a > > device. > > > > The size of osmmap.img for my test area, with the patch, is: > > 9216 --no-order-by-decreasing-area throughout > > 10752 --order-by-decreasing-area throughout > > 9219 --order-by-decreasing-area at start, > > --no-order-by-decreasing-area for the combiners > > So, there is a slight increase, as expected, it really isn't of any > > significance. > > > > --order-by-decreasing-area needs to be applied to both phases for > > it > > to > > work correctly. > > > > If applied to the tile phase only, the overview map will render > > polygons in order of the results of the the shapeMergeFilter. > > > > If applied to the overview phase only, probably similar; the order > > of > > the shapeMergeFilter governed ordering in the ovm_ .img > > > > Ticker > > > > On Mon, 2021-01-04 at 18:52 +, Ge
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd Thinking about this more, any attempt at merging will most likely cause violation of the rule that all overlaying polygons must be in the same subdivision. Also, just feeding all the points/lines/polygons back through the non -order-by splitting process could cause similar problems, so my current solution might give incorrect results. I think this is very unlikely and my preference would be to wait for someone to have this problem - it hasn't been reported in the 4 or so years that it could have happened. A solution is to preserve the subdivision structure and content from each ovm_, linking, per level, the ones from each source. If there is a single one per tile/level and it fits, the 0x4a polygon can be added in, otherwise an extra subdivision is added to hold it. Ticker ___ 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
Hi Gerd Because (I presume) the overview map needs to share the same TYP as the detail tiles, something must be done to ensure that polygons in the overview map are ordered in the correct way. The main problem in the overview is that it doesn't have the original/full areas, before tile clipping and other splitting happens. So it seemed most correct, and certainly the simplest method, to preserve the order in each tile. It might be possible to have a special version of the merging that keeps all the partial orders per tile except for the polygons that get merged into another polygon. This will require a bit of work to implement and could suffer two problems that I can see. 1/ Some apparently mergeable polygons shouldn't be merged because they derive from different objects, the knowledge of which has been lost by this point. If merged, it could then disrupt the partial ordering logic (a bit like a file compare syncing on the the wrong line). 2/ The merged areas might overflow their subdivision and this would lead to the non-order-by MapSplitter logic shifting some polygons into a new subdivision that overlaps the same area. This could cause the rendering to be incorrect. Another option would be: No need to generate the ovm_ imgs with order-by. Allow full merging. Calculate the areas of the merged polygons and sort by this. This could be inaccurate because of the low resolution and not give the correct order, for reasons given above. In the map splitting phase, prevent the 0x4a polygon from being split; this is what caused the Australia problem. The significant problem with this is that the style (and the sea default) can override the rendering order and this information is lost. Is this extra size of the overview map (5k in your case, 1.5k in mine where the full gmapsupp.img is 27M), such a problem. Ticker On Wed, 2021-01-06 at 09:35 +, Gerd Petermann wrote: > Hi Ticker, > > OK regarding the naming. > I think what I tried to point out is that the overview map probably > never suffers the problem that should be solved with the order-by > stuff, but on the other hand we really want to keep that map as small > as possible to allow continent or maybe even planet wide overview > maps. So, I really prefer to enable the shape merging for the > overview map. > A possible work around might be to merge the shapes before > MapSplitter is executed. The number of points is rather small, so > performance shouldn't be a problem as it is with real OSM data. We > might even use java.awt.area for that. > Another question is if the --order-by could/should be disabled for > the ovm_ maps. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 6. Januar 2021 10:19 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > Sorry about overview-dem-dists. > > I'd prefer the Map variable to be called IsOverviewComponent to make > clear the distinction between the 2 types of overview and to be > consistent with the names used in MapBuilder. I can do a patch to > this > effect. > > --order-by is expected to increase the map size a bit; extra polygon > splitting (in the ovm_ and carried into the composite) is performed > so > that all polygons at any given point are in the same subdivision and > some merges (in both the ovm_ and the composite) are inhibited. > > An overview map is unlikely to have multiple overlayed polygons so > probably there won't be any cases where a fixed _drawOrder couldn't > be > defined correctly, but it exists with the detail tiles that need a > TYP > where all _drawOrders are equal. > > Ticker > > On Tue, 2021-01-05 at 15:35 +, Gerd Petermann wrote: > > Hi Ticker, > > > > there is a typo in the patch, overview-dem-dists instead of > > overview > > -dem-dist. My rather small overview map got 20MB instead of 181K ;) > > I also didn't like the idea that the overview map is recognized by > > the name. That can lead to strange effects with test maps, so I > > added > > a parameter. > > > > With the corrections the size increases by only by 5K, but I have > > no > > idea how these 5K improve the map. > > I see one small difference where a label of a lake (1) is placed a > > bit of the center. The "patched" map contains two polygons for this > > lake, I assume the Garmin software avoids to render its name twice > > but uses a different algo to calculate the position. These are the > > results for my own style, a variant of Minkos OpenFietsMap Light > > style. > > Will try again with default style and type file sameOrder.txt. > > > &g
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, OK regarding the naming. I think what I tried to point out is that the overview map probably never suffers the problem that should be solved with the order-by stuff, but on the other hand we really want to keep that map as small as possible to allow continent or maybe even planet wide overview maps. So, I really prefer to enable the shape merging for the overview map. A possible work around might be to merge the shapes before MapSplitter is executed. The number of points is rather small, so performance shouldn't be a problem as it is with real OSM data. We might even use java.awt.area for that. Another question is if the --order-by could/should be disabled for the ovm_ maps. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 6. Januar 2021 10:19 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd Sorry about overview-dem-dists. I'd prefer the Map variable to be called IsOverviewComponent to make clear the distinction between the 2 types of overview and to be consistent with the names used in MapBuilder. I can do a patch to this effect. --order-by is expected to increase the map size a bit; extra polygon splitting (in the ovm_ and carried into the composite) is performed so that all polygons at any given point are in the same subdivision and some merges (in both the ovm_ and the composite) are inhibited. An overview map is unlikely to have multiple overlayed polygons so probably there won't be any cases where a fixed _drawOrder couldn't be defined correctly, but it exists with the detail tiles that need a TYP where all _drawOrders are equal. Ticker On Tue, 2021-01-05 at 15:35 +, Gerd Petermann wrote: > Hi Ticker, > > there is a typo in the patch, overview-dem-dists instead of overview > -dem-dist. My rather small overview map got 20MB instead of 181K ;) > I also didn't like the idea that the overview map is recognized by > the name. That can lead to strange effects with test maps, so I added > a parameter. > > With the corrections the size increases by only by 5K, but I have no > idea how these 5K improve the map. > I see one small difference where a label of a lake (1) is placed a > bit of the center. The "patched" map contains two polygons for this > lake, I assume the Garmin software avoids to render its name twice > but uses a different algo to calculate the position. These are the > results for my own style, a variant of Minkos OpenFietsMap Light > style. > Will try again with default style and type file sameOrder.txt. > > Gerd > (1) > https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.1991 > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 5. Januar 2021 10:58 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > shapeMergeFilter.merge() sorts the shapes according to typ, skipSize, > fullArea and name. For --order-by to work for the overview, this must > not happen; the order in the ovm_ files must be used. This is the > same > idea as when the more than 1 detail tiles are displayed on a device. > > The size of osmmap.img for my test area, with the patch, is: > 9216 --no-order-by-decreasing-area throughout > 10752 --order-by-decreasing-area throughout > 9219 --order-by-decreasing-area at start, > --no-order-by-decreasing-area for the combiners > So, there is a slight increase, as expected, it really isn't of any > significance. > > --order-by-decreasing-area needs to be applied to both phases for it > to > work correctly. > > If applied to the tile phase only, the overview map will render > polygons in order of the results of the the shapeMergeFilter. > > If applied to the overview phase only, probably similar; the order of > the shapeMergeFilter governed ordering in the ovm_ .img > > Ticker > > On Mon, 2021-01-04 at 18:52 +, Gerd Petermann wrote: > > Hi Ticker, > > > > thanks for the patch. I'll have a closer look during the next days. > > I > > don't yet understand why shapes aren't always merged. > > What is the impact on the size of the overview map? What happens > > for > > those users who create the overview map in an extra step that > > doesn't > > have the --order-by-decreasing-area option? What happens when it's > > the other way around, no --order-by-decreasing-area option for the > > tiles but --order-by-decreasing-area for the overview map? > > > > Gerd > > ___ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://www.mkg
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd Sorry about overview-dem-dists. I'd prefer the Map variable to be called IsOverviewComponent to make clear the distinction between the 2 types of overview and to be consistent with the names used in MapBuilder. I can do a patch to this effect. --order-by is expected to increase the map size a bit; extra polygon splitting (in the ovm_ and carried into the composite) is performed so that all polygons at any given point are in the same subdivision and some merges (in both the ovm_ and the composite) are inhibited. An overview map is unlikely to have multiple overlayed polygons so probably there won't be any cases where a fixed _drawOrder couldn't be defined correctly, but it exists with the detail tiles that need a TYP where all _drawOrders are equal. Ticker On Tue, 2021-01-05 at 15:35 +, Gerd Petermann wrote: > Hi Ticker, > > there is a typo in the patch, overview-dem-dists instead of overview > -dem-dist. My rather small overview map got 20MB instead of 181K ;) > I also didn't like the idea that the overview map is recognized by > the name. That can lead to strange effects with test maps, so I added > a parameter. > > With the corrections the size increases by only by 5K, but I have no > idea how these 5K improve the map. > I see one small difference where a label of a lake (1) is placed a > bit of the center. The "patched" map contains two polygons for this > lake, I assume the Garmin software avoids to render its name twice > but uses a different algo to calculate the position. These are the > results for my own style, a variant of Minkos OpenFietsMap Light > style. > Will try again with default style and type file sameOrder.txt. > > Gerd > (1) > https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.1991 > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 5. Januar 2021 10:58 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > shapeMergeFilter.merge() sorts the shapes according to typ, skipSize, > fullArea and name. For --order-by to work for the overview, this must > not happen; the order in the ovm_ files must be used. This is the > same > idea as when the more than 1 detail tiles are displayed on a device. > > The size of osmmap.img for my test area, with the patch, is: > 9216 --no-order-by-decreasing-area throughout > 10752 --order-by-decreasing-area throughout > 9219 --order-by-decreasing-area at start, > --no-order-by-decreasing-area for the combiners > So, there is a slight increase, as expected, it really isn't of any > significance. > > --order-by-decreasing-area needs to be applied to both phases for it > to > work correctly. > > If applied to the tile phase only, the overview map will render > polygons in order of the results of the the shapeMergeFilter. > > If applied to the overview phase only, probably similar; the order of > the shapeMergeFilter governed ordering in the ovm_ .img > > Ticker > > On Mon, 2021-01-04 at 18:52 +, Gerd Petermann wrote: > > Hi Ticker, > > > > thanks for the patch. I'll have a closer look during the next days. > > I > > don't yet understand why shapes aren't always merged. > > What is the impact on the size of the overview map? What happens > > for > > those users who create the overview map in an extra step that > > doesn't > > have the --order-by-decreasing-area option? What happens when it's > > the other way around, no --order-by-decreasing-area option for the > > tiles but --order-by-decreasing-area for the overview map? > > > > 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
Hi Ticker, there is a typo in the patch, overview-dem-dists instead of overview-dem-dist. My rather small overview map got 20MB instead of 181K ;) I also didn't like the idea that the overview map is recognized by the name. That can lead to strange effects with test maps, so I added a parameter. With the corrections the size increases by only by 5K, but I have no idea how these 5K improve the map. I see one small difference where a label of a lake (1) is placed a bit of the center. The "patched" map contains two polygons for this lake, I assume the Garmin software avoids to render its name twice but uses a different algo to calculate the position. These are the results for my own style, a variant of Minkos OpenFietsMap Light style. Will try again with default style and type file sameOrder.txt. Gerd (1) https://www.openstreetmap.org/relation/3582977#map=14/53.5815/11.1991 Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 5. Januar 2021 10:58 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd shapeMergeFilter.merge() sorts the shapes according to typ, skipSize, fullArea and name. For --order-by to work for the overview, this must not happen; the order in the ovm_ files must be used. This is the same idea as when the more than 1 detail tiles are displayed on a device. The size of osmmap.img for my test area, with the patch, is: 9216 --no-order-by-decreasing-area throughout 10752 --order-by-decreasing-area throughout 9219 --order-by-decreasing-area at start, --no-order-by-decreasing-area for the combiners So, there is a slight increase, as expected, it really isn't of any significance. --order-by-decreasing-area needs to be applied to both phases for it to work correctly. If applied to the tile phase only, the overview map will render polygons in order of the results of the the shapeMergeFilter. If applied to the overview phase only, probably similar; the order of the shapeMergeFilter governed ordering in the ovm_ .img Ticker On Mon, 2021-01-04 at 18:52 +, Gerd Petermann wrote: > Hi Ticker, > > thanks for the patch. I'll have a closer look during the next days. I > don't yet understand why shapes aren't always merged. > What is the impact on the size of the overview map? What happens for > those users who create the overview map in an extra step that doesn't > have the --order-by-decreasing-area option? What happens when it's > the other way around, no --order-by-decreasing-area option for the > tiles but --order-by-decreasing-area for the overview map? > > Gerd ___ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev overview-v2.patch Description: overview-v2.patch ___ 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
Hi Gerd shapeMergeFilter.merge() sorts the shapes according to typ, skipSize, fullArea and name. For --order-by to work for the overview, this must not happen; the order in the ovm_ files must be used. This is the same idea as when the more than 1 detail tiles are displayed on a device. The size of osmmap.img for my test area, with the patch, is: 9216 --no-order-by-decreasing-area throughout 10752 --order-by-decreasing-area throughout 9219 --order-by-decreasing-area at start, --no-order-by-decreasing-area for the combiners So, there is a slight increase, as expected, it really isn't of any significance. --order-by-decreasing-area needs to be applied to both phases for it to work correctly. If applied to the tile phase only, the overview map will render polygons in order of the results of the the shapeMergeFilter. If applied to the overview phase only, probably similar; the order of the shapeMergeFilter governed ordering in the ovm_ .img Ticker On Mon, 2021-01-04 at 18:52 +, Gerd Petermann wrote: > Hi Ticker, > > thanks for the patch. I'll have a closer look during the next days. I > don't yet understand why shapes aren't always merged. > What is the impact on the size of the overview map? What happens for > those users who create the overview map in an extra step that doesn't > have the --order-by-decreasing-area option? What happens when it's > the other way around, no --order-by-decreasing-area option for the > tiles but --order-by-decreasing-area for the overview map? > > Gerd ___ 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
Hi Ticker, thanks for the patch. I'll have a closer look during the next days. I don't yet understand why shapes aren't always merged. What is the impact on the size of the overview map? What happens for those users who create the overview map in an extra step that doesn't have the --order-by-decreasing-area option? What happens when it's the other way around, no --order-by-decreasing-area option for the tiles but --order-by-decreasing-area for the overview map? Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Montag, 4. Januar 2021 19:16 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd I found another unexpected case: giving the --dem... option caused the overview map to have NET and NOD sections To stops surprises, we should either pass in all the args and let the receiver of them decide what to do with them or pass in only the presumed significant options. I think it much better to pass them all in; the logic to decide is then all in the place where it is significant. I've made some changes to this effect - attached. In the case of --order-by-decreasing area, the final overview map needs to know that this is wanted so it can keep the polygons in the same order in each detail tile. The large ovm_ size is because it has a LBL section containing all the names for all levels. Unused ones don't make it into the final overview so I don't think this is worth bothering with. I've removed the scans for 0x4a polygons and do the equivalent when they are inserted per detail tile. Also I've also removed some misleading comments Ticker On Wed, 2020-12-30 at 11:21 +, Gerd Petermann wrote: > Hi Ticker, > > yes, this code needs review, thanks for this. For now I've just > disabled the --order-by-decreasing-area option for the overview map > in r4590 > > I am not sure if it would be better to always pass the args to > MapBuilder or only those for DEM. I'd prefer to always pass them but > maybe there are other side effects > Reg. size 1%: My understanding was that the merging of shapes is > responsible for all of this, but I might be wrong. > > I am working on a routing issue that I found while looking at Carlos' > problem. It only happens with --x-no-force-end-nodes-routing-nodes. > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 30. Dezember 2020 09:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I'm going to experiment with the combined overview map and which > options cause problems. Also look at the effect of 0x4a polygons at > just 1 level. > > I also notices that the combined overview (osmmap.img) is a fraction > of > the size (~1%) of the sum of the ovm_ images that are used to build > it. > > Ticker > > On Tue, 2020-12-29 at 15:52 +, Gerd Petermann wrote: > > Hi Ticker, > > > > thanks for the hints. I agree that the code in OverviewBuilder is > > not > > very clear. I'll have a closer look tomorrow, but at least we > > should > > remove the -order-by-decreasing-area when copying the options. Or > > maybe I change the code so that only the hgt/dem options are > > copied. > > I guess I was too lazy there. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Dienstag, 29. Dezember 2020 10:50 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd & Carlos > > > > Reading and trying to understand the code, I'm finding a few > > strange > > things with the Overview map generation, DEM, 0x4a etc > > > > The most significant is that the MapBuilder invocation for the > > combined > > overview map normally runs without any options being passed to it. > > Only > > if --overview-dem-dist is supplied are all the other options > > (including > > --order-by-decreasing-area) passed in. I'm not sure if would be a > > good > > idea to supply all every time or just be more selective and filter > > out > > all but the necessary DEM options. > > > > I'm still investigating the overview map levels. The ovm_ files are > > produced with all the overview-levels as specified by options. When > > this is read back by the overview combiner, a 0x4a polygon is added > > covering each ovm_ tile, but it looks like it is at all levels, so, > > for > > a tile with a large area or lots of detail is
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd I found another unexpected case: giving the --dem... option caused the overview map to have NET and NOD sections To stops surprises, we should either pass in all the args and let the receiver of them decide what to do with them or pass in only the presumed significant options. I think it much better to pass them all in; the logic to decide is then all in the place where it is significant. I've made some changes to this effect - attached. In the case of --order-by-decreasing area, the final overview map needs to know that this is wanted so it can keep the polygons in the same order in each detail tile. The large ovm_ size is because it has a LBL section containing all the names for all levels. Unused ones don't make it into the final overview so I don't think this is worth bothering with. I've removed the scans for 0x4a polygons and do the equivalent when they are inserted per detail tile. Also I've also removed some misleading comments Ticker On Wed, 2020-12-30 at 11:21 +, Gerd Petermann wrote: > Hi Ticker, > > yes, this code needs review, thanks for this. For now I've just > disabled the --order-by-decreasing-area option for the overview map > in r4590 > > I am not sure if it would be better to always pass the args to > MapBuilder or only those for DEM. I'd prefer to always pass them but > maybe there are other side effects > Reg. size 1%: My understanding was that the merging of shapes is > responsible for all of this, but I might be wrong. > > I am working on a routing issue that I found while looking at Carlos' > problem. It only happens with --x-no-force-end-nodes-routing-nodes. > > Gerd > > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Mittwoch, 30. Dezember 2020 09:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd > > I'm going to experiment with the combined overview map and which > options cause problems. Also look at the effect of 0x4a polygons at > just 1 level. > > I also notices that the combined overview (osmmap.img) is a fraction > of > the size (~1%) of the sum of the ovm_ images that are used to build > it. > > Ticker > > On Tue, 2020-12-29 at 15:52 +, Gerd Petermann wrote: > > Hi Ticker, > > > > thanks for the hints. I agree that the code in OverviewBuilder is > > not > > very clear. I'll have a closer look tomorrow, but at least we > > should > > remove the -order-by-decreasing-area when copying the options. Or > > maybe I change the code so that only the hgt/dem options are > > copied. > > I guess I was too lazy there. > > > > Gerd > > > > > > Von: mkgmap-dev im Auftrag > > von Ticker Berkin > > Gesendet: Dienstag, 29. Dezember 2020 10:50 > > An: Development list for mkgmap > > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > > > Hi Gerd & Carlos > > > > Reading and trying to understand the code, I'm finding a few > > strange > > things with the Overview map generation, DEM, 0x4a etc > > > > The most significant is that the MapBuilder invocation for the > > combined > > overview map normally runs without any options being passed to it. > > Only > > if --overview-dem-dist is supplied are all the other options > > (including > > --order-by-decreasing-area) passed in. I'm not sure if would be a > > good > > idea to supply all every time or just be more selective and filter > > out > > all but the necessary DEM options. > > > > I'm still investigating the overview map levels. The ovm_ files are > > produced with all the overview-levels as specified by options. When > > this is read back by the overview combiner, a 0x4a polygon is added > > covering each ovm_ tile, but it looks like it is at all levels, so, > > for > > a tile with a large area or lots of detail is very likely to be > > split > > (if --order-by) or shunted around into another subdivision and > > multiple > > copies might exist. > > > > My understanding of the purpose of the 0x4a is that, in the > > overview > > map, there should be exactly 1 per detailed tile. It would be > > sensible > > to set its maxResolution so it only occurs at one level. > > > > After the 0x4a polygon has been added, a couple of bits of code > > scan > > for them in all the overview polygons. It might be possible to > > improve > > this, given they have just been added in the same
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Ticker, yes, this code needs review, thanks for this. For now I've just disabled the --order-by-decreasing-area option for the overview map in r4590 I am not sure if it would be better to always pass the args to MapBuilder or only those for DEM. I'd prefer to always pass them but maybe there are other side effects Reg. size 1%: My understanding was that the merging of shapes is responsible for all of this, but I might be wrong. I am working on a routing issue that I found while looking at Carlos' problem. It only happens with --x-no-force-end-nodes-routing-nodes. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Mittwoch, 30. Dezember 2020 09:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd I'm going to experiment with the combined overview map and which options cause problems. Also look at the effect of 0x4a polygons at just 1 level. I also notices that the combined overview (osmmap.img) is a fraction of the size (~1%) of the sum of the ovm_ images that are used to build it. Ticker On Tue, 2020-12-29 at 15:52 +, Gerd Petermann wrote: > Hi Ticker, > > thanks for the hints. I agree that the code in OverviewBuilder is not > very clear. I'll have a closer look tomorrow, but at least we should > remove the -order-by-decreasing-area when copying the options. Or > maybe I change the code so that only the hgt/dem options are copied. > I guess I was too lazy there. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 29. Dezember 2020 10:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd & Carlos > > Reading and trying to understand the code, I'm finding a few strange > things with the Overview map generation, DEM, 0x4a etc > > The most significant is that the MapBuilder invocation for the > combined > overview map normally runs without any options being passed to it. > Only > if --overview-dem-dist is supplied are all the other options > (including > --order-by-decreasing-area) passed in. I'm not sure if would be a > good > idea to supply all every time or just be more selective and filter > out > all but the necessary DEM options. > > I'm still investigating the overview map levels. The ovm_ files are > produced with all the overview-levels as specified by options. When > this is read back by the overview combiner, a 0x4a polygon is added > covering each ovm_ tile, but it looks like it is at all levels, so, > for > a tile with a large area or lots of detail is very likely to be split > (if --order-by) or shunted around into another subdivision and > multiple > copies might exist. > > My understanding of the purpose of the 0x4a is that, in the overview > map, there should be exactly 1 per detailed tile. It would be > sensible > to set its maxResolution so it only occurs at one level. > > After the 0x4a polygon has been added, a couple of bits of code scan > for them in all the overview polygons. It might be possible to > improve > this, given they have just been added in the same processing phase. > > If --order-by-decreasing-area is used, the overview map combiner > shouldn't attempt to respect it because it doesn't have the full size > information of polygons that cross a tile boundary. Rather it should > respect the polygon ordering in each ovm_ tile. I'm not sure yet this > is feasible; Maybe something like the equivalent of --preserve > -element > order for this phase and look at all the logic paths of polygons to > stop any other order changes due to merging etc. > > 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 ___ 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
Hi Gerd I'm going to experiment with the combined overview map and which options cause problems. Also look at the effect of 0x4a polygons at just 1 level. I also notices that the combined overview (osmmap.img) is a fraction of the size (~1%) of the sum of the ovm_ images that are used to build it. Ticker On Tue, 2020-12-29 at 15:52 +, Gerd Petermann wrote: > Hi Ticker, > > thanks for the hints. I agree that the code in OverviewBuilder is not > very clear. I'll have a closer look tomorrow, but at least we should > remove the -order-by-decreasing-area when copying the options. Or > maybe I change the code so that only the hgt/dem options are copied. > I guess I was too lazy there. > > Gerd > > > Von: mkgmap-dev im Auftrag > von Ticker Berkin > Gesendet: Dienstag, 29. Dezember 2020 10:50 > An: Development list for mkgmap > Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map > > Hi Gerd & Carlos > > Reading and trying to understand the code, I'm finding a few strange > things with the Overview map generation, DEM, 0x4a etc > > The most significant is that the MapBuilder invocation for the > combined > overview map normally runs without any options being passed to it. > Only > if --overview-dem-dist is supplied are all the other options > (including > --order-by-decreasing-area) passed in. I'm not sure if would be a > good > idea to supply all every time or just be more selective and filter > out > all but the necessary DEM options. > > I'm still investigating the overview map levels. The ovm_ files are > produced with all the overview-levels as specified by options. When > this is read back by the overview combiner, a 0x4a polygon is added > covering each ovm_ tile, but it looks like it is at all levels, so, > for > a tile with a large area or lots of detail is very likely to be split > (if --order-by) or shunted around into another subdivision and > multiple > copies might exist. > > My understanding of the purpose of the 0x4a is that, in the overview > map, there should be exactly 1 per detailed tile. It would be > sensible > to set its maxResolution so it only occurs at one level. > > After the 0x4a polygon has been added, a couple of bits of code scan > for them in all the overview polygons. It might be possible to > improve > this, given they have just been added in the same processing phase. > > If --order-by-decreasing-area is used, the overview map combiner > shouldn't attempt to respect it because it doesn't have the full size > information of polygons that cross a tile boundary. Rather it should > respect the polygon ordering in each ovm_ tile. I'm not sure yet this > is feasible; Maybe something like the equivalent of --preserve > -element > order for this phase and look at all the logic paths of polygons to > stop any other order changes due to merging etc. > > 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 ___ 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
Hi Ticker, thanks for the hints. I agree that the code in OverviewBuilder is not very clear. I'll have a closer look tomorrow, but at least we should remove the -order-by-decreasing-area when copying the options. Or maybe I change the code so that only the hgt/dem options are copied. I guess I was too lazy there. Gerd Von: mkgmap-dev im Auftrag von Ticker Berkin Gesendet: Dienstag, 29. Dezember 2020 10:50 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map Hi Gerd & Carlos Reading and trying to understand the code, I'm finding a few strange things with the Overview map generation, DEM, 0x4a etc The most significant is that the MapBuilder invocation for the combined overview map normally runs without any options being passed to it. Only if --overview-dem-dist is supplied are all the other options (including --order-by-decreasing-area) passed in. I'm not sure if would be a good idea to supply all every time or just be more selective and filter out all but the necessary DEM options. I'm still investigating the overview map levels. The ovm_ files are produced with all the overview-levels as specified by options. When this is read back by the overview combiner, a 0x4a polygon is added covering each ovm_ tile, but it looks like it is at all levels, so, for a tile with a large area or lots of detail is very likely to be split (if --order-by) or shunted around into another subdivision and multiple copies might exist. My understanding of the purpose of the 0x4a is that, in the overview map, there should be exactly 1 per detailed tile. It would be sensible to set its maxResolution so it only occurs at one level. After the 0x4a polygon has been added, a couple of bits of code scan for them in all the overview polygons. It might be possible to improve this, given they have just been added in the same processing phase. If --order-by-decreasing-area is used, the overview map combiner shouldn't attempt to respect it because it doesn't have the full size information of polygons that cross a tile boundary. Rather it should respect the polygon ordering in each ovm_ tile. I'm not sure yet this is feasible; Maybe something like the equivalent of --preserve-element order for this phase and look at all the logic paths of polygons to stop any other order changes due to merging etc. 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] Tiles pruned in DEM map
Hi Gerd & Carlos Reading and trying to understand the code, I'm finding a few strange things with the Overview map generation, DEM, 0x4a etc The most significant is that the MapBuilder invocation for the combined overview map normally runs without any options being passed to it. Only if --overview-dem-dist is supplied are all the other options (including --order-by-decreasing-area) passed in. I'm not sure if would be a good idea to supply all every time or just be more selective and filter out all but the necessary DEM options. I'm still investigating the overview map levels. The ovm_ files are produced with all the overview-levels as specified by options. When this is read back by the overview combiner, a 0x4a polygon is added covering each ovm_ tile, but it looks like it is at all levels, so, for a tile with a large area or lots of detail is very likely to be split (if --order-by) or shunted around into another subdivision and multiple copies might exist. My understanding of the purpose of the 0x4a is that, in the overview map, there should be exactly 1 per detailed tile. It would be sensible to set its maxResolution so it only occurs at one level. After the 0x4a polygon has been added, a couple of bits of code scan for them in all the overview polygons. It might be possible to improve this, given they have just been added in the same processing phase. If --order-by-decreasing-area is used, the overview map combiner shouldn't attempt to respect it because it doesn't have the full size information of polygons that cross a tile boundary. Rather it should respect the polygon ordering in each ovm_ tile. I'm not sure yet this is feasible; Maybe something like the equivalent of --preserve-element order for this phase and look at all the logic paths of polygons to stop any other order changes due to merging etc. Ticker ___ 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
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 t
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Carlos, most of the options can be prefixed with no- since many years. 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. 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 > lates
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 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
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Gerd & Carlos I've started looking at this, but can't do anything serious until tomorrow. Ticker ___ 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
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 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
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 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 &
Re: [mkgmap-dev] Tiles pruned in DEM map
="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
________________________
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-profil
Re: [mkgmap-dev] Tiles pruned in DEM map
Hi Carlos,
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).
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.
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.
3) You use a special version of mkgmap, so please try also with the latest
version.
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 .
Gerd
Von: mkgmap-dev im Auftrag von Carlos
Dávila
Gesendet: Dienstag, 22. Dezember 2020 18:05
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Tiles pruned in DEM map
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}
--p
Re: [mkgmap-dev] Tiles pruned in DEM map
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
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
>
>
> 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
___
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
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
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] Tiles pruned in DEM map
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
