[Talk-us] Prima Facie Speed Limits

Toby Murray toby.murray at gmail.com
Mon Sep 15 17:30:00 UTC 2014


On Mon, Sep 15, 2014 at 10:52 AM, Martin Koppenhoefer <
dieterdreist at gmail.com> wrote:

>
> 2014-09-15 16:59 GMT+02:00 Ed Hillsman <hillsman at pobox.com>:
>
>> I agree there is a need to have a way to deal with this. Where I have
>> checked a street, in both directions, for a posted speed limit and found
>> none, I tag the street as maxspeed=unposted, source:maxspeed=survey. This
>> makes it clear that the street has been checked in the field and found not
>> to have a posted speed limit.
>
>
>
> one problem I could see with that approach is that the information density
> in your 2 tags is very low (the "unposted" value doesn't say anything about
> the actual speed limit and the survey-value could be seen as implicit for
> this kind of tag). IMHO putting an actual limit into the maxspeed key is
> valueable, regardless whether this is signposted or an implicit limit,
> because this is the speed information that most drivers on that road will
> be interested in (typically).
>
>
I may have some locational bias on this because as far as I know, Kansas
does not have any default speed limits and it is fairly uncommon to see a
(paved) road without a speed limit sign somewhere along it.

So that being said, I'm a fan of putting a maxspeed=<number> tag on
everything. Leaving it up to data consumers to interpret the thousands of
potential local defaults around the world doesn't seem like a good argument
to me. And yes, in urban areas a maxspeed tag is likely to be less useful
but most of our data consumers aren't going to have a historical, indexed
by time of day archive of user traces to extract realistic data from. And
as far as I am aware, there is no open repository of such information. So a
maxspeed tag is at least a good starting point. I don't see the data
maintenance being any different from most of our other data. If it is
actually used in applications (such as OsmAnd or on Garmin devices) then
any errors are going to be fairly visible to users which leads to feedback
and fixing of data.

Toby
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20140915/2cd448b2/attachment.html>


More information about the Talk-us mailing list