Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

render access=agricultural and access=forestry #1308

Closed
cm8 opened this issue Feb 12, 2015 · 30 comments
Closed

render access=agricultural and access=forestry #1308

cm8 opened this issue Feb 12, 2015 · 30 comments
Labels
Milestone

Comments

@cm8
Copy link

cm8 commented Feb 12, 2015

Currently

access=destination is rendered with a pale cyan dashed line ontop of a highway=*

access=private is rendered with a pale red dashed line ontop of a highway=*

May you add style rules for

access=agricultural, agricultural=yes rendered with a pale brown dashed line ontop
access=forestry, forestry=yes rendered with a pale dark green dashed line ontop

Ideally the offsets of all of these access styles should differ, so they can be mixed (e.g. if both agricultural and forestry is given, pale brown and pale dark green should interleave).

Greetings,
cm8

@pnorman
Copy link
Collaborator

pnorman commented Feb 12, 2015

I'm skeptical about adding more access colours. access=* needs to be simplified into a smaller number of values to be usable, and I think we're at the right spot.

@cm8
Copy link
Author

cm8 commented Feb 13, 2015

This is far from reality - and access=* reflects mostly what is readable on traffic signs on the ground. So in consequence, access=* needs to reflect the access restrictions given by law,

agricultural and forestry access belonging clearly to this, such as "destination"

(and unlike private)

I disagree with you in this respect, we do not need to simplify it, but rather add map styles for the more commonly used values - agricultural again clearly belonging to that..

@matthijsmelissen
Copy link
Collaborator

I'm skeptical about adding more access colours. access=* needs to be simplified into a smaller number of values to be usable, and I think we're at the right spot.

+1.

@cm8
Copy link
Author

cm8 commented Feb 13, 2015

Well, I've tried. People are deathmute these days, so honestly I didn't expect anything different. If you're looking for an easy solution, why not close all the other tickets as well? Easier by far than actually "collaborating"..

@pnorman
Copy link
Collaborator

pnorman commented Feb 13, 2015

I'm skeptical about adding more access colours. access=* needs to be simplified into a smaller number of values to be usable, and I think we're at the right spot.
+1.

Re-opening - not adding new colours doesn't imply not adding more values to one of the current groups of access.

@pnorman pnorman reopened this Feb 13, 2015
@pnorman
Copy link
Collaborator

pnorman commented Feb 13, 2015

Well, I've tried. People are deathmute these days, so honestly I didn't expect anything different. If you're looking for an easy solution, why not close all the other tickets as well? Easier by far than actually "collaborating"..

Less of the snarky comments please.

@cm8
Copy link
Author

cm8 commented Feb 13, 2015

What do you expect if tickets are closed almost immediately after being opened without even having had the chance to be viewed by broad audience? This is frustrating, you should leave them open at least a couple of days for a couple of guys to comment instead of taking the easy route.

@matthijsmelissen
Copy link
Collaborator

Re-opening - not adding new colours doesn't imply not adding more values to one of the current groups of access.

I would also be opposed to adding more values. Same reason as we are against highway=residential_link or track_type=grade6.

@lest69
Copy link

lest69 commented Feb 13, 2015

Forestry and agricultural seem restrictive enough that they could be grouped with the "private" accesses. Regardless of who exactly is allowed to go there, the general public isn't allowed, similarly to access=no or access=private. For a general purpose map, all a user really needs to know is whether they're allowed to go there or not.

@cm8
Copy link
Author

cm8 commented Feb 13, 2015

lest69, your comment shows a huge lack of knowledge about the complexities of access restrictions.

Reality in that respect is not as black and white as you are trying to simplify it. First of all, a general purpose map serves a lot of different people with different background - the "general public", if you will, is a compound of lots of users with different implied rights given by law depending on the "mode" they are in. If looking at an individual you need the following information to properly determine restrictions:

  • what transport mode is he/she using (vehicle, motor_vehicle, bicycle, etc..)
  • what role is he/she in (forest/agricultural worker, owner of the road, local residential living next to the road, emergency doctor, police, fire fighters, goods delivery, visitors, etc..)
  • what country and maybe subdivision the road of interest is in (different country, different laws/rites)

To be explicit: Your example about the public not being allowed if there is just forestry or agricultural access may easily be falsified within Germany: Lots of roads that primarily serve forest or agricultural work are also open to the general public, depending on the transport mode (most of the time this is by foot or by bicycle, but sometimes horse and moped/mofa are allowed in addition).

Even people privately owning an acre of land or forest from time to time decide to let the public pass on the roads within their property. So imho you have to be really careful to not abstract all of reality out of your general purpose map.

@lest69
Copy link

lest69 commented Feb 13, 2015

I fully understand how access restrictions work. I'm not new to the project.

The reality is that every possible combination of access restriction and mode of transport cannot be displayed on this general purpose map without hopelessly cluttering it. Some simplifications have to be made.

If rendering these two access restriction types similarly to the other already-rendered access types wouldn't be acceptable, then I'd support not rendering them at all and leaving it to more-specialized maps.

@mboeringa
Copy link

I think these kind of access restrictions actually call for toggable overlays. Even the current access restriction rendering, as a kind of "fixed" transparent stipple line overlay that can not be removed, can be rather confusing to anyone new to OSM. It would really help if these were just overlays that you could switch on and off at will in the browser.

In that case, adding more "restriction types" would also be less of problem, as users could select the stuff they need.

But with this suggestion, we are starting to get out scope for the carto-style, as this would also require a change to the main web-interface of OSM, the Rails application if I understood well...

@cm8
Copy link
Author

cm8 commented Feb 13, 2015

Even the current access restriction rendering, as a kind of "fixed" transparent stipple line overlay that can not be removed, can be rather confusing to anyone new to OSM.

True.

Also, the suggestion to use toggable overlays is a good idea. imho a subset of the most important restrictions should be chosen for the general purpose map, even if that calls for aggregating a bunch of them into a single style, like suggested earlier. More rare cases may make it to toggable overlays if/when they are available or be processed by specialized maps (might be already out there..)

@mboeringa
Copy link

"More rare cases may make it to toggable overlays if/when they are available or be processed by specialized maps (might be already out there..)"

I think this one by a Dutch cyclist is a nice example, with all the toggable different surface and cycle path types overlays:
http://mijndev.openstreetmap.nl/~ligfietser/fiets/?map=route&zoom=13&lat=52.35322&lon=4.85851&layers=B00000FFTFFFFFFFFFFFF

@cm8
Copy link
Author

cm8 commented Feb 16, 2015

I think this one by a Dutch cyclist is a nice example

Has a focus on different tags, currently, not access restrictions. It's more on the physical side: tracktype, surface, smoothness and it's main purpose is to give detail on cycling paths.

To add some progress to this ticket and to re-center its issue:

What about putting

access=destination
access=forestry and
access=agricultural

into one group, keeping the pale blue dashed line style? This way map users may recognize that certain conditions must be met to travel the element and that it's probably not ok to drive there by motor_vehicle without this condition being met.

Imho the pale red dashed line should be reserved for cases where non-vehicle transport modes are denied to the general public in addition to motorized access being denied. Generally, if foot/bicycle are explicitely allowed on a access=no or access=private tagged way, then use the pale blue dashed line as well. I.e., use red only, if access to the object in question is private or 'no' for all transport modes.

Greetings

@simonpoole
Copy link

@cm8 you've actually pointed it out yourself: access values x transportation mode/vehicle is rather complex and there is no hope of doing it properly without adding multiple dozens of additional renderings. On top of that the rendering databases currently do not contain the necessary values to do this in the first place.

I would rather suggest to drop all access specific rendering, particulary since as it is currently it motivates incorrect tagging.

@dieterdreist
Copy link

2015-02-16 1:50 GMT+01:00 cm8 [email protected]:

What about putting

access=destination
access=forestry and
access=agricultural

+1, or use the same as "private". Not showing them at all surely is worse,
and adding even more access colours is even worse, because nobody will be
able to read this.
Btw.: "access=forestry" or "access=agricultural" seem wrong for all
situations I know of, that should most probably become "motor_vehicle" or
"vehicle" in some cases of bad signage.

@cm8
Copy link
Author

cm8 commented Feb 18, 2015

.., particulary since as it is currently it motivates incorrect tagging.

@simonpoole This actually was one intention when opening this ticket: correct rendering <=> correctly mapped access restrictions.

However, while I agree that not doing access specific rendering at all might lead to less 'mistakes' when data is entered, I do not think this is a good thing to do on the usage side. It might be a solution if the map was exclusively used by mappers but it is not.

To be useful to a broad range of people some sensible subset of mappable access restrictions should be chosen, even if this means that there remains ample room for mapper's abuse of this subset to have a specific rendering. The documentation in the osm wiki should discourage such practice. Droping the feature completely eventually means droping any feature, to the maximum extent we'll have an empty map, which is not quite in line with the project's goals.

So what is the easiest and most useful rule out of all access restrictions? This is a question which should be focused on. If we want to reduce access restriction styles to one single style, then maybe use:
'Is there any access restriction for any kind of motor_vehicle, implied or explicit?'

If yes - indicate this with a dashed pale red line and document this in the maps legend. For a map user to find out about the specific restriction he/she will have to look at the map data or consult a specific purpose map.

For the general purpose map then we'd simply trust the red dashed line to tell us: 'There is some access restriction for at least one kind of motor vehicle when traveling to this element.' (But which one in specific it does not tell.)

@matkoniecz
Copy link
Contributor

'Is there any access restriction for any kind of motor_vehicle, implied or explicit?'

That is a poor idea. Maybe it may work as 'Is there any access restriction for main type of communication on this way, implied or explicit?'

Otherwise it will render footways and cycleways as restricted because motor vehicles may not use them.

@cm8
Copy link
Author

cm8 commented Feb 19, 2015

That is a poor idea.

Since you were able to generalize on it, I'd refrain from thinking it was poor :)
If we continue to build on your generalisation we'd have to ask, if there is a 'main type of communication' for each type of highway, or -better- if it's determinable for all relevant ones.

@matkoniecz
Copy link
Contributor

It may not be possible to select reasonable ones. For example for highway=track main type of communication may range from agricultural motor vehicles through bicycles to foot traffic (and many others types of transport in a different places of world).

It sounds like trying to find a smart heuristic - that is doomed to fail horribly in significant amount of cases (1%? 5%?).

@matkoniecz matkoniecz added this to the New features milestone Mar 6, 2015
@matkoniecz
Copy link
Contributor

It seems that from all these proposals "render access=agricultural and access=forestry like access=private" is the best one.

@jojo4u
Copy link

jojo4u commented Sep 4, 2015

It seems that from all these proposals "render access=agricultural and access=forestry like access=private" is the best one.

Is there a country where access=agricultural/forestry is widespread and correct tagging? In Germany we have huge data quality issues since all those tags are in reality vehicle/motor_vehicle=agricultural/forestry as @dieterdreist mentioned.

@matkoniecz
Copy link
Contributor

Is there a country where access=agricultural/forestry is widespread and correct tagging?

Not in Poland. Is there any location where it would be useful?

@matthijsmelissen
Copy link
Collaborator

Not in the UK, the Netherlands, or Luxembourg, as far as I know.

@simonpoole
Copy link

As I've pointed out before, anything outside of dropping the current rendering of access will cause even more problems as long as we cannot include the transport mode keys in a reasonable way.

Problem recap: people add access=somevalue instead of vehicle=somevalue, motor_vehicle=somevalue or motorcar=somevalue which would typically be the correct tagging, because access=somevalue is renderd. As @jojo4u points out, this breaks routing in really bad ways.

@dieterdreist
Copy link

sent from a phone

Am 11.09.2015 um 14:00 schrieb Mateusz Konieczny [email protected]:

Is there a country where access=agricultural/forestry is widespread and correct tagging?

in Germany motor_vehicle=agricultural is very common on tracks, see e.g. here:
http://taginfo.openstreetmap.org/tags/motor_vehicle=agricultural#map

@matkoniecz
Copy link
Contributor

Is it also true for access=agricultural? http://taginfo.openstreetmap.org/tags/access=agricultural#map shows that it used - but is it used correctly?

@dieterdreist
Copy link

sent from a phone

Am 11.09.2015 um 21:07 schrieb Mateusz Konieczny [email protected]:

Is it also true for access=agricultural? http://taginfo.openstreetmap.org/tags/access=agricultural#map shows that it used - but is it used correctly?

likely not, but there is some gray area whether access=no foot=yes
is good tagging or not (similarly here you could substitute no with agricultural). All signs I have seen ban either motorized vehicles or vehicles, with an exception for agricultural and forestry traffic. I've never seen restrictions for pedestrians or cyclists on ways for agricultural traffic.

@matkoniecz
Copy link
Contributor

Closing as apparently answer to

Is there a country where access=agricultural/forestry is widespread and correct tagging?

is no.

Showing invalid data and making easier to spot it may be worthwhile but access rendering is not intuitive so it would be merely confusing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

9 participants