Modify

Opened 4 years ago

Closed 4 years ago

#18544 closed defect (fixed)

Don't warn crossing administrative and protected_area boundaries.

Reported by: anonymous Owned by: GerdP
Priority: normal Milestone: 20.01
Component: Core validator Version:
Keywords: boundary Cc: simon04

Description

JOSM validator raise a warning of "crossing boundaries" when one boundary is tagged as boundary=protected_area and the other is tagged boundary=adminstrative. I see no reason for this warning.

Attachments (4)

x-boundaries.osm (1.6 KB ) - added by GerdP 4 years ago.
fix stupid paste&copy error boundary=boundary=protected_area
18544.patch (1.9 KB ) - added by GerdP 4 years ago.
18544-v2.patch (1.9 KB ) - added by GerdP 4 years ago.
ignore boundary=protected_area
18544-v3.patch (2.5 KB ) - added by GerdP 4 years ago.
ignore boundary=protected_area earlier, don

Download all attachments as: .zip

Change History (18)

comment:1 by Klumbumbus, 4 years ago

Owner: changed from team to anonymous
Status: newneedinfo

I doesn't warn for me. Please add an example .osm file.

comment:2 by GerdP, 4 years ago

Not sure if the sample makes sense but it shows the error.

by GerdP, 4 years ago

Attachment: x-boundaries.osm added

fix stupid paste&copy error boundary=boundary=protected_area

in reply to:  2 comment:3 by Klumbumbus, 4 years ago

Owner: changed from anonymous to team
Status: needinfonew

Replying to GerdP:

Not sure if the sample makes sense but it shows the error.

I think boundaries should have type=boundary not type=multipolygon, but when changing your example the warning remains.

comment:4 by GerdP, 4 years ago

Owner: changed from team to GerdP
Status: newassigned

Yes, problem is in CrossingWays.java. I'll have a look at it.

comment:5 by GerdP, 4 years ago

I think best is to exclude boundary=protected_area from this test? Or do we want to report a crossing between two such boundaries?

Last edited 4 years ago by GerdP (previous) (diff)

in reply to:  5 comment:6 by skyper, 4 years ago

Replying to GerdP:

I think best is to exclude boundary=protected_area from this test? Or do we want to report a crossing between two such boundaries?

Only warn if the value of boundary is equal.

comment:7 by GerdP, 4 years ago

I agree, but for members of relations this is not that easy. The way itself may have a boundary tag or not. The way can be a member in different boundary relations. Working on this ...

comment:8 by Don-vip, 4 years ago

Just ignore protected_area boundaries. I'm sure there is some cases where several different protected areas overlap each other.

comment:9 by Don-vip, 4 years ago

Keywords: boundary added
Milestone: 20.01

by GerdP, 4 years ago

Attachment: 18544.patch added

comment:10 by GerdP, 4 years ago

That was also my thought when I wrote comment:5. OTOH I think my comment:7 is also true, isn't it? Attached patch implements the enhanced test but doesn't ignore protected_area yet.

by GerdP, 4 years ago

Attachment: 18544-v2.patch added

ignore boundary=protected_area

comment:11 by GerdP, 4 years ago

I wonder why we ignore relations with incomplete members here?

            return super.isPrimitiveUsable(p) && p.hasKey("boundary")
                    && (!(p instanceof Relation) || (((Relation) p).isMultipolygon() && !((Relation) p).hasIncompleteMembers()));

My understanding is that we can safely remove it since we only check ways.

comment:12 by Don-vip, 4 years ago

Cc: simon04 added

Maybe just an extra safety, see r6581

by GerdP, 4 years ago

Attachment: 18544-v3.patch added

ignore boundary=protected_area earlier, don

comment:13 by GerdP, 4 years ago

ignore boundary=protected_area earlier, don't ignore relations with incomplete members, just ignore the incomplete members

comment:14 by GerdP, 4 years ago

Resolution: fixed
Status: assignedclosed

In 15691/josm:

fix #18544: Don't warn crossing administrative and protected_area boundaries

  • exclude boundary=protected_area crossings
  • check also complete members of incomplete relations
  • if segments are crossing: collect boundary tags of all parent relations and complain if any match is found

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain GerdP.
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.