Opened 14 years ago

Closed 14 years ago

#662 closed defect (fixed)

ST_AddPoint is broken

Reported by: robe Owned by: pramsey
Priority: blocker Milestone: PostGIS 2.0.0
Component: postgis Version: master
Keywords: Cc:

Description

Paul,

I didn't test your very very last set of changes, so this might be fixed. Your bulk load of changes didn't get too far in my maze of traps before setting off alarms.

Can you run the below and see if it works on your system. On my 9.1 alpha2 install it crashes the service.

CREATE TABLE pgis_garden (gid serial);
CREATE TABLE
	SELECT AddGeometryColumn('pgis_garden','the_geom',ST_SRID(the_geom),GeometryType(the_geom),ST_CoordDim(the_geom))
			FROM ((SELECT ST_MakePolygon(ST_AddPoint(ST_AddPoint(ST_MakeLine(ST_SetSRID(ST_MakePointM(i+m,j,m),4326),ST_SetSRID(ST_MakePointM(j+m,i-m,m),4326)),ST_SetSRID(ST_MakePointM(i,j,m),4326)),ST_SetSRID(ST_MakePointM(i+m,j,m),4326)))  As the_geom
		FROM generate_series(-10,50,20) As i
			CROSS JOIN generate_series(50,70, 20) As j
			CROSS JOIN generate_series(1,2) As m
			ORDER BY i, j, m, i*j*m
			)) As foo limit 1;

Change History (6)

comment:1 by pramsey, 14 years ago

It's probably the AddPoint stuff. My latest changes won't have touched that. Basically that last bulk tossed me over the wall and now I have to retrofit a big pile of things. I got the generic regressions running before committing, is there a way we can add more things to the standard 'make check'? Patience with me, it will take a while.

comment:2 by robe, 14 years ago

No worries. I'd be really disappointed if you managed to pass my battery of tests unscathed with that many changes you had there. I'd have to spend more time making them harder to pass. :). I did add some logging so it logs and times the tests so its a bit easier to compare against past tests and spot check things that are failing that shouldn't be. Though even my test has bugs are have to fix.

I'm not sure we want to add more to the make check as opposed to just having varying degrees of make check. The standard one -- for casual changes. A more intense one for things that touch a lot of the code base.

FWIW - I can't run make check in 2.0 because I still get that CUnit error.

cu_tester.c:15:19: dlfcn.h: No such file or directory

I thought we had a bug report for that and Nicklas had a patch, but I can't find that ticket now.

comment:3 by robe, 14 years ago

Okay like Mark mentioned seems CUnit seems to work under mingW if I just get rid of that line. Can we get rid of the

#include <dlfcn.h>

Or does that pose problems for people?

comment:4 by pramsey, 14 years ago

Doesn't seem to be needed... could be something cut'n'pasted from a cunit example. I removed it from trunk at r6189

comment:5 by robe, 14 years ago

Summary: Make POLYGONM geometry crashes serverST_AddPoint is broken

Just retitling this since it's not POLYGONM at fault but as Paul rightfully suspected -- ST_AddPoint is just broken in 2.0. I've excluded ST_AddPoint and ST_MinimumBoundingCircle from my tests for now since both use ST_AddPoint and also replaced geometries built with ST_AddPoint with static ST_GeomFrom... ones.

comment:6 by pramsey, 14 years ago

Resolution: fixed
Status: newclosed

Fixed at r6491

Note: See TracTickets for help on using tickets.