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