[mkgmap-dev] New branch for default typ file

Mon Dec 9 16:41:30 GMT 2019

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 <osm at pinns.co.uk>
Gesendet: Montag, 9. Dezember 2019 16:17
An: Gerd Petermann; mkgmap-dev at lists.mkgmap.org.uk
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 <osm at pinns.co.uk>
> Gesendet: Montag, 9. Dezember 2019 16:04
> An: Gerd Petermann; mkgmap-dev at lists.mkgmap.org.uk
> 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 <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Pinns UK <osm at pinns.co.uk>
>> Gesendet: Montag, 9. Dezember 2019 15:42
>> An: mkgmap-dev at lists.mkgmap.org.uk
>> 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
>> mkgmap-dev at lists.mkgmap.org.uk
>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev