[mkgmap-dev] Pending changes

Mon Feb 15 18:02:40 GMT 2021

Hi Mike

There are various problems trying to do it as you suggest:

If the point is to be indexed, the likelihood is that it hasn't matched
a specific instance of the category and so must use the generic 0x00
subtype.

The list of values could be long; having to have a rule for each, along
with the allocation of a distinct typCode, would be a mess.

It wouldn't be able to cope with new, unknown values. I realise that
these won't have translations, but just formatting the string is a good
start, until a translation can be added.

Having to add lots of identical TYP icons just to get translations
would also be a mess.

I hate having to find/generate icons and maintain them in the TYP
file when there are perfectly good ones built into the device simply to
get a better description. I haven't found a way of keeping the device
icon but changing the string.

Ticker

On Mon, 2021-02-15 at 12:51 +0000, Mike Baggaley wrote:
> 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.htm
> > > > l
> > > > http://www.mkgmap.org.uk/pipermail/mkgmap-dev/2020q3/031424.htm
> > > > l
> > > > 
> > > > 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.htm
> > > > l
> > > > 
> > > > 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.h
> > > > > tm
> > > > > 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
> 
> 
> _______________________________________________
> mkgmap-dev mailing list
> mkgmap-dev at lists.mkgmap.org.uk
> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev