[Proj] "Double Ellipsoid" error, reproduction

[Gerald I. Evenden]

On Monday 08 December 2008 11:01:33 am Frank Warmerdam wrote:
> Gerald I. Evenden wrote:
> >> Yes, this is possible now using pipelining something like:
> >>
> >> proj4 -I +proj=merc +ellps=sphere
> >>
> >>     | cs2cs +proj=latlong +datum=WGS84 +to +proj=latlong +datum=potsdam
> >>     | proj +proj=... +datum=potsdam
> >
> > Whoa.  Proj or the versions I am familiar with do not recognize +datum=.
>
> Gerald,
>
> To be clear, I am speaking of the "PROJ.4" package - the substantially
> altered derivative of the PROJ.4 you developed at the USGS, yet distinct
> from the libproj4 project you now lead.  The PROJ.4 package has had
> a +datum construct for several years now.  I would guess that the PROJ.4
> package I'm speaking of is the one used by the vast majority of end users
> on this list.

It was certainly modified beyond my wildest dreams.  :-(

> I would note that named datums in the currently PROJ.4 expand into
> datum shift parameters and an ellipsoid.  The ellipsoid is then used
> with the projection code.
>
> warmerda at gdal64[1]% proj -ld
> __datum_id__ __ellipse___
> __definition/comments______________________________ WGS84 WGS84       
> towgs84=0,0,0
>        GGRS87 GRS80        towgs84=-199.87,74.79,246.62
>                            Greek_Geodetic_Reference_System_1987
>         NAD83 GRS80        towgs84=0,0,0
>                            North_American_Datum_1983
>         NAD27 clrk66      
> nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat North_American_Datum_1927
>       potsdam bessel       towgs84=606.0,23.0,413.0
>                            Potsdam Rauenberg 1950 DHDN

Of course, this violates my oft repeated law: datums and projections are two 
entirely different entities.

This and remaining discussion is why I had so much difficulty understanding 
the early parts of this thread: I could not conceive that projections would 
be so tightly bound in with non-projection details so as to so severely 
inhibit the obvious inherent flexibility to be expected, at least to me, of 
cs2cs.

My assumptions were what blinded me.

I think more desirable approach is to create a d2d program with optional i/o 
filtering through projection procedures.  One might have options like:

d2d --in=EPSG1234 --out=NAD83_1105

where --in and --out may refer to library systems but one can also have

d2d --in=proj=latlon --datum_in=xyx --datum_out=mm \
          --out="proj=merc ellps=WGS84 R_A"

To me, that kills all mice with flexibility and ease of use.  *AND* you can 
easily use libproj4 updates.  ;-)

The --in --out part is relating to proj use is easy and doable in a couple of 
days.  I can't speak for the datum stuff as I remain, hopefully, totally 
ignorant of the details. ;-)

> > Projections only care about ellipsoid parameters *not* datums.  I would
> > rephrase:
> >
> > proj4 -I +proj=merc +R=12..9 | cs2cs <options> | \
> >      proj4  +ellps=<Potsdam ellipsoid name>
>
> This is indeed an alternate way of expressing such a pipeline, but
> I was trying to make a particular point.
>
> > Would it not be possible to write cs2cs where all the proj control is
> > available on both sides of the +to dividing line?  That is, the pipeline
> > script in cs2cs would could look like:
> >
> > cs2cs +proj=merc +R=12..9 +datum_conversion_options +to \
> >        +proj=merc +ellps=<Potsdam's ellipsoid>
>
> This is what was requested at the start of this thread - that is the
> ability to specify a different ellipsoid to be used with the datum
> conversion than is used with the projection method.  As I mentioned
> to Rich this could be added if it were useful enough.
>
> I would note that right now cs2cs does allow specifying the source
> and destination projections.  I expressed the previous example as a
> pipeline to show that the datum shift step could be isolated from the
> projection steps via the pipeline mechanism using existing commands if
> desired.
>
> > A big part of the problem is that things like EPSG or data sets defining
> > US state plane coordinates system do indeed bind
> > projection-ellipsoid-datum into a single definition.  And that is fine. 
> > *BUT* we do need the flexibility to handle the odd case where the "cs" is
> > not in a convenient library of standard systems.  The "cs" in cs2cs need
> > not be in EPSG or NAD data sets and the user should be free to define all
> > the details themselves like I have proto'ed in the last script example.
> >
> > cs2cs may already do this but it is unclear from current discussions.
>
> With the exception of now allowing distinct ellipsoids for datum shifts
> as opposed to projection operations cs2cs does what you discuss above.
> My previous email was not intended to be an exaustive explanation of what
> cs2cs can do.
>
> Best regards,



-- 
The whole religious complexion of the modern world is due
to the absence from Jerusalem of a lunatic asylum.
-- Havelock Ellis (1859-1939) British psychologist