[GRASS-dev] importing & projecting

[Michael Barton]

On Sep 22, 2015, at 7:56 PM, grass-dev-request at lists.osgeo.org<mailto:grass-dev-request at lists.osgeo.org> wrote:

From: Anna Petrášová <kratochanna at gmail.com<mailto:kratochanna at gmail.com>>
Subject: Re: [GRASS-dev] importing & projecting
Date: September 22, 2015 at 2:46:26 PM MST
To: Markus Neteler <neteler at osgeo.org<mailto:neteler at osgeo.org>>
Cc: Paulo van Breugel <p.vanbreugel at gmail.com<mailto:p.vanbreugel at gmail.com>>, Martin Landa <landa.martin at gmail.com<mailto:landa.martin at gmail.com>>, GRASS developers email list <grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>>




On Tue, Sep 22, 2015 at 4:18 PM, Markus Neteler <neteler at osgeo.org<mailto:neteler at osgeo.org>> wrote:
On Tue, Sep 22, 2015 at 8:37 PM, Martin Landa <landa.martin at gmail.com<mailto:landa.martin at gmail.com>> wrote:
> Hi,
>
> 2015-09-22 18:25 GMT+02:00 Moritz Lennert <mlennert at club.worldonline.be<mailto:mlennert at club.worldonline.be>>:
>> 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
grass-dev at lists.osgeo.org<mailto:grass-dev at lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/grass-dev



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20150923/bf019d38/attachment.html>