[Talk-us] Prima Facie Speed Limits
Martijn van Exel
m at rtijn.org
Tue Sep 9 18:48:02 UTC 2014
There's a functional difference between speed limits and the actual speed
driven. For ETA prediction, speed limit data is not all that useful -
detailed historical and live speed profiles are. That is not data that is
in OSM (or should be). The speed limits are mostly useful for alerting
drivers they may be driving too fast. For a system like that to be feasible
you will need comprehensive posted speed limit coverage, which OSM
currently does not have.
On Tue, Sep 9, 2014 at 12:38 PM, Tod Fitch <tod at fitchdesign.com> wrote:
> On Sep 9, 2014, at 10:31 AM, stevea wrote:
> I wonder if 15 mph in a school zone and 25 mph in a residential area are
> some sort of federal standard? The source tag might be useful but not much
> different than other states.
> The federal government doesn't have anything to say about speed limits (in
> states), as the US Constitution leaves such things to the states. An
> exception is on federal land, such as national parks or BLM land, where
> specific parts of the US Code regarding speed limits DO apply. This is why
> you can get a speeding or parking ticket at Yosemite, but you won't deal
> with California to fight it or pay the fine: Yosemite is not part of
> California. Surrounded by it, yes. Part of it, no.
> My GPS (a still-tough Garmin 60 CSx) does an excellent job of calculating
> Estimated Time of Arrival (ETA) when routing. It does so by assuming speed
> limits for all road segments in the current route and guesses I'll travel
> at those speeds. This is done without assigning a speed limit to each and
> every road segment, instead implementing a simple table lookup (freeway:
> assume 65 MPH, residential: assume 25 MPH...). This is a highly efficient
> solution that keeps the data light and the calculation short and simple, so
> it quickly produces an accurate ETA result.
> Though I don't find incorrect (or offensive) the suggestion of tagging* prima
> facie* limits with the tagging syntax specified, I find speed limit
> tagging to be most useful where there are posted signs with a specific
> number. That's just me, though.
> The DVD map based nav system in my 10 year old car makes the same
> assumption about speeds based on its three classes of roads. It had wildly
> incorrect times until I configured it for California speeds. Now it does a
> reasonable job at estimating travel times on its selected route if I am in
> California. But typical rural speed freeway speeds vary considerably from
> state to state and for longer trips the times are still quite a bit off.
> Assumed values are not as good as actual values. (And my car nav system
> always tries for the slow way to the southern SF bay are apparently
> ignoring that CA 152 exists until I actually make the turn on to it from
> I-5 when it realizes that my way is both shorter and faster than the route
> it picked, so it has other problems.)
> A while back I suggested that prima facie speed limits tags be put the
> boundary area/relation for administrative areas. So the relation for
> California could specify something like "prima_facie:maxspeed:motorway=65
> MPH". This would be a simple to implement scheme with relatively few
> entries in OSM and be easy to update in the rare situation where the law
> changes. It could also allow for city or county rules to be specified.
> Routing algorithms could discover the appropriate assumed speeds for any
> class of road in an area buy looking at the enclosing administrative
> boundaries and the tags on those boundaries.
> But that suggestion was met with a pretty cold response by the tagging
> mail list. Instead a multitude of roads in Europe and elsewhere are being
> tagged with the prima facie speeds and having a source:maxspeed tag to
> explain it. My suggestion in this thread will contributed to that so I
> admit it is not my first choice.
> Talk-us mailing list
> Talk-us at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us