
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">

<html><head><meta name="qrichtext" content="1" /><style type="text/css">

p, li { white-space: pre-wrap; }

</style></head><body style=" font-family:'monospace'; font-size:9pt; font-weight:400; font-style:normal;">

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> Except that they have a scale factor with LCC 2SP, but it gets silently</p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> dropped by GDAL/PROJ.4.</p>

<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Which is OK. The LCC 2SP formulation just needs the 2 standard parallels and the latitude of origin. Basically when GDAL imports a ESRI WKT and sees that there's 2 standard parallel, it considers it is a LCC_2SP. The scale factor is redundant there. proj.4 doesn't need it when the 2 standard parallels are provided; You need either the 2 standard parallels, or 1 standard parallel + the scale factor, and with some maths you can go from one form to the equivalent other one (the importFromESRI() method could probably be enhanced to check the consistency of the 4 parameters when present and emit a warning in case they are not consistent. Exercice left to contributors)</p>

<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Actually looking at proj.4 code, you must *not* include a +k_0 (other than 1) when using the +lat_1 +lat_2 formulation, otherwise the scale factor would be applied twice.</p>

<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> ... and that looks nothing similar to the Ocotepeque datum shift. They</p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">> are about 400 meters apart.</p>

<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Well that's expected if NAD27 and Octopeque are indeed 2 different datums: there must be a shift between. The EPSG database has also shifts from Octopeque to NAD27. Apparently they also offer the datasets in WGS 84, so you can perhaps check which hypothesis is right from that.</p>

<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>

<p style="-qt-paragraph-type:empty; margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; "> </p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">-- </p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">Spatialys - Geospatial professional services</p>

<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px; margin-right:0px; -qt-block-indent:0; text-indent:0px; -qt-user-state:0;">http://www.spatialys.com</p></body></html>