Jeremy Brewer
unread,Dec 4, 2008, 5:48:17 PM12/4/08Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to wcs2kml
Since there have been no posts in over a year because I was finishing
up my PhD, I thought I would add a short note describing where I want
to take wcs2kml in the next few months. Feel free to comment on any
features you'd like to see, etc.
Short term goals:
- Migrate off automake/autoconf and switch to compiling a static
binary. There are 2 reasons for doing this. First, the GNU autotool
stuff is a nightmare to work with when it fails (which is often). I
want the confidence to be able to add new files and dependencies
without breaking the build. Second, static binaries are much easier
to test and debug, and 99% of our users almost certainly just want to
build the binary and run it. We can eventually add a library install
at a later time for users who want to directly use the API.
As a first step, I will just write a plain Makefile with static
library options that should work on Linux + Mac OS X. Once I'm ready
to release a tarball we'll move to CMake (which is fantastic if you
haven't used it).
- Improve portability with the internal Google version of wcs2kml.
This involves reinventing some wheels but it shouldn't be too bad.
The advantage of this is that it will make my life much easier.
Medium term goals:
- Improve the efficiency of regionated images as much as possible.
This is a rather big goal as it involves many, many improvements. In
particular, this requires:
* Integrating Ryan's changes to use the native quad tree and a more
efficient KML representation
* Writing JPEG read/write code for images that don't need
transparency. This will also involve moving to a registration pattern
to autodetect which type of image is being read.
* Fixing any alignment bugs in Regionator - there are reports of
pixel-level overlap issues that I haven't been able to verify/test
* Writing a Python script to intelligently bundle regionated images +
KML into a KMZ file that points at the desired web server. Here we
can be smart and do something like bundle the first 2-4 levels of the
quad tree hierarchy so that the images load very quickly. We can
retire regionated_dir_compressor.py then.
* Evaluating the new code - I have no idea how to do this
quantitatively, so I will probably just do so qualitatively then ask
the Earth team for help here.
- Cleaning up the API. There are some warts in wcs2kml that need to
be cleaned up. In particular, the code for stepping through the
warped image is repeated.
- Finish the FITS class so that we can read keywords and check the WCS
projection code for errors before the bounding box calculation.
- Extend the JPEG work above to directly support FITS images in
wcs2kml (and to move fits2png.py to a C++ implementation).
- Try to fix the image size guessing code so it doesn't break down for
North aligned images.
- Clean up the command line flags. There are way too many of them and
some won't make sense after the improvements. In particular, we will
probably always regionate images by default.
- Release an updated tarball containing the above changes.
Longer term goals:
- Support for Maps. Support for the Mercator projection should be
fairly easy if the API cleanup is done properly. I'm not sure how
hard the accompanying metadata generation is.
- Mosaicing support. A huge performance gain for multiple images can
be had simply by mosaicing them all into one image then regionating.
Additionally, I'm guessing many people are just creating a mosaic
image then passing it to wcs2kml anyway, so it makes sense to support
mosaicing directly. We'll try to support 2 ways of creating mosaics.
The first mode will involve just passing in a list of files via the
command line (e.g. *.png), and the