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
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
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
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
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
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
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
> 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
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
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,
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
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
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
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
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
>
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
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
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
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
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
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
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
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?
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
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
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
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
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
28 matches
Mail list logo
