Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#20674 closed defect (fixed)

Water area inside water area not detected for waterway=riverbank

Reported by: zelonewolf@… Owned by: team
Priority: normal Milestone: 21.03
Component: Core validator Version:
Keywords: Cc: skyper

Description

When one waterway=riverbank objects is inside another, no warning is shown in the validator.

However, when two natural=water objects overlap in this way, the "water area inside water area" warning is reported.

Test case demonstrating the issue attached.

Attachments (2)

overlapping_riverbank.osm (2.6 KB ) - added by zelonewolf@… 4 years ago.
Test case demonstrating the problem.
20674.patch (998 bytes ) - added by GerdP 4 years ago.

Download all attachments as: .zip

Change History (9)

by zelonewolf@…, 4 years ago

Attachment: overlapping_riverbank.osm added

Test case demonstrating the problem.

comment:1 by GerdP, 4 years ago

I thought about adding this test when I fixed #20570. These tests are rather slow, so the question is if they are useful. Did you see this problem in real world data?

comment:2 by anonymous, 4 years ago

Yes, I've encountered this in real world data, though I've fixed it each time I found it, so I don't have a ready example to show. The issue is that the value "riverbank" sometimes makes people think it is for tagging the sides of rivers (rather than water-covered areas of rivers) and as a result of that, sometimes you'll find river islands tagged with "riverbank", with people thinking they're tagging the sides of an inner riverbank. But really, they're just making the river island invisible :) The only way I'm even able to detect this error is to convert all riverbanks in an area to natural=water + water=river, and then the validator works properly and detects these cases.

This misunderstanding of the value "riverbank" is why I've reported #20591 Rename "Riverbank" preset to "River area", to help reduce this confusion.

This situation/confusion is yet another reason why waterway=riverbank should be replaced with natural=water + water=river and I've been working at a grassroots level with local communities to fix river issues which includes upgrading this tag (see https://wiki.openstreetmap.org/wiki/User:ZeLonewolf/Procedure/River_modernization where a number of mappers have been collaborating).

Personally, I would like to see JOSM recommend auto-upgrade of this tag, just like iD has done since late 2018 (https://github.com/openstreetmap/iD/issues/5591), but I recognize (see: #17874, #8759) that not everyone seems to agree.

In the absence of JOSM recommending upgrade of riverbank, let's at least fix tagging issues associated with riverbank-style tagging on an equal footing with those of natural=water.

by GerdP, 4 years ago

Attachment: 20674.patch added

comment:3 by GerdP, 4 years ago

Cc: skyper added

@skyper: I just wonder why we have the check for :areaStyle in these tests. Do you know why?

comment:4 by skyper, 4 years ago

No, I never took care about :areaStyle. I'd say this is not needed for positive search/regex and its origin might be the general rule (L206):

area:closed:areaStyle  area:closed:areaStyle {
  throwOther: tr("Overlapping Areas");
}

The two rules (L191) above probably do not need it, but below (L216), I guess, it is needed as not all closed ways with natural=* are areas.

/* #9556, #20570 */
area:closed:areaStyle[tag("natural") = parent_tag("natural")]  area:closed:areaStyle[natural][natural !~ /^(water|wetland|coastline)$/] {
  throwWarning: tr("Overlapping Identical Natural Areas");
  }

Just, my 2 cents.

comment:5 by GerdP, 4 years ago

I came to the same conclusions.

comment:6 by GerdP, 4 years ago

Resolution: fixed
Status: newclosed

In 17680/josm:

fix #20674: Water area inside water area not detected for waterway=riverbank

  • add checks for waterway=riverbank
  • remove check for :areaStyle where obsolete or wrong

comment:7 by GerdP, 4 years ago

Milestone: 21.03

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.