[mkgmap-dev] New branch for default typ file

Mon Nov 5 15:30:04 GMT 2018

Hi all

Some comments on this and other requests/ideas relating to TYP file.

Beware of moving the test for building=* up in the file - there might
be other, more significant, tags that won't be triggered

My Garmin device doesn't show polygons with type > 0x5f, lines > 0x3d, points > 0x72. I haven't tested the behaviour with a TYP file

I feel that the default style and associated TYP file should not use
extended types, and stick as far as possible to well known Garmin
meanings for type. A couple of extended types have crept into the
default style recently.

However, some of the Garmin types are overloaded with slightly
different OSM meanings and could be spread out over unused types. eg
polygon 0x17 is used for common, garden, park, playground,
square/plaza, greenfield, meadow, grass, village_green but there are
unused types that look similar (0x14-16, 0x1e-20)

Having change some of these mappings for my system, I'd like to be able
to name them correctly in the TYP file but not change any other aspect
of their representation from the device default. mkgmap (and possibly
the TYP format) doesn't allow just:
;
[_polygon]
Type=0x1b
String=Farm
[end]
;
Does anyone know if it would be possible to change mkgmap to allow
this? It is possible to change the representation but not supply the
string and the device shows it's inbuilt title.

Concerning language/translation, there should always be a default
language translation (American-english?), followed by common language
differences, eg
;
[_polygon]
Type=0x25
String=Square
String1=0x01,Place
String1=0x02,German
for this
String1=0x05,Piazza
String1=0x08,Plaza
Xpm=...
...

Another TYP usage is to have transparent polygons showing counties,
small island name etc, such that hovering over them gives useful
information. Again, the TYP compiler won't allow a transparent block
colour, but would be nice to be able to say:
;
[_polygon]
Type=0x58
String=County
Xpm="0 0 1 0"
    "a c none"
[end]
;
It is possible to get round this by having a bit-map with 2 colours and
not using the non-transparent one. Another way of getting a similar
effect is to reduce the [_drawOrder] for this type, but this is
incorrect with transparent maps.

On the subject of _drawOrder, I use --order-by-decreasing-area and have
all polygons from 0x01 to 0x5f to set to the same level except 0x4b
(map background). I have attached a simple patch that stops this being
a special case by causing the background to be written before the Sea.
@gerd - can you apply - thanks.

I haven't been through all of Joris's document in detail and will
probably have more comments

I also have lots of minor changes to the default style that shouldn't
be controversial and will post this later

Regards
Ticker

On Tue, 2018-10-30 at 10:00 +0000, Gerd Petermann wrote:
> Hi all, 
> 
> I've created a new branch now with changes proposed by Joris. I hope
> this helps bringing this forward.
> Attached is a document from Joris. 
> 
> Gerd
> _______________________________________________
> 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: backgroundArea.patch
Type: text/x-patch
Size: 596 bytes
Desc: not available
URL: <http://www.mkgmap.org.uk/pipermail/mkgmap-dev/attachments/20181105/c527dc1a/attachment.bin>