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 <andrew.harv...@gmail.com> wrote: > > On Wed, 10 Oct 2018 at 16:29, Ewen Hill <ewen.h...@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.
_______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
