Hi All, We expect to encounter the same problem at the NHVR if we begin to use OSM.
My (possibly unfounded) initial thoughts are based around linking the OSM & Source feature outside OSM in something similar to a "join" table. The join might be on attribution (id), geometry or both. Then, you have to accept that the link/join will break and a process is needed to detect breakages when they happen so they can be repaired (a mix of automated & manual). Someone else might be able to comment on this with more clarity. The way I see it, you can't stop the breakage. You have to accept it and deal with change. A Hughes On Sat, 18 Jul 2020 at 23:10, Sebastian Spiess <[email protected]> wrote: > On 9/7/20 7:52 pm, Mateusz Konieczny via Talk-au wrote: > > > > > Jul 9, 2020, 06:50 by [email protected]: > > Hi, > Bicycle Network Tasmania are trying to improve the quality of cycling > infrastructure information in OSM. > Much has been done by volunteers in various jurisdictions, and we have > done lots locally, but the tagging is quite complex for cycle paths and not > always correct. > Local councils are responsible for much of the infrastructure, but they > usually have little interaction with OSM. > It would be most efficient if the councils GIS data worked in tandem with > OSM data so that they kept each other up to date, each storing the info > that is most useful for them. For instance, for bike parking, there is > little utility in OSM storing the asset numbers and other info that the > councils use to maintain their assets (although the ref tag could be used > as a foreign key to help keep the two in sych). > The Hobart councils we work with are concerned with the quality of the > data in OSM and the ability of anyone to change it. > Does anyone know of any examples we could learn from of local government > itself working to keep OSM data up to date? > Thanks. > > One of the easiest things that local government may do is to > > 1) publish their datasets on an open license allowing to use it by mappers > 2) react to reports of mistakes in their data > > Both work relatively well in Poland for address data - with publishing > required by > national law (though still ignored be many local governments) > > Note that (1) is useful for mappers even if data quality is unsufficient > to import it > into OSM. I am using a bit noisy bicycle parking in locating unmapped ones > (often location, description and real location mismatches significantly, > but > almost always it allows me to find something that was missing in OSM) > > _______________________________________________ > Talk-au mailing > [email protected]https://lists.openstreetmap.org/listinfo/talk-au > > Hi, indeed great to see you reach out. > > Yes I agree that a good approach is to make the data open. However, I > understand Greg is asking if there are working concepts on how to maintain > a link between local government GIS (which might have additional > information) and OSM data. > > Once the relevant information has been entered into OSM, how is the > council to track the data? e.g. to see if tags get modified, nodes moved, > added. > > e.g. worst case is that a nicely mapped and tagged area gets re-done by > someone. This results in new node and way numbers. > > A good example would be a single node gets expanded by OSM users. > > In both cases the data is diverging from another. How to keep track? Are > there concepts/solutions? > > Yes > _______________________________________________ > Talk-au mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/talk-au >
_______________________________________________ Talk-au mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-au
