area of barrier=wall not filled #3453
Comments
|
Side note, but a bridge support structure should be tagged bridge:support=x, and in your case likely bridge:support=abutment: |
|
Sounds like a real problem, but we lack coders to solve issues - would you like to try making the code fixing it? |
|
My understanding is that currently non-hedge barriers are assumed to be linear rather than area features. I suspect it'd need a check in the database to find out roughly how many should be filled vs not filled. |
|
Am Di., 16. Okt. 2018 um 15:12 Uhr schrieb SomeoneElseOSM <
[email protected]>:
My understanding is that currently non-hedge barriers are assumed to be
linear rather than area features. I suspect it'd need a check in the
database to find out roughly how many should be filled vs not filled.
It is generally ok to assume closed way barriers as linear features (by
default), but it should be possible to explicitly make them either areas or
not with the key:area.
|
You're right and I'll be happy to re-tag it after this issue is solved and wall areas render opaque. :-) |
|
I agree that they should have some filling, because lack of it causes weird holes on map. The same applies also to I propose to test:
|
|
barrier=fence is only valid for lines (wiki) Some naturals/amenities are using barrier=fence as the border and the other tags as the fill on the same osm object (random example). So any change here needs good tests. |
|
There are multiple problems here
Adding rendering of fill for walls will end with #971 suddenly appearing for all walls. Small sample of affected objects (barrier=wall with leisure=playground - but the same affects any object rendered as an area) - https://overpass-turbo.eu/s/D26 |
|
What should be done to proceed - someone who thinks that barrier=wall is valid for areas should discuss it with people who think that this use is not OK and edit Wiki to either document disagreement and potential solution or to describe consensus position (on OSM wiki or tagging mailing list). |
|
I do not understand the https://overpass-turbo.eu/s/D26 example - I clicked a couple of those object and all of them were tagged as Because that's what my original post is about: I only expect wall areas with |
|
There is no real difference between
|
|
For me it's obvious that we mean only the ones with |
|
@Tomasz-W Note that achieving what you want would require If nothing changed then this map style is not able to distinguish between explicit area=yes and implicit area=yes. |
|
It sounds like this issue is not fixable with the current tools and
database?
This sounds like a job for an “area” data primitive!
As long as we only have nodes, ways and relations, it will always be
difficult to deal with closed ways.
Perhaps we have to close this issue for now?
…On Wed, Oct 24, 2018 at 5:14 AM Mateusz Konieczny ***@***.***> wrote:
@Tomasz-W <https://github.com/Tomasz-W> Note that achieving what you want
would require osm2pgsql to create two geometries (line and area) from a
single closed line. Last time I checked it was not doing this.
If nothing changed then this map style is not distinguishing between
explicit area=yes and implicit area=yes.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#3453 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AoxshJPAiWmC69J96SwwktKzOmv-KT4uks5un3ivgaJpZM4XeL8p>
.
|
|
sent from a phone
On 17. Oct 2018, at 12:08, Holger Jeromin ***@***.***> wrote:
Some naturals/amenities are using barrier=fence as the border and the other tags as the fill on the same osm object (random example).
But this is used for walls, too:
https://www.openstreetmap.org/way/209604284#map=19/51.43414/7.02914
https://www.openstreetmap.org/way/144635248
So any change here needs good tests.
rather than good tests we should fix the mapping, as it is mixing different things into one element, and rendering is just one field where this may create problems
|
|
sent from a phone
On 23. Oct 2018, at 22:14, Mateusz Konieczny ***@***.***> wrote:
@Tomasz-W Note that achieving what you want would require osm2pgsql to create two geometries (line and area) from a single closed line. Last time I checked it was not doing this
I believe this should be fixed in the data, because osm2pgsql cannot know which tags and properties belong to which things, if there is more than one represented by the same object.
|
|
sent from a phone
On 23. Oct 2018, at 22:14, Mateusz Konieczny ***@***.***> wrote:
If nothing changed then this map style is not distinguishing between explicit area=yes and implicit area=yes.
isn’t barrier=hedge already implemented to work as both, areas and lines? Couldn’t walls just act similarly?
|
Adding rendering of fill for walls will end with #971 suddenly appearing for all closed ways with Small sample of affected objects (barrier=wall with leisure=playground - but the same affects any object rendered as an area that has barrier=wall) - https://overpass-turbo.eu/s/D26 This effect is acceptable if we consider tagging |
|
Currently main blocker is "is EDIT: wiki describes area tagging as OK for walls, so it is not a blocker - https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dwall |
|
It makes sense to only render a closed way with For rendering hedges this works quite well. Some examples where a similar rendering of |
AFAIK this is impossible with our currently used technology ( |
|
I never noticed a closed hedge was filled without the |
|
Currently there are 2 layers for barriers in So how about splitting the |
|
So I just noticed that closed hedges without an area tag are drawn as a line... |
|
It should be checked for which barrier types that applies as well. I have the following strange example: Somebody mapped block barriers as small squares, tagged
https://www.openstreetmap.org/?mlat=52.47568&mlon=13.46644#map=19/52.47568/13.46644 |
|
We could change this during the next database reload, which we are discussing now at #3611 - however, as mentioned above it will lead to problems with features double-tagged with barrier=wall & amenity=, leisure=, etc. - since those keys are assumed to mark polygons features, all closed ways would be imported, and this would be a problem for amenities and leisure features that are just rendered with an icon and no color fill. On the other hand, we do render barrier=hedge when it is imported as a polygon, so there is a precedent. For the original poster, it seems the initial issue would actually be addressed by rendering |
|
sent from a phone
On 11. Apr 2019, at 01:30, jeisenbe ***@***.***> wrote:
The result of 3 will tell us how many features may unexpectedly turn into the appearance of a filled wall if we add a polygon fill for barrier=wall polygons. Especially those in 3)b) may be confusing to mappers.
I would not let these come into the way, rather they will more likely be fixed after the renderer shows the problem.
These should be distinct objects, or implicit through a property, similar to this: https://taginfo.openstreetmap.org/keys/fenced
|
|
sent from a phone
On 11. Apr 2019, at 09:05, jeisenbe ***@***.***> wrote:
Since there are "only" 926 features tagged with barrier=wall and area=yes that are also double-tagged with another polygon keys, there are not too many that would have "wrong" renderings.
garbage in garbage out. „double tagging“ is not a mapping style, it is an error
|
|
I agree that double-tagging is a mapping error and it will continually get fixed as soon as mappers notice the new rendering.
Agree as well. I am looking at the referenced issue about hedge now and I have to say that it is actually odd that it renders as an area without |
|
I like above renderings of filled walls which are correctly tagged. I also think that proposed rendering of them would help to remove bad tagging from database. |
I agree that this would be the main reason for rendering. A good comparison is barrier=hedge; there are some mistakes, but much fewer than with barrier=wall, because tagging on areas leads to the hedge fill appearing. |
|
BTW. What do you think about including also |
|
The wiki page for It can't be drawn as an area because: "barrier=retaining_wall behaves same as natural=cliff, that is no crossing as left-right are different heights. Lower side on right side of way direction" So it needs to be drawn so that the left side of the way is the high ground, and the right side is lower. This is the same method used to map natural=cliff and man_made=embankment. The wiki page has said this it was first created in 2008, after the barriers proposal was approved. |
|
Maintainers: I suggest closing this issue as wontfix because most of the closed ways tagged |
|
And what about the minority that is not a mapping error? I believe that:
That's all. |
|
I am not sure how to treat this In case where it is "valid tagging that is perfectly OK but there are many mistakes" rendering it would be OK as it would encourage fixing problems In case where "basically no one is suing it correctly and this tagging scheme is rather unwanted" WONTFIXing it would be preferable. |
|
IMHO the semantics of area=yes are clear and we should stick to the obvious interpretation, even if it will highlight a lot of problematic tagging initially. Ignoring it because of mapping errors will lead to inconsistency and in the long run will make it more difficult for contributors to understand the logic behind tagging (indeed it would dilute these logics). |
|
@PontiacCZ, could you point to some examples of correct tagging in your area, for testing? As you saw above, I had trouble finding good examples. I'm thinking that we should probably treat this the same as I've recently given my opinion that this style should probably lean toward the option that provides the best mapper feedback, even if it isn't ideal cartographically, but this issue is a tough choice because there are very few benefits of having walls and hedges mapped as areas in the database, instead of as linear ways. I can see how the area mapping could be helpful at very high scales, z20 and above, for wide features, but at most scales or zoom levels the linear mapping is more useful for almost all walls and hedges. With the current 3 pixel wide rendering for hedges (and city walls), a 1 meter thick feature is already life-size or larger up to z18 near the equator. Even the 0.4 pixel wide rendering for barrier=wall and =fence is life-size up to z17 for 50 cm thick walls (near the equator) |
|
I'm again recommending closing this issue, based on the results above (#3453 (comment)) and in PR #3834 and #3844. But I need input from @pnorman about this issue and #3844 first. |
|
Closed: since #3844 hedges mapped as areas are now rendered with an outline, so the situation is now similar to that of |
|
Hmm, well, what now...? Are we supposed to retag walls so they do not render transparent? How? |
|
It is uncommon to use “barrier=wall” as an area rather than as a linear
barrier feature. But those areas that are tagged “barrier=wall” will
continue to render as a thin black line, the same as all other walls.
If mappers want to develop a specific tag for the area of a wall (eg
area:barrier= or barrier_area= or similar) we could consider rendering that
in the future, if it becomes widely used by the community.
We can also reopen this issue if many more mappers start tagging walls as
areas in a consistent way.
|
https://overpass-turbo.eu/s/12TV https://overpass-turbo.eu/s/1aK1 may be useful for detecting mapping of |
|
sent from a phone
On 28 Jan 2021, at 20:55, Mateusz Konieczny ***@***.***> wrote:
We can also reopen this issue if many more mappers start tagging walls as areas in a consistent way.
my guess is you would be surprised how fast these would be remapped when the map brought these ambiguities to light instead of hiding them
|
|
Why guess and be surprised when you can simply ask the community, for example on the talk list? |
When we rendered barrier=hedge as an area, there were 30,177 ways with barrier=hedge and area=yes, but also 11,677 of features with barrier=hedge + another key such as "landuse", "amenity" etc which we imported as polygons, which were being incorrectly rendered as dark green hedge areas, since hedge areas were rendered above other landcover fill colors. So previously rendering this as a “mistake” was not enough to remove very many of them for hedges. |
|
Please excuse my bug report duplicate. I ask you to reconsider your decision of wrongly rendering walls and hedges with area=yes just because of wrongly mapped closed ways that contradict the "one feature, one OSM element" principle. By the way, areas are usually not entirely closed by walls or hedges, as they would be impossible to enter otherwise. (I'll look for and try to fix such wrongly mapped areas in my surroundings.) |
|
sent from a phone
On 18 Apr 2021, at 18:26, dafadllyn ***@***.***> wrote:
By the way, areas are usually not entirely closed by walls or hedges, as they would be impossible to enter otherwise.
our representation is always an abstraction, for example you can either leave a hole in the wall or add a node with barrier=entrance, both are valid representations for a wall with an opening
|
Expected behavior
Barrier=wall with area=yes should be rendered filled with grey color.
Actual behavior
The wall areas are rendered as transparent.
Links and screenshots illustrating the problem
Bridge pillars of unbuilt bridge - https://www.openstreetmap.org/way/584963675
Use of area=yes with barrier=* is suggested in manual for thick walls:
The text was updated successfully, but these errors were encountered: