PROJ file sometimes not created with location

[cmbarton]

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.

Michael

[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.

Paul

[pkelly]

It seems the problem was with gis_set.tcl not forwarding the warning message that g.proj emitted on to the user. I think I've fixed this now in SVN.

This fix is for files that had no projection information associated with them. If there is a separate problem we can look at that too of course.

[pkelly]

Changeset 30557. ​http://trac.osgeo.org/grass/changeset/30557

Not sure how to associate that with the bug report here??

[hamish]

Apparently fixed by Paul with r30557.