+1 if SAGA devs are not interested to merge in QGIS, I strongly suggest to just fork a stable version shipped with qgis (as proposed in this thread), but NOT to integrate the algs in qgis. I prefer to fix API changes with fixed time frame (on demand) than maintaining a large bunch of code.
cheers Luigi Pirelli ************************************************************************************************** * Boundless QGIS Support/Development: lpirelli AT boundlessgeo DOT com * LinkedIn: https://www.linkedin.com/in/luigipirelli * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli * GitHub: https://github.com/luipir * Mastering QGIS: https://www.packtpub.com/application-development/mastering-qgis ************************************************************************************************** On 1 June 2016 at 15:05, Martin Dobias <[email protected]> wrote: > Hi > > On Wed, Jun 1, 2016 at 2:16 PM, Neumann, Andreas <[email protected]> wrote: >> >> If you guys think about integrating SAGA closer into QGIS, could we also fix >> the issue that SAGA is currently limited to reading Shapefiles for vector >> input? Probably a lot of work - but would this be feasible? > > After last year's hackfest in Nodebo just out of curiosity I was > looking at the feasibility of replacing SAGA's native shapefile > support by OGR. IMHO it is feasible - not something for a rainy > afternoon, but maybe a project for 2-3 weeks of developer time. All > work with shapefiles is done by API calls to saga core, so it would be > a matter of reimplementing a part of the API. Similarly, raster access > could be adapted to use GDAL. We could even use directly QGIS API for > vector/raster access if we chose even tighter integration. > > I think integrating SAGA tightly into QGIS would be very beneficial > for both projects: > - QGIS would finally have a native analysis engine, ending the long > time struggle with changing parameter names, data conversions, CRS > issues, algorithm naming (e.g. raster vs grid), duplication of > algorithms etc. > - SAGA source code would get more eyes of developers (increasing > quality and bringing in new algorithms) and users. SAGA devs could > focus more on algorithms as GUI side would be handled by QGIS. > > This would be however best done with consent from SAGA developers, so > we do not end up with two competing projects. > > Cheers > Martin > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
