[Proj] "Double Ellipsoid" error, reproduction
Gerald I. Evenden
geraldi.evenden at gmail.com
Mon Dec 8 12:10:28 EST 2008
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
More information about the Proj
mailing list