[GRASS-dev] way to create PROJ_INFO and PROJ_UNITS

[andrea antonello]

Hi Paul,
thanks for your reply.

[...]
>  > I would like to try once more to start a discussion about
>  > standardization (or call it whatever you want) of the projection
>  > information.
>  > All projects that are not using proj have problems to guess and
>  > reconstruct the projection of a GRASS workspace.
>
>  Can you give some specific examples? I think "all" sounds like a bit of a
>  generalisation. What is wrong with the internal GRASS functions
>  GPJ_grass_to_wkt() and GPJ_grass_to_osr()? Or the -p, -d, -j, -w and -e
>  options of g.proj? The GRASS representation can be converted to PROJ.4
>  format without using any external libraries at all, and to WKT format
>  using the OGR libraries of GDAL. PROJ.4 is not required at all for
>  converting to either of those.

Alright, some examples. All geotools based projects are not able to
read the projection info of GRASS, such as obviously JGrass as well as
udig, jump, gvsig, etc etc... I should probably say java based or
non-c based?
At the current time none of those projects is able to cooperate with
GRASS, if not JGrass. In JGrass I have always put all the effort to
base on the GRASS workspace, but in pure java environments, which we
often have to deal with, we need a way to create the projection info
without the use of proj. I tried to maintain it with proj in the past
but it has always been errore prone and a maintenance horror. I also
wrote a small JNI wrapper to proj only for that purpose in the past,
but I can't believe that there isn't an easier way.

>  > Would it be possible to create also a PROJ_INFO.WKT well known text
>  > version of the file whenever a location is created? This would greatly
>  > enhance interoperability between projects, which imho, is necessary.
>
>  I don't think WKT is a very good format to use internally. The WKT
>  descriptions of projections are impenetrable to look at and very easy to
>  make errors in parsing. They also are not very versatile with regards to
>  datum information, in that there is no standard way of specifying a datum
>  gridshift file. AIUI it the WKT definitions are specified by the Open GIS
>  Consortium, which used to be called the Open GRASS Consortium, but
>  obviously has very seriously diverged from GRASS somewhere along the way.
>  I've always wondered about the politics of that, but have no idea really.
>
>  However, any discussion on the merits of GRASS internal co-ordinate system
>  data should be irrelevant to other projects extracting data from GRASS
>  locations, because PROJ_INFO/PROJ_UNITS is an *internal* GRASS format, and
>  GRASS provides functions to convert those representations to other
>  formats. If there is a problem with the tools GRASS provides to extract
>  the projection information, then we should investigate these and try to
>  make them easier to use - I think this would be the path of least
>  resistance.

That is true until you don't want to base on the GRASS workspace,
which we absolutely do. And the projection file is the only thing that
we can't reconstruct, which makes it a GRASS as-if-proprietary thing,
since only proj seems to be able to understand it (glad to be
corrected here). Wouldn't it be possible to supply something that
contains the info to reconstruct the projection information? If not
WKT, make a whatever proposal, I will follow if I can.

>  I guess my point is that it is a reasonable requirement for other software
>  to use GRASS libraries to access data in GRASS locations, rather than
>  reverse engineering the internal GRASS database formats which can and will
>  change in future. But I suppose that is a topic definitely open to
>  debate?....

Why does it seem to strange that we want to base on the grass
database-workspace format to exploit GRASS as well as tools
implemented in java? Why should I always import/export data to do
calculations on them?
In one thing you are right: it should not be necessary to reverse
engineer the grass database, since it is FOSS.

Andrea


>
>  Paul
>