[OSM-talk] Important Maintenance shortly

[Grant Slater]

Hi All,

OpenStreetMap website + API will be read-only midday to 1pm (UTC/GMT)
later today for important hardware maintenance. Apologies for the
short notice.

Mappers will not be able to save map updates during this maintenance window.

For status updates during the maintenance window please visit
http://irc.openstreetmap.org in the #osm-dev channel.

Kind regards,
Grant
Part of the OpenStreetMap operations team.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Announce] Important Maintenance shortly

[Ruben Maes]

To view this in your own time zone, you can visit:
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+website+and+API+down&iso=20150727T12&p1=1440&ah=1

2015-07-27 13:21 GMT+02:00 Grant Slater :
> Hi All,
>
> OpenStreetMap website + API will be read-only midday to 1pm (UTC/GMT)
> later today for important hardware maintenance. Apologies for the
> short notice.
>
> Mappers will not be able to save map updates during this maintenance window.
>
> For status updates during the maintenance window please visit
> http://irc.openstreetmap.org in the #osm-dev channel.
>
> Kind regards,
> Grant
> Part of the OpenStreetMap operations team.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Announce] Important Maintenance shortly

[Ruben Maes]

Sorry, of course that should have been "read-only" instead of down.
https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+website+and+API+read-only&iso=20150727T12&p1=1440&ah=1

2015-07-27 13:28 GMT+02:00 Ruben Maes :
> To view this in your own time zone, you can visit:
> https://www.timeanddate.com/worldclock/fixedtime.html?msg=OSM+website+and+API+down&iso=20150727T12&p1=1440&ah=1
>
> 2015-07-27 13:21 GMT+02:00 Grant Slater :
>> Hi All,
>>
>> OpenStreetMap website + API will be read-only midday to 1pm (UTC/GMT)
>> later today for important hardware maintenance. Apologies for the
>> short notice.
>>
>> Mappers will not be able to save map updates during this maintenance window.
>>
>> For status updates during the maintenance window please visit
>> http://irc.openstreetmap.org in the #osm-dev channel.
>>
>> Kind regards,
>> Grant
>> Part of the OpenStreetMap operations team.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Am I mapping this wrong, or should the router be fixed for this?

[James Mast]

I've been normally mapping slip lanes as '_link' highways at intersections 
since the beginning.  However, as most fellow US mappers know, they almost 
never have 'speed limits' posted for them, and that seems to help cause 
problems in some routing programs when they give those slip lanes a speed limit 
higher than the main highway.

Anyways, I've been using OSMAnd recently for occasional offline routing on my 
tablet and have come across weird routing (I'd like to call them 'bugs') at 
some intersections that have 3+ traffic lights nodes at them because of the 
roads being divided.  Here, OSMAnd routes me onto a slip lane, makes a U-Turn 
on the side road, and then continues the across the main road to accomplish 
what a simple 'left turn' could have done [1], all to avoid '1' traffic light 
node.  So, I go report the 'bug' on the OSMAnd Google group [2], and then 
somebody forwards it to the GitHub site [3].

In the response I get back on GitHub, one of the maintainers of OSMAnd says 
it's a 'map data' issue and closes it.  Claims that in the 'maneuver', since it 
avoids an extra traffic light node, it's the shortest route, even though it 
does that funky U-Turn.  Say what?!  I mean, honestly, if both MapQuest Open & 
OSMR can do that left turn 'normally' without needing to make a funky U-Turn, 
something has to be wrong in OSMAnd, right??  Sure, there isn't a 'NO U-Turn' 
sign posted for this maneuver, but still, the routing engine shouldn't be 
suggesting it since there isn't a 'NO Left Turn' relation there preventing the 
left turn from McKnight SB to Siebert EB.

So, that leads me to my question.  Does anybody think I've tagged the 
intersection incorrectly?  This is how I've been tagging intersections like 
this from since the start, and I know most other US mappers have been doing the 
same.  Or should I start adding 'false' U-Turn restrictions to prevent the 
routing bugs and then be called out as 'tagging for the router', or even maybe 
start putting traffic light nodes at the stop lines for intersections that have 
both roads divided (and just leave simple one-node intersections as-is)?

I'm very curious to see what others have to say about this to see how I'll move 
forward when I map in the future.  Also, don't hesitate to respond at the 
Google Group post or the GitHub one too as I get the e-mail notifications from 
them as well.

-James



[1] - (MapQuest routing, OSMAnd suggestion in [2] link) - 
https://www.openstreetmap.org/directions?engine=mapquest_car&route=40.53204%2C-80.01073%3B40.53002%2C-80.00614
 
[2] - https://groups.google.com/forum/#!topic/osmand/XJ-HVOHhKEM 
[3] - https://github.com/osmandapp/Osmand/issues/1501 
  ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Talk-us] Am I mapping this wrong, or should the router be fixed for this?

[Mike Thompson]

In reality there is only one set of stop lights there, correct? In other
words, if one were headed south on McKnight Road turning east on Seibert,
one would not have to stop (assuming red lights) three different times.

1) A routing engine should have some heuristics to interpret the three (in
this case) nodes tagged "highway=traffic_signals" as one.

2) There should be some cost in a routing engine for making a u-turn so as
to discourage such routes even if there was an extra set of signals. Making
a u-turn does take time (one can not go from the posted speed limit in one
direction to the posted speed limit in the other direction instantly). The
presence of other traffic in the opposing directly would add further to the
time needed to make a u-turn as one would have to wait for an opening.

Mike

On Mon, Jul 27, 2015 at 9:58 AM, James Mast 
wrote:

> I've been normally mapping slip lanes as '_link' highways at intersections
> since the beginning.  However, as most fellow US mappers know, they almost
> never have 'speed limits' posted for them, and that seems to help cause
> problems in some routing programs when they give those slip lanes a speed
> limit higher than the main highway.
>
> Anyways, I've been using OSMAnd recently for occasional offline routing on
> my tablet and have come across weird routing (I'd like to call them 'bugs')
> at some intersections that have 3+ traffic lights nodes at them because of
> the roads being divided.  Here, OSMAnd routes me onto a slip lane, makes a
> U-Turn on the side road, and then continues the across the main road to
> accomplish what a simple 'left turn' could have done [1], all to avoid '1'
> traffic light node.  So, I go report the 'bug' on the OSMAnd Google group
> [2], and then somebody forwards it to the GitHub site [3].
>
> In the response I get back on GitHub, one of the maintainers of OSMAnd
> says it's a 'map data' issue and closes it.  Claims that in the 'maneuver',
> since it avoids an extra traffic light node, it's the shortest route, even
> though it does that funky U-Turn.  Say what?!  I mean, honestly, if both
> MapQuest Open & OSMR can do that left turn 'normally' without needing to
> make a funky U-Turn, something has to be wrong in OSMAnd, right??  Sure,
> there isn't a 'NO U-Turn' sign posted for this maneuver, but still, the
> routing engine shouldn't be suggesting it since there isn't a 'NO Left
> Turn' relation there preventing the left turn from McKnight SB to Siebert
> EB.
>
> So, that leads me to my question.  Does anybody think I've tagged the
> intersection incorrectly?  This is how I've been tagging intersections like
> this from since the start, and I know most other US mappers have been doing
> the same.  Or should I start adding 'false' U-Turn restrictions to prevent
> the routing bugs and then be called out as 'tagging for the router', or
> even maybe start putting traffic light nodes at the stop lines for
> intersections that have both roads divided (and just leave simple one-node
> intersections as-is)?
>
> I'm very curious to see what others have to say about this to see how I'll
> move forward when I map in the future.  Also, don't hesitate to respond at
> the Google Group post or the GitHub one too as I get the e-mail
> notifications from them as well.
>
> -James
>
>
>
> [1] - (MapQuest routing, OSMAnd suggestion in [2] link) -
> 
> https://www.openstreetmap.org/directions?engine=mapquest_car&route=40.53204%2C-80.01073%3B40.53002%2C-80.00614
> [2] - https://groups.google.com/forum/#!topic/osmand/XJ-HVOHhKEM
> [3] - https://github.com/osmandapp/Osmand/issues/1501
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Am I mapping this wrong, or should the router be fixed for this?

[Maarten Deen]

On 2015-07-27 17:58, James Mast wrote:

I've been normally mapping slip lanes as '_link' highways at
intersections since the beginning.  However, as most fellow US mappers
know, they almost never have 'speed limits' posted for them, and that
seems to help cause problems in some routing programs when they give
those slip lanes a speed limit higher than the main highway.

Anyways, I've been using OSMAnd recently for occasional offline
routing on my tablet and have come across weird routing (I'd like to
call them 'bugs') at some intersections that have 3+ traffic lights
nodes at them because of the roads being divided.  Here, OSMAnd routes
me onto a slip lane, makes a U-Turn on the side road, and then
continues the across the main road to accomplish what a simple 'left
turn' could have done [1], all to avoid '1' traffic light node.  So, I
go report the 'bug' on the OSMAnd Google group [2], and then somebody
forwards it to the GitHub site [3].

In the response I get back on GitHub, one of the maintainers of OSMAnd
says it's a 'map data' issue and closes it.  Claims that in the
'maneuver', since it avoids an extra traffic light node, it's the
shortest route, even though it does that funky U-Turn.  Say what?!  I
mean, honestly, if both MapQuest Open & OSMR can do that left turn
'normally' without needing to make a funky U-Turn, something has to be
wrong in OSMAnd, right??  Sure, there isn't a 'NO U-Turn' sign posted
for this maneuver, but still, the routing engine shouldn't be
suggesting it since there isn't a 'NO Left Turn' relation there
preventing the left turn from McKnight SB to Siebert EB.

So, that leads me to my question.  Does anybody think I've tagged the
intersection incorrectly?  This is how I've been tagging intersections
like this from since the start, and I know most other US mappers have
been doing the same.  Or should I start adding 'false' U-Turn
restrictions to prevent the routing bugs and then be called out as
'tagging for the router', or even maybe start putting traffic light
nodes at the stop lines for intersections that have both roads divided
(and just leave simple one-node intersections as-is)?

I'm very curious to see what others have to say about this to see how
I'll move forward when I map in the future.  Also, don't hesitate to
respond at the Google Group post or the GitHub one too as I get the
e-mail notifications from them as well.

-James

[1] - (MapQuest routing, OSMAnd suggestion in [2] link) -
https://www.openstreetmap.org/directions?engine=mapquest_car&route=40.53204%2C-80.01073%3B40.53002%2C-80.00614
[1]
[2] - https://groups.google.com/forum/#!topic/osmand/XJ-HVOHhKEM
[3] - https://github.com/osmandapp/Osmand/issues/1501


It is a routing problem. No sane person would take that road and it 
should be possible to make an algorithm that does not take that road, 
even with the speed limit missing.
OSRM is flawed the same way in that it will blindly take a highway 
offramp and onramp because it is a few metres shorter, like in example 
[4].


[4] 
http://www.openstreetmap.org/directions?engine=osrm_car&route=51.4740%2C6.0507%3B51.4631%2C6.0584#map=16/51.4686/6.0546


I would not map it differently, I would like to urge router programmers 
to fix these issues in their router. I'm sure it's possible.


Maarten

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] waterway - "routable network" and reservoirs/lakes

[Mike Thompson]

 The wiki states that the linear features representing waterways should
"connect with other linked waterway features to create a routable network."
[1]
In the case where a stream flows into a reservoir , and then a stream (with
the same name) also flows out of that reservoir, should a linear way be
drawn through the reservoir to connect the two streams (the reservoir is
currently represented by its own closed way tagged natural=water,
water=reservoir)?

[1]
https://wiki.openstreetmap.org/wiki/Waterways#Linear_water_features:_rivers.2C_canals.2C_streams_etc

Mike
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] waterway - "routable network" and reservoirs/lakes

[Christoph Hormann]

On Monday 27 July 2015, Mike Thompson wrote:
>  The wiki states that the linear features representing waterways
> should "connect with other linked waterway features to create a
> routable network." [1]
> In the case where a stream flows into a reservoir , and then a stream
> (with the same name) also flows out of that reservoir, should a
> linear way be drawn through the reservoir to connect the two streams
> (the reservoir is currently represented by its own closed way tagged
> natural=water, water=reservoir)?

Yes.

-- 
Christoph Hormann
http://www.imagico.de/

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] waterway - "routable network" and reservoirs/lakes

[Lester Caine]

On 27/07/15 19:56, Christoph Hormann wrote:
>> In the case where a stream flows into a reservoir , and then a stream
>> > (with the same name) also flows out of that reservoir, should a
>> > linear way be drawn through the reservoir to connect the two streams
>> > (the reservoir is currently represented by its own closed way tagged
>> > natural=water, water=reservoir)?

> Yes.

Although a height difference between in and out might indicate a weir or
other obstruction may well indicate that a route is non-navigable? The
outflow from a dam may have the same name, but have no use as a through
route?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] waterway - "routable network" and reservoirs/lakes

[Jochen Topf]

On Mo, Jul 27, 2015 at 08:08:22 +0100, Lester Caine wrote:
> On 27/07/15 19:56, Christoph Hormann wrote:
> >> In the case where a stream flows into a reservoir , and then a stream
> >> > (with the same name) also flows out of that reservoir, should a
> >> > linear way be drawn through the reservoir to connect the two streams
> >> > (the reservoir is currently represented by its own closed way tagged
> >> > natural=water, water=reservoir)?
> 
> > Yes.
> 
> Although a height difference between in and out might indicate a weir or
> other obstruction may well indicate that a route is non-navigable? The
> outflow from a dam may have the same name, but have no use as a through
> route?

This is more about the water flow than about being navigable by a ship.

Jochen
-- 
Jochen Topf  joc...@remote.org  http://www.jochentopf.com/  +49-351-31778688

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] waterway - "routable network" and reservoirs/lakes

[Mike Thompson]

>
> > Although a height difference between in and out might indicate a weir or
> > other obstruction may well indicate that a route is non-navigable? The
> > outflow from a dam may have the same name, but have no use as a through
> > route?
>
> This is more about the water flow than about being navigable by a ship.
>
> I assumed that when the wiki spoke about "routable" it was referring to
the water flow rather than boat/ship/barge traffic.   In any event, a
routing engine for boats could use the presence of a dam or weir (combined
with the absence of a lock) to deduce that ship navigation was not
possible.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] waterway - "routable network" and reservoirs/lakes

[Lester Caine]

On 27/07/15 20:55, Mike Thompson wrote:
> I assumed that when the wiki spoke about "routable" it was referring to
> the water flow rather than boat/ship/barge traffic.   In any event, a
> routing engine for boats could use the presence of a dam or weir
> (combined with the absence of a lock) to deduce that ship navigation was
> not possible. 

'This way used should point in the direction of water flow' is only
applicable to non-tidal flows, and reservoirs may well control water
flow in a way that makes a 'water flow map' somewhat difficult to deduce.

The use of 'routable network' is rather ambiguous, but this is little
different to the problem of routing through other land based open areas
where several waterway features link into an area of open water. The
jury is still out on putting in all the paths through the area, but if
there is a navigable route designated through a water body it should be
drawn, but an imaginary link just showing water flow should not be
necessary? Any routing process should be able to deduce the relation,
there is no need to draw it.

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] waterway - "routable network" and reservoirs/lakes

[Maarten Deen]

On 2015-07-27 23:39, Lester Caine wrote:

On 27/07/15 20:55, Mike Thompson wrote:
I assumed that when the wiki spoke about "routable" it was referring 
to

the water flow rather than boat/ship/barge traffic.   In any event, a
routing engine for boats could use the presence of a dam or weir
(combined with the absence of a lock) to deduce that ship navigation 
was

not possible.


'This way used should point in the direction of water flow' is only
applicable to non-tidal flows, and reservoirs may well control water
flow in a way that makes a 'water flow map' somewhat difficult to 
deduce.


Only if they are entirely artificial. A dam in a river or stream makes 
the direction of water very clear: high to low. Only when there is an 
artificial reservoir with no natural tributary it is not clear.



The use of 'routable network' is rather ambiguous, but this is little
different to the problem of routing through other land based open areas
where several waterway features link into an area of open water. The
jury is still out on putting in all the paths through the area, but if
there is a navigable route designated through a water body it should be
drawn, but an imaginary link just showing water flow should not be
necessary? Any routing process should be able to deduce the relation,
there is no need to draw it.


Causality. Does a water area need a way indicating the direction of 
water? Of is it that when you draw a way through the water area it 
should point in the direction of the water flow.


Maarten




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk