Opened 7 years ago
Closed 6 years ago
#3349 closed enhancement (wontfix)
v.import: add 'where' parameter
| Reported by: | mlennert | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.4.1 |
| Component: | Vector | Version: | unspecified |
| Keywords: | v.import where | Cc: | |
| CPU: | Unspecified | Platform: | Unspecified |
Description
Was there choice of not adding a 'where' parameter to v.import a deliberate one ? I would find this parameter quite useful, but do not want to implement it if there was an explicit decision against it.
Change History (9)
follow-up: 2 comment:1 by , 7 years ago
follow-up: 3 comment:2 by , 7 years ago
Replying to mmetz:
Replying to mlennert:
Was there choice of not adding a 'where' parameter to v.import a deliberate one ? I would find this parameter quite useful, but do not want to implement it if there was an explicit decision against it.
The reason to not add a 'where' option to v.import, as well as various other options and flags present in v.in.ogr but not in v.import, was to provide a module with a simplified user-interface that combines v.in.ogr + v.proj. It was not meant to be a replacement for using v.in.ogr and v.proj separately.
Well, the fact that AFAICT the GUI now exclusively uses v.import for imports (even when you chose "Common import formats" and not "Import of common formats with reprojection") and automatically proposes to reproject data at import if it is not in the location's projection, creates a situation where most people will use v.import, without knowing it.
Actually, the where option is thus not available at all in the GUI import wizard... :-(
Once again a case where I think that dumbing down the GUI is not always a good idea.
follow-up: 4 comment:3 by , 7 years ago
Replying to mlennert:
Replying to mmetz:
Replying to mlennert:
Was there choice of not adding a 'where' parameter to v.import a deliberate one ? I would find this parameter quite useful, but do not want to implement it if there was an explicit decision against it.
The reason to not add a 'where' option to v.import, as well as various other options and flags present in v.in.ogr but not in v.import, was to provide a module with a simplified user-interface that combines v.in.ogr + v.proj. It was not meant to be a replacement for using v.in.ogr and v.proj separately.
Well, the fact that AFAICT the GUI now exclusively uses v.import for imports (even when you chose "Common import formats" and not "Import of common formats with reprojection") and automatically proposes to reproject data at import if it is not in the location's projection, creates a situation where most people will use v.import, without knowing it.
When you choose "Common import formats", you get a custom GUI interface to v.in.ogr, not the interface of v.in.ogr --ui (gui/wxpython/xml/wxgui_items.xml). That means the 'where' option (and others) is missing in the custom GUI interface to v.in.ogr. Similar for r.in.gdal (Import raster data -> Common formats import).
Any reason why the menu entry for v.in.ogr is "Common import formats" while for r.in.gdal it is "Common formats import"?
Actually, the where option is thus not available at all in the GUI import wizard... :-(
Once again a case where I think that dumbing down the GUI is not always a good idea.
follow-up: 5 comment:4 by , 7 years ago
Replying to mmetz:
Replying to mlennert:
Replying to mmetz:
Replying to mlennert:
Was there choice of not adding a 'where' parameter to v.import a deliberate one ? I would find this parameter quite useful, but do not want to implement it if there was an explicit decision against it.
The reason to not add a 'where' option to v.import, as well as various other options and flags present in v.in.ogr but not in v.import, was to provide a module with a simplified user-interface that combines v.in.ogr + v.proj. It was not meant to be a replacement for using v.in.ogr and v.proj separately.
Well, the fact that AFAICT the GUI now exclusively uses v.import for imports (even when you chose "Common import formats" and not "Import of common formats with reprojection") and automatically proposes to reproject data at import if it is not in the location's projection, creates a situation where most people will use v.import, without knowing it.
When you choose "Common import formats", you get a custom GUI interface to v.in.ogr, not the interface of v.in.ogr --ui (gui/wxpython/xml/wxgui_items.xml). That means the 'where' option (and others) is missing in the custom GUI interface to v.in.ogr. Similar for r.in.gdal (Import raster data -> Common formats import).
These custom GUIs now directly call v./r.import. The only difference between the first and second menu entries in the respective GUI menus is that the first calls the GUI wizard (which then calls v./r.import) and the second calls the v./r.import module GUI.
If the wizard calls the *.import modules, then I think it would be better to have as second entry a call to the original v.in.ogr/r.in.gdal module GUIs in the menu, instead of the v.import GUI which does not bring much added value in comparison to the wizard...
This would allow to increase the visibility of the original modules and their additional options.
Any reason why the menu entry for v.in.ogr is "Common import formats" while for r.in.gdal it is "Common formats import"?
None to my knowledge.
follow-up: 6 comment:5 by , 7 years ago
Replying to mlennert:
Replying to mmetz:
Replying to mlennert:
Replying to mmetz:
Replying to mlennert:
Was there choice of not adding a 'where' parameter to v.import a deliberate one ? I would find this parameter quite useful, but do not want to implement it if there was an explicit decision against it.
The reason to not add a 'where' option to v.import, as well as various other options and flags present in v.in.ogr but not in v.import, was to provide a module with a simplified user-interface that combines v.in.ogr + v.proj. It was not meant to be a replacement for using v.in.ogr and v.proj separately.
Well, the fact that AFAICT the GUI now exclusively uses v.import for imports (even when you chose "Common import formats" and not "Import of common formats with reprojection") and automatically proposes to reproject data at import if it is not in the location's projection, creates a situation where most people will use v.import, without knowing it.
When you choose "Common import formats", you get a custom GUI interface to v.in.ogr, not the interface of v.in.ogr --ui (gui/wxpython/xml/wxgui_items.xml). That means the 'where' option (and others) is missing in the custom GUI interface to v.in.ogr. Similar for r.in.gdal (Import raster data -> Common formats import).
These custom GUIs now directly call v./r.import.
It seems that wxgui_items.xml has not been updated accordingly.
The only difference between the first and second menu entries in the respective GUI menus is that the first calls the GUI wizard (which then calls v./r.import) and the second calls the v./r.import module GUI.
If the wizard calls the *.import modules, then I think it would be better to have as second entry a call to the original v.in.ogr/r.in.gdal module GUIs in the menu, instead of the v.import GUI which does not bring much added value in comparison to the wizard...
This would allow to increase the visibility of the original modules and their additional options.
Sounds reasonable: v.import + GUI wizard for quick and dirty import, v.in.ogr + generic UI for full-featured import, accordingly for raster import.
comment:6 by , 7 years ago
Replying to mmetz:
Replying to mlennert:
[...]
If the wizard calls the *.import modules, then I think it would be better to have as second entry a call to the original v.in.ogr/r.in.gdal module GUIs in the menu, instead of the v.import GUI which does not bring much added value in comparison to the wizard...
This would allow to increase the visibility of the original modules and their additional options.
Sounds reasonable: v.import + GUI wizard for quick and dirty import, v.in.ogr + generic UI for full-featured import, accordingly for raster import.
The menu entries have been changed in trunk r71108. The [r|v].import modules are now labelled as "Simplified [raster|vector] import with reprojection" and use the customized GUI interface. r.in.gdal and v.in.ogr use their generic UI interface and are in the wxGUI menu labelled as "Import of common [raster|vector] formats".
wxGUI developers, please review these changes.
comment:9 by , 6 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | new → closed |
Closing as the original question of a 'where' parameter in v.import was answered as wonfix as the module is deliberately meant to be simple.
If anyone disagrees, please reopen.
Replying to mlennert:
The reason to not add a 'where' option to v.import, as well as various other options and flags present in v.in.ogr but not in v.import, was to provide a module with a simplified user-interface that combines v.in.ogr + v.proj. It was not meant to be a replacement for using v.in.ogr and v.proj separately.