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 <grin> 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? <snip> > +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=<number><optional units; assume km/h if none 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=<number><optional units>), or if different vehicle types have different limits (e.g. maxspeed:psv=<number><optional units>) 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 [email protected] http://lists.openstreetmap.org/listinfo/talk -- Tristan Scott BSc(Hons) Yare Valley Technical Services www.yvts.co.uk 07837 205829 _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
