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
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
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
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
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:
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:
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
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
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
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
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
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
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:
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
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
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.
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
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
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
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,
20 matches
Mail list logo
