On Sep 22, 2015, at 7:56 PM, [email protected]<mailto:[email protected]> wrote:
From: Anna Petrášová <[email protected]<mailto:[email protected]>> Subject: Re: [GRASS-dev] importing & projecting Date: September 22, 2015 at 2:46:26 PM MST To: Markus Neteler <[email protected]<mailto:[email protected]>> Cc: Paulo van Breugel <[email protected]<mailto:[email protected]>>, Martin Landa <[email protected]<mailto:[email protected]>>, GRASS developers email list <[email protected]<mailto:[email protected]>> On Tue, Sep 22, 2015 at 4:18 PM, Markus Neteler <[email protected]<mailto:[email protected]>> wrote: On Tue, Sep 22, 2015 at 8:37 PM, Martin Landa <[email protected]<mailto:[email protected]>> wrote: > Hi, > > 2015-09-22 18:25 GMT+02:00 Moritz Lennert > <[email protected]<mailto:[email protected]>>: >> IMHO, the best solution, as Paulo already said, would be to have >> r.in.gdal/v.in.ogr as the default import modules used by the import dialog. >> A checkbox (unchecked by default) could propose to "Reproject maps to >> current projection system before import" or something like that. yes >> For now, I propose to revert import_export.py to r65634 and to see if >> everyone agrees with the above proposal of how to integrate the *.import >> modules. > > instead of simply reverting I would be happier if anyone here would > implement the suggestion above. +1 .. I agree with Martin Disasters happened when people were trying to import data in different projection and because it "didn't work", they just checked override projection. So I am convinced it should stay there but just improved. What is currently missing is the choice of which reprojection method to use. So we could dynamically (based on if it's needed or not) add there a widget for selecting the reprojection method. And maybe also the output resolution which is by default estimated. I am not sure whether the import dialog should be still associated with r.in.gdal (when you open r.in.gdal from gui command line, it opens this custom dialog). Does something like that sounds better? Anna This all rings true in a number of ways. I may have missed part of the earlier thread, and if this has already been discussed please forgive. r.in.gdal and v.in.ogr have options to create a location based on a dataset's embedded/attached projection info and import the data into the new location. These options have been left out of the current import wrapper. However, they could be used and enhanced. If an imported dataset does not match the current location projection, a popup dialog could offer to create a location that does match the dataset's projection, import it into that location (r.in.gdal and v.in.ogr), and then reproject it into the current location (r.proj and v.proj). That maintains the robusticity and reliability of the current GRASS projection framework and simplifies import of data from different CRS. Michael ____________________ C. Michael Barton Director, Center for Social Dynamics & Complexity Professor of Anthropology, School of Human Evolution & Social Change Head, Graduate Faculty in Complex Adaptive Systems Science Arizona State University voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC) fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC) www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu Markus _______________________________________________ grass-dev mailing list [email protected]<mailto:[email protected]> http://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
