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
···
On Tue, Sep 22, 2015 at 4:18 PM, Markus Neteler <neteler@osgeo.org> wrote:
On Tue, Sep 22, 2015 at 8:37 PM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2015-09-22 18:25 GMT+02:00 Moritz Lennert <mlennert@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
Markus
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
On 23/09/15 07:17, Michael Barton wrote:
On Sep 22, 2015, at 7:56 PM, grass-dev-request@lists.osgeo.org
<mailto:grass-dev-request@lists.osgeo.org> wrote:
*From:*Anna Petrášová <kratochanna@gmail.com
<mailto:kratochanna@gmail.com>>
*Subject:**Re: [GRASS-dev] importing & projecting*
*Date:*September 22, 2015 at 2:46:26 PM MST
*To:*Markus Neteler <neteler@osgeo.org <mailto:neteler@osgeo.org>>
*Cc:*Paulo van Breugel <p.vanbreugel@gmail.com
<mailto:p.vanbreugel@gmail.com>>, Martin Landa <landa.martin@gmail.com
<mailto:landa.martin@gmail.com>>, GRASS developers email list
<grass-dev@lists.osgeo.org <mailto:grass-dev@lists.osgeo.org>>
On Tue, Sep 22, 2015 at 4:18 PM, Markus Neteler<neteler@osgeo.org
<mailto:neteler@osgeo.org>>wrote:
On Tue, Sep 22, 2015 at 8:37 PM, Martin Landa
<landa.martin@gmail.com <mailto:landa.martin@gmail.com>> wrote:
> Hi,
>
> 2015-09-22 18:25 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be <mailto:mlennert@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