[GRASS-dev] way to create PROJ_INFO and PROJ_UNITS

Paul Kelly paul-grass at stjohnspoint.co.uk
Wed Feb 27 07:12:37 EST 2008


On Tue, 26 Feb 2008, andrea antonello wrote:
[...]
> But I do feel that it is important to have open formats, where open in
> my opinion not only means that the specification is known and that
> there is one unique software that can read the thing.

Well, GRASS can import from and export to many different open formats... 
but I would not consider the native GRASS database a data transfer format 
in itself.

> If GRASS's
> policy however is to have its own raster and vector formats and proj
> format and let only GRASS itself and direct derivates have real fun on
> them, then I will (have to) accept it, even if not agree.

There isn't really any policy, but the I'm pretty sure compatiblity with 
other software that might want to access GRASS' internal files directly 
was not prominent in the minds of developers designing and extending 
GRASS' internal storage format. I don't think it's unreasonable to expect 
only GRASS to be able to reliably operate on its own internal formats? If 
we had to try and keep it consistent and unchanged so external software 
could always still read it it would be a huge amount of extra work as 
Glynn said.

Regarding your proposal of adding another file to GRASS' internal 
co-ordinate system definition containing the co-ordinate system in WKT 
format, it can't be both ways - either it is considered part of the 
internal GRASS data format or it isn't. If it isn't, then GRASS will not 
use it for anything and there will be real way of testing whether it's 
correct and consistent or not. I.e., external software can't rely on it 
exactly representing the current co-ordinate system of the location. If it 
*is* considered part of the internal GRASS data format, then a lot of work 
will have to be put into keeping it in sync with PROJ_INFO/PROJ_UNITS - at 
present just modifying these files is enough to change the co-ordinate 
system of a GRASS location - that will no longer be possible. And how to 
handle co-ordinate systems that can only be specified in one format but 
not the other? I can see it just leading to a confusing mess.

If it would help though, I could properly document the PROJ_INFO / 
PROJ_UNITS format and how it differs from PROJ.4 format (note that 
GDAL/OGR includes lots of functionality for converting to and from PROJ.4 
format and it really isn't necessary to involve PROJ.4 itself at all, 
unless you want to use it for reprojection).

Paul



More information about the grass-dev mailing list