Hi Sam, I'll try to keep it short, and I won't crosspost to Imports and OSM dev Sherbrooke. Only the original message was posted to those lists as well, since there have been Canvec-related discussions on them in the past.
> What was not mentioned is that CanVec is just 1 of the many datasets > that are available. > The focus of the meeting, and of my previous e-mail was predominantly on Canvec. Trying to do everything at once, means that in the end nothing at all is done. I know that there is more data out there. > Do you want to set up a 'post process' national database as a > repository of data? > Then a web interface to handle it all? (perform the on-demand internal > conversion) > What I want is something that works for all of us. Obviously I can't, and won't decide that on my own. Anyways, something similar in nature as what Emilie showed, is the way to go. We all concluded that. I haven't had the occasion to have an in-depth look at it, but from what I understood a user could select a particular area. He could convert the data to OSM. During this the data is split into 3 categories, depending on overlap with existing OSM data. Data without any overlap was imported automatically (although triggered by human action), and the rest was imported "manually". The conversion was already done, and the changes made available somehow. > Before, i did recommended that internationally, we have a > 'post-OSM-importable-data' database'. but my voice wasnt understood > What do you mean by that? The file repository on Mediafire you created? And in particular, the resulting files after OpenJump / Roadmatcher has been applied to Geobase input data, which were later converted to OSM files? Or possibly also the files of the simplified process, in which data is copied over manually? To be fair, I kinda liked the latter process. My experience with OpenJump / Roadmatcher wasn't that it was worth the effort (due to ending up adding / removing many nodes, and retiring ways myself), compared to the simplified process. However, there is no way to revisit the data, even not if you make the files available. It is very easy to forget roads during the import, so you end up adding scattered roads later. > (because i can see the project on an overall scale, and most people, > just focus on their local area) :-) ...oh well, like frank said, i > suck at communicating. :) > Thank you very much for rephrasing my words, I do appreciate that. Anyways, you just came to the conclusion that your voice wasn't understood. This has everything to do with your communication style, and you know that. Anyways, there is no point in debating this further, and if you still think you should, please keep it off the list. > Its similar in concept to OpenAerialMap) > What role does OpenAerialMap suddenly play here? It is as if a number of steps in your thought process are skipped, so I got lost. > This way, it becomes a true 'community effort' for actually getting > the data from the web-interface to OSM. > > The technical part of the back-end database 'warehouse', maybe thats > something we can check with the OSGeo Community, as that is what they > are working on. (where the imports@ list becomes a point of contact > with the OSGeo community, Sure. We should reuse as much as possible, otherwise it will be too much work. Many people have developed excellent, useful tools. The Imports, and also the Dev list will be involved when necessary, but they don't need to follow each single step we're making. By the way, the Imports list is an OSM list, and does not have direct contact with OSGeo, which is a different entity: [1] > since that database will not be 'tainted' or > 'improved' (depending on your POV) > You lost me again. Regards, Frank [1] http://www.osgeo.org/ _______________________________________________ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
