Is height: filter working as described?
According to style manual the rule natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24] from default style should convert ele values from meters to feet, assuming ele is in meters, but this is what map shows for the following ele values: ele=500, map: ", 500 m" ele=500m, map: ", 500 m" ele=500ft, map: ", 152 m" So it seems to be doing right the opposite, converting from feet to meters. Also, with m=>ft rule, map should show ft units, not m. If I invert the rule from m=>ft to ft=>m this is what happens: ele=500, map: ", 46 m" ele=500m, map: ", 152 m" ele=500ft, map: ", 46 m" Now it seems when values are in feet conversion factor is applied twice. It seems when height: is used it always does a ft to m conversion first and then it applies what is specified in the rule. For the same examples, conv: filter gives the right values.
Hi Carlos, this seems to be a problem in the documentation. I found this description for the height filter: "This is exactly the same as the conv filter, except that it prepends a special separation character before the value which is intended for elevations." ${ele|height:"m=>ft"} This can be easily confused with the example for the conv filter: ${height|conv:"m=>ft"} Looking at the source code the description for height seems okay. In your examples the rule doesn't place the argument in "", maybe that is the problem? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Donnerstag, 2. Februar 2017 10:45:02 An: Development list for mkgmap Betreff: [mkgmap-dev] Is height: filter working as described? According to style manual the rule natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24] from default style should convert ele values from meters to feet, assuming ele is in meters, but this is what map shows for the following ele values: ele=500, map: ", 500 m" ele=500m, map: ", 500 m" ele=500ft, map: ", 152 m" So it seems to be doing right the opposite, converting from feet to meters. Also, with m=>ft rule, map should show ft units, not m. If I invert the rule from m=>ft to ft=>m this is what happens: ele=500, map: ", 46 m" ele=500m, map: ", 152 m" ele=500ft, map: ", 46 m" Now it seems when values are in feet conversion factor is applied twice. It seems when height: is used it always does a ft to m conversion first and then it applies what is specified in the rule. For the same examples, conv: filter gives the right values. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Carlos, I forgot to mention that the special separation character added by the height filter might tell Garmin softtware to convert the value (again). IIRC there is a flag in the img file which tells Garmin if values are in feet or metres, so you are probably right that the filter doesn't work as expected. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 2. Februar 2017 11:18:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is height: filter working as described? Hi Carlos, this seems to be a problem in the documentation. I found this description for the height filter: "This is exactly the same as the conv filter, except that it prepends a special separation character before the value which is intended for elevations." ${ele|height:"m=>ft"} This can be easily confused with the example for the conv filter: ${height|conv:"m=>ft"} Looking at the source code the description for height seems okay. In your examples the rule doesn't place the argument in "", maybe that is the problem? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Donnerstag, 2. Februar 2017 10:45:02 An: Development list for mkgmap Betreff: [mkgmap-dev] Is height: filter working as described? According to style manual the rule natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24] from default style should convert ele values from meters to feet, assuming ele is in meters, but this is what map shows for the following ele values: ele=500, map: ", 500 m" ele=500m, map: ", 500 m" ele=500ft, map: ", 152 m" So it seems to be doing right the opposite, converting from feet to meters. Also, with m=>ft rule, map should show ft units, not m. If I invert the rule from m=>ft to ft=>m this is what happens: ele=500, map: ", 46 m" ele=500m, map: ", 152 m" ele=500ft, map: ", 46 m" Now it seems when values are in feet conversion factor is applied twice. It seems when height: is used it always does a ft to m conversion first and then it applies what is specified in the rule. For the same examples, conv: filter gives the right values. _______________________________________________ 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
I thought the special character was the comma that is added after the name. So there is some internal character that may affect displayed units, right? El 02/02/17 a las 11:31, Gerd Petermann escribió:
Hi Carlos,
I forgot to mention that the special separation character added by the height filter might tell Garmin softtware to convert the value (again). IIRC there is a flag in the img file which tells Garmin if values are in feet or metres, so you are probably right that the filter doesn't work as expected.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 2. Februar 2017 11:18:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is height: filter working as described?
Hi Carlos,
this seems to be a problem in the documentation. I found this description for the height filter: "This is exactly the same as the conv filter, except that it prepends a special separation character before the value which is intended for elevations." ${ele|height:"m=>ft"}
This can be easily confused with the example for the conv filter: ${height|conv:"m=>ft"}
Looking at the source code the description for height seems okay. In your examples the rule doesn't place the argument in "", maybe that is the problem?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Donnerstag, 2. Februar 2017 10:45:02 An: Development list for mkgmap Betreff: [mkgmap-dev] Is height: filter working as described?
According to style manual the rule natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24] from default style should convert ele values from meters to feet, assuming ele is in meters, but this is what map shows for the following ele values: ele=500, map: ", 500 m" ele=500m, map: ", 500 m" ele=500ft, map: ", 152 m" So it seems to be doing right the opposite, converting from feet to meters. Also, with m=>ft rule, map should show ft units, not m. If I invert the rule from m=>ft to ft=>m this is what happens: ele=500, map: ", 46 m" ele=500m, map: ", 152 m" ele=500ft, map: ", 46 m" Now it seems when values are in feet conversion factor is applied twice. It seems when height: is used it always does a ft to m conversion first and then it applies what is specified in the rule. For the same examples, conv: filter gives the right values.
Not sure. I think the that the values for contourlines work like this. I'll experiment with the values later. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Donnerstag, 2. Februar 2017 11:44:42 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is height: filter working as described? I thought the special character was the comma that is added after the name. So there is some internal character that may affect displayed units, right? El 02/02/17 a las 11:31, Gerd Petermann escribió:
Hi Carlos,
I forgot to mention that the special separation character added by the height filter might tell Garmin softtware to convert the value (again). IIRC there is a flag in the img file which tells Garmin if values are in feet or metres, so you are probably right that the filter doesn't work as expected.
Gerd
________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@hotmail.com> Gesendet: Donnerstag, 2. Februar 2017 11:18:05 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is height: filter working as described?
Hi Carlos,
this seems to be a problem in the documentation. I found this description for the height filter: "This is exactly the same as the conv filter, except that it prepends a special separation character before the value which is intended for elevations." ${ele|height:"m=>ft"}
This can be easily confused with the example for the conv filter: ${height|conv:"m=>ft"}
Looking at the source code the description for height seems okay. In your examples the rule doesn't place the argument in "", maybe that is the problem?
Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Donnerstag, 2. Februar 2017 10:45:02 An: Development list for mkgmap Betreff: [mkgmap-dev] Is height: filter working as described?
According to style manual the rule natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 24] from default style should convert ele values from meters to feet, assuming ele is in meters, but this is what map shows for the following ele values: ele=500, map: ", 500 m" ele=500m, map: ", 500 m" ele=500ft, map: ", 152 m" So it seems to be doing right the opposite, converting from feet to meters. Also, with m=>ft rule, map should show ft units, not m. If I invert the rule from m=>ft to ft=>m this is what happens: ele=500, map: ", 46 m" ele=500m, map: ", 152 m" ele=500ft, map: ", 46 m" Now it seems when values are in feet conversion factor is applied twice. It seems when height: is used it always does a ft to m conversion first and then it applies what is specified in the rule. For the same examples, conv: filter gives the right values.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Carols, some guessing on my part, hope someone corrects if I'm wrong. As I understand, elevations in img are stored in feet. Filters hight:m=>ft and conv:m=>ft indicate, that value from source has to be converted into feet, as expected by img format. When you look at map, you see height units according to settings in GPS. You can set meters or feet. So for hight:m=>ft, these values are correct: ele=500, map: ", 500 m" = 1650ft, default conversion ele=500m, map: ", 500 m" = 1650ft, converted form meters ele=500ft, map: ", 152 m" = 499ft, preserved feet Settings in GPS are valid only for some objects types and label content. Conversion in GPS is done, when label starts with numeric or numeric is prefixed by special separator (it is [0x1f] for cgpsmapper). I guess filter "hight:" adds separator and GPS converts it to ", ". Now filter hight:ft=>m seems to be kind of useless. It converts feet to meters, stores this value in img and adds a prefix, indicating that value is in feet. What we need here, is no conversion but separator only. Maybe something like this could work: {ele|height:ft=>ft}. Actually it always should be feet as a destination for height, we could simplify this filter like this: {ele|height:m} or {ele|height:ft}, indicating only default unit in source data. -- Best regards, Andrzej
Hi all, Andrzejs findings sound logical to me. I propose to add a check which prints an error message if height is used with a target unit other then ft: Error in style: Error: height filter reqires ft (feet) as target unit: 'ft=>m' and I can add a corresponding hint in the doc. OK? Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 2. Februar 2017 14:06:22 An: mkgmap-dev@lists.mkgmap.org.uk Betreff: Re: [mkgmap-dev] Is height: filter working as described? Hi Carols, some guessing on my part, hope someone corrects if I'm wrong. As I understand, elevations in img are stored in feet. Filters hight:m=>ft and conv:m=>ft indicate, that value from source has to be converted into feet, as expected by img format. When you look at map, you see height units according to settings in GPS. You can set meters or feet. So for hight:m=>ft, these values are correct: ele=500, map: ", 500 m" = 1650ft, default conversion ele=500m, map: ", 500 m" = 1650ft, converted form meters ele=500ft, map: ", 152 m" = 499ft, preserved feet Settings in GPS are valid only for some objects types and label content. Conversion in GPS is done, when label starts with numeric or numeric is prefixed by special separator (it is [0x1f] for cgpsmapper). I guess filter "hight:" adds separator and GPS converts it to ", ". Now filter hight:ft=>m seems to be kind of useless. It converts feet to meters, stores this value in img and adds a prefix, indicating that value is in feet. What we need here, is no conversion but separator only. Maybe something like this could work: {ele|height:ft=>ft}. Actually it always should be feet as a destination for height, we could simplify this filter like this: {ele|height:m} or {ele|height:ft}, indicating only default unit in source data. -- Best regards, Andrzej _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, warning is OK. I hope filters with the same units for source and target work too. They would be convenient to remove unit shortcut from tag. Another suggestion for default style, support for comma as decimal separator: natural=peak {name '${name|def:}${ele|subst:,=>.|height:m=>ft|def:}' } [0x6616 resolution 24] -- Best regards, Andrzej
El 02/02/17 a las 15:24, Andrzej Popowski escribió:
Hi Gerd,
warning is OK. I hope filters with the same units for source and target work too. They would be convenient to remove unit shortcut from tag.
Another suggestion for default style, support for comma as decimal separator:
natural=peak {name '${name|def:}${ele|subst:,=>.|height:m=>ft|def:}' } [0x6616 resolution 24]
Comma as decimal separator is wrong in OSM data, so it would be good to throw a warning when comma is found, not only for ele, but also for width, weight, maxheight, maxwidth, maxweight and may be other tags.
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
+1. BTW, comma is also standard decimal separator in Spain, and also a usual error in data here. El 02/02/17 a las 16:38, Andrzej Popowski escribió:
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.
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@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@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
_______________________________________________ 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
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@lists.mkgmap.org.uk> im Auftrag von Colin Smale <colin.smale@xs4all.nl> Gesendet: Freitag, 3. Februar 2017 11:48:26 An: mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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 _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Colin Smale <colin.smale@xs4all.nl> Gesendet: Freitag, 3. Februar 2017 11:48:26 An: mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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
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@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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@lists.mkgmap.org.uk> im Auftrag von Colin Smale <colin.smale@xs4all.nl> Gesendet: Freitag, 3. Februar 2017 11:48:26 An: mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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@lists.mkgmap.org.uk> im Auftrag von Colin Smale <colin.smale@xs4all.nl> Gesendet: Freitag, 3. Februar 2017 11:48:26 An: mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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
_______________________________________________ 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
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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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@lists.mkgmap.org.uk> im Auftrag von Colin Smale <colin.smale@xs4all.nl> Gesendet: Freitag, 3. Februar 2017 11:48:26 An: mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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
Hi Carlos, yes, sorry, I forgot to hardcode the m. I understood your post so that you want to hardcode the m value and that meter should be the only unit. I agree that it seems impossible to get the Garmin translated value in the format you want. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@orangecorreo.es> Gesendet: Samstag, 4. Februar 2017 13:55:38 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is height: filter working as described? 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@lists.mkgmap.org.uk> im Auftrag von Gerd Petermann <GPetermann_muenchen@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@lists.mkgmap.org.uk> im Auftrag von Carlos Dávila <cdavilam@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@lists.mkgmap.org.uk> im Auftrag von Colin Smale <colin.smale@xs4all.nl> Gesendet: Freitag, 3. Februar 2017 11:48:26 An: mkgmap-dev@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@lists.mkgmap.org.uk<mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk>> im Auftrag von Andrzej Popowski <popej@poczta.onet.pl<mailto:popej@poczta.onet.pl>> Gesendet: Donnerstag, 2. Februar 2017 16:38:37 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@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
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
El 02/02/17 a las 14:06, Andrzej Popowski escribió:
Hi Carols,
some guessing on my part, hope someone corrects if I'm wrong.
As I understand, elevations in img are stored in feet.
Filters hight:m=>ft and conv:m=>ft indicate, that value from source has to be converted into feet, as expected by img format.
When you look at map, you see height units according to settings in GPS. You can set meters or feet. So for hight:m=>ft, these values are correct: ele=500, map: ", 500 m" = 1650ft, default conversion ele=500m, map: ", 500 m" = 1650ft, converted form meters ele=500ft, map: ", 152 m" = 499ft, preserved feet
Settings in GPS are valid only for some objects types and label content. Conversion in GPS is done, when label starts with numeric or numeric is prefixed by special separator (it is [0x1f] for cgpsmapper). I guess filter "hight:" adds separator and GPS converts it to ", ".
Now filter hight:ft=>m seems to be kind of useless. It converts feet to meters, stores this value in img and adds a prefix, indicating that value is in feet. What we need here, is no conversion but separator only. Maybe something like this could work: {ele|height:ft=>ft}.
Actually it always should be feet as a destination for height, we could simplify this filter like this: {ele|height:m} or {ele|height:ft}, indicating only default unit in source data.
It also looks reasonable to me.
Hi Andrzej That is exactly right. In particular I agree that it should be {ele|height:m} as it has to have feet as the target unit. Since the default unit in OSM is meters even the :m part could be defaulted. ..Steve
some guessing on my part, hope someone corrects if I'm wrong.
As I understand, elevations in img are stored in feet.
Filters hight:m=>ft and conv:m=>ft indicate, that value from source has to be converted into feet, as expected by img format.
When you look at map, you see height units according to settings in GPS. You can set meters or feet. So for hight:m=>ft, these values are correct: ele=500, map: ", 500 m" = 1650ft, default conversion ele=500m, map: ", 500 m" = 1650ft, converted form meters ele=500ft, map: ", 152 m" = 499ft, preserved feet
Settings in GPS are valid only for some objects types and label content. Conversion in GPS is done, when label starts with numeric or numeric is prefixed by special separator (it is [0x1f] for cgpsmapper). I guess filter "hight:" adds separator and GPS converts it to ", ".
Now filter hight:ft=>m seems to be kind of useless. It converts feet to meters, stores this value in img and adds a prefix, indicating that value is in feet. What we need here, is no conversion but separator only. Maybe something like this could work: {ele|height:ft=>ft}.
Actually it always should be feet as a destination for height, we could simplify this filter like this: {ele|height:m} or {ele|height:ft}, indicating only default unit in source data.
I'd prefer not to change the syntax because that would break backward compatibility. Attached is a small patch which allows to use height without an argument. If an arg is given it must use ft or feet as target. The doc is changed accordingly. I've also tried to fix a problem in the docu for conv. If I hear no complains I'll commit this tomorrow. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Donnerstag, 2. Februar 2017 22:52:09 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is height: filter working as described? Hi Andrzej That is exactly right. In particular I agree that it should be {ele|height:m} as it has to have feet as the target unit. Since the default unit in OSM is meters even the :m part could be defaulted. ..Steve
some guessing on my part, hope someone corrects if I'm wrong.
As I understand, elevations in img are stored in feet.
Filters hight:m=>ft and conv:m=>ft indicate, that value from source has to be converted into feet, as expected by img format.
When you look at map, you see height units according to settings in GPS. You can set meters or feet. So for hight:m=>ft, these values are correct: ele=500, map: ", 500 m" = 1650ft, default conversion ele=500m, map: ", 500 m" = 1650ft, converted form meters ele=500ft, map: ", 152 m" = 499ft, preserved feet
Settings in GPS are valid only for some objects types and label content. Conversion in GPS is done, when label starts with numeric or numeric is prefixed by special separator (it is [0x1f] for cgpsmapper). I guess filter "hight:" adds separator and GPS converts it to ", ".
Now filter hight:ft=>m seems to be kind of useless. It converts feet to meters, stores this value in img and adds a prefix, indicating that value is in feet. What we need here, is no conversion but separator only. Maybe something like this could work: {ele|height:ft=>ft}.
Actually it always should be feet as a destination for height, we could simplify this filter like this: {ele|height:m} or {ele|height:ft}, indicating only default unit in source data.
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On 02/03/2017 07:32 AM, Gerd Petermann wrote:
I'd prefer not to change the syntax because that would break backward compatibility.
Attached is a small patch which allows to use height without an argument. If an arg is given it must use ft or feet as target. The doc is changed accordingly. I've also tried to fix a problem in the docu for conv.
+ public HeightFilter(String s) { + super(s == null ? "m=>s" : s); There is a typo there I think, should be "m=>ft" ..Steve
Hi Steve, good catch. The additional constructor is also not needed. Attached is v2 of the patch. Gerd ________________________________________ Von: mkgmap-dev <mkgmap-dev-bounces@lists.mkgmap.org.uk> im Auftrag von Steve Ratcliffe <steve@parabola.me.uk> Gesendet: Freitag, 3. Februar 2017 10:53:20 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Is height: filter working as described? On 02/03/2017 07:32 AM, Gerd Petermann wrote:
I'd prefer not to change the syntax because that would break backward compatibility.
Attached is a small patch which allows to use height without an argument. If an arg is given it must use ft or feet as target. The doc is changed accordingly. I've also tried to fix a problem in the docu for conv.
+ public HeightFilter(String s) { + super(s == null ? "m=>s" : s); There is a typo there I think, should be "m=>ft" ..Steve _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
participants (5)
-
Andrzej Popowski -
Carlos Dávila -
Colin Smale -
Gerd Petermann -
Steve Ratcliffe