| From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
|---|---|
| To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Emre Hasegeli <emre(at)hasegeli(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andreas Karlsson <andreas(at)proxel(dot)se>, Teodor Sigaev <teodor(at)sigaev(dot)ru> |
| Subject: | Re: Floating point comparison inconsistencies of the geometric types |
| Date: | 2016-06-01 15:59:52 |
| Message-ID: | aea67ff8-c088-4e5a-1106-41e1508eee6a@BlueTreble.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 6/1/16 10:03 AM, Paul Ramsey wrote:
> We don't depend on these, we have our own :/
> The real answer for a GIS system is to have an explicit tolerance
> parameter for calculations like distance/touching/containment, but
> unfortunately we didn't do that so now we have our own
> compatibility/boil the ocean problem if we ever wanted/were funded to
> add one.
Well it sounds like what's currently happening in Postgres is probably
going to change, so how might we structure that to help PostGIS? Would
simply lopping off the last few bits of the significand/mantissa work,
or is that not enough when different GRSes are involved?
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
Data in Trouble? Get it in Treble! http://BlueTreble.com
855-TREBLE2 (855-873-2532) mobile: 512-569-9461
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2016-06-01 16:07:51 | Re: JSON[B] arrays are second-class citizens |
| Previous Message | Jim Nasby | 2016-06-01 15:55:44 | Re: JSON[B] arrays are second-class citizens |