Opened 10 years ago

Closed 10 years ago

Last modified 10 years ago

#3025 closed defect (wontfix)

Analyze not creating spatial statistics on LineString Z geometry

Reported by: rightway Owned by: pramsey
Priority: medium Milestone: PostGIS 2.1.6
Component: postgis Version: 2.1.x
Keywords: extents, analyze Cc:

Description

I’ve loaded a line shapefile containing height information into PostGIS using OGR2OGR. The shapefile has loaded OK and the geometry all seems to be fine in PostGIS, showing as a LineStringZ geometry.

When I run st_estimated_extent on the table it fails with the error message ‘ERROR: stats for “testlayer.shape” do not exist. When I run an analyze on the table it says "NOTICE: no non-null/empty features, unable to compute statistics"

Running st_isvalidreason(shape) on the table says that all the geometry is valid.

I haven't had the chance to test any other types of 'Z' or 'M' geometry but I assume they behave the same way.

We are running on: PostGIS 2.1.5 64 bit Postgres 9.3.5 64 bit Windows 2012

Attachments (1)

Sample_Routes.zip (17.5 KB ) - added by rightway 10 years ago.

Download all attachments as: .zip

Change History (7)

comment:1 by pramsey, 10 years ago

Could you attach the file to the ticket? I need to recreate the problem to fix it. Thanks!

by rightway, 10 years ago

Attachment: Sample_Routes.zip added

comment:2 by rightway, 10 years ago

I've uploaded a sample file. I notice that ogr2ogr defaults to loading the shapefile as a linestringZ, while the postgis shapefile loader loads it in as MultiLinestringM, but either way extents are not calculated.

comment:3 by pramsey, 10 years ago

The problem is that the third dimensions is garbage

308,289680.5366 693147.6176 -1.79769313486232e+308

Every vertex seems to have -1.79769313486232e+308 as the M value. (Since ogr2ogr doesn't understand M, it has to interpret it as Z)

comment:4 by robe, 10 years ago

Milestone: PostGIS 2.1.6

comment:5 by pramsey, 10 years ago

Resolution: wontfix
Status: newclosed

comment:6 by rightway, 10 years ago

Thanks, finally managed to create a valid linestringZ dataset and verified that st_estimatedextent does work with it.

I guess that my only comment is that if the geometry isn't valid enough to analyze then it would be helpful if the st_isvalid and st_isvalidreason commands picked up this error. Either that or get the analyze to ignore dodgy Z and M values and still work out the extents which is only a box2d anyway.

Note: See TracTickets for help on using tickets.