logo separator

[mkgmap-dev] Is height: filter working as described?

From Carlos Dávila cdavilam at orangecorreo.es on Sat Feb 4 12:55:38 GMT 2017

There's no way. With your rule Garmin doesn't recognize ele_in_m value 
as an elevation and so units are not displayed. I could hard code an m 
of ft unit to be shown, but then user could not change it in settings. I 
was already using a rule with the same problem:
ele ~ '.*feet' { set ele='${ele|conv:feet=>m}'}
ele ~ '.*ft' { set ele='${ele|conv:ft=>m}'}
natural=peak {name '${name} (${ele|subst:"m=>"}m)' | '${name}' | 
'${ele|subst:"m=>"}m' } [0x6616 resolution 24]
Anyway, I can live with "name, ele unit" ;-)

El 04/02/17 a las 13:03, Gerd Petermann escribió:
> Hi Carlos,
>
> to answer your question: my understanding is that you should  not use the height filter.
> I did not try but I think something like conv:m=>ft|conv:ft=>m should extract the raw
> value in m, so maybe something like this:
> ele=* {set ele_in_m='(${ele|conv:m=>ft|conv:ft=>m})'
> natural=peak {name '${name|def:}${ele_in_m}' } [0x6616 resolution 24]
>
> Gerd
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen at hotmail.com>
> Gesendet: Samstag, 4. Februar 2017 11:51:32
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Is height: filter working as described?
>
> Hi Carlos,
>
> it seems that the Garmin software is interpreting a value with the prefix "\u001f"
> to format it as something lije ", " + convertFeetToWantedUnit(value).
>
> BTW: I found some routines im mkgmap which treat these prefixes special, e.g.
> Label.stripGarminCodes(String s), but those are called for lines, not for POI, .
> Maybe that is an error?
>
> Gerd
>
> ________________________________________
> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam at orangecorreo.es>
> Gesendet: Samstag, 4. Februar 2017 10:17:23
> An: Development list for mkgmap
> Betreff: Re: [mkgmap-dev] Is height: filter working as described?
>
> Current rule for peaks using height: filter results in peaks named in
> the form "name, ele m" (of ft according to your settings). I would like
> show peaks formated as "name (ele m)". I've been playing with line "s =
> "\u001f" + s;" in HeightFilter.java adding parenthesis in different
> ways, but nothing worked as desired. Is there a way to get what I want?
>
> El 03/02/17 a las 12:16, Gerd Petermann escribió:
>> Hi Colin,
>>
>> my understanding is that the heigth filter is used to allow the Garmin software to interpret the value
>> and format it as wanted by the user.
>>
>> Gerd
>>
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk> im Auftrag von Colin Smale <colin.smale at xs4all.nl>
>> Gesendet: Freitag, 3. Februar 2017 11:48:26
>> An: mkgmap-dev at lists.mkgmap.org.uk
>> Betreff: Re: [mkgmap-dev] Is height: filter working as described?
>>
>> I am not sure how far mkgmap should exceed its original scope and become a QA tool... But maybe an option to configure the output format of the height and conv functions (w.r.t. decimal separator, thousands separator, number of digits etc) might be useful? Perhaps the program could take (some of) the settings from the user's current locale.
>>
>>
>>
>> --colin
>>
>> On 2017-02-03 11:37, Gerd Petermann wrote:
>>
>> Hi all,
>>
>> it is quite easy to implement the support for comma as optional decimal separator, but
>> much more difficult to produce a reasonable warning. The problem is that the routine
>> which detects the error may be called several times when style rules are evaluated.
>> Attached is a patch which creates a warning for each evaluation.
>> With the default style the messages look like this:
>> WARN: uk.me.parabola.mkgmap.osmstyle.actions.ConvertFilter  f:\osm\peaks.osm: invalid decimal separator found in value '13,3' http://www.openstreetmap.org/node/-31655
>> WARN: uk.me.parabola.mkgmap.osmstyle.actions.ConvertFilter  f:\osm\peaks.osm: invalid decimal separator found in value '13,3' http://www.openstreetmap.org/node/-31655
>> WARN: uk.me.parabola.mkgmap.osmstyle.actions.ConvertFilter  f:\osm\peaks.osm: invalid decimal separator found in value '13,3m' http://www.openstreetmap.org/node/-31660
>> WARN: uk.me.parabola.mkgmap.osmstyle.actions.ConvertFilter  f:\osm\peaks.osm: invalid decimal separator found in value '13,3m' http://www.openstreetmap.org/node/-31660
>>
>> The corresponding OSM file is attached, a binary with the patch is here:
>>    http://files.mkgmap.org.uk/download/332/mkgmap.jar
>>
>> @Steve: Please check the change in the regex pattern, I think the dot in the existing pattern should be quoted ?
>>
>> Gerd
>>
>>
>> ________________________________________
>> Von: mkgmap-dev <mkgmap-dev-bounces at lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces at lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <popej at poczta.onet.pl<mailto:popej at poczta.onet.pl>>
>> Gesendet: Donnerstag, 2. Februar 2017 16:38:37
>> An: mkgmap-dev at lists.mkgmap.org.uk<mailto:mkgmap-dev at lists.mkgmap.org.uk>
>> Betreff: Re: [mkgmap-dev] Is height: filter working as described?
>>
>> Hi Carlos,
>>
>> maybe mkgmap could issue a warning for filter whenever input data are
>> not compatible? Comma is a standard decimal separator in Poland and
>> there is a lot of erroneous tags. I haven't noticed this problem until now.
>>
>> When numeric value contains a comma, filter "height" doesn't convert tag
>> value but adds a a separator. The result is that Mapsource doesn't
>> display label at all.
>>
>> --
>> Best regards
>>
>>
>



More information about the mkgmap-dev mailing list