logo separator

[mkgmap-dev] Disconnected map sections, types in TYP-files.

From Ticker Berkin rwb-mkgmap at jagit.co.uk on Fri Oct 9 14:48:42 BST 2020

Hi

Some TYP file answers embedded.

Regards
Ticker

On Fri, 2020-10-09 at 11:37 +0200, 7700 wrote:
> Hi.
> Still on my learning path, and thanks for good documents, which have
> helped a 
> lot.
> 

> 2.
> When working with TYP files, i have read:
> If a polygon type is not listed in this section, then it will not be
> displayed 
> at all.
> 
> Is this valid?
> If it is, then it means i really have to add every single item which
> may be 
> generated and which is on the map, otherwise i risk loosing
> information 
> without even knowing, say if i want to change very small portions
> from how the 
> device displays something.

If you have a TYP file, I think it is correct that any polygons not in
the [_draworder] section won't show. If you don't have a [_polygon]
entry, you'll get the default representation for your device.

Information on the default [_draworder] assumed by some devices is
documented here and there on the web and there are comments about it in
mkgmap-rXXXX/examples/typ-files/sameOrder.txt
 
> I have found that there some information sets that cover a lot of
> types that 
> garmin devices can show, but is it possible to extract a list from
> mkgmap, for 
> example extracting the default set?

There have been postings in this group about all the types generated
from the default style. You have to examine
examples/styles/default/{points,lines,polygons} for the current,
definitive, list

> Is the example mapnik.txt file complete or just an example?

I think it has an entry for everything in the current default style.

> 
> If i didn't make errors, it seems there is a difference between
> generating 
> gmapsupp with no TYP and this example TYP.

Yes - a big difference. mapnik.txt is attempting to reproduce a
particular look. I find that it doesn't look good on small devices and
I much prefer a very basic TYP file that doesn't change anything where
most devices give a reasonable representation by default. 
 
> 
> 3.
> From which type number can i define my own type to avoid collission
> with 
> existing types?

For lines, you need to beware of routable/non-routable and there are
not many free entries in the non-extended section.

> I am thinking of adding handling for aerialways.
> 

Look at the thread "default style lines enhancements" from july:
http://gis.19327.n8.nabble.com/default-style-lines-enhancements-td59712
80.html
It has something on this.

> 
> 4.
> Related to the polygon amenity=parking and displaying of a picture.
> on maps such as from garmin.openstreetmap.nl, the polygon for
> amenity=parking 
> displays the same parking symbol (garmin default, round with red P
> and black 
> border) as for a point amenity=parking.
> I tried generating the individual tiles with the style present from
> mkgmap 
> using --style-file=path/styles/, in which i see a mapping in the
> polygons file:
> amenity=parking | parking=surface [0x05 resolution 22]
> 

I think you are just seeking the [_point] parking icon 0x2f0b.
Depending on the OSM tagging, there might be a polygon with type 0x05
or 0x06.
 
> But even with this, the parking polygons do not show any
> picture/symbol.
> What else is needed?

to define a polygon icon or solid colour that will be repeated over the
parking area. mapnik.txt just defines a solid colour

> 
> Kind regards
> Karl
> 
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev


More information about the mkgmap-dev mailing list