[gdal-dev] convert shapefile from California State Plane to EPSG:4326

[maning sambale]

Thanks Daniel and Even,

Using following Even's advice, I get better results:
https://gist.github.com/maning/093a866fd465ea880032#better-conversion

> Wondering if it might be appropriate to change proj.4 defaults to the above ?

+1

On Mon, Feb 8, 2016 at 10:00 PM, Daniel Fenton <dmfenton at gmail.com> wrote:
> I don't pretend to be an expert on this subject although we certainly do
> have experts at Esri.
>
> Anyways, it's been explained to me that the exact datum transformation
> depends on the geography of the source data, as well as the exact time. The
> datum conversion I offered was given to me as the most general
> transformation between NAD83 and WGS84.
>
> One should expect the transformed data to be slightly off from the source.
> This is not a worry though because it is highly unlikely that the source
> data capture is rated to the precision level that matches the change.
>
> On Mon, Feb 8, 2016 at 11:17 AM Even Rouault <even.rouault at spatialys.com>
> wrote:
>>
>> Le lundi 08 février 2016 15:54:11, Daniel Fenton a écrit :
>> > Hi Maning,
>> >
>> > For NAD83 you need to convert the Datum to WGS84. The WKT string you
>> > show
>> > does not include that conversion. Proj.4 is missing these in a lot of
>> > cases.
>> >
>> > Try this string instead:
>> >
>> >
>> > PROJCS["NAD83_California_zone_5_ftUS",GEOGCS["GCS_North_American_1983",DATU
>> >
>> > M["D_North_American_1983",SPHEROID["GRS_1980",6378137,298.257222101]],TOWGS
>> >
>> > 84[-0.9956,1.9013,0.5215,0.025915,0.009426,0.011599,-0.00062],PRIMEM["Green
>> >
>> > wich",0],UNIT["Degree",0.017453292519943295]],PROJECTION["Lambert_Conformal
>> >
>> > _Conic"],PARAMETER["standard_parallel_1",35.46666666666667],PARAMETER["stan
>> >
>> > dard_parallel_2",34.03333333333333],PARAMETER["latitude_of_origin",33.5],PA
>> >
>> > RAMETER["central_meridian",-118],PARAMETER["false_easting",6561666.667],PAR
>> >
>> > AMETER["false_northing",1640416.667],UNIT["Foot_US",0.30480060960121924]]
>> >
>> > Hopefully that works for you. Let me know if it doesn't.
>>
>> (CC'ing proj mailing list)
>>
>> That's interesting, as indeed, proj assumes that WGS84 == NAD83, if no
>> extra parameters
>> are specified. Comparing the TOWGS84 values you suggest with the EPSG
>> database,
>> I see you suggest using EPSG:6866 coordinate transformation "ITRF2000 to
>> NAD83(CORS96)"
>> (actually the opposite transformation, NAD83(CORS96) to ITRF2000).
>>
>> Wondering if it might be appropriate to change proj.4 defaults to the
>> above ?
>>
>> Although it is not clear to me which realization of WGS84 is supposed to
>> be the one used
>> by proj.4 as its pivot when datum transformations are involved. I guess
>> this must depends
>> on the semantics of the grid or towgs84 parameters used...
>>
>> There's also the EPSG:6864 (ITRF96 to NAD83(CORS96)) values that could be
>> used if we rely rather
>> on the original WGS84 realization : -0.9910,
>> 1.9072,0.5129,0.02579,0.00965,0.01166,0
>>
>>
>> Using the HTDP grids ( https://trac.osgeo.org/proj/wiki/HTDPGrids ) might
>> also be an option.
>>
>>
>> Indeed Daniel's suggestion seems to do the trick, or at least better match
>> other data from the site
>> http://geohub.lacity.org/datasets/813fcefde1f64b209103107b26a8909f_0
>> . I see it has also a geojson output :
>>
>> http://geohub.lacity.org/datasets/813fcefde1f64b209103107b26a8909f_0.geojson
>>
>> And the first feature returned is OBJECT_ID=4001 whose first vertex is :
>> -118.276946349107,33.7920287419671
>>
>> If I do,
>> ogr2ogr -f kml /vsistdout/ /vsizip/Building_Footprints.zip  -where
>> "OBJECTID=4001"
>>
>> I get :
>> -118.276934177326,33.7920239166625
>>
>> which is off by a bit more than 1 meter from the position of the geojson
>> output.
>>
>> But If I do :
>>
>> ogr2ogr -f kml /vsistdout/ /vsizip/Building_Footprints.zip  -where
>> "OBJECTID=4001" \
>>  -s_srs "+proj=lcc +lat_1=35.46666666666667 +lat_2=34.03333333333333 \
>> +lat_0=33.5 +lon_0=-118 +x_0=2000000.000101601 +y_0=500000.0001016002 \
>> +ellps=GRS80
>> +towgs84=-0.9956,1.9013,0.5215,0.025915,0.009426,0.011599,-0.00062
>> +units=us-ft +no_defs" \
>> -t_srs EPSG:4326
>>
>> I get:
>>
>> -118.276946349109,33.7920287419681
>>
>> which is identical to the geojson output (difference is in the 10
>> micrometer precision range)
>>
>> >
>> > Daniel Fenton
>> > Software Engineer
>> > Esri R&D
>> >
>> > On Mon, Feb 8, 2016 at 6:56 AM maning sambale
>> > <emmanuel.sambale at gmail.com>
>> >
>> > wrote:
>> > > Hi,
>> > >
>> > > I'm trying to convert LA City building data from State Plane to
>> > > EPSG:4326. I converted the data using ogr2ogr.  Visually inspecting
>> > > using Bing imagery, I'm seeing an offset.
>> > >
>> > > Details of SRS info and sample images here:
>> > > https://gist.github.com/maning/093a866fd465ea880032
>> > >
>> > > It is possible that Bing has the offset, but the source of Bing comes
>> > > from LARIAC (Los Angeles Region Imagery Acquisition Consortium)
>> > > imagery, the same source as the building footprints were traced.
>> > >
>> > > Any hints on the "proper" conversion from State Plane to EPSG:4326.
>> > >
>> > > --
>> > > cheers,
>> > > maning
>> > > ------------------------------------------------------
>> > > "Freedom is still the most radical idea of all" -N.Branden
>> > > https://epsg4253.wordpress.com/
>> > > http://twitter.com/maningsambale
>> > > ------------------------------------------------------
>> > > _______________________________________________
>> > > gdal-dev mailing list
>> > > gdal-dev at lists.osgeo.org
>> > > http://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>> --
>> Spatialys - Geospatial professional services
>> http://www.spatialys.com



-- 
cheers,
maning
------------------------------------------------------
"Freedom is still the most radical idea of all" -N.Branden
https://epsg4253.wordpress.com/
http://twitter.com/maningsambale
------------------------------------------------------