benducke
commented
1 year ago Control via three options: outfile(s) = CSV file(s) to write by v.net.models, containing simple matrix representation of network processor = programm to run that implements the external model (outfile(s) is passed as argument) infile(s) = file that is created when "processor" is done, and that will then be further processed by v.net.models Flow:
- v.net.models creates initial network
- v.net.models writes "outfile(s)"
- v.net.models runs "processor <outfile(s)>
- v.net.models waits for "processor" to complete & processor writes "infile(s)"
- v.net.models reads "infile(s)" and produces GIS output
It would be convenient to have v.net.models act as a "worker ant" for geocomputing, so that an external program can run a more complex connectivity model, concentrating on the core mathematics of such a model, and without needing to do the heavy lifting (cost-based computations, topological cleaning, etc.).
In such a workflow, one would first use v.net.model to create a completely connected model and export simple CSV files with link/node properties (in addition to regular vector maps output). An external program could then ingest this and decide which links to remove and which to leave. In a second pass, v.net.models could then import the connectivity file and reduce the complete (or initial!) model accordingly. A simple file format for import into v.net.models could have just two columns:
FROM_ID<space>TO_ID(Plus '#' as comment marker.)
In terms of user interface, we would add a new model choice "external". If this type is chosen, then a connectivity file must also be provided via another option.