root676 / QNEAT3

QNEAT3 - Qgis Network Analysis Toolbox 3
GNU General Public License v3.0
64 stars 13 forks source link

Enhancements/Additions #7

Open paul-bsc opened 6 years ago

paul-bsc commented 6 years ago

Good day

Full disclosure, I have not done a deep dive through your code yet but am willing to contribute if what I'm suggesting is sensible.

  1. Can we have an additional tool to "Create Network"?
    • the thinking here is that for larger networks, you can do this as a once-off and just point subsequent tools to the already built network graph
  2. For the OD Matrix Tool, could we set a cut off distance parameter?
    • the thinking here is that (in my own experience) there are many use cases for an OD Matrix where you are only interested in recording data for points that are within a certain distance of one another
aaron1uk commented 6 years ago

The first point would be a fantastic addition, I have tested this using OS Mastermap Highways dataset and it works great but on a national data set you can imagine how long it takes.

paul-harambee commented 6 years ago

I will try make time for the Create Network tool in the coming weeks as it's something I aim to benefit from.

root676 commented 6 years ago

Hi guys! Thank you for the interest and commitment! Unfortunately I was heavily invested into another project at work. I already started some research into seralizing the QgsGraph class that is built in every algorithm call. Matthias Kuhn, a QGIS dev answered the following on Twitter:

"There is no method to serialize a graph builtin, but it shouldn't be too hard to iterate over all edges and vertices and save their properties to a data structure and recreate the graph from that on next use."

Based on this Information I dug deeper into methods like the python pickle module which can be used for searializing pyhton objects (NOT the Qgs C++ objects). My conclusion from this was to extract the vertices, edges and related information into primitive python types, that are then once again put into python objects (representing the C++ classes) - eg. a conversion from C++ objects to Python objects. Those classes can then be serialized in a file on disk and read every time. So, serialization should not be the main problem. The real problem lies in the analysis points (start/stop points) that are tied to the graph in the process of building (necessary due to QGIS C++ network analysis class implementation). Those points must be included during the build process - otherwise routing is not possible. The result of the algorithm would then only work with the respective set of points that has been matched in the building process. This discouraged me from setting this feature request to high priority as it reduces the use cases of the produced network file: Creating a network that only works with a specific set of points is only interesting when running the same analysis over and over again...

In case you see or know any other approach that is more feasible or more straight forward, I am very keen on including it in the QNEAT3 plugin. @paul-harambee what do you think of this usability problem?

Best, Clemens

aaron1uk commented 6 years ago

This tool is very good with this addition I can see it being widely used, if only I had the expertise to help with the coding. I am happy to help with the testing.

paul-harambee commented 6 years ago

Hi Clemens

I think it might be worth exploring how osmnx handles exports and imports of the networkx graph it runs on. I suspect much of the logic may be reusable. Things are a tad crazy with work and my dissertation at the moment, but I will do some digging when I have a moment.