Native support for MOC operations in the Java HEALPix package

Andreas Wicenec awicenec at gmail.com
Thu Oct 16 02:04:04 CEST 2014


Thanks for sharing. This is more than useful.

Cheers,
Andreas

On 15 Oct 2014 20:16, Martin Reinecke <martin at MPA-Garching.MPG.DE> wrote:
>
> Hi, 
>
> I was encouraged by Pierre Fernique to send this announcement to the 
> IVOA apps mailing list, since there might be broader interest ... 
>
>
> After the MOC standard document had been accepted, I started working on 
> native MOC support in the Java HEALPix package. 
> My aim was to provide a compact and highly efficient implementation of 
> the central functionality (MOC construction, input/output and set 
> operations). Here is a fairly complete list of the current capabilities: 
>
> - import/export from/to FITS (both files and streams are supported) 
>
> - import/export from/to strings (both the basic ASCII and JSON syntax 
> shown in the MOC standard) 
>
> - import/export from/to a highly compressed bitstream representation, 
> making use of interpolative coding. These objects are significantly 
> smaller than the FITS and ASCII representations, and can be read/written 
> very quickly; they could be useful on a VO server dealing with many MOCs 
> at the same time. 
>
> - import/export from/to RangeSets of UNIQ pixels 
>
> - set operations (union, intersection, subtraction, overlap test, subset 
> test, complement) that are even faster than what was available so far, 
> due to improvements in the RangeSet class. 
>
> - resolution degradation of a MOC to a desired Healpix order. Partially 
> covered pixels can be kept or discarded, depending on a parameter. 
>
> If you are interested, I have attached a source tarball of the current 
> Java HEALPix package. The most up-to-date version can always be found in 
> the subversion repository at http://sourceforge.net/projects/healpix 
>
> Please let me know if you think that essential functionality is still 
> missing! 
> Concerning class and function names, I'm still considering various 
> alternatives to make them as unambiguous as possible. Again, if you have 
> suggestions in that area, please tell me. 
>
> Best regards, 
>   Martin Reinecke 
>


More information about the apps mailing list