Re: [OSRM-talk] Bicycle routing, crossing large roads: how to get information on the roads crossed

[Spencer Gardner]

Unfortunately, I don't have a good solution to offer, but I wanted to add
my two cents. I did a ton of research on this exact problem a couple of
years ago and virtually none of the open source routing platforms I came
across were properly equipped to handle it. It seems to be an issue that
only bicycle-oriented folks think about. The solution for my problem was to
implement in pgRouting where I can do additional processing to assign costs
as you've described. It's not the way I'd prefer to do it but until bicycle
routing becomes more sophisticated on other routing platforms that's what
I've settled on.

I don't have the technical expertise to contribute code to OSRM but I'd be
more than happy to share my experience with bicycle network planning with
anyone looking to improve OSRM's handling of bicycles on this and other
questions.

Spencer

On Mon, Dec 23, 2019 at 6:35 AM Richard Fairhurst 
wrote:

> Jeroen Hook wrote:
>
> Is there another way to find out what type of road(s) I am crossing?
>
>
> I think the easiest solution would be to allow bicycles on your
> highway=primary, but set it to be a restricted access road (or just to have
> a really high cost). That way you’d still call process_turn, but in reality
> the primary road wouldn't be used for routing.
>
> My private cycle.travel fork does something like this in its equivalent
> of process_turn (e.g.
> https://cycle.travel/map?from=51.7546,-1.2612=51.7554,-1.2616), though
> it’s a (pretty extensive) fork of 4.9.x so not directly comparable.
>
> Alternatively, you could do some preprocessing to mark intersections,
> depending on the size of your source data. For a different project I wrote
> https://github.com/systemed/intersector which identifies junctions in an
> .osm.pbf. If you were to patch it to output node IDs, then look up those
> node IDs in process_node, you could assign crossing penalties that way.
>
> Richard
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-us] Bicycle infrastructure

[Spencer Gardner]

You'll probably want to include cycleway=buffered_lane as well. It's
undocumented but used pretty frequently in some places. PeopleForBikes has
published a list of OSM tags they use in their Bike Network Analysis tool
(disclosure: I worked on this project). You can download the list here:
https://s3.amazonaws.com/pfb-public-documents/OSM.Tags.xlsx

You might also find some other useful resources via the methodology page:
https://bna.peopleforbikes.org/#/methodology

On Wed, Oct 4, 2017 at 1:38 PM, Mike N  wrote:

> I'm not sure about the syntax, but there's
>
>   cycleway=shared_lane   (for sharrows)
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] People For Bikes Connectivity Tool

[Spencer Gardner]

>
> This looks great. It would be good to share your recipe (as per "fully
> transparent set of calculations") so that others can suggest improvements,
> and so that bike routing tools can make maximum use of the data you're
> encouraging people to collect for OSM.
>

Ah yes. Forgot to specify that the tool will be released under an open
source license (MIT, I believe but not certain). Not sure when the code
will be made available but I would guess sometime within the next month.

In case you're curious, we make heavy use of PostGIS, osm2pgsql, and
osm2pgrouting. The whole thing runs on an Ubuntu VM with Vagrant. As you
might expect, large cities are computationally expensive and might set you
back several days running the calcs on a consumer desktop. For home use it
works perfectly fine on the scale of a neighborhood or small-to-medium
sized city.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] People For Bikes Connectivity Tool

[Spencer Gardner]

On Thu, Apr 6, 2017 at 6:09 PM, Clifford Snow 
wrote:

>
> Spencer,
> What cities have shown interest into updating OSM? There may be local
> mappers that would be interested in help the city add to OSM.
>
>
Good question. People for Bikes is planning to run scores for up to 300
cities, which will likely include all major US cities. There's a short
application process for cities (details
). I
can't make any promises but I can probably get contact info for any city
people who have submitted applications with People for Bikes. If you're
interested in working with your city feel free to contact me off-list and
I'll see if I can get details for your city.


> On another thread, do you plan to submit a presentation to this year's
> SOTM-US conference?
>

The thought had crossed my mind. People for Bikes is based in Boulder so it
would make a lot of sense. Thanks for the reminder to check into details
re: submission deadlines.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] People For Bikes Connectivity Tool

[Spencer Gardner]

Hi all. I wanted to notify the community about an upcoming website that
makes heavy use of OSM for rating the quality of the bicycle network in
communities around the USA. The website is being developed by People for
Bikes as part of their Places for Bikes
<http://www.peopleforbikes.org/placesforbikes/pages/about-placesforbikes>
and Big Jump
<http://www.peopleforbikes.org/blog/entry/here-are-the-10-leading-cites-poised-for-a-big-jump-in-biking>
programs.

Here's a blog post about the tool:
http://www.peopleforbikes.org/blog/entry/who-does-your-bike-network-serve-get-free-answers-from-a-new-tool

The tool uses OSM for routing and uses information such as speed limits,
number of vehicle lanes, the presence and type of bicycle facilities, and
the types of treatments at intersections/crossings for determining whether
a particular way is acceptable for bicycling or not. In places where data
is limited, assumptions are made based largely on the road classification.

People for Bikes has been encouraging cities to make sure their bike
networks are up-to-date in OSM so you may see some activity in your
respective cities. We have produced some training materials to introduce
users to tagging bicycle facilities in OSM (and referring them to LearnOSM
for more general training).

I'd invite anyone interested in bicycling to work on OSM bicycle tagging
within their own community in the coming weeks. We will be beta testing
scores in some cities at the end of this month. A final run of scoring will
occur at the end of May.

I've been heavily involved in the development of the tool and am happy to
answer any OSM-related questions.

Regards,
Spencer Gardner
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] greenways tagging

[Spencer Gardner]

I agree that OSM tags related to bicycle infrastructure could be expanded.
However, I'm not convinced many of the situations raised in this discussion
can't already be addressed by existing tags (e.g. vehicle=no for a street
with no vehicular access).

Bike boulevards are especially tricky, since their design and
implementation can vary significantly. It would seem more appropriate to
treat them as a relation, since it's effectively a branded corridor which
may or may not have any special engineering treatments. Madison, WI, for
example, has several bike boulevards that are regular streets with
virtually no special design but they have blue signs with a bicycle symbol.
Some (myself included) would argue that these are no more or less useful to
a bicyclist than a regular residential street, so giving them special
treatment in OSM would seem misleading. Better to tag the actual design
features (crossing islands, access restrictions) than to rely on a vague
concept.


On Fri, Mar 24, 2017 at 11:42 AM, Mike N  wrote:

> I have tagged 2 local living_streets that don't quite meet the strict
> European definition, but they are blocked by bollards, which are rarely
> dropped to allow service vehicles to enter.
>
> On 3/23/2017 9:27 PM, Nathaniel V. Kelso wrote:
>
>> The existing OSM wiki documented tags for bicycle needs to grow a bit to
>> describe things like bike boulevards, greenwaves, and buffered_lanes.
>>
>
>  Thanks for the detail - I also get the feeling that OSM tags should be
> expanded to cover more variations  of bike infrastructure.
>
>
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] RRFB Tag

[Spencer Gardner]

Perhaps I can answer my own question. I hadn't noticed the
flashing_lights=yes suggestion in the wiki. So does a scheme like this make
sense?:
crossing=uncontrolled
flashing_lights=yes
button_operated=yes

On Wed, Feb 22, 2017 at 4:18 PM, Spencer Gardner <spencergard...@gmail.com>
wrote:

> Is there a conventional way to tag Rectangular Rapid Flash Beacons
> <https://safety.fhwa.dot.gov/intersection/conventional/unsignalized/tech_sum/fhwasa09009/>?
> These are effectively crosswalks with additional signage and user-activated
> flashing yellow lights. The crossing=traffic_signals tag seems more akin to
> a HAWK <https://safety.fhwa.dot.gov/ped_bike/tools_solve/fhwasa14014/>
> signal (similar to European "Pelican") and doesn't really work for RRFBs
> since there's no real traffic control.
>
> Spencer
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] RRFB Tag

[Spencer Gardner]

Is there a conventional way to tag Rectangular Rapid Flash Beacons
?
These are effectively crosswalks with additional signage and user-activated
flashing yellow lights. The crossing=traffic_signals tag seems more akin to
a HAWK 
signal (similar to European "Pelican") and doesn't really work for RRFBs
since there's no real traffic control.

Spencer
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Combined parking/bike lanes

[Spencer Gardner]

Good catch on the MUTCD language. I'm not opposed to tagging with a bike
lane and a parking lane, but then what should be used as the assumed width
of the bike lane? This has direct relevance for my application, where I
need to know how wide a bike lane is. Would you suggest an assumed width
for parking and then subtract from the total to arrive at the operable
space for people on bicycles?

On Thu, Feb 16, 2017 at 10:06 AM, Paul Johnson <ba...@ursamundi.org> wrote:

> On Fri, Feb 3, 2017 at 12:00 PM, Spencer Gardner <spencergard...@gmail.com
> > wrote:
>
>> The problem I see with that approach is that it doesn't distinguish
>> between a road with a striped bike lane next to a parking lane and a road
>> with the combined lane.
>>
>
> I'm not sure that's a distinction that makes a difference.
>
>
>>  is considered a different facility from an engineering perspective.
>>
>
> Is this something that's California specific?  I know California does a
> lot of things that noplace else in the US does because the benefit of
> federal highway funds outweighs the costs of implementing them for
> California, but this would be splitting hairs going a long way back.
> Especially since California was one of the major relevant jurisdictions for
> getting bicycle facilities in to the federal standards back in the '70s.
>
> USMUTCD 2009 rev 1 and 2 inclusive
> <https://mutcd.fhwa.dot.gov/pdfs/2009r1r2/mutcd2009r1r2edition.pdf> (the
> current edition of the federal standards) seems to suggest it's not a
> different kind of facility.  Here's what appears to be the relevant parts:
>
> Section 3B.07 Warrants for Use of Edge Lines, line 6: If a bicycle lane is
> marked on the outside portion of the traveled way, the edge line that would
> mark the outside edge of the bicycle lane may be omitted.
>
> I read that as "It should have an edge line, but it doesn't have to have
> an edge line".
>
> The only other thing that I could see someone construing a situation like
> this with no edge line as is a "shared lane", but Section 9C.07 Shared Lane
> Marking line 3 specifically says "03 Shared Lane Markings shall not be used
> on shoulders or in designated bicycle lanes."  So that's not the case, plus
> it's lacking the "Corporal Bicycle" style shared lane marking in Figure
> 9C-9, so it's not a shared lane.
>
> I'd say "Pretend there's an edge line between the shoulder and the bike
> lane" since that's what it is in practice.  This is up there with being
> regionally idiomatic in leaving off markings that aren't strictly required,
> like crosswalk lines and stop bars at signalized intersections with
> signalized crosswalks in my neck of the woods.  Are they marked on the
> ground?  No.  Is it still highway=traffic_signals with
> crossing=traffic_signals where the crosswalks functionally exist?  Yes.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Combined parking/bike lanes

[Spencer Gardner]

No. That's not a mistake. My city uses this as a standard treatment in a
number of locations. And as was mentioned earlier this facility type is
also common in California.

On Thu, Feb 16, 2017 at 9:49 AM, Paul Johnson <ba...@ursamundi.org> wrote:

> On Fri, Feb 3, 2017 at 11:11 AM, Spencer Gardner <spencergard...@gmail.com
> > wrote:
>
>> Hi all. Has anyone worked out a good tagging scheme for combined
>> bike/parking lanes? I'm not sure how common they are elsewhere but there
>> are a number of such facilities in my city.
>>
>> For reference, you can see an example here:
>> https://www.mapillary.com/app/?lat=43.06056159=-89.45121
>> 134=17=XByvWxyrk9quLK-noyoB5g=photo=mapbox_streets
>> Notice the bike lane sign above the speed limit sign and the cars parked
>> on the side. These are also accompanied with pavement markings indicating
>> it is a bicycle facility. In effect it's like a regular bike lane next to a
>> parking lane, but there's no stripe to separate the two.
>>
>
> I think they just forgot to put the shoulder line down.
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] tagging rumble-strip-separated road shoulders

[Spencer Gardner]

shoulder(left/right)=yes
shoulder:(left/right):rumble_strip=yes

Would make sense to me.

Just a side note that rumble strips are decidedly not better for cyclists
if the shoulder is narrow enough that the cyclist is left with insufficient
space to navigate without riding over them. It might be good to note the
shoulder width in such cases.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Combined parking/bike lanes

[Spencer Gardner]

The problem I see with that approach is that it doesn't distinguish between
a road with a striped bike lane next to a parking lane and a road with the
combined lane. In terms of the distribution of space on the road it might
be the same but it's different psychologically and is considered a
different facility from an engineering perspective.

On Fri, Feb 3, 2017 at 11:44 AM, David Chiles <dwalt...@gmail.com> wrote:

>
> Would the following tags work?
>
> parking:lane:(right/left) = parallel
> cycleway:(left/right) = lane
>
> https://wiki.openstreetmap.org/wiki/Key:parking:lane
> https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dlane
>
> On Fri, Feb 3, 2017 at 9:11 AM, Spencer Gardner <spencergard...@gmail.com>
> wrote:
>
>> Hi all. Has anyone worked out a good tagging scheme for combined
>> bike/parking lanes? I'm not sure how common they are elsewhere but there
>> are a number of such facilities in my city.
>>
>> For reference, you can see an example here:
>> https://www.mapillary.com/app/?lat=43.06056159=-89.45121
>> 134=17=XByvWxyrk9quLK-noyoB5g=photo=mapbox_streets
>> Notice the bike lane sign above the speed limit sign and the cars parked
>> on the side. These are also accompanied with pavement markings indicating
>> it is a bicycle facility. In effect it's like a regular bike lane next to a
>> parking lane, but there's no stripe to separate the two.
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Combined parking/bike lanes

[Spencer Gardner]

Hi all. Has anyone worked out a good tagging scheme for combined
bike/parking lanes? I'm not sure how common they are elsewhere but there
are a number of such facilities in my city.

For reference, you can see an example here:
https://www.mapillary.com/app/?lat=43.06056159=-89.45121134=17=XByvWxyrk9quLK-noyoB5g=photo=mapbox_streets
Notice the bike lane sign above the speed limit sign and the cars parked on
the side. These are also accompanied with pavement markings indicating it
is a bicycle facility. In effect it's like a regular bike lane next to a
parking lane, but there's no stripe to separate the two.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Center Turn Lanes/Auxiliary Lanes

[Spencer Gardner]

I've been researching the way auxiliary lanes (right/left turn, etc.) are
tagged in OSM but I can't tell if there's an accepted standard for handling
these. There are a number of competing proposals for different scenarios
and nothing seems to cover all cases.


Key:turn  appears to be pretty
widely used but I don't see anything in there about the commonly used center
turn lane 
here in the US.

So I guess I have two questions:

   1. Is there an accepted standard for handling auxiliary lanes?
   2. Is there a common way for US mappers to tag the center turn lane?

Thanks,
Spencer
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSRM-talk] Per-Direction Node Restrictions

[Spencer Gardner]

Come to think of it, it would probably be simpler to just make each node
aware of the "highest" order of highway. Knowing that, it would work to
read that info for each constituent way and determine priority based on if
the way's order matches the node's order..

On Thu, Oct 6, 2016 at 1:29 AM, Daniel Hofmann <hofm...@mapbox.com> wrote:

> This is not planned at the moment, since all the profiles know about are
> tags. All additional processing has to happen internally in the C++ code,
>  and that's exactly why priority roads / give ways / stop signs are a bit
> ugly to implement. Sorry.
>
> On Thu, Oct 6, 2016 at 12:19 AM, Spencer Gardner <spencergard...@gmail.com
> > wrote:
>
>> I started working on this in https://github.com/Project-OSR
>>> M/osrm-backend/pull/3009 but it won't be a quick change in the
>>> profiles, for sure.
>>>
>>> Cheers,
>>> Daniel J H
>>>
>>>
>> Thanks. Will your changes also allow me to read the tags of other roads
>> approaching the same node? That's the important piece for my purposes. A
>> priority_road tag is likely to be unreliable in the US since it has no
>> legal status, so I need to make some assumptions about priority based on
>> the various highway tags of the incoming ways.
>>
>> ___
>> OSRM-talk mailing list
>> OSRM-talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osrm-talk
>>
>>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Per-Direction Node Restrictions

[Spencer Gardner]

>
> I started working on this in https://github.com/Project-
> OSRM/osrm-backend/pull/3009 but it won't be a quick change in the
> profiles, for sure.
>
> Cheers,
> Daniel J H
>
>
Thanks. Will your changes also allow me to read the tags of other roads
approaching the same node? That's the important piece for my purposes. A
priority_road tag is likely to be unreliable in the US since it has no
legal status, so I need to make some assumptions about priority based on
the various highway tags of the incoming ways.
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSRM-talk] Per-Direction Node Restrictions

[Spencer Gardner]

On Tue, Sep 27, 2016 at 5:11 AM, Daniel Hofmann  wrote:

> When you say "should be avoided" you mean completely discarding a way
> going over a specific node in a single direction?
> In that case, we support turn restrictions in the form of
> `fromWay,viaNode,toWay` you could try.
>
> As in: `no_turn, fromResidential, viaHighwayNode, toResidential`
>
> (Relevant: via-way restrictions: https://github.com/Project-
> OSRM/osrm-backend/issues/2681)
>
> Cheers,
> Daniel J H
>
>
I had considered turn restrictions, but I was hoping for something a little
more generalizable so that I don't have to identify specific nodes and ways
in the config. For example, I'd like to tell the router to avoid a node
representing the intersection of a residential way and a primary way IF the
route is using the residential way. But I'd like to avoid having to
identify all such instances via turn restrictions.

I could imagine something like the following pseudo code:

function crossing_penalty(entering_way, crossing_way, node)
local entering_highway = way:get_value_by_key("highway")
local crossing_highway = way:get_value_by_key("highway")
-- get traffic signals
local tag = node:get_value_by_key("highway")
if tag and "traffic_signals" == tag then
traffic_lights = true
end

if entering_highway == "residential" and crossing_highway == "primary"
and not traffic_lights then:
crossing_penalty = some_large_number
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSRM-talk] Per-Direction Node Restrictions

[Spencer Gardner]

Is there currently a way to treat a node differently based on the way that
is used to access it? I think what I'm after is something similar to the
discussion here:
https://github.com/Project-OSRM/osrm-backend/issues/2652

My issue is specific to bicycle routing, though. There are instances where
a node should be avoided on a residential highway because it crosses a high
speed or heavily traveled primary highway. However, the same node is an
acceptable crossing for a cyclist traveling along the primary highway since
they have the right of way.

Is this possible currently? It doesn't seem like the existing bicycle
profile accounts for it.
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[Talk-us] MassGIS Road Import - Lanes

[Spencer Gardner]

Is anyone on here familiar with the process that was used to upload MassGIS
road data for the state of Massachusetts? I'm noticing a lot of incorrect
lane information on one-way residential streets and wondering if the bulk
import process could be the cause. I'd love to hear if anyone else has come
across this.

For reference, see http://www.openstreetmap.org/way/8615602

I haven't scoured the rest of the state, but Cambridge is riddled with
one-way residential streets that all have lanes=2 when there's clearly only
a single travel lane.

Thanks
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us