326 | | ---------------------------------------------------------------------------------- |
327 | | What is treating as the string in QGIS Processing: |
328 | | |
329 | | - Separators - 'separator' and all names which have not equivalent class in Processing plugin - 'color', 'cats', 'dbname', 'dbtable'. |
330 | | ---------------------------------------------------------------------------------- |
| 334 | |
| 335 | ''' What is treating as the string in QGIS Processing: ''' |
| 336 | |
| 337 | Separators - 'separator' and all names which have not equivalent class in Processing plugin - 'color', 'cats', 'dbname', 'dbtable'. |
| 338 | |
| 339 | ''' GRASS layer, sublayer: ''' |
| 340 | |
| 352 | Conclusion: More intuitive distribution of parameters in GRASS GIS (more in Future to do) |
| 353 | |
| 354 | === What is the best way how to divide parameters of modules in Processing plugin QGIS? === |
| 355 | Discussed possibilities: |
| 356 | |
| 357 | - Required x Optional - This version was declined, because of a lot of important parameters are optional in GRASS modules. |
| 358 | |
| 359 | - Frequently used x Rarely used - This system was declined for now, because it is not clear what parameter is rarely or often used. But it could be a good point to think for future because this distribution has to be first done in GRASS GIS. |
| 360 | |
| 361 | - GUI Tabs - We decided for distribution according to the GUI sections in GRASS. It should be the least confusing system for users because it will be same in QGIS and GRASS. Also for future changes and maintenance, it appears like a good solution. |
| 362 | |
| 363 | === How solved differences in GRASS and QGIS terminology. === |
| 364 | |
| 365 | The biggest problem is that descriptions of parameters are different between GRASS and QGIS now and simultaneously parameter names are not shown in QGIS Processing plugin. So it is very difficult for a user to orientate in manuals. |
| 366 | |
| 367 | There are following variants: |
| 368 | - what is possible to change in GRASS, so change it. E.g. 'raster map' in GRASS x 'raster layer' in QGIS - could be solved as 'raster input' or 'raster output' without the word map or layer. |
| 369 | |
| 370 | - what is not possible change in GRASS, then add a new tag with OGC (or QGIS) friendly description. This description could be shown in manuals too. |
| 371 | |
| 372 | Because that's a big deal and have to be thoroughly discussed in GRASS Mailing list. I will try to find all differences in QGIS and GRASS terminology and report them to ML as a source for a final decision. |
| 373 | |
| 374 | == Future to do: == |
| 375 | - add keywords to Processing Plugin - for improvement of searching in modules |
| 376 | - add similar keywords to ArcGIS tools to modules - for better orientation for ArcGIS users |
| 377 | - show parameters in Processing Plugin - for better orientation in GRASS manual for QGIS users. |
| 378 | - more intuitive distribution of parameters in GRASS - e.g. 'r.slope.aspect' could be divided into tabs slope and aspect, after this is not necessary to divide module in Processing Plugin to two modules - one for slope and second for aspect. Because it is intuitive to use just one tab if I want to compute slope. |
| 379 | |
| 380 | |
| 381 | |
| 382 | |
| 383 | |