I am concerned about mixing Vector and Raster maps as inputs in a
module. I think it's less of a complication if a module considers either
only Vector or Raster maps as inputs.
Should I just not worry and mix these? The question is about user-friendliness.
If tha add-on is exposed to QGIS, non-experienced users will be able to
use it. Should they be forced to think about doing some rasterisation
themselves? Or should the module do this job for them?
This is a generic question. I much appreciate your thoughts.
I would personally keep modules simpler and make them do one task really well (Unix philosophy unless there are multiple related tasks that share a significant portion of the procedure. I would assume that rasterization is a pre-processing step that needs to be done before using your module, and it may not need to be done every time you run the module. If this pre-processing doesn’t require any special treatments to the input raster, I would leave it out and just add some notes in the manual.
I am concerned about mixing Vector and Raster maps as inputs in a
module. I think it’s less of a complication if a module considers either
only Vector or Raster maps as inputs.
Should I just not worry and mix these? The question is about user-friendliness.
If tha add-on is exposed to QGIS, non-experienced users will be able to
use it. Should they be forced to think about doing some rasterisation
themselves? Or should the module do this job for them?
This is a generic question. I much appreciate your thoughts.
(Re-structuring this thread as I might need to share the discussion)
Nikos Alexandris wrote:
Dear all,
I am concerned about mixing Vector and Raster maps as inputs in a
module. I think it's less of a complication if a module considers either
only Vector or Raster maps as inputs.
Should I just not worry and mix these? The question is about
user-friendliness.
If tha add-on is exposed to QGIS, non-experienced users will be able to
use it. Should they be forced to think about doing some rasterisation
themselves? Or should the module do this job for them?
This is a generic question. I much appreciate your thoughts.
Nikos
Huidae Cho:
Nikos,
I would personally keep modules simpler and make them do one task really
well (Unix philosophy unless there are multiple related tasks that
share a significant portion of the procedure. I would assume that
rasterization is a pre-processing step that needs to be done before using
your module, and it may not need to be done every time you run the module.
If this pre-processing doesn't require any special treatments to the input
raster, I would leave it out and just add some notes in the manual.
Best,
Huidae
Dear Huidae,
(Dear @grass-dev readers, I would appreciate additional feed-backers)
thank you for your thoughts.
Yes, the case is as you assume.
I work on an algorithm that is all raster based.
The prototype module is "overloaded" with multiple input options,
already.
While it is possible to use a vector map, to serve as a "base" map for
`v.rast.stats`, technically it is not required.
If nothing changes (for example, request for a vector output map from the
module), the outputs are all raster maps and one CSV file.
Is there an "independent" and "convincing" source, for non-programmers,
that not keeping a script simple, will eventually lead to code that is harder
to read, to test, to maintain, to update?
unless there are multiple related tasks that share a significant portion of the procedure. I would assume that rasterization is a pre-processing step that needs to be done before using your module, and it may not need to be done every time you run the module. If this pre-processing doesn’t require any special treatments to the input raster, I would leave it out and just add some notes in the manual.