[mkgmap-dev] Pending changes

Mon Feb 15 12:51:05 GMT 2021

HI Ticker,

If you name the typ in the typ file, there should be no need for a default name in the style, and as the typ file already allows multiple languages this should mostly negate the need for a 'translate' function. Of course, this assumes that you don't use a generic typ code for several different objects. Or am I missing something?

Regards,
Mike

-----Original Message-----
From: Ticker Berkin [mailto:rwb-mkgmap at jagit.co.uk] 
Sent: 15 February 2021 09:16
To: Development list for mkgmap <mkgmap-dev at lists.mkgmap.org.uk>
Subject: Re: [mkgmap-dev] Pending changes

Hi Gerd

This has always been a problem with styles, encouraged by
    [... default_name ...], eg:

amenity=embassy & country!=*
    [0x3003 resolution 24 default_name 'Embassy']
amenity=emergency_phone
    [0x2f12 resolution 24 default_name 'Emergency Phone']

I've added to this in an attempt to provide more useful information for
unnamed entities by using constructs like:

tourism=* & name!=* & tourism!=yes & tourism!=no
    {set name='${tourism|subst:"_=> "}'}
amenity=restaurant {add name='${cuisine|subst:"_=> "}'}

What is needed is another "substitution filter" - translate, that takes
an optional parameter "context"; context is normally the name of the
tag. The above would read:

amenity=embassy & country!=*
    {add name='${amenity|translate:amenity}'}
    [0x3003 resolution 24]
amenity=emergency_phone
    {add name='${amenity|translate:amenity}'}

[0x2f12 resolution 24 default_name 'Emergency Phone']

tourism=* & name!=* & tourism!=yes & tourism!=no
    {set name='${tourism|translate:tourism}'}
amenity=restaurant {add name='${cuisine|translate:cuisine}'}

Options would be added to mkmap:
1/ to specify a required language; given as a list, in the same manner as browsers, eg --language=en:gb,en

2/ a set of translation files (zip, list, directory or something),
These could be simple lists of {language,context,tag,translation} where an empty value takes the previous value, so could have:

en,amenity,parking,Parking
  ,       ,bench,Bench
  ,       ,place_of_worship,Church
  ,       ,restaurant,Restaurant

or, ordered in a different way:

en,barrier,fence,Fence
fr,       ,     ,french for fence barrier
de,       ,     ,german ...
en,       ,gate,Gate
fr,       ,    ,french for gate

There would be a special "common" context that is used if the search for language/context/word fails, or if |translate isn't given a context parameter. As a final resort, the untranslated string is initcap'd and underscores are replaced by spaces.

With a bit of trickery anything can be translated:

    {set whatever='${_|def:strToTranslate|translate}'; ...}

Ticker 

On Fri, 2021-02-12 at 10:19 +0000, Gerd Petermann wrote:
> Hi,
> 
> reg. barrier names:
> I don't want those texts in the map at all. I might want to see them
> when I select the icon to look at the details. I expect strings in
> the map to be names of objects (streets, cities), not barrier
> properties. Esp. not in a foreign language. My opinion: If you can't
> find a good way to render them better don't render them at all.
> 
> Gerd
> 
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag
> von jan meisters <jan_m23 at gmx.net>
> Gesendet: Freitag, 12. Februar 2021 10:52
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Pending changes
> 
> Hi Ticker,
> 
> in fact 3200 - 3f1f strictly follow their given resolution value -
> other than e.g. 2a-2f, which only appear at kind of 24+, no matter
> what resolution is given.
> Even if both ranges are styled to resolution 24: 2a-2f will always
> appear a bit later.
> I suspect that´s what Gerd found to be confusing.
> 
> Jan
> 
> 
> > Am 12.02.2021 um 09:46 schrieb Ticker Berkin <
> > rwb-mkgmap at jagit.co.uk>:
> > 
> > Hi Gerd
> > 
> > The "points" barriers use 0x3200 and I only see these when I
> > "overzoom". I think I configured the device Map Detail levels and
> > Text
> > sizes to get it how I wanted.
> > 
> > I find them useful when walking and sometimes useful for choosing
> > an
> > end-point for car navigation or seeing why a route hasn't been
> > chosen.
> > 
> > "lines" barriers (wall/ditch/etc) again I find useful when walking.
> > 
> > Either of these can commented out by users making their own style
> > starting from default. When I started, the first thing I had to
> > remove
> > were all the low-level administrative boundaries, but I think it
> > right
> > that they are in the default style.
> > 
> > I'd rather not start on other changes until this lot is out of the
> > way.
> > 
> > Ticker
> > 
> > On Thu, 2021-02-11 at 15:27 +0000, Gerd Petermann wrote:
> > > Hi Ticker,
> > > 
> > > while you are at it: I see lots of rather confusing texts like
> > > "gate"
> > > or "lift_gate" popping up in the map on my Oregon. I think they
> > > might
> > > be useful for mappers but they are not very useful for the normal
> > > user. Maybe it is only on my device but I don't see any need for
> > > this.
> > > 
> > > Gerd
> > > 
> > > ________________________________________
> > > Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im
> > > Auftrag
> > > von Ticker Berkin <rwb-mkgmap at jagit.co.uk>
> > > Gesendet: Donnerstag, 11. Februar 2021 15:57
> > > An: Development list for mkgmap
> > > Betreff: Re: [mkgmap-dev] Pending changes
> > > 
> > > Hi all
> > > 
> > > I've re-made this set of changes, along with a few improvements
> > > that
> > > I've gathered over the last 6 months. Following list numbering is
> > > the
> > > same as original patch, but include some [extra] notes + new
> > > items at
> > > the end.
> > > 
> > > Relevant threads:
> > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.html
> > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.html
> > > 
> > > 1/ Sometimes charges for using a pedestrian highway are expressed
> > > as
> > > a
> > > fee rather than a toll, so pick this up in mkgmap:toll.
> > > 
> > > 2/ Show bridges using type 0x10107. With the mapnik addition,
> > > these
> > > look good for narrow highways, but might not show for wide
> > > representations like motorways.
> > > 
> > > 3/ Where it is likely that bits of highway might not be connected
> > > to
> > > the road/path system, use mkgmap:set_unconnected_type and
> > > mkgmap:set_semi_connected_type to stop the NET/NOD rather than
> > > relying
> > > on NETnoNOD (now disabled) and --check-routing-island-len=+ve,
> > > which
> > > is
> > > being suspected of causing problems on some devices and BaseCamp.
> > > 
> > > [extra] In all cases where unconnected/semi-connected changes are
> > > mentioned, this only applies to lines not derived from an
> > > original/OSM
> > > standard highway.
> > > 
> > > 4/ Quote some filter subst strings that contain spaces - no
> > > actual
> > > effect but clearer and safer.
> > > 
> > > 5/ Have line for leisure=track even if area.
> > > 
> > > 6/ Change the type for tracks/raceways etc from 0x30, which
> > > doesn't
> > > show on BaseCamp or MapSource, to 0x2a.
> > > 
> > > 7/ For piers, if 'unconnecting', use marine type 0x1040c
> > > (Obstruction:
> > > Pier or Jetty) instead of footway.
> > > 
> > > 8/ Change type for the various barriers from 0x17, which doesn't
> > > show
> > > on BaseCamp to 0x2b, see:
> > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q1/030348.html
> > > 
> > > 9/ Consider natural=cliff a barrier.
> > > 
> > > 10/ Add motorway[_link] roundabouts (yes, some do exist).
> > > 
> > > 11/ Unquote some numbers - no actual effect.
> > > 
> > > 12/ Tweak some road speeds.
> > > [extra] A few more tweaked.
> > > 
> > > 13/ Use 0x09 (high-speed ramp) for road class 4 links
> > > 
> > > 14/ Add footway around car parks if 'connecting'.
> > > [extra] This change is disabled.
> > > 
> > > 15/ Disable coastline. For a long time the tag was suppressed by
> > > the
> > > Sea processing and it adds little to the map.
> > > 
> > > 16/ Improve railway platform names and suppress footway if not
> > > 'connecting'.
> > > 
> > > 17/ Show disused:railway in the same way as railway=disused.
> > > 
> > > 18/ Have cable_car, gondola, funicular as routable, by default
> > > with a
> > > toll and pedestrian only.
> > > 
> > > 19/ Show "Course of old Railway", unless a highway has taken over
> > > the
> > > way (for you Eric, but I like it as well).
> > > [extra] This change is disabled
> > > 
> > > 20/ Speed up car ferries.
> > > 
> > > 21/ A few other layout/space fixes.
> > > 
> > > Additional changes:
> > > 
> > > 22/ motorroad=yes just sets mkgmap:fast_road, which generally
> > > increases
> > > the speed/class of the highway and decreases the resolution
> > > 
> > > 23/ natural=landslide like other barriers (eg cliff)
> > > 
> > > 24/ Don't generate (routable) line for highway=unclassified &
> > > area=yes;
> > > there are many instances in OSM where this is used to draw a
> > > polygon
> > > around a complex junction.
> > > 
> > > 25/ Change the bridleway from 0x07 (Alley) to 0x16 (Trail)
> > > 
> > > 26/ For ferry/platform/aerialway, blank out address fields to
> > > prevent
> > > it getting into the Address index
> > > 
> > > 27/ Add comment about colour pallet to mapnik.txt
> > > 
> > > Patch attached
> > > 
> > > Ticker
> > > 
> > > On Tue, 2021-02-09 at 11:30 +0100, Carlos Dávila wrote:
> > > > On [1] Ticker proposed a set of changes to default style lines
> > > > file.
> > > > There was a long discussion about point #14, which ended
> > > > without a
> > > > consensus. Other changes didn't get any objection, but they
> > > > didn't
> > > > get
> > > > into trunk. I agree with numbers 1, 6, 8, 10, 15, 17, 18. Also
> > > > with
> > > > 7
> > > > and 16, but for unconnected ways only, see #3.
> > > > 
> > > > 2: more codes could be added for wider highways and their
> > > > corresponding
> > > > entries in mapnik.txt
> > > > 
> > > > 3: not sure about this one, specially about semi-connected
> > > > ways,
> > > > which I
> > > > think should remain as routable (also applies for 7, 16).
> > > > 
> > > > [1]
> > > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031375.htm
> > > > l
> > > > 
> > > > _______________________________________________
> > > > 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