search

GIScience / orstools-qgis-plugin

Plugin for QGIS with a set of tools to use openrouteservice API´s, based on openstreetmap
https://plugins.qgis.org/plugins/ORStools/
MIT License
99 stars 31 forks source link

provide processing algorithms #41

Closed noerw closed 5 years ago

noerw commented 6 years ago

Is there a way to use this plugin (fetch isochrones) from other python code?

If not, the cleanest way would be to encapsulate the API-fetch and data transformation in an processing provider. I would do this myself, but I do not understand the program flow yet: The request logic seems to be in accRequest(), which is called from iterAnalysis(). Can accRequest() be called with any list of QgsGeometry, or are there additional preconditions?

nilsnolde commented 6 years ago

I reserved two days this week to re-write a lot of the plugin, hopefully finished by end of next week.

It's been a bit unstable from the last release on anyways, plus I need to upgrade to QGIS3. After the upgrade, I'll refactor quite a bit. I wrote this PyPI version for ORS. That's when I realized how poorly written the plugin is.. But the Py package could get you off the ground for now.

So, don't spend any of your resources on this for now (even though highly appreciated!). I'll let you know when I'm happy again with the plugin:) And I will heed your suggestion, I think that'd be a great addition!

noerw commented 6 years ago

Alright, thanks for the effort! Will look into the PyPI version.

nilsnolde commented 6 years ago

@noerw Wanna take this on? I just completed refactoring for v3

noerw commented 6 years ago

Yeah, would like to help you out! I'm not sure though when I will get it done. (The issue is that I would need this for a project that will be stuck on QGIS2 for a while due to other plugin dependencies)

nilsnolde commented 6 years ago

Right. I'd like to backport this again to v2.x anyways. Hopefully this week. v.2.18 be LTS for quite a while I imagine. Lots of companies won't do the switch to v3 before.

I'm just thinking of adding our matrix API before, to output large amounts of routings to a table (since it doesn't provide geometries).

What will adding the tool to processing module mean anyways (I get the benefits that'd add, I mean in terms of code change)? The GUI is then internally managed in QGIS right? So, it'd be an entire rewrite of GUI related things?

noerw commented 6 years ago

Exactly. You don't write any GUI code at all, you only define a subclass of GeoAlgorithm, specify parameters and outputs, and a processAlgorithm() function implementing the logic. This GeoAlgorithm is then registered with an AlgorithmProvider, which can group several GeoAlgorithms.

QuickOSM is a plugin that has both a custom UI and a processing provider. They separated the core logic quite nicely to be used in both the UI and Processing. I would do it in a similar way

backporting sounds great!

nilsnolde commented 6 years ago

Yeah, sounds pretty cool actually.. You’d miss out on advanced gui features like the map buttons, but you’d be able to use it in modelling.. that’s surely a good tradeoff.

Let me include the matrix api on the weekend (should be a quick one), then proccesing makes even more sense.

nilsnolde commented 6 years ago

Sooo, it's all done for a while, I hope:

pcav already approved, so you can have a look.

Note, I did most of the dev on Linux, only the backport on Win. Now, I realized, that the GUI is not really consistent across platforms. It's behaving weird on Linux, maybe some QtBackend stuff.. Anyways, didn't care really, just wanna be done;)

jbdesbas commented 5 years ago

Yeah, sounds pretty cool actually.. You’d miss out on advanced gui features like the map buttons, but you’d be able to use it in modelling.. that’s surely a good tradeoff.

Let me include the matrix api on the weekend (should be a quick one), then proccesing makes even more sense.

Today, it is possible to add a parameterPoint to get coordinates by clic the map (see the processing alog qgis:serviceareafrompoint as exemple).

nilsnolde commented 5 years ago

Finally in there. It's active in the current development branch.

@noerw I reaaally tried to get the difference operation to the isochrone algo. It's not easy and way different the v3.x API compared to your original implementation in v2.x. One has to postprocess the polygon output, but I couldn't get the postprocessing method to see the dissolved layer held in memory. Smth to do with processing contexts.. As far as I could tell I did it all correctly, still didn't work. Anyways, I guess it could work with Tmp files, but I don't like writing to disk. If you ever wanna have a shot at this:

Postprocessing method (sorry, I unfortunately deleted my attempt): https://github.com/nilsnolde/OSMtools/blob/ffbe6bed72d41acfdcc84e62fe6dc41ef42794f9/ORStools/proc/isochrones_proc.py#L219

First shot to get at least the dissolve layer reported back to the postprocessing method: https://github.com/nilsnolde/OSMtools/blob/ffbe6bed72d41acfdcc84e62fe6dc41ef42794f9/ORStools/core/isochrones_core.py#L114

nilsnolde commented 5 years ago

fixed in newest master and available in plugin repo