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 <[email protected]> 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 <[email protected]> > 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 >> > <[email protected]> >> > >> > 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 >> > > [email protected] >> > > 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 ------------------------------------------------------ _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
