The import has progressed and so far I’ve completed the uploads for Stage 3, adding new addresses from Vicmap for blocks which did not previously contain any addresses.
The next stage is to upload new addresses from Vicmap for blocks which did previously contain addresses, taking into account conflation to try and avoid adding duplicate data.
As a result of this import, there are situations where we imported multiple address nodes at the same location. While there are sometimes valid reasons for this, a lot of the time it’s limitations of Vicmap data and there is room for improvement.
Therefore I’ve created a MapRoulette challenge at https://mpr.lt/c/50541 which identifies all of these locations for manual review.
@mueschel raised a point about the addr:flats keys when the value overflowed 255 characters (the maximum allowed tag value). In the import we had used addr:flats, addr:flats2, addr:flats3…
Purely relying on this scheme instead of a semi-colon separator Multiple values - OpenStreetMap Wiki would result in too many tags, so combining both schemes would be the only viable option in my view.
However according to overpass turbo there are 49 nodes where we made use of addr:flats2. and I think it would be worth manually reviewing them all to ensure they are indeed correct. They would probably require a ground survey to confirm. Should we open map notes for all of these? I don’t want to spam notes though, especially if it would be hard for people to solve them.
I also think it’s worth a wider discussion to determine if there are better ways of tagging these.
eg. addr:flats:floor:1=list of units on floor 1, addr:flats:floor:2=list of units on floor 2 etc.
I think they will definitely need local review for the best outcome.
I also noticed on this node that the split of the numbers triggered between two units
addr:flats=…5615-5618;5710**-**
addr:flats2=5713;5715-5720
I will check a few out and can fix these but I think notes are a good idea to highlight the issue. certainly some strange numbering in some locations which could also be vicmap errors.
That was actually by design, when the value overflowed 255 characters, it’s split exactly there, I didn’t attempt to split only at the semi-colon. This is something we could do an automated edit along with using the suffixed colon.
If we feel the values are too unwieldy I’m also happy to delete them and then leave them to be surveyed.
This will keep the tag values shorter and make it easier for us mappers too, while also adding extra data about the level each unit number is found on.
The only limitation is sometimes it would be obvious from the numbering scheme or the letter boxes alone.
The downside is this requires one to enter the building to map, which in many instances you wouldn’t be able to access. Quite different to just surveying the letterboxes from outside.
That’s not what I meant. My comment was just about using the common scheme addr:flats:3 instead of the uncommon addr:flats3. The semicolon-separated lists are fine.
That would be a totally new and up to now unsupported scheme for addresses.
It might be better to have individual nodes for each level.
I’d just leave it for now. It looks like Nominatim doesn’t currently handle addr:unit (and its friends):
Which makes this all a bit theoretical. If they ever figure out how to consume these then we can bulk edit them to match whatever scheme they come up with.
