Move up to the latest patch revision of postgis, the 2.1.0 release
definitely had a few subtle issues with geography distance of the sort
you are describing.
P.
On Thu, Jan 8, 2015 at 2:09 PM, Hartranft, Robert M.
(GSFC-423.0)[RAYTHEON COMPANY] wrote:
> Hi All,
>
> I am hoping someone here has e
You have created an index on your geometry column using something like
CREATE INDEX myindex ON mytable (geom);
This has created a b-tree index, which is limited in the object size
it can handle (and won't answer spatial questions efficiently in any
event). Drop it, and replace with a GIST inde
Hi All,
I am hoping someone here has experience with the
issue I am having…
I am using:
-rw-r--r-- 1 postgres postgres 10241357 Oct 8 22:04 gdal-1.10.1.tar.gz
-rw-r--r-- 1 postgres postgres 1813726 Oct 8 22:04 geos-3.4.2.tar.bz2
-rw-r--r-- 1 postgres postgres 340953 Oct 8 22:04 json-c-0
Hugues: Yes, that was it. When I initially created this column, I used 4269.
I was following an example, and this is what was used.I recreated the table
using the default (not specifying) and did the same with my query. This solved
my issue!
Thanks for your help! Hopefully I won't have any
Hi,
You're using different srid between your geometries. It means you're using
different coordinate systems. I don't know how this thing is managed by geoJSON
but if your table uses a single srid (you can ensure that by using type in
postgis 2 or constraint in pgis 1.5) you can use st_transfo
Hugues:
Thanks for the info! I think I'm getting close. Now it seems to work
~sometimes~. It will error if any rows would be returned. But it will not
throw an error if no rows would be returned. I verified with a few queries
that I know the results beforehand, and was able to determine
Hi Joseph,
If you take a look at the error returned, you can read that the problem comes
from the ST_Intersects function which works with geometries but not with text.
I think, if your geoJSON is right formatted, you can just remove the ST_AsText
part and it should work.
However it also
