(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? Thank you, Nikos
signature.asc
Description: PGP signature
_______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
