[postgis-devel] wktraster ST_ConvexHull

[Paragon Corporation]

Jorge,

Thanks.  I'm feeling déjà vu now.  I'm sure Pierre explained this to me
before and pointed me at the spec and  I forgot, I guess cause it feels kind
of unintuitive to me.  I apologize for my denseness.

So the ST_ConvexHull is really only useful if you have an irregularly shaped
raster or a rotated raster which I guess I don't commonly run into.

The ST_AsPolygon I guess I also got wrong.  I keep on thinking about it as
what is referred to as ST_Shape except my concept of ST_Shape would take all
bands (leaving out nodata)  into consideration instead of a specific.

Would seem better to call ST_AsPolygon - ST_DumpPolygons or something like
that as it seems to be more in line with the PostGIS concept of  ST_Dump,
ST_DumpRings, ST_DumpPoints... that return geometry_dump.

The distinction I see  it would always return a dump of polygons rather than
an arbitrary dump of geometries
And the path value would be replaced with a pixel value.

Getting to names -- ST_AsWKTPolygon should not start with an ST_ if it is
not intended for end user use.

Thanks,
Regina

-----Original Message-----
From: postgis-devel-bounces at postgis.refractions.net
[mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Jorge
Arevalo
Sent: Tuesday, April 06, 2010 6:11 AM
To: PostGIS Development Discussion
Subject: Re: [postgis-devel] wktraster ST_ConvexHull

Hello Regina,

On Tue, Apr 6, 2010 at 3:14 AM, Paragon Corporation <lr at pcorp.us> wrote:
> I'm a little bit confused about what ST_ConvexHull is supposed to 
> return. I thought it would return the convex hull of the polygon 
> formed by the pixels that aren't the BandNoDataValue value.
>
> It seems to always return the same result as ST_Envelope regardless of 
> what I set the ST_BandNoDataValue too.

The resulting polygon from implemented ST_ConvexHull function encloses every
pixel, even those containing NODATA values. You can read the specs here
http://trac.osgeo.org/postgis/wiki/WKTRaster/SpecificationWorking01#Objectiv
e0.1.6e-Beingabletointersectvectorandrastertoproducevector.

Anyway, that point is not included in final specs yet. So, comments are
welcome. Pierre can provide more qualified opinion.

Best regards,
Jorge
_______________________________________________
postgis-devel mailing list
postgis-devel at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-devel