Opened 12 years ago

Last modified 8 years ago

#9440 closed enhancement

Consistent definition of ways treated as areas — at Version 2

Reported by: Don-vip Owned by: team
Priority: normal Milestone: 13.12
Component: Core validator Version:
Keywords: Cc:

Description (last modified by Don-vip)

To the simple question "does this way concerns an area", it looks like we have 3 different answers:

  1. OverlappingWays:
        private boolean concernsArea(OsmPrimitive p) {
            return p.get("landuse") != null
                    || "riverbank".equals(p.get("waterway"))
                    || p.get("natural") != null
                    || p.get("amenity") != null
                    || p.get("leisure") != null
                    || p.get("building") != null
                    || p.get("building:part") != null;
        }
    
  1. UnconnectedWays:
            public boolean isArea() {
                return w.hasKey("landuse")
                        || w.hasKey("leisure")
                        || w.hasKey("amenity")
                        || w.hasKey("building");
            }
    

3. WayConnectedToArea:

    private boolean isArea(OsmPrimitive p) {
        return (p.hasKey("landuse") || p.hasKey("natural"))
                && ElemStyles.hasAreaElemStyle(p, false);
    }

We should have a single one that matches all the the first two cases.

Change History (2)

comment:1 by skyper, 12 years ago

At least the WayConnectedToArea is special as e.g. buildings, parkings and so on are OK.

comment:2 by Don-vip, 12 years ago

Description: modified (diff)

You're right.

Note: See TracTickets for help on using tickets.