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
