Follow-up of previous ObsParis / CDS meeting
Using Aladin prototype v9.6 (27/6/2017) and TOPCAT v4.4 on MacOS
- See also page: Aladin & planetary surfaces for other use cases / examples.
Set up for planetary mapping in TOPCAT
Assuming longitude is E-handed (EPN-TAP convention, and IAU convention in planetocentric frames):
• Standard setup for planetary maps in TOPCAT SkyPlot:
(in Axes / Projection)
Projection = sin (i.e. sphere, for orthographic), but car (cylindrical) is also possible
Uncheck Reflect longitude axis,
View Sky System: Equatorial,
(in Axis / Grid)
Increase Grid Crowding cursor value to 30 or 60° tick
• Standard setup for planetary maps in TOPCAT PlanePlot (cylindrical):
(in Axes / Range)
Set Max X value to 360
Central meridian will be on left side
• To put the central meridian at the center:
(in Axes / Range)
Min / Max X = -180 / 180
(in Mark / Position)
X: LON > 180 ? Lon - 360 : Lon
(in Axes / Labels)
X Label = Longitude
Healpix generation from a table in TOPCAT
Healpix is a tesselation system on the sphere, which depends on a resolution/scale parameter. It provides regular sampling in surface, with no singularity (poles).
The point is to easily get a combined map from sparse data; the result is also scalable in resolution, at least degradation is performed correctly by combining healpix cells.
Cell size (in FoV size, ie in longitude at Equator): scale 6 ~ 1°, 12 ~ 1', 18 ~ 1"
Map projections available with this mode are (in Axes panel) "sin" (actually: orthographic), Aitoff (all surface visible, minimize deformations near the poles), and "car" (cylindrical).
In TOPCAT, load a table containing a list of observations located in lon/lat
(working example is a large table of VIRTIS/Rosetta observations of 67P)
A detailed step by step tutorial is now available: Use case: mapping sparse spatial data with TOPCAT
1) Standard way (density map from a lon/lat table):
• Open the SkyPlot panel, select table and Lon & Lat parameters in Position panel
• Go to Form panel, click on the big Forms button (green cross) and "Add SkyDensity" from the local menu. Uncheck the previous Mark Form
• Go back to Position panel, select Lon and Lat parameters (C1min and C2min for an EPN-TAP view)
• Back to the Form panel, select parameter to plot as Weight (will be weighted by density), select combine mode, and adjust scale. Healpix generation is performed on the fly, so all scales are OK.
• Possibly adapt color scale in the Aux Axis tab (left menu)
• In the Form panel, you can save the healpix map (cell #, plotting parameter) - saved at scale 12, apparently (FITS formatting is more efficient than VOTable, as it is compressed).
You can also load an existing map from there.
2) Alternatively (from a binned table):
This other method is adapted when you have only 1 or 0 data / healpix cell, ie if the grouping has already been done in a previous step (e.g., with an ADQL query to group data by healpix cells). It is not intended to group or average table rows in the cells.
• Start from a lon/lat table, first add a new synthetic column providing healpix cell number (right-click on table column header and enter new column description):
healpixNestIndex( 6, longitude, latitude )
(adapt scale to data in use, 6 provides a resolution of ~ 1° at the Equator)
• (once you have a table with healpix cell # included)
Open Skyplot panel, add New healpix layer, provide inputs
Correct Healpix Data Level in particular (TOPCAT will try to guess, but this is uncertain)
• In Skyplot / Style panel, use Degrade and Combine mode to reduce resolution on the fly (super-resolution can no longer be achieved)
Mars HiPS generation in Aladin
HiPS (Hierarchical progressive survey) are associations of healpix maps at different scales. They provide efficient multiresolution scaling on the fly in Aladin.
1) From a single file (updated Aug 2017)
The use is mostly to get a 3D spherical model from a map, where contours and objects can be overplotted. See Io use case for more details: Aladin & planetary surfaces
In Aladin, load file Mars_MGS_colorhillshade_mola_1024.jpg (MOLA integrated relief map)
• Go to Image > astrometric calibration:
Coord = 0.,0.
pos x/y = 512, 256 (lon = 0°, lat = 0° at image center)
size = 21.1' (= 360. / 1024)
RA symmetry = False => this is mandatory to get the image in the correct orientation.
• Convert to HiPS :
Tool > Generate HiPS based on… > current image
• The hpx image is saved (somewhere) on disk automatically (you may have to search for it)
Open issue: this provides a correct E longitude frame. However, s_region footprints sent from an EPN-TAP service will now plot at the wrong longitude (see figure below with Huygens and Schiaparelli)
E.g. for Huygens crater, s_region = Polygon UNKNOWNFrame 55.582 -17.8305918846 54.7737623408 -17.7532983656…
(in short, s_region Unknown frame is incorrectly assumed W-handed)
Settable longitude direction in Properties panel of drawings would provide a workaround.
The real solution is to define a E-handed frame in s_region
2) From a series of local files in Aladin
This method will provide adaptive resolution when using files of various scales
TBC, did not work on my machine early 2017.
MOC use case in Aladin
MOC (Multi-Order Coverages) are footprints defined in terms of a healpix cells list mixing various resolutions. They provide immediate location information e.g. about intersections, and can accommodate footprints of arbitrary complexity (hollowed, non-connex, etc…). There is no explicit contour associated, so the usage is different from the s_region parameter.
- Should also retain info about original file coverages, for callback purpose.
- Load previous Mars MOLA HiPS in Aladin
- Select two large craters in Mars Craters service from VESPA client
- send as s_region from VESPA client (to Aladin) — (s_region was then provided in this service with W longitudes, so this projected correctly)
- select them in Aladin with pointer
- Generate common MOC for these 2 craters (Coverage > Generate a MOC based on… > selected drawing objects)
- You can save it from File > Export Planes (save preferably as fits for reuse)
This is OK and very quick.
This is not a direct alternative to s_region however: resulting contours are much larger, can't be included in a table. But we can either have precomputed MOC stored somewhere (for datasets?) or compute them on the fly when required.
• Then: test intersections with something else - see example in next pages