[postgis-devel] Postgis documentation clarification request.

[Bborie Park]

Thanks for the heads up. I'll see what we can do...

-bborie

On Fri, Feb 23, 2018 at 10:42 AM, Birkett, Scott <scott.birkett at pioneer.com>
wrote:

> Dear postgis developers,
>
>
>
> "PostgreSQL 9.5.6 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.8.3
> 20140911 (Red Hat 4.8.3-9), 64-bit POSTGIS="2.2.5 r15298"
> GEOS="3.5.1-CAPI-1.9.1 r4246" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL
> 2.0.3, released 2016/07/01" LIBXML="2.9.1" LIBJSON="0. (...)"
>
>
>
> Please consider adding documentation to explain why the following SQL
> statement returns true.
>
>
>
> *SELECT ( ST_AsTiff(raster, ARRAY[1,2]) = ST_AsTiff(raster, ARRAY[3]) )*
>
> *FROM*
>
> *(*
>
> *SELECT
> '0100000200000000000000F03F000000000000F0BF00000000000000000000000000000000000000000000000000000000000000000000000002000200080000000000000000000000000000000000000000080000000001000000010000000100000001000000'::raster*
>
> *)*
>
> *as rast;*
>
>
>
> The raster created by …
>
> SELECT '0100000200000000000000F03F000000000000F0BF000000000000000000
> 000000000000000000000000000000000000000000000000000000020002
> 000800000000000000000000000000000000000000000800000000010000
> 00010000000100000001000000'::raster
>
> is a two band raster with zeros in the first band and ones in the second
> band.
>
>
>
> *( ST_AsTiff(raster, ARRAY[1,2]) = ST_AsTiff(raster, ARRAY[3]) )* appears
> to evaluate to true because any raster band selection on a band that
> doesn’t exists (*ARRAY[3] in this example)* returns ALL the raster bands.
>
>
>
> The functionality is especially confusing as some raster functions
> (ST_SummaryStats, ST_DumpValues, etc.) take the band argument more
> literally and return nothing when requesting bands that don’t exist.
>
>
>
> I am not asking for ST_Band or ST_AsTiff to change functionality, but if
> the documentation https://postgis.net/docs/RT_ST_AsTIFF.html made it
> apparent that parameter *integer[] nbands* fetches you ALL the bands when
> band request are made that don’t exists might help people of the future.
>
>
>
>
> This communication is for use by the intended recipient and contains
> information that may be Privileged, confidential or copyrighted under
> applicable law. If you are not the intended recipient, you are hereby
> formally notified that any use, copying or distribution of this e-mail,in
> whole or in part, is strictly prohibited. Please notify the sender by
> return e-mail and delete this e-mail from your system. Unless explicitly
> and conspicuously designated as "E-Contract Intended", this e-mail does not
> constitute a contract offer, a contract amendment, or an acceptance of a
> contract offer. This e-mail does not constitute a consent to the use of
> sender's contact information for direct marketing purposes or for transfers
> of data to third parties. Francais Deutsch Italiano Espanol Portugues
> Japanese Chinese Korean http://www.DuPont.com/corp/email_disclaimer.html
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180223/600f3562/attachment.html>