Lots to read here. My take away is Postcodes are not from Australia Post and a proprietary system.
Postcodes are not great for areas, it might work but can also be complex. (I'm thinking sprinkled houses in a rough terrain making the relation consists of several areas that are not officially defined?) Postcodes are considered part of the address by most of us, however Australia Post could go without. I still prefer them on the node, however I'm ok if the import proceeds without. As being said, we should get going, make a decision, document it and go. On 19 June 2021 3:54:38 am AEST, stevea <stevea...@softworkers.com> wrote: >On Jun 17, 2021, at 2:14 AM, Andrew Harvey via Talk-au ><talk-au@openstreetmap.org> wrote: >>> It's a fair point that Vicmap's own postcode field shouldn't be >taken as 100% correct, it looks like it might have been assigned based >on postcode boundaries so might still suffer issues because of this, >but where addr:postcode is not already mapped, most of the time the >Vicmap one will be correct. > >To be clear, I'm 100% OK with postcodes on nodes with addresses, such >things belong together (as that tag on that node): it is indeed "the >correct way to go." (IMHO). > >I'm not terribly excited (dejected) to see a suggestion that ABS' >described "imprecise process" (of conflating postcodes with geographic >boundaries) is glibly said as "we can still have postal_codes on admin >boundaries where the vast majority of addresses within that boundary >have that postcode." > >In the USA (in OSM) we say rather bluntly "ZIP codes are not >boundaries." (ZIP codes are USA postcodes). It seems ABS agrees. >Putting them on entire admin boundaries, especially where they are not >100% correct (all of them?) adds noise to our data, which I am >identifying and say "in the USA, we just don't do this" (as they are >simply not the same). > >Though, postcode tags on address nodes, sure. Good way to do it, >correct way to go, et cetera. > >In the USA, OSM imported mid-2000s national census data to "lay down a >road grid." We continue to unravel and fully "TIGER Review" these >data, 15 years later. They are "noisily (though that gets better over >time, with effort) mostly correct" today, but. > >There is a wide distribution / spectrum of such (postal) data scattered >around OSM in various jurisdictions. I'm saying that at this level of >conversation, pave the road smarter, rather than glibly or easily. >Good planning makes better maps. > >Thank you for saying "fair point," too. I hope I haven't beaten it up >too much, so thank you to all for patience reading. >_______________________________________________ >Talk-au mailing list >Talk-au@openstreetmap.org >https://lists.openstreetmap.org/listinfo/talk-au
_______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
