Comments (15)
I added the footway:surface
to the next generation lookups.dat
from brouter.
See discussion in #641
Could you expand on how the linked PR relates to the issue at hand, since the tag mentioned in the issue's title (cycleway:surface
) is nowhere to be found in that PR?
from brouter.
As suggested by rkflx, a fix for the trekking profile could look like this:
- assign ispaved = surface=paved|asphalt|concrete|paving_stones|sett + assign ispaved = or surface=paved|asphalt|concrete|paving_stones|sett \ + cycleway:surface=paved|asphalt|concrete|paving_stones|sett
the same code could be used for the fastbike profile.
from brouter.
As suggested by rkflx, a fix for the trekking profile could look like this
FTR, that's not what I said. I said that this "triggers the correct behaviour" for that particular example, and that "not considering cycleway:surface
[...] should be fixed". I did in no way describe how the actual fix would look like, so don't make it look like I "suggested a fix" that "could look like this".
Also, either properly @-mention my name, or link to the actual comment. Linking my name without actually notifying me makes people question your intentions.
in either BRouter's profiles or in BRouter's tag aliasing
I might be talking nonsense and should probably read the code, but is there a way in BRouter to automatically alias surface
to surface|cycleway:surface
for profiles setting validForBikes
(and surface|footway:surface
for validForFoot
)?
This seems a bit more elegant and could ease profile maintenance compared to having to repeat the whole shebang everywhere each time.
(Ideally such aliasing should be reflected in the emitted messages too, i.e. when a profile has validForBikes
and evaluates surface
, the way's message should say cycleway:surface
if that's what was used for routing.)
If that does not work yet or is too hard to implement, changing the profile as mentioned is probably the second best option.
from brouter.
is there a way in BRouter to automatically alias
surface
tosurface|cycleway:surface
I also have not looked at that part of the code yet, but maybe @afischerdev knows more.
This seems a bit more elegant and could ease profile maintenance
I prefer as little preprocessing as possible, but maybe in this case it indeed would make sense to make an exception?
changing the profile as mentioned is probably the second best option
Yes, it certainly looks tempting, but I wouldn't change it without regression testing.
from brouter.
surface|cycleway:surface
To clarify what I mean by that (in case it wasn't obvious):
cycleway:surface
should be used ifsurface
is missing (and vice versa),- and the more specific
cycleway:surface
should have precedence oversurface
if both are specified.
Essentially provide what is called "tag normalization" in nrenner/brouter-web#460 (also note fixes in nrenner/brouter-web#550 and nrenner/brouter-web#553).
not only for asphalt, obviously
And probably not only for surface
, but for smoothness
too.
That being said, I just discovered another complication with the idea of automatic aliasing:
We'd not only have to look at validForBikes
, but would need to differentiate between a profile wanting to route over the (car) lane part of the highway
or the cycleway part in case of non-mandatory cycleways. I guess we should leave that to profiles, after all, or only apply the aliasing if cycleway:surface
is unambiguous, e.g. if cycleway=*
is unset or for highway=path|track|cycleway
. Sigh.
changing the profile
I wouldn't change it without regression testing.
What particular regressions do you have in mind?
- Something like
surface=<accurate data> cycleway:surface=<incorrect data>
? I doubt this is common, and in any case should be fixed directly in OSM. - Or the case of non-mandatory cycleways? Indeed, here we might want to add another condition depending on the profile's needs (see above). In that sense, the current profile code is not entirely accurate currently, either, since we might classify an asphalt road with a mandatory gravel cycleway as paved, which it is not in reality.
Apart from that I don't see any room for trade-offs or subjective preferences here, as it would be merely about evaluating more accurately what has been mapped.
from brouter.
What particular regressions do you have in mind?
Basically the ones you mentioned above:
- That, for example, a road bike profile might prefer to route over the (car) lane part.
- That, for example,
cycleway:surface=paved
shouldn't overwritesurface=asphalt
.
Plus the ones we probably did not think about it yet.
I just discovered another complication with the idea of automatic aliasing
We would also have to properly consider the oneway logic.
from brouter.
I also have not looked at that part of the code yet, but maybe @afischerdev knows more.
I'm sorry, no. I'll do have a look later on - but will take a few weeks.
And we will need the lookups update #458.
Seeing the weight of the surface value, I could think of ordering the surface
values in the lookups.dat
file.
from brouter.
cycleway:surface=paved
shouldn't overwritesurface=asphalt
I disagree. When the cycleway is mandatory and a patchwork of different paving styles, paved
would be much more accurate than asphalt
, even though the latter might seem more specific at first glance.
Thinking more about this, perhaps we could define aliasing a bit differently (|
meaning "fallback if not existing" as detailed previously, and _
illustrating the tag being an alias):
cycling_surface
as an alias forcycleway:surface|surface
(or possibly even more complex conditions / subtags)walking_surface
as an alias forfootway:surface|surface
(or possibly even more complex conditions / subtags)surface
stays as-is (or could be renamed todriving_surface
)
That way profiles could simply choose what they require (e.g. it would be explicit whether the car lane or a cycleway is meant), while still being less verbose (no repetitions and no extra conditions necessary). Maybe we could even move aliasing to rd5 creation time that way, instead of having to process it dynamically during routing.
Note that it might make sense to be even more generic here, e.g. define a whole class of aliases like A_X
for A:X|X
with A ∈ {cycleway, footway, …}
and X ∈ {surface, smoothness, …}
. Are there any further tags for …
you could think of?
AFAICT from (finally) reading the code, in lookups.dat
we currently only support aliasing like this: tag;001 value1 value2 value3
(where value1
will become an alias for value{1,2,3}
in the expression tag=value1
). This is different from aliasing tags themselves as discussed here. However, there is also generatePseudoTags
which we might be able to extend.
OTOH, it might be too much work for too little gain…
from brouter.
Does this mean all ways have a new cycleway_surface
or footway_surface
tag at the end - when they have a surface tag?
Could be blow up the data source.
The more I look at it, the more I think:
A simple surface
has no place in cycleway:surface
and/or footway:surface
combination.
I followed some ways that are visible in GMap Streetview like this. Visible is the traffic seperation but where is the asphalt?
There are more tags around:
cycleway:both:surface
cycleway:right:surface
cycleway:left:surface
sidewalk:surface
sidewalk:both:surface
sidewalk:right:surface
sidewalk:left:surface
from brouter.
Does this mean all ways have a new
cycleway_surface
orfootway_surface
tag at the end - when they have a surface tag?
We could coalesce all specialized tags into a single tag per use case, so while there would be some duplication (which might be possible to avoid by deferring selected parts of the fallback algorithm to runtime), we could also drop other tags not needed anymore in such a scenario.
Could be blow up the data source.
Whether or not rd5 sizes will be affected is yet to be determined, it's not even clear where/when to do the aliasing yet. Also note that evaluating more complex expressions in profiles comes with quite a sizable performance penalty too, so there is always a space/time trade-off.
In summary, it does not seem trivial to answer a question like "Assuming a cyclist using mandatory cycleways and riding in direction X on way Y, what will the surface there look like?", since only looking at surface
can be incomplete or even misleading, as we've seen.
On the contrary, it can be quite complicated. This brings us back to the original dilemma: Is it reasonable to expect each profile author (which includes advanced users too) to know about and evaluate all of these tag combinations and special conditions, or should we pre-process the complexity into an alias once? Or maybe choose a different approach and extend profile syntax to allow for |
and/or *
in the left side of tag=value
expressions too? Perhaps we should just ask profile authors what they prefer.
Anyway, I'll stop my investigations here for now. Nevertheless I still believe we should probably somehow consider cycleway:surface
for routing. I'll be curious though to watch with which constructive solutions you'll come up with.
from brouter.
I spent an hour trying to find an example (using this overpass query: https://overpass-turbo.eu/s/1zIa) were:
- assign ispaved = surface=paved|asphalt|concrete|paving_stones|sett
+ assign ispaved = or surface=paved|asphalt|concrete|paving_stones|sett \
+ cycleway:surface=paved|asphalt|concrete|paving_stones|sett
would affect the trekking profile routing and only found this one:
- https://www.openstreetmap.org/way/1125846213#map=18/53.74589/9.65670
- https://brouter.de/brouter-web/#map=18/53.74598/9.65651/standard,route-quality&lonlats=9.657122,53.745272;9.656339,53.747054
- https://www.mapillary.com/app/?lat=53.745974954545&lng=9.6593258963636&z=17&pKey=487840566320545&focus=photo
Querying cycleway:surface
in the trekking profile increases the calculation time by about 0.65%.
As a side note, the above overpass query has a near 100% success rate in finding map errors.
from brouter.
I'll be curious though to watch with which constructive solutions you'll come up with.
Probably an unpopular opinion, but I would suggest to do nothing. No tag aliasing and no profile change.
from brouter.
See discussion in #641
from brouter.
Tank for the feedback, Sorry!
I confused "cycleway" and "cycleroute"... ( #622 in my mind)
from brouter.
Related Issues (20)
- Support for node-tags in lookups.dat HOT 8
- "bicycle:backward=no" is not considered HOT 1
- Generating segments by process_pbf_planet.sh fails HOT 5
- Distinguish between villages/towns and country HOT 11
- Problem building from Dockerfile HOT 4
- Brouter Java error HOT 7
- The least cost route is not being used HOT 3
- Make timestamp format in server log to ISO8601 compatible HOT 1
- RFC: Improvement to Logging HOT 3
- Using segment cost instead of distance when processing bicycle kinematic model. HOT 22
- Success message on routing HOT 4
- bug with brouter.damsy HOT 1
- Cycling overlay doesn't work HOT 4
- Problem with communication between BRouter lib 1.7.5 and BRouter-web
- Car Profiles Not Working v1.7.5 HOT 7
- Adding waypoints beyond 9 HOT 1
- Feature Request: Implementation of Altitude Parameters for Route Calculation
- Update in F-Droid? HOT 6
- `Stick to cycleroute` does not minimize routes without bike lane HOT 4
- Add Panoramax Optional Coverage Layer
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from brouter.