[wktraster] Implement ST_DumpAsPolygons function for raster

[mloskot]

Function ST_AsPolygon is part of Objective 0.1.6e and shall be implemented:

ST_AsPolygon(raster) -> polygon geometry set

This algorithm is very useful since it ensure that ST_AsRaster(ST_AsPolygon(raster)) should returns the same raster as the original (because it is based on the centroid of the pixel).

Open questions:

• Pierre: Can we directly use the GDAL function by copying the raster data into a GDAL structure or should we just copy/adapt the algorythm?

References:

•  Raster to Polygon Converter implemented in GDAL

[mloskot]

Pierre,

Technically, we can use GDAL function, namely  GDALPolygonize.

However, we have to keep in mind what steps it would require on various levels of use and deployment. It is, roughly:

• GDAL requirement, compile-time and run-time
• Translation of WKT Raster WKB to  GDALDataset with bands (likely using GDAL MEM driver)
• Call to GDALPolygonize to generate  OGRLayer
• Translation of  OGRGeometry objects attached to OGRLayer to PostGIS geometry

[pracine]

Replying to mloskot:

Pierre, Technically, we can use GDAL function, namely  GDALPolygonize. However, we have to keep in mind what steps it would require on various levels of use and deployment. It is, roughly: * GDAL requirement, compile-time and run-time * Translation of WKT Raster WKB to  GDALDataset with bands (likely using GDAL MEM driver) * Call to GDALPolygonize to generate  OGRLayer * Translation of  OGRGeometry objects attached to OGRLayer to PostGIS geometry

Sounds good!

[jorgearevalo]

We should take into account that GDALPolygonize uses a signed 32bit integer buffer (Int32) for the band data. Floating point values will be truncated before processing. This is a limitation for complex bands.

[jorgearevalo]

rt_raster_as_wktpolygon implemented and tested in r5449 with this one-band raster: http://trac.osgeo.org/postgis/attachment/wiki/WKTRaster/SpecificationWorking01/WKTRasterEnvelopeConvexHullAndShape.gif

Comments welcome

[jorgearevalo]

Bug solved: Now only the polygons with stored value distinct from nodata value for the band are return. In r5456.

[robe]

Pierre et al. We'll probably have a lot of questions and bug reports coming up since we are working on the WKT Raster chapter of book.

For the above -- is this exposed as an SQL function yet. Didn't see it. It also seems to rely on GDAL so not sure if that is an additional dependency we need to compile in to expose this or not.

Thanks, Regina

[jorgearevalo]

Replying to robe:

Pierre et al. We'll probably have a lot of questions and bug reports coming up since we are working on the WKT Raster chapter of book. For the above -- is this exposed as an SQL function yet. Didn't see it. It also seems to rely on GDAL so not sure if that is an additional dependency we need to compile in to expose this or not. Thanks, Regina

Hi Regina,

We don't have a SQL function yet, only a core C function. I'll create a SQL function ASAP. Sorry for delay, but I was involved in a different project (and studying) until 2 days ago. And the C function relys on GDAL, yes, but only if you specify the "--enable-development" option during configure. If not, a "dummy" function that only returns 0 is compiled. We may change this in the future.

Best regards, Jorge

[jorgearevalo]

Created ST_DumpASPolygons in r5516. The base function, called RASTER_dumpAsWKTPolygons, is under conditional compilation, because still doesn't work properly. A default "dummy" version returning NULL has been created if no '--enable-development' option is passed to configure script. Any comments welcome.

[pracine]

What is the purpose of the dummy function?

[pracine]

Could you document the compilation process now including GDAL in section 2 of the documentation. What, how do we compile...

http://trac.osgeo.org/postgis/wiki/WKTRaster/Documentation01

[jorgearevalo]

Replying to pracine:

What is the purpose of the dummy function?

Simply to have a function to compile when you don't specify --enable-development option. I thought in this option as a way to activate "experimental" or "under development" features. If you don't specify it, you have a function to compile (a needed function, actually), but a dummy function. For a short time.

[jorgearevalo]

Implemented in r5582. Needs more testing. So, I leave the ticket open by now. Related ticket #494.

[jorgearevalo]

Minor bug solved in r5583.

[robe]

Jorge,

I believe you called this function ST_Polygon?

When I run against this:

SELECT ST_Polygon(rast,1)
FROM pele

I get error ERROR: lwline_deserialize: attempt to deserialize a line which is really a Polygon.

Anyrate haven't upgraded to 1.5.2SVN yet. Same dataset as #494.

I'll attach the dataset to this ticket.

[jorgearevalo]

No, ST_Polygon is a different function. I was working on it just now. Here, the difference:

ST_DumpAsPolygons: http://trac.osgeo.org/postgis/attachment/wiki/WKTRaster/SpecificationWorking01/WKTRasterAsPolygon.gif

ST_Polygon: http://trac.osgeo.org/postgis/attachment/wiki/WKTRaster/SpecificationWorking01/WKTRasterEnvelopeConvexHullAndPolygon.gif

[robe]

Ah okay. This ticket is confusing. So I guess this ticket is redundant and I should have opened another ticket for ST_Polygon. I forgot that ST_AsPolygon is what we now call ST_DumpAsPolygons.

Anyrate ST_Polygon should be the same as ST_Union(ST_DumpAsPolygons) -- correct?

[jorgearevalo]

Don't worry, my fault. I should have remarked the ticket title was confusing when we decided to change the name of the function.

And about ST_Union, tecnically yes. But I'd like to implement a C function, similar to the one implemented for ST_DumpAsPolygons, to make it faster. Anyway, I suppose we could work with ST_Union(ST_DumpAsPolygons) by now...

[jorgearevalo]

Thanks Mateusz! How could I forgot to change the name... Stupid me :-)

[jorgearevalo]

Function ST_Polygon, that collects all the single geometries returned by st_dumpaspolygons, implemented in r5605

[jorgearevalo]

BTW, I'm going to delete the conditional compilation of ST_DumpAsPolygons function. This is important, because now we force the existence of GDAL in the system. Any vote against it?

[pracine]

Replying to jorgearevalo:

BTW, I'm going to delete the conditional compilation of ST_DumpAsPolygons function. This is important, because now we force the existence of GDAL in the system. Any vote against it?

Is GDAL easy to compile for both Windows and Linux users? Is the process well documented? We should ensure this before.

[jorgearevalo]

I think GDAL shouldn't be more difficult to compile on Windows than GEOS, for example. And GEOS is required. But I'm not a Windows developer. I can't ensure it. And ok... GEOS may be easier to compile, but the point is if we're going to compile WKT Raster against GDAL anyway...

About Linux, I think most users will be able to compile the library, at least if they could compile PostGIS, or GEOS.

The process is well documented here:  http://trac.osgeo.org/gdal/wiki/BuildHints

[pracine]

Regina what do you suggest? Are we ready to force our users to compile and link with GDAL?

[robe]

I would go for it. libgdal seemed easier to compile than GEOS actually and compiles faster. So I don't consider it a major obstacle.

If you are doing a minimalist compile which is all that is needed to enable ST_DumpAsPolygons and I assume the others, I don't see it as a major barrier.

Most windows users will just download binaries anyway as the PostGIS compile process under windows is a bare to begin with. I imagine compiling WKT Raster even with GDAL is even easier under Linux, though I haven't tried yet.

[pracine]

Then +1

[robe]

Jorge,

For your r5605 -- may I be so bold as to suggest you use ST_Union instead of ST_Collect. ST_Collect may be faster but I think you will end up with many invalid polygons. Though in this example ST_Union is faster (I guess because of the new cascaded union feature)

For example

-- Takes 4.2 seconds

SELECT rid,ST_IsValid(ST_Collect(geom)) As geom
FROM (SELECT rid, (ST_DumpAsPolygons(rast,1)).*
FROM ch13.usdem WHERE rid = 1) As foo
WHERE val <> 0
GROUP BY rid

Gives false

-- Takes 3.8 seconds

SELECT rid,ST_IsValid(ST_Union(geom)) As geom
FROM (SELECT rid, (ST_DumpAsPolygons(rast,1)).*
FROM ch13.usdem WHERE rid = 1) As foo
WHERE val <> 0
GROUP BY rid

Gives true

to union the whole set above takes about 5 minutes. It looks about right though and didn't give any errors.

[jorgearevalo]

I forgot to anwer this. I changed it. Now, we're using st_union instead of st_collect. Thanks Regina!

[jorgearevalo]

I think this ticket may be closed. Working on Linux and Windows. I hope working on Mac...

[jorgearevalo]

The function is implemented. So, I close this ticket for the time being.