[GRASS-dev] importing & projecting

[Moritz Lennert]

On 23/09/15 07:17, Michael Barton wrote:
>
>> 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

A popup might be a nice solution.

> 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.

This is exactly what v./r.import do.

Moritz