ADQL new function to compute area of intersection?

[alberto micol]

Yes Arnold, I fully agree.

SELECT AREA(INTERSECTION(region1, region2)) 

is indeed what we want. Much more flexible.
Let me then rephrase my request:

Can we add in ADQL an INTERSECTION function
which returns the polygon intersection of two regions?

Alberto
PS: We did try the INTERSECTION way, but a problem with the underlying library stopped us.
Our user-defined function returned a value whose type was interpreted as UNKNOWN
instead of REGION by that library, and that is why we went for a function
that computed the area of the intersection of the two input regions instead.
Much more inflexible indeed, though that solved our immediate problem.
Sorry to have been sidetracked by what is only a library issue!
Thanks Arnold!


> On 07 Jun 2017, at 19:29, Arnold Rots <arots at cfa.harvard.edu> wrote:
> 
> I was going to ask: doesn't it make more sense to define two functions:
> 1. return the intersection of two regions
> 2. return the area of a region
> The combination of the two provides Alberto's area of the intersection
> and separately they provide more functionality.
> One might of course want to add:
> 3. return the union of two regions
> 
> Cheers,
> 
>   - Arnold
> 
> -------------------------------------------------------------------------------------------------------------
> Arnold H. Rots                                          Chandra X-ray Science Center
> Smithsonian Astrophysical Observatory                   tel:  +1 617 496 7701
> 60 Garden Street, MS 67                                      fax:  +1 617 495 7356
> Cambridge, MA 02138                                         arots at cfa.harvard.edu <mailto:arots at cfa.harvard.edu>
> USA                                                   http://hea-www.harvard.edu/~arots/ <http://hea-www.harvard.edu/~arots/>
> --------------------------------------------------------------------------------------------------------------
> 
> 
> On Wed, Jun 7, 2017 at 1:15 PM, Walter Landry <wlandry at caltech.edu <mailto:wlandry at caltech.edu>> wrote:
> alberto micol <amicol.ivoa at googlemail.com <mailto:amicol.ivoa at googlemail.com>> wrote:
> > Dear All,
> > cc: Bruno, for the Standing Committee on Science Priorities <http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaSciencePriorities <http://wiki.ivoa.net/twiki/bin/view/IVOA/IvoaSciencePriorities>>
> >
> > The following science use case cannot be accomplished without a new ADQL function:
> >
> > I want to find images of the Galactic Centre in two bands (J and H) provided that the images
> > in the 2 bands overlap, in order to get the colours (J-H) of the sources imaged by both.
> > The overlapping region must be big enough so that I can detect sources
> > in both images: an overlap of, say, 0.001 square degrees would be irrelevant for my science case.
> >
> > I’ll show in the PS how this can be achieved using ObsCore with a user-defined function.
> >
> > The issue is that, to avoid images just “touching” each other, we had to create a user-defined function
> > that computes the area of the intersection of the two regions.
> >
> > Issues: (1) only those users that read the documentation or the TAPRegExt will know
> > that such functionality exists, and (2) this function cannot be used when querying other data centres.
> >
> > Can I suggest to introduced a new function in ADQL 2.1 which can be used to compute
> > the area of the intersections between two regions?
> 
> It sounds like what you actually want is the distance to the edge, not
> the overlap area.  I needed something like that.  We wanted the "most
> centered" image, so we sort results by the distance to the edge.  It
> required a bit of hacking on our end.
> 
> With that said, I am not a fan of new functions that can not be
> implemented via simple rewriting on GIS backends.
> 
> Cheers,
> Walter Landry
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170608/56e4d0ff/attachment-0001.html>