I agree with the progressive approach in your PR e.g. just integrate the alg as processing algorithm. A 2) approach can come later
https://github.com/qgis/QGIS/pull/7626 tnks to point out about this alg/plugin, I didn't realized it's existence... it's a pain we missed the opportunity to work on it, just when we where in FOSS4G-EU that was hosted by the university/department that published the algorithm. Luigi Pirelli ************************************************************************************************** * LinkedIn: https://www.linkedin.com/in/luigipirelli * Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli * GitHub: https://github.com/luipir * Mastering QGIS 2nd Edition: * https://www.packtpub.com/big-data-and-business-intelligence/mastering-qgis-second-edition * Hire me: http://goo.gl/BYRQKg ************************************************************************************************** On Wed, 15 Aug 2018 at 12:47, Rudi von Staden <[email protected]> wrote: > Hi all, > > I've been using the concave hull processing algorithm as part of a model > which iterates over species distribution data to create a basic > distribution polygon. I've found that it can produce very unexpected > outputs for certain input data, so I don't think it's a good algorithm to > use 'unsupervised'. > > The results from the k-neighbour concave hull algorithm ( > https://www.researchgate.net/publication/220868874_Concave_hull_A_k-nearest_neighbours_approach_for_the_computation_of_the_region_occupied_by_a_set_of_points) > are generally more pleasing and will never have strange pinches or ignored > points (although it also doesn't provide for holes). From my testing I > think the outputs correspond more to how someone would naturally > circumscribe a set of points. As such I would argue for it to be included > as one of the default algorithms. > > There is an existing plugin ( > https://github.com/detlevn/QGIS-ConcaveHull-Plugin) which is pretty > decent but it hasn't been updated to work with QGIS3. I've also come across > a C++ implementation ( > https://www.codeproject.com/Articles/1201438/The-Concave-Hull-of-a-Set-of-Points) > which seems to have a lot of optimisation advantages. > > I see three options: > 1. Update the plugin code and streamline it as a qgis algorithm. I'd be > happy to give this a go if there's support and I think it would be > relatively straightforward. > 2. Adapt the c++ implementation and add it as a native algorithm. This > would probably have significant performance advantages, but may not be > worth the effort. I'm not that confident with C++ and would at least need a > fair amount of guidance if someone else doesn't want to take it on. I did > reach out to the developer and he'd be happy for his code to be used if it > comes to that. > 3. Update the plugin for QGIS3 (or at least the parts of it that I need). > I would do this anyway if we don't proceed with either of the other options. > > Any thoughts? > > Rudi > _______________________________________________ > QGIS-Developer mailing list > [email protected] > List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
