Opened 16 years ago

Closed 14 years ago

#94 closed defect (fixed)

PROJ file sometimes not created with location

Reported by: cmbarton Owned by: grass-dev@…
Priority: major Milestone: 6.4.0
Component: Default Version: svn-trunk
Keywords: location PROJ projection g.proj Cc:
CPU: Unspecified Platform: Unspecified


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


Change History (4)

comment:1 by pkelly, 16 years ago

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.


comment:2 by pkelly, 16 years ago

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.

comment:3 by pkelly, 16 years ago

Changeset 30557.

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

comment:4 by hamish, 14 years ago

CPU: Unspecified
Platform: Unspecified
Resolution: fixed
Status: newclosed

Apparently fixed by Paul with r30557.

Note: See TracTickets for help on using tickets.