From: Mark Fenbers <Mark.Fenbers@noaa.gov>
Subject: [postgis-users] (no subject)
Date: Mon, 18 Jul 2005 14:03:20 -0400
Message-ID: <42DBEEE8.4010508@noaa.gov> (raw)
In-Reply-To: <5A94289A9268514C8D6C0F1FF44BA0279C3DC4@venus.VividSolutions.com>
References: <5A94289A9268514C8D6C0F1FF44BA0279C3DC4@venus.VividSolutions.com>
I had a similar problem when the values were different at the 13th
decimal place. This was way too much precision for me, so I was able to
get around the problem by using the SnapToGrid(0.0000001) function on my
data before using the Difference() function, etc.
Mark
Martin Davis wrote:
>Good point, Dave - that would produce the same symptoms.
>
>Hmmm - this sort of thing sounds like it could be a real problem, if
>there's extra junk precision which isn't visible textually, but causes
>strange results in spatial operations. Maybe one answer to this is to
>allow specifying the desired precision when storing and operating on
>PostGIS data? This would have the added benefit of encouraging people
>to store their data with no more than the actual precision contained in
>the original observations.
>
>SDE has this capability by default, since it forces you to define a
>mapping to its internal integer storage. Oracle sort of has this by
>virtue of its tolerance (although AFAIK there's no way of enforcing
>actual storage to a given precision).
>
>Martin Davis, Senior Technical Architect
>Vivid Solutions Inc. www.vividsolutions.com
>Suite #1A-2328 Government Street Victoria, B.C. V8T 5G5
>Phone: (250) 385 6040 - Local 308 Fax: (250) 385 6046
>
>
>
>
>>-----Original Message-----
>>From: postgis-users-bounces at postgis.refractions.net
>>[mailto:postgis-users-bounces at postgis.refractions.net] On
>>Behalf Of dblasby at openplans.org
>>Sent: July 18, 2005 10:36 AM
>>To: postgis-users at postgis.refractions.net
>>Subject: [postgis-users] (no subject)
>>
>>
>>
>>
>>>This sounds like floating point comparisons failing because
>>>
>>>
>>>>of numerical
>>>>rounding issues.
>>>>
>>>>
>>>Highly unlikely - JTS/GEOS is very robust wrt predicates.
>>>
>>>
>>I think he means the 2 geometries arent actually identical -
>>the points maybe "10-7 off". These differences would be
>>hidden by converting to WKT (since it doesnt show all 64bits
>>of precision).
>>
>>Try something like this:
>>
>>SELECT encode( asBinary( geometry1 ) , 'hex'),
>> encode( asBinary( geometry2 ) , 'hex')
>>FROM ... ;
>>
>>And see if the two are actually equal.
>>
>>dave
>>
>>
>>
>>
>>
>>----------------------------------------------------------
>>This mail sent through IMP: https://webmail.limegroup.com/
>>_______________________________________________
>>postgis-users mailing list postgis-users at postgis.refractions.net
>>http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>>
>_______________________________________________
>postgis-users mailing list
>postgis-users at postgis.refractions.net
>http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mark.Fenbers.vcf
Type: text/x-vcard
Size: 283 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20050718/c05fe1da/attachment.vcf;
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: postgis-users@lists.osgeo.org
Cc: Mark.Fenbers@noaa.gov
Subject: Re: [postgis-users] (no subject)
In-Reply-To: <42DBEEE8.4010508@noaa.gov>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox