[gdal-dev] GDAL 3, PROJ 6.2 exportToProj4() drops Datum silently

[Michael Sumner]

> I'm a bit extreme when I say "don't use PROJ strings", but otherwise
people
> don't get it :-) So yes if you don't care about datum transformations,
don't
> use unusual axis orders, you might still use them. They won't disappear
in a
> foreseable future.
> The GDAL OGRSpatialReference class has a number of helper methods to help
you
> build your own custom CRS, like SetLAEA(), SetLCC(), etc. and SetGeogCS()

Oh excellent, that's less scary than I'd understood.

 I'll look at exposing those custom builders in R.

Cheers, Mike.


On Wed, Oct 30, 2019 at 9:33 AM Even Rouault <even.rouault at spatialys.com>
wrote:

> On mercredi 30 octobre 2019 09:22:11 CET Michael Sumner wrote:
> > Great discussion, thanks to both of you.  I have a question.
> >
> > I wonder how we ought to specify a projection that we desire, I work in
> > contexts where 1.5m or even 1.5 km is not an unreasonable level of
> > precision, and we get a lot of value out of specifying local projections
> > (at ocean basin scale) in LAEA, LCC, STERE and others  (OMERC is
> especially
> > good for hermisphere-scale migrating birds, very custom and not related
> to
> > human activities) - PROJ strings are obviously an easy to specify the
> > family and centre point of the projection, and we have a lot of workflows
> > (computer and human) for this. The datum is a bit irrelevant a lot of the
> > time but we always include it and try to explain it to users.
> >
> > Are we expected to express a full WKT or WKT2 string for this?   I know
> we
> > can write wrappers in some language, but there doesn't seem to be a
> culture
> > around crafting custom projections that I can latch onto. Usually I see
> > people looking for an EPSG code for their region, and as often as not
> they
> > end up using UTM because "it's a projection" and no authority has ever
> done
> > a survey in their part of the Southern Ocean and published it with EPSG.
> >
> > Is something like the gdaltransform pipelining syntax the most concise we
> > can aim for, or do we somehow cache our own local EPSG-like codes?
>
> I'm a bit extreme when I say "don't use PROJ strings", but otherwise
> people
> don't get it :-) So yes if you don't care about datum transformations,
> don't
> use unusual axis orders, you might still use them. They won't disappear in
> a
> foreseable future.
> The GDAL OGRSpatialReference class has a number of helper methods to help
> you
> build your own custom CRS, like SetLAEA(), SetLCC(), etc. and SetGeogCS()
>
> The PROJJSON notation might also be slightly easier to work with than WKT2
> (it
> is completely equivalent to it, just using a more standard encoding):
> example at https://github.com/OSGeo/PROJ/pull/1547
> Schema at https://proj.org/schemas/v0.1/projjson.schema.json
>
> Even
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>


-- 
Michael Sumner
Software and Database Engineer
Australian Antarctic Division
Hobart, Australia
e-mail: mdsumner at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20191030/3fe54f5c/attachment-0001.html>