<HTML dir=ltr><HEAD><TITLE>[Proj] Lambert tangent form to Lambert secant form</TITLE>
<META http-equiv=Content-Type content="text/html; charset=unicode">
<META content="MSHTML 6.00.6000.16587" name=GENERATOR></HEAD>
<BODY>
<DIV id=idOWAReplyText25487 dir=ltr>
<DIV dir=ltr><FONT face="Times New Roman" color=#000000 size=2>The Lambert Conformal Conic with one standard parallel defined with&nbsp; a latitude of origin and a scale factor at origin less than one is a secant Lambert.&nbsp; There are very few truly tangent Lambert Conformal Conic zones extant in the entire world.&nbsp; The difference is what you have a problem with is likely just some algebra.&nbsp; See Chapter 3 of the current "Manual of Photogrammetry" published by the American Society for Photogrammetry and Remote Sensing for some algebraic clues to your conundrum.</FONT></DIV>
<DIV dir=ltr><FONT size=2></FONT>&nbsp;</DIV>
<DIV dir=ltr><FONT size=2>C. Mugnier</FONT></DIV>
<DIV dir=ltr><FONT size=2>Louisiana State University</FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> proj-bounces@lists.maptools.org on behalf of RICHARD Didier<BR><B>Sent:</B> Sun 13-Jan-08 12:18<BR><B>To:</B> proj@lists.maptools.org; gdal-dev@lists.osgeo.org<BR><B>Subject:</B> [Proj] Lambert tangent form to Lambert secant form<BR></FONT><BR></DIV>
<DIV>
<P><FONT size=2>Hi all,<BR><BR>I am facing a bug in the MapInfo driver of GDAL that might need some<BR>modifications of PROJ.4. The bug is two fold :<BR><BR>- MapInfo driver only supports 1SP LCC when building the CoordSys string.<BR>Before, I implement an algorithm that modify LCC 1SP parameters to LCC 2SP<BR>parameters. I would like to know whether someone on the list has already<BR>implemented such a code. Another point is how to wrap that in GDAL (I<BR>address this question to those who are on both list);<BR><BR>- When I use a SRS definition with both nadgrids and towgs84 parameters in<BR>a PROJ.4 string, the later is not taken into account. Therefore, a WKT<BR>string of such a SRS lacks the TOWGS84 block. As a consequence, the<BR>MapInfo driver is not able to code the datum correctly (104 is written<BR>which is the WGS84 datum). I would like to suggest to modify<BR>pj_datum_set.c to keep storing towgs84 values even when nadgrids have been<BR>encountered. The idea is to keep the datum_type has PJD_GRIDSHIFT in order<BR>to keep precise coordinates transformation with grid and to parse the<BR>towgs84 (from line 113). I don't know if there are known or already<BR>debated issues on that, but I would like to know whether this idea is<BR>correct or not.<BR><BR>Any comments/suggestions ?<BR><BR>Sincerely,<BR><BR>didier<BR>--<BR>RICHARD Didier - Chef du pôle technique du Géoportail<BR>2/4, avenue Pasteur - 94165 Saint Mandé Cedex<BR>Tél : +33 (0) 1 43 98 83 23<BR>_______________________________________________<BR>Proj mailing list<BR>Proj@lists.maptools.org<BR><A href="http://lists.maptools.org/mailman/listinfo/proj">http://lists.maptools.org/mailman/listinfo/proj</A><BR></FONT></P></DIV></BODY></HTML>