IVOA Footprints Telecon Meeting Notes March 11, 2013 Attendees: Gretchen Greene, Tom Donaldson, Mark Taylor, Brian McLean, Francois Bonnarel, Pierre Fernique,Arnold Rots, Doug Tody The agenda followed the basic topics outlined below: 1. Basic DAL footprints, and basis for development of Footprint Access Protocol (FAP) GG: - summary that DALI was proposed to define basic DAL footprints as per DM proposed in ObsCaore. This is longer in proposition for basic dal. FB - agrees that ObsTAP region should be extended to other DAL protocols ObsTAP generalized to other protocols. Recommend to include this topic in RFC DALI discussion. Francois - queston on schedule for FAP document? since this is not making good progress, it will take too long MT: agrees FAP may be weighty for basic DAL ---- TD: footprints may be too generalized for client development, need development to occur sooner than later 2. MOC - based on Healpix PF: main question is that MOC is used in several clients, and data providers, problem to register list of MOCS/maps. Is it possible to link the IVOA registry with MOC? How to update list and maintain. MT: interest in using MOC, Defined 2 use cases: (1) position (or list), which resources cover position: STC/x or S is not easy to register MOC descriptions in registry, scale * Send registry a point, then indexed list of coverages * Do not want to search through cone searches and subsequent run of spatial queries (2) client wants to display coverages. MOC works nicely for this. TD: including MOC on registry side and providing registry services would be affective. Getting MOCS for all the resources is where does the responsibility come, who maintains this especially after resource changes. What is the purpose of the registry for services that do not have MOCS? Detailed issues about where do these quality coverages from providers come from. Tools would be needed to help providers generate these, may not be easy to get providers to get on board. AR: Chandra archive cone search, pointed archive, sparse, search for candidate observations within distance from position. The MOC would have holes, less efficient than sorting through field centers, doesn't tell you how things are covered, e.g. outer regions. Cone has distance restrictions from pointing centers. TD: MOC is more convenience because it handles simple contains before list searching However, MOC does not represent density. Limitation. PF: Could not compress with density. MOC is map. AR: simple cone search on observation catalog is as efficient PF: 10,000 MOCS is more efficient than 10,000 cone searches TD: put the FAP on the registry, RegionCoverage could be converted on method to input MOC to STC. Method where you have point or cone. Going with this combined approach that could serve same method but have translation AR: Think about full search, once you have MOCs, next step in discovery. MT: where it saves you time, tells you which of those services you drill down TD: filter negative responses. Vizier MOC is used for this GG: main goal for FAP to index and support this capability, i.e. spatial index with performance for contains search AR: is there an index on the Vizier catalogs? Is the sky coverage included in the index? PF: MOC is accessible for all Vizier tables. MT: MOCS are not to have information about regions covered. Only pixelated is there is something in the area. Results are not exact in nature. Concept...MOCS are only weed out. AR: Clearly 2 types of coverage for catalogs: Actual sky coverage of the catalog, is important information 3. Coverage integration into Registry: RegTAP: coverage, may be simple bounding boxes (from Markus) 4. Apps discovery of footprints (see also previous discussion about MOC) AR: If looking at specific position, very useful to know if there is a catalog that coverage area but does not have actual content. Cone search allows only catalog search Observations, allows users to ask one or the other TD: SIA vs object search cone search, then coverage map for SIA should include full coverage of all images. Not just central point of each image, i.e. catalog. SIA MOCS should be important to be generated to reflect actual coverage. TD: Discovery of Footprints: How does client know that there are STC/s regions. Should we be more specific? DALI may be the correct RFC discussion to propose to include to extend to all DAL protocols Recommended at next interop. DT: More of data model thing than interface thing. DALI not the correct standard. ObsTAP/ObsCore, SIA v2, SSA will have the STC/s. Use newer services. SDM possibly too. This does not address the legacy services, does not solve the problem. 5. Interop Meeting - suggestions for possible sessions or splinter meeting to discuss footprints efforts. MT: Applications/Registry joint session: * Coverage discussion: MOC + coverage capability * Telecon Group propose to have a splinter meeting before this joint session to discuss what we are/are not going to talk about in the session.