[mkgmap-dev] New branch for default typ file

Mon Dec 9 19:45:19 GMT 2019

Hi All,

I don't think any changes needed in mkgmap itself. When the draworder of bay is lower then water it will display correctly.
See attached new typ-file for correct usage.
Even better (but this is a change in default style): don't use natural = bay in polygons but only in points for displaying as name.

Today I spent some time testing and repairing.

The mapnik.txt in branch mkgmap-default-typ-r4268 was pretty old and also did not have the translations of all the languages anymore. It also lost draworder of a lot of polygons which made the bay-problem occur.

I did a complete recheck of the most recent default-style in: mkgmap-r4386.zip and changed de typ-file accordingly.

I downloaded a full europe-latest from geofabrik today, builded it as a big full europa map with the default style of r4386  and with mkgmap r4386.jar No errors occured.

I think it’s up to date again but some review and comments are always welcome.

See typ-file in attachement,

Kind regards,
Joris

-----Oorspronkelijk bericht-----
Van: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> Namens Pinns UK
Verzonden: maandag 9 december 2019 18:31
Aan: Gerd Petermann <gpetermann_muenchen at hotmail.com>; mkgmap-dev at lists.mkgmap.org.uk
Onderwerp: Re: [mkgmap-dev] New branch for default typ file

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 <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
_______________________________________________
mkgmap-dev mailing list
mkgmap-dev at lists.mkgmap.org.uk
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 20191209 mapnik update.pdf
Type: application/pdf
Size: 135888 bytes
Desc: 20191209 mapnik update.pdf
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191209/c0e70551/attachment-0001.pdf>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mapnik.typ
Type: application/octet-stream
Size: 30559 bytes
Desc: mapnik.typ
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191209/c0e70551/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: mapnik.txt
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20191209/c0e70551/attachment-0001.txt>