[talk-au] Victorian Vicmap Address Import Proposal

Wed May 19 08:40:48 UTC 2021

The initiative sounds good to me.

It sounds like this might be on a tight timeline, so a simple manual merge
one small group at a time would definitely not work. It seems any community
involvement would be, e.g. through a (post-import?) maproulette task. This
is therefore quite a different import than I expect Yuchen's would have
been.

Re 1. I support replacing interpolation ways because individual addresses
provide more flexibility for address placement

Re 2.,3. I've noticed someone deleting addr region tags, which is why I
haven't been adding them (in Canberra). I don't really mind either way, but
recognise that others do

I'm ok with addresses being added as lone nodes if they are not already
present. It seems like the only option for a large import.

My experience is that the position of units can be much more ambiguous in
some datasets (including being superimposed at the same coordinates), so my
intuition would be to only include housenumber and not unit number.
I see the intention is to use addr:flats ranges and addr:flats1,
addr:flats2 as needed. I don't have a strong opinion but it does seem like
this is a better solution than just dropping that data.

Cheers,

Joseph

On Wed, 19 May 2021, 4:50 pm Sebastian Spiess, <mapping at consebt.de> wrote:

> Hi Andrew,
> indeed a great initiative and yes the NSW import has stalled way too
> long.
>
> You will also need to detail how to deal with Unit numbers. For the NSW
> import there where many single houses that had several entries like 12A,
> 12B and 12-2 Lakewook Road. Do you import them as individual nodes? or
> just one omitting A/B/2?
>
> My comments, also based on some of my NSW import experience below in
> line.
>
> Cheers, Seb
>
> Am 2021-05-19 14:48, schrieb Andrew Harvey via Talk-au:
> > Some specific topics for discussion/feedback I have so far are:
> >
> > 1. How should we handle existing address interpolation ways? Should
> > these be left as they are or replaced with individually mapped address
> > points? I'm proposing we replace.
> >
> > 2. Should we also import `addr:suburb`, `addr:state` and
> > `addr:postcode` tags? I'm proposing we do.
>
> I vote for adding the information. I have been adding it where possible.
> In theory the POI should know in which State or LGA it sits but the
> reality is that this does not result in the user having complete
> addresses on the POI. E.g. restaurants don't have the suburb
> automatically shown in OSMAnd.
>
> I would also argue that the information is part of the full address of
> the house/building. Else I dare say we should have a similar discussion
> for phone numbers. We don't need to add +61 or (0)2 as this is implicit
> by the POI location.
>
> >
> > Given postcode regions aren't mapped, then adding these to the address
> > should be very helpful.
> >
> > `addr:state` is less important given these addresses fall within the
> > Victoria state admin boundary already. The wiki touches on this saying
> > "A few mappers consider higher-level tags, or even addr:city=* as
> > redundant, since they could be calculated from the respective boundary
> > relations they are contained in (if present and valid). However, such
> > practice has severe disadvantages and can lead to wrong results."
> >
> > Either way, I don't think it matters too much, but since it's not
> > harmful to include, and might provide some benefit, then we may as
> > well include `addr:state`?
>
> State and post code are part of the full address. I vote for including
> it.
>
> >
> > `addr:suburb` is similar to `addr:state`, suburb/locality boundaries
> > are already well mapped in Victoria. Since we have this detail from
> > the source data I think we probably should still include it.
> >
> > 3. `addr:suburb` vs `addr:city`.
> >
> > Both tags are in use within Australia. According to taginfo
> > (
> https://taginfo.geofabrik.de/australia-oceania/australia/search?q=addr%3A)
> > within Australia addr:suburb occurs 521 ,671 times and addr:city
> > 562,542 times.
> >
> > The iD address preset fields uses addr:suburb.
> >
> > Victoria only has a handful of place=city objects
> > (https://overpass-turbo.eu/s/17vc), Melbourne, Geelong, Ballarat,
> > Bendigo, Shepparton, Warrnambool, Traralgon, Bairnsdale, Wangaratta,
> > Wodonga, Horsham, Mildura.
> >
> > Because for addressing, it's the suburb/locality that appears on the
> > address not the city (eg. Melbourne place/city covers the whole
> > greater melbourne urban area, but not all the addresses here include
> > "Melbourne", only those within the CBD area where the Melbourne
> > place=suburb exists.
> >
> > While in rural areas it's a locality not a suburb, the two usually go
> > hand in hand, and I'd say it's okay to still tag these as addr:suburb
> > even though it's technically a locality and not a suburb.
> >
> > In this way I'd argue that addr:city has no place in Australia
> > (convince me otherwise).
> >
>
>
> Not sure if I want to convince you.
> To me this sounds like different names for the same thing. Aren't City
> or Suburb just different words for the next level up from Street?
>
> The Auspost is referring to 'placename/suburb/locality' page 25
>
> https://auspost.com.au/content/dam/auspost_corp/media/documents/australia-post-addressing-standards-1999.pdf
>
> For the NSW import I recall that I settled for city=<name that
> corresponds to a post code>.
>
> >
> > Maybe for this import, where we find an address existing in OSM and it
> > has addr:city which matches the addr:suburb from our Vicmap address,
> > then we automatically swap it to addr:suburb?
> > _______________________________________________
> > Talk-au mailing list
> > Talk-au at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-au
>
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20210519/44202130/attachment-0001.htm>