[Proj] "Double Ellipsoid" error, reproduction
warmerdam at pobox.com
Mon Dec 8 11:01:33 EST 2008
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=.
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.
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% proj -ld
__datum_id__ __ellipse___ __definition/comments______________________________
WGS84 WGS84 towgs84=0,0,0
GGRS87 GRS80 towgs84=-199.87,74.79,246.62
NAD83 GRS80 towgs84=0,0,0
NAD27 clrk66 nadgrids=@conus, at alaska, at ntv2_0.gsb, at ntv1_can.dat
potsdam bessel towgs84=606.0,23.0,413.0
Potsdam Rauenberg 1950 DHDN
> Projections only care about ellipsoid parameters *not* datums. I would
> 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.
I set the clouds in motion - turn up | Frank Warmerdam, warmerdam at pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
More information about the Proj