I imported raster layers in a projected mapset, while the data layers were in latlon. I used the r.in.gdal from the menu (i.e., not command line), importing all geotif files in a directory.
I would have assumed that GRASS would throw an error as the layers were not in the correct projection. Instead GRASS just imported the layers, projecting the layers 'on the fly'.
A very convenient option , but I wonder if it shouldn't be an option that should be explicitly selected by the user?
Paulo
On 18/09/15 13:34, Paulo van Breugel wrote:
I imported raster layers in a projected mapset, while the data layers
were in latlon. I used the r.in.gdal from the menu (i.e., not command
line), importing all geotif files in a directory.I would have assumed that GRASS would throw an error as the layers were
not in the correct projection. Instead GRASS just imported the layers,
projecting the layers 'on the fly'.A very convenient option , but I wonder if it shouldn't be an option
that should be explicitly selected by the user?
I very strongly agree and I think that such an important decision should have been discussed on the ML (if it was, sorry, I must have missed it). The relevant changes, AFAICT, are r65751 (v.import) and r65917 (r.import).
I don't have a strong opinion on this, but I think that there is some advantage to GRASS telling the user that the file she is trying to import is in a different projection than the location and that explicit use of v./r.import would necessary.
Now the import wizard just silently imports anything without even informing the user that reprojection is happening. This does not always make sense and is a potential path to many disasters...
Projection handling is not easy, but IMHO it is one of the strengths of GRASS to force the user to think about it. I agree that r./v.import are a very nice convenience, but their use should at least result from a conscious decision, not out of ignorance...
Moritz
On 22-09-15 14:19, Moritz Lennert wrote:
On 18/09/15 13:34, Paulo van Breugel wrote:
I imported raster layers in a projected mapset, while the data layers
were in latlon. I used the r.in.gdal from the menu (i.e., not command
line), importing all geotif files in a directory.I would have assumed that GRASS would throw an error as the layers were
not in the correct projection. Instead GRASS just imported the layers,
projecting the layers 'on the fly'.A very convenient option , but I wonder if it shouldn't be an option
that should be explicitly selected by the user?I very strongly agree and I think that such an important decision should have been discussed on the ML (if it was, sorry, I must have missed it). The relevant changes, AFAICT, are r65751 (v.import) and r65917 (r.import).
I don't have a strong opinion on this, but I think that there is some advantage to GRASS telling the user that the file she is trying to import is in a different projection than the location and that explicit use of v./r.import would necessary.
The explicit choice could still be included in the GUI, but should, I think, be off by default.
Now the import wizard just silently imports anything without even informing the user that reprojection is happening.
I can't remember the exact words, but a line is shown telling that the data has been projected when the import is finished. Easy to miss though, especially for users not really aware their data is in another projection.
This does not always make sense and is a potential path to many disasters...
I would say it is a sure path to disasters.. not always, but there will be some
Projection handling is not easy, but IMHO it is one of the strengths of GRASS to force the user to think about it. I agree that r./v.import are a very nice convenience, but their use should at least result from a conscious decision, not out of ignorance...
Moritz
Hi,
2015-09-22 14:19 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
[...]
Now the import wizard just silently imports anything without even informing
the user that reprojection is happening. This does not always make sense and
is a potential path to many disasters...Projection handling is not easy, but IMHO it is one of the strengths of
GRASS to force the user to think about it. I agree that r./v.import are a
very nice convenience, but their use should at least result from a conscious
decision, not out of ignorance...
the current implementation in trunk should be improved. Please feel
free to contribute. Thanks, Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
On 22/09/15 16:49, Martin Landa wrote:
Hi,
2015-09-22 14:19 GMT+02:00 Moritz Lennert <mlennert@club.worldonline.be>:
[...]
Now the import wizard just silently imports anything without even informing
the user that reprojection is happening. This does not always make sense and
is a potential path to many disasters...Projection handling is not easy, but IMHO it is one of the strengths of
GRASS to force the user to think about it. I agree that r./v.import are a
very nice convenience, but their use should at least result from a conscious
decision, not out of ignorance...the current implementation in trunk should be improved. Please feel
free to contribute.
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.
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.
Moritz
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.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.
Martin
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
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
Markus
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 22/09/15 23:46, Anna Petrášová wrote:
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.
I agree that this is another path to disaster. 
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.
So this sounds somewhat like the "pop-up" solution Michael proposed.
What I really find important is that there is a big red sign flashing when reprojection happens. And I would like the user to have to at least click on "ok" to confirm that this is what she wants.
It's the fact that things are happening quietly without informing the user, and without giving a choice, that bothers me right now. And the fact that it happened without discussion. To repeat myself: I think that such fundamental changes as were introduced by replacing r.in.gdal/v.in.ogr by the *.import modules in the import wizard should be discussed (at least announced with sufficient time for others to react) before implementation.
And I readily admit that I don't have the wxGUI knowledge to code that myself, at least not in the limited time I have available for that right now. But I don't think that this takes away the right to question the current choice.
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).
So, you propose to associate the gui dialog with the *.import modules and to put r.in.gdal and v.in.ogr back into "normal" module status with their module GUI launched when called ?
Sounds ok to me, although we should be aware that this will mean quite a lot of changes in existing documentation. But I think it is worth the effort.
Moritz