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

[Maciek Sieczka]

Hi Paul,

On pon, 2005-11-28 at 23:10 +0000, Paul Kelly wrote: 
> 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

Grass specific ellipsoid names, different than PROJ.4 names, are alone
confusing enough.

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

That is not a solution IMHO. Users want to use ellipsoids names - not
their dimensions, eccentricity squared black magic, inverse flattening
or whatever. When I do "g.proj -p" or look into PROJ_INFO I need to know
what ellipsoid is used.

Interestingly, when setting up the location at Grass startup or with
g.setproj ellps names are used, not dimensions as in case of other methods.

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

There is a pretty annoying thing about datum for krassovsky - sometimes
Grass uses name S-42, sometimes Pulkovo 42 and sometimes both. Either
use only one or both all the time, please. Otherwise it may seem to a newbie they indicate something different.

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

Ok. If it is really needed, please support the old names for backawrds
comptatibility, but accept th PROJ.4 names too. Currently the lack of support for PROJ.4 ellipsoid names is confusing and poses a problem, really.

Imagine this:
1. the user wants to know what ellipsoids are possible in Grass
2. he already knows Grass depends on PROJ.4
3. he won't even consider referring to Grass documentation for supported
ellipsoids list, it's not logical considering point 2
4. he refers to PROJ.4 documentation
5. cs2cs -le (or proj -le)
6. picks up "krass"
7. Grass doesn't recognize it - while it should
8. where's the logics he asks


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

Support PROJ.4 names.


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

Ok, stay flexible in reagrd to cAsEs if you really think it is worth it.
But default to PROJ.4 names - GRS80 in this example. Is there a practical reason Grass really has to differ in this regard from PROJ.4?

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

I see. Fine.

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

Not really. I'm refering to the lack of consequnce and lack of user
friendlines in regard to coordinate systems in Grass - the PROJ_INFO
syntax differs depending on what method is used to set up a location and
and it is different from what we would expect knowing that Grass depends
on PROJ.4. PROJ.4 is sort of a standard for coordinate systems in FOSS
GIS community an I believe Grass shouldn't force it's own nomenclature here.

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

It is not that bad actaully. Fairly starightforward. If only it's output coluld conform to PROJ.4 (this refers to other location setup methods too) it would be ok.

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

I mean that a good starting point for teaching how to handle coordinate
systems in Grass is  explaining that Grass depends on PROJ.4. and some
simple examples of coordinates transformation using cs2cs. But after
this people find it strange that ellipsoids names are different in
PROJ_INFO that in the +ellps= they've just used for cs2cs, or that there
is no ellipsoid name in spite of it was given explicitely to "g.proj
proj4=-". Or this ll and latlong issue.

> You should be able to convert any
> PROJ.4 projection string to GRASS format using g.proj with the proj4=
> option.

Sure. Could you only use the same names in PROJ_INFO that PROJ.4 does?

> > 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 consider it quite an issue since geographic coordinate system are
widely used. Again, PROJ.4 uses "latlong", Grass forces it's "ll". Don't
confuse the user.

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

It is Grass that depends on PROJ.4, not the other way round. The logics
and straightforwardness sake. Grass is not the centre of the world.
There is GDAL/OGR, QGIS and other apps which also depend on PROJ.4 and
they somehow conform to PROJ.4 standards. I can imagine a QGIS user
trying to sort out why Grass doesn't undesrtand the following:

proj: latlong
ellps: krass

I also wonder how much time will it take him to sort out he is supposed
to use:

proj: ll
ellps: krassovsky

...while any other common projection name (tmerc, stere, lcc) or
ellipsoid name (bessel, WGS84, GRS80) works in Grass.

If Grass PROJ_INFO was completely different than what we are used to in
PROJ.4, it would be actually easier to cope with. The point is that
PROJ_INFO mostly conforms to PROJ.4 syntax, while it has some slight,
but critical differences - unexpected and nonsense from the user point
of view, missleading.

> They are just different and always have
> been. To change them would introduce incompatibilities and break
> things for people unnecessarily.

Support those old, add support PROJ.4 names as well. Nobody will use
Grass flavour soon and the problem's gone.

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

If this is really the case, I won't insist. Anyway, the issue remains
and looks forward to a resolution.


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

But why does it have to be complex for users too? Only because of
legacy?

Cheers,
Maciek


--------------------
Historia, która przeros³a fikcjê. Chcesz poznaæ rozwi±zanie jednej z najwiêkszych tajemnic II wojny ¶wiatowej? 
Przeczytaj BURSZTYNOW¡ KOMNATÊ, Catherine Scott-Clark, Adrian Levy
http://www.rebis.com.pl/rebis/strony/pokaz_ksiazke.html?id=32787