[mkgmap-dev] New branch for default typ file

Sat Dec 14 17:20:01 GMT 2019

Dear Sirs:

Control pages are Microsoft WIndows-centric. Please, use Unicode (UTF-8) 
as that works in iOS and Unix.

Randolph J. Herber

On 12/14/2019 9:53 AM, Pinns UK wrote:
> Hi Gerd
>
> The reason for suggesting unicode is that it caters for all languages, 
> not just  those specified by 1252 or 1250 or 1251
>
> However,   anyone not used to or bothered about codepages, will 
> benefit from a mapnik.txt where the characters are 1252 compliant.
>
>  I now have all my maps using cp 65001 as  Basecamp/ (mapsource?) 
> automatically selects the appropriate  language depending on the 
> user's Region settings.
>
> Nick
>
>
>
>
> On 14/12/2019 15:11, Gerd Petermann wrote:
>> Hi all,
>>
>> when the source for the typ file specifies a codePage which is 
>> different from the one used on the command line we see a warning
>> WARNING: SortCode in TYP txt file different from command line setting
>>
>> As an unexperienced user I would try to get rid of such a warning, 
>> maybe causing more trouble than needed.
>> A comment in the source says "This is just a warning, not a definite 
>> problem"
>>
>> In (1) Nick suggested to use unicode in the typ file, so I wonder in 
>> what situation this warning is needed?
>>
>> Gerd
>> (1) 
>> http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932168.html
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag 
>> von Gerd Petermann <gpetermann_muenchen at hotmail.com>
>> Gesendet: Samstag, 14. Dezember 2019 15:21
>> An: Ticker Berkin; Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] New branch for default typ file
>>
>> Hi Ticker & Joris
>>
>> I'd also prefer to maintain it as txt file, else I'd prefer to remove 
>> the file and add a simple hint were to find Joris files.
>>
>> @Ticker:
>> The problem mentioned here is still there.
>> http://gis.19327.n8.nabble.com/Update-of-typ-with-correct-codepage-and-special-chars-tp5932059p5932172.html 
>>
>> I'll try to code a fix now.
>>
>> Gerd
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag 
>> von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
>> Gesendet: Samstag, 14. Dezember 2019 10:41
>> An: Development list for mkgmap
>> Betreff: Re: [mkgmap-dev] New branch for default typ file
>>
>> Hi Joris & Gerd
>>
>> Great to see the typ-files now in trunk and all the work in updating
>> mapnik.txt to the current default style. Next week I plan to go through
>> "20191209 mapnik update.pdf" and comment on it and possible changes to
>> the default style.
>>
>> Some other questions however:
>>
>> How do you see mapnik.txt now being maintained; will it be as as simple
>> .txt file with patches being supplied in the same way as other source
>> files, or will it be regenerated from your translation spreadsheet and
>> other sources? I'd prefer the simple text file approach, but this might
>> allow changes into the file which make it incompatible with the tools
>> Joris uses to enhance it.
>>
>> It is currently in UTF8 format, with an appropriate BOM at the start of
>> the file. I don't know how the java input libraries determine the
>> conversion rules to internal unicode, but this file should be
>> consistent with all the others that contain characters outside the
>> simple ansi 7-bit range (roadNameConfig.txt, default/inc/address)
>>
>> It contains the statement:
>>> CodePage=65001
>> This is saying the output should be unicode, but the output should be
>> the same as the associated map.
>>
>> Also the FID should be removed.
>>
>> Regards
>> Ticker
>>
>> On Tue, 2019-12-10 at 09:59 +0000, Gerd Petermann wrote:
>>> Hi Joris,
>>>
>>> the file mapnik.txt says "Based on mkgmap default style version:
>>> r4262"
>>> Is it the right file?
>>>
>>> reg. line type 0x0b: highway=motorway_link & (mkgmap:exit_hint=true |
>>> mkgmap:dest_hint=*)
>>> I want to look at the DestinationHook. If I got that right it should
>>> be OK to have a zero-length road with that type to get the wanted
>>> destination hint. In that case we don't have to care about rendering.
>>>
>>> Gerd
>>>
>>> ________________________________________
>>> Von: Joris Bo <jorisbo at hotmail.com>
>>> Gesendet: Montag, 9. Dezember 2019 20:45
>>> An: Development list for mkgmap; Gerd Petermann
>>> Betreff: RE: [mkgmap-dev] New branch for default typ file
>>>
>>> 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
>>> _______________________________________________
>>> 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
>> _______________________________________________
>> 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
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev