[postgis-devel] [raster] hasnodata, exclude_nodata, include_nodata , whatever nodata :)

[Bborie Park]

Thanks for pulling the trigger!  I've updated the functions I've
written (and underlying C code) to use the new parameter name
"exclude_nodata_value" and will update the corresponding entries in
the working specs shortly.

I'm glad to hear that the functions are working pretty quickly.  I do
expect them to slow down with larger rasters (10000 x 10000) and
coverages.  I need to do some testing on a physical machine instead of
my dev virtual machines to see what can be improved.

Thanks for letting me contribute code where I can.

-bborie

On Mon, May 30, 2011 at 12:51 AM, Paragon Corporation <lr at pcorp.us> wrote:
> Great.  I've replaced in the user manual docs where hasnodata argument is
> used to exclude_nodata_value. I'm still correcting descriptions of logic I
> had that was erroneous.
>
> So I guess it just needs to be changed in the specs and the functions
> themselves.
>
> I also created a new section in Raster called "Raster Band Statistics and
> Analytics"  to hold Bborie's new functions since they din't really feel like
> they belonged in processing to me are not in gettors and settors since they
> are computations.  Still have a ways to go to finish documenting all his
> great work.
>
> Bborie,
>
> These functions you have created so far are pretty darn cool and fast too as
> far as I can tell.   Thanks a lot for joining our team.
>
> Thanks,
> Regina
>
> -----Original Message-----
> From: postgis-devel-bounces at postgis.refractions.net
> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of Jorge
> Arévalo
> Sent: Sunday, May 29, 2011 5:42 AM
> To: PostGIS Development Discussion
> Subject: Re: [postgis-devel] [raster] hasnodata, exclude_nodata,
> include_nodata , whatever nodata :)
>
> On Sat, May 28, 2011 at 12:57 AM, dustymugs <dustymugs at gmail.com> wrote:
>> On 05/27/2011 03:33 PM, Paragon Corporation wrote:
>>>
>>> I took this off the ticket since it's a side topic affecting many
>>> functions.
>>>
>>> I feel we can use different names as long as we don't use the same
>>> name to mean two different things.
>>>
>>>
>>> But if we must go with one name, the value must mean the same thing
>>> as hasnodata so that people used to using that argument don't get
>>> surprised when it does something different.
>>>
>>> How about:
>>>
>>> exclude_nodata_value = true   is the same as hasnodata=true
>>>
>>> I don't really think we need to throw band in there since the nodata
>>> is tied to a band.
>>>
>>
>> +1 for me!  A little long but easy to understand.  Also, the underlying
>> logic can stay the same.
>>
>
> +1 for me too. I think it's clearer.
>
>
>>> Thanks,
>>> Regina
>>>
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: postgis-devel-bounces at postgis.refractions.net
>>> [mailto:postgis-devel-bounces at postgis.refractions.net] On Behalf Of
>>> PostGIS
>>> Sent: Friday, May 27, 2011 5:24 PM
>>> Cc: postgis-devel at postgis.refractions.net
>>> Subject: Re: [postgis-devel] [PostGIS] #985: [raster] ST_Count
>>>
>>> #985: [raster] ST_Count
>>> -----------------------------+------------------------------------------
>>> -----------------------------+----
>>>   Reporter:  dustymugs       |       Owner:  dustymugs
>>>       Type:  task            |      Status:  reopened
>>>   Priority:  medium          |   Milestone:  PostGIS 2.0.0
>>>  Component:  postgis raster  |     Version:  trunk
>>> Resolution:                  |    Keywords:  history
>>> -----------------------------+------------------------------------------
>>> -----------------------------+----
>>>
>>> Comment(by pracine):
>>>
>>>  I think we should keep it then...
>>>
>>>  I think this name should be consistent and involve the same behavior for
>>> all functions (ST_Value and ST_Intersects included).
>>>
>>>  What about "disablebandnodata"? Which means the opposite of hasnodata...
>>>  and should be FALSE by default.
>>>
>>>  I think Regina should come with a consistent name that we can apply
>>> everywhere. I was happy with hasnodata. Snif ;-( I already miss it...
>>>
>>> --
>>> Ticket URL:<http://trac.osgeo.org/postgis/ticket/985#comment:15>
>>> PostGIS<http://trac.osgeo.org/postgis/>  The PostGIS Trac is used for
> bug,
>>> enhancement&  task tracking, a user and developer wiki, and a view into
>>> the
>>> subversion code repository of PostGIS project.
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>>
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>>
>
>
>
> --
> Jorge Arévalo
> Internet & Mobilty Division, DEIMOS
> jorge.arevalo at deimos-space.com
> http://es.linkedin.com/in/jorgearevalo80
> http://mobility.grupodeimos.com/
> http://gis4free.wordpress.com
> http://geohash.org/ezjqgrgzz0g
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-devel
>