Last week the Worldwide Telescope team put out some tools to support astronomy and earth-system science with a strong emphasis on time-series support and 3-D rendering. This includes the beta release of new tools and SDK for WWT. They include:
WWT Excel Add-in - Excel Add-in ribbon to load location and time-based data into the WWT visualization environment. Such data, for example, can include latitude, longitude, magnitude, and depth for earthquakes or latitude, longitude, and magnitude for disease outbreaks. By installing the WWT Add-In for Excel, you highlight and load your data into WWT in seconds.
WWT Client Layer Control API (LCapi) – the API to send datasets (time series, images, 3D models, etc) to WWT Windows client to visualize as well controlling the visualization. This is the API that the Excel Add-in was built on.
SDK - documentations, an interactive LCapi sample to demonstrate the LCapi commands, and image processing tools and libraries to create tile pyramids for rendering in WorldWide Telescope – be it the entire sky or earth or even specific regions.
It would be great to see folks use/test out the Excel Add-in and LCapi and let us know how it works…feedback and questions are appreciated
If you are a professional or student interested in visualizing astronomy data then you should not miss the Astro-Viz 2011 workshop. We invite participants who span a broad range of interests and expertise, including: visualization and graphics experts, illustrators/animators, planetarium developers and media. The goal for this workshop is discussion on the development of visualization for use in research and education and not just limited to astronomy. Registration is live. For more information visit http://ssg.astro.washington.edu/astroviz.shtml
Astro-Viz 2011 Workshop
This workshop is dedicated to astronomy visualization. We invite participants who span a broad range of interests and expertise, including, visualization and graphics experts, illustrators and animators, planetarium developers and technical media. Our goal for this workshop is an active discussion on the development of visualization for use in research and education. The workshop will be held at the University of Washington's new digital planetarium. Areas of discussion will include Open discussion of visualization in astrophysics ranging from interactivity to high-dimensional data Volume and point rendering Interaction with massive data sets Scalable and interactive visualization Outreach and visualization Planetariums/museums Dome visualization Connection between the dome and the classroom Content creation The role of the observatories Generating full dome content Standards and sharing
This workshop is dedicated to astronomy visualization. We invite participants who span a broad range of interests and expertise, including, visualization and graphics experts, illustrators and animators, planetarium developers and technical media. Our goal for this workshop is an active discussion on the development of visualization for use in research and education. The workshop will be held at the University of Washington's new digital planetarium. Areas of discussion will include
AstroViz 2011
For those of you interested in Geospatial issues – check out the new strawman proposal for adding Geospatial to the OData protocol.
Geospatial data support in OData This is a strawman proposal. Please challenge it in the OData mailing list. OData supports geospatial data types as a new set of primitives. They can be used just like any other primitives - passed in URLs as literals, as types and values for properties, projected in $select, and so on. Like other primitives, there is a set of canonical functions that can be used with them. The only restriction, as compared to other primitives, is that geospatial types may not be used as entity keys (see below). The rest of this spec goes into more detail about the geospatial type system that we support, how geospatial types are represented in $metadata, how their values are represented in Atom and JSON payloads, how they are represented in URLs, and what canonical functions are defined for them. Modeling Primitive Types Our type system is firmly rooted in the OGC Simple Features geometry type system. We diverge from their type system in only four ways. Figure 1: The OGC Simple Features Type Hierarchy
This is a strawman proposal. Please challenge it in the OData mailing list.
OData supports geospatial data types as a new set of primitives. They can be used just like any other primitives - passed in URLs as literals, as types and values for properties, projected in $select, and so on. Like other primitives, there is a set of canonical functions that can be used with them.
The only restriction, as compared to other primitives, is that geospatial types may not be used as entity keys (see below).
The rest of this spec goes into more detail about the geospatial type system that we support, how geospatial types are represented in $metadata, how their values are represented in Atom and JSON payloads, how they are represented in URLs, and what canonical functions are defined for them.
Our type system is firmly rooted in the OGC Simple Features geometry type system. We diverge from their type system in only four ways.
Figure 1: The OGC Simple Features Type Hierarchy
http://www.odata.org/blog/2011/5/3/geospatial-data-support-in-odata