OKAY, found it, and it's an odd one. It has nothing to do with the
shape buffers or the transit into PostGIS... I just wrote a small
program that uses the FGDB API almost exclusively, it only uses OGR to
write the shape buffer.
And the difference is in the declaration of the SRS... when I declare
a UTM srs with the following extra XML
<XOrigin>-5120900</XOrigin>
<YOrigin>-9998100</YOrigin>
<XYScale>10000</XYScale>
<ZOrigin>-100000</ZOrigin>
<ZScale>10000</ZScale>
<MOrigin>-100000</MOrigin>
<MScale>10000</MScale>
<XYTolerance>0.001</XYTolerance>
<ZTolerance>0.001</ZTolerance>
<MTolerance>0.001</MTolerance>
<HighPrecision>true</HighPrecision>
Then writing the POINT(1 2 3) and reading back with ogrinfo I get
FID Column = OBJECTID
Geometry Column = SHAPE
OGRFeature(test):1
POINT (1 2 3)
But if I omit those lines, I get:
FID Column = OBJECTID
Geometry Column = SHAPE
OGRFeature(test):1
POINT (1.000001729731139 1.999981429457875 0.0)
Weird precision changes and my Z is gone! So those things matter...
but what do they do...
P.
On Thu, Jun 30, 2011 at 11:52 AM, Peter Baumann
<p.baum...@jacobs-university.de> wrote:
> to retain the 3rd dimension, maybe better use WGS84-3D, EPSG:4329 ?
> -Peter
>
>
> On 06/30/2011 08:45 PM, Paul Ramsey wrote:
>>
>> In running a round trip from PostGIS>FGDB>PostGIS for a simple table:
>>
>> 3dgeom=# select st_asewkt(g) from points ;
>> st_asewkt
>> ------------------------
>> SRID=4326;POINT(1 2 3)
>> SRID=4326;POINT(2 3 4)
>> SRID=4326;POINT(3 4 5)
>>
>> When I get to FGDB, I've lost my third dimension (still trying to
>> figure that out)
>>
>> [pramsey@localhost postgis2fgdb]$ ../gdal-svn/gdal/apps/ogrinfo -al
>> ~/3dgeom.gdb
>> INFO: Open of `/home/pramsey/3dgeom.gdb'
>> using driver `FileGDB' successful.
>>
>> Layer name: points
>> Geometry: 3D Point
>> Feature Count: 3
>> Layer SRS WKT:
>> GEOGCS["WGS 84",
>> DATUM["WGS_1984",
>> SPHEROID["WGS 84",6378137,298.257223563,
>> AUTHORITY["EPSG","7030"]],
>> AUTHORITY["EPSG","6326"]],
>> PRIMEM["Greenwich",0,
>> AUTHORITY["EPSG","8901"]],
>> UNIT["degree",0.0174532925199433,
>> AUTHORITY["EPSG","9122"]],
>> AUTHORITY["EPSG","4326"]]
>> FID Column = OBJECTID
>> Geometry Column = g
>> OGRFeature(points):1
>> POINT (1.0 2.0 0.0)
>>
>> OGRFeature(points):2
>> POINT (2.0 3.0 0.0)
>>
>> OGRFeature(points):3
>> POINT (3.0 4.0 0.0)
>>
>> But even odder, when I go back to PostGIS, I've got slight coordinate
>> drift.
>>
>> 3dgeom2=# select st_asewkt(g) from points ;
>> st_asewkt
>> --------------------------------------------------------------------------
>> SRID=4326;POINT(1.00000000000005 2.00000000000001 1.04446235346063e-305)
>> SRID=4326;POINT(2.00000000000005 3.00000000000001 1.04446235346063e-305)
>> SRID=4326;POINT(3.00000000000005 4.00000000000001 1.04446235346063e-305)
>> (3 rows)
>>
>> I just turned on statement logging and watched both the export and the
>> import to PostGIS and in both cases the database is sending and
>> receiving the canonical form (hex ewkb) there is no text
>> representation step. This seems frightfully odd. Any suggestions on
>> debugging steps?
>>
>> Paul
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev@lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
> --
> Dr. Peter Baumann
> - Professor of Computer Science, Jacobs University Bremen
> www.faculty.jacobs-university.de/pbaumann
> mail: p.baum...@jacobs-university.de
> tel: +49-421-200-3178, fax: +49-421-200-493178
> - Executive Director, rasdaman GmbH Bremen (HRB 26793)
> www.rasdaman.com, mail: baum...@rasdaman.com
> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
> "Si forte in alienas manus oberraverit hec peregrina epistola incertis
> ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli
> destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD
> 1083)
>
>
>
>
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
