[GRASS-dev] way to create PROJ_INFO and PROJ_UNITS

[andrea antonello]

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

Alright, this comes new to me. Pretty strange, since I wrote the jni
wrapper to proj in order to gain the info needed to create the
PROJ_INFO in java. I'll have to check, this has been ages ago.

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

I can see your point of view and understand also what you say about
the somtimes-differences between GRASS proj and WKT and so on.
However I assume That it should be possible to supply a WKT with added
towgs parameters that can be read from the java community.

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

You are right, the problem will be there at some point. I started with
JNI wrappers in early days. But that is something I won't do again, if
not in extreme situations. I started to develop in java also for its
portability.

>  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. :)

Paul, it is not a problem, as long as we at least talk. I prefer a
harsh answer against a non-answer :)

I'm just sad that we can't get a bit closer to each other
(GRASS-JGrass). I made all possible efforts, but can't solve this one.
I passed the last years just hearing "it is slow", "it is not GPL",
"it is wasted time", but in the meanwhile I build a business around
that works and yet think it has been the right way to go. But I also
developed a lot for GRASS in the past, so I know both world pretty
well.
Now that JGrass is merging into Udig, I felt that it would be worth to
try once again to get some more interaction, that is why I asked once
more. I don't want to loose the GRASS compatibility since I use a lot
GRASS.
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. 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.

Just my 2c,
Andrea