Re: [mkgmap-dev] Split gmapsupp.img

[Gerd Petermann]

Hi Felix,

I also thought about this alternative. Sad news that it doesn't work :(
Yesterday I managed to download a map for Europe, so I think I have now the 
data to play with this.

Gerd


Von: mkgmap-dev  im Auftrag von Felix 
Hartmann 
Gesendet: Montag, 19. Oktober 2020 20:37
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Split gmapsupp.img

MapInstall cannot be scripted to create a gmapsupp.img (plus setting it up on 
linux is a pain). I'm pretty sure the <4GB gmapsupp part files - shouldn't be 
too difficult if mkgmap can associate the address index for the choses tiles 
only.
Right now for scripting I can only see how to create gmapsupp part files 
without address search.

Cutting Europe into smaller parts using osmcut or similar takes quite a lot of 
time, plus if you compile a full map of Europe anyhow already - would kinda 
double the work. And you would need to adapt the area rather often as osm data 
increases...
Having mkgmap split the map into parts would be great therefore (and also put 
out some sort of parts.list similar to the areas.list from splitter would be 
even better).

On Mon, 19 Oct 2020 at 17:15, Carlos Dávila 
mailto:car...@alternativaslibres.org>> wrote:
El 19/10/20 a las 0:30, Andrzej Popowski escribió:
> Hi Carlos,
>
> splitting could be useful, when you'd like to create img in one step.
> Other option is to install map on PC and then use MapInstall to create
> img. MapInstall does splitting for big maps.
>
Hi Andrej

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

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


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

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

Re: [mkgmap-dev] Resurrect adjust-turn-headings

[Gerd Petermann]

Hi Ticker,

sorry for the delay. I've started to compare the results of the patched and the 
original version. I think there might be a problem with --x-ignore-sharp-angles.
I assume that patch disables the compact dirs when this undocument option is 
used?

Gerd


Von: mkgmap-dev  im Auftrag von Gerd 
Petermann 
Gesendet: Mittwoch, 14. Oktober 2020 19:26
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings

Hi Ticker,

thanks for the patch. I'll have a closer look at the weekend.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Mittwoch, 14. Oktober 2020 10:24
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings

Hi Gerd

I've been looking at turn pop-ups and routing decisions and attach a
patch that makes improvements:

Move decision about when to use compactDir initialHeadings from
RouteNode to AngleChecker.
The current code checks if any headings from a RouteNode share the same
compactDir/4-bit sector and, if so, revert to the full/8-bit value.
Overlaid roads triggered this, also sharp angles that couldn't be
widened, probably when many paths converge at a road.

AngleChecker::fixSharpAngles was coded on the basis that compactDirs
are used and it tested/increased angles based on this 4-bit step, but
if these are then represented in 8-bit format, the encode angle could
be much (up to 22.5 degrees) less that the code was expecting and
result in turning delays in route calculations.

Recode fixSharpAngles to work in degrees but choose the thresholds to
be good for compactDirs. Test the resultant angles and only use
compactDirs if there are no roads in the same or adjacent 4-bit
sectors.
Not allowing Adjacent is necessary because, in compactDirs format, if
there is a path in the opposite sector to the road and the road
continuation is the adjacent sector, Garmin gives a "turn to stay on
road" pop-up, but with 8-bit headings it doesn't. This is slightly
different from the following case because this concerns an angle that
doesn't need to be "unsharpened" as it isn't permitted for vehicles to
make this turn.

When increasing an angle, change the heading of the lower class/speed
road in preference to the major road.
This helps prevent the "turn to stay on road" type pop-ups when the
lead-off road was more straight-on than the main road and one-way
tagging possibly missing.

Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving
slight efficiency improvements.

Add some diagnostics for showing RouteNodes and RouteArcs in an area.

Tidy up normalisation of headings.

Fix some bugs.

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] Resurrect adjust-turn-headings

[Ticker Berkin]

Hi Gerd

Yes, with --x-ignore-sharp-angles, the compactDirs format is disabled.
Some of the example problems I looked at behaved much better when not
using compactDirs, so it seemed reasonable, to avoid more developer "-
-x-" type options, to have it this way.

I thought about having another option to control this when "ignore
-sharp-angles", with options to force on, force off and auto mode that
looks for the cases of 2 roads being in the same sector or where the
road continuation isn't in the opposite sector but some other way is.

I can do something like this if you think it worthwhile.

Ticker

On Tue, 2020-10-20 at 08:10 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> sorry for the delay. I've started to compare the results of the
> patched and the original version. I think there might be a problem
> with --x-ignore-sharp-angles.
> I assume that patch disables the compact dirs when this undocument
> option is used?
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Mittwoch, 14. Oktober 2020 19:26
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
> 
> Hi Ticker,
> 
> thanks for the patch. I'll have a closer look at the weekend.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 14. Oktober 2020 10:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
> 
> Hi Gerd
> 
> I've been looking at turn pop-ups and routing decisions and attach a
> patch that makes improvements:
> 
> Move decision about when to use compactDir initialHeadings from
> RouteNode to AngleChecker.
> The current code checks if any headings from a RouteNode share the
> same
> compactDir/4-bit sector and, if so, revert to the full/8-bit value.
> Overlaid roads triggered this, also sharp angles that couldn't be
> widened, probably when many paths converge at a road.
> 
> AngleChecker::fixSharpAngles was coded on the basis that compactDirs
> are used and it tested/increased angles based on this 4-bit step, but
> if these are then represented in 8-bit format, the encode angle could
> be much (up to 22.5 degrees) less that the code was expecting and
> result in turning delays in route calculations.
> 
> Recode fixSharpAngles to work in degrees but choose the thresholds to
> be good for compactDirs. Test the resultant angles and only use
> compactDirs if there are no roads in the same or adjacent 4-bit
> sectors.
> Not allowing Adjacent is necessary because, in compactDirs format, if
> there is a path in the opposite sector to the road and the road
> continuation is the adjacent sector, Garmin gives a "turn to stay on
> road" pop-up, but with 8-bit headings it doesn't. This is slightly
> different from the following case because this concerns an angle that
> doesn't need to be "unsharpened" as it isn't permitted for vehicles
> to
> make this turn.
> 
> When increasing an angle, change the heading of the lower class/speed
> road in preference to the major road.
> This helps prevent the "turn to stay on road" type pop-ups when the
> lead-off road was more straight-on than the main road and one-way
> tagging possibly missing.
> 
> Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving
> slight efficiency improvements.
> 
> Add some diagnostics for showing RouteNodes and RouteArcs in an area.
> 
> Tidy up normalisation of headings.
> 
> Fix some bugs.
> 
> 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] Polygon fill

[Vuki]

  
  

  Hello Guys,
  I am brewing custom maps for my Garmin zumo 396.
  - get the OSM data from the overpass api (0.5 by 0.5 degree
bounding box) 
- use splitter to split too large parts
- use mkgmap to build the maps.
  The generated garmin maps have wrong filled polygons, lakes are
filled with land and vice versa.
Here are two examples (lake Balatom and lake Geneva)
  http://www.informatik.hu/balaton.jpg
http://www.informatik.hu/geneva.jpg
  When I download the lake Balaton in one bounding box the
artefacts are disappearing, thus there must be something merging
the files.
I have tried various mkgmap settings but could not solve the
issues. Curret config is:
  levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
add-pois-to-areas
add-pois-to-lines
adjust-turn-headings
bounds: ../bounds-latest.zip
check-roundabout-flares
check-roundabouts
copyright-message: Map data © Openstreetmap.org
drive-on=detect,right
generate-sea: land-tag=natural=background
gmapi
gmapsupp
housenumbers
ignore-maxspeeds
index
keep-going
latin1
link-pois-to-ways
location-autofill: is_in,nearest
make-opposite-cycleways
merge-lines
name-tag-list: int_name,name:en,name:hu,name,place_name
#nsis
order-by-decreasing-area
precomp-sea: ../sea-latest.zip
preserve-element-order
process-destination
process-exits
reduce-point-density-polygon=8
reduce-point-density=3
remove-ovm-work-files
remove-short-arcs
road-name-pois
route 
# show-profiles: 1
style-file: ../styles
style: default
tdbfile
x-split-name-index
verbose
  Do you have any ideas what can cause the issue?
  
  
  
  -- 
Br,
Vuki

  

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

Re: [mkgmap-dev] Resurrect adjust-turn-headings

[Gerd Petermann]

Hi Ticker,

my understanding is that original Garmin maps use compact dirs a lot, so I 
think it is not a good idea to disable them. My problem with the patch is that 
NodCheck complains a lot more
Steve and I are not sure how Garmin calculates the encoded angles, so we are 
still just guessing. Your approach might well be the best so far.
The code in NodCheck has one big problem: It uses the data stored in RGN to 
calculate the bearings, and that means 24 bit precision. So for nearby nodes 
the rounding errors are too big and NodCheck uses a fallback algo which selects 
another point.
I guess Garmin also calculates the NOD data with more than 24 bit precision, so 
they probably also have some kind of angle fixer.
How did you test your changes? I think I used fake data that contained two 
alternative routes. That helped me  to find the threshold values for the 
penalties.
I also used real world OSM data to check special cases like roundabouts or 
*_link  roads.
Unfortunately it is very difficult to create unit tests for this, and the risk 
is high that a change improves 10 cases but worsens another 10, esp. with other 
styles or in other countries.

Maybe there is only one way to find out. I commit your patch and we wait for 
comments here or in the Garmin forum...

Gerd






Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 20. Oktober 2020 10:46
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings

Hi Gerd

Yes, with --x-ignore-sharp-angles, the compactDirs format is disabled.
Some of the example problems I looked at behaved much better when not
using compactDirs, so it seemed reasonable, to avoid more developer "-
-x-" type options, to have it this way.

I thought about having another option to control this when "ignore
-sharp-angles", with options to force on, force off and auto mode that
looks for the cases of 2 roads being in the same sector or where the
road continuation isn't in the opposite sector but some other way is.

I can do something like this if you think it worthwhile.

Ticker

On Tue, 2020-10-20 at 08:10 +, Gerd Petermann wrote:
> Hi Ticker,
>
> sorry for the delay. I've started to compare the results of the
> patched and the original version. I think there might be a problem
> with --x-ignore-sharp-angles.
> I assume that patch disables the compact dirs when this undocument
> option is used?
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Gerd Petermann 
> Gesendet: Mittwoch, 14. Oktober 2020 19:26
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
>
> Hi Ticker,
>
> thanks for the patch. I'll have a closer look at the weekend.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Mittwoch, 14. Oktober 2020 10:24
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
>
> Hi Gerd
>
> I've been looking at turn pop-ups and routing decisions and attach a
> patch that makes improvements:
>
> Move decision about when to use compactDir initialHeadings from
> RouteNode to AngleChecker.
> The current code checks if any headings from a RouteNode share the
> same
> compactDir/4-bit sector and, if so, revert to the full/8-bit value.
> Overlaid roads triggered this, also sharp angles that couldn't be
> widened, probably when many paths converge at a road.
>
> AngleChecker::fixSharpAngles was coded on the basis that compactDirs
> are used and it tested/increased angles based on this 4-bit step, but
> if these are then represented in 8-bit format, the encode angle could
> be much (up to 22.5 degrees) less that the code was expecting and
> result in turning delays in route calculations.
>
> Recode fixSharpAngles to work in degrees but choose the thresholds to
> be good for compactDirs. Test the resultant angles and only use
> compactDirs if there are no roads in the same or adjacent 4-bit
> sectors.
> Not allowing Adjacent is necessary because, in compactDirs format, if
> there is a path in the opposite sector to the road and the road
> continuation is the adjacent sector, Garmin gives a "turn to stay on
> road" pop-up, but with 8-bit headings it doesn't. This is slightly
> different from the following case because this concerns an angle that
> doesn't need to be "unsharpened" as it isn't permitted for vehicles
> to
> make this turn.
>
> When increasing an angle, change the heading of the lower class/speed
> road in preference to the major road.
> This helps prevent the "turn to stay on road" type pop-ups when the
> lead-off road was more straight-on than the main road and one-way
> tagging possibly missing.
>
> Handle simple (<= 2 RouteArcs) RouteNodes as special cases, giving
> slight efficiency improvements.
>
> Add some diagnostics for showing RouteNodes and RouteArcs in an area.
>
> Tidy up normalisation of headings.
>

Re: [mkgmap-dev] Polygon fill

[Gerd Petermann]

Hi Vuki,

flooded lakes are typically caused by incomplete multipolygons. Another reason 
can be that the OSM data itself is wrong. Do you use splitter with the 
keep-complete option enabled?

Best way to verify is to load a tile that contains a part of the lake in JOSM 
(use the pbf or o5m plugin). If JOSM shows a problem than mkgmap cannot be 
blamed.

Gerd


Von: mkgmap-dev  im Auftrag von Vuki 

Gesendet: Dienstag, 20. Oktober 2020 11:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Polygon fill

Hello Guys,

I am brewing custom maps for my Garmin zumo 396.

- get the OSM data from the overpass api (0.5 by 0.5 degree bounding box)
- use splitter to split too large parts
- use mkgmap to build the maps.

The generated garmin maps have wrong filled polygons, lakes are filled with 
land and vice versa.
Here are two examples (lake Balatom and lake Geneva)

http://www.informatik.hu/balaton.jpg
http://www.informatik.hu/geneva.jpg

When I download the lake Balaton in one bounding box the artefacts are 
disappearing, thus there must be something merging the files.
I have tried various mkgmap settings but could not solve the issues. Curret 
config is:

levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
add-pois-to-areas
add-pois-to-lines
adjust-turn-headings
bounds: ../bounds-latest.zip
check-roundabout-flares
check-roundabouts
copyright-message: Map data © Openstreetmap.org
drive-on=detect,right
generate-sea: land-tag=natural=background
gmapi
gmapsupp
housenumbers
ignore-maxspeeds
index
keep-going
latin1
link-pois-to-ways
location-autofill: is_in,nearest
make-opposite-cycleways
merge-lines
name-tag-list: int_name,name:en,name:hu,name,place_name
#nsis
order-by-decreasing-area
precomp-sea: ../sea-latest.zip
preserve-element-order
process-destination
process-exits
reduce-point-density-polygon=8
reduce-point-density=3
remove-ovm-work-files
remove-short-arcs
road-name-pois
route
# show-profiles: 1
style-file: ../styles
style: default
tdbfile
x-split-name-index
verbose

Do you have any ideas what can cause the issue?


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

Re: [mkgmap-dev] Polygon fill

[7770]

Hi.
I noted a similar thing with Sweden (Stockholm area) where the sea floods the 
land. 
The only change that i recall i have made is to update the sea data file.
Earlier i had one from the beginning of october, and only one or two days ago 
(18'th or 19th of october)  i updated the sea file. The map data was not 
updated so i don't think i have introduced other issues.

i went back to an earlier version of the sea file
http://osm.thkukuk.de/data/
sea-20200921001501.zip

This at least resolved my issue.
It's hard to say if your problem is identical, but you may want to try.


Karl

On tisdag 20 oktober 2020 kl. 11:17:14 CEST Vuki wrote:
> Hello Guys,
> 
> I am brewing custom maps for my Garmin zumo 396.
> 
> - get the OSM data from the overpass api (0.5 by 0.5 degree bounding box)
> - use splitter to split too large parts
> - use mkgmap to build the maps.
> 
> The generated garmin maps have wrong filled polygons, lakes are filled with
> land and vice versa. Here are two examples (lake Balatom and lake Geneva)
> 
> http://www.informatik.hu/balaton.jpg
> http://www.informatik.hu/geneva.jpg
> 
> When I download the lake Balaton in one bounding box the artefacts are
> disappearing, thus there must be something merging the files. I have tried
> various mkgmap settings but could not solve the issues. Curret config is:
> 
> levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
> add-pois-to-areas
> add-pois-to-lines
> adjust-turn-headings
> bounds: ../bounds-latest.zip
> check-roundabout-flares
> check-roundabouts
> copyright-message: Map data © Openstreetmap.org
> drive-on=detect,right
> generate-sea: land-tag=natural=background
> gmapi
> gmapsupp
> housenumbers
> ignore-maxspeeds
> index
> keep-going
> latin1
> link-pois-to-ways
> location-autofill: is_in,nearest
> make-opposite-cycleways
> merge-lines
> name-tag-list: int_name,name:en,name:hu,name,place_name
> #nsis
> order-by-decreasing-area
> precomp-sea: ../sea-latest.zip
> preserve-element-order
> process-destination
> process-exits
> reduce-point-density-polygon=8
> reduce-point-density=3
> remove-ovm-work-files
> remove-short-arcs
> road-name-pois
> route
> # show-profiles: 1
> style-file: ../styles
> style: default
> tdbfile
> x-split-name-index
> verbose
> 
> Do you have any ideas what can cause the issue?




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

Re: [mkgmap-dev] Polygon fill

[Gerd Petermann]

Hi Karl,

not related. These lakes are not handled by the precomp-sea data. You are right 
whenever the problem is related to coastline data.

Gerd


Von: mkgmap-dev  im Auftrag von 7770 
<7...@foskan.eu>
Gesendet: Dienstag, 20. Oktober 2020 13:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Polygon fill

Hi.
I noted a similar thing with Sweden (Stockholm area) where the sea floods the
land.
The only change that i recall i have made is to update the sea data file.
Earlier i had one from the beginning of october, and only one or two days ago
(18'th or 19th of october)  i updated the sea file. The map data was not
updated so i don't think i have introduced other issues.

i went back to an earlier version of the sea file
http://osm.thkukuk.de/data/
sea-20200921001501.zip

This at least resolved my issue.
It's hard to say if your problem is identical, but you may want to try.


Karl

On tisdag 20 oktober 2020 kl. 11:17:14 CEST Vuki wrote:
> Hello Guys,
>
> I am brewing custom maps for my Garmin zumo 396.
>
> - get the OSM data from the overpass api (0.5 by 0.5 degree bounding box)
> - use splitter to split too large parts
> - use mkgmap to build the maps.
>
> The generated garmin maps have wrong filled polygons, lakes are filled with
> land and vice versa. Here are two examples (lake Balatom and lake Geneva)
>
> http://www.informatik.hu/balaton.jpg
> http://www.informatik.hu/geneva.jpg
>
> When I download the lake Balaton in one bounding box the artefacts are
> disappearing, thus there must be something merging the files. I have tried
> various mkgmap settings but could not solve the issues. Curret config is:
>
> levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
> add-pois-to-areas
> add-pois-to-lines
> adjust-turn-headings
> bounds: ../bounds-latest.zip
> check-roundabout-flares
> check-roundabouts
> copyright-message: Map data © Openstreetmap.org
> drive-on=detect,right
> generate-sea: land-tag=natural=background
> gmapi
> gmapsupp
> housenumbers
> ignore-maxspeeds
> index
> keep-going
> latin1
> link-pois-to-ways
> location-autofill: is_in,nearest
> make-opposite-cycleways
> merge-lines
> name-tag-list: int_name,name:en,name:hu,name,place_name
> #nsis
> order-by-decreasing-area
> precomp-sea: ../sea-latest.zip
> preserve-element-order
> process-destination
> process-exits
> reduce-point-density-polygon=8
> reduce-point-density=3
> remove-ovm-work-files
> remove-short-arcs
> road-name-pois
> route
> # show-profiles: 1
> style-file: ../styles
> style: default
> tdbfile
> x-split-name-index
> verbose
>
> Do you have any ideas what can cause the issue?




___
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] Resurrect adjust-turn-headings

[Ticker Berkin]

Hi Gerd

With sharp-angle code enabled, most junctions will get compactDirs;
just a few less than the existing code. Original gmapsupp.img for my
test area was 9801728 and with this change it is 4096 bytes bigger. 

I looked at some of the NodCheck angle errors and decided that not much
could be done as it only has the low-res road points to work with.

In mkgmap, the algo using hi-res points gave a good angle in all the
cases I looked at, so the code is now really there to deal with real
sharp junctions that cause the time penalty and misleading direction
pop-ups.

I had a list of troublesome junctions and looked at the angles in 8-bit
and 4-bit format before & after my changes to see that it was doing as
expected. I also looked the leg-time info from MapSource for various
routes. Since then I've been using it a lot for car routing and it
hasn't done anything that I've disagreed with.

It seemed that you had determined that there was no benefit in
increasing angles so that there was more than 1 empty sector between
vehicle arcs, so I just did the same such that it was also guaranteed
to work if the junction went non-compact for some other reason - an
angle of 23 degrees, say the arcs were at -11.5 and +11.5, would
considered non-sharp in compact format but is sharp in 8-bit format. 

Ticker

On Tue, 2020-10-20 at 09:25 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> my understanding is that original Garmin maps use compact dirs a lot,
> so I think it is not a good idea to disable them. My problem with the
> patch is that NodCheck complains a lot more
> Steve and I are not sure how Garmin calculates the encoded angles, so
> we are still just guessing. Your approach might well be the best so
> far.
> The code in NodCheck has one big problem: It uses the data stored in
> RGN to calculate the bearings, and that means 24 bit precision. So
> for nearby nodes the rounding errors are too big and NodCheck uses a
> fallback algo which selects another point.
> I guess Garmin also calculates the NOD data with more than 24 bit
> precision, so they probably also have some kind of angle fixer.
> How did you test your changes? I think I used fake data that
> contained two alternative routes. That helped me  to find the
> threshold values for the penalties.
> I also used real world OSM data to check special cases like
> roundabouts or *_link  roads.
> Unfortunately it is very difficult to create unit tests for this, and
> the risk is high that a change improves 10 cases but worsens another
> 10, esp. with other styles or in other countries.
> 
> Maybe there is only one way to find out. I commit your patch and we
> wait for comments here or in the Garmin forum...
> 
> Gerd

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

Re: [mkgmap-dev] Resurrect adjust-turn-headings

[Gerd Petermann]

Hi Ticker,

OK, I believe that you tested it well with the default style? Did you also try 
a style that adds multiple routable ways for one OSM way? Not sure if Felix 
still uses this for his maps on https://www.velomap.org/  but in the past this 
lead to all kinds of special cases that do not appear with the default style.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 20. Oktober 2020 14:30
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings

Hi Gerd

With sharp-angle code enabled, most junctions will get compactDirs;
just a few less than the existing code. Original gmapsupp.img for my
test area was 9801728 and with this change it is 4096 bytes bigger.

I looked at some of the NodCheck angle errors and decided that not much
could be done as it only has the low-res road points to work with.

In mkgmap, the algo using hi-res points gave a good angle in all the
cases I looked at, so the code is now really there to deal with real
sharp junctions that cause the time penalty and misleading direction
pop-ups.

I had a list of troublesome junctions and looked at the angles in 8-bit
and 4-bit format before & after my changes to see that it was doing as
expected. I also looked the leg-time info from MapSource for various
routes. Since then I've been using it a lot for car routing and it
hasn't done anything that I've disagreed with.

It seemed that you had determined that there was no benefit in
increasing angles so that there was more than 1 empty sector between
vehicle arcs, so I just did the same such that it was also guaranteed
to work if the junction went non-compact for some other reason - an
angle of 23 degrees, say the arcs were at -11.5 and +11.5, would
considered non-sharp in compact format but is sharp in 8-bit format.

Ticker

On Tue, 2020-10-20 at 09:25 +, Gerd Petermann wrote:
> Hi Ticker,
>
> my understanding is that original Garmin maps use compact dirs a lot,
> so I think it is not a good idea to disable them. My problem with the
> patch is that NodCheck complains a lot more
> Steve and I are not sure how Garmin calculates the encoded angles, so
> we are still just guessing. Your approach might well be the best so
> far.
> The code in NodCheck has one big problem: It uses the data stored in
> RGN to calculate the bearings, and that means 24 bit precision. So
> for nearby nodes the rounding errors are too big and NodCheck uses a
> fallback algo which selects another point.
> I guess Garmin also calculates the NOD data with more than 24 bit
> precision, so they probably also have some kind of angle fixer.
> How did you test your changes? I think I used fake data that
> contained two alternative routes. That helped me  to find the
> threshold values for the penalties.
> I also used real world OSM data to check special cases like
> roundabouts or *_link  roads.
> Unfortunately it is very difficult to create unit tests for this, and
> the risk is high that a change improves 10 cases but worsens another
> 10, esp. with other styles or in other countries.
>
> Maybe there is only one way to find out. I commit your patch and we
> wait for comments here or in the Garmin forum...
>
> 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] Polygon fill

[Ticker Berkin]

Hi Vuki

Various possibilities / questions:

Do you do anything particular with natural=background in your style.
The default is natural=land and the default style doesn't need to
generate anything for it because the device default background isn't
sea.

Do you have a typ file? Does it assign assign a hierarchy of
[_drawOrder] levels to the different types of polygons. 

With --order-by-decreasing-area, it is assumed that you give everything
except the background (0x4a/0x4b) the same value and that the device
renders polygons in the the order they appear in the .img file. It is
possible that your device doesn't do this.

In your examples, I only see parts of lakes not showing as water. As
far as I'm aware, these are not represented with coastline and sea
processing. They should have natural=water tags and generate standard
blue polygons (maybe 0x3c).

It is possible that the resolution these lakes appear at is too high,
but this is unlikely because it is showing the rivers within the lake.

Regards
Ticker

On Tue, 2020-10-20 at 11:17 +0200, Vuki wrote:
> > Hello Guys,
> > I am brewing custom maps for my Garmin zumo 396.
> > - get the OSM data from the overpass api (0.5 by 0.5 degree
> > bounding box) 
> > - use splitter to split too large parts
> > - use mkgmap to build the maps.
> > The generated garmin maps have wrong filled polygons, lakes are
> > filled with land and vice versa.
> > Here are two examples (lake Balatom and lake Geneva)
> > http://www.informatik.hu/balaton.jpg
> > http://www.informatik.hu/geneva.jpg
> > When I download the lake Balaton in one bounding box the artefacts
> > are disappearing, thus there must be something merging the files.
> > I have tried various mkgmap settings but could not solve the
> > issues. Curret config is:
> > levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
> > add-pois-to-areas
> > add-pois-to-lines
> > adjust-turn-headings
> > bounds: ../bounds-latest.zip
> > check-roundabout-flares
> > check-roundabouts
> > copyright-message: Map data © Openstreetmap.org
> > drive-on=detect,right
> > generate-sea: land-tag=natural=background
> > gmapi
> > gmapsupp
> > housenumbers
> > ignore-maxspeeds
> > index
> > keep-going
> > latin1
> > link-pois-to-ways
> > location-autofill: is_in,nearest
> > make-opposite-cycleways
> > merge-lines
> > name-tag-list: int_name,name:en,name:hu,name,place_name
> > #nsis
> > order-by-decreasing-area
> > precomp-sea: ../sea-latest.zip
> > preserve-element-order
> > process-destination
> > process-exits
> > reduce-point-density-polygon=8
> > reduce-point-density=3
> > remove-ovm-work-files
> > remove-short-arcs
> > road-name-pois
> > route 
> > # show-profiles: 1
> > style-file: ../styles
> > style: default
> > tdbfile
> > x-split-name-index
> > verbose
> > Do you have any ideas what can cause the issue?
> > 
> > -- 
> > Br,
> > Vuki
> ___
> 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] Resurrect adjust-turn-headings

[Ticker Berkin]

Hi Gerd

I kept the existing logic that takes all arcs within one degree and
treats them as one (and fixed the extra case where they straddle +-180)
so there should be no difference in this aspect.

Ticker

On Tue, 2020-10-20 at 12:48 +, Gerd Petermann wrote:
> Hi Ticker,
> 
> OK, I believe that you tested it well with the default style? Did you
> also try a style that adds multiple routable ways for one OSM way?
> Not sure if Felix still uses this for his maps on 
> https://www.velomap.org/  but in the past this lead to all kinds of
> special cases that do not appear with the default style.
> 
> Gerd
> 
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 20. Oktober 2020 14:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
> 
> Hi Gerd
> 
> With sharp-angle code enabled, most junctions will get compactDirs;
> just a few less than the existing code. Original gmapsupp.img for my
> test area was 9801728 and with this change it is 4096 bytes bigger.
> 
> I looked at some of the NodCheck angle errors and decided that not
> much
> could be done as it only has the low-res road points to work with.
> 
> In mkgmap, the algo using hi-res points gave a good angle in all the
> cases I looked at, so the code is now really there to deal with real
> sharp junctions that cause the time penalty and misleading direction
> pop-ups.
> 
> I had a list of troublesome junctions and looked at the angles in 8
> -bit
> and 4-bit format before & after my changes to see that it was doing
> as
> expected. I also looked the leg-time info from MapSource for various
> routes. Since then I've been using it a lot for car routing and it
> hasn't done anything that I've disagreed with.
> 
> It seemed that you had determined that there was no benefit in
> increasing angles so that there was more than 1 empty sector between
> vehicle arcs, so I just did the same such that it was also guaranteed
> to work if the junction went non-compact for some other reason - an
> angle of 23 degrees, say the arcs were at -11.5 and +11.5, would
> considered non-sharp in compact format but is sharp in 8-bit format.
> 
> Ticker
> 
> On Tue, 2020-10-20 at 09:25 +, Gerd Petermann wrote:
> > Hi Ticker,
> > 
> > my understanding is that original Garmin maps use compact dirs a
> > lot,
> > so I think it is not a good idea to disable them. My problem with
> > the
> > patch is that NodCheck complains a lot more
> > Steve and I are not sure how Garmin calculates the encoded angles,
> > so
> > we are still just guessing. Your approach might well be the best so
> > far.
> > The code in NodCheck has one big problem: It uses the data stored
> > in
> > RGN to calculate the bearings, and that means 24 bit precision. So
> > for nearby nodes the rounding errors are too big and NodCheck uses
> > a
> > fallback algo which selects another point.
> > I guess Garmin also calculates the NOD data with more than 24 bit
> > precision, so they probably also have some kind of angle fixer.
> > How did you test your changes? I think I used fake data that
> > contained two alternative routes. That helped me  to find the
> > threshold values for the penalties.
> > I also used real world OSM data to check special cases like
> > roundabouts or *_link  roads.
> > Unfortunately it is very difficult to create unit tests for this,
> > and
> > the risk is high that a change improves 10 cases but worsens
> > another
> > 10, esp. with other styles or in other countries.
> > 
> > Maybe there is only one way to find out. I commit your patch and we
> > wait for comments here or in the Garmin forum...
> > 
> > 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] Resurrect adjust-turn-headings

[Gerd Petermann]

Hi Ticker,

OK, let's try it. Some cleanup is needed. I see
- hard coded tests like if (isClose(51.182575, -1.388928, 0.002))
- dead code: getImgAngle() is not used

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 20. Oktober 2020 15:21
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings

Hi Gerd

I kept the existing logic that takes all arcs within one degree and
treats them as one (and fixed the extra case where they straddle +-180)
so there should be no difference in this aspect.

Ticker

On Tue, 2020-10-20 at 12:48 +, Gerd Petermann wrote:
> Hi Ticker,
>
> OK, I believe that you tested it well with the default style? Did you
> also try a style that adds multiple routable ways for one OSM way?
> Not sure if Felix still uses this for his maps on
> https://www.velomap.org/  but in the past this lead to all kinds of
> special cases that do not appear with the default style.
>
> Gerd
>
> 
> Von: mkgmap-dev  im Auftrag
> von Ticker Berkin 
> Gesendet: Dienstag, 20. Oktober 2020 14:30
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Resurrect adjust-turn-headings
>
> Hi Gerd
>
> With sharp-angle code enabled, most junctions will get compactDirs;
> just a few less than the existing code. Original gmapsupp.img for my
> test area was 9801728 and with this change it is 4096 bytes bigger.
>
> I looked at some of the NodCheck angle errors and decided that not
> much
> could be done as it only has the low-res road points to work with.
>
> In mkgmap, the algo using hi-res points gave a good angle in all the
> cases I looked at, so the code is now really there to deal with real
> sharp junctions that cause the time penalty and misleading direction
> pop-ups.
>
> I had a list of troublesome junctions and looked at the angles in 8
> -bit
> and 4-bit format before & after my changes to see that it was doing
> as
> expected. I also looked the leg-time info from MapSource for various
> routes. Since then I've been using it a lot for car routing and it
> hasn't done anything that I've disagreed with.
>
> It seemed that you had determined that there was no benefit in
> increasing angles so that there was more than 1 empty sector between
> vehicle arcs, so I just did the same such that it was also guaranteed
> to work if the junction went non-compact for some other reason - an
> angle of 23 degrees, say the arcs were at -11.5 and +11.5, would
> considered non-sharp in compact format but is sharp in 8-bit format.
>
> Ticker
>
> On Tue, 2020-10-20 at 09:25 +, Gerd Petermann wrote:
> > Hi Ticker,
> >
> > my understanding is that original Garmin maps use compact dirs a
> > lot,
> > so I think it is not a good idea to disable them. My problem with
> > the
> > patch is that NodCheck complains a lot more
> > Steve and I are not sure how Garmin calculates the encoded angles,
> > so
> > we are still just guessing. Your approach might well be the best so
> > far.
> > The code in NodCheck has one big problem: It uses the data stored
> > in
> > RGN to calculate the bearings, and that means 24 bit precision. So
> > for nearby nodes the rounding errors are too big and NodCheck uses
> > a
> > fallback algo which selects another point.
> > I guess Garmin also calculates the NOD data with more than 24 bit
> > precision, so they probably also have some kind of angle fixer.
> > How did you test your changes? I think I used fake data that
> > contained two alternative routes. That helped me  to find the
> > threshold values for the penalties.
> > I also used real world OSM data to check special cases like
> > roundabouts or *_link  roads.
> > Unfortunately it is very difficult to create unit tests for this,
> > and
> > the risk is high that a change improves 10 cases but worsens
> > another
> > 10, esp. with other styles or in other countries.
> >
> > Maybe there is only one way to find out. I commit your patch and we
> > wait for comments here or in the Garmin forum...
> >
> > 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] Split gmapsupp.img

[Andrzej Popowski]

Hi Felix,

> Right now for scripting I can only see how to create gmapsupp part
> files without address search.

Doesn't mkgmap combine *.img with correct index? I mean you can get like 
1000 of tiles after compiling a big area, but you can combine first 500 
and next 500 separately.


I'm doing something similar for my maps. I split and compile area like 
Africa in one go and then I run separate tasks to create parts of 
Africa, without recompiling tiles. Mkgmap calculates indexes and preview 
maps basing on provided list of img.


What could be a problem with partial maps is that one country can be 
split into multiple parts. This can prohibit for correct address search, 
if your current position is in one part, but searched address in 
another. But I haven't tested that.


--
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] Polygon fill

[Vuki]

  
  
Hi Gerd,
the OSM comes directly from overpass API, this is small
enough not to split. It also looks good for me. 
  
18.00x46.50 by 18.50x47.00
  
The arifact is somehow connected to the bounding box borders?
Example:
http://www.informatik.hu/balaton2.jpg
  

  


Köszi:
Vuki
On 2020.10.20. 11:32, Gerd Petermann
  wrote:


  Hi Vuki,

flooded lakes are typically caused by incomplete multipolygons. Another reason can be that the OSM data itself is wrong. Do you use splitter with the keep-complete option enabled?

Best way to verify is to load a tile that contains a part of the lake in JOSM (use the pbf or o5m plugin). If JOSM shows a problem than mkgmap cannot be blamed.

Gerd


Von: mkgmap-dev  im Auftrag von Vuki 
Gesendet: Dienstag, 20. Oktober 2020 11:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Polygon fill

Hello Guys,

I am brewing custom maps for my Garmin zumo 396.

- get the OSM data from the overpass api (0.5 by 0.5 degree bounding box)
- use splitter to split too large parts
- use mkgmap to build the maps.

The generated garmin maps have wrong filled polygons, lakes are filled with land and vice versa.
Here are two examples (lake Balatom and lake Geneva)

http://www.informatik.hu/balaton.jpg
http://www.informatik.hu/geneva.jpg

When I download the lake Balaton in one bounding box the artefacts are disappearing, thus there must be something merging the files.
I have tried various mkgmap settings but could not solve the issues. Curret config is:

levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
add-pois-to-areas
add-pois-to-lines
adjust-turn-headings
bounds: ../bounds-latest.zip
check-roundabout-flares
check-roundabouts
copyright-message: Map data © Openstreetmap.org
drive-on=detect,right
generate-sea: land-tag=natural=background
gmapi
gmapsupp
housenumbers
ignore-maxspeeds
index
keep-going
latin1
link-pois-to-ways
location-autofill: is_in,nearest
make-opposite-cycleways
merge-lines
name-tag-list: int_name,name:en,name:hu,name,place_name
#nsis
order-by-decreasing-area
precomp-sea: ../sea-latest.zip
preserve-element-order
process-destination
process-exits
reduce-point-density-polygon=8
reduce-point-density=3
remove-ovm-work-files
remove-short-arcs
road-name-pois
route
# show-profiles: 1
style-file: ../styles
style: default
tdbfile
x-split-name-index
verbose

Do you have any ideas what can cause the issue?


--
Br,
Vuki
___
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] Polygon fill

[Gerd Petermann]

Hi Vuki,

the question is if the multipolygon for the lake is complete. Your screen shot 
shows an imcomplete area.
Check relation 1638031.

Gerd


Von: mkgmap-dev  im Auftrag von Vuki 

Gesendet: Dienstag, 20. Oktober 2020 20:38
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: Re: [mkgmap-dev] Polygon fill

Hi Gerd,

the OSM comes directly from overpass API, this is small enough not to split. It 
also looks good for me.

18.00x46.50 by 18.50x47.00

The arifact is somehow connected to the bounding box borders?

Example:
http://www.informatik.hu/balaton2.jpg



Köszi:
Vuki

On 2020.10.20. 11:32, Gerd Petermann wrote:

Hi Vuki,

flooded lakes are typically caused by incomplete multipolygons. Another reason 
can be that the OSM data itself is wrong. Do you use splitter with the 
keep-complete option enabled?

Best way to verify is to load a tile that contains a part of the lake in JOSM 
(use the pbf or o5m plugin). If JOSM shows a problem than mkgmap cannot be 
blamed.

Gerd


Von: mkgmap-dev 

 im Auftrag von Vuki 
Gesendet: Dienstag, 20. Oktober 2020 11:17
An: mkgmap-dev@lists.mkgmap.org.uk
Betreff: [mkgmap-dev] Polygon fill

Hello Guys,

I am brewing custom maps for my Garmin zumo 396.

- get the OSM data from the overpass api (0.5 by 0.5 degree bounding box)
- use splitter to split too large parts
- use mkgmap to build the maps.

The generated garmin maps have wrong filled polygons, lakes are filled with 
land and vice versa.
Here are two examples (lake Balatom and lake Geneva)

http://www.informatik.hu/balaton.jpg
http://www.informatik.hu/geneva.jpg

When I download the lake Balaton in one bounding box the artefacts are 
disappearing, thus there must be something merging the files.
I have tried various mkgmap settings but could not solve the issues. Curret 
config is:

levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
add-pois-to-areas
add-pois-to-lines
adjust-turn-headings
bounds: ../bounds-latest.zip
check-roundabout-flares
check-roundabouts
copyright-message: Map data © Openstreetmap.org
drive-on=detect,right
generate-sea: land-tag=natural=background
gmapi
gmapsupp
housenumbers
ignore-maxspeeds
index
keep-going
latin1
link-pois-to-ways
location-autofill: is_in,nearest
make-opposite-cycleways
merge-lines
name-tag-list: int_name,name:en,name:hu,name,place_name
#nsis
order-by-decreasing-area
precomp-sea: ../sea-latest.zip
preserve-element-order
process-destination
process-exits
reduce-point-density-polygon=8
reduce-point-density=3
remove-ovm-work-files
remove-short-arcs
road-name-pois
route
# show-profiles: 1
style-file: ../styles
style: default
tdbfile
x-split-name-index
verbose

Do you have any ideas what can cause the issue?


--
Br,
Vuki
___
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] Polygon fill

[Vuki]

  
  
Hi Ticker,
I have regerated with default style and TYP and shows the
same issue.
Basecamp and device also shows the issue.
  
Köszi:
Vuki
On 2020.10.20. 14:56, Ticker Berkin
  wrote:


  Hi Vuki

Various possibilities / questions:

Do you do anything particular with natural=background in your style.
The default is natural=land and the default style doesn't need to
generate anything for it because the device default background isn't
sea.

Do you have a typ file? Does it assign assign a hierarchy of
[_drawOrder] levels to the different types of polygons. 

With --order-by-decreasing-area, it is assumed that you give everything
except the background (0x4a/0x4b) the same value and that the device
renders polygons in the the order they appear in the .img file. It is
possible that your device doesn't do this.

In your examples, I only see parts of lakes not showing as water. As
far as I'm aware, these are not represented with coastline and sea
processing. They should have natural=water tags and generate standard
blue polygons (maybe 0x3c).

It is possible that the resolution these lakes appear at is too high,
but this is unlikely because it is showing the rivers within the lake.

Regards
Ticker

On Tue, 2020-10-20 at 11:17 +0200, Vuki wrote:

  

  Hello Guys,
I am brewing custom maps for my Garmin zumo 396.
- get the OSM data from the overpass api (0.5 by 0.5 degree
bounding box) 
- use splitter to split too large parts
- use mkgmap to build the maps.
The generated garmin maps have wrong filled polygons, lakes are
filled with land and vice versa.
Here are two examples (lake Balatom and lake Geneva)
http://www.informatik.hu/balaton.jpg
http://www.informatik.hu/geneva.jpg
When I download the lake Balaton in one bounding box the artefacts
are disappearing, thus there must be something merging the files.
I have tried various mkgmap settings but could not solve the
issues. Curret config is:
levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
add-pois-to-areas
add-pois-to-lines
adjust-turn-headings
bounds: ../bounds-latest.zip
check-roundabout-flares
check-roundabouts
copyright-message: Map data © Openstreetmap.org
drive-on=detect,right
generate-sea: land-tag=natural=background
gmapi
gmapsupp
housenumbers
ignore-maxspeeds
index
keep-going
latin1
link-pois-to-ways
location-autofill: is_in,nearest
make-opposite-cycleways
merge-lines
name-tag-list: int_name,name:en,name:hu,name,place_name
#nsis
order-by-decreasing-area
precomp-sea: ../sea-latest.zip
preserve-element-order
process-destination
process-exits
reduce-point-density-polygon=8
reduce-point-density=3
remove-ovm-work-files
remove-short-arcs
road-name-pois
route 
# show-profiles: 1
style-file: ../styles
style: default
tdbfile
x-split-name-index
verbose
Do you have any ideas what can cause the issue?

-- 
Br,
Vuki


___
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] Polygon fill

[Vuki]

  
  
Hello Guys,
I am brewing custom maps for my Garmin zumo 396.
- get the OSM data from the overpass api (0.5 by 0.5 degree
  counding box) 
  - use splitter to split too large parts 
  - use mkgmap to build the maps.
The generated garmin maps have wrong filled polygons, lakes are
  filled with land and vice versa.
  Here are two examples (lake Balatom and lake Geneva)
http://www.informatik.hu/balaton.jpg
  http://www.informatik.hu/geneva.jpg
When I download the lake Balaton in one bounding box the
  artefacts are disappearing, thus there must be something merging
  the files.
  I have tried various mkgmap settings but could not solve the
  issues. Curret config is:
levels: 0:24, 1:22, 2:20, 3:18, 4:16, 5:14, 6:12, 7:10
  add-pois-to-areas
  add-pois-to-lines
  adjust-turn-headings
  bounds: ../bounds-latest.zip
  check-roundabout-flares
  check-roundabouts
  copyright-message: Map data © Openstreetmap.org
  drive-on=detect,right
  generate-sea: land-tag=natural=background
  gmapi
  gmapsupp
  housenumbers
  ignore-maxspeeds
  index
  keep-going
  latin1
  link-pois-to-ways
  location-autofill: is_in,nearest
  make-opposite-cycleways
  merge-lines
  name-tag-list: int_name,name:en,name:hu,name,place_name
  #nsis
  order-by-decreasing-area
  precomp-sea: ../sea-latest.zip
  preserve-element-order
  process-destination
  process-exits
  reduce-point-density-polygon=8
  reduce-point-density=3
  remove-ovm-work-files
  remove-short-arcs
  road-name-pois
  route 
  # show-profiles: 1
  style-file: ../styles
  style: default
  tdbfile
  x-split-name-index
  verbose
Do you have any ideas what can cause the issue?



-- 
Br,
Vuki
  

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

Re: [mkgmap-dev] Polygon fill

[Ticker Berkin]

Hi Vuki

Looking at OSM, the latest change for one of your problem areas is:

Relation: Lake Geneva (332617)
Version  #235
Trying to fix the lake (4)
Edited 12 days ago by MFlamm
Changeset  #92217016

So most likely you've picked up an incorrect polygon.

Probably unrelated are my comments about --order-by-decreasing-area and
TYP file [_drawOrder]. Having different [_drawOrder] levels will negate
the effect of the option; it needs them all to be the same. Without a
TYP file most are the same for devices I've encountered - see
distribution file mkgmap-r/examples/typ-files/sameOrder.txt

Ticker

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

Re: [mkgmap-dev] Polygon fill

[Gerd Petermann]

Hi Vuki,

a general comment regarding the use of overpass in batch for mkgmap input:
If you do this only once for a single small tile that's OK. If you do it in a 
loop to produce multiple tiles you risk to download different versions of the 
same object in different tiles. Think of a situation where a mapper uploads a 
move of node of a longer road while your batch program is downloading. You see 
all kinds of weired effects when this happens, from visual distortion to bad 
routing.
So, for a large map with many tiles this is a bad idea. The extracts from e.g. 
http://download.geofabrik.de/ are the better choice for this.

Gerd


Von: mkgmap-dev  im Auftrag von Ticker 
Berkin 
Gesendet: Dienstag, 20. Oktober 2020 23:56
An: Development list for mkgmap
Betreff: Re: [mkgmap-dev] Polygon fill

Hi Vuki

Looking at OSM, the latest change for one of your problem areas is:

Relation: Lake Geneva (332617)
Version  #235
Trying to fix the lake (4)
Edited 12 days ago by MFlamm
Changeset  #92217016

So most likely you've picked up an incorrect polygon.

Probably unrelated are my comments about --order-by-decreasing-area and
TYP file [_drawOrder]. Having different [_drawOrder] levels will negate
the effect of the option; it needs them all to be the same. Without a
TYP file most are the same for devices I've encountered - see
distribution file mkgmap-r/examples/typ-files/sameOrder.txt

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