[Proj] "Double Ellipsoid" error, reproduction

Gerald I. Evenden geraldi.evenden at gmail.com
Mon Dec 8 10:39:44 EST 2008


On Sunday 07 December 2008 11:18:50 pm Frank Warmerdam wrote:
> Gerald I. Evenden wrote:
> > On Sunday 07 December 2008 10:43:25 pm Richard Greenwood wrote:
	...
> > With that process, Rich can do anything he wants if he is willing to
> > contruct a pipe procedure and learn to directly use proj4 or lproj.
>
> 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=.  
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>

> In the above scenario the original projection from mercator would be
> done using a sphere, while the datum shift is done assuming a WGS84
> ellipsoid.
>
> However, it is not practical for most folks using PROJ.4 in an application
> to do the transformation with a pipeline ... instead the API is called
> directly with a coordinate system defined using pj_init() for the source
> and destination of a pj_transform() call.  In general (for stuff like
> MapServer, GDAL, GRASS, QGIS) all the user can specify is the textual
> PROJ.4 representation of the source and destination coordinate system.

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>

If the "proj=" were omitted on either side, the +latlon would be the default.
The <datum conversion options> could be placed anywhere.

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

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