[gdal-dev] Precision Mystery (FGDB)

[Ragi Burhum]

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?

On Fri, Jul 1, 2011 at 11:13 AM, Paul Ramsey <pramsey at cleverelephant.ca>wrote:

> Nope, it's the Origin and Scale, which between them form a snapping
> grid. Unless your point is on the grid, it'll be snapped to a new
> location when inserted into file. So my problem was that in my process
>
> FGDB1>PostGIS>FGDB2
>
> the grid in FGDB2 was different from that of FGDB1. So everything got
> slightly perturbed. The question is, what origin and scale should we
> be using? Clearly these are going to need to be file writing options,
> but are the defaults OK as it stands? Actually, we know they aren't
> (at the moment) because not including a Z origin and scale results in
> the Z being zeroed out, which is No Good.
>
> P.
>
> On Fri, Jul 1, 2011 at 10:56 AM, Ragi Burhum <ragi at burhum.com> wrote:
> > Paul,
> >
> > The one line that I think is making the difference is
> > <HighPrecision>true</HighPrecision>
> > because, if memory serves me right, it kicks in logic for using
> > 64bit-coordinates internally (actually I remember something about the
> sign
> > and the mantissa being 53bits - can't recall exactly). ESRI migrated to
> what
> > they call high precision coordinate system in ArcGIS 9.2. So all the
> > software really expects the coordinate system to be declared that way by
> > now. There is a good white paper on the ESRI site that describes how
> ArcGIS
> > manages its coordinate systems internally. I hope that helps.
> > - Ragi
> >
> >
> >> Date: Thu, 30 Jun 2011 13:26:21 -0700
> >> From: Paul Ramsey <pramsey at cleverelephant.ca>
> >> Subject: Re: [gdal-dev] Precision Mystery (FGDB)
> >> To: gdal-dev at lists.osgeo.org
> >> Message-ID: <BANLkTikNQyhsDkuNFNdEkN3S6GiHL5ihDQ at mail.gmail.com>
> >> Content-Type: text/plain; charset=ISO-8859-1
> >>
> >> 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.
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110701/4ed37f3f/attachment-0001.html