Re: [OSM-talk] Map Features, maxspeed and maplint
"Tristan Scott" <[EMAIL PROTECTED]> 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 <[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). 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 [EMAIL PROTECTED] [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On Tue, Oct 14, 2008 at 11:05 AM, Tristan Scott <[EMAIL PROTECTED]> 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 <[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 >> >> 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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
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 > > -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
"Tristan Scott" <[EMAIL PROTECTED]> 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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
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 <[EMAIL PROTECTED]> > "Tristan Scott" <[EMAIL PROTECTED]> 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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
"Tristan Scott" <[EMAIL PROTECTED]> 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@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Tristan wrote: > I am happy to use 30mph not 48 (which conflicts > with map features which specify kmh and not units..) > as it seems a widely-used value and hence /ought/ to > be interpreted by renderers (is it? are any of them?) I don't think I know of any renderers that render maxspeed, whatever the units. The maplint validation works from an xml file which is generated from the Map Features page using a perl script, the updated XML output of which needs commiting to svn which will then get downloaded by [EMAIL PROTECTED] clients when they next update. I recently did this to try and get parking_aisle to be recognised by the maplint validation (I didn't do the svn commit - someone did this bit for me). Anyway, because the Map Features Restrictions template which includes maxspeed has Number in the relevant column it is interpreted as a special field type and the validation done at present is !=NaN (or some similar syntax) which basically says it is an error if the value of a maxspeed key is "Not a Number", and highlights the way with a non-numeric maxspeed as not-in-map_features. I don't believe there is an easy solution to this. I was looking at the Perl script and a quick but distasteful workaround would be to change Number on the Map Features page to Number / User defined which I think *might* then allow *anything* (which is why I don't want to do it). I think this would be the only way without amending the perl script. If the perl script was to be amended then either we could add special code to handle the key of maxspeed, or define a type of "speed" which could be applied to both maxspeed and minspeed and allow either a number (with assumed km/h units) or a number followed by "mph" - I guess this would be done using a regular expression comparison which from my limited perl knowledge seems to use the =~ comparator. If a new type of "speed" was defined in the code, then Map Features would still need modifying in some way for the script to know which fields are of that type - perhaps by changing "Number" to "Number (speed)". As I said, there is no easy solution to the maplint issue that I can think of, although I'm still considering the possibilities. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
I've been reading this discussion since it started...
So far I've seen that there's a problem with conflicting values. It seems
that not only is maxspeed=??mph widely used, it's also handily in exactly
the same place as maxspeed=48 (which is what map features told me to do
(..ish, it didn't specify d.p), therefore it's what I did)
I accept the argument that mapping mph values in kmh is a problem as people
use different levels of precision, and also any mapped value is inaccurate.
When I mapped my first maxspeed (ah, sweet innocence since lost) I found
that people seemed to be converting inaccurately (in that they'd trucated
values rather the rounding according to tagwatch) so I added the lookup
table as a canonical guide (30mph is 48kph if the same number of dp are
used).
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).
I am happy to use 30mph not 48 (which conflicts with map features which
specify kmh and not units..) as it seems a widely-used value and hence
/ought/ to be interpreted by renderers (is it? are any of them?)
Use of the data?
What I had in mind was a satnav, with the user on the way driving along. He
doesn't care what the units are internally, just that the satnav goes "bong"
when he's over the limit. He might have the units displayed, but they'd be
displayed in whatever format he'd told the satnav to use anyway, and so
again the internal types are irrelevant - as long as they can be
standardised by the parser they're ok.
This use would best fit with kmh values (numbers are much easier to atoi()
than various concatenated value+unit strings) in my view. However. "30mph"
to "30" requires some logic by the program.
##I thought that the program being:
waySpeedDisplay = round(atoi(way.maxspeed)*0.621371) #use 1 for kph display
##would be much simpler than the program being
if (sub_string(way.maxspeed,last3chars) == mph)
{
CONV_FACTOR=0.621371
}
else if (not_is_numeric(way.maxspeed))
{
echo "you what?" #handle other string suffixes too!
}
else
{
CONV_FACTOR = 1
}
waySpeedDisplay = round(atoi(way.maxspeed)*CONV_FACTOR); #divide by 0.621371
for km/h display
I may start mapping "mph" suffixes instead of kmh values as it seems in wide
use (therefore logically interpretors would handle it) and arguments for it
on this thread seem logical and well-founded to me.
Tristan
2008/10/13 Ed Loach <[EMAIL PROTECTED]>
> Andy wrote:
> > It's much simpler to parse maxspeed=30mph than it is to work
> > out which
> > one is correct when there's multiple maxspeed:[kph|mph]=30
> > tags, I'd
> > say. I'd try to avoid having two potentially conflicting ways
> > of
> > tagging the same property.
> >
> > Oh, and changing documentation on the wiki to promote the
> > least-prevalent method of tagging is bad form! The wiki should
> > (IMNotVeryHO) be there to document what's in the database, not
> > promote
> > particular tagging schemes over one another.
>
> I agree, and I think the changes to the wiki should be at least
> reversed, and possibly an additional note added to say many users
> append mph to the value where the speed limit is signposted in mph
> rather than converting to km/h (as is already noted on the following
> page I discovered today, following a link from the maxspeed=none
> voting page:
> http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Maxspee
> d
> )
>
> Ed
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
--
Tristan Scott BSc(Hons)
Yare Valley Technical Services
www.yvts.co.uk
07837 205829
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Andy wrote: > It's much simpler to parse maxspeed=30mph than it is to work > out which > one is correct when there's multiple maxspeed:[kph|mph]=30 > tags, I'd > say. I'd try to avoid having two potentially conflicting ways > of > tagging the same property. > > Oh, and changing documentation on the wiki to promote the > least-prevalent method of tagging is bad form! The wiki should > (IMNotVeryHO) be there to document what's in the database, not > promote > particular tagging schemes over one another. I agree, and I think the changes to the wiki should be at least reversed, and possibly an additional note added to say many users append mph to the value where the speed limit is signposted in mph rather than converting to km/h (as is already noted on the following page I discovered today, following a link from the maxspeed=none voting page: http://wiki.openstreetmap.org/index.php/OSM_tags_for_routing/Maxspee d ) Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On Fri, Oct 10, 2008 at 11:36 AM, Shaun McDonald <[EMAIL PROTECTED]> wrote: > It is > much simpler to parse maxspeed:mph=30 than to parse maxspeed=30mph. It's much simpler to parse maxspeed=30mph than it is to work out which one is correct when there's multiple maxspeed:[kph|mph]=30 tags, I'd say. I'd try to avoid having two potentially conflicting ways of tagging the same property. Oh, and changing documentation on the wiki to promote the least-prevalent method of tagging is bad form! The wiki should (IMNotVeryHO) be there to document what's in the database, not promote particular tagging schemes over one another. Cheers, Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Shaun McDonald <[EMAIL PROTECTED]> writes: > On 11 Oct 2008, at 08:09, Ed Loach wrote: >> [..] >> As Matthias writes: >> "From the >> programmer's point of view I don't think it makes much of a >> difference >> whether the unit is stored in the key or in the value." > > hrm with ruby if you are expecting a number in that field and try to > parse it, the units will be lost: > Unknown-00-1f-5b-ec-f0-9b:~ shaunmcdonald$ ruby -v > ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] > Unknown-00-1f-5b-ec-f0-9b:~ shaunmcdonald$ irb >>> "30mph".to_i > => 30 >>> > > http://ruby-doc.org/core/classes/String.html#M000802 > > Now there is a reason from a programmers point of view why units > should be left out of the value. > > (I now better run an hide while someone comes up with a way to parse > that string into an object containing the speed and the units). Don't worry, I won't start an post Ruby code here... Generally tag values are strings. A subset of those are strings that can be parsed into a number + unit (where for some 'unit' is empty). This would be done by very generic code in an application. So, in contrary to my own statement above this is probably more straightforward for a programmer than having to parse keys for the presence of a unit. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On 11 Oct 2008, at 08:09, Ed Loach wrote: [..] As Matthias writes: "From the programmer's point of view I don't think it makes much of a difference whether the unit is stored in the key or in the value." hrm with ruby if you are expecting a number in that field and try to parse it, the units will be lost: Unknown-00-1f-5b-ec-f0-9b:~ shaunmcdonald$ ruby -v ruby 1.8.6 (2008-03-03 patchlevel 114) [universal-darwin9.0] Unknown-00-1f-5b-ec-f0-9b:~ shaunmcdonald$ irb >> "30mph".to_i => 30 >> http://ruby-doc.org/core/classes/String.html#M000802 Now there is a reason from a programmers point of view why units should be left out of the value. (I now better run an hide while someone comes up with a way to parse that string into an object containing the speed and the units). Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On Fri, Oct 10, 2008 at 02:35:59PM +0100, Dermot McNally wrote: > Seriously, though, we're currently in a situation where we have a > documented truth Are you referring to Map features here? Is it a documented truth just because it's in there? So how often have you used the one true tag shop=trumpet for "A shop that sells instruments to hand made music like guitars, drums or saxophones as well as microphones, mixers and amplifiers" today? :-) For me, the documented truth is what people have actually been using. I find myself using tagwatch much more often than map features to find how I should map things. > and a disparate group of people ignoring it in > different ways with a view to solving the same problem. What we badly > need is a considered truth that everybody can use. Is it really that bad? Of course using the same standard is nice, but all serious OSM data usage needs preprocessing anyway. So why is it that bad to have a preprocessor that converts all maxspeed=30mph to maxspeed:mph=30? I am not saying that everyone should tag things in a totally anarchic manner. But to some groups "sensible" might mean different things and if OSM can accommodate both groups and make both feel comfortable, why shouldn't we? spaetz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
> It doesn't help anybody trying to use the data on the terms > implied in > the docs. Furthermore, you're deciding that your opinion (that > the > requirement to process units isn't onerous) is more valid that > the > opinion of the person who first documented maxspeed (that the > tag was > most valuable as a raw number of implied units). To be honest, I don't know why it was first documented this way. Checking the revision history of map features it was first set as a numeric km/hr field by Andy Robinson (Blackadder [0]) when Map Features was little more than a week old, back in March 2006. To my surprise Andy is based in the UK, so his choice of specifying the units are km/hr seems a strange one - I could understand it more if he were based in part of the world where km/h is the default. But perhaps Andy was just documenting what there was already; as he mentions he has been involved with the project since 2005. As Matthias writes: "From the programmer's point of view I don't think it makes much of a difference whether the unit is stored in the key or in the value." and " Also from the logical standpoint I think the unit belongs to the value. But I guess opinions differ here." With which I agree on both counts. I also agree that these differences of opinion are similar to those about oneway=yes as an implied default. Opinions differ. Mine are that if a road is oneway then tag it explicitly, but perhaps that's because Map Features doesn't (currently) document an implied default. Anyway I've got to dash and get a train. I'll be tracking the rail replacement service from Bury-St-Edmunds to Peterborough and will see if it uses any currently not-uploaded-ways when I return. Ed [0] http://wiki.openstreetmap.org/index.php/User:Blackadder ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
"Dermot McNally" <[EMAIL PROTECTED]> writes: > Consider your word-processing package. Most will allow you to set > margins and positions in a number of units: millimetres, centimetres, > ems, points, possibly variable concepts like lines and even really > wacky units like inches. But the representation of any of these units > (except possibly lines) is just a layer of make-up on whatever > internal units the program happens to use. It doesn't actually matter > to us as users how this is done under the hood, as long as we can > still use the kinds of units we like, and as long as the page we print > looks the way we want it to. If you suggested to the programmers that > they should internally store not just the sizes you had chosen, but > also the units you used to express them, they would probably not be > very impressed. > > And yet that's exactly what you advocate for OSM. You want to turn a > field whose only documented usage was to store a simple, > easily-interpreted number into a string that must be parsed to cater > for what is likely to be an ever-increasing range of possible input > styles. All so we can achieve a result that can already be achieved > with the existing key. The missing functionality (the ability to store > both the information of what the original unit was and the value > expressed in that unit) can be added using maxspeed:mph. So now we see > another drawback of anarchy - with no enforcement of good design, you > rely on the crowd to apply it voluntarily. HTML for example allows for the specification of units, too. From the programmer's point of view I don't think it makes much of a difference whether the unit is stored in the key or in the value. Both need to be parsed and either way one has to deal with an ever-increasing range of units. If the unit is included in the value the renderer for example can decide not to care about it and to render either just the numerical part hoping that people would not mix units in an area or print the whole string on the map. Also from the logical standpoint I think the unit belongs to the value. But I guess opinions differ here. Either way, as it stands with current editors the user needs to spell out the unit in either the key or value and editor support would be needed to make that easier for the user and less error prone. I am all for defining a set of "acceptable" units for different physical properties (length, speed, weight, ...) in Map Features and reference that from the different tags that require a unit. Matthias ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
2008/10/10 Ed Loach <[EMAIL PROTECTED]>: > It seems wrong if anyone can just amend Map Features even if their > preferred method is in the minority. That way leads to chaos. I'm > more than tempted to add "or add an mph suffix to the speed" in the > maxspeed= comments field, to document what is already the widely > followed practice (and to my mind makes more sense than allowing two > maxspeed tags on a single way - surely it is as easy to parse any > optional units as it is to read both maxspeed definitions and decide > based on location which is most likely to be the correct one?). But > presumably someone else might just edit out such an amendment. And here we see the drawback of an anarchy. If anybody can document the truth, the quality of the truth can suffer. This is why discussion is important to restore balance. Consider your word-processing package. Most will allow you to set margins and positions in a number of units: millimetres, centimetres, ems, points, possibly variable concepts like lines and even really wacky units like inches. But the representation of any of these units (except possibly lines) is just a layer of make-up on whatever internal units the program happens to use. It doesn't actually matter to us as users how this is done under the hood, as long as we can still use the kinds of units we like, and as long as the page we print looks the way we want it to. If you suggested to the programmers that they should internally store not just the sizes you had chosen, but also the units you used to express them, they would probably not be very impressed. And yet that's exactly what you advocate for OSM. You want to turn a field whose only documented usage was to store a simple, easily-interpreted number into a string that must be parsed to cater for what is likely to be an ever-increasing range of possible input styles. All so we can achieve a result that can already be achieved with the existing key. The missing functionality (the ability to store both the information of what the original unit was and the value expressed in that unit) can be added using maxspeed:mph. So now we see another drawback of anarchy - with no enforcement of good design, you rely on the crowd to apply it voluntarily. In a world where we will all agree that the tag: maxspeed=six thousand one hundred and eighty furlongs per fortnight ...is utterly daft, where are we going to draw the line? It's possible to parse it in as automated a way as you can maxspeed=30mph. But it's extra work, isn't it? Let's remind ourselves that the project is about the collection of data. By keeping the data as clean as practical, we maximise the uses to which it can be put. > Mappers should be mapping what it is they find. If I find an 11'3" > clearance bridge with a 20mph limit beneath it then that is what I > want to map. Nobody is suggesting you shouldn't do that. I'll certainly express the view that when I drive under that bridge, my km/h speedometer and lack of feet and inches reckoning skills will mean that I'll want that translated into real money, but this is going to be possible wherever you choose to store this information. What I'm saying is that when we have tags that are documented as containing simple numbers interpreted as being in a particular unit, that you should either convert your data into that format or choose another tag where your preferred way of using it doesn't break with the already documented behaviour. > I don't want to have to artificially convert either of > these to metric, or use alternate tags for the same thing. This is an unreasonable position. I can't and won't force you to convert anything, but what you're saying is that you want to store your data under a tag conceived for a different kind of data. And without even any update to the documentation of that tag. How can this be a good thing? > addition of units if they aren't the default should be sufficient. It doesn't help anybody trying to use the data on the terms implied in the docs. Furthermore, you're deciding that your opinion (that the requirement to process units isn't onerous) is more valid that the opinion of the person who first documented maxspeed (that the tag was most valuable as a raw number of implied units). This is a bit like the argument that's going on about whether trunk highways should be implicitly one way, just because mappers in some countries happen to use them only for roads where that is the case. It's just another case of the tail trying to wag the dog. > And for those mappers who aren't reading this discussion, or > watching for un-voted amendments to Map Features, they won't even > know about the minority use tags that were added today. Mappers relying on map features will have a hell of a time coping with that stuff you're adding as maxspeed... Dermot -- -- Iren sind menschlich ___ talk mailing list talk@openstreetmap.org ht
Re: [OSM-talk] Map Features, maxspeed and maplint
Chris wrote: > My comment was more to point out that changing the Map features > by > adding the editor's favourite option as though it was an > accepted norm > while the discussion about the options was still taking place > seemed a > bit premature to me. And perhaps as this discussion is limited to the few people who use this list, or spot changes to the wiki, it's all a bit pointless anyway. People are already using maxspeed=30mph much more widely than maxspeed:mph=30 Assuming the figures here are correct: http://tagwatch.stoecker.eu/Great_britain/En/tags.html then there are 1079 uses of =30mph and 93 of :mph=30, and that presumably includes all the ones I switched to :mph at the start of this discussion and will probably switch back at some point if I get time (usefully, maplint highlights the ways so I can find them easily...) It seems wrong if anyone can just amend Map Features even if their preferred method is in the minority. That way leads to chaos. I'm more than tempted to add "or add an mph suffix to the speed" in the maxspeed= comments field, to document what is already the widely followed practice (and to my mind makes more sense than allowing two maxspeed tags on a single way - surely it is as easy to parse any optional units as it is to read both maxspeed definitions and decide based on location which is most likely to be the correct one?). But presumably someone else might just edit out such an amendment. Mappers should be mapping what it is they find. If I find an 11'3" clearance bridge with a 20mph limit beneath it then that is what I want to map. I don't want to have to artificially convert either of these to metric, or use alternate tags for the same thing. The addition of units if they aren't the default should be sufficient. And for those mappers who aren't reading this discussion, or watching for un-voted amendments to Map Features, they won't even know about the minority use tags that were added today. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Frederik Ramm wrote: > Hi, > > Chris Hill wrote: >> [listens for the sound of the voting request email to arrive - hears >> nothing] > > Voting is optional. We could do with a lot less if you ask me. If more > people would just go ahead and tag something... I have the impression > that many newcomers seem to view this as some kind of trophy: (a) find > obscure thing for which there is no map feature yet, (b) write > proposal, (c) get it accepted, (d) yay, you're a real mapper. - You > are a real mapper if you map a hundered occurrences of your obscure > thing and it is found to be useful. > > Bye > Frederik > I have mixed feelings about voting, I think you, Frederik, are close to the non-voting extreme. I respect your POV and your consistent stance, but I think there is a place for voting. It gives a framework for discussion, it helps to draw a discussion to a close, it prompts more involvement in the Wiki by some people and is not binding. My comment was more to point out that changing the Map features by adding the editor's favourite option as though it was an accepted norm while the discussion about the options was still taking place seemed a bit premature to me. Cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Hi, > In my opinion the voting process is broken, as it can potentially vote > in proposals that will break backwards compatibility and require > extensively more complex processing of the data. Maybe we should make sure that the voting pages carry a disclaimer saying: "You are voting for a recommendation, not a binding resolution. Nobody is obliged to follow your decision - neither mappers, nor programmers of editors or renderers. If you vote on something that requires further work to be useful, only vote yes if YOU are prepared to do that work." Or just dump voting altogether, it's useless anyway. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
"yay, you're a real mapper." Those five seconds of happiness create an emotional link between the newcomer and OSM, which I think is a great triumph for the latter. cheers, Lucas = Hi, Chris Hill wrote: > [listens for the sound of the voting request email to arrive - hears > nothing] Voting is optional. We could do with a lot less if you ask me. If more people would just go ahead and tag something... I have the impression that many newcomers seem to view this as some kind of trophy: (a) find obscure thing for which there is no map feature yet, (b) write proposal, (c) get it accepted, (d) yay, you're a real mapper. - You are a real mapper if you map a hundered occurrences of your obscure thing and it is found to be useful. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Hi, Chris Hill wrote: > [listens for the sound of the voting request email to arrive - hears > nothing] Voting is optional. We could do with a lot less if you ask me. If more people would just go ahead and tag something... I have the impression that many newcomers seem to view this as some kind of trophy: (a) find obscure thing for which there is no map feature yet, (b) write proposal, (c) get it accepted, (d) yay, you're a real mapper. - You are a real mapper if you map a hundered occurrences of your obscure thing and it is found to be useful. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00'09" E008°23'33" ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
> maxspeed:mph only conforms to map features because Shaun > amended it > earlier today! And the way it has been amended with two keys in one table row means that if the perl script is run that rebuilds the xml that is used to generate the maplint not-in-mapfeatures validation rules, then maxspeed:mph still isn't picked up as a valid key, so makes no difference to my original problem. Running the perl script does recognise a couple of sports that weren't there previously, and that 1 is now valid for oneway as well as yes (though strangely no-one has yet added True as valid, and I find lots of oneway=true routes when using the maplint layer...) >From a programming point of view, perhaps we should move away from a Value column and have a RegularExpression for validation. Something like ^[1-9]\d*(mph)?$ would validate 1 or more digits as a non-zero limit with optional units of mph. We'd probably still need a Value column for human readable examples, and some better explanation in the Comment column. Certainly I still think maxspeed:mph is a poorer solution than maxspeed=NNmph. It should not be possible to tag contradictory limits on the same way, whether by accident or deliberately. You may have to assume that if both exist then the :mph one takes priority as someone has gone to the trouble of adding it, though in other countries you may want the km/h one to take priority, so again we're back to regional differences. To answer the question someone asked of how many ways can you mis-spell "miles per hour" - the obvious answer is the same as the number of ways that you can spell it wrong putting it after a : in the keyname. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Shaun McDonald wrote: > (I'm wondering if there is a station out there that has all the > railway=platforms mapped, rather than just placing a footpath to the > railway=station node.) Guildford station is pretty close, thanks to TimSC. -- Jonathan (Jonobennett) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On 10 Oct 2008, at 14:27, Chris Hill wrote: Dermot McNally wrote: 2008/10/10 Chris Hill <[EMAIL PROTECTED]>: Conversions to 0dp is inaccurate, accurate conversions are a mess, namespacing allows for conflicting values so only an optional suffix really makes sense, so this why I use. Well, maxspeed:mph would also work for your purposes. The only difference is that you have chosen to silently ignore the behaviour documented in Map Features. I'm not convinced by your point about conflicts - in a world where a single field can have, essentially, different data types in it, I think we've already sacrificed any pretence of orderliness. Dermot maxspeed:mph only conforms to map features because Shaun amended it earlier today! [listens for the sound of the voting request email to arrive - hears nothing] In my opinion the voting process is broken, as it can potentially vote in proposals that will break backwards compatibility and require extensively more complex processing of the data. Take for example: http://wiki.openstreetmap.org/index.php/Proposed_features/Status (I'm wondering if there is a station out there that has all the railway=platforms mapped, rather than just placing a footpath to the railway=station node.) Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
2008/10/10 Chris Hill <[EMAIL PROTECTED]>: > maxspeed:mph only conforms to map features because Shaun amended it earlier > today! > > [listens for the sound of the voting request email to arrive - hears > nothing] Well, two wrongs and all that. Though its worse, IMHO, to do a poo in another man's shed than to build your own shed and do one there ;) Seriously, though, we're currently in a situation where we have a documented truth and a disparate group of people ignoring it in different ways with a view to solving the same problem. What we badly need is a considered truth that everybody can use. Dermot -- -- Iren sind menschlich ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Dermot McNally wrote: > 2008/10/10 Chris Hill <[EMAIL PROTECTED]>: > > >> Conversions to 0dp is inaccurate, accurate conversions are a mess, >> namespacing allows for conflicting values so only an optional suffix really >> makes sense, so this why I use. >> > > Well, maxspeed:mph would also work for your purposes. The only > difference is that you have chosen to silently ignore the behaviour > documented in Map Features. I'm not convinced by your point about > conflicts - in a world where a single field can have, essentially, > different data types in it, I think we've already sacrificed any > pretence of orderliness. > > Dermot > > maxspeed:mph only conforms to map features because Shaun amended it earlier today! [listens for the sound of the voting request email to arrive - hears nothing] Cheers, Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Ed Loach wrote: >Sent: 05 October 2008 1:46 PM >To: talk@openstreetmap.org >Subject: [OSM-talk] Map Features, maxspeed and maplint > > >"(restore metrics text, although it should be discussed)". I don't know >where to find the versions pre 2008 to find out what it said on older >versions. > Map Features didn't originally use templates, so perhaps you need to go back through the history of the Map Features page itself to see the progression. FYI the original version of maxspeed (2006) was km/h Cheers Andy ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
2008/10/10 Chris Hill <[EMAIL PROTECTED]>: > Conversions to 0dp is inaccurate, accurate conversions are a mess, > namespacing allows for conflicting values so only an optional suffix really > makes sense, so this why I use. Well, maxspeed:mph would also work for your purposes. The only difference is that you have chosen to silently ignore the behaviour documented in Map Features. I'm not convinced by your point about conflicts - in a world where a single field can have, essentially, different data types in it, I think we've already sacrificed any pretence of orderliness. Dermot -- -- Iren sind menschlich ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Dermot McNally wrote: > >> It makes more >> sense to have maxspeed=> specified> to avoid the chance of that happening. >> > > Doing so prevents simple numerical analysis of the field contents. > Nothing can be analysed without pre-processing, and you are very prone > to dodgy units (how many ways can you right Miles Per Hour?) > > > Any analysis requires the data to be preprocessed to extract it from the XML storage format, so a little extra to account for the suffix is a small overhead. Conversions to 0dp is inaccurate, accurate conversions are a mess, namespacing allows for conflicting values so only an optional suffix really makes sense, so this why I use. Cheers, Chris (living on a street where maxspeed=30mph) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
2008/10/8 Ed Loach <[EMAIL PROTECTED]>: > I'd argue that it doesn't make sense, in that if you allow both > maxspeed:mph and maxspeed as valid tags, a way may end up tagged > with both showing contradictory speed information. This would require either 2 mappers not heeding each other's work or one very disorganised mapper. > It makes more > sense to have maxspeed= specified> to avoid the chance of that happening. Doing so prevents simple numerical analysis of the field contents. Nothing can be analysed without pre-processing, and you are very prone to dodgy units (how many ways can you right Miles Per Hour?) Dermot -- -- Iren sind menschlich ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On 10 Oct 2008, at 10:24, Tristan Scott wrote: I added the conversion table to maxspeed, as I do a lot of maxspeed tagging in my area. I read the maxspeed definition as needing a numeric value in km/h. While km/h doesn't mean a lot to me, I does to whatever app I use to draw speed limit signs (or, more likely, whatever app runs a satnav system and informs the user when they're over the stated maxspeed for the way they're on) The maxspeed needs to be computer-readable, so people tagging maxspeed=30 when the wiki states km/h is misleading, to my mind. People tagging as 30mph is fine, as that can be parsed to a consistent value anyway. I think it should be in the database as rounded numeric km/h for the following reasons: 1) 30 mph/30mph/30 all meaning 48 is difficult to parse (or at least, more coding) 2) tagging in floating point is more accurate, but rounding the result to 0 dp seems sensible (I also did that because I didn't know if floating-points were approved in the database) 3) The conversion table is an accurate table to 0dp - some people according to the tags-in-use pages seem to have converted the value inaccurately, so I thought it'd save people doing bad math... (30mph != 50km/h, though if we get converted by europe it might change to that) 4) the wiki says km/h, as as previous suggested it's sometimes (often) unclear which unit was meant by mapper, and which unit is in use where the tag in (international waters/boundaries/ways crossing borders/etc You should use maxspeed:mph=nn for speeds in miles per hour, not convert it to km/h, which gives an inexact value and more importantly doesn't map what is on the ground. I don't expect to have to look up a value every time I enter a speed into the database. And I'd welcome a sed-like change to the database to "fix" (imho) the maxspeed=30mph tags (I'd like them consistent. I not too bothered if we store millions of "mph" strings instead of just using km/h, as long as I can easily parse the data) Don't run bots on osm! It is much better to correct things with local knowledge, as there is often other things that need to be fixed too. It is much simpler to parse maxspeed:mph=30 than to parse maxspeed=30mph. Shaun Oh, and I tend to only tag ways with non-national speed limits on - I assume there's a country-wide default maxspeed per road type (though again the border problem raises it's head) Tristan 2008/10/8 Ed Loach <[EMAIL PROTECTED]> Mark wrote: > Maybe this is calling out for a 'bot approach, to take > maxspeed:mph & add a numeric maxspeed, to check out > maxspeed=30's & mark > them in some way (restricted to UK, obviously), and to check > for entries > of both=30 & fix them? > +1 on the namespace; I'm not generally keen on it, but here it > makes > sense. I'd argue that it doesn't make sense, in that if you allow both maxspeed:mph and maxspeed as valid tags, a way may end up tagged with both showing contradictory speed information. It makes more sense to have maxspeed= to avoid the chance of that happening. It does make sense for other situations, such as if opposite directions have different limits (e.g. maxspeed:opposite=), or if different vehicle types have different limits (e.g. maxspeed:psv=) as these clearly can't lead to contradictory information (assuming that if a vehicle type is specified it overrides any other maxspeed tags). Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
2008/10/8 Simon Ward <[EMAIL PROTECTED]>: > "en" is a language code, not a country code. Not all English-speaking > countries use imperial units on road signs. I think Australia uses > metric, for example. So does the Republic of Ireland. In fact, I believe the only English-speakers that don't are in UK and USA. -- -- Iren sind menschlich ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
I added the conversion table to maxspeed, as I do a lot of maxspeed tagging in my area. I read the maxspeed definition as needing a numeric value in km/h. While km/h doesn't mean a lot to me, I does to whatever app I use to draw speed limit signs (or, more likely, whatever app runs a satnav system and informs the user when they're over the stated maxspeed for the way they're on) The maxspeed needs to be computer-readable, so people tagging maxspeed=30 when the wiki states km/h is misleading, to my mind. People tagging as 30mph is fine, as that can be parsed to a consistent value anyway. I think it should be in the database as rounded numeric km/h for the following reasons: 1) 30 mph/30mph/30 all meaning 48 is difficult to parse (or at least, more coding) 2) tagging in floating point is more accurate, but rounding the result to 0 dp seems sensible (I also did that because I didn't know if floating-points were approved in the database) 3) The conversion table is an accurate table to 0dp - some people according to the tags-in-use pages seem to have converted the value inaccurately, so I thought it'd save people doing bad math... (30mph != 50km/h, though if we get converted by europe it might change to that) 4) the wiki says km/h, as as previous suggested it's sometimes (often) unclear which unit was meant by mapper, and which unit is in use where the tag in (international waters/boundaries/ways crossing borders/etc And I'd welcome a sed-like change to the database to "fix" (imho) the maxspeed=30mph tags (I'd like them consistent. I not too bothered if we store millions of "mph" strings instead of just using km/h, as long as I can easily parse the data) Oh, and I tend to only tag ways with non-national speed limits on - I assume there's a country-wide default maxspeed per road type (though again the border problem raises it's head) Tristan 2008/10/8 Ed Loach <[EMAIL PROTECTED]> > Mark wrote: > > > Maybe this is calling out for a 'bot approach, to take > > maxspeed:mph & add a numeric maxspeed, to check out > > maxspeed=30's & mark > > them in some way (restricted to UK, obviously), and to check > > for entries > > of both=30 & fix them? > > > > > +1 on the namespace; I'm not generally keen on it, but here it > > makes > > sense. > > I'd argue that it doesn't make sense, in that if you allow both > maxspeed:mph and maxspeed as valid tags, a way may end up tagged > with both showing contradictory speed information. It makes more > sense to have maxspeed= specified> to avoid the chance of that happening. It does make sense > for other situations, such as if opposite directions have different > limits (e.g. maxspeed:opposite=), or if > different vehicle types have different limits (e.g. > maxspeed:psv=) as these clearly can't lead > to contradictory information (assuming that if a vehicle type is > specified it overrides any other maxspeed tags). > > Ed > > > > ___ > talk mailing list > talk@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk > -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Mark wrote: > Maybe this is calling out for a 'bot approach, to take > maxspeed:mph & add a numeric maxspeed, to check out > maxspeed=30's & mark > them in some way (restricted to UK, obviously), and to check > for entries > of both=30 & fix them? > +1 on the namespace; I'm not generally keen on it, but here it > makes > sense. I'd argue that it doesn't make sense, in that if you allow both maxspeed:mph and maxspeed as valid tags, a way may end up tagged with both showing contradictory speed information. It makes more sense to have maxspeed= to avoid the chance of that happening. It does make sense for other situations, such as if opposite directions have different limits (e.g. maxspeed:opposite=), or if different vehicle types have different limits (e.g. maxspeed:psv=) as these clearly can't lead to contradictory information (assuming that if a vehicle type is specified it overrides any other maxspeed tags). Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On Wed, Oct 08, 2008 at 07:32:36AM +0100, I wrote: > On Wed, Oct 08, 2008 at 12:38:01AM +0100, Mark Williams wrote: > > Either the way mentioned, or maxspeed:en as per name:en for > > consistency? > > “en” is a language code “metric” and “imperial” might be better, although I feel that specifying the units somehow (by key suffix or otherwise) is much more clear. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On Wed, Oct 08, 2008 at 12:38:01AM +0100, Mark Williams wrote: > +1 on the namespace; I'm not generally keen on it, but here it makes > sense. Either the way mentioned, or maxspeed:en as per name:en for > consistency? “en” is a language code, not a country code. Not all English-speaking countries use imperial units on road signs. I think Australia uses metric, for example. Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dermot McNally wrote: > 2008/10/5 Ed Loach <[EMAIL PROTECTED]>: > >> 30mph. If we had stayed with assumed country-specific units then the tagging >> would have been more consistent, easier for the user to tag, and not require >> a conversion to a random number of decimal places. > > I'm not a fan of the options that include suffixes or other tricks to > imply units. That said, even that approach is better than using > country-specific units, because it's a huge burden on applications to > work out what country a restriction falls within (twofold, since the > border data is often imprecise too). Consider the Irish border, which > is also an imperial/metric border. Yuck! > > A further drawback with the approach is the assumption that units stay > uniform within a particular country. But in the UK, it's getting > common for height restrictions to be stated in dual units. So for > transitional cases like that, the country-specific model breaks down. > > I'm with Shaun on the namespacing thing. Allowing fields like maxspeed > to contain normalised, pure numeric data is beneficial for fast data > extraction, and the namespaced approach allows for automatic updating > of the "real|" numeric field. > > Dermot Maybe this is calling out for a 'bot approach, to take maxspeed:mph & add a numeric maxspeed, to check out maxspeed=30's & mark them in some way (restricted to UK, obviously), and to check for entries of both=30 & fix them? Note: I haven't said "I'll do it" because I know I'd be shot... I think a lot of people have refrained from using these tags where the speed limit is what you'd expect, so residential defaults to 30mph, trunk to 70, etc & tagging it is not required - so any bot approach should respect that. +1 on the namespace; I'm not generally keen on it, but here it makes sense. Either the way mentioned, or maxspeed:en as per name:en for consistency? Mark -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI6/LZJfMmcSPNh94RAijGAJ9M/dxPTjuPkCsUNgkbMhs9sFLupwCePQsZ oQltkcfxNEHS9tLSEfMxtfI= =JYyp -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
Simon wrote: > This is my method too. I have converted before, but always > included > both maxspeed=* (~km/h) and maxspeed:mph=* (mph) OK, I can see having (or allowing for) both of these makes some sort of sense, although it does lead to the situation where you might have two maxspeed tags for a way which might not even be close to agreeing (say if one user adds maxspeed:mph=30 at one time and someone later adds maxspeed=30 without specifying units anywhere). Users of the data would then need some sort of algorithm to try and determine which is most likely to be accurate, and I would suggest that may need to perhaps use knowledge of individual countries to know whether their limits are in mph or km/h anyway, so that would suggest country specific units wouldn't have been any extra issue in the first place. Certainly with the UK maxspeed data as it currently stands, it will need some sort of algorithm to try and work out what the maxspeed value represents. However, having changed my maxspeed=30mph tags to maxspeed:mph=30 and got the tiles rerendered, this still doesn't seem to help with the maplint not-in-map_features highlighting, and even if it did then it still probably wouldn't like maxspeed(with or without :mph)=national to mark roads that are at the national speed limit (I've not checked to see whether it copes with maxspeed=none as is recommended for relevant German autobahns, but I'd guess not, and I can see despite the suggestion to use it on the maxspeed wiki page [1], the proposal to formalise it currently seems to be being generally opposed [2]). Also, checking Tagwatch [0], maxspeed:mph=30 seems much less common than maxspeed=30mph so this does seem to be a minority choice for tagging, although could be added to Map Features easily enough as a numeric value and so not highlighted by Maplint. I guess this then means any other maxspeed:units should also be added. Does anyone use maxspeed:knots for example? I'm almost tempted to add maxspeed=30mph and maxspeed:mph=30 - just to be clear what the speed limit actually is . I can see no point at all in putting a km/h speed limit value on a tag unless the sign is in km/h (and I believe I have read of a few in the UK). Surely it should be down to the users of the data to do the conversion of maxspeed at whatever accuracy they want, rather than making the people collecting the data calculate something other than that which is physically denoted on the signs, resulting in differing degrees of rounding which the user of the data would then have to guess means 30mph, effectively converting from estimate to accurate and back to desired accuracy. As long as the units are clearly expressed if they are not the default then this shouldn't be a problem (and I'm assuming no-one would read mph as metres per hour, except perhaps snails). Looking at the comments about maxspeed on the wiki at present, perhaps some consideration should be put towards some proposal, such as: maxspeed=number (optional units from predefined list, default km/h) maxspeed:opposite=number (optional units from predefined list, default km/h) maxspeed:psv=number (optional units etc) maxspeed:psv:opposite=number (optional etc) which would allow for where single ways have different speeds in opposite directions (I can't think of any examples, but someone asked about it on maxspeed discussion page), and where different vehicle types (I use psv only as one example) have different limits - I think it more common on things like the French toll routes than in the UK; in the UK some vehicle types have different limit, but that is a feature of the vehicle therefore and not something that needs mapping). I have suggested the optional units here be with the value as that avoids having multiple contradictory maxspeeds that differ only in the units specified; it is for this reason I was using maxspeed=30mph originally (rather than maxspeed:mph=30, as I had seen mention of both alternatives previously. I note though maxspeed=walk seems to be looking like it might get voted through [3], which wouldn't fit very well with the above. Ed [0] http://tagwatch.stoecker.eu/Great_britain/En/tags.html [1] http://wiki.openstreetmap.org/index.php/Key:maxspeed [2] http://wiki.openstreetmap.org/index.php/Proposed_features/maxspeed_none [3] http://wiki.openstreetmap.org/index.php/Proposed_features/maxspeed_walk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
On Sun, Oct 05, 2008 at 02:09:26PM +0100, Shaun McDonald wrote: > All units in osm should be the metric value, unless the units have been > name spaced. Whenever I enter mph units, I use the tag maxspeed:mph=30 > etc as this is the most accurate way of representing the data. This is my method too. I have converted before, but always included both maxspeed=* (~km/h) and maxspeed:mph=* (mph) Simon -- A complex system that works is invariably found to have evolved from a simple system that works.—John Gall signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
2008/10/5 Ed Loach <[EMAIL PROTECTED]>: > 30mph. If we had stayed with assumed country-specific units then the tagging > would have been more consistent, easier for the user to tag, and not require > a conversion to a random number of decimal places. I'm not a fan of the options that include suffixes or other tricks to imply units. That said, even that approach is better than using country-specific units, because it's a huge burden on applications to work out what country a restriction falls within (twofold, since the border data is often imprecise too). Consider the Irish border, which is also an imperial/metric border. Yuck! A further drawback with the approach is the assumption that units stay uniform within a particular country. But in the UK, it's getting common for height restrictions to be stated in dual units. So for transitional cases like that, the country-specific model breaks down. I'm with Shaun on the namespacing thing. Allowing fields like maxspeed to contain normalised, pure numeric data is beneficial for fast data extraction, and the namespaced approach allows for automatic updating of the "real|" numeric field. Dermot -- -- Iren sind menschlich ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Map Features, maxspeed and maplint
All units in osm should be the metric value, unless the units have
been name spaced. Whenever I enter mph units, I use the tag
maxspeed:mph=30 etc as this is the most accurate way of representing
the data. I'm not going to spend time converting between mph and kph,
when entering the data, that is for whoever uses the data to do. In my
opinion, it is far better to use the local units, but always have it
clear as to the units, when they are not metric/most common.
Shaun
On 5 Oct 2008, at 13:45, Ed Loach wrote:
I've not done much maxspeed tagging to date, for various reasons,
but the main one is that Map Features says that maxspeed should be
in km/h. Or more accurately looking at the history for the template
for that section [1], the original conversion stated:
"{{{maxspeed:desc|Maximum speed, country-specific units}}"
And the revision 3 minutes later changed it to
"{{{maxspeed:desc|Maximum speed in km/h}}}"
With a description for the edit (from Pieren) of
"(restore metrics text, although it should be discussed)". I don’t
know where to find the versions pre 2008 to find out what it said on
older versions.
I noticed that “should be discussed” note, but don’t know where to
look for that discussion. However, the decision to put in km/h has
made a mess of the maxspeed tagging on UK roads, especially as there
is both a conversion table in the wiki quoting whole numbers, and a
multiplication factor to use. See for example Tagwatch [2] where the
most common maxspeed is 48, followed by 30mph (the format I’ve been
using), and lower down come 48.28, 48.28032, 48.27808 and 48.3. I’d
also guess that the ways tagged as maxspeed=30 mean 30mph. If we had
stayed with assumed country-specific units then the tagging would
have been more consistent, easier for the user to tag, and not
require a conversion to a random number of decimal places.
The maplint mention in the message subject is because Map Features
defines the value for the maxspeed key as being a number, so any way
I’ve tagged as =30mph, 20mph, 10mph, national or 40mph (as I did for
the first time yesterday) gets highlighted in the maplint
information, rendering it (no pun intended) next to useless for
checking other mistakes I may have made in the tagging.
I have no suggestion what to do about either of these situations
though. I wouldn’t have been bothered at all if maplint hadn’t
suddenly started highlighting lots of ways in the area… I realise
that that is down to the word number in the wiki page causing the
validation to fail with the mph in the value.
Thinking about it I have a similar issue with maxheight. Most of the
signs these days I think quote in metres, but I tagged one the other
day as so many feet and inches (possibly 13’9” – I forget), as I tag
what is on the sign and not what a metric conversion is (to the
centimetre, metre, decimetre, millimetre?). It seems I’m not the
only one [3].
I suspect what I’d like most would be for maplint to recognise that
if the value contains valid units for whatever the key is (optional
units), then it wouldn’t highlight the way as in need of checking. I
believe maplint is common to both Mapnik and Osmarender (as it’s
highlighting ways on Mapnik which don’t yet show as I only added
them yesterday), and I know how to rebuild the not-in-map_features
information as I did it recently to add some keys that *were* in Map
Features but not being recognised by the [EMAIL PROTECTED] client when it
generated the maplint tiles, but it would probably need the perl
code that creates the XML tweaking to cope with optional units in
some way (a bit like it currently doesn’t like * in the value
column, IIRC, or “User Defined”).
It’s raining here incidentally, which is why I thought I’d rant on
email instead of going out mapping a bit more of the area.
Ed
[1]
http://wiki.openstreetmap.org/index.php?title=Template%3AMap_Features%3Arestrictions&diff=73032&oldid=73031
[2] http://tagwatch.stoecker.eu/Great_britain/En/
keystats_maxspeed.html
[3] http://tagwatch.stoecker.eu/Great_britain/En/keystats_maxheight.html
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
