Opened 9 years ago
Closed 9 years ago
#2744 closed defect (fixed)
r.import latlong bug
Reported by: | neteler | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 7.0.3 |
Component: | Python | Version: | svn-trunk |
Keywords: | r.import | Cc: | |
CPU: | Unspecified | Platform: | Unspecified |
Description
Would it be possible to catch this user error?
The user tried to import reprojected METOP-A data (Stereographic projection) into a LatLong location (yeah, things happen):
r.import input=EUMETSAT/output/Soil moisture/1/ascat_METOPA.20090401163331.12715_soil_moisture.tif output=01_third WARNING: Datum <unknown> not recognised by GRASS and no parameters found WARNING: Datum <unknown> not recognised by GRASS and no parameters found WARNING: Datum <unknown> not recognised by GRASS and no parameters found Proceeding with import of 1 raster bands... Importing raster map <01_third>... Traceback (most recent call last): File "/usr/local/grass-7.1.svn/scripts/r.import", line 333, in <module> sys.exit(main()) File "/usr/local/grass-7.1.svn/scripts/r.import", line 258, in main srcregion = grass.parse_key_val(tgtextents, val_type=float, vsep=' ') File "/usr/local/grass-7.1.svn/etc/python/grass/script/utils.py", line 223, in parse_key_val result[k] = val_type(v) ValueError: invalid literal for float(): 53:39:06.894826N
Probably the Python code which compares the two projections (input file and location) failed?
Solution: It could be taken from r.pack where a similar test is done.
Change History (8)
follow-up: 2 comment:1 by , 9 years ago
comment:2 by , 9 years ago
follow-ups: 6 7 comment:5 by , 9 years ago
I don't have any more the ASCAT dataset mentioned above for testing of trunk. I vote for backporting, though, since no complaints came in 3 month about the change in trunk.
comment:6 by , 9 years ago
Replying to neteler:
I don't have any more the ASCAT dataset mentioned above for testing of trunk.
OK, now I got it sent to me. Trunk
GRASS 7.1.svn (latlong):~/Downloads > r.import input=ascat_METOPA.20090401163331.12715_soil_moisture.tif output=01_third WARNING: Datum <unknown> not recognised by GRASS and no parameters found WARNING: Datum <unknown> not recognised by GRASS and no parameters found WARNING: Datum <unknown> not recognised by GRASS and no parameters found Proceeding with import of 1 raster bands... Importing raster map <01_third>... 100% Estimated target resolution for input band <01_third>: 0.120517219445 Reprojecting <01_third>... WARNING: No data base element files found GRASS 7.1.svn (latlong):~ > r.info -r 01_third min=-1 max=74.3199996948242
It no longer crashes (note: the datum is also not recognized by GDAL; not sure what the warning means). And the resulting map looks ok.
follow-up: 8 comment:7 by , 9 years ago
Replying to neteler:
I don't have any more the ASCAT dataset mentioned above for testing of trunk. I vote for backporting, though, since no complaints came in 3 month about the change in trunk.
As this is a bug fix and it does not change the behaviour of the module except for cases where the module would crash, I think this should definitely be backported.
comment:8 by , 9 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Replying to mlennert:
I think this should definitely be backported.
I just checked: nothing to backport since the module was introduced in relbr70 only after the fix:
https://trac.osgeo.org/grass/log/grass/branches/releasebranch_7_0/scripts/r.import
Closing.
Replying to neteler:
why is this a user error ? r/v.import are supposed to allow importing data that is in one projection into a location in another projection.
As mentioned on the ML (sorry, I didn't notice this was a ticket, need more sleep): parse_key_val has an optional parameter val_type which is set to 'float', here, but r.proj outputs lat-lon coordinates in DMS style. I don't know why val_type is set here and if that is necessary as the results are just sent to g.region which can take strings as input.
So as first try I would just delete this parameter from the parse_key_val call and see what happens.