[OSM-talk] Highway=trunk : harmonization between countries ?

[Greg Troxel]

Richard <ricoz.osm at gmail.com> writes:

> On Tue, Aug 22, 2017 at 08:09:25PM -0400, Greg Troxel wrote:
>> 
>> john whelan <jwhelan0112 at gmail.com> writes:
>> 
>
>> > As someone who lives in a city street with one school in the middle and one
>> > at either end posted at 40 km/h with an average traffic speed of 60 km/h
>> > and over 100 km/h from some high school kids driving to and from school I
>> > would prefer it if traffic stuck to the posted speed limits.  Cars running
>> > across front lawns to avoid collisions are not unknown.
>> 
>> That sounds crazy, but I would guess that it isn't the people actually
>> paying attention going 48 that are the real issue!  But in all
>> seriousness, that sounds like an actual problem, not an OSM
>> representation problem.
>
> it would become an OSM problem if someone decides to tag this road 
> with maxspeed:practical=60. A router may then decide to route you 
> to this route instead of some alternative that would be much faster 
> for people who decide to respect speed limits at schools.

That's a fair point.  But, I wonder how waze and apple maps handle this.
I suppose one could find the dividing point experimentally and infer it.

In the end, though, if a router is actually faster when driving with the
flow of trafic, I don't see it as OSM's place to make it not seem that
way, and the above case really seems to need the attention of the
authorities.

> In cities I believe that maxspeed:practical can be usefull foremost
> in situations where traffic flow is for whichever reason much slower 
> than could be expected for an average city road tagged identically.
> That is because on average other factors like traffic lights, left
> turns, yielding etc determine the travelling speed much more then
> driving speed. None of those OSM and OsmAnd is particularly good at..

Agreed, mostly, but lights should be modeled by routers and if they
aren't, it isn't good to bury it in something else.  But for things that
aren't inferrable from tags I agree.

> Also consider the effect of the majority and other statistical effects. 
> If in Montana or wherever it is common to drive 20-40 miles faster 
> than posted on most rural roads than the router will probably do correct 
> routing decissions on average even without maxspeed:practical. 

You have a really good point and I agree that it's complicated.  But at
least around me, people drive a little bit faster than posted in most
places, and a lot on some roads.  Basically the speed limits are
sometimes correct (85% rule) and sometimes very much under.

I think your point about errors between (whatever tag, including
maxspeed) and reality being an error is valid even now, but I agree we
need to not make things much worse.

So I'm seeing a systematic bias (in fastest time mode) to slower,
shorter routes.

I should get some actual data and compare reality to OSM more
systematically.

> Tagging some roads with maxspeed:practical would have only the 
> effect to distort routing decissions. You owwould have to tag the 
> large majority of roads with this tag to achieve a similar effect 
> like not having it on any of those roads.h

That's a fair point in theory.  It's a good question how many roads need
to be adjusted to have things make sense.  Around me, adjusting the
interstates and route 2 would help vastly.

Maybe we need a "maxspeed:speed_limit_ought_to_be".  Really I mean
"people drive like the speed limit is X, and that's ok".  I'm sort of
joking, but will ponder.

I might experiment with a few roads.  But people should not worry that
I'll do anything large scale (more than 30 minutes in JOSM, the unit of
editing :-) -- I agree this is complicated and not resolved.  I view it
as an eventual step towards better routing.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: <http://lists.openstreetmap.org/pipermail/talk/attachments/20170824/10e8a0e5/attachment.sig>