#2744: r.import latlong bug
-------------------------+-------------------------
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Python | Version: svn-trunk
Keywords: r.import | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
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.
#2744: r.import latlong bug
-------------------------+-------------------------
Reporter: neteler | Owner: grass-dev@…
Type: defect | Status: new
Priority: normal | Milestone: 7.1.0
Component: Python | Version: svn-trunk
Keywords: r.import | CPU: Unspecified
Platform: Unspecified |
-------------------------+-------------------------
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
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?
No, IIUC, the problem seems to be that parse_key_val at line 258 expects boundary coordinates to be in float, but r.proj on delivers lat lon coordinates in a character string. Maybe you can try with just deleting the 'val_type=float' in the call parameters. I'm not sure this is absolutely necessary.
Moritz
Solution: It could be taken from r.pack where a similar test is done.
Replying to [ticket:2744 neteler]:
> Would it be possible to catch this user error?
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.
>
> 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
> }}}
>
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.
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.
Replying to [comment:5 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
Replying to [comment:5 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.