Hi, assume I create a location from outside GRASS and need to create
the PROJ_INFO and PROJ_UNITS files, since without proj there is no way
to do that.
Is there a way to create those file through g.proj from null, best if
supplying the epsg code?
Thanks,
Andrea
andrea antonello wrote:
Hi, assume I create a location from outside GRASS and need to create
the PROJ_INFO and PROJ_UNITS files, since without proj there is no way
to do that.
Is there a way to create those file through g.proj from null, best if
supplying the epsg code?
g.proj -c epsg=...
--
Glynn Clements <glynn@gclements.plus.com>
Thanks,
I didn't notice the "modifies current location unless 'location'
option specified".
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.
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.
Comments welcome,
Andrea
> Hi, assume I create a location from outside GRASS and need to create
> the PROJ_INFO and PROJ_UNITS files, since without proj there is no way
> to do that.
> Is there a way to create those file through g.proj from null, best if
> supplying the epsg code?g.proj -c epsg=...
--
Glynn Clements <glynn@gclements.plus.com>
On Mon, 25 Feb 2008, andrea antonello wrote:
Thanks,
I didn't notice the "modifies current location unless 'location'
option specified".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.
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.
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?....
Paul
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
On 25/02/08 18:57, andrea antonello wrote:
Hi Paul,
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.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?
You haven't really answered Paul's question: What is the problem with using the current g.proj '-w' or '-e' flags ?
Moritz
andrea antonello wrote:
All projects that are not using proj have problems to guess and
reconstruct the projection of a GRASS workspace.
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.
You can get this info at any time from g.proj:
Flags:
-p Print projection information (in conventional GRASS format)
-d Verify datum information and print transformation parameters
-j Print projection information in PROJ.4 format
-w Print projection information in WKT format
-e Use ESRI-style format (applies to WKT output only)
-f Print 'flat' output with no linebreaks (applies to WKT and
PROJ.4 output)
....
Hamish
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
Hi Moritz,
[...]
> 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.
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?
Andrea
PS: this should also answer Hamish's post
Moritz
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. 
> [...]
>> > 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
Paul Kelly wrote:
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,
We don't need to. As you have already pointed out, they are *internal*
formats. GRASS' internal formats exist for GRASS, not for anything
else.
Any change will result in incompatibility between different versions
of GRASS. Although that isn't the end of the world, it's a much more
important issue than any incompatibility with third-party software.
--
Glynn Clements <glynn@gclements.plus.com>
> 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,We don't need to. As you have already pointed out, they are *internal*
formats. GRASS' internal formats exist for GRASS, not for anything
else.Any change will result in incompatibility between different versions
of GRASS. Although that isn't the end of the world, it's a much more
important issue than any incompatibility with third-party software.
Why incompatibility? I can understand that an extra file in the
PERMANENT mapset is not so stylish, but it would make things much
easier for 3rd parties. And it would certainly not break things.
--
Glynn Clements <glynn@gclements.plus.com>
On Tue, 26 Feb 2008, andrea antonello wrote:
[...]
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.
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.
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).
Paul
[...]
> 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
If GRASS is installed you can try a small batch script:
echo "g.proj -w > PROJ_INFO.WKT" > /tmp/get_grass_proj_info.sh
MAPSET="~/grassdata/spearfish60/user1/"
GRASS_BATCH_JOB=/tmp/get_grass_proj_info.sh
export GRASS_BATCH_JOB
grass63 "$MAPSET"
unset GRASS_BATCH_JOB
cat PROJ_INFO.WKT
As mentioned earlier in the thread 'g.proj -c epsg=' will create a new
location from an epsg code. But WKT from EPSG doesn't need GRASS.
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping
If GRASS is installed you can try a small batch script:
echo "g.proj -w > PROJ_INFO.WKT" > /tmp/get_grass_proj_info.sh
MAPSET="~/grassdata/spearfish60/user1/"
GRASS_BATCH_JOB=/tmp/get_grass_proj_info.sh
export GRASS_BATCH_JOB
grass63 "$MAPSET"
unset GRASS_BATCH_JOBcat PROJ_INFO.WKT
As mentioned earlier in the thread 'g.proj -c epsg=' will create a new
location from an epsg code. But WKT from EPSG doesn't need GRASS.
Yes, I needed some time to figure out it is a new feature of 6.3 :),
but now I have it up and running.
This last sentence gives me a new glimmer of hope. Would it be
possible to have in the proj_info file also the epsg code? Now I'm not
in the office and on a mac with grass 6.2, so I can't check if the
epsg code has been already included in the params of the PROJ_INFO
file, so please be patient if it is there already.
Would that in case be possible? In that case i would be able to know
the epsg and also have the bursa wolf parameters. Nifty...
Andrea
Hamish
____________________________________________________________________________________
Looking for last minute shopping deals?
Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping