From msdemlei at ari.uni-heidelberg.de  Mon Jan  9 05:50:47 2012
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Mon, 9 Jan 2012 14:50:47 +0100
Subject: Server specific examples
Message-ID: <20120109135047.GA22666@ari.uni-heidelberg.de>

Dear all,

If you attended the TAPRegExt session in Pune you may remember we
discussed how TAP servers could expose (commented) example queries to
users and clients in some "standard" way; my experience in watching
people use TOPCAT's TAP interface is that everyone starts with
examples and works on from there.  TAP clients should have a fair
chance of being able to display something tailored to a server's
contents.

In Pune we decided against having such a thing in TAPRegExt (and
hence including example queries in the capabilities endpoint).
Instead, we agreed I'd try a tap_schema.examples table.

I've done this now, and you can find it behind the access URL
http://dc.g-vo.org/tap (that's the service
ivo://org.gavo.dc/__system__/tap/run) or in HTML at

http://dc.zah.uni-heidelberg.de/__system__/adql/query/form?__nevow_form__=genForm&query=select%20*%20from%20tap_schema.examples&_TIMEOUT=5&_FORMAT=HTML&submit=Go

Now that I've done it, I have to say I don't partiularly like this
particular solution.

Firstly, I agree with (private) feedback from Mark Taylor:

> I think machine readable is good for me, and the way you've done it
> looks OK.  Having it in a TAP table is a bit heavy duty though.
> One issue is that a TAP query may be slow (e.g. queued behind all
> the other pending queries). [Issue 1]

(though I guess that's somewhat mitigated by queries against that
table always running through sync).

Then, I'd really like to have something that easily works as a simple
web resource that users can just point their browsers to -- I admit
you can get a similar effect doing a sync query with a stylesheet,
but again that feels rather heavyweight, and injecting the proper
stylesheet at the right time could be tricky.  [Issue 2]

One thing I had in mind in Pune was associating queries with tables;
in my examples, the katkat bibliography query, to name one, should be
prominently shown when people peruse the metadata of the
katkat.katkat table, whereas it's not so eminently useful for most
other tables.  One could do this in a new column within the
tap_schema.examples table, but since a single query could be
"pertaining" to multiple tables, it would be messy in one way or
another. [Issue 3]

Finally, when writing the descriptions, I found myself yearning for
markup (paragraphs, "literal" values, maybe even links).  I'm not
sure allowing something like that is a good idea, I'm just saying my
fingers ached for it. [Issue 4]


As to suggestions where to go, let me first quote Mark again:

> Since it's static data of moderate size an "/examples" endpoint would
> work better, but then somebody has to define an output format
> (could be VOTable just as you have it).

An /examples endpoint delivering a static VOTable, possibly more or
less what would come out of a TAP endpoint with the current table
structure would certainly solve issues 1 and 2 (for issue 2, it's
more straightforward to bind a pretty stylesheet tailored for the
examples to such a VOTable than it would be when pulling the document
out of a real TAP service).  Issue 3 could still be addressed if
desired, by introducing an additional column.

For issue 4, that wouldn't help (let's not even think about storing
some kind of markup, let alone HTML, within a VOTable).  If we wanted
this (and tackle issue 2 offensively), we could simply use xhtml plus
a microformat.  Standalone applications probably would not want to
display the whole example records (since they'd need to render HTML
for that), but it would be easy to get the sample queries and
relevant metadata (a name, the link for the explanation, and possibly
the tables the queries are "meant for") using either a proper XML
parser or just screen scraping.  What I have in mind could look like
this:

<div class="ivo_tap_example" id="katkatbib">
<h1 class="ivo_tap_examplename">Katkat Bibliography</h1>

<p>To search for title (or other) words in the source field of <abbr
class="ivo_tap_pertainingtable">katkat.katkat</abbr> use the
<tt>gavo_hasword</tt> locally defined function. This basically works
a bit like you'd expect from search engines: case-insensitive, and
oblivious to any context.</p>

<pre class="ivo_tap_examplequery">
SELECT * 
FROM katkat.katkat 
WHERE gavo_hasword('variable', source) 
  AND minEpoch<1900
</pre>
</div>

An application could render this as button "insert query 'Katkat
Bibliography'" with another button "More info" behind it; that
button could, e.g., just open a web browser for
http://foo.bar/tap/examples#katkatbib.


So -- what do you think?  Which of the issues posed above do you
regard as relevant?  Do you prefer a static endpoint or a tap_schema
table?  VOTable, microformatted HTML, or still something else if
static endpoint?  Or would you rather forget about the whole thing?
[For the last position, you'll probably have to try hard to convince
me...]


Cheers,

           Markus


From grgbeal at gmail.com  Mon Jan  9 12:28:38 2012
From: grgbeal at gmail.com (Gretchen Greene)
Date: Mon, 9 Jan 2012 14:28:38 -0600
Subject: AAS IVOA footprint tag up 
Message-ID: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>

Hi folks,

We will be having a tag up on Tuesday, 1:00 in the exhibit hall snack table area, to talk about footprint specification standards to take advantage of a few folks present.

I will post our discussion notes to the DAL group to keep the communication flowing.  I am hopeful we can work toward assembling elements of a working draft spec for the spring interop.

cheers, Gretchen

Sent from my iPad

From grgbeal at gmail.com  Wed Jan 11 07:56:35 2012
From: grgbeal at gmail.com (Gretchen Greene)
Date: Wed, 11 Jan 2012 09:56:35 -0600
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>
References: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>
Message-ID: <6BFC4A86-1FAF-403C-AD6C-272B1148C7CF@gmail.com>


Meeting Minutes from AAS Footprint Tag-up

Attendees: Francois Ochsenbein, Gretchen Greene, Jonathan Fay, Arnold
Rots, Doug Tody, Thomas Boch

Summary: The discussion focused on establishing agreement on the format
of the metadata used to describe simple outline footprints, i.e.
spatial regions, for basic DAL services, SSA, TAP, SIA etc. (ultimately
we want a uniform representation for all such services).  The issue of
defining a general footprint service will be considered separately.

The issue of region specification follows a discussion thread on Utypes
for regions.  The minutes will be circulated to the DAL working group to
see if we have considered valid points.  A follow on action will be to
draft a technical note on the agreed upon implementation.  Having a
standard description for the spatial region support will provide uniform
format specifications across services and simplify client software
handling of regions.

The current SSA, ObsCore (Observation), and draft SIAV2 specs already
provide a mechanism for this based upon Characterisation.  The main
change required is to generalize the STS-S region specification used to
support more complex multi-area regions, particularly where there is
substantial blank area within the overall region covered.

As currently defined in the ObsTAP/ObsCore specification and in SSA and
the draft SIA v2, spatial regions will adopt as a default coordinate
system ICRS.  The region will be defined as an STC-s string
representation of the standard Space Time Coordinate data model.  The
Utype will follow the Characterization data model as already
used in SSA, ObsCore, etc., i.e.,

   Char.SpatialAxis.Coverage.Support.Area

The ObsCore column name "s_region" is suggested to identify this column
but is not mandatory.

The "semantic type" of the region is defined as AstroCoordArea.  This is
distinct from the Utype, which may have been source of confusion in the
earlier Utype discussions.

Compound Regions:

The main change would be to allow even this "simple" service region
metadata field to be used to describe compound regions that have
multiple areas described.  This is required by observations from some
modern detectors [eg?] which can simultaneously observe multiple spatial
regions.

An example (will provide more accurate example in technical note) of
this:

   UNION (Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4,
          Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4)

Compound types include union, intersection, negation.

Some current service implementions (e.g. HST?) already implement an
earlier version of this and would need to be updated along with
dependent client applications.  We would like to agree on timing for
some of the reference implementation for clients to utilize the new
representation.

In the case of multiple coordinate systems, this is special client case
that will be addressed with more complete footprint service spec.  The
general Footprint service specification will be a more complete utility
which addresses footprint capability metadata registry descriptions,
methods for accessing and manipulating regions, spatial tessellation ,
etc., not covered with basic access protocol extension...


On Jan 9, 2012, at 2:28 PM, Gretchen Greene <grgbeal at gmail.com> wrote:

> Hi folks,
> 
> We will be having a tag up on Tuesday, 1:00 in the exhibit hall snack table area, to talk about footprint specification standards to take advantage of a few folks present.
> 
> I will post our discussion notes to the DAL group to keep the communication flowing.  I am hopeful we can work toward assembling elements of a working draft spec for the spring interop.
> 
> cheers, Gretchen
> 
> Sent from my iPad

From msdemlei at ari.uni-heidelberg.de  Tue Jan 17 00:48:20 2012
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Tue, 17 Jan 2012 09:48:20 +0100
Subject: Server specific examples
In-Reply-To: <4F145D72.3040407@asdc.asi.it>
References: <20120109135047.GA22666@ari.uni-heidelberg.de>
	<4F145D72.3040407@asdc.asi.it>
Message-ID: <20120117084820.GA4994@ari.uni-heidelberg.de>

Hi Bruce, dear all,

On Mon, Jan 16, 2012 at 06:25:06PM +0100, bruce gendre wrote:
> that's my first message on this ML, just to give my 2 cents. At ASDC
Welcome...

> catalogs and high energy mission archives. My first point is quite
> obvious, here we would prefer a static end point where we can do
> "what we want" rather than a more rigid structure linked the
> TAP_SCHEMA.
Ok -- I'd say unless someone speaks up for TAP_SCHEMA now, that
particular proposal is dead.

I'm a bit alarmed at the "what we want" part, though.  So far, the
plan with /examples has been to specifically provide sample
*queries*.  I don't think we should blur that, mainly because I think
the more machine-readable we can keep the whole thing the better --
which roughly means "have a narrow focus".

> The second comment is that our TAP service will serve VOTable
> (catalogs) and FITS (HE data), so I think the example end point
> should merge a mandatory VOTable (machine and post-doc readable) and
> a mandatory HTML description (user readable). TAP providers should
> insert (if they want) other formats, but these should not be
> mandatory.
Hm -- what kind of use case do you have in mind for including a FITS
in /examples?

> compared to a catalog, so I think an /example endpoint is really a
> good think, if it can be customized by the TAP service provider.
Would the "microformat-based" HTML I suggested in the orignal mail
provide enough flexibility for you?

Cheers,

         Markus


From amicol.ivoa at googlemail.com  Wed Jan 18 07:24:55 2012
From: amicol.ivoa at googlemail.com (Alberto Micol)
Date: Wed, 18 Jan 2012 16:24:55 +0100
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <6BFC4A86-1FAF-403C-AD6C-272B1148C7CF@gmail.com>
References: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>
	<6BFC4A86-1FAF-403C-AD6C-272B1148C7CF@gmail.com>
Message-ID: <90087DDE-7250-43D5-9753-4068C6CEF55E@googlemail.com>


This is a fantastic step ahead! Thank you so much.

Now, taken by enthusiasm as I am, I want to immediately implement it.

Would you know whether a library that can parse, digest, and maybe plot
a generic STC-s region exist?

I need something that can deal with, eg:

Union ICRS TOPOCENTER
(Circle 180 10 20
Circle 190 20 20
Intersection
   (Circle 120 -10 20
     Difference  (Circle 130 -10 20  Circle 125 -10 2)
    Not  (Circle 118 -8 3)
   )
)

<thinkingloud>Mmmhh... do I really need such  a complex beast?</ 
thinkingloud>

I think that:
- 70-90% of the DAL cases will have to deal with a single polygon;
- 10-30% of the cases will be for a simple UNION of polygons (eg for  
multi chip cameras)
- 1% of the remaining cases will be for quite complex regions, like  
the one described above.

Please correct me if you think my stats do not represent real *DAL*  
usage.
Looking at the DAL standards already available or in the making, DAL  
does not seem
concerned by more complex shapes like for example the sky coverage of  
a survey
(see for example the final SDSS sky coverage: http://www.sdss.org/includes/sideimages/orangespider.html 
  ).

Therefore I find asking asking myself:

<morethinkingloud>

- how many providers will implement a complex library to handle all  
possible the cases?

- does such library already exist (and for which language)?

- otherwise, is it foolish to suggest to limit the usage of an STC-s  
region in DAL to few representative cases
that cover 95% (or more) of the DAL cases (e.g. single polygon, union  
of 2 or more polygons, plus maybe the NOT operator to describe holes) ?

- otherwise, is there the need (for lazy providers) to have two  
different votable fields:
   (1) s_region: the full and potentially complex region,
   (2) s_polygon (invented here): the higher level polygon that  
inscribes the s_region
  ?   (s_polygon would be a LOCATION, while s_region a SUPPORT, in  
chardm  speak);

- is it maybe just me being too lazy?

</morethinkingloud>

Just thinking loud, to stimulate discussion (but I think lowering  
implementation costs is always good).

Eager to know what you think,

Thanks a lot, it is really a great news,
Alberto


On 11 Jan 2012, at 16:56, Gretchen Greene wrote:

>
> Meeting Minutes from AAS Footprint Tag-up
>
> Attendees: Francois Ochsenbein, Gretchen Greene, Jonathan Fay, Arnold
> Rots, Doug Tody, Thomas Boch
>
> Summary: The discussion focused on establishing agreement on the  
> format
> of the metadata used to describe simple outline footprints, i.e.
> spatial regions, for basic DAL services, SSA, TAP, SIA etc.  
> (ultimately
> we want a uniform representation for all such services).  The issue of
> defining a general footprint service will be considered separately.
>
> The issue of region specification follows a discussion thread on  
> Utypes
> for regions.  The minutes will be circulated to the DAL working  
> group to
> see if we have considered valid points.  A follow on action will be to
> draft a technical note on the agreed upon implementation.  Having a
> standard description for the spatial region support will provide  
> uniform
> format specifications across services and simplify client software
> handling of regions.
>
> The current SSA, ObsCore (Observation), and draft SIAV2 specs already
> provide a mechanism for this based upon Characterisation.  The main
> change required is to generalize the STS-S region specification used  
> to
> support more complex multi-area regions, particularly where there is
> substantial blank area within the overall region covered.
>
> As currently defined in the ObsTAP/ObsCore specification and in SSA  
> and
> the draft SIA v2, spatial regions will adopt as a default coordinate
> system ICRS.  The region will be defined as an STC-s string
> representation of the standard Space Time Coordinate data model.  The
> Utype will follow the Characterization data model as already
> used in SSA, ObsCore, etc., i.e.,
>
>   Char.SpatialAxis.Coverage.Support.Area
>
> The ObsCore column name "s_region" is suggested to identify this  
> column
> but is not mandatory.
>
> The "semantic type" of the region is defined as AstroCoordArea.   
> This is
> distinct from the Utype, which may have been source of confusion in  
> the
> earlier Utype discussions.
>
> Compound Regions:
>
> The main change would be to allow even this "simple" service region
> metadata field to be used to describe compound regions that have
> multiple areas described.  This is required by observations from some
> modern detectors [eg?] which can simultaneously observe multiple  
> spatial
> regions.
>
> An example (will provide more accurate example in technical note) of
> this:
>
>   UNION (Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4,
>          Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4)
>
> Compound types include union, intersection, negation.
>
> Some current service implementions (e.g. HST?) already implement an
> earlier version of this and would need to be updated along with
> dependent client applications.  We would like to agree on timing for
> some of the reference implementation for clients to utilize the new
> representation.
>
> In the case of multiple coordinate systems, this is special client  
> case
> that will be addressed with more complete footprint service spec.  The
> general Footprint service specification will be a more complete  
> utility
> which addresses footprint capability metadata registry descriptions,
> methods for accessing and manipulating regions, spatial tessellation ,
> etc., not covered with basic access protocol extension...
>
>
> On Jan 9, 2012, at 2:28 PM, Gretchen Greene <grgbeal at gmail.com> wrote:
>
>> Hi folks,
>>
>> We will be having a tag up on Tuesday, 1:00 in the exhibit hall  
>> snack table area, to talk about footprint specification standards  
>> to take advantage of a few folks present.
>>
>> I will post our discussion notes to the DAL group to keep the  
>> communication flowing.  I am hopeful we can work toward assembling  
>> elements of a working draft spec for the spring interop.
>>
>> cheers, Gretchen
>>
>> Sent from my iPad

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20120118/95d2bbbf/attachment.html>

From thomas.boch at astro.unistra.fr  Thu Jan 19 07:23:17 2012
From: thomas.boch at astro.unistra.fr (Thomas Boch)
Date: Thu, 19 Jan 2012 16:23:17 +0100
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <90087DDE-7250-43D5-9753-4068C6CEF55E@googlemail.com>
References: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>
	<6BFC4A86-1FAF-403C-AD6C-272B1148C7CF@gmail.com>
	<90087DDE-7250-43D5-9753-4068C6CEF55E@googlemail.com>
Message-ID: <4F183565.8080009@astro.unistra.fr>

Hi Alberto,
> Would you know whether a library that can parse, digest, and maybe plot
> a generic STC-s region exist?
I asked a similar question 2 months ago. What I remember from the 
discussion is that :

- CADC has developed an STC-S parser in Java 
(http://code.google.com/p/opencadc/source/browse/trunk/projects/#projects%2FcadcTAP%2Fsrc%2Fca%2Fnrc%2Fcadc%2Fstc) 


- the AST C library, developed by David Berry, has a STC-S parser  
(http://starlink.jach.hawaii.edu/starlink/AST) and provides bindings to 
Python, Perl, Java, ...

Cheers,

Thomas

>
> I need something that can deal with, eg:
>
> Union ICRS TOPOCENTER
> (Circle 180 10 20
> Circle 190 20 20
> Intersection
>   (Circle 120 -10 20
>     Difference  (Circle 130 -10 20  Circle 125 -10 2)
>    Not  (Circle 118 -8 3)
>   )
> )
>
> <thinkingloud>Mmmhh... do I really need such  a complex 
> beast?</thinkingloud>
>
> I think that:
> - 70-90% of the DAL cases will have to deal with a single polygon;
> - 10-30% of the cases will be for a simple UNION of polygons (eg for 
> multi chip cameras)
> - 1% of the remaining cases will be for quite complex regions, like 
> the one described above.
>
> Please correct me if you think my stats do not represent real *DAL* usage.
> Looking at the DAL standards already available or in the making, DAL 
> does not seem
> concerned by more complex shapes like for example the sky coverage of 
> a survey
> (see for example the final SDSS sky coverage: 
> http://www.sdss.org/includes/sideimages/orangespider.html ).
>
> Therefore I find asking asking myself:
>
> <morethinkingloud>
>
> - how many providers will implement a complex library to handle all 
> possible the cases?
>
> - does such library already exist (and for which language)?
>
> - otherwise, is it foolish to suggest to limit the usage of an STC-s 
> region in DAL to few representative cases
> that cover 95% (or more) of the DAL cases (e.g. single polygon, union 
> of 2 or more polygons, plus maybe the NOT operator to describe holes) ?
>
> - otherwise, is there the need (for lazy providers) to have two 
> different votable fields:
>   (1) s_region: the full and potentially complex region,
>   (2) s_polygon (invented here): the higher level polygon that 
> inscribes the s_region
>  ?   (s_polygon would be a LOCATION, while s_region a SUPPORT, in 
> chardm  speak);
>
> - is it maybe just me being too lazy?
>
> </morethinkingloud>
>
> Just thinking loud, to stimulate discussion (but I think lowering 
> implementation costs is always good).
>
> Eager to know what you think,
>
> Thanks a lot, it is really a great news,
> Alberto
>
>
> On 11 Jan 2012, at 16:56, Gretchen Greene wrote:
>
>>
>> Meeting Minutes from AAS Footprint Tag-up
>>
>> Attendees: Francois Ochsenbein, Gretchen Greene, Jonathan Fay, Arnold
>> Rots, Doug Tody, Thomas Boch
>>
>> Summary: The discussion focused on establishing agreement on the format
>> of the metadata used to describe simple outline footprints, i.e.
>> spatial regions, for basic DAL services, SSA, TAP, SIA etc. (ultimately
>> we want a uniform representation for all such services).  The issue of
>> defining a general footprint service will be considered separately.
>>
>> The issue of region specification follows a discussion thread on Utypes
>> for regions.  The minutes will be circulated to the DAL working group to
>> see if we have considered valid points.  A follow on action will be to
>> draft a technical note on the agreed upon implementation.  Having a
>> standard description for the spatial region support will provide uniform
>> format specifications across services and simplify client software
>> handling of regions.
>>
>> The current SSA, ObsCore (Observation), and draft SIAV2 specs already
>> provide a mechanism for this based upon Characterisation.  The main
>> change required is to generalize the STS-S region specification used to
>> support more complex multi-area regions, particularly where there is
>> substantial blank area within the overall region covered.
>>
>> As currently defined in the ObsTAP/ObsCore specification and in SSA and
>> the draft SIA v2, spatial regions will adopt as a default coordinate
>> system ICRS.  The region will be defined as an STC-s string
>> representation of the standard Space Time Coordinate data model.  The
>> Utype will follow the Characterization data model as already
>> used in SSA, ObsCore, etc., i.e.,
>>
>>   Char.SpatialAxis.Coverage.Support.Area
>>
>> The ObsCore column name "s_region" is suggested to identify this column
>> but is not mandatory.
>>
>> The "semantic type" of the region is defined as AstroCoordArea.  This is
>> distinct from the Utype, which may have been source of confusion in the
>> earlier Utype discussions.
>>
>> Compound Regions:
>>
>> The main change would be to allow even this "simple" service region
>> metadata field to be used to describe compound regions that have
>> multiple areas described.  This is required by observations from some
>> modern detectors [eg?] which can simultaneously observe multiple spatial
>> regions.
>>
>> An example (will provide more accurate example in technical note) of
>> this:
>>
>>   UNION (Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4,
>>          Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4)
>>
>> Compound types include union, intersection, negation.
>>
>> Some current service implementions (e.g. HST?) already implement an
>> earlier version of this and would need to be updated along with
>> dependent client applications.  We would like to agree on timing for
>> some of the reference implementation for clients to utilize the new
>> representation.
>>
>> In the case of multiple coordinate systems, this is special client case
>> that will be addressed with more complete footprint service spec.  The
>> general Footprint service specification will be a more complete utility
>> which addresses footprint capability metadata registry descriptions,
>> methods for accessing and manipulating regions, spatial tessellation ,
>> etc., not covered with basic access protocol extension...
>>
>>
>> On Jan 9, 2012, at 2:28 PM, Gretchen Greene <grgbeal at gmail.com 
>> <mailto:grgbeal at gmail.com>> wrote:
>>
>>> Hi folks,
>>>
>>> We will be having a tag up on Tuesday, 1:00 in the exhibit hall 
>>> snack table area, to talk about footprint specification standards to 
>>> take advantage of a few folks present.
>>>
>>> I will post our discussion notes to the DAL group to keep the 
>>> communication flowing.  I am hopeful we can work toward assembling 
>>> elements of a working draft spec for the spring interop.
>>>
>>> cheers, Gretchen
>>>
>>> Sent from my iPad
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dal/attachments/20120119/0931f1a0/attachment-0001.html>

From arots at head.cfa.harvard.edu  Thu Jan 19 07:52:08 2012
From: arots at head.cfa.harvard.edu (Arnold Rots)
Date: Thu, 19 Jan 2012 10:52:08 -0500 (EST)
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <4F183565.8080009@astro.unistra.fr>
Message-ID: <201201191552.q0JFq8Iw019990@xebec.cfa.harvard.edu>

CXC and HLA have footprint services with common ancestry.
Ours is written in Java and paints on Canvas.

I think the 10/90 - 30/70 split is optimistic.
50/50 is closer to reality and the multi-chip fraction will increase.
It also depends whether you count services or actual number of
footprints processed.
Catalog footprints will also be more complex.

For us the typical case will be:

Union ICRS TOPOCENTER
  (Polygon ...
   Polygon ...
   ...
  )

Although there will be occasional footprints like:

Intersection ICRS TOPOCENTER
  (Union
    (Polygon ...
     Polygon ...
     ...
    )
   Not 
    (Union
      (Polygon ...
        Polygon ...
        ...
      )
    )
  )


  - Arnold

Thomas Boch wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> Hi Alberto,
> > Would you know whether a library that can parse, digest, and maybe plot
> > a generic STC-s region exist?
> I asked a similar question 2 months ago. What I remember from the 
> discussion is that :
> 
> - CADC has developed an STC-S parser in Java 
> (http://code.google.com/p/opencadc/source/browse/trunk/projects/#projects%2FcadcTAP%2Fsrc%2Fca%2Fnrc%2Fcadc%2Fstc) 
> 
> 
> - the AST C library, developed by David Berry, has a STC-S parser  
> (http://starlink.jach.hawaii.edu/starlink/AST) and provides bindings to 
> Python, Perl, Java, ...
> 
> Cheers,
> 
> Thomas
> 
> >
> > I need something that can deal with, eg:
> >
> > Union ICRS TOPOCENTER
> > (Circle 180 10 20
> > Circle 190 20 20
> > Intersection
> >   (Circle 120 -10 20
> >     Difference  (Circle 130 -10 20  Circle 125 -10 2)
> >    Not  (Circle 118 -8 3)
> >   )
> > )
> >
> > <thinkingloud>Mmmhh... do I really need such  a complex 
> > beast?</thinkingloud>
> >
> > I think that:
> > - 70-90% of the DAL cases will have to deal with a single polygon;
> > - 10-30% of the cases will be for a simple UNION of polygons (eg for 
> > multi chip cameras)
> > - 1% of the remaining cases will be for quite complex regions, like 
> > the one described above.
> >
> > Please correct me if you think my stats do not represent real *DAL* usage.
> > Looking at the DAL standards already available or in the making, DAL 
> > does not seem
> > concerned by more complex shapes like for example the sky coverage of 
> > a survey
> > (see for example the final SDSS sky coverage: 
> > http://www.sdss.org/includes/sideimages/orangespider.html ).
> >
> > Therefore I find asking asking myself:
> >
> > <morethinkingloud>
> >
> > - how many providers will implement a complex library to handle all 
> > possible the cases?
> >
> > - does such library already exist (and for which language)?
> >
> > - otherwise, is it foolish to suggest to limit the usage of an STC-s 
> > region in DAL to few representative cases
> > that cover 95% (or more) of the DAL cases (e.g. single polygon, union 
> > of 2 or more polygons, plus maybe the NOT operator to describe holes) ?
> >
> > - otherwise, is there the need (for lazy providers) to have two 
> > different votable fields:
> >   (1) s_region: the full and potentially complex region,
> >   (2) s_polygon (invented here): the higher level polygon that 
> > inscribes the s_region
> >  ?   (s_polygon would be a LOCATION, while s_region a SUPPORT, in 
> > chardm  speak);
> >
> > - is it maybe just me being too lazy?
> >
> > </morethinkingloud>
> >
> > Just thinking loud, to stimulate discussion (but I think lowering 
> > implementation costs is always good).
> >
> > Eager to know what you think,
> >
> > Thanks a lot, it is really a great news,
> > Alberto
> >
> >
> > On 11 Jan 2012, at 16:56, Gretchen Greene wrote:
> >
> >>
> >> Meeting Minutes from AAS Footprint Tag-up
> >>
> >> Attendees: Francois Ochsenbein, Gretchen Greene, Jonathan Fay, Arnold
> >> Rots, Doug Tody, Thomas Boch
> >>
> >> Summary: The discussion focused on establishing agreement on the format
> >> of the metadata used to describe simple outline footprints, i.e.
> >> spatial regions, for basic DAL services, SSA, TAP, SIA etc. (ultimately
> >> we want a uniform representation for all such services).  The issue of
> >> defining a general footprint service will be considered separately.
> >>
> >> The issue of region specification follows a discussion thread on Utypes
> >> for regions.  The minutes will be circulated to the DAL working group to
> >> see if we have considered valid points.  A follow on action will be to
> >> draft a technical note on the agreed upon implementation.  Having a
> >> standard description for the spatial region support will provide uniform
> >> format specifications across services and simplify client software
> >> handling of regions.
> >>
> >> The current SSA, ObsCore (Observation), and draft SIAV2 specs already
> >> provide a mechanism for this based upon Characterisation.  The main
> >> change required is to generalize the STS-S region specification used to
> >> support more complex multi-area regions, particularly where there is
> >> substantial blank area within the overall region covered.
> >>
> >> As currently defined in the ObsTAP/ObsCore specification and in SSA and
> >> the draft SIA v2, spatial regions will adopt as a default coordinate
> >> system ICRS.  The region will be defined as an STC-s string
> >> representation of the standard Space Time Coordinate data model.  The
> >> Utype will follow the Characterization data model as already
> >> used in SSA, ObsCore, etc., i.e.,
> >>
> >>   Char.SpatialAxis.Coverage.Support.Area
> >>
> >> The ObsCore column name "s_region" is suggested to identify this column
> >> but is not mandatory.
> >>
> >> The "semantic type" of the region is defined as AstroCoordArea.  This is
> >> distinct from the Utype, which may have been source of confusion in the
> >> earlier Utype discussions.
> >>
> >> Compound Regions:
> >>
> >> The main change would be to allow even this "simple" service region
> >> metadata field to be used to describe compound regions that have
> >> multiple areas described.  This is required by observations from some
> >> modern detectors [eg?] which can simultaneously observe multiple spatial
> >> regions.
> >>
> >> An example (will provide more accurate example in technical note) of
> >> this:
> >>
> >>   UNION (Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4,
> >>          Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4)
> >>
> >> Compound types include union, intersection, negation.
> >>
> >> Some current service implementions (e.g. HST?) already implement an
> >> earlier version of this and would need to be updated along with
> >> dependent client applications.  We would like to agree on timing for
> >> some of the reference implementation for clients to utilize the new
> >> representation.
> >>
> >> In the case of multiple coordinate systems, this is special client case
> >> that will be addressed with more complete footprint service spec.  The
> >> general Footprint service specification will be a more complete utility
> >> which addresses footprint capability metadata registry descriptions,
> >> methods for accessing and manipulating regions, spatial tessellation ,
> >> etc., not covered with basic access protocol extension...
> >>
> >>
> >> On Jan 9, 2012, at 2:28 PM, Gretchen Greene <grgbeal at gmail.com 
> >> <mailto:grgbeal at gmail.com>> wrote:
> >>
> >>> Hi folks,
> >>>
> >>> We will be having a tag up on Tuesday, 1:00 in the exhibit hall 
> >>> snack table area, to talk about footprint specification standards to 
> >>> take advantage of a few folks present.
> >>>
> >>> I will post our discussion notes to the DAL group to keep the 
> >>> communication flowing.  I am hopeful we can work toward assembling 
> >>> elements of a working draft spec for the spring interop.
> >>>
> >>> cheers, Gretchen
> >>>
> >>> Sent from my iPad
> >
> 
--------------------------------------------------------------------------
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 head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From jfay at microsoft.com  Thu Jan 19 09:19:34 2012
From: jfay at microsoft.com (Jonathan Fay)
Date: Thu, 19 Jan 2012 17:19:34 +0000
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <201201191552.q0JFq8Iw019990@xebec.cfa.harvard.edu>
References: <4F183565.8080009@astro.unistra.fr>,
	<201201191552.q0JFq8Iw019990@xebec.cfa.harvard.edu>
Message-ID: <5AC8AF9D933B124A95DFD9E1F0298161087DEB70@TK5EX14MBXC238.redmond.corp.microsoft.com>

What about circles?

________________________________________
From: dal-bounces at ivoa.net [dal-bounces at ivoa.net] on behalf of Arnold Rots [arots at head.cfa.harvard.edu]
Sent: Thursday, January 19, 2012 7:52 AM
To: Thomas Boch
Cc: Gretchen Greene; arcops at head.cfa.harvard.edu; dal at ivoa.net
Subject: Re: Notes from AAS IVOA footprint tag up

CXC and HLA have footprint services with common ancestry.
Ours is written in Java and paints on Canvas.

I think the 10/90 - 30/70 split is optimistic.
50/50 is closer to reality and the multi-chip fraction will increase.
It also depends whether you count services or actual number of
footprints processed.
Catalog footprints will also be more complex.

For us the typical case will be:

Union ICRS TOPOCENTER
  (Polygon ...
   Polygon ...
   ...
  )

Although there will be occasional footprints like:

Intersection ICRS TOPOCENTER
  (Union
    (Polygon ...
     Polygon ...
     ...
    )
   Not
    (Union
      (Polygon ...
        Polygon ...
        ...
      )
    )
  )


  - Arnold

Thomas Boch wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> Hi Alberto,
> > Would you know whether a library that can parse, digest, and maybe plot
> > a generic STC-s region exist?
> I asked a similar question 2 months ago. What I remember from the
> discussion is that :
>
> - CADC has developed an STC-S parser in Java
> (http://code.google.com/p/opencadc/source/browse/trunk/projects/#projects%2FcadcTAP%2Fsrc%2Fca%2Fnrc%2Fcadc%2Fstc)
>
>
> - the AST C library, developed by David Berry, has a STC-S parser
> (http://starlink.jach.hawaii.edu/starlink/AST) and provides bindings to
> Python, Perl, Java, ...
>
> Cheers,
>
> Thomas
>
> >
> > I need something that can deal with, eg:
> >
> > Union ICRS TOPOCENTER
> > (Circle 180 10 20
> > Circle 190 20 20
> > Intersection
> >   (Circle 120 -10 20
> >     Difference  (Circle 130 -10 20  Circle 125 -10 2)
> >    Not  (Circle 118 -8 3)
> >   )
> > )
> >
> > <thinkingloud>Mmmhh... do I really need such  a complex
> > beast?</thinkingloud>
> >
> > I think that:
> > - 70-90% of the DAL cases will have to deal with a single polygon;
> > - 10-30% of the cases will be for a simple UNION of polygons (eg for
> > multi chip cameras)
> > - 1% of the remaining cases will be for quite complex regions, like
> > the one described above.
> >
> > Please correct me if you think my stats do not represent real *DAL* usage.
> > Looking at the DAL standards already available or in the making, DAL
> > does not seem
> > concerned by more complex shapes like for example the sky coverage of
> > a survey
> > (see for example the final SDSS sky coverage:
> > http://www.sdss.org/includes/sideimages/orangespider.html ).
> >
> > Therefore I find asking asking myself:
> >
> > <morethinkingloud>
> >
> > - how many providers will implement a complex library to handle all
> > possible the cases?
> >
> > - does such library already exist (and for which language)?
> >
> > - otherwise, is it foolish to suggest to limit the usage of an STC-s
> > region in DAL to few representative cases
> > that cover 95% (or more) of the DAL cases (e.g. single polygon, union
> > of 2 or more polygons, plus maybe the NOT operator to describe holes) ?
> >
> > - otherwise, is there the need (for lazy providers) to have two
> > different votable fields:
> >   (1) s_region: the full and potentially complex region,
> >   (2) s_polygon (invented here): the higher level polygon that
> > inscribes the s_region
> >  ?   (s_polygon would be a LOCATION, while s_region a SUPPORT, in
> > chardm  speak);
> >
> > - is it maybe just me being too lazy?
> >
> > </morethinkingloud>
> >
> > Just thinking loud, to stimulate discussion (but I think lowering
> > implementation costs is always good).
> >
> > Eager to know what you think,
> >
> > Thanks a lot, it is really a great news,
> > Alberto
> >
> >
> > On 11 Jan 2012, at 16:56, Gretchen Greene wrote:
> >
> >>
> >> Meeting Minutes from AAS Footprint Tag-up
> >>
> >> Attendees: Francois Ochsenbein, Gretchen Greene, Jonathan Fay, Arnold
> >> Rots, Doug Tody, Thomas Boch
> >>
> >> Summary: The discussion focused on establishing agreement on the format
> >> of the metadata used to describe simple outline footprints, i.e.
> >> spatial regions, for basic DAL services, SSA, TAP, SIA etc. (ultimately
> >> we want a uniform representation for all such services).  The issue of
> >> defining a general footprint service will be considered separately.
> >>
> >> The issue of region specification follows a discussion thread on Utypes
> >> for regions.  The minutes will be circulated to the DAL working group to
> >> see if we have considered valid points.  A follow on action will be to
> >> draft a technical note on the agreed upon implementation.  Having a
> >> standard description for the spatial region support will provide uniform
> >> format specifications across services and simplify client software
> >> handling of regions.
> >>
> >> The current SSA, ObsCore (Observation), and draft SIAV2 specs already
> >> provide a mechanism for this based upon Characterisation.  The main
> >> change required is to generalize the STS-S region specification used to
> >> support more complex multi-area regions, particularly where there is
> >> substantial blank area within the overall region covered.
> >>
> >> As currently defined in the ObsTAP/ObsCore specification and in SSA and
> >> the draft SIA v2, spatial regions will adopt as a default coordinate
> >> system ICRS.  The region will be defined as an STC-s string
> >> representation of the standard Space Time Coordinate data model.  The
> >> Utype will follow the Characterization data model as already
> >> used in SSA, ObsCore, etc., i.e.,
> >>
> >>   Char.SpatialAxis.Coverage.Support.Area
> >>
> >> The ObsCore column name "s_region" is suggested to identify this column
> >> but is not mandatory.
> >>
> >> The "semantic type" of the region is defined as AstroCoordArea.  This is
> >> distinct from the Utype, which may have been source of confusion in the
> >> earlier Utype discussions.
> >>
> >> Compound Regions:
> >>
> >> The main change would be to allow even this "simple" service region
> >> metadata field to be used to describe compound regions that have
> >> multiple areas described.  This is required by observations from some
> >> modern detectors [eg?] which can simultaneously observe multiple spatial
> >> regions.
> >>
> >> An example (will provide more accurate example in technical note) of
> >> this:
> >>
> >>   UNION (Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4,
> >>          Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4)
> >>
> >> Compound types include union, intersection, negation.
> >>
> >> Some current service implementions (e.g. HST?) already implement an
> >> earlier version of this and would need to be updated along with
> >> dependent client applications.  We would like to agree on timing for
> >> some of the reference implementation for clients to utilize the new
> >> representation.
> >>
> >> In the case of multiple coordinate systems, this is special client case
> >> that will be addressed with more complete footprint service spec.  The
> >> general Footprint service specification will be a more complete utility
> >> which addresses footprint capability metadata registry descriptions,
> >> methods for accessing and manipulating regions, spatial tessellation ,
> >> etc., not covered with basic access protocol extension...
> >>
> >>
> >> On Jan 9, 2012, at 2:28 PM, Gretchen Greene <grgbeal at gmail.com
> >> <mailto:grgbeal at gmail.com>> wrote:
> >>
> >>> Hi folks,
> >>>
> >>> We will be having a tag up on Tuesday, 1:00 in the exhibit hall
> >>> snack table area, to talk about footprint specification standards to
> >>> take advantage of a few folks present.
> >>>
> >>> I will post our discussion notes to the DAL group to keep the
> >>> communication flowing.  I am hopeful we can work toward assembling
> >>> elements of a working draft spec for the spring interop.
> >>>
> >>> cheers, Gretchen
> >>>
> >>> Sent from my iPad
> >
>
--------------------------------------------------------------------------
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 head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------



From d.berry at jach.hawaii.edu  Thu Jan 19 09:43:13 2012
From: d.berry at jach.hawaii.edu (David Berry)
Date: Thu, 19 Jan 2012 17:43:13 +0000
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <4F183565.8080009@astro.unistra.fr>
References: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>
	<6BFC4A86-1FAF-403C-AD6C-272B1148C7CF@gmail.com>
	<90087DDE-7250-43D5-9753-4068C6CEF55E@googlemail.com>
	<4F183565.8080009@astro.unistra.fr>
Message-ID: <CAALafn45JVRCcNSLpowJ498u2qQB1ADp=UhSD5PcYpkjGAvJ0w@mail.gmail.com>

On 19 January 2012 15:23, Thomas Boch <thomas.boch at astro.unistra.fr> wrote:
> Hi Alberto,
>
> Would you know whether a library?that can parse, digest, and maybe plot
> a generic STC-s region?exist?
>
> I asked a similar question 2 months ago. What I remember from the discussion
> is that :
>
> - CADC has developed an STC-S parser in Java
> (http://code.google.com/p/opencadc/source/browse/trunk/projects/#projects%2FcadcTAP%2Fsrc%2Fca%2Fnrc%2Fcadc%2Fstc)
>
> - the AST C library, developed by David Berry, has a STC-S parser
> (http://starlink.jach.hawaii.edu/starlink/AST) and provides bindings to
> Python, Perl, Java, ...

AST includes facilities for plotting outlines of simple or compound
STC-S regions. See my ADASS 2009 poster:

http://starlink.jach.hawaii.edu/starlink/AST?action=AttachFile&do=view&target=adass2009.pdf

Also see the on-line demo of ASTs STC-S handling and plotting facilities at

http://starlink.jach.hawaii.edu/starlink/AST#stcdemo

David

From arots at head.cfa.harvard.edu  Thu Jan 19 10:49:11 2012
From: arots at head.cfa.harvard.edu (Arnold Rots)
Date: Thu, 19 Jan 2012 13:49:11 -0500 (EST)
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <5AC8AF9D933B124A95DFD9E1F0298161087DEB70@TK5EX14MBXC238.redmond.corp.microsoft.com>
Message-ID: <201201191849.q0JInPmj020046@xebec.cfa.harvard.edu>

We display a circle to indicate the search area, but for us it isn't
part of the footprint.
I am sure radio images would use circles.

  - Arnold

Jonathan Fay wrote:
> What about circles?
> 
> ________________________________________
> From: dal-bounces at ivoa.net [dal-bounces at ivoa.net] on behalf of Arnold Rots [arots at head.cfa.harvard.edu]
> Sent: Thursday, January 19, 2012 7:52 AM
> To: Thomas Boch
> Cc: Gretchen Greene; arcops at head.cfa.harvard.edu; dal at ivoa.net
> Subject: Re: Notes from AAS IVOA footprint tag up
> 
> CXC and HLA have footprint services with common ancestry.
> Ours is written in Java and paints on Canvas.
> 
> I think the 10/90 - 30/70 split is optimistic.
> 50/50 is closer to reality and the multi-chip fraction will increase.
> It also depends whether you count services or actual number of
> footprints processed.
> Catalog footprints will also be more complex.
> 
> For us the typical case will be:
> 
> Union ICRS TOPOCENTER
>   (Polygon ...
>    Polygon ...
>    ...
>   )
> 
> Although there will be occasional footprints like:
> 
> Intersection ICRS TOPOCENTER
>   (Union
>     (Polygon ...
>      Polygon ...
>      ...
>     )
>    Not
>     (Union
>       (Polygon ...
>         Polygon ...
>         ...
>       )
>     )
>   )
> 
> 
>   - Arnold
> 
> Thomas Boch wrote:
> [ Charset ISO-8859-1 unsupported, converting... ]
> > Hi Alberto,
> > > Would you know whether a library that can parse, digest, and maybe plot
> > > a generic STC-s region exist?
> > I asked a similar question 2 months ago. What I remember from the
> > discussion is that :
> >
> > - CADC has developed an STC-S parser in Java
> > (http://code.google.com/p/opencadc/source/browse/trunk/projects/#projects%2FcadcTAP%2Fsrc%2Fca%2Fnrc%2Fcadc%2Fstc)
> >
> >
> > - the AST C library, developed by David Berry, has a STC-S parser
> > (http://starlink.jach.hawaii.edu/starlink/AST) and provides bindings to
> > Python, Perl, Java, ...
> >
> > Cheers,
> >
> > Thomas
> >
> > >
> > > I need something that can deal with, eg:
> > >
> > > Union ICRS TOPOCENTER
> > > (Circle 180 10 20
> > > Circle 190 20 20
> > > Intersection
> > >   (Circle 120 -10 20
> > >     Difference  (Circle 130 -10 20  Circle 125 -10 2)
> > >    Not  (Circle 118 -8 3)
> > >   )
> > > )
> > >
> > > <thinkingloud>Mmmhh... do I really need such  a complex
> > > beast?</thinkingloud>
> > >
> > > I think that:
> > > - 70-90% of the DAL cases will have to deal with a single polygon;
> > > - 10-30% of the cases will be for a simple UNION of polygons (eg for
> > > multi chip cameras)
> > > - 1% of the remaining cases will be for quite complex regions, like
> > > the one described above.
> > >
> > > Please correct me if you think my stats do not represent real *DAL* usage.
> > > Looking at the DAL standards already available or in the making, DAL
> > > does not seem
> > > concerned by more complex shapes like for example the sky coverage of
> > > a survey
> > > (see for example the final SDSS sky coverage:
> > > http://www.sdss.org/includes/sideimages/orangespider.html ).
> > >
> > > Therefore I find asking asking myself:
> > >
> > > <morethinkingloud>
> > >
> > > - how many providers will implement a complex library to handle all
> > > possible the cases?
> > >
> > > - does such library already exist (and for which language)?
> > >
> > > - otherwise, is it foolish to suggest to limit the usage of an STC-s
> > > region in DAL to few representative cases
> > > that cover 95% (or more) of the DAL cases (e.g. single polygon, union
> > > of 2 or more polygons, plus maybe the NOT operator to describe holes) ?
> > >
> > > - otherwise, is there the need (for lazy providers) to have two
> > > different votable fields:
> > >   (1) s_region: the full and potentially complex region,
> > >   (2) s_polygon (invented here): the higher level polygon that
> > > inscribes the s_region
> > >  ?   (s_polygon would be a LOCATION, while s_region a SUPPORT, in
> > > chardm  speak);
> > >
> > > - is it maybe just me being too lazy?
> > >
> > > </morethinkingloud>
> > >
> > > Just thinking loud, to stimulate discussion (but I think lowering
> > > implementation costs is always good).
> > >
> > > Eager to know what you think,
> > >
> > > Thanks a lot, it is really a great news,
> > > Alberto
> > >
> > >
> > > On 11 Jan 2012, at 16:56, Gretchen Greene wrote:
> > >
> > >>
> > >> Meeting Minutes from AAS Footprint Tag-up
> > >>
> > >> Attendees: Francois Ochsenbein, Gretchen Greene, Jonathan Fay, Arnold
> > >> Rots, Doug Tody, Thomas Boch
> > >>
> > >> Summary: The discussion focused on establishing agreement on the format
> > >> of the metadata used to describe simple outline footprints, i.e.
> > >> spatial regions, for basic DAL services, SSA, TAP, SIA etc. (ultimately
> > >> we want a uniform representation for all such services).  The issue of
> > >> defining a general footprint service will be considered separately.
> > >>
> > >> The issue of region specification follows a discussion thread on Utypes
> > >> for regions.  The minutes will be circulated to the DAL working group to
> > >> see if we have considered valid points.  A follow on action will be to
> > >> draft a technical note on the agreed upon implementation.  Having a
> > >> standard description for the spatial region support will provide uniform
> > >> format specifications across services and simplify client software
> > >> handling of regions.
> > >>
> > >> The current SSA, ObsCore (Observation), and draft SIAV2 specs already
> > >> provide a mechanism for this based upon Characterisation.  The main
> > >> change required is to generalize the STS-S region specification used to
> > >> support more complex multi-area regions, particularly where there is
> > >> substantial blank area within the overall region covered.
> > >>
> > >> As currently defined in the ObsTAP/ObsCore specification and in SSA and
> > >> the draft SIA v2, spatial regions will adopt as a default coordinate
> > >> system ICRS.  The region will be defined as an STC-s string
> > >> representation of the standard Space Time Coordinate data model.  The
> > >> Utype will follow the Characterization data model as already
> > >> used in SSA, ObsCore, etc., i.e.,
> > >>
> > >>   Char.SpatialAxis.Coverage.Support.Area
> > >>
> > >> The ObsCore column name "s_region" is suggested to identify this column
> > >> but is not mandatory.
> > >>
> > >> The "semantic type" of the region is defined as AstroCoordArea.  This is
> > >> distinct from the Utype, which may have been source of confusion in the
> > >> earlier Utype discussions.
> > >>
> > >> Compound Regions:
> > >>
> > >> The main change would be to allow even this "simple" service region
> > >> metadata field to be used to describe compound regions that have
> > >> multiple areas described.  This is required by observations from some
> > >> modern detectors [eg?] which can simultaneously observe multiple spatial
> > >> regions.
> > >>
> > >> An example (will provide more accurate example in technical note) of
> > >> this:
> > >>
> > >>   UNION (Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4,
> > >>          Polygon ra1 dec1, ra2 dec2, ra3 dec3, ra4 dec4)
> > >>
> > >> Compound types include union, intersection, negation.
> > >>
> > >> Some current service implementions (e.g. HST?) already implement an
> > >> earlier version of this and would need to be updated along with
> > >> dependent client applications.  We would like to agree on timing for
> > >> some of the reference implementation for clients to utilize the new
> > >> representation.
> > >>
> > >> In the case of multiple coordinate systems, this is special client case
> > >> that will be addressed with more complete footprint service spec.  The
> > >> general Footprint service specification will be a more complete utility
> > >> which addresses footprint capability metadata registry descriptions,
> > >> methods for accessing and manipulating regions, spatial tessellation ,
> > >> etc., not covered with basic access protocol extension...
> > >>
> > >>
> > >> On Jan 9, 2012, at 2:28 PM, Gretchen Greene <grgbeal at gmail.com
> > >> <mailto:grgbeal at gmail.com>> wrote:
> > >>
> > >>> Hi folks,
> > >>>
> > >>> We will be having a tag up on Tuesday, 1:00 in the exhibit hall
> > >>> snack table area, to talk about footprint specification standards to
> > >>> take advantage of a few folks present.
> > >>>
> > >>> I will post our discussion notes to the DAL group to keep the
> > >>> communication flowing.  I am hopeful we can work toward assembling
> > >>> elements of a working draft spec for the spring interop.
> > >>>
> > >>> cheers, Gretchen
> > >>>
> > >>> Sent from my iPad
> > >
> >
> --------------------------------------------------------------------------
> 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 head.cfa.harvard.edu
> USA                                     http://hea-www.harvard.edu/~arots/
> --------------------------------------------------------------------------
> 
> 
> 
--------------------------------------------------------------------------
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 head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------

From msdemlei at ari.uni-heidelberg.de  Thu Jan 19 09:14:36 2012
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Thu, 19 Jan 2012 18:14:36 +0100
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <90087DDE-7250-43D5-9753-4068C6CEF55E@googlemail.com>
References: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>
	<6BFC4A86-1FAF-403C-AD6C-272B1148C7CF@gmail.com>
	<90087DDE-7250-43D5-9753-4068C6CEF55E@googlemail.com>
Message-ID: <20120119171436.GA22679@ari.uni-heidelberg.de>

Hi Alberto, hi list,

On Wed, Jan 18, 2012 at 04:24:55PM +0100, Alberto Micol wrote:
> Would you know whether a library that can parse, digest, and maybe plot
> a generic STC-s region exist?
Well, for complete STC-s, "digest" is a big word (e.g., as concerns
all the transformations between the coordinate systems you can
specify with STC-S).

Having said that, the GAVO STC library
(http://soft.g-vo.org/subpkgs#STC) parses what's basically a slight
superset of STC-S and can do "some things" (TM) with the result.

Within the context of the server package
(http://soft.g-vo.org/dachs), I derive coverage information of
registry purposes from it, generate utypes, and use it to turn ADQL
regions into something that pgSphere can deal with.  I've not touched
the footprint issue as such, though.

Cheers,

       Markus


From msdemlei at ari.uni-heidelberg.de  Fri Jan 20 00:38:21 2012
From: msdemlei at ari.uni-heidelberg.de (Markus Demleitner)
Date: Fri, 20 Jan 2012 09:38:21 +0100
Subject: TAP examples revisited
Message-ID: <20120120083821.GA31136@ari.uni-heidelberg.de>

Dear TAP enthusiats (and others),

After the feedback on the first attempt with TAP examples (in the
tap_schema.examples table), I've now cooked up a second proposal,
basically in the spirit of microformats.  I've already written up
something spec-like that I'd develop into a note if I hear
encouraging words: http://docs.g-vo.org/tapexample.html

If I may say so myself, I like that proposal much better than the
tap_schema one.  The service at http://dc.g-vo.org/tap currently
implements both (internally, the HTML is generated from
tap_schema.examples), so you can compare for yourself.

I'd appreciate any kind of feedback, most of all of course from
client authors.

Cheers,

         Markus


From greene at stsci.edu  Fri Jan 20 06:46:23 2012
From: greene at stsci.edu (Gretchen Greene)
Date: Fri, 20 Jan 2012 14:46:23 +0000
Subject: Notes from AAS IVOA footprint tag up
In-Reply-To: <20120119171436.GA22679@ari.uni-heidelberg.de>
References: <D79F55E2-D0E9-4350-B546-B9EFB857B27A@gmail.com>
	<6BFC4A86-1FAF-403C-AD6C-272B1148C7CF@gmail.com>
	<90087DDE-7250-43D5-9753-4068C6CEF55E@googlemail.com>,
	<20120119171436.GA22679@ari.uni-heidelberg.de>
Message-ID: <F4391FEBF3C01E499F244DFA4B689A6B0A901A30@EXCHMAIL2.stsci.edu>

Hi folks,

I've tried to capture some of this information on the main DAL page topic for footprint access protocol.  I think it will be more and more important to have a complete spec that can handle regions accurately and efficiently with standard methods,  but first things first...;)  i fully support this effort to incorporate the simpler regions in the basic DAL protocols which we have already standard framework to utilize near term.

There is some additional information that is much overdue for me to transfer in (presented at Victoria interop and before) that i'm hoping to transfer over in the next couple days that describe the specifications we have been proposing for the more complete footprint/spatial region handling,  of which this simplified STC-s DAL standard implementation is associated with.

http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/FootprintAccessProtocol

There are a few topics off this page that hold this recent thread content,  including the proposed DAL basic footprint.

http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/DALBasicFootprintHere
http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/STCparsers

-Gretchen

________________________________________
From: dal-bounces at ivoa.net [dal-bounces at ivoa.net] on behalf of Markus Demleitner [msdemlei at ari.uni-heidelberg.de]
Sent: Thursday, January 19, 2012 12:14 PM
To: dal at ivoa.net
Subject: Re: Notes from AAS IVOA footprint tag up

Hi Alberto, hi list,

On Wed, Jan 18, 2012 at 04:24:55PM +0100, Alberto Micol wrote:
> Would you know whether a library that can parse, digest, and maybe plot
> a generic STC-s region exist?
Well, for complete STC-s, "digest" is a big word (e.g., as concerns
all the transformations between the coordinate systems you can
specify with STC-S).

Having said that, the GAVO STC library
(http://soft.g-vo.org/subpkgs#STC) parses what's basically a slight
superset of STC-S and can do "some things" (TM) with the result.

Within the context of the server package
(http://soft.g-vo.org/dachs), I derive coverage information of
registry purposes from it, generate utypes, and use it to turn ADQL
regions into something that pgSphere can deal with.  I've not touched
the footprint issue as such, though.

Cheers,

       Markus