Re: [mkgmap-dev] splitter r590,wrong handling of relations

[Gerd Petermann]

Hi Thomas,

I've just fixed the relation [1], so please try again with a fresh download 
tomorrow.

Gerd
[1] https://www.openstreetmap.org/changeset/56139020


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Dienstag, 6. Februar 2018 14:47
An: Thomas Morgenstern; Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Thomas,

the relation is broken. Use JOSM validator and it will report 2 errors.
I think this way
https://www.openstreetmap.org/way/556302821
should not belong to it and a few nodes should be merged to repiar it:
node 4298102908
node 4298102907
node 655141348

Gerd


Von: mkgmap-dev  im Auftrag von Thomas 
Morgenstern 
Gesendet: Dienstag, 6. Februar 2018 14:35
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Gerd, i have now made a different split, so that 1 tile contains the
whole isle. In this case it looks good. I assume, that the relation is okay.
No idea what should be changed in data. Also i have looked before with JOSM
in the old split and  confirm, that in the left tile the relation also
exists, but not rendered from mkgmap. I can't judge, if the relation is
broken or not. Therefore the problem is in mkgmap ? I
thomas

--
Von: "Gerd Petermann" 
Datum: Dienstag, 6. Februar 2018 12:15
An: "Thomas Morgenstern" ; "Development list for
mkgmap" 
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations

> Hi Thomas,
>
> I think the problem is that the relation is broken. Splitter writes it to
> both tiles, but
> mkgmap seems to have problems with it.
> Anyway, the problem is in the data and should be fixed in OSM.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Thomas Morgenstern 
> Gesendet: Dienstag, 6. Februar 2018 12:50
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] splitter r590,wrong handling of relations
>
> Hi Gerd, i found out, that splitter r590 can not proper handle the
> relation
> 2.691.138. I can reproduce the problem. It makes no different, if I splitt
> the canary-islands-latest.osm.pbf with the default-option or with my own
> splitt.list. If I move the tileborder by changing the nord-south border,
> also the problem is moved. See picture at
> http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary
> splitter
> creates only for the rightsite tile the polygon for  tag
> boundary=protected_area , respektive leisure=nature_reserve. In the
> leftsite-tile this tags are missing.
> maybee you can have a look at that ?
>
> regards thomas
>
>
>
> ___
> 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] max-jobs patch

[Mike Baggaley]

Hi Gerd, please find attached v2 of the max-jobs patch.

This version additionally catches out of heap memory exceptions and displays
a message suggesting either the use of the Java -Xmx option to increase the
available heap memory or the mkgmap --max-jobs option with a smaller value
to reduce the memory requirement (the latter is suggested only if using more
than one thread).

How does that seem?
Regards,
Mike

-Original Message-
From: Gerd Petermann [mailto:gpetermann_muenc...@hotmail.com] 
Sent: 05 February 2018 07:28
To: Mike Baggaley ; 'Development list for mkgmap'

Subject: Re: [mkgmap-dev] max-jobs patch

Hi Mike,

thought about this again. Maybe this change is too simple. With multiple
jobs one also
needs more heap (-Xmx JRE option). If you create rather large tiles with
splitter (max-nodes=160)
you need 0.5 - 1 GB for each job. Not sure what happens when a user creates
a map with
10 tiles on an 8-core machine without any -Xmx option.

I fear this will result in OutOfMemory exception, so better check the
available heap as well.

Gerd


Von: mkgmap-dev  im Auftrag von Mike
Baggaley 
Gesendet: Sonntag, 4. Februar 2018 15:14
An: 'Development list for mkgmap'
Betreff: [mkgmap-dev] max-jobs patch

Hi Gerd,

Please find attached a patch that amends the default behaviour if the
--max-jobs option is not specified, to using a value equal to the number of
CPU cores, as suggested in a previous post. The documentation is also
amended to reflect the change. This halves the execution time of mkgmap for
building a map of Staffordshire on my 8-core PC when --max-jobs is not
specified (I didn't know about this option previously and was unaware the
performance could have been improved).

Cheers,
Mike



maxjobs-v2.patch
Description: Binary data
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev

Re: [mkgmap-dev] Garmin uses overlapping tiles

[Gerd Petermann]

Hi Andrzej,

changing the TRE bounds helps sometimes, but not always :-(

@Frank: All Garmin TRE files that I looked at where aligned to multiples of 4 
map units.
I tried this as well as aligning to multiples of 2, nothing worked without 
crashes so far.

Anyhow, it seems to be the right thing to look at.

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Dienstag, 6. Februar 2018 15:49
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Garmin uses overlapping tiles

Hi Gerd,

I guess basemap is overview map. 0x4A objects are derived form
backgrounds of detailed tiles, but with resolution of overview map, it
would be difficult to guess, if background overlap or not.

I hope extending values written to TRE will work.

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

Re: [mkgmap-dev] Garmin uses overlapping tiles

[Frank Stinner]

Hi Gerd,

i have only picked 1 IMG from the "Garmin TransAlpin v2" (Immenstadt im 
Allgau / 16596679.img). The TRE-borders are overlapping with 2 units with 
all the 4 neighbors. Perhaps a border-value is ever even (?).


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

Re: [mkgmap-dev] Garmin uses overlapping tiles

[Andrzej Popowski]

Hi Gerd,

I guess basemap is overview map. 0x4A objects are derived form 
backgrounds of detailed tiles, but with resolution of overview map, it 
would be difficult to guess, if background overlap or not.


I hope extending values written to TRE will work.

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

Re: [mkgmap-dev] Garmin uses overlapping tiles

[Gerd Petermann]

Hi Andrzej,

hard to say where exactly the DEM area ends on the right / bottom side.

I got the info about 0x4a polygons from GPSMapEdit looking at the basemap.
MapSource shows the tile boundary more or less exactly at E16.5, so I have no 
idea
whrere the 0x4a value comes from.

I don't plan to change splitter, I want to change the TRE file written by 
mkgmap.
Working on a patch right now ...

Gerd


Von: mkgmap-dev  im Auftrag von Andrzej 
Popowski 
Gesendet: Dienstag, 6. Februar 2018 14:57
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Garmin uses overlapping tiles

Hi Gerd,

I have some questions.

Is TRE area bigger than DEM area or tiles overlap but still DEM area is
bigger than TRE? It looks like overlap is 4 Garmin's units, this is less
than DEM raster size.

 > The next interesting point is that the 0x4a polygons of these two
 > tiles do NOT overlap.
 > They seem to share  768896 (!).

Is it a typo? I guess: polygon 0x4B and 768856

Does map data overlap too, or this is only extended rectangle size
written to TRE header? If backgrounds don't overlap, maybe real map data
don't either. If I get border value right, than maybe tile is extended
only at left and top border?

What about routing nodes, if splitter creates overlapped tiles? I think
there should be an external routing node where road crosses tile border.
There would be mismatch, if tiles overlap.

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

Re: [mkgmap-dev] Garmin uses overlapping tiles

[Andrzej Popowski]

Hi Gerd,

I have some questions.

Is TRE area bigger than DEM area or tiles overlap but still DEM area is 
bigger than TRE? It looks like overlap is 4 Garmin's units, this is less 
than DEM raster size.


> The next interesting point is that the 0x4a polygons of these two
> tiles do NOT overlap.
> They seem to share  768896 (!).

Is it a typo? I guess: polygon 0x4B and 768856

Does map data overlap too, or this is only extended rectangle size 
written to TRE header? If backgrounds don't overlap, maybe real map data 
don't either. If I get border value right, than maybe tile is extended 
only at left and top border?


What about routing nodes, if splitter creates overlapped tiles? I think 
there should be an external routing node where road crosses tile border. 
There would be mismatch, if tiles overlap.


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

Re: [mkgmap-dev] splitter r590,wrong handling of relations

[Gerd Petermann]

Hi Thomas,

the relation is broken. Use JOSM validator and it will report 2 errors.
I think this way
https://www.openstreetmap.org/way/556302821
should not belong to it and a few nodes should be merged to repiar it:
node 4298102908
node 4298102907
node 655141348

Gerd


Von: mkgmap-dev  im Auftrag von Thomas 
Morgenstern 
Gesendet: Dienstag, 6. Februar 2018 14:35
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Gerd, i have now made a different split, so that 1 tile contains the
whole isle. In this case it looks good. I assume, that the relation is okay.
No idea what should be changed in data. Also i have looked before with JOSM
in the old split and  confirm, that in the left tile the relation also
exists, but not rendered from mkgmap. I can't judge, if the relation is
broken or not. Therefore the problem is in mkgmap ? I
thomas

--
Von: "Gerd Petermann" 
Datum: Dienstag, 6. Februar 2018 12:15
An: "Thomas Morgenstern" ; "Development list for
mkgmap" 
Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations

> Hi Thomas,
>
> I think the problem is that the relation is broken. Splitter writes it to
> both tiles, but
> mkgmap seems to have problems with it.
> Anyway, the problem is in the data and should be fixed in OSM.
>
> Gerd
>
>
> 
> Von: mkgmap-dev  im Auftrag von
> Thomas Morgenstern 
> Gesendet: Dienstag, 6. Februar 2018 12:50
> An: Development list for mkgmap
> Betreff: [mkgmap-dev] splitter r590,wrong handling of relations
>
> Hi Gerd, i found out, that splitter r590 can not proper handle the
> relation
> 2.691.138. I can reproduce the problem. It makes no different, if I splitt
> the canary-islands-latest.osm.pbf with the default-option or with my own
> splitt.list. If I move the tileborder by changing the nord-south border,
> also the problem is moved. See picture at
> http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary
> splitter
> creates only for the rightsite tile the polygon for  tag
> boundary=protected_area , respektive leisure=nature_reserve. In the
> leftsite-tile this tags are missing.
> maybee you can have a look at that ?
>
> regards thomas
>
>
>
> ___
> 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] splitter r590,wrong handling of relations

[Thomas Morgenstern]

Hi Gerd, i have now made a different split, so that 1 tile contains the 
whole isle. In this case it looks good. I assume, that the relation is okay. 
No idea what should be changed in data. Also i have looked before with JOSM 
in the old split and  confirm, that in the left tile the relation also 
exists, but not rendered from mkgmap. I can't judge, if the relation is 
broken or not. Therefore the problem is in mkgmap ? I

thomas

--
Von: "Gerd Petermann" 
Datum: Dienstag, 6. Februar 2018 12:15
An: "Thomas Morgenstern" ; "Development list for 
mkgmap" 

Betreff: Re: [mkgmap-dev] splitter r590,wrong handling of relations


Hi Thomas,

I think the problem is that the relation is broken. Splitter writes it to 
both tiles, but

mkgmap seems to have problems with it.
Anyway, the problem is in the data and should be fixed in OSM.

Gerd



Von: mkgmap-dev  im Auftrag von 
Thomas Morgenstern 

Gesendet: Dienstag, 6. Februar 2018 12:50
An: Development list for mkgmap
Betreff: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Gerd, i found out, that splitter r590 can not proper handle the 
relation

2.691.138. I can reproduce the problem. It makes no different, if I splitt
the canary-islands-latest.osm.pbf with the default-option or with my own
splitt.list. If I move the tileborder by changing the nord-south border,
also the problem is moved. See picture at
http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary 
splitter

creates only for the rightsite tile the polygon for  tag
boundary=protected_area , respektive leisure=nature_reserve. In the
leftsite-tile this tags are missing.
maybee you can have a look at that ?

regards thomas



___
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] splitter r590,wrong handling of relations

[Gerd Petermann]

Hi Thomas,

I think the problem is that the relation is broken. Splitter writes it to both 
tiles, but
mkgmap seems to have problems with it.
Anyway, the problem is in the data and should be fixed in OSM.

Gerd



Von: mkgmap-dev  im Auftrag von Thomas 
Morgenstern 
Gesendet: Dienstag, 6. Februar 2018 12:50
An: Development list for mkgmap
Betreff: [mkgmap-dev] splitter r590,wrong handling of relations

Hi Gerd, i found out, that splitter r590 can not proper handle the relation
2.691.138. I can reproduce the problem. It makes no different, if I splitt
the canary-islands-latest.osm.pbf with the default-option or with my own
splitt.list. If I move the tileborder by changing the nord-south border,
also the problem is moved. See picture at
http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary splitter
creates only for the rightsite tile the polygon for  tag
boundary=protected_area , respektive leisure=nature_reserve. In the
leftsite-tile this tags are missing.
maybee you can have a look at that ?

regards thomas



___
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] splitter r590,wrong handling of relations

[Thomas Morgenstern]

Hi Gerd, i found out, that splitter r590 can not proper handle the relation 
2.691.138. I can reproduce the problem. It makes no different, if I splitt 
the canary-islands-latest.osm.pbf with the default-option or with my own 
splitt.list. If I move the tileborder by changing the nord-south border, 
also the problem is moved. See picture at 
http://img2ms.de/OSM/ErrorInSplitter-r590.jpg. At the tile-boundary splitter 
creates only for the rightsite tile the polygon for  tag 
boundary=protected_area , respektive leisure=nature_reserve. In the 
leftsite-tile this tags are missing.

maybee you can have a look at that ?

regards thomas



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

[mkgmap-dev] Garmin uses overlapping tiles

[Gerd Petermann]

Hi all,

so far I've never seen the crash in MapSource using the Garmin maps, although 
they also have
tiles with "invalid heights" and therefore the tile headers have the "Extra 
flag".

my idea: 
- use mkgmap to create DEM data for exactly the same two areas as in a Garmin 
map [1]
- Try to reproduce the crash with those two areas 
- replace Garmin DEM by mkgmap DEM and see what happens in MapSource

The interesting point: Garmin tiles overlap. I've created this areas.list from 
the information 
in two Garmin TRE files:

0029: 2174824,745652 to 2190360,768956
# 46,6667,16, 47,,16,5000 
0030: 2174824,768952 to 2190360,792260 
# 46,6667,16,4999 47,,17,0001

Note that  the first tile has eastern border at 768956 while the 2nd uses 
768952 for the western border.

When I use exactly those values I cannot reproduce the crash.
When I move the boundary of  one of the two tiles so that they are equal I can 
reproduce the crash,
but not always with the same routes. I tried 768952, 768954, 768956.
So, I tried to change mkgmap so that it calculates DEM as if the tile 
boundaries are overlapping,
but with TRE where tiles have same 768956 --> crash possible.

The next interesting point is that the 0x4a polygons of these two tiles do NOT 
overlap.
They seem to share  768896 (!).
So, I used a new   areas.list with this value and still see the crash.

My conclusion:
We have to modify mkgmap to write a different TRE file, probably it has to 
cover the DEM area as well.
Does that make sense?

Gerd

[1] TopoGuide Hungary 2.12c 
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev