[Gdal-dev] Projection Parameters

Grabowski, Hank hgrabows at stk.com
Thu Jan 8 14:10:49 EST 2004


More info for you guys.  Unluckily I chose an Albers projection as my
default import case.  It turns out for Albers projection, the following
code gets executed:

        GetRoot()->applyRemapper( 
            "PARAMETER", apszAlbersMapping + 1, apszAlbersMapping + 0, 2
);

I *really* need this to be executed for the World Mercatur, North
America Equidistant Cylindrical and maybe other projections as well.  If
I remove the test to only apply this on Albers projections, will this
cause issues for other types of projections?

Hank Grabowski
hgrabowski at stk.com
1-610-578-1000
------------------------------------------------------------------------
----------
Get an opportunity to win an iQue PDA/GPS handheld system by inviting
your friends and colleagues to join the STK user community at
http://www.stk.com/referral. "Share The Knowledge!"


-----Original Message-----
From: Grabowski, Hank 
Sent: Thursday, January 08, 2004 1:36 PM
To: gdal-dev at remotesensing.org
Subject: RE: [Gdal-dev] Projection Parameters


Hey Frank,

I was just using the Validate method in a preliminary pass.
Unfortunately if I simply ignore that step and let OGR try and reproject
the data anyway, I don't get a valid reprojection.  From what I can tell
the importFromESRI function is calling the morphFromESRI function, but
it isn't successfully remapping the parameters.  The projection I'm
trying to import is a World Mercator projection.  Is there a csv
datafile, that I see references to in the code, that I should have
installed?  I'm thinking the answer is no, because the IsAliasFor method
used in ValidateProjection has all the necessary values.  At one point
are these parameters supposed to be swapped or re-interpreted during the
morphFromESRI or importFromESRI function?

Hank Grabowski
hgrabowski at stk.com
1-610-578-1000
------------------------------------------------------------------------
----------
Get an opportunity to win an iQue PDA/GPS handheld system by inviting
your friends and colleagues to join the STK user community at
http://www.stk.com/referral. "Share The Knowledge!"


-----Original Message-----
From: Frank Warmerdam [mailto:warmerdam at pobox.com] 
Sent: Thursday, January 08, 2004 1:27 PM
To: gdal-dev at remotesensing.org
Subject: Re: [Gdal-dev] Projection Parameters


Grabowski, Hank wrote:
> Hello again,
>  
> We are continuing to use, quite successfully, the OGR library for
> doing
> automatic reprojections of data for our application.  However in 
> internal testing I found a weird issue with some of the Parameter 
> variables.  I noticed that there are certain keywords, like 
> Central_Meridian and Latitude_Of_Origin that vary between ESRI code
and 
> the OGR code.  Looking at it in debug mode I discover that the
> ValidateProjection method is aware of the discrepancy and is able to
map 
> between the OGR values, Longitude_of_Center and Latitude_Of_Center in
> this case, but instead throws an error and aborts the loading process.

> Should the true behavior be for the code to remap the names to their
> respective OGR values?  If the internal code is capable of parsing it,

> thus removing the need for actually changing the label, shouldn't the
> loop continue on and allow future variables to be read anyway? 

Hank,

The Validate() method is (in theory) intended to verify that a given
OGRSpatialReference is fully legitimate according to OGC WKT specs. It
doesn't really do that all that well, but it tries.  So it values to
validate aliases because they aren't the "legal" values.

I presume what you really want is a Validate() method that verifies that
an OGRSpatialReference is usable form, as opposed to being "standards
compliant".  Is that right?  Unfortuatenly, that currently doesn't
exist. I would suggest just trying to use the coordinate systems, and
see if they fail.

I would also note that when loading ESRI WKT projections, you should
consider using the morphFromESRI() method to convert ESRI names to more
normal OGR names. The Fixup() method is also useful in filling in
defaults and fixing some things that can be technically wrong when
pulled in from various WKT sources.

I hope this helps.

Best regards,

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


_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev
_______________________________________________
Gdal-dev mailing list
Gdal-dev at remotesensing.org
http://remotesensing.org/mailman/listinfo/gdal-dev



More information about the Gdal-dev mailing list