While having a discussion at the office a few days ago, I realized that some Simple Image Access Protocol (SIAP) services from the Hubble Legacy Archive (HLA) return footprint information in the form of Space Time Coordinates (STC).
This process, which should have been quick, turn out to be tedious just because of the format SIAP retuns: VOTable. While being the standard XML way for Virtual Observatory (VO) data and metadata to be exchanged, this format is inefficient, antiquated and not sufficiently curated to be a standard. Furthermore, the lack of easy parsing tools for its structure renders VOTable not an operationally viable XML format for rapid application development. The use of industry standards, like JSON would work better for the large majority of VO data exchanges.
VOTables seem to have emerged as an "XML copy" of FITS files: the standard data transport in astronomy. FITS files have headers and data. VOTables have resources and data. The issue is how resources are tagged in VOTables and most importantly how the data is stored. I still cannot believe I have to see <TR> and <TD> in an XML file!
Even worse, in some cases the fields that hold the STC Polygon contains multiple polygons simply reparated by spaces... When you try to deserialize a VOTable with any of the ready-to-use de/serializers for many languages (I was using mono - C# - on my mac), deserialization simply fails. I looked for a VOTable parser in C# (I remember I wrote something for this a few years back), but mine worked only for VOTable v1.0 and the current version is version 1.1.
Regardless of these obstables, a little bit of awk in the returned VOTable, allowed me to basically extract the STS-regions.
I ran a query for HLA footprints around the Kepler Field of View. The results are in a KML file that contains also the Kepler detectors footprints. I did not add any information to the footprint (that requires parsing properly a VOTable and getting lost in <TD>s). Perhaps the best way is to go to the source database of MAST footprints and simply create a KML service. That would really be fast and perhaps even fun! :)