Why are all the un-named peaks called '6140565'?
Stylists, Just noticed that in the UK map, points tagged natural=peak that don't have a name are showing a name of '6140565'. I guess it's something to do with this rule from the points file: natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 18] The style language is completely beyond me, what's it doing? Mark
Mark Burton wrote:
Just noticed that in the UK map, points tagged natural=peak that don't have a name are showing a name of '6140565'. I guess it's something to do with this rule from the points file:
natural=peak {name '${name|def:}${ele|height:m=>ft|def:}' } [0x6616 resolution 18]
Is "6140565" the last name in the .osm file being processed at that time? I've seen a similar effect with all unnamed natural=peak being named "YHA Ravenstor" (which happened to be the last name in the file that I was processing at the time). As to how to fix it; haven't a clue...
Hi Someoneelse,
Is "6140565" the last name in the .osm file being processed at that time? I've seen a similar effect with all unnamed natural=peak being named "YHA Ravenstor" (which happened to be the last name in the file that I was processing at the time). As to how to fix it; haven't a clue...
That's interesting to learn. In this case, 6140565 does appear as a tag value: <node id='27424899' lat='55.8449129' lon='-4.4298279'> <tag k='highway' v='bus_stop'/> <tag k='nat_ref' v='6140565'/> </node> Hey, that's a really great bug, it causes anonymous peaks to be named in honour of a bus stop! Mark
On Sun, Mar 14, 2010 at 11:29 PM, Mark Burton <markb@ordern.com> wrote:
Hey, that's a really great bug, it causes anonymous peaks to be named in honour of a bus stop!
This may be caused by the "def" (default value) and "height" filters. I believe the statement is attempting the following: 1. ${name|def:} use either the 'name' value, or as default '' (empty string). 2. ${ele|height:m=>ft|def:} Convert the elevation in meters to feet. If no 'ele' value is present, use an empty string. I have a feeling that the empty string part may be misinterpreted right now. It could be that the last value found is instead used. The relevant files are below, if you want to debug: DefaultFilter.java - called for the 'def' filter. HeightFilter.java - called for the 'height' filter (a subclass of ConvertFilter.java) ValueBuilder.java - instantiates the filter classes. This would be a good place to start. Cheers.
Hi Clinton,
On Sun, Mar 14, 2010 at 11:29 PM, Mark Burton <markb@ordern.com> wrote:
Hey, that's a really great bug, it causes anonymous peaks to be named in honour of a bus stop!
This may be caused by the "def" (default value) and "height" filters. I believe the statement is attempting the following:
1. ${name|def:} use either the 'name' value, or as default '' (empty string).
2. ${ele|height:m=>ft|def:} Convert the elevation in meters to feet. If no 'ele' value is present, use an empty string.
I have a feeling that the empty string part may be misinterpreted right now. It could be that the last value found is instead used.
The relevant files are below, if you want to debug:
DefaultFilter.java - called for the 'def' filter.
HeightFilter.java - called for the 'height' filter (a subclass of ConvertFilter.java)
ValueBuilder.java - instantiates the filter classes. This would be a good place to start.
Thanks for the info - I started to nose around in that area but haven't got far - I shall take another look this evening. One thing that struck me was (somewhere in that code) I saw where it was testing to see if a passed in String value was null but it didn't test if it was zero-length. So, like you above, I wonder if the empty default value is causing problems. Cheers, Mark
Hi
<node id='27424899' lat='55.8449129' lon='-4.4298279'> <tag k='highway' v='bus_stop'/> <tag k='nat_ref' v='6140565'/> </node>
It may be a clue that nat_ref does not occur in the style file at all. As far as I can tell so far, the problem is happening after style processing. Very strange. ..Steve
Hi Steve,
<node id='27424899' lat='55.8449129' lon='-4.4298279'> <tag k='highway' v='bus_stop'/> <tag k='nat_ref' v='6140565'/> </node>
It may be a clue that nat_ref does not occur in the style file at all. As far as I can tell so far, the problem is happening after style processing. Very strange.
In StyledConverter.elementSetup() if an element doesn't have a name but it has a ref (ref|int_ref|nat_ref|etc.) the first ref gets assigned to the name. It also does some pattern matching like the filter stuff does. I wonder if there is a connection...? Mark
Hi Mark
It may be a clue that nat_ref does not occur in the style file at all. As far as I can tell so far, the problem is happening after style processing. Very strange.
In StyledConverter.elementSetup() if an element doesn't have a name but it has a ref (ref|int_ref|nat_ref|etc.) the first ref gets assigned to
Yes, I was thinking that the fact that nat_ref was involved meant that it couldn't be anything much to do with ValueBuilder et al. It turns out that the problem is Labels that are empty but not null. All such labels, however generated, show as whatever label was defined right after the first empty one. The attached patch should fix it. ..Steve
participants (4)
-
Clinton Gladstone -
Mark Burton -
Someoneelse -
Steve Ratcliffe