Hi,
unfortunately I didn't have time or ability to test the patch. Seems
like problems are solved when I changed POI types
(https://github.com/pailakka/mtk2garmin/commit/4b3969d726e7b3e36eaa4f0fb8323a744a6c33cf).
Looks like 0x10f__ types are not working on polygons despite both IMG
and
Can you drop some sample input that shows this behaviour along with
your command-line/options and style somewhere, and I'll try and work
out what is happening.
Ticker
On Thu, 2016-11-17 at 15:04 +0100, rheinskipper1...@gmx.de wrote:
> After some more testing I can confirm that even three
After some more testing I can confirm that even three different draw levels
also work as expected. This example shows fairway on top of intertidal zone
which is on top of sea polygon:
https://drive.google.com/file/d/0Bz9KchYfWW3reHRrSGR6c0Jmc0U/view?usp=sharing
But I got some errors regarding
Should have read your mail better :(
I think the test should be implemented in mkgmap while reading the input
data tiles.
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
As you know, I'm using overlapping tiles, but in different gmapsupps.
Never had any problems. Is splitter still able to split overlapping tiles?
Henning
___
mkgmap-dev mailing list
mkgmap-dev@lists.mkgmap.org.uk
Hi Ticker,
Ticker Berkin wrote
> The messing with the area happens after style processing so doesn't
> effect the result of the area_size() function.
you are right, sorry for the noise.
Gerd
--
View this message in context:
Hi Gerd
The messing with the area happens after style processing so doesn't
effect the result of the area_size() function.
Ticker
On Wed, 2016-11-16 at 23:00 -0700, Gerd Petermann wrote:
> Hi all,
>
> Ticker Berkin wrote
> > It is used in conjunction with --order-by-decreasing-area and
> >
