Message below forwarded from OSM-talk, where after much discussion
it seems that a number of people feel that while maxspeed is
currently documented as a numeric field in km/h, that as many UK
mappers have mapped what it is they find (such as maxspeed=30mph)
that it would make sense if units are to be added to the maxspeed in
some cases that they be with the value rather than the units being a
separate key. From the point of view of maplint validation this
suggests (to me) a new type of “speed” to go on the Map Features
page (rather than Number) and regular expressions to validate the
special speed type, and I was having a quick play here today. I
added the following bits of code to my local copy of
not-in-map_features.pl
Firstly, after the TODO bit about time, I added:
# Speed
elsif( lc($value) eq 'speed'){
$special = { type => 'regex',
regex =>
'[1-9]\d*.?\d*\s*(kmh|km/h|knots|mph)?'};
}
# Width/Height
elsif( lc($value) eq 'width' | lc($value) eq 'height'){
$special = { type => 'regex',
regex =>
'[1-9]\d*(\x27){1}\s*[1-9]\d*(\x22){1}|[1-9]\d*\s*(m)?'};
}
And lower down I added before the } else die BUG bit:
} elsif( $special->{type} eq 'regex' ){
my $regex = $special->{regex};
print "<xsl:when test=\"matches([EMAIL PROTECTED],
'$regex')\" />\n";
This generated a bit of code in the xml file (after I cheated and
added code before the numberic value check to check key=maxspeed)
which looked like:
<xsl:when test="@k='maxspeed'">
<xsl:choose>
<xsl:when test="matches(@v,
'[1-9]\d*.?\d*\s*(kmh|km/h|knots|mph)?')" />
<xsl:otherwise>
<maplint:result><xsl:value-of select="concat('Value not in map
features: ', @k, '=', @v)" /></maplint:result>
</xsl:otherwise>
</xsl:choose>
</xsl:when>
which I then manually inserted into my local copies of tests.xml and
tests.xsl (as I don’t know what does what, but they looked like they
had sections based on not-in-map_features.xml)
I then tried to rerender an area I knew had non-numeric maxspeeds as
a test (xy 2062 1355 12 maplint), and got the following error:
This is version 11132 (Trondheim) of tilesgen running on MSWin32,
ID: 38701
[#0 0% ] Tileset (12,2062,1355) around 51.86,1.27
[#0 0% maplint] Running maplint... ERROR
The following command produced an error message:
"d:\TilesAtHome\xmlstarlet\xml.exe" tr maplint/lib/run-tests.xsl
D:\TilesAtHome\tmp\12_2062_1355_twiFk\data.osm > "tmp.2832"
Debug output follows:
| xmlXPathCompOpEval: function matches not found
| XPath error : Unregistered function
| xmlXPathCompiledEval: 1 object left on the stack
Additional info about the Error(s):
[#0 0% maplint-z16] Rendering...
This looks a bit like xmlstarlet doesn’t support the XSLT/XPath2
matches function, which if I’ve read everything correctly is how I
was hoping to introduce Regular Expression checks. If I’m correct
that the latest release of XMLStarlet was from early 2005 then I’m
not too surprised.
Perhaps someone with more knowledge than I might be able to suggest
another way of implementing such checks? Or is there an alternative
(newer) tool that the client could use in place of xmlstarlet?
In the meantime I’ll revert my local files to the stable version
(now I’ve documented what I did when playing…)
Thanks
Ed
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Tristan Scott
Sent: 14 October 2008 19:06
To: David Earl
Cc: [EMAIL PROTECTED]
Subject: Re: [OSM-talk] Map Features, maxspeed and maplint
If this catches on not only do we have a well-defined and
easily-processed value for "speed" to use in all manner of things,
we also have a template for defining other data types (bridge
height? maxweight?) which might (or might not) make the job of the
data processor for an map consuming application (satnav etc) much
easier.
Tristan
2008/10/14 David Earl <[EMAIL PROTECTED]>
On 14/10/2008 18:26, Tristan Scott wrote:
Given that SI units are standard across OSM could be define a
"speed" value in addition to "Numeric" "String" etc like so:
(default to kmh as specified before (also means not adding millions
of pointless "kmh" strings to the db)
Factor means "multiply by this to convert to SI - interpreters would
either use value as-is or multiply by Factor for that suffix to get
SI units.
"Suffix" is the entire string after the numerical value, with
whitespace trimmed - so spaced/not spaced suffix wouldn't matter -
defining this rigidly would be ignored by most users, i suspect
My proposed table:
Unit - Factor
"" - 1
"kmh" - 1
"mph" - 1.609
"knots" - 1.852
+1.
I really don't see what all the fuss is about. It's not exactly
novel to do it this way: CSS puts units as part of the value.
It's what I've been doing all along, except some pedant comes along
and changes it to some incomprehensible decimal number almost as
soon as I add them to the map (which means I can carry on doing it
that way even if others think differently, as they'll get converted
automatically as far as i am concerned and I don't have to think
about a magic number in km/h).
David
_______________________________________________
Tilesathome mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/tilesathome
