I’m looking for some guidance - my searches haven’t come up with anything.
If we have a field, with a stone wall running across it, and the wall has regular entrance holes built in, what is the best way of representing this? There are no associated paths or highways through the wall entrances.
The situation I’m describing is exactly as shown in the photo for the barrier:entrance feature. But as far as I can see, this feature doesn’t show on the standard rendering, so a user would not know that there are multiple ways through the wall.
The alternative is to draw separate walls, with gaps, which I guess would be an accurate representation of reality.
I think your problem is that you misunderstand who is the user of the standard Mapnik layer. The users of that layer are not hikers, but other mappers, and it would be impossible to represent every piece of information in the map, on that layer, without making it impossibly cluttered.
Gaps in the barrier=wall way would probably be a valid representation of reality, but my preference is to use barrier=entrance. The reason is that even a gap in the wall is still a bit of a barrier itself (it imposes a maximum width, for one) and therefore not the same as there not being a wall at all. Routing engines, for example, can take barrier=entrance nodes into account. That’s less important when there isn’t a path leading through the gap, but it’s still a benefit.
I tend to agree with hadw that this decision should not be based on the standard rendering (although it’s not really clear who or what that map is designed for – there are a lot of different, often competing goals).
I disagree with this suggestion, as entrance=* is intended for an entrance to a building or feature (such as a supermarket or library). It’s not designed for openings in barriers.
Based on previous discussions and how I’ve seen the tag being used, I think of things like water parks and golf clubs when I read “enclosed area”. Those may very well be surrounded with a wall or fence not unlike this meadow, but the entrance=* tag still represents the entrance into that facility, not the gap in the barrier. If we use an entrance=* node in this case, I would interpret it as “this is the (main) entrance of the meadow” which probably isn’t inherently wrong, but feels like a bit of a stretch.
Even if we use entrance=* here, barrier=entrance still needs to be tagged at the same time, because entrance=* on its own doesn’t tell you that the entrance is a gap in the wall - it might as well be a door, gate, turnstile, or other type of entrance.
Many thanks for the comments. I no longer lie awake worrying about walls and entrances. I now lie there trying to understand the purpose and target user for the standard map…
The curiosity of the standard map keeps me awake in the quiet hours too
If it’s primary objective is to serve the mapper, I would expect that a map that rendered much much more would be more suitable. It seems the bulk of the mappers have to suffer just so a few can view an uncluttered European city map.
I suspect that the bulk of the style maintainers live in European cities, and as a result that’s what the “standard” map shows. It has been raised several times (including on https://github.com/gravitystorm/openstreetmap-carto/pull/747 ). The problem is that it’s not possible for the same map style to have the same rendering rules applied everywhere and work both in Polish graveyards and in the middle of Australia, and its also impossible to both look nice and provide mapper feedback about all of the things that people might want to map.
For me, the standard style fails as soon as you’re outside a city centre - paths and tracks disappear to soon to make it a usable map. I ended up making my own (see https://wiki.openstreetmap.org/wiki/User:SomeoneElse/Ubuntu_1604_tileserver_load for setup instructions) and while that’s designed for rural England and Wales it would probably work better than the standard style outside city limits anywhere. The standard style also fails to show offices and a lot of industrial detail; which is odd.
Incidentally, it’s not impossible to have different rendering rules in different places - I know that cycle.travel does it (urban vs rural); I am also in the process of applying differing language rules in different places as explained at http://www.openstreetmap.org/user/SomeoneElse/diary/42069 ; you could expand that to apply other rendering rules differently too (perhaps “urban footpath” vs “rural footpath”).
I’m new to all this, but I thought it was supposed to be a comprehensive database that client apps would filter to the subset appropriate for their users and then apply their own rendering style.
I know that I have used three apps that use OSM data but don’t show the same things, and use different symbols for some of the same things.
The map is a comprehensive database. What we are talking about here is the rendering of that map that you see, by default, when you go to www.openstreetmap.org On that, you only actually see the map, if you use show data, and you only get outlines for all except the selected object.
