Map Features, maxspeed and maplint

[Tristan Scott-2]

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

Not sure if any other units are in (common) use? Can someone check tagwatch?

Tristan

2008/10/14 Matthias Julius <lists@...>

"Tristan Scott" <trs998@...> writes:

> If it were up to me (dicatorships are so much swifter to deal with
> things...)
> * maxspeed should be the only tag. Therefore you can't contradict
> yourself/others (or update one to 40mph, or not catching because it's not
> normal, maxspeed:mph is still 30 you end up with broken data)
> * "mph" is the only permittable suffix (or a SHORT fixed list added to map
> features), therefore parsing is simple. If Mph / MilesPerHour / mp/h /
> yard/minute / walk / et al is allowed then parsing becomes either impossibly
> (inf types of value) difficult, or becomes easy (if it's not all numeric,
> ignore it).

The list doesn't need to be very short, but it needs to be defined
somewhere.  Then, any application that uses the data can be taught how
to deal with it.

Then Map Features needs to specify that maxspeed is a speed
measurement and link to the table of speed units.

Then Maplint can be extended to recognize tags that require a speed
unit and it can warn if there is none.

Matthias

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

--
Tristan Scott BSc(Hons)
Yare Valley Technical Services
www.yvts.co.uk
07837 205829

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Matthias Julius]

"Tristan Scott" <trs998@...> writes:

> 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
>
> Not sure if any other units are in (common) use? Can someone check tagwatch?

Maybe we need to support scientific notation in case someone wants to
add maxspeed for the LHC...

Matthias

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[David Earl]

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


_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Tristan Scott-2]

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 <david@...>

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

--
Tristan Scott BSc(Hons)
Yare Valley Technical Services
www.yvts.co.uk
07837 205829

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Karl Newman]

On Tue, Oct 14, 2008 at 11:05 AM, Tristan Scott <trs998@...> wrote:

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 <david@...>

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

What about just using the maxspeed tag with just a number and having a separate tag for the units. i.e., maxspeed=30; maxspeed_units=mph

Karl

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[David Earl]

On 15/10/2008 00:17, Karl Newman wrote:
> What about just using the maxspeed tag with just a number and having a
> separate tag for the units. i.e., maxspeed=30; maxspeed_units=mph

Because it takes twice as long to enter.

Because it is non-obvious and unnecessary.

Because it separates two intimately related bits of data.


_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk

[Knut Arne Bjørndal-2]

"Tristan Scott" <trs998@...> writes:

> 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 <david@...>
>
>     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).

Earlier tonight I patched not-in-map_features.pl to accept units for maxspeed, se the post to the tilesathome list for all the details.

I think this proves a point: If it's doable to parse it in perl-generated xpath in under an hour it's not really hard to code.

Don't ask me to add support for validating maxspeed:mph etc, to check that it doesn't conflict with other units or anything, I wouldn't know how to start doing it...

What about making some new lists on the wiki detailing units, make it at least as machine-readable as map features (preferably a little more, as parsing map features is a mess) and I could have the maplint test automatically fetch it's unit descriptions there.

This would also make it easily documented, the value column in map features would say "speed" which links to a page explaining the units allowable for this data type. Exactly how to fit this in with the current template magick in map features is left as an exercise for somebody well versed in mediawiki voodoo.

--
Knut Arne Bjørndal
aka Bob Kåre
bob+osm@...
bobkare@irc

_______________________________________________
talk mailing list
talk@...
http://lists.openstreetmap.org/listinfo/talk