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

[Daniel Fenton]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20160208/40fc0685/attachment.html>