#3349: v.import: add 'where' parameter --------------------------+---------------------------- Reporter: mlennert | Owner: grass-dev@… Type: enhancement | Status: new Priority: normal | Milestone: 7.4.0 Component: Vector | Version: unspecified Resolution: | Keywords: v.import where CPU: Unspecified | Platform: Unspecified --------------------------+----------------------------
Comment (by mmetz): Replying to [comment:4 mlennert]: > Replying to [comment:3 mmetz]: > > Replying to [comment:2 mlennert]: > > > Replying to [comment:1 mmetz]: > > > > Replying to [ticket:3349 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. -- Ticket URL: <https://trac.osgeo.org/grass/ticket/3349#comment:5> GRASS GIS <https://grass.osgeo.org>
_______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/grass-dev