Modify ↓
#9440 closed enhancement (fixed)
Consistent definition of ways treated as areas
Reported by: | Don-vip | Owned by: | team |
---|---|---|---|
Priority: | normal | Milestone: | 13.12 |
Component: | Core validator | Version: | |
Keywords: | Cc: |
Description (last modified by )
To the simple question "does this way concerns an area", it looks like we have 3 different answers:
- 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; }
- 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.
Attachments (0)
Change History (5)
comment:1 by , 11 years ago
comment:4 by , 11 years ago
Milestone: | → 13.12 (6502) |
---|
Note:
See TracTickets
for help on using tickets.
At least the WayConnectedToArea is special as e.g. buildings, parkings and so on are OK.