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 _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
