That makes a lot of sense. Perhaps we should use the default values that are hardcoded in ArcGIS when a new FGDB gets created? If someone uses other values, then they may get the slight snapping effect, which would be OK in that case? thoughts?<br>
<br><div class="gmail_quote">On Fri, Jul 1, 2011 at 11:13 AM, Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Nope, it's the Origin and Scale, which between them form a snapping<br>
grid. Unless your point is on the grid, it'll be snapped to a new<br>
location when inserted into file. So my problem was that in my process<br>
<br>
FGDB1>PostGIS>FGDB2<br>
<br>
the grid in FGDB2 was different from that of FGDB1. So everything got<br>
slightly perturbed. The question is, what origin and scale should we<br>
be using? Clearly these are going to need to be file writing options,<br>
but are the defaults OK as it stands? Actually, we know they aren't<br>
(at the moment) because not including a Z origin and scale results in<br>
the Z being zeroed out, which is No Good.<br>
<font color="#888888"><br>
P.<br>
</font><div><div></div><div class="h5"><br>
On Fri, Jul 1, 2011 at 10:56 AM, Ragi Burhum <<a href="mailto:ragi@burhum.com">ragi@burhum.com</a>> wrote:<br>
> Paul,<br>
><br>
> The one line that I think is making the difference is<br>
> <HighPrecision>true</HighPrecision><br>
> because, if memory serves me right, it kicks in logic for using<br>
> 64bit-coordinates internally (actually I remember something about the sign<br>
> and the mantissa being 53bits - can't recall exactly). ESRI migrated to what<br>
> they call high precision coordinate system in ArcGIS 9.2. So all the<br>
> software really expects the coordinate system to be declared that way by<br>
> now. There is a good white paper on the ESRI site that describes how ArcGIS<br>
> manages its coordinate systems internally. I hope that helps.<br>
> - Ragi<br>
><br>
><br>
>> Date: Thu, 30 Jun 2011 13:26:21 -0700<br>
>> From: Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</a>><br>
>> Subject: Re: [gdal-dev] Precision Mystery (FGDB)<br>
>> To: <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
>> Message-ID: <<a href="mailto:BANLkTikNQyhsDkuNFNdEkN3S6GiHL5ihDQ@mail.gmail.com">BANLkTikNQyhsDkuNFNdEkN3S6GiHL5ihDQ@mail.gmail.com</a>><br>
>> Content-Type: text/plain; charset=ISO-8859-1<br>
>><br>
>> OKAY, found it, and it's an odd one. It has nothing to do with the<br>
>> shape buffers or the transit into PostGIS... I just wrote a small<br>
>> program that uses the FGDB API almost exclusively, it only uses OGR to<br>
>> write the shape buffer.<br>
>><br>
>> And the difference is in the declaration of the SRS... when I declare<br>
>> a UTM srs with the following extra XML<br>
>><br>
>> <XOrigin>-5120900</XOrigin><br>
>> <YOrigin>-9998100</YOrigin><br>
>> <XYScale>10000</XYScale><br>
>> <ZOrigin>-100000</ZOrigin><br>
>> <ZScale>10000</ZScale><br>
>> <MOrigin>-100000</MOrigin><br>
>> <MScale>10000</MScale><br>
>> <XYTolerance>0.001</XYTolerance><br>
>> <ZTolerance>0.001</ZTolerance><br>
>> <MTolerance>0.001</MTolerance><br>
>> <HighPrecision>true</HighPrecision><br>
>><br>
>> Then writing the POINT(1 2 3) and reading back with ogrinfo I get<br>
>><br>
>> FID Column = OBJECTID<br>
>> Geometry Column = SHAPE<br>
>> OGRFeature(test):1<br>
>> POINT (1 2 3)<br>
>><br>
>> But if I omit those lines, I get:<br>
>><br>
>> FID Column = OBJECTID<br>
>> Geometry Column = SHAPE<br>
>> OGRFeature(test):1<br>
>> POINT (1.000001729731139 1.999981429457875 0.0)<br>
>><br>
>> Weird precision changes and my Z is gone! So those things matter...<br>
>> but what do they do...<br>
>><br>
>> P.<br>
>><br>
</div></div></blockquote></div><br>