On Fri, 18 Sep 2020 at 21:25, Andrew Davidson wrote:
> On 17/9/20 5:36 pm, Andrew Harvey wrote:
> >
> > So while I'd prefer using ref: I guess some psma specific tag
> > could be okay.
>
> Do you have a preference between ref: and note: ?
>
I can't decide, so I'm happy with whatever you or
On 17/9/20 5:36 pm, Andrew Harvey wrote:
So while I'd prefer using ref: I guess some psma specific tag
could be okay.
Do you have a preference between ref: and note: ?
So you're suggesting 1) uploading duplicate state borders, and then
cleanup after import or 2) doing the upload so that it
On Wed, 16 Sep 2020 at 20:07, Andrew Davidson wrote:
> On 15/9/20 10:53 pm, Andrew Harvey wrote:
> >
> > 1. psma:loc_pid. Where this is a stable ID that is used as a reference,
> > the existing ref tag is better for this. If we want to be more specific
> > then ref:psma or something like that
On 15/9/20 10:53 pm, Andrew Harvey wrote:
1. psma:loc_pid. Where this is a stable ID that is used as a reference,
the existing ref tag is better for this. If we want to be more specific
then ref:psma or something like that would work. No need to invent new
tags here when one already exists,
On Wed, 16 Sep 2020 at 10:44, cleary wrote:
> Thanks to both Andrew Davidson and Andrew Harvey for their work as I see
> addition of PSMA administrative boundaries as an important improvement for
> our map.
>
> In regard to adding source tags to objects, I find them very helpful when
> editing
Thanks to both Andrew Davidson and Andrew Harvey for their work as I see
addition of PSMA administrative boundaries as an important improvement for our
map.
In regard to adding source tags to objects, I find them very helpful when
editing something. If I think I have contrary information, I
Resurecting this old thread as Andrew Davidson has been working on this
import plan a bit more ->
https://wiki.openstreetmap.org/w/index.php?title=Import%2FCatalogue%2FPSMA_Admin_Boundaries=revision=2034132=1918537
Surfacing a few points from my review:
1. psma:loc_pid. Where this is a stable ID
I do remember that problem, getting it fixed should be great.
Then we should start to make plans, I assume the work-flow would span
multiple days so that we can do things removing the old boundaries, right?
On 20/12/18 3:54 pm, Andrew Harvey wrote:
> Just posting any questions here, works for
Just posting any questions here, works for me.
I lost time to work on this, but I'm back again with free time heading
into the holidays.
I thought we still had some issues with the .osm files, specifically I
needed to increase the generalisation to try to ensure ways that
should be snapped are
I have a few remaining tagging question left to answer and the workflow
still needs to be written up (and agreed on). Other than that, I think
we're all good to go.
Not wanting to hijack the project I've been a bit unsure on how to push
this import over the last hump. I could write up a list
Hmm, It's been almost a month since the last message in this
import-related thread. I hope for a date planned so we can follow
through with the plan, since it seems pretty complete.
If Andrew Davidson is still interested, his script could help match and
add the nodes into the relationships and
Planning for the import is not finished yet, so please wait until after
that.
On Mon, 19 Nov 2018 21:23 Lee Mason I am prepared to make a start on the Tasmania import over the next few
> days, unless there is some further discussion?
>
>
>
___
Talk-au
Ok!
From: Andrew Davidson
Sent: Monday, November 19, 2018 9:45:24 PM
To: Lee Mason
Subject: Re: [talk-au] PSMA Administrative Boundaries
Planning for the import is not finished yet, so please wait until after that.
On Mon, 19 Nov 2018 21:23 Lee Mason
I am prepared to make a start on the Tasmania import over the next few days,
unless there is some further discussion?
From: Joel H.
Sent: Wednesday, November 7, 2018 2:57:45 PM
To: talk-au@openstreetmap.org; Andrew Harvey
Subject: Re: [talk-au] PSMA
Just downloaded to take a look, Most seem right.
In order to QA something like this, taking random samples won't help
since any number of errors would be small.
Does the script currently check for a byte-to-byte match of the name=*
text? I think that should be the determining faction of adding a
If you want to start working on something I have had a go at matching
place nodes:
http://overpass-turbo.eu/s/Dy3
with the corresponding admin_level 10 boundaries:
https://github.com/FrakGart/TestAdmin10Labels
These have been matched by finding the best matching place node by name
within a
How are we with our import plan on the wiki, Do we have any blockers
stopping the PSMA import?
I think we should start setting dates state-by-state for import.
___
Talk-au mailing list
Talk-au@openstreetmap.org
Thanks for expressing interest!
The integration will mostly involve... (and I'm going to specify this on
the wiki when I get a chance.)
- Changing the place=* tags on the boundaries to match the nodes that
are already in OSM (e.g. Gold Coast should be changed from
place=municipality to
Hi Joel
Happy to help with Gold Coast area if there's anything I can do.
I only use iD though, not JOSM, so don't know if that's a problem?
Thanks
Graeme
On Tue, 30 Oct 2018 at 21:13, Joel H. wrote:
> I've put my self down for integration in QLD.
>
I have edited the wiki with a table relating to the team approach, It's
rough but it shows who is doing what.
I have enlisted Andrew Harvey as the uploader/account holder. I've put
my self down for integration in QLD. I'm hoping that others can handle
integration in their own states and put names
Just for the record, be very careful removing level 10 boundaries around
QLD, PSMA appears to be missing a few around central QLD.
I'm going back now and reverting bad changes.
On 23/10/18 10:25 am, Andrew Harvey wrote:
> I see, thanks. It's in the original non-simplified files too. It can
> be
I see, thanks. It's in the original non-simplified files too. It can
be manually fixed, but just adding a shared node is not the right fix,
we need to snap the nodes and then removed the shared ways.
We should be able to fix this in the processing scripts by increasing
the tolerance that things
Not sure why I can't find it on the list archives but there was some
discussion about this below. In short, I'm in favour of not uploading
duplicate state borders and during or post-import we manually fix up
the relations to use the existing state boundaries.
On Thu, 18 Oct 2018 at 12:35, Andrew
One last note (and I don't know if this has been mentioned already).
But it seems that the State boundary (at least on the QLD/NSW boarder)
doesn't match up precisely with what we already have in OSM. Should we
remove the outer edges of the PSMA data and then add existing state ways?
On 22/10/18
Per the import guidelines
https://wiki.openstreetmap.org/wiki/Import/Guidelines I've requested a
review from the wider imports mailing list at
https://lists.openstreetmap.org/pipermail/imports/2018-October/005760.html
On Mon, 22 Oct 2018 at 14:40, Andrew Harvey wrote:
>
> > I don't know if this
> I don't know if this was introduced in the simplification or it was an
error with PSMA. But there is only 26 of these errors in QLD so I would
hardly call this an issue, you can easily fix these manually.
I'm not sure either, so unless there's a better/automated way, let's
just address this
Is there a problem with crossing ways? Why do they need a shared node when
they are different admin levels?
On Fri., 19 Oct. 2018, 5:56 pm Joel H., wrote:
> Just took a look at the crossing boarders without ways error, and it
> seems some level 10 boundaries are indeed overlaping. Check out
>
Just took a look at the crossing boarders without ways error, and it
seems some level 10 boundaries are indeed overlaping. Check out
-22.5639465 147.0726169 in Queensland.
As for way too long, I also don't think that needs fixing, just some
automated JOSM warning not taking context into
I tried to find out more about two JOSM warnings but I couldn't.
1. Way segment too long
What's wrong with long way segments? I'm not convinced we should add
nodes where they aren't necessary for detail.
2. Crossing borders without a shared way.
This should only happen when you have an LGA
On Wed, Oct 17, 2018 at 6:29 PM Andrew Harvey
wrote:
>
> So I guess at this point do people want to checkout the simplified OSM
> files for any issues?
>
> They look OK, but I would like to have an opportunity to clean up the JOSM
warnings before we upload them (except the relations with the
On Wed, Oct 17, 2018 at 6:29 PM Andrew Harvey
wrote:
> I'm in favour of first manually removing the
> state borders so we don't dump more nodes on top and then post-upload
> we can just join the new relations to the existing state borders where
> they meet.
>
I can see your point about not
I've reprocessed these files again, I have simplified versions, which
cut the number of nodes with not much loss in detail:
Original full resolution: https://tianjara.net/data/PSMA_AdminBdy_OSM/
Simplified: https://tianjara.net/data/PSMA_AdminBdy_OSM_Simplified/
Andrew Davidson has been testing
OK, just tell me when you are ready, and I'll clean up QLD ready for
import.
On 14/10/18 10:46 pm, Andrew Harvey wrote:
> On Sun, 14 Oct 2018 at 21:15, Joel H. wrote:
>> Hey Andrew,
>>
>> Today on the QLD slack, I had a local mapper ask me about suburb areas.
>> I personally think it would be an
On Sun, 14 Oct 2018 at 21:15, Joel H. wrote:
>
> Hey Andrew,
>
> Today on the QLD slack, I had a local mapper ask me about suburb areas.
> I personally think it would be an opportune time to start on the QLD
> import at least.
>
>
> What is the status on the PSMA data? Is it ready to import, and
Hey Andrew,
Today on the QLD slack, I had a local mapper ask me about suburb areas.
I personally think it would be an opportune time to start on the QLD
import at least.
What is the status on the PSMA data? Is it ready to import, and is
anything holding us back?
In the meantime, I have run
Let's try to document things on the wiki
https://wiki.openstreetmap.org/wiki/Import/Catalogue/PSMA_Admin_Boundaries
to help document, it's open to all to edit.
On Wed, 10 Oct 2018 at 19:04, Andrew Harvey wrote:
>
> On Wed, 10 Oct 2018 at 16:29, Ewen Hill wrote:
> >
> > Good afternoon all,
> >
On Wed, 10 Oct 2018 at 16:29, Ewen Hill wrote:
>
> Good afternoon all,
>Firstly, I assume that this has been an issue elsewhere in the world
> where a large body of official data over a wide area needs to be integrated.
> Is there a way of going out to other countries and seeing how they
On Tue, 9 Oct 2018 at 20:51, Andrew Davidson wrote:
> One question would be should we be putting a place tag on admin
> boundaries? According to taginfo only 34% of admin_level=10 has a place
> tag.
I say yes since these suburbs are an area not a single point.
> > - how we'll manage that upload
Good afternoon all,
Firstly, I assume that this has been an issue elsewhere in the world
where a large body of official data over a wide area needs to be integrated.
Is there a way of going out to other countries and seeing how they worked it
and what lessons they learned.
My plan would be to
Good, doing country wide I think would have been a pain. I just tried
QLD and all is looking good except the boundaries which extend into the
ocean.
Are you going to do the upload? And when should we do it?
On 9/10/18 6:19 pm, Andrew Harvey wrote:
> On Tue, 9 Oct 2018 at 13:10, Andrew Harvey
Brisbane, the LGA comprises the mainland and all
islands above their respective sea-shores within the encompassed area.”
From: Andrew Davidson<mailto:thesw...@gmail.com>
Sent: Tuesday, 9 October 2018 20:56
To: talk-au@openstreetmap.org<mailto:talk-au@openstreetmap.org>
Subject: Re: [t
On 07/10/18 23:27, Lee Mason wrote:
Nice work on cleaning up the PSMA data, Andrew. It looks a lot easier to
manage for importing now.
A quick look at the data, and it appears there is some regional/state
variance in the boundaries:
Some of the WA LGAs extend out to the coastal waters
On 07/10/18 18:32, Andrew Harvey wrote:
I see the next steps are to:
- discuss if this is the right format for upload or not,
One question would be should we be putting a place tag on admin
boundaries? According to taginfo only 34% of admin_level=10 has a place
tag.
- how we'll manage
On Tue, 9 Oct 2018 at 13:10, Andrew Harvey wrote:
> By state https://tianjara.net/data/PSMA_AdminBdy_OSM/
Just a note that I've just updated these files, to remove duplicate nodes
Another issue is I've applied place=suburb to these
Suburbs/Localities, but in many cases they'd probably be better
By state https://tianjara.net/data/PSMA_AdminBdy_OSM/
On Tue, 9 Oct 2018 at 05:36, Andrew Harvey wrote:
>
> I realised the JOSM PBF plugin doesn't like negative IDs. However
> there are duplicate nodes, so i'm re-processing to fix this. I'll also
> split it up by states. Originally I was
I realised the JOSM PBF plugin doesn't like negative IDs. However
there are duplicate nodes, so i'm re-processing to fix this. I'll also
split it up by states. Originally I was hesitant at doing that since
you want shared borders, but we're going to want to reuse the existing
state boundaries so
>discuss if this is the right format for upload or not
I found that GeoJSON file you sent worked best for me. Otherwise we
stick with .osm for OSM. I'm having trouble with that PBF file you sent
(or I don't have enough memory (I have 8GB))
>how we'll manage that upload in terms of breaking it
(including the
contained localities).
Cheers
Lee
From: Andrew Harvey
Sent: Sunday, October 7, 2018 6:32:02 PM
To: OSM Australian Talk List
Subject: Re: [talk-au] PSMA Administrative Boundaries
I've approached this from the angle of what we'd need to get
I've approached this from the angle of what we'd need to get the data
to look like if importing as is into OSM. I couldn't find any tools
which correctly ensure that boundary ways were shared via relations
instead of duplicated so I wrote some new tools. The process I used is
documented at
I'll look there. Thanks.
On Sun, Oct 7, 2018, at 12:31 PM, Warin wrote:
> On 07/10/18 11:22, cleary wrote:
> >
> > In regard to admin boundaries sharing the coastline, I think that would
> > also be incorrect but I am less confident of my view on this.
> >
> > I did update some administrative
PS While on coast lines ... computer model of the Kimberly coastline
over a few thousand years.. looks like it is breathing.
http://www.abc.net.au/news/2018-10-07/wa-coastline-transformed-by-sea-levels-over-thousands-of-years/10338500
On 07/10/18 11:22, cleary wrote:
In regard to admin
On 07/10/18 11:22, cleary wrote:
In regard to admin boundaries sharing the coastline, I think that would also be
incorrect but I am less confident of my view on this.
I did update some administrative boundaries in South Australia using the SA
Government Data and those boundaries did not
In regard to admin boundaries sharing the coastline, I think that would also be
incorrect but I am less confident of my view on this.
I did update some administrative boundaries in South Australia using the SA
Government Data and those boundaries did not coincide with the coastline (see
the
On 06/10/18 21:34, Andrew Harvey wrote:
Thanks for raising that. I'd seen some boundaries in WA defined in
legislation as, follow this road, then that road etc. but I think that
was for school zones. So the LGA and Suburb/Localities are defined by
the cadastral plans then?
I hear the points and
Thanks for raising that. I'd seen some boundaries in WA defined in
legislation as, follow this road, then that road etc. but I think that
was for school zones. So the LGA and Suburb/Localities are defined by
the cadastral plans then?
I hear the points and see there is consensus to not reuse
On 06/10/18 20:52, cleary wrote:
In regard to administrative boundaries being attached to other features such as
waterways and roads, I think it is a trade-off between accuracy and convenience.
+1.
If the admin boundaries use other features as there boundaries then it is the
other feature
In regard to administrative boundaries being attached to other features such as
waterways and roads, I think it is a trade-off between accuracy and
convenience.
I am most familiar with NSW. Boundaries are not "defined" by words but rather
by surveyors' charts. The surveyors may often have
>Do you have examples of the overlapping ways? It looks pretty okay
around Brisbane to me. Here's an a mesh of the LGA's in GeoJSON which
you can import into JOSM with enough memory.
https://tianjara.net/data/LGA_mesh.geojson.xz
Just import the shapefile into JOSM and use the validation. The
On Sat, 6 Oct 2018 at 15:57, Joel H. wrote:
>
> OK everyone I am currently editing the LGA shapefiles for QLD so no one
> should attempt as to not create conflicts (although I'm not currently working
> on the suburbs file).
Don't worry, no one should actually be doing any importing until we
On Fri, 5 Oct 2018 at 11:43, cleary wrote:
> A month ago, we celebrated the news that OSM now has approval to use the PSMA
> Administrative Boundaries and there was some discussion, including the need
> for a proper import process. I am willing to start adding some boundaries in
> areas with
OK everyone I am currently editing the LGA shapefiles for QLD so no one
should attempt as to not create conflicts (although I'm not currently
working on the suburbs file).
The PSMA data isn't good IMO. And requires a lot of fixing to be
imported, lots of problems with overlapping ways.
But the
Hi cleary (and everyone),
This is excellent news, I wasn't aware of this. I think this is great
and would be interested in importing Queensland's
My first though is to add a fixme notice (in similar fashion to the NSW
import), that tells us to reconsider the place label node already in
OSM, and
A month ago, we celebrated the news that OSM now has approval to use the
PSMA Administrative Boundaries and there was some discussion, including
the need for a proper import process. I am willing to start adding some
boundaries in areas with which I am familiar/interested but I am waiting
for
Good to see there is a lot of interest in this. Local knowledge is going to
be key to ensuring success if we undertake work to bring this into OSM.
On Fri, 31 Aug 2018 at 16:45, Ewen Hill wrote:
> I would like to aski if it is possible to
> 1. add the ability to have, possibly at [*5*], the
Yes, good work getting the waiver. I would also agree not to include electoral
boundaries. And my primary interest would also be Tasmania.
The state (and probably more broadly) already has a comprehensive naming of
localities and suburbs from surveys, but mostly from the GeoScience Australia
Permission to include the PSMA Boundaries in OSM is great news.
In regard to questions and comments from other mappers:
- I find the current boundaries in NSW and SA to be useful i.e. include
LGA and suburb/locality. However, electoral boundaries including
local government wards seem very
On 31/08/18 17:20, Andrew Davidson wrote:
On 31/8/18 16:23, Andrew Harvey wrote:
(not sure why the split across 9 and 10...? but it looks like no data
for 9
and all suburb/localities are marked as 10, a separate discussion but
perhaps they should be 9 and smaller neighbourhoods be in 10?)
On 31/8/18 16:23, Andrew Harvey wrote:
(not sure why the split across 9 and 10...? but it looks like no data for 9
and all suburb/localities are marked as 10, a separate discussion but
perhaps they should be 9 and smaller neighbourhoods be in 10?)
Level 9 appears to have been intended for
Hi Andrew,
I am happy to help out BUT, I have never done any imports previously so it will
be a cautious approach from me. My main interest is in Tasmania.
Cheers - Phil,
On the road with his iPad
> On 31 Aug 2018, at 4:23 pm, Andrew Harvey wrote:
>
> The Department of Industry,
Andrew,
Thank you for all the hard work and achieving this key element. I would
like to look at all level numbers to standardise these and to go forward.
Also happy to have a dabble of the import process and associated doco.
I would like to aski if it is possible to
1. add the ability to have,
The Department of Industry, Innovation and Science which manages data.gov.au
have just completed the OSMF CC BY waiver allowing the PSMA Administrative
Boundaries[1] to be used within OpenStreetMap[2].
Quoting their email, "The Australian Government received great
encouragement from PSMA
71 matches
Mail list logo
