Should a wall tag be on the amenity itself?

Help and support
1

Hello, If I have an amenity that has a fence or a wall around it, should the amenity itself have a barrier=wall tag or should a new area be made that has the exact same dimensions with the wall properties?

2

I usually keep a property (area) separated from a wall or fence (linear object) surrounding it, as both are separate objects. In such cases I draw an area for the property and another separate line following the outline of the property and tag it as wall or fence, whatever applies.

3

Separate features should be separate objects, so the wall tag shouldn’t go on the same way as the amenity.

4

If it is a simple feature like this: Way History: 1544008717 | OpenStreetMap or this: https://www.openstreetmap.org/way/1009205816/I tend to have them as one. Importantly, the barrier needs to be consistent all the way around - alternating sections of fence and wall would be problematic. However, gates or other entrances don’t need to be ways and can be added as nodes.

However, as the feature becomes more complicated, I find that the feature and the barrier can deviate from each other, e.g. a school that has a set-down area for vehicle passengers that is outside the boundary, but still on school property.

Certainly in the past, Osmose used to complain that separately mapped amenities (or whatever) and (identical) barriers were two objects with the same geometry and they should be merged. I don’t think that happens anymore.

I you need to add area=yes to a particular object (an example would be rarer or less documented tags, animal=horse_walker had the problem for a long time), the QA services will complain that the barrier should be a line and shouldn’t be an area.

5

Often barrier= + amenity= / landuse= doesn’t work. They deviate from each other.
Instead of a feature, attributes have ~5k fenced= , a few walled= , and 203 relevant wall=


```sql
{{data:sql,server=https://postpass.geofabrik.de/api/,geojson=false}}
SELECT
    osm_type, osm_id, tags
    FROM 
    	postpass_polygon
    WHERE
    	tags ?& array['wall', 'amenity'] AND
        NOT (tags ?| array['barrier', 'building', 'structure']) AND 
        NOT (tags @> '{"wall": "no"}'::JSONB)
* `wall=no` * Has been used on `building=` for structures without walls; * Used for showing the feature isn't bounded by walls * `structure=` were some tens of `amenity=refuge_housing` mistakes without `building=`

But this is not scalable. I suggest expanding the use of separation= originating cycleway:*:separation= to outside highway= roads, allowing any separator to be recognized easily. There can be =fence , =wall , and anything. However as discussed with author, the coordination with barrier= is to debated. Proposal:Separation - OpenStreetMap Wiki

6

and to be clear, it is survivable and better than nothing being mapped

but even there having barrier as a separate feature would be even nicer

7

This is why we can’t have nice things hedge areas in carto

Osmose tends to be simply wrong quite often unfortunately

8

Oh, important point. If the wall is on the amenity, it can become rather complicated when you want to add type, height, material, etc., especially if those tags could also apply to the amenity. So, simple objects only.

If Osmose was always right, then an Osmose bot could just go about changing things. As we can’t tolerate a bot acting like that, Osmose has to provide false positives sometimes. If it is providing false positives lots of the time, then the rules for that particular item / class need review.

9

Sadly some Osmose rules are altogether wrong (at least in my opinion) or ask to do useless changes (at least in my opinion)

(and yes, I reported some to Osmose developers, part of reports was acted on)