-
Notifications
You must be signed in to change notification settings - Fork 819
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
Comments
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. |
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.. |
+1. |
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".. |
Re-opening - not adding new colours doesn't imply not adding more values to one of the current groups of access. |
Less of the snarky comments please. |
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. |
I would also be opposed to adding more values. Same reason as we are against highway=residential_link or track_type=grade6. |
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. |
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:
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. |
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. |
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... |
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..) |
"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: |
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 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 |
@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. |
2015-02-16 1:50 GMT+01:00 cm8 [email protected]:
+1, or use the same as "private". Not showing them at all surely is worse, |
@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: 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.) |
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. |
Since you were able to generalize on it, I'd refrain from thinking it was poor :) |
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%?). |
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. |
Not in Poland. Is there any location where it would be useful? |
Not in the UK, the Netherlands, or Luxembourg, as far as I know. |
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. |
sent from a phone
in Germany motor_vehicle=agricultural is very common on tracks, see e.g. here: |
Is it also true for access=agricultural? http://taginfo.openstreetmap.org/tags/access=agricultural#map shows that it used - but is it used correctly? |
sent from a phone
likely not, but there is some gray area whether access=no foot=yes |
Closing as apparently answer to
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. |
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
The text was updated successfully, but these errors were encountered: