Can't compile under Windows mingw since raster commit

[robe]

Since the ST_Intersects feature add, I don't seem to be able to compile anymore.

Getting all sorts of weird errors:

rt_api.c:8492: error: redefinition of 'hasnodataL'
rt_api.c:8312: error: previous definition of 'hasnodataL' was here
rt_api.c:8492: warning: passing arg 1 of `rt_band_get_hasnodata_flag' makes pointer from integer without a cast
rt_api.c:8492: error: initializer element is not constant
rt_api.c:8492: warning: data definition has no type or storage class
rt_api.c:8493: error: syntax error before "if"
rt_api.c:8499: warning: type defaults to `int' in declaration of `hasnodataL'
rt_api.c:8499: error: redefinition of 'hasnodataL'
rt_api.c:8492: error: previous definition of 'hasnodataL' was here
rt_api.c:8499: error: redefinition of 'hasnodataL'

See attached build log files.

I'm compiling against gdal trunk r23095.

[Bborie Park]

Regina,

Based upon build90.log between lines 280 and 297, it looks like lwgeom_geos.h can't find geos_c.h. The same error is present on line 289 of build84.log.

-bborie

[robe]

Any thoughts why this would change. It was working fine yesterday when I last compiled.

[strk]

Either a missing ./configure run (geos_c.h is generated from geos_c.h.in at configure time) or a change in the Makefile stripping the correct -I out. Check if the file is there (capi/geos_c.h)

[robe]

I assume my capi is okay since I can compile and make check without raster support fine.

I did notice in Bborie's r7884 commit he did introduce the geos header. #include "lwgeom_geos.h"

on line 107. I assume that is when my problems started. I was trying to figure out how that is different from postgis folder. One thing I did notice is that the postgis folder has a copy of lwgeom_geos.c/h, which seems to me a bit redundant with the ones in liblwgeom and raster seems to be going for the liblwgeom copies. Why do we have these files in both postgis and liblwgeom? I thought that was one of the reasons of this separation to reduce this redundancy.

[robe]

okay I see on closer inspection that the postgis lwgeom_geos.h references the one in liblwgeom so they aren't duplicates of each other as I had originally thought. Don't see a similar pattern for raster and copying over doesn't help presumably because postgis one has relative paths that would not work in raster folder.

[strk]

It's just a name conflict, they are different headers. What does rt_api.c needs lwgeom_geos.h for ?

[robe]

for the new raster / raster intersects functionality Bborie added. He uses LWGEOM2GEOS functions etc.

Though I'm wondering if this is failing for me for same reason raster says my GDAL doesn't have Geos Polygonize support. Bborie — does your functionality require GDAL be compiled with GEOS? I assume not but I could be mistaken.

[Bborie Park]

The ST_Intersects function does not use any GDAL functionality. The lwgeom_geos.h is used for testing the convex hulls of the two rasters for intersection and if one raster is completely within the other.

The relevant bit of code that needs lwgeom_geos.h is on line 8350 and in the code block below.

	do {
		int rtn;

		initGEOS(lwnotice, lwgeom_geos_error);

		rtn = 1;
		for (i = 0; i < 2; i++) {
			hull[i] = rt_raster_get_convex_hull(i < 1 ? rast1 : rast2);
			if (NULL == hull[i]) {
				for (j = 0; j < i; j++) {
					GEOSGeom_destroy(ghull[j]);
					lwpoly_free(hull[j]);
				}
				rtn = 0;
				break;
			}
			ghull[i] = (GEOSGeometry *) LWGEOM2GEOS((LWGEOM *) hull[i]);
			if (NULL == ghull[i]) {
				for (j = 0; j < i; j++) {
					GEOSGeom_destroy(ghull[j]);
					lwpoly_free(hull[j]);
				}
				lwpoly_free(hull[i]);
				rtn = 0;
				break;
			}
		}
		if (!rtn) break;

		/* test to see if raster within the other */
		within = 0;
		if (GEOSWithin(ghull[0], ghull[1]) == 1)
			within = -1;
		else if (GEOSWithin(ghull[1], ghull[0]) == 1)
			within = 1;

		if (within != 0)
			rtn = 1;
		else
			rtn = GEOSIntersects(ghull[0], ghull[1]);

		for (i = 0; i < 2; i++) {
			GEOSGeom_destroy(ghull[i]);
			lwpoly_free(hull[i]);
		}

		if (rtn != 2) {
			RASTER_DEBUGF(4, "convex hulls of rasters do %sintersect", rtn != 1 ? "NOT " : "");
			if (rtn != 1) {
				*intersects = 0;
				return 1;
			}
			/* band isn't specified */
			else if (nband1 < 0) {
				*intersects = 1;
				return 1;
			}
		}
	}
	while (0);

[Bborie Park]

Can you try r7889? I don't think it will help you much as I think I need to make one other change to explicitly set GEOS_CPPFLAGS so that gcc knows where the GEOS include path is.

[robe]

Yap still doesn't compile though I don't think I am getting the missing geos_c anymore. I just compiled on my 9.1 so can't recall if I was or wasn't on that one.

[Bborie Park]

Can you post a build log based upon r7889?

[robe]

Sure attached is my revised 90 build smaller than before so I guess that is good and I don't see missing geos_c.h in it.

[Bborie Park]

Can you try r7890? I believe I've fixed the problem.

[robe]

Almost - it wasn't make checking until I added a geos flag in test core at r7891.

Can you verify that change doesn't cause problems for you and that is right.

I'll close this out once I've verified it works on my 8.4 and 9.1 builds

[robe]

Looks good on my 8.4 and 9.1 builds. Thanks Bborie, for jumping on this so quickly. I'm a happy camper again.

[Bborie Park]

Replying to robe:

for the new raster / raster intersects functionality Bborie added. He uses LWGEOM2GEOS functions etc.

Though I'm wondering if this is failing for me for same reason raster says my GDAL doesn't have Geos Polygonize support. Bborie — does your functionality require GDAL be compiled with GEOS? I assume not but I could be mistaken.

I just wanted to make sure and leave a note about GDAL usage in ST_Intersects. The underlying C function rt_raster_intersects uses no GDAL functions. The plpgsql ST_Intersects function does convert the geometry to a raster using ST_AsRaster.