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@jagit.co.uk] Sent: 15 February 2021 09:16 To: Development list for mkgmap <mkgmap-dev@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@lists.mkgmap.org.uk> im Auftrag von jan meisters <jan_m23@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@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@lists.mkgmap.org.uk> im Auftrag von Ticker Berkin <rwb-mkgmap@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@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev