[GRASS-dev] way to create PROJ_INFO and PROJ_UNITS

[Paul Kelly]

Hello Andrea

On Tue, 26 Feb 2008, andrea antonello wrote:

> [...]
>> > 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?
>>
>>  You haven't really answered Paul's question: What is the problem with
>>  using the current g.proj '-w' or '-e' flags ?
>
> The answer to that is in the begin of the post. I need to create the
> projection information without proj.

g.proj is a GRASS module. It's not part of any PROJ.4 distribution; in 
fact it doesn't need to use any PROJ.4 functions for any of its output 
modes (it uses GDAL/OGR).

> Let's put it that way: why is it possible to get projection
> transformation parameters from a shapefile's prj file without proj
> libs but it is impossible to do the same with a grass location?

The coincidence is that the internal format used in the Shapefile and the 
internal format you want to use in your appication are the same or 
similar. Probably they aren't *exactly* the same, e.g. the software that 
creates the Shapefile might have a slightly different interpretation of 
some of the WKT fields than your software, but in general they are close 
enough that they are compatible without you having to use any explicit 
conversion step.
However the internal format used in GRASS is different (it predates both 
Shapefiles and Java, AFAIK), thus you need to use GRASS functions to 
convert it into a format that your software understands. I still don't see 
why we need to change or add to the internal files GRASS uses for the 
co-ordinate system, when (a) they serve the current purpose well and (b) 
GRASS already provides functionality, both in C libraries and command-line 
modules, to convert the information to other formats.

In general I think accessing the GRASS database directly without using any 
GRASS functions is only going to lead to problems sooner or later, e.g. 
what about when there is a re-write of the raster storage format?
I'm curious too as to if the software packages you mention read GRASS 
vector maps directly from the GRASS database, or just raster maps? The way 
GDAL uses a plug-in "bridge layer" to access the GRASS libraries and pass 
the data back into GDAL is quite neat; would this not be suitable for 
other projects? Maybe somebody could write a nice little library with Java 
wrappers for all the essential functions to read from a GRASS database and 
then all the Java GIS packages could use it and everything would be nice 
and neat.

Paul

P.S. Apologies if the tone of this e-mail sounds a bit harsh; reading back 
over it, I seem to have turned into a bit of a grumpy old man lately. :)