Hi Martin, I think the OSM plugin has to be improved, and it's a good news if you have started a new architecture.
Can the plugin be extracted from the core? For the edit purpose, I think it's an important feature because gis user don't want to use an other software than the one they use for gis data. ArcGIS users are happy to have an OSM plugin to update data. But if the new OSM plugin can be regularly updated, it can start without. Cheers, René-Luc Le 1 févr. 2013 01:26, "Martin Dobias" <wonder...@gmail.com> a écrit : > Hi > > recently I have started to think about the future of the OpenStreetMap > plugin we currently ship with QGIS. The plugin (~2K lines of c++ and > ~6K lines of python) supports downloading, viewing, editing and > uploading OSM data. My concern is that it has received little to no > updates from the time we have imported it to QGIS tree back in > mid-2009. Given that it is not being maintained and the issue tracker > reveals several major bugs, I have started to wonder how useful it > actually is in its current form and what could we do about it. > > There are few other things apart from lack of maintenance that need fixing: > - it has a special provider because data are stored in custom sqlite3 DB > - data access logic is spread through either provider and plugin > - working with tags (aka attributes) is VERY inefficient > - there's no API that could be used for scripting / analyses > - it mixes topology with simple features > - using custom hardcoded old symbology renderer > - some hacks here and there (e.g. messaging from long-running XML > import in provider, "all tags" attribute) > > Currently my thoughts are that we should simply remove the plugin > because fixing its problems would need huge amount of time. In > meanwhile I have started to play with an idea of fixing the > architecture with the following ideas: > 1. import from XML to database should only import the topological > structure and tags (and relations), without post-processing that would > create simple features representations. > 2. instead of having a special provider, we could reuse an existing > provider for viewing OSM layers - SpatiaLite seems to be the most > viable candidate. Once data is imported from XML into a database, it > should be possible to create one or more views (SpatiaLite tables) of > the database (e.g. all polygons or linestrings with "highway" tag) > 3. OSM-related code should be in analysis library. providing > c++/python API. In this way, other plugins/scripts could do automatic > processing without having to deal directly with OSM XML or some > database calls. Extraction of data should require just few lines of > code. > > I have a working proof of concept (<1K lines of code) and it looks > good - it's fairly simple and fast. For example, import of Essex > county data (2135K nodes, 203K ways, XML size 420MB), including > creation of SpatiaLite layers took less than 3 minutes, the subsequent > map viewing was as fast as any other SpatiaLite data. There's just one > catch (there always is, right?) - it does not support editing and I am > not even considering adding it myself. OSM editor would be a big > project and it would take ages to get at least close to the editing > experience of specialized editors such as Potlatch or JOSM. And > frankly, is there anyone using QGIS OSM plugin for editing? > > What are your thoughts and wishes on QGIS - OpenStreetMap integration? > > Regards > Martin > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
