> [...] > > > 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.
Alright, but since we started JGrass with the thought to extend GRASS with our functionalities, we chose to base on the same format whenever possible. I yet believe that has been and is a great choice we did. > > 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. I can see your points and respect the GRASS community decisions. As such I promise I will never ask this one again (not sure I will be able to :) ). > 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). That would for sure be of great help to extend my knowledge in this issue. Thanks for this discussion, Regards, Andrea > > Paul > > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
