[GRASS-dev] way to create PROJ_INFO and PROJ_UNITS

[andrea antonello]

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