[talk-au] Victorian Vicmap Address Import Proposal

[Andrew Davidson]

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.