Hi Gerd
Yes, you can do that with a draw level 1 higher than sea.
Draw orders are defined at the beginning of a (txt) typ file just before
the polygons
using the following format
Type=0x type number , draworder
It is good practice to sort the draworders , as that is how they appear
in a typ file
[_drawOrder]
Type=0x03,1
Type=0x28,1
Type=0x54,1
Type=0x01,2
Type=0x09,2
Type=0x4E,2
Type=0x10F1C,2
etc etc
[end]
I have no idea what the draworder for sea is , but just make it one higher
On 09/12/2019 16:41, Gerd Petermann wrote:
Hi Nick,
I don't want to cut out islands from bay polygons, I thought about a proper typ for 0x3d
which somehow marks "calmer water"
and a draw order that puts this above water and below any land type polygon.
Is that possible?
Gerd
________________________________________
Von: Pinns UK <[email protected]>
Gesendet: Montag, 9. Dezember 2019 16:17
An: Gerd Petermann; [email protected]
Betreff: Re: AW: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
Yes, I suppose so
On 09/12/2019 15:14, Gerd Petermann wrote:
Hi Nick,
my understanding is that you always have another water polygon, either ocean or
natural=water.
Gerd
________________________________________
Von: Pinns UK <[email protected]>
Gesendet: Montag, 9. Dezember 2019 16:04
An: Gerd Petermann; [email protected]
Betreff: Re: AW: [mkgmap-dev] New branch for default typ file
Hi Gerd
In case of 2) you need 2 polygons for doing each job; one showing
'water' and the other one not
Ideally, mkgmap checks if islands are in a 'bay' area
In my area we have lots of natural=bays ; fortunately they do not
include islands
On 09/12/2019 14:51, Gerd Petermann wrote:
Hi,
thanks for the help.
I see two ways to handle the a polygon with natural=bay:
1) in ponts style with natural=bay & name=* [....]
2) in polygons (as it is now) with natural=bay [0x3d resolution 18]
In case of 1) we just need option add-pois-to-areas
In case of 2) we would want to render the water area covered by the bay polygon
different, but not anything on the land or on islands. Would that be possible?
Gerd
________________________________________
Von: mkgmap-dev <[email protected]> im Auftrag von Pinns UK
<[email protected]>
Gesendet: Montag, 9. Dezember 2019 15:42
An: [email protected]
Betreff: Re: [mkgmap-dev] New branch for default typ file
Andrzej is correct about how transparency is defined
Garmin regards all polygons with transparency as bitmaps and therefore
require 2 colours.
The Bitmap need to be shown below the xpm
If a polygon is completely transparent then a second 'dummy' colour is
still needed
Xpm="32 32 2 1"
"0 c none"
"1 c #C8C8C8"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
"00000000000000000000000000000000"
;12345678901234567890123456789012
[end]
On 09/12/2019 14:19, Andrzej Popowski wrote:
Hi Gerd,
I use TypViewer for creating typ files and I don't know XPM details.
But looking at TypViewer output, I guess that transparent pixels are
defined with color like that:
" c none"
where space ' ' is used for marking pixels.
Changing draw order instead of transparent graphics could be a
solution too, but I'm not sure if covered polygon label would remain
visible. And without label, there is not much use of this object.
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________
mkgmap-dev mailing list
[email protected]
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
