#94: PROJ file sometimes not created with location
---------------------------------------------+------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Keywords: location PROJ projection g.proj |
---------------------------------------------+------------------------------
While we're talking about location creation, here's something that has
come up a few times recently.
A person makes a new location while importing a georeferenced file (e.g.,
in r.in.gdal), or from a georeferenced file (i.e., from the startup
screen).
The location creation happens without generating any errors and the file
is imported fine. The user can see and manipulate the file in the created
location without problem and even import additional files in the same
reference system.
The person goes to reproject it into another location and gets an error
that there is no projection information for the file. On checking it turns
out that there is no PROJ file in the location that was created from the
initial georeferenced file.
This only happens sporadically. My guess is that the georeferenced file is
missing some information that g.proj (or gdal?) needs to create a PROJ
file.
It seems that we need one of the following solutions (in order of my
personal preference):
1) Go ahead and create a PROJ file with a warning to the user that it is
generic and may need to be reviewed or revised. If there is enough
information to create a valid location, there should be enough to create
some kind of PROJ file IMHO.
2) Make the location but give the user a warning that it is missing a PROJ
file and that this will need to be created with g.proj prior to
reprojecting anything from the location.
3) Cause the location creation to fail with a message that there is not
enough information in the georeferenced file to create a valid location
and PROJ file.
#94: PROJ file sometimes not created with location
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: location PROJ projection g.proj
-----------------------+----------------------------------------------------
Comment (by pkelly):
Hello Michael,
Please can you give an example of a file that causes this problem (put it
online somewhere and post a link?) and I will investigate it. As far as I
know any errors in parsing the projection information are reported. The
only thing I can think of is that the file doesn't actually contain
projection information - it's not an error to carry on creating a location
from this though, as some information from the file (i.e. the extents and
resolution) can still be used in creating the location.
AND... as far as I can see g.proj already outputs a warning when an
unprojected file is being used. Something like:
Read of file ./roads.shp was successful, but it did not contain
projection information. 'XY (unprojected)' will be used
An additional warning could I suppose be added if a location is being
created, specifically reminding the user of the need to run g.setproj or
g.proj at a later date, if we think that's necessary. But I really need to
see an example of the file that causes this problem as I can't see where
it would be happening.
I'll see if I can track down a file that caused this kind of error.
Michael
______________________________
Michael Barton, Professor
Professor of Anthropology
Director of Graduate Studies
School of Human Diversity & Social Change
Center for Social Dynamics & Complexity
Arizona State University
Tempe, AZ 85287-2402
USA
#94: PROJ file sometimes not created with location
-----------------------+----------------------------------------------------
Reporter: cmbarton | Owner: grass-dev@lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: default | Version: svn-trunk
Resolution: | Keywords: location PROJ projection g.proj
-----------------------+----------------------------------------------------
Comment (by pkelly):
Hello Michael,
Please can you give an example of a file that causes this problem (put it
online somewhere and post a link?) and I will investigate it. As far as I
know any errors in parsing the projection information are reported. The
only thing I can think of is that the file doesn't actually contain
projection information - it's not an error to carry on creating a location
from this though, as some information from the file (i.e. the extents and
resolution) can still be used in creating the location.
AND... as far as I can see g.proj already outputs a warning when an
unprojected file is being used. Something like:
Read of file ./roads.shp was successful, but it did not contain
projection information. 'XY (unprojected)' will be used
An additional warning could I suppose be added if a location is being
created, specifically reminding the user of the need to run g.setproj or
g.proj at a later date, if we think that's necessary. But I really need to
see an example of the file that causes this problem as I can't see where
it would be happening.
Wow!. 24 hr turn around from reported issue to fix. I didn't even have time to find example files.
...and this is typical of GRASS. Any commercial programs able to make this kind of claim?
Michael
____________________
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University