[GRASS5] Re: [GRASSLIST:9231] krass/krassovsky

[Paul Kelly]

Hello Maciek
The simple answer is that the PROJ_INFO format is very flexible. The
formats created by (a) g.setproj, (b) r.in.gdal/v.in.ogr/g.proj, (c)
manually using your preferred choice of PROJ.4 parameters are all
equally valid.

Basically, any set of parameters that will work with PROJ.4 in any other
application can be used (with the exceptions of ellipsoid and datum
parameters; see below) although certain other formats are accepted for
historical/backward compatiblity, and convenience.

The exceptions are (1) ellipsoid names because GRASS historically has
its own ellipsoid table---that is why PROJ_INFO files created with
r.in.gdal/v.in.ogr/g.proj avoid the confusion of using ellipsoid names
and just include the parameters directly and (2) datum names because
PROJ.4 doesn't have any kind of comprehensive datum listing at all.
GRASS's datum listing and paramter tables are totally separate.

Maciek Sieczka wrote:
> Dear developers,
> 
> Sevaral questions and complaints:
> 
> 1. Does Grass need to have it's own names for ellipsoids? PROJ.4 for
> Krassovsky uses "krass". Grass doesn't recognize it and requires
> "krassovsky".

GRASS had an ellipsoid table before PROJ.4 was brought into GRASS and so
it is different.

> 2. When creating a location from EPSG code in Grass, instead of
> ellipsoids names "a" and "es" are used. Using ellipsoids names would
> make PROJ_INFO less obscure.

But the ellipsoid names are incompatible between GRASS and PROJ.4 so
this would just be very confusing.

> 3. Why does Grass recognize both GRS80 and grs80 (as well as gRs80 and
> other mutations)? PROJ.4 demands GRS80 strictly.

Because the strcasecmp() function (case-insensitive string comparison)
function is used in GPJ_get_ellipsoid_by_name() [6.x] and G_strcasecmp()
in G_get_ellipsoid_by_name() [5.x]. Why not? I think being flexible in
reading PROJ_INFO files is a good thing. The GRASS name is grs80 but
this functionality allows the PROJ.4 version to be recognised.

> 4. Creating a PROJ_INFO form ESPG:2180 inserts a "datum: etrs89" line.
> For what purpose? Wouldn't it better and conformal with PROJ.4 to use
> towgs84: 0,0,0 simply? PROJ.4 doesn't even know what "etrs89" is.

For writing the projection information when exporting to other GIS
formats. If that line wasn't there then there would be no record that
the datum was ETRS89. PROJ.4's datum support isn't great but we need to
know the datum name when writing WKT projection files, for example.

> 5. Beginners I talk about PROJ.4 to find it hard to understand why
> Grass, being dependant on PROJ.4 for handling coordinate systems,
> doesn't fully follow it's convention and complicates issues complicated
> enough.

I think you are talking about g.setproj here and the files it creates.
It is an historical legacy module but is still required for interactive
entry of projection informtion while there is no definitive record of
which parameters are required by each PROJ.4 projection.

> I agree with them - once I learn the correct syntax for a
> projection definition to use with  cs2cs or gdalwarp I have to learn it
> once more for Grass.

Can you explain exactly what you mean? You should be able to convert any
PROJ.4 projection string to GRASS format using g.proj with the proj4=
option.

> 6. What's worse, PROJ_INFO actually follows PROJ.4 convention in some
> aspects, but in other it doesn't. This is confussing - eg. once I learn
> "tmerc" means the same for PROJ.4 and Grass I start suspecting that eg.
> ellipsoids will be handled the same way. And it seems to be true for
> some time, until this assumption fails for Krassovsky.

As far as I can think it is the same for everything except ellipsoid and
datum parameters (oh and also that latitude/longitude is known as ll in
GRASS and longlat in PROJ). I don't see any compelling reason why GRASS
should be changed to conform with PROJ.4 over why PROJ.4 should be
changed to conform with GRASS. They are just different and always have
been. To change them would introduce incompatibilities and break things
for people unnecessarily.

It would be a very large amount of work to change it as Helena said but
possible I suppose. But there are other areas of GRASS that would be
better deserving of effort from the quality of programmer that would be
needed to sort this out!

> All these make teaching PROJ.4 and Grass more complicated than needed.
> Anybody thinks the same? Opposite?

Yes I agree it is extraordinarily complex. It took me several years to
get my head round it all.

If you want to read some complex discussion about the inter-connections
between GRASS and PROJ please see here:
http://www.kergis.org/doc/proj.html at Thierry Laronde's KerGIS site
(which is coming on really well; well worth a look!)

Paul