> > OHM was in a position where a new hosting arrangement needed to be worked > out, when a major server crash occurred. so we were literally twisting > in the wind > until those issues were resolved. there is no real external support for > the project > so we couldn't just go out and rent a server or VM somewhere. > > the previous backup arrangements were inadequate, and files were truncated. > so i think 6-9 months worth of data (maybe 12 months) was lost. i'm in the > process of assessing what work i need to personally redo, but it doesn't > look > all that bad. i am working with Rob Warren on setting up a stronger backup > plan - but even if we'd had a stronger backup plan, the need to rehost OHM > would still have been an issue. >
Ok, good point ...but the result of these unafortunate facts is...lost information and the worst : lost collaborative work. And it is a reality: the information about parking would be lost if "unafortunate things" happened and the information was saved as OHM was. I think all the information is important, and the best way to keep it secure, updated and completed is the same database. > > there are some advantages to a separate OHM. > > a large part of the community thinks OSM should only be about current > data. if we started seriously doing the things we want to do in OSM, it > would > be pretty controversial with a potential risk of an edit war. > > OHM can be a playpen for experimentation. i wish to work on a schema for > relations so that i can describe the movements of troop units in campaigns > and battles. again, if i started doing this in OSM, i imagine that the > unhappiness > would be extensive, and given the other goals of OSM, it's not really a > good > place to play. > > there is a need for need for tagging extensions for historical mapping. > this is > a tricky one. historical mapping needs some temporal language for which > current OSM tagging is completely inadequate. and given how the tagging > discussion goes some times, i think the tagging list is the completely > wrong > place for such discussions - but if we are trying to keep historic data > in OSM, > this is where we would have to have it. > OK, with new tags, with new values, with new behaviour, but not outside OSM data because if there would be another "accident" or unafortunate facts the information will be inside OSM and other can start another render with these information. Think about Wikipedia: is wikipedia divided in kinds of information? All are at the same system, You have some portals but all the information is at the same place (for this reason an image in wikipedia is uploaded to commons). Historic information is so important...that I think all has to be at the same place (data). Renders is other thing, you can make whatever you want, featuring the information you want to. > > so from my point of view, keeping the historic data in its own place is > part of > trying to keep OSM peace. did we have some problems? yes. are they > correctable? > yes. i think some lessons have been learned, but our takeaway is very > different > from yours. I don't know what is your takeaway. I'm a user, I'm a mapper, I'm a man who loves the history and I want that all my possible future work and the others won't be lost, and will be accessible...forever. Because that is about history. So more information, more historical information about refs would be interesting in OSM with the correct keys and values. Salut i història (Health and History) yopaseopor
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
