On 21/5/21 9:23 pm, Andrew Harvey via Talk-au wrote:
For now the iD preset doesn't show the any inherited attributes, so
it will prompt mappers to supply these fields. While it might be
redundant, it's also not wrong, would you go so far as removing these
fields other mappers manually add?
Ideally, if we agreed that anything beyond addr:street was not
necessary, we would ask the iD developers to change the AU address
format to:
{
"countryCodes": ["au"],
"format": [
["unit","housenumber", "street"],
]
}
and it would stop asking users to enter the redundant information. This
would be a literal one line change to a configuration file.
If we tolerate when mappers manually enter these, then I'd say
filling in these values is worth it, it shows the address as
complete, and prevents other mappers manually adding this information
we could have just imported anyway.
We've never had a discussion about this. Until last year we didn't have
a complete set of bounded localities, so people would have to put this
information in. Now that we've finished, people are wasting their time
if they do.
If you are relying on the level 10 boundary for addr:suburb, that
means data consumers need to know that for Australia, addr:suburb
comes from admin_level 10. In other regions it might be different and
this information isn't really stored in OSM.
The first stop for data consumers would be to look at the Nominatim
address format configuration file.
I think we need to back up here and think about why you would import
address data into OSM. If we do this import then we'll get:
1. A rendering of street numbers at high zoom levels.
2. Nominatim searches would be able to return results at the street
number level.
Both of which would be nice to have. However, if you were a downstream
data consumer, who was looking for street addressing data in Australia,
you would have three sources:
1. Extracting address data from OSM.
2. Various state government address datasets.
3. G-NAF
I think we need to be realistic here. OSM is never going to be able to
compete with G-NAF. Because importing and updating the data will take
time and effort then the copy in OSM will likely be out of date, so a
data consumer is going to be better off pulling their data straight from
the source.
_______________________________________________
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au
