Re: [postgis-users] Substantial different index use between 9.5 and 9.6 using Postgis

2016-12-04 Thread Sandro Santilli
On Sun, Dec 04, 2016 at 02:46:03PM +1100, Bill Measday wrote: > This looks odd. Here is what pgAdmin tells me if is the current definition > of st_setsrid (cost of 1.0) > > CREATE OR REPLACE FUNCTION public.st_setsrid( > geog geography, > srid integer) > RETURNS geography > LANGUAG

Re: [postgis-users] Substantial different index use between 9.5 and 9.6 using Postgis

2016-12-04 Thread Bill Measday
Just checking that someone was paying attention [cough] Thanks - that explains it. Bill On 4/12/2016 9:17 PM, Sandro Santilli wrote: On Sun, Dec 04, 2016 at 02:46:03PM +1100, Bill Measday wrote: This looks odd. Here is what pgAdmin tells me if is the current definition of st_setsrid (cost of

Re: [postgis-users] PostGIS export - data is inexplicably truncated from 3234 records to 3221 when using 'pgsql2shp', PGAdmin, AND QGIS 2.6+

2016-12-04 Thread Regina Obe
Ruth, Following up on Jorge's answer. I do recall we have some logic with the import and export routines that refuse to import or export invalid geometries. I think the policy has changed over the years and you're running a fairly old install. I forget what the condition is, but I know we spe

Re: [postgis-users] PostGIS export - data is inexplicably truncated from 3234 records to 3221 when using 'pgsql2shp', PGAdmin, AND QGIS 2.6+

2016-12-04 Thread Ben Madin
FWIW, if you are running SELECT gid, st_isValid(geom) FROM data; you might want to try SELECT gid, st_isValid(geom), st_isValidReason(geom) FROM data; As someone that gets a lot of rubbish data, st_isvalidreason() is my # 1 favourite function… cheers Ben > On 2016-12-05, at 00:06 , Regin