Is the data significantly interpolated?

[CloCkWeRX]

Other address data sets in openstreetmap tend to be inserted into buildings or other geometry (ie, cadastre or other land type polygons).

This represents a lot of what is observable on the ground; as opposed to the legal or delivery point information.

Example: 174 Grattan Street Parkville:

Its highly unlikely this is a 'real' address as a person would see it from survey - the university grounds would likely be known as something else encompassing all of the Grattan St addresses.

If so, a few decisions need to be made about existing data:

• Should things which contain multiple address points but have an existing address be amended to street number low-street number high on the parent building/geometry, and the points added within?
• Should things that are not made of individual parcels except in cadastre be kept seperate, or merged? A number of parklands for example fit this criteria. Example:
• Or is it best to model this data as address interpolation only

[CloCkWeRX]

@stevage had a few things I wasnt sure about re address data, decided to put into github to sort through it all easily.

[stevage]

@CloCkWeRX Ok, it looks like there might be a different form of addresses that we should publish that would be a better starting point. I think this dataset is indeed interpolated - we have other datasets which accurately reflect "real" addresses. The information model is a bit complicated (properties, child properties, entrances...) so I'm still getting my head around it.

If you look at the basemap at maps.melbourne.vic.gov.au you can see the level of detail we have: individual building names and numbers at University of Melbourne, for instance. But that dataset also has individual flat locations, which maybe we don't want to publish.

It might be helpful if you look at the basemap above and describe the exact kind of dataset that would be most helpful? Also, are entrances or centroids more useful?

[CloCkWeRX]

Entrances are indeed useful for multiple addresses in a parent building/polygon - ie; ground floor shops.

Centroids for top level/'parent' buildings are great. Simplest case; single detached dwelling ("A house"); they are easy to merge onto existing geometry. The more complex case of an address range works too.

Not my most helpful answer is it :)

[stevage]

Ok, hopefully this gives an indication of what our data looks like. Here I've selected two layers:

• PropertyEntrance (white dots) has the street entrance of every "property", including buildings within the university. I've clicked on the Grattan St entrance, and you see there are lots of buildings that share that point as their entrance.
• BaseBldgCentroid (green dots) has the centre of each building.

It's kind of complicated because sometimes one building has multiple entrances (eg, a block of flats, a shopping centre...), and sometimes one entrance has multiple buildings (as above). And sometimes there isn't a BaseBldCentroid, as for small houses.

Actually, maybe PropertyPoint is better:

Each blue dot there is one point. It links to either a building or a property, and is placed not at the centroid, but somewhere within the polygon.

[stevage]

I've generated a new dataset based on the property points. Just waiting on approval to publish it, which in the ideal case will be tomorrow.

[stevage]

@CloCkWeRX I've published a subset of the original Address Points dataset, called "Addresses that have entrances": https://data.melbourne.vic.gov.au/Property-Planning/Addresses-that-have-entrances/ntgd-3rsr

Hopefully this is more useful for your original problem - for instance, it just has one point for University of Melbourne along Grattan St (230 Grattan St), instead of all the "hypothetical" addresses.

Still working on a building addresses dataset - it's quite confusing to work out what is actually the most meaningful thing to publish. There's a common situation where one property has several distinct entrances with different addresses.