On Tue, 25 May 2021, at 4:41 PM, Daniel O'Connor wrote: > I'd make a polite argument there is still value in at least the suburb, > possibly postcode being still provided. When exporting data via overpass as > CSV; it's not currently easy or obvious to appropriately bring in the parent > attributes; even if it is for a Real Human looking at the map. > There's a fair number of use cases for "data in a spreadsheet friendly > format" I feel. > > Yes, it does come with a maintenance problem when suburbs change or postcodes > merge, but I feel that's one problem for one set of folks - us maintainers - > vs a repeated problem for many simple data consumers. > Ideally, as maintainers, we would over time semi automated this with tooling > (much like the proposed import)
Okay, so it sounds like we have a few people advocating including the full address tags even when they could be derived from a parent boundary object mostly because it makes it easier for some data consumers, and a few people advocating to not include them, and go so far as to actively discourage mappers adding these tags (via removing iD presets). If we decide to include these tags, then if a suburb boundary changed in JOSM you can 1. Select the new boundary 2. Selection | All inside 3. Search with `"addr:suburb"='old suburb name'` using "find in selection" 4. Update all the addr:suburb tags from old to new within the new boundary Yes it's a semi-automated mass change, so care must be taken and the community should be onboard with the mass change, but apart from that it's not too much effort. `addr:state` won't change so there's no real maintenance burden. Personally I feel if we won't actively delete addr:suburb tags someone manually adds then, we may as well add them for completeness, but not too fussed either way. At this point I'm not sure of the way forward, but given I've only heard positive feedback for doing an import of addresses, I don't want to let this stop the import happening. So we'll have to pick one approach and live with it for the time being (can be re-evaluated later). _______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
