From: Mark Fenbers Date: Mon, 18 Jul 2005 14:03:20 -0400 Subject: [postgis-users] (no subject) In-Reply-To: <5A94289A9268514C8D6C0F1FF44BA0279C3DC4@venus.VividSolutions.com> References: <5A94289A9268514C8D6C0F1FF44BA0279C3DC4@venus.VividSolutions.com> Message-ID: <42DBEEE8.4010508@noaa.gov> 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: