Re: [talk-au] Victorian Vicmap Address Import Proposal - Suburb and Postcode discussion

[Andrew Davidson]

On 14/6/21 10:28 pm, Ewen Hill wrote:


Suburbs are a little different however I can't see the issue of adding 
the suburb/locality. It makes life so much simpler for a lot of people 
with not a lot of significant issues. Where suburbs are split (like 
Fraser Rise) then there will be few properties involved as this is done 
before the creation of these new estates.


There is a basic OSM principle that mappers are our most valuable 
resource. This means that if there is more than one way to map the same 
information then we choose the option that reduces the work for the mapper.


The data consumer is expected to post-process OSM data. You can't get a 
list of addresses out of OSM without doing some sort of post-processing. 
As a minimum you are going to have to possess enough programming skill 
to write an Overpass QL query. This is the problem I have with our 
hypothetical user who, apparently, possesses enough technical skill to 
write Overpass QL but doesn't have enough skill to run a program to 
download what they need. I estimate that the total number of users in 
this category would be zero.


Maybe there is a user requirement to generate a list of addresses from 
OSM. I have been pondering why you would want to do that, but other than 
printing out a "gazetteer" I can't think of one. If someone could 
explain how they would use one then we could think about what the best 
way to provide this. There could be a need to replace OpenAddresses, as 
they now require you to be a donor to download in CSV format. Otherwise 
you have to download GeoJSON and post-process.


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Sun, 13 Jun 2021, at 12:24 PM, Sebastian S. wrote:
> Hi Andrew,
> 
> Have you considered adding a 
> ref:{Vic map reference}={Vic map ID} 
> Tag to the imported data points?
> 
> Or do you consider a ref tag or source tag an issue for users?

I decided against a reference, see 
https://gitlab.com/alantgeo/vicmap2osm/#why-no-vicmap-id

> I am also wondering if it makes sense to add a clean up tag for all duplicate 
> points. Think tiger data import.

The import makes a big effort to remove all duplicates before import, so it 
shouldn't be adding any duplicates. There could be cases where the conflation 
hasn't picked up on an existing address being the same, so you could end up 
with duplicates this way, but from the checking I've done so far it doesn't 
look like it would happen much.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Sun, 13 Jun 2021, at 12:21 PM, Sebastian S. wrote:
> Thanks Andrew for this great proactive communication. Please keep at it.
> 
> With regards to the suburb etc tags I must say I was swayed for some time. 
> However I still feel that including the full address has more benefits for 
> the majority of users. 
> At the same time you have also provided options for checking and maintaining 
> the data. A Maproulet task that flags POI seems a good idea to me.
> 
> It is true that the postcode etc can be deduced from the boundary relations 
> but until this is done by the consumers for all POI I will support the full 
> address.

I agree, and the posts here indicate the majority of the community prefer to 
have addr:suburb on each address object in addition to the boundary. But some 
community members here who don't want to see addr:suburb on the address object, 
so I had to decide to either push ahead based on the majority support even with 
vocal opposition, or do what I'm currently proposing which is the bare minimum 
and not include these tags. I'm open to changing this if those who oppose voice 
their support of a decision based on the majority even if it disagrees with 
their view.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Sebastian S.]

Hi Andrew,

Have you considered adding a 
ref:{Vic map reference}={Vic map ID} 
Tag to the imported data points?

Or do you consider a ref tag or source tag an issue for users?

I am also wondering if it makes sense to add a clean up tag for all duplicate 
points. Think tiger data import.

On 10 June 2021 8:55:29 pm AEST, Andrew Harvey via Talk-au 
 wrote:
>On Tue, 8 Jun 2021, at 7:33 PM, Ewen Hill wrote:
>> Andrew,
>>   Thank you for both your initial work and the communication as well
>as the listening. Can I congratulate you on the lib/toOSM.js for the
>capitalisation and duplication processing. Very detailed
>> 
>> A few numpty questions after being late to the party...
>>  * Is there a node id on the vicmap address and are we storing this
>in OSM so we can match and look for missing or deleted ones later?
>
>Good question, I've added a section to the code repo at
>https://gitlab.com/alantgeo/vicmap2osm/-/tree/master#why-no-vicmap-id,
>essentially because such an ID makes it confusing for OSM contributors,
>makes the data feel less organic to OSM, and conflation can still be
>done without it.
>
>>  * Can we provide a couple of samples of the
>existingAddressesWithNewTagsOnly export once available
>
>Yes I'll post the full import candidates shortly, I'm still working
>finalising them at the moment.
> 
>>  * Could we perform some sampling of suburbs/levels. Perhaps 
>>* Mallacoota (large reserves, complex islands and altered
>crown/public land ownership)
>>* Meringur or Learmouth (large farming community)
>>* Fitzroy (complex inner city)
>
>Yes, I can sample these out, I'll post them shortly.
>
>>  * I can't see what happens on collision with a totally incorrect
>address. Is the new node just added where you can't find a matching
>address. 
>
>At the moment yes if it doesn't find an exact match then the new node
>will be imported. In the conflation I broke the state up by city block
>(land surrounded by roads) because where there are no addresses in OSM
>in that block we can be fairly certain there will be no conflicts.
>Where there are addresses in the block there is a chance that the
>address exists but it wasn't an exact match, I haven't decided what I
>think should happen here.
>
>Treating all the blocks where at least one address already exists in
>OSM would be too overwhelming to review them all manually (636,532
>addresses fall into this category compared to 1,311,095 which very
>likely aren't already in OSM, compared to 107,194 which are certainly
>already in OSM).
>
>1,311,095 Vicmap addresses are in a block which has no OSM addresses
>13,830 Vicmap addresses are within an OSM address polygon (which may or
>may not be the same address)
>636,532 Vicmap addresses are in a block which has some OSM addresses
>already but couldn't be matched exactly
>107,194 Vicmap addresses are in a block which has some OSM addresses
>already and there was an exact match found
>
>>* Is there an exceptions file for the above that can be reviewed.
>Could map roulette some of these?
>>  * How have you gone with best practices globally?
>
>Let me circle back to these points. I have created two sets of
>MapRoulette challenges (not publicly visible yet) but these are for the
>Vicmap complex name and building / property name, which we aren't
>importing automatically instead via MapRoulette inviting the local
>community if they'd like to review these.
>
>> I am amazed by the amount of code you have developed and documented
>to do this. The benefits of adding this import will far outweigh any
>minor local issues. Chapeau!
>
>From the README I wrote, Vicmap data isn't perfect, OSM data isn't
>perfect. This import isn't without issues, it aims to get it right for
>the vast majority of instances, but local mappers will still be left
>with some burden of correcting or cleaning up edge and corner cases.
>I'm with you that the benefits outweigh the issues.  
>
>I've done on the ground surveying of addresses and shocked by how many
>errors I made.
>
>___
>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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Sebastian S.]

Thanks Andrew for this great proactive communication. Please keep at it.

With regards to the suburb etc tags I must say I was swayed for some time. 
However I still feel that including the full address has more benefits for the 
majority of users. 
At the same time you have also provided options for checking and maintaining 
the data. A Maproulet task that flags POI seems a good idea to me.

It is true that the postcode etc can be deduced from the boundary relations but 
until this is done by the consumers for all POI I will support the full address.

Another way to argue would the that the postcode area could be deduced from the 
cloud of address points.



On 8 June 2021 2:59:01 pm AEST, Andrew Harvey via Talk-au 
 wrote:
>To sum up the contentious issue of suburb, postcode, state tags,
>
>- Phil, Daniel and Seb would prefer the suburb and postcode on each
>address object.
>- Andrew Davidson and cleary would prefer we not include suburb and
>postcode on each address object and instead require data consumers to
>derive this data from the existing boundaries, and actively discourage
>mappers manually adding this data via removing the preset in ID.
>
>Thinking further I'd support including the full address details on each
>address object, to provide a complete address, even if duplicated by
>the boundary. QA tools could be built to validate these match the admin
>boundaries and it becomes a maintenance task to maintain these tags,
>but I think that's okay.
>
>However, to avoid stalling this import on this issue (it doesn't sound
>like anyone will change their mind soon), I'll plan the minimum viable
>option of excluding addr:suburb, addr:postcode and addr:state from the
>import.
>
>There's nothing stopping a further discussion of a planned automated
>edit to update address objects with suburb, postcode and state if the
>community changes their mind later on.
>
>I'll make these changes to the import code, then once I've completed
>all the documentation and remaining issues hopefully post some import
>candidate files if anyone would like to review.
>
>___
>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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Tue, 8 Jun 2021, at 7:33 PM, Ewen Hill wrote:
> Andrew,
>   Thank you for both your initial work and the communication as well as the 
> listening. Can I congratulate you on the lib/toOSM.js for the capitalisation 
> and duplication processing. Very detailed
> 
> A few numpty questions after being late to the party...
>  * Is there a node id on the vicmap address and are we storing this in OSM so 
> we can match and look for missing or deleted ones later?

Good question, I've added a section to the code repo at 
https://gitlab.com/alantgeo/vicmap2osm/-/tree/master#why-no-vicmap-id, 
essentially because such an ID makes it confusing for OSM contributors, makes 
the data feel less organic to OSM, and conflation can still be done without it.

>  * Can we provide a couple of samples of the existingAddressesWithNewTagsOnly 
> export once available

Yes I'll post the full import candidates shortly, I'm still working finalising 
them at the moment.
 
>  * Could we perform some sampling of suburbs/levels. Perhaps 
>* Mallacoota (large reserves, complex islands and altered crown/public 
> land ownership)
>* Meringur or Learmouth (large farming community)
>* Fitzroy (complex inner city)

Yes, I can sample these out, I'll post them shortly.

>  * I can't see what happens on collision with a totally incorrect address. Is 
> the new node just added where you can't find a matching address. 

At the moment yes if it doesn't find an exact match then the new node will be 
imported. In the conflation I broke the state up by city block (land surrounded 
by roads) because where there are no addresses in OSM in that block we can be 
fairly certain there will be no conflicts. Where there are addresses in the 
block there is a chance that the address exists but it wasn't an exact match, I 
haven't decided what I think should happen here.

Treating all the blocks where at least one address already exists in OSM would 
be too overwhelming to review them all manually (636,532 addresses fall into 
this category compared to 1,311,095 which very likely aren't already in OSM, 
compared to 107,194 which are certainly already in OSM).

1,311,095 Vicmap addresses are in a block which has no OSM addresses
13,830 Vicmap addresses are within an OSM address polygon (which may or may not 
be the same address)
636,532 Vicmap addresses are in a block which has some OSM addresses already 
but couldn't be matched exactly
107,194 Vicmap addresses are in a block which has some OSM addresses already 
and there was an exact match found

>* Is there an exceptions file for the above that can be reviewed. Could 
> map roulette some of these?
>  * How have you gone with best practices globally?

Let me circle back to these points. I have created two sets of MapRoulette 
challenges (not publicly visible yet) but these are for the Vicmap complex name 
and building / property name, which we aren't importing automatically instead 
via MapRoulette inviting the local community if they'd like to review these.

> I am amazed by the amount of code you have developed and documented to do 
> this. The benefits of adding this import will far outweigh any minor local 
> issues. Chapeau!

From the README I wrote, Vicmap data isn't perfect, OSM data isn't perfect. 
This import isn't without issues, it aims to get it right for the vast majority 
of instances, but local mappers will still be left with some burden of 
correcting or cleaning up edge and corner cases. I'm with you that the benefits 
outweigh the issues.  

I've done on the ground surveying of addresses and shocked by how many errors I 
made.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Wed, 9 Jun 2021, at 5:36 PM, Benjamin Ceravolo wrote:
> How is address going to be 'placed' onto the map, I assume a node?
> 
> My primary question is where is the node going to be placed? 
> 
> Will it be placed in the centre of the property/parcel? If so, they will be 
> fine in denser areas but how effective will they be in rural areas, will they 
> need to be moved to near the driveway/gate manually? or is this a non-issue? 

I touch on this at 
https://gitlab.com/alantgeo/vicmap2osm/-/tree/master#where-should-addresses-exist,
 yes it will be on a node, and the location of the node is wherever Vicmap has 
it.

Where the address is already in OSM it will be left at its existing location, 
and new addresses imported can be manually moved post import by mappers if they 
like.

> In the case of a subdivision where there is common property, will the common 
> property receive its own address, as on VicPlan it shows a separate address 
> for both the common property and the units? (see example) 

As it currently stands, yes. At that specific location 1/37 and 2/37 addresses 
from vicmap were matched with existing addresses in OSM (so nothing imported), 
and a new third address of 37 would be imported.

What do you think should happen here?

I will post the candidate import files here shortly, I'm just still working to 
make sure I've covered everything I'm aware of on my side first.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Benjamin Ceravolo]

Forgive me if this has already been asked, and I believe Ewen may have been
alluding to this.

How is address going to be 'placed' onto the map, I assume a node?

My primary question is where is the node going to be placed?

Will it be placed in the centre of the property/parcel? If so, they will be
fine in denser areas but how effective will they be in rural areas, will
they need to be moved to near the driveway/gate manually? or is this a
non-issue?

In the case of a subdivision where there is common property, will the
common property receive its own address, as on VicPlan it shows a separate
address for both the common property and the units? (see example)

Thanks, Ben.

[image: image.png] (37.88839°S, 145.26755°E)

On Wed, 9 Jun 2021 at 16:31, Phil Wyatt  wrote:

> Go for it Andrew,
>
>
>
> I am all for better data, so even small steps are better than missing data.
>
>
>
> Re Data consumers - I tend to work with volunteer groups that often have a
> low level of GIS knowledge so 'complete exports' of data will always be
> best for them. It gets them started on mapping projects (QGIS) and also
> gets them into OpenStreetMap!
>
>
>
> Cheers - Phil
>
>
>
>
>
> *From:* Ewen Hill 
> *Sent:* Tuesday, 8 June 2021 7:34 PM
> *To:* o...@97k.com
> *Cc:* OpenStreetMap 
> *Subject:* Re: [talk-au] Victorian Vicmap Address Import Proposal
>
>
>
> Andrew,
>
>   Thank you for both your initial work and the communication as well as
> the listening. Can I congratulate you on the lib/toOSM.js for the
> capitalisation and duplication processing. Very detailed
>
>
>
> A few numpty questions after being late to the party...
>
>- Is there a node id on the vicmap address and are we storing this in
>OSM so we can match and look for missing or deleted ones later?
>- Can we provide a couple of samples of
>the existingAddressesWithNewTagsOnly export once available
>- Could we perform some sampling of suburbs/levels. Perhaps
>
>
>- Mallacoota (large reserves, complex islands and altered crown/public
>   land ownership)
>   - Meringur or Learmouth (large farming community)
>   - Fitzroy (complex inner city)
>
>
>- I can't see what happens on collision with a totally incorrect
>address. Is the new node just added where you can't find a matching
>address.
>
>
>- Is there an exceptions file for the above that can be reviewed.
>   Could map roulette some of these?
>
>
>- How have you gone with best practices globally?
>
> I am amazed by the amount of code you have developed and documented to do
> this. The benefits of adding this import will far outweigh any minor local
> issues. Chapeau!
>
>
>
> Ewen
>
>
>
>
>
>
>
> On Tue, 8 Jun 2021 at 16:19, cleary  wrote:
>
> Thanks Andrew. A considered and thoughtful response. I support your
> proposed actions. Your work for OSM is always very good and much
> appreciated.
>
>
>
> On Tue, 8 Jun 2021, at 2:59 PM, Andrew Harvey via Talk-au wrote:
> > To sum up the contentious issue of suburb, postcode, state tags,
> >
> > - Phil, Daniel and Seb would prefer the suburb and postcode on each
> > address object.
> > - Andrew Davidson and cleary would prefer we not include suburb and
> > postcode on each address object and instead require data consumers to
> > derive this data from the existing boundaries, and actively discourage
> > mappers manually adding this data via removing the preset in ID.
> >
> > Thinking further I'd support including the full address details on each
> > address object, to provide a complete address, even if duplicated by
> > the boundary. QA tools could be built to validate these match the admin
> > boundaries and it becomes a maintenance task to maintain these tags,
> > but I think that's okay.
> >
> > However, to avoid stalling this import on this issue (it doesn't sound
> > like anyone will change their mind soon), I'll plan the minimum viable
> > option of excluding addr:suburb, addr:postcode and addr:state from the
> > import.
> >
> > There's nothing stopping a further discussion of a planned automated
> > edit to update address objects with suburb, postcode and state if the
> > community changes their mind later on.
> >
> > I'll make these changes to the import code, then once I've completed
> > all the documentation and remaining issues hopefully post some import
> > candidate files if anyone would like to review.
> >
> > ___
> > Talk-au mailing list
> > Ta

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Phil Wyatt]

Go for it Andrew,

 

I am all for better data, so even small steps are better than missing data.

 

Re Data consumers - I tend to work with volunteer groups that often have a low 
level of GIS knowledge so 'complete exports' of data will always be best for 
them. It gets them started on mapping projects (QGIS) and also gets them into 
OpenStreetMap!

 

Cheers - Phil

 

 

From: Ewen Hill  
Sent: Tuesday, 8 June 2021 7:34 PM
To: o...@97k.com
Cc: OpenStreetMap 
Subject: Re: [talk-au] Victorian Vicmap Address Import Proposal

 

Andrew,

  Thank you for both your initial work and the communication as well as the 
listening. Can I congratulate you on the lib/toOSM.js for the capitalisation 
and duplication processing. Very detailed

 

A few numpty questions after being late to the party...

*   Is there a node id on the vicmap address and are we storing this in OSM 
so we can match and look for missing or deleted ones later?
*   Can we provide a couple of samples of the 
existingAddressesWithNewTagsOnly export once available 
*   Could we perform some sampling of suburbs/levels. Perhaps 

*   Mallacoota (large reserves, complex islands and altered crown/public 
land ownership)
*   Meringur or Learmouth (large farming community)
*   Fitzroy (complex inner city)

*   I can't see what happens on collision with a totally incorrect address. 
Is the new node just added where you can't find a matching address. 

*   Is there an exceptions file for the above that can be reviewed. Could 
map roulette some of these?

*   How have you gone with best practices globally?

I am amazed by the amount of code you have developed and documented to do this. 
The benefits of adding this import will far outweigh any minor local issues. 
Chapeau!

 

Ewen

 

 

 

On Tue, 8 Jun 2021 at 16:19, cleary mailto:o...@97k.com> > wrote:

Thanks Andrew. A considered and thoughtful response. I support your proposed 
actions. Your work for OSM is always very good and much appreciated.



On Tue, 8 Jun 2021, at 2:59 PM, Andrew Harvey via Talk-au wrote:
> To sum up the contentious issue of suburb, postcode, state tags,
> 
> - Phil, Daniel and Seb would prefer the suburb and postcode on each 
> address object.
> - Andrew Davidson and cleary would prefer we not include suburb and 
> postcode on each address object and instead require data consumers to 
> derive this data from the existing boundaries, and actively discourage 
> mappers manually adding this data via removing the preset in ID.
> 
> Thinking further I'd support including the full address details on each 
> address object, to provide a complete address, even if duplicated by 
> the boundary. QA tools could be built to validate these match the admin 
> boundaries and it becomes a maintenance task to maintain these tags, 
> but I think that's okay.
> 
> However, to avoid stalling this import on this issue (it doesn't sound 
> like anyone will change their mind soon), I'll plan the minimum viable 
> option of excluding addr:suburb, addr:postcode and addr:state from the 
> import.
> 
> There's nothing stopping a further discussion of a planned automated 
> edit to update address objects with suburb, postcode and state if the 
> community changes their mind later on.
> 
> I'll make these changes to the import code, then once I've completed 
> all the documentation and remaining issues hopefully post some import 
> candidate files if anyone would like to review.
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org <mailto:Talk-au@openstreetmap.org> 
> https://lists.openstreetmap.org/listinfo/talk-au
> 

___
Talk-au mailing list
Talk-au@openstreetmap.org <mailto:Talk-au@openstreetmap.org> 
https://lists.openstreetmap.org/listinfo/talk-au




 

-- 

Warm Regards

Ewen Hill

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[cleary]

Thanks Andrew. A considered and thoughtful response. I support your proposed 
actions. Your work for OSM is always very good and much appreciated.



On Tue, 8 Jun 2021, at 2:59 PM, Andrew Harvey via Talk-au wrote:
> To sum up the contentious issue of suburb, postcode, state tags,
> 
> - Phil, Daniel and Seb would prefer the suburb and postcode on each 
> address object.
> - Andrew Davidson and cleary would prefer we not include suburb and 
> postcode on each address object and instead require data consumers to 
> derive this data from the existing boundaries, and actively discourage 
> mappers manually adding this data via removing the preset in ID.
> 
> Thinking further I'd support including the full address details on each 
> address object, to provide a complete address, even if duplicated by 
> the boundary. QA tools could be built to validate these match the admin 
> boundaries and it becomes a maintenance task to maintain these tags, 
> but I think that's okay.
> 
> However, to avoid stalling this import on this issue (it doesn't sound 
> like anyone will change their mind soon), I'll plan the minimum viable 
> option of excluding addr:suburb, addr:postcode and addr:state from the 
> import.
> 
> There's nothing stopping a further discussion of a planned automated 
> edit to update address objects with suburb, postcode and state if the 
> community changes their mind later on.
> 
> I'll make these changes to the import code, then once I've completed 
> all the documentation and remaining issues hopefully post some import 
> candidate files if anyone would like to review.
> 
> ___
> 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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

To sum up the contentious issue of suburb, postcode, state tags,

- Phil, Daniel and Seb would prefer the suburb and postcode on each address 
object.
- Andrew Davidson and cleary would prefer we not include suburb and postcode on 
each address object and instead require data consumers to derive this data from 
the existing boundaries, and actively discourage mappers manually adding this 
data via removing the preset in ID.

Thinking further I'd support including the full address details on each address 
object, to provide a complete address, even if duplicated by the boundary. QA 
tools could be built to validate these match the admin boundaries and it 
becomes a maintenance task to maintain these tags, but I think that's okay.

However, to avoid stalling this import on this issue (it doesn't sound like 
anyone will change their mind soon), I'll plan the minimum viable option of 
excluding addr:suburb, addr:postcode and addr:state from the import.

There's nothing stopping a further discussion of a planned automated edit to 
update address objects with suburb, postcode and state if the community changes 
their mind later on.

I'll make these changes to the import code, then once I've completed all the 
documentation and remaining issues hopefully post some import candidate files 
if anyone would like to review.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Davidson]

On 27/5/21 9:03 pm, Daniel O'Connor wrote:


Look, as a dev as well, yes this is absolutely doable.
If this were a one click addon to an overpass query or otherwise 
massively dropped the barriers for non devs, fantastic.
But at least for me personally, the folks like us that can do a data 
import ALSO have the skills to handle bulk edits for maintenance, I feel 
we should make it as easy as possible to use the resulting data.


OK, so you already know how to do this? So when I thought I was being 
helpful, I was actually wasting my time?


Cheers thanks for that.



___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Davidson]

On 27/5/21 8:52 pm, Andrew Harvey wrote:

Okay, so it sounds like we have a few people advocating including the
full address tags even when they could be derived from a parent
boundary object mostly because it makes it easier for some data
consumers, 


Who are these data consumers? The only two concrete data consumers we 
have are OSM Carto and Nominatim. Neither of which require anything 
beyond street to function correctly.


People keep throwing up hypotheticals and when I show how you would deal 
with these supposed problems, the assumptions get moved and we continue 
the argument.


Let me be blunt here: if you don't have a smidgen of coding or GIS 
expertise you are not going to get any value out of trying to extract 
the address information from OSM and do something with it.


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Daniel O'Connor]

On Thu, 27 May 2021, 8:09 pm Andrew Davidson,  wrote:

> On 25/5/21 4:41 pm, Daniel O'Connor wrote:
> > I'd make a polite argument there is still value in at least the suburb,
> > possibly postcode being still provided.  When exporting data via
> > overpass as CSV; it's not currently easy or obvious to appropriately
> > bring in the parent attributes; even if it is for a Real Human looking
> > at the map.
> > There's a fair number of use cases for "data in a spreadsheet
> > friendly format" I feel.
>
> You don't need to add addr:suburb to get that, all you need is a little
> Python.
>

Look, as a dev as well, yes this is absolutely doable.
If this were a one click addon to an overpass query or otherwise massively
dropped the barriers for non devs, fantastic.
But at least for me personally, the folks like us that can do a data import
ALSO have the skills to handle bulk edits for maintenance, I feel we should
make it as easy as possible to use the resulting data.


>
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Thu, 27 May 2021, at 8:39 PM, Andrew Davidson wrote:
> On 25/5/21 4:41 pm, Daniel O'Connor wrote:
> > I'd make a polite argument there is still value in at least the suburb, 
> > possibly postcode being still provided.  When exporting data via 
> > overpass as CSV; it's not currently easy or obvious to appropriately 
> > bring in the parent attributes; even if it is for a Real Human looking 
> > at the map.
> > There's a fair number of use cases for "data in a spreadsheet 
> > friendly format" I feel.
> 
> You don't need to add addr:suburb to get that, all you need is a little 
> Python.

I think the point Daniel is making is that's too much for unsophisticated data 
consumers, and if we can do some processing on the OSM side to make it easier 
then we should.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Tue, 25 May 2021, at 4:41 PM, Daniel O'Connor wrote:
> I'd make a polite argument there is still value in at least the suburb, 
> possibly postcode being still provided.  When exporting data via overpass as 
> CSV; it's not currently easy or obvious to appropriately bring in the parent 
> attributes; even if it is for a Real Human looking at the map.
> There's a fair number of use cases for "data in a spreadsheet friendly 
> format" I feel.
> 
> Yes, it does come with a maintenance problem when suburbs change or postcodes 
> merge, but I feel that's one problem for one set of folks - us maintainers - 
> vs a repeated problem for many simple data consumers.
> Ideally, as maintainers, we would over time semi automated this with tooling 
> (much like the proposed import)

Okay, so it sounds like we have a few people advocating including the full 
address tags even when they could be derived from a parent boundary object 
mostly because it makes it easier for some data consumers, and a few people 
advocating to not include them, and go so far as to actively discourage mappers 
adding these tags (via removing iD presets).

If we decide to include these tags, then if a suburb boundary changed in JOSM 
you can

1. Select the new boundary
2. Selection | All inside
3. Search with `"addr:suburb"='old suburb name'` using "find in selection"
4. Update all the addr:suburb tags from old to new within the new boundary

Yes it's a semi-automated mass change, so care must be taken and the community 
should be onboard with the mass change, but apart from that it's not too much 
effort.

`addr:state` won't change so there's no real maintenance burden.

Personally I feel if we won't actively delete addr:suburb tags someone manually 
adds then, we may as well add them for completeness, but not too fussed either 
way.

At this point I'm not sure of the way forward, but given I've only heard 
positive feedback for doing an import of addresses, I don't want to let this 
stop the import happening. So we'll have to pick one approach and live with it 
for the time being (can be re-evaluated later).

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Davidson]

On 25/5/21 4:41 pm, Daniel O'Connor wrote:
I'd make a polite argument there is still value in at least the suburb, 
possibly postcode being still provided.  When exporting data via 
overpass as CSV; it's not currently easy or obvious to appropriately 
bring in the parent attributes; even if it is for a Real Human looking 
at the map.
There's a fair number of use cases for "data in a spreadsheet 
friendly format" I feel.


You don't need to add addr:suburb to get that, all you need is a little 
Python.


Assuming you have a csv dump of the address points from OSM eg:

@type,@id,@lat,@lon,addr:unit,addr:housenumber,addr:street
node,34495141,-35.2641690,149.1223146,,3,Sargood Street
node,40293773,-35.2640376,149.1226107,,9,Sargood Street
node,254020381,-35.2623407,149.1451050,1,5,Edgar Street
node,291548764,-35.3847749,149.0720245,,56,Mannheim Street
node,318854867,-35.3339561,149.1697838,,289,Canberra Avenue
node,318855426,-35.3244730,149.1792480,4,59-61,Wollongong Street
node,318856277,-35.3150098,149.1417359,,19,Jardine Street
node,318859652,-35.3627241,149.0815960,,70,Hodgson Crescent
node,318859688,-35.3627835,149.0817144,,70,Hodgson Crescent
.
.
.


and you've the corresponding admin_level 10 and post code boundaries in 
geojson:


act_suburbs.geojson
postcodes.geojson

then you import the libraries you need:

import pandas as pd
import geopandas as gpd

read in the address points:

addlist= pd.read_csv('act_address_dump.csv',low_memory=False)

convert the list to a geoframe:

address_points = 
gpd.GeoDataFrame(addlist,crs="EPSG:4326",geometry=gpd.points_from_xy(addlist['@lon'],addlist['@lat'])) 



read in the suburb boundaries:

suburbs = gpd.read_file('act_suburbs.geojson')

drop all of the tags that we will not need:

suburbs = suburbs[['name','geometry']]

then do the same for the post code boundaries:

postcodes = gpd.read_file('postcodes.geojson')
postcodes = postcodes[['postal_code','geometry']]

now we merge the three data sets together with a series of spatial 
joins. First the suburb names:


address_points = gpd.sjoin(address_points,suburbs,op="within")

the join creates a column we don't need so get rid of that:

address_points = address_points.drop(['index_right'], axis=1)

then join the post codes:

address_points = gpd.sjoin(address_points,postcodes,op="within")

we've now got all of the data into the one frame but we need to clean up 
the column labels before we write it out, so do a rename:


address_points = 
address_points.rename(columns={"name":"addr:suburb","postal_code":"addr:postcode"})


and we can then write out the columns we want to a csv file:

address_points[['@type','@id','@lat','@lon','addr:unit','addr:housenumber','addr:street','addr:suburb',
'addr:postcode']].to_csv('act_out.csv')

which gives you:

,@type,@id,@lat,@lon,addr:unit,addr:housenumber,addr:street,addr:suburb,addr:postcode
310,node,2441363738,-35.3076927,149.1333269,,7,National Circuit,Barton,2600
2280,way,564187362,-35.1539837,149.1117804,,5,Jimmy Little 
Street,Moncrieff,2914

4414,way,823380125,-35.2242021,149.0456133,,55,Ennor Crescent,Florey,2615
2249,way,547120674,-35.2540932,149.1531645,,24,Piper Street,Ainslie,2602
1548,way,220316259,-35.3349388,149.0923894,,27,Coxen Street,Hughes,2605
4511,way,847394981,-35.2353182,149.0470223,,2,Diggles Street,Page,2614
3747,way,796706631,-35.2288001,149.0513507,,4,Caddy Place,Florey,2615
555,node,4214686496,-35.318041,149.1264149,,39,Empire Circuit,Forrest,2603
3280,way,776943661,-35.4468204,149.1164925,,8,Mackerras 
Crescent,Theodore,2905

1052,node,7930404220,-35.1705767,149.0708312,,13,Gladstone Street,Hall,2618

I did this in an interactive ipython session, but if this is something 
people want it could be easily turned into a Python script that does the 
pull from overpass and writes out the file.


I did the whole country in one go to see how well it scales and the run 
time was pretty much the same. Of course you can't do postcodes for 
everywhere as we have put them all in yet.







___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Daniel O'Connor]

On Mon, May 24, 2021 at 8:59 PM Andrew Davidson  wrote:

> 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:
>

I'd make a polite argument there is still value in at least the suburb,
possibly postcode being still provided.  When exporting data via overpass
as CSV; it's not currently easy or obvious to appropriately bring in the
parent attributes; even if it is for a Real Human looking at the map.
There's a fair number of use cases for "data in a spreadsheet
friendly format" I feel.

Yes, it does come with a maintenance problem when suburbs change or
postcodes merge, but I feel that's one problem for one set of folks - us
maintainers - vs a repeated problem for many simple data consumers.
Ideally, as maintainers, we would over time semi automated this with
tooling (much like the proposed import)
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

21, at 2:05 PM, Graeme Fitzpatrick wrote:
> On this, I'm not sure if this may be an OSMAND problem, or an issue with the 
> way the info has been loaded in OSM, but here's something that I noticed a 
> few weeks ago, that may apply here?
> 
> Had to go visit a bloke for the first time, & his address is Watson Road, 
> Armstrong Creek:
> 
> https://www.openstreetmap.org/search?query=Watson%20Road%2C%20Armstrong%20Creek#map=17/-27.23885/152.81791
> 
> As you can see, Nominatim shows "Watson Road, Armstrong Creek, Kobble Creek, 
> Moreton Bay Regional Council", but when you look at Watson Road, all it says 
> is highway=tertiary + name=Watson Road, with no suburb / city, State or 
> postcode listed.

Nominatim shows at 
https://nominatim.openstreetmap.org/ui/details.html?osmtype=W&osmid=28276516&class=highway
 it's matching both admin boundaries, which is fair because the road separates 
the two boundaries. So addresses on one side of the street will be in one 
locality, and addresses on the other side, the other locality. Because you're 
just searching for the road and not a street number it returns both localities.

> In this area, Watson Road is the boundary between Armstrong Creek & Kobble 
> Creek "localities"
> 
> AC: https://www.openstreetmap.org/relation/11675264#map=13/-27.2282/152.7932
> 
> KC: https://www.openstreetmap.org/relation/11675296#map=13/-27.2679/152.8018
> 
> KC has also been created as a "village" 
> https://www.openstreetmap.org/node/310513460, although there is no village as 
> such, it's just an area name.
> 
> When I search via OSMAND though, it will find Watson Road, Kobble Creek, but 
> won't find Watson Road, Armstrong Creek? It will also find Kobble as a 
> suburb, & Kobbe Creek as a village, but won't find Armstrong Creek?
> 
> So, is this a peculiarity of the way the PSMA ADmn Boundaries have been 
> created, or something in OSMAND?

Maybe OSMAnd, I tried to search in the app but it was finding other results 
closer to me and not the ones you've listed here. If the address number was in 
OSM then it would probably start working as expected.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Graeme Fitzpatrick]

On Tue, 25 May 2021 at 12:06, Andrew Harvey via Talk-au <
talk-au@openstreetmap.org> wrote:

>
> From what I can see Nominatim pulls any parent place=* or
> boundary=administrative area. Which is fine, even though sometimes these
> boundaries or places don't form part of the postal address, it's harmless
> for data consumers to display these.
>
> Nominatim can and does correctly deal with addresses which have omitted
> these tags. I tried OSMAnd and it does seem to pickup the suburb from a
> parent boundary, and it seems to ignore postcode regardless of it being on
> a parent boundary, or addr:postcode next to the number/street.
>

On this, I'm not sure if this may be an OSMAND problem, or an issue with
the way the info has been loaded in OSM, but here's something that I
noticed a few weeks ago, that may apply here?

Had to go visit a bloke for the first time, & his address is Watson Road,
Armstrong Creek:

https://www.openstreetmap.org/search?query=Watson%20Road%2C%20Armstrong%20Creek#map=17/-27.23885/152.81791

As you can see, Nominatim shows "Watson Road, Armstrong Creek, Kobble
Creek, Moreton Bay Regional Council", but when you look at Watson Road, all
it says is highway=tertiary + name=Watson Road, with no suburb / city,
State or postcode listed.

In this area, Watson Road is the boundary between Armstrong Creek & Kobble
Creek "localities"

AC: https://www.openstreetmap.org/relation/11675264#map=13/-27.2282/152.7932

KC: https://www.openstreetmap.org/relation/11675296#map=13/-27.2679/152.8018

KC has also been created as a "village"
https://www.openstreetmap.org/node/310513460, although there is no village
as such, it's just an area name.

When I search via OSMAND though, it will find Watson Road, Kobble Creek,
but won't find Watson Road, Armstrong Creek? It will also find Kobble as a
suburb, & Kobbe Creek as a village, but won't find Armstrong Creek?

So, is this a peculiarity of the way the PSMA ADmn Boundaries have been
created, or something in OSMAND?

Thanks

Graeme
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Yuchen Pei]

Graeme Fitzpatrick  writes:

On Mon, 24 May 2021 at 21:29, Andrew Davidson 
 wrote:


Now that we've finished, people are wasting their time if they 
do.




Thanks, Andrew, I'll stop adding suburbs as I'm updating 
addresses!


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.



As somebody who uses OSMAND for navigation, I'd *really* like to 
have all

street addresses available!


Hear hear. I was forced to use some proprietary apps and maps 
several times because of lack of street addresses.




Thanks

Graeme
___
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

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Graeme Fitzpatrick]

On Mon, 24 May 2021 at 21:29, Andrew Davidson  wrote:

> Now that we've finished, people are wasting their time if they do.
>

Thanks, Andrew, I'll stop adding suburbs as I'm updating addresses!

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.


As somebody who uses OSMAND for navigation, I'd *really* like to have all
street addresses available!

Thanks

Graeme
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Bob Cameron]

Hi Andrew

Wonder if you might add the following to your later communications with 
NHVR. Not pressing, just an inclusion.


As I understand it formal heavy vehicle rest area locations are more a 
state database system. The "three green dot" informal rest areas however 
were/are a NHVR initiative. If they have a (changing) data base of these 
locations It might be handy if they were also imported.


Tnx Bob

On 18/5/21 10:23 pm, Andrew Harvey via Talk-au wrote:


I'm working with the National Heavy Vehicle Regulator (NHVR) on a 
proposal to import Vicmap addresses for Victoria into OSM. For 
context, here is the statement from the NHVR.




___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [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.


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Andrew Harvey via Talk-au]

On Fri, 21 May 2021, at 4:48 PM, Graeme Fitzpatrick wrote:
> With regard to postcodes how does it work when there are 2 postcodes out of 
> the same mail centre?
> 
> EG Gold Coast Mail Centre at Bundall is postcode 4217, but the GC City 
> Council, which is in that area, has its own postcode 9726?
> 
> I'll assume that this isn't limited to GC, so would that cause any issues?

I think from the analysis I just posted, it's not an issue in Victoria, except 
for 3000 and 3004 which are different parts of the same suburb.

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Sebastian S.]

Hi Andrew,
Great interaction and transparency!

I have not read the code, will have a look but not sure how much I will 
understand. Therefore I'm asking how do you determine the location of the POI 
to be added?

In the NSW the address data was part of an area of the plot of land the address 
is for. So as part of the import process the area was converted to a node 
location.
Long driveways or other thin parts of the plot resulted in the node often being 
outside of the actual area.

Also most plot of lands have the house towards one end and garden in the other. 
This results in the node outside of the building.

I assume that you do not intend to manually correct node locations such that 
they are on top of an unit.


On 19 May 2021 11:26:57 pm AEST, Andrew Harvey via Talk-au 
 wrote:
>I've started to summarise the general consensus to some of the import
>questions at https://gitlab.com/alantgeo/vicmap2osm#community-feedback.
>
>Another thing is where someone has mapped an address with
>housenumber=2/5, but Vicmap is indicating it's unit 2 number 5, we
>convert this to addr:unit=2 addr:housenumber=5. This is slightly
>overstepping simply importing Vicmap data, to changing existing data in
>OSM (which mostly for the rest of the import, if OSM says something
>different we flag it for manual review), so I'm happy to also skip
>this.
>
>However, given X/Y usually means unit/number, and then only where
>Vicmap data confirms this, and given addr:unit is a widely used tag for
>unit value, I feel it's probably best we do this.
>
>Soon I'll share some links to actual maps and data that show exactly
>what would be changes so we can do more QA.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[cleary]

I think I recall discussion some months ago about incorrect suburbs being 
assigned addresses in Nominatim when relying on suburb boundaries. I think I 
recall that most errors occurred near the boundaries rather than the centre of 
areas, and more often when the suburb has an irregular shape (not many suburb 
areas are even close to rectangular in shape). Therefore I would support 
inclusion of the suburb/town/hamlet in  addresses to ensure accuracy.  

In regard to addr:suburb and addr:city,  I have always tried to match the 
address with the designation in OSM. So if an address is in a bounded area 
identified as "place=town" then I added addr:town=*  or for a hamlet it would 
be addr:hamlet=*  etc.   Localities are by definition, unpopulated places so it 
would be unusual to have addr:locality=  as almost all "localities" would be 
small places located within bounded areas such as hamlets, towns, etc.   
Bounded areas that have no shops, schools, amenities (or almost none) would 
usually be place=hamlet  as they are identified bounded areas usually with a 
population. For the purposes of the import, it might be too diffiicult to 
separate OSM's various place classifications city/suburb/town/village/hamlet 
etc so I would support  addr:suburb=* as better than nothing.

I would also support adding postcodes.  I am more familiar with NSW than other 
states but there are three bounded areas in NSW named Kingswood differentiated 
only by their postcodes and local government areas. Similarly I know of two 
bounded areas in NSW named Long Plain. I think there are others but they don't 
come readily to mind. However I think it emphasises the usefulness of postcodes 
in addresses.




On Wed, 19 May 2021, at 2:48 PM, Andrew Harvey via Talk-au wrote:
> 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.
> 
> 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`?
> 
> `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).
> 
> 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@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-au
> 

___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Joseph Guillaume]

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,  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 th

Re: [talk-au] Victorian Vicmap Address Import Proposal

[Sebastian Spiess]

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=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@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au


___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au