[talk-au] PSMA Administrative Boundaries
Andrew Harvey
andrew.harvey4 at gmail.com
Wed Oct 10 08:04:07 UTC 2018
On Wed, 10 Oct 2018 at 16:29, Ewen Hill <ewen.hill at gmail.com> 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 worked it
> and what lessons they learned.
There's some material at https://wiki.openstreetmap.org/wiki/Import
> My plan would be to make a web based system outside OSM by having an
> external web db having both the PSMA and the current OSM suburb level data.
> Both would be updated daily automatically and identify
> 1. Where the PSMA is completely missing from OSM
> 2. Where OSM data is completely missing from PSMA or duplicated (two suburbs
> of same name) or broken.
> 3. Where there are significant differences in size or overlap of the
> polygons (sorted in order of mismatch)
> 4. Where there are small differences that can be taken as creek alignment or
> a new roundabout and could be flagged as potentially a false positive.
>
> In that way, we can attack the list, suburb by suburb from 1 to 4. A map
> could be made of the the PSMA location and have all associated nodes and
> ways displayed and mathematically provide a best solution for the editor to
> consider. It may use portion or entire existing lines or it may be easier
> just to down load the new suburb and have the other suburbs meet it
> manually.
>
> Once the editor has decided the approach, it creates a data set and then
> sends them to their prefer editor to make sure all is good. The old boundary
> is tagged as well as the new one correctly.
>
> The entire system doesn't need to be built immediately, just the variation
> list perhaps. Happy to help further.
>
> This process removes a lot of risk out of the equation and allows for
> constant monitoring however is clerly slower than a bulk update by state.
>
> Your thoughts?
I think since for the most part at least, the data is either in OSM or
not when you break it down by state, I'd be +1 for importing on a per
state basis initially.
Each quarter as the upstream data gets updated, then we can go through
the manual process of patching the changes.
If you want to build a GUI around that, I think that's fine, but I
don't think it's required to bring this data in.
More information about the Talk-au
mailing list