logo separator

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

From 7770 7770 at foskan.eu on Thu Oct 15 21:01:49 BST 2020

Hi!
Thanks for answers.

--add-pois-to-areas helped to achieve a map to display an icon on some types 
of areas, such as parking lots. Thanks for hints.


About the mapnik TYP file which is included in mkgmap.
in the [_drawOrder] section types seems to be 
prefixed with an extra zero, say 0x03d, but later the same type is given as 
0x3d.
Is there a reason for that, or can i just as well change the numbers and 
remove the extra zero?

In the TYP file, i am considering adding swedish names, which i hope to post 
later when done if you think it is of help.
Swedish has a string code 0x07 (iirc), but may i choose StringN where N is a 
number freely from one not yet taken?



I tried mapping aerialways to railroad, that was the best i could think of. 
They do work in similar way, there is a fixed infrastructure, often with fixed 
entry and exit points, cars can usually not route, but pedestrians may.
On land i guess that typically one cannot cross the rail at any point, but it 
is often possible under the aerialway.
This seems to work and is a possible addition in lines file, just after railway 
(after line 236):
# Add ski lifts and alike
aerialway=* {add name='Aerialway ${name} (${aerialway})' | 'Aerialway ($
{aerialway})' } [0x14 resolution 22]



An off topic question, i noted that on GPSMAP 66st the fuel stations 
(amenity=fuel) never show up earlier than if zooming in to 80 m or closer 
which is rather inconvenient when driving and looking at the map to locate a 
fuel station.
It does not help to set the device to show more or most details, nor to change 
the resolution while compiling the maps. Is there some way to force some types 
to show earlier?
As a note, on a etrex vista hcx the fuel stations show earlier if i changed 
the resolution.


Regards
Karl

On fredag 9 oktober 2020 kl. 15:48:42 CEST Ticker Berkin wrote:
> 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
> 
> _______________________________________________
> 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