Open hulsiejames opened 2 years ago
Specifically, if a feature is marked as access="no", but with the addition of bicycle="yes" (also, foot="yes") should this be included in osmextracts (and others) final walking/cycling network?
I think so yes.
I have found 20 features that maybe could be included in the definition of a cycling network - but due to
access="no"
these are excluded from the osmextract network despite containingbicycle="yes"
&foot="yes"
tags.
This is really useful info and yes I see this as an issue in {osmextract}. Feel free to open an issue.
So I guess we need to come up with a better set of rules?
So I guess we need to come up with a better set of rules?
I think so potentially - I've had a little play this morning but think I will need to read up on some SQL queries and try this afternoon.
Working on LTN compliance and presence of lighting at this moment!
Hi @hulsiejames!
Specifically, if a feature is marked as access="no", but with the addition of bicycle="yes" (also, foot="yes") should this be included in osmextracts (and others) final walking/cycling network?
I just checked the OSM wiki docs (https://wiki.openstreetmap.org/wiki/Key:access#Transport_mode_restrictions) and it looks like you are right, those streets should be included. Happy to check the code behind osmextract. However, I'm not sure why you get those discrepancies. I will check your examples as soon as possible (later this week or next week hopefully).
However, I'm not sure why you get those discrepancies.
Me neither! Though, SQL is not my strong point. I will also have a look and see if I can find out the reason for these discrepancies as it could have been a simple mistype by myself - if so, I will update here accordingly.
Quick update on the above - will look into this some more over coming days.
I had thought that by chaning the SQL query from access NOT IN ('private', 'no')
to (access NOT IN ('private', 'no') OR bicycle IN ('yes'))
we only picked up one out of the additional 20 features I had found with my function, due to some dplyr
anti_join and semi_joins
I had performed, along with returning ~4.9k additional features:
(code below taken from details above)
# An additional 4,916 features are reutnred - not what I was expecting!!!
proposed_diff = dplyr::anti_join(as.data.frame(proposed_osmextract_update), as.data.frame(function_output))
# of the additional 4,916 features returned, only 1 is from the 20 additional features I had found
union_of_proposed = dplyr::semi_join(as.data.frame(proposed_osmextract_update), as.data.frame(function_output_not_in_osmextract_cycle))
However, it seems that all of the 20 additional features I had found are actually included in the proposed osmextract SQL query, see:
# The osm_id's of the additional 20 features I had found with my own function
ids = function_output_not_in_osmextract_cycle$osm_id
# Check if these ids are acutally included within the proposed osmextract SQL query
ids %in% proposed_osmextract_update$osm_id
[1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE
As can be seen - the ids of the additional features are indeed caught by the proposed SQL filtering - I must have made some mistake when using the dplyr filtering joins.
To make sure this was behaving as expected, I added a random id as a sense check and it was detected as false:
> ids = c(ids, "111222333")
> ids %in% proposed_osmextract_update$osm_id
[1] TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE TRUE FALSE
Again, for reference, proposed_osmextract_update
is a network defined with the following query:
proposed_osmextract_update = oe_get(
place = "Leeds",
provider = "bbbike",
layer = "lines",
#layer = "lines",
extra_tags = c("access", "bicycle", "service"),
force_download = TRUE,
never_skip_vectortranslate = TRUE,
force_vectortranslate = TRUE,
vectortranslate_options = c(
"-where", "
(highway IS NOT NULL)
AND
(highway NOT IN (
'abandoned', 'bus_guideway', 'byway', 'construction', 'corridor', 'elevator',
'fixme', 'escalator', 'gallop', 'historic', 'no', 'planned', 'platform',
'proposed', 'raceway', 'steps'
))
AND
(highway NOT IN ('motorway', 'motorway_link', 'footway', 'bridleway',
'pedestrian') OR bicycle IN ('yes', 'designated', 'permissive', 'destination')
)
AND
(access NOT IN ('private', 'no') OR bicycle IN ('yes'))
AND
(bicycle NOT IN ('private', 'no', 'use_sidepath', 'restricted'))
AND
(service NOT ILIKE 'private%')"
),
quiet = FALSE
)
I have tried OR bicycle IN ('yes'))
& OR bicycle = 'yes'
interchangeably with identical network dimensions returned (98,965 features)
Next, I need to look at these additional returned features (~4.9k) by this change and see if they are all appropriate for a cycling network. For those that are not, what additional SQL filtering is needed to exclude them from the network.
Note: because we're writing R code we could also import the maximum number of features and do the filtering in R.
Note: because we're writing R code we could also import the maximum number of features and do the filtering in R.
Provided there are no performance motives for applying the SQL filtering prior to loading into R, I think this could be a good idea.
There are performance motives but they are not the primary ones, especially when we're talking about a small fraction of the total.
Please see the script contained within details which replicates this analysis!
Hi @Robinlovelace @Agila5 - I have a question on the use of access="no" and its filtering within osmextract.
Specifically, if a feature is marked as access="no", but with the addition of bicycle="yes" (also, foot="yes") should this be included in osmextracts (and others) final walking/cycling network? Full context is discussed below, but see the exaples at the bottom for a quick visualisation.
I've been working on a function that defines a cycling network mimicing the filtering of the the oe_get_netwrok function
network = oe_get_network(mode="cycling")
SQL query.I have found 20 features that maybe could be included in the definition of a cycling network - but due to
access="no"
these are excluded from the osmextract network despite containingbicycle="yes"
&foot="yes"
tags.To find these 20 features I dowloaded some network
data
for Leeds withoe_get(place="Leeds")
- I then mimicked the filtering ofoe_get_network(mode=cycling)
within my function,oi_active_cycle
, and comapred the two outputs which theoretically should be the same, however my function has detected these 20 additional features, stored in the variablefunction_output_not_in_osmextract_cycle
see full script in detailsUsing this
data
, I have created a network identical to theosmextract::oe_get_network(mode = "cycling")
by applying the following manual filtering from documentation:Next, using my new function, I go through the data and create a new column,
oi_active_cycle
, for each way in the network, if this way would be in the osmextrct cycling network,oi_active_travel
will be "yes". This filtering is done usingdplyr::case_when()
Note that below,
osm_sf
will bedata
defined above:Example 1, 2 & 3 - Carriage Drive Carriage Drive : W689484794 - Street view image 74095066 - Street view 236322053 Contains Tags:
access="no"
bicycle="yes"
foot="yes"
(some other tags too but not useful in this context) A way that is used to access Roundhay Park in Leeds and is used by cyclists and pedestrians, hence thebicycle="yes"
&foot="yes"
tags.I am not sure if the access tag has been used correctly in this instance, the general public are expected to use this way to access the park, yet the park will be (I assume) privately owned thus
access="no"
would technically be correct?Similar to the discussion in #32 by Greta proposing to use
acces NOT IN ("no", "private") OR foot IN "(yes")
I propose we use something similar but for thebicycle="yes"
tag, in SQL query this could beaccess NOT IN ('private', 'no') OR bicycle IN ('yes', 'designated', 'permissive', 'destination')
, or just"yes"
, rather than just `access NOT IN ('private', 'no')On the above (wrote an hour ago) - I have just tried updating the SQL query to:
That is, I changed
access NOT IN ('private', 'no')
to(access NOT IN ('private', 'no') OR bicycle IN ('yes'))
I expected this to return a network that contained the additioanl 20 features I had found, instead this returned an additional 4,916 features- not what I expected!!! Additionally, out of those additional (4,916) features, only 1 out of the initial 20 additional features have are included!
See the bottom of the script within details for clarification. Running this script will show all variable dimensions and allow you to view them. If you do not have access to a computer here are my current variable dimensions:
Apologies if this does not make sense- the heat is getting to me today! Feel free to ask me any questions and I will try and reply as soon as possible. Cheers