Abstract: For many geophysical disciplines it is sufficient, and often expedient, to treat the Earth as a Cartesian plane, at least for data search and order purposes. Unfortunately the Earth is round and the majority of Earth Science data is being gathered by satellite born sensors circling the Earth in polar orbits. As the number of satellite born sensors increases, and the resolution of those sensors increases, the shear volume of the available data has made the flat Earth paradigm increasingly problematic. Cryospheric Science is one discipline that is ill-served by the flat Earth paradigm so the National Snow and Ice Data Center has been working with the sphere for quite some time. We have found that treating the Earth as a sphere significantly increases spatial search accuracy for many data types and consequently can be of equal, or even greater, benefit to scientists working in the tropics and mid-latitudes. This poster describes a number of tools we have developed to make working with the sphere easier on both sides (client and server) of data search and order systems. Introduction: Historically the use of a lat/lon bounding box on a flat Earth has dominated the spatial search components of data search and order systems for Earth Science data for good reason. The flat Earth paradigm works well in many cases and makes both client and server development a much easier task. On the client side user interfaces that allow the user to draw a lat/lon bounding box on a flat, Cartesian, Earth (the Cylindrical Equidistant projection) are fairly simple to implement because the projection transformations are far easier to work with than any other projection. Even other cylindrical projections, like the Mercator, require some trigonometry to covert screen (x, y) coordinates to (lat, lon). And on the server side defining the spatial coverage of the granules with a lat/lon bounding box minimizes the database footprint and results in a fast, Boolean, search. The geographic area selection interfaces for several large geographic database search and order systems are shown above. On the left are the Data and Information AccessLink ( and the NOAAServer ( interfaces. On the right is the Master Environmental Library ( interface. The flat Earth paradigm dominates such systems and more examples can be found at Unfortunately the most voluminous data is gathered by satellite born sensors circling the Earth and consequently the lat/lon bounding box is often not a good fit. A minimal lat/lon bounding box describing the data coverage area often contains quite a bit of empty space which means search results will often contain a high percentage of false positives. As the number of satellite born sensors increases, and the resolution of those sensors increases, the shear volume of the available data makes false positives in the returned results a serious problem. Scientists do not want to order data only to find a high percentage of it is useless for their purposes because it doesn't actually cover their study area, and data providers do not want to waste resources delivering data that's never going to be used. Fortunately computer technology has kept pace with, or exceeded, satellite technology. These days database size constraints are orders of magnitude larger than just ten years ago, so database footprint isn't as big an issue. Many RDBMS's can now handle spatial searches on the sphere in fairly efficient ways. And just the raw speed of today's computers means that more complex search methods no longer cause an unacceptable performance hit. Spheres: Probably the biggest single obstacle to working with the spherical Earth is the sphere itself. Unlike the Euclidean geometry of the flat Earth paradigm, which most of us learned in Junior High School, the geometry of the sphere is both exotic and complex. Working directly with the sphere entails not only spherical geometry, but spherical trigonometry, which is even worse. Spheres is a Java package written at NSIDC that does spherical trigonometry efficiently and accurately using algorithms based in Cartesian space, thus avoiding most of the trigonometry. Unlike the transformation of the spherical Earth to the Cartesian plane the switch from spherical coordinates to 3-D Cartesian coordinates involves equalities. We’re still working with the sphere (x 2 + y 2 + z 2 = r 2 ) we’ve just changed the coordinate system. JAZ: The JAZPanel (Java Area selection with Zoom) is a module we developed for our Java interfaces to handle user selection of their area of interest. The JAZ project is an effort to make that module easier to implement in other interfaces. We made the module a standalone applet, added javascript hooks so it could interact with an HTML interface, downgraded it to Java1 so it wouldn’t require the plugin, and, ironically, added the ability to draw and display lat/lon bounding boxes so it could be used with legacy systems. The big advantage of JAZ is it is projection aware. JAZ is currently capable of displaying 12 different projections at any resolution and adding another projection to the system is fairly straightforward. In addition to lat/lon bounding boxes JAZ can also be used to define areas using row/col bounding boxes (which are projection dependent) and spherical quadrilaterals (which are projection independent). The hope is that by making JAZ flexible it can be used by legacy systems that depend on the flat Earth paradigm, and ease the transition to a spherical Earth paradigm since the only change required by the interface would be a single configuration parameter. For more information see Mapx: Mapx is NSIDC’s in-house map transformation library. It was originally developed in C over ten years ago, ported to Java about 5 years ago, and revised extensively about 6 months ago to more fully take advantage of the object oriented nature of Java. It was mentioned above that adding a new projection to JAZ is relatively straightforward. This is because JAZ itself doesn’t know anything about map projections. Instead JAZ uses the Mapx package, so adding a new projection to JAZ entails writing a new projection class for Mapx, the guts of which is just three methods. The hope is that because Mapx makes map transforms for a variety of projections just as easy to implement as the transforms for the Cylindrical Equidistant projection, developers with less cartographic expertise will be less inclined to rely exclusively on the flat Earth. For more information see The Spheres package contains methods for doing areal comparison on the sphere so it could be used to write spherical area comparison algorithms for a geographic database server, but both Oracle and Informix now have the capability of handling areal comparisons on the sphere natively, which is sure to give better performance for large geographic databases. The real utility of the spheres package is in assisting with the transition from legacy “flat Earth” databases by helping to generate more accurate metadata to describe the coverage areas, at least for the problematic data types. One of the most problematic data types, satellite orbit and scene data, is also the most voluminous. On a flat Earth satellite scenes or partial orbits have an awkward shape, and defining the coverage of a scene with a lat/lon bounding box can create a lot of empty space which can lead to grossly inaccurate search results. Full orbits are even worse since they commonly cover every latitude and every longitude, but only a small part of the surface of the Earth, so two classes in the Spheres package deserve special attention. The Orbit class can be used to define orbits and obtain information about them. The Orbit class contains a simplified orbit model that does not use the two line elements, which is sufficient for most earth science satellites. Similarly the Scene class can be used to define partial orbits and obtain information about them. While both Oracle and Informix can handle searches on spherical polygons natively those polygon methods break down when the polygon covers more than half the earth in any direction, and a lot of orbital data is stored in half-orbit, full-orbit, or even multi-orbit granules. The best way we have found to spatially search orbital swath data is to use the Backtrack Orbit Search Algorithm (see poster IN23A-1204 ) and the Orbit class of the Spheres package contains an implementation of the backtrack algorithm. Consequently the Spheres package can not only be used to implement the search, it can also be used to generate the metadata the algorithm searches on. For higher resolution instruments it is common to chunk the data into scenes, much smaller than a half orbit, to ensure the granule file size is reasonable, and for those the polygon methods native to the RDBMS are highly efficient. Unfortunately simply converting a legacy lat/lon bounding box into a spherical polygon won’t have any impact on search accuracy if the lat/lon bounding box was grossly inaccurate to begin with. For a more accurate search one needs more accurate metadata. While satellite scenes are not spherical polygons, a spherical polygon is generally a much better fit than a lat/lon bounding box. Indeed, a scene is so nearly a spherical quadrilateral that just using the corner points of the scene to define the quadrilateral is often sufficient. For greater accuracy the Scene class of the Spheres package can be used to convert scenes into spherical n-gons. For more information see: Area selection in the JAZpanel is configurable and the best choice depends on the purpose of the interface. Lat/lon bounding boxes (upper left) are necessary for searching legacy databases that rely on the flat Earth paradigm. Row/column rectangles (upper right) are useful if the intent is to allow the user to choose a subset of a grid. And spherical polygons (lower left) have the virtue of being truly projection independent. The controls (lower right) allow for selection of the grid and zoom level and allow for text input of the corner points. The controls are also configurable to use the native Java, which is highly browser independent, or they can be hidden behind a layer of HTML, which may be more 508 compliant. The Mapx javadoc documentation shows the class structure of the Java version of Mapx and the key three methods that must be written to add a new projection to the package. At right are a number of projections supported by Mapx including: Mollweide, Sinusoidal, Orthographic, Azimuthal Equal-Area, and the ever-popular Cylindrical Equidistant. Determining whether or not two spherical polygons overlap requires either a large amount of trigonometry, or a small amount of algebra, depending on what coordinate system you work in. More information on methods, techniques, and software related to our round planet is available at Ross Swick and Ken Knowles National Snow and Ice Data Center Spatial Tools for a Round Planet Poster IN23A-1204 AGU, Fall 2005

National Snow and Ice Data Center Spatial Tools for a Round Planet Ross S. Swick and Ken Knowles Abstract: For many geophysical disciplines it is sufficient, and often expedient, to treat the Earth as a Cartesian plane, at least for data search and order purposes. Unfortunately the Earth is round and the majority of Earth Science data is being gathered by satellite born sensors circling the Earth in polar orbits. As the number of satellite born sensors increases, and the resolution of those sensors increases, the shear volume of the available data has made the flat Earth paradigm increasingly problematic. Cryospheric Science is one discipline that is ill-served by the flat Earth paradigm so the National Snow and Ice Data Center has been working with the sphere for quite some time. We have found that treating the Earth as a sphere significantly increases spatial search accuracy for many data types and consequently can be of equal, or even greater, benefit to scientists working in the tropics and mid-latitudes. This poster describes a number of tools we have developed to make working with the sphere easier on both sides (client and server) of data search and order systems. Introduction: Historically the use of a lat/lon bounding box on a flat Earth has dominated the spatial search components of data search and order systems for Earth Science data for good reason. The flat Earth paradigm works well in many cases and makes both client and server development a much easier task. On the client side user interfaces that allow the user to draw a lat/lon bounding box on a flat, Cartesian, Earth (the Cylindrical Equidistant projection) are fairly simple to implement because the projection transformations are far easier to work with than any other projection. Even other cylindrical projections, like the Mercator, require some trigonometry to covert screen (x, y) coordinates to (lat, lon). And on the server side defining the spatial coverage of the granules with a lat/lon bounding box minimizes the database footprint and results in a fast, Boolean, search. The geographic area selection interfaces for several large geographic database search and order systems are shown above. On the left are the Data and Information AccessLink ( and the NOAAServer ( interfaces. On the right is the Master Environmental Library ( interface. Unfortunately the most voluminous data is gathered by satellite born sensors circling the Earth and consequently the lat/lon bounding box is often not a good fit. A minimal lat/lon bounding box describing the data coverage area often contains quite a bit of empty space which means search results will often contain a high percentage of false positives. As the number of satellite born sensors increases, and the resolution of those sensors increases, the shear volume of the available data makes false positives in the search a serious problem. Scientists do not want to order data only to find a high percentage of it is useless for their because it doesn't actually cover their study area, and data providers do not want to waste resources delivering data that's never going to get used. Fortunately computer technology has kept pace with, or exceeded, satellite technology. These days database size constraints are orders of magnitude larger than just ten years ago, so database footprint isn't as big an issue. Many RDBMS's can now handle spatial searches on the sphere in fairly efficient ways. And the just the raw speed of today's computers means that more complex search methods no longer cause an unacceptable performance hit. Spheres: Probably the biggest single obstacle to working with the spherical Earth is the sphere itself. Unlike the Euclidean geometry of the flat Earth paradigm, which most of us learned in Junior High School, the geometry of the sphere is both exotic and complex. Working directly with the sphere entails not only spherical geometry, but spherical trigonometry, which is even worse. For example; finding the points where two great circles on the sphere intersect involves solving four equations, one of which is: lon c -> (-ArcCos[ (-((([Sqrt](( b 2 f 2 Cos[lon 1 ] 2 - 2abf 2 Cos[lon 1 ] Cos[lon 2 ] + a 2 f 2 Cos[lon 2 ] 2 - 2bcef Cos[lon 1 ] Cos[lon 3 ] + 2acef Cos[lon 2 ] Cos[lon 3 ] + c 2 e 2 Cos[lon 3 ] 2 + 2bcdf Cos[lon 1 ] Cos[lon 4 ] - 2acdf Cos[lon 2 ] Cos[lon 4 ] - 2c 2 de Cos[lon 3 ] Cos[lon 4 ] + c 2 d 2 Cos[lon 4 ] 2 )))) / (([Sqrt](( b 2 f 2 Cos[lon 1 ] 2 - 2abf 2 Cos[lon 1 ] Cos[lon 2 ] + a 2 f 2 Cos[lon 2 ] 2 - 2bcef Cos[lon 1 ] Cos[lon 3 ] + 2acef Cos[lon 2 ] Cos[lon 3 ] + c 2 e 2 Cos[lon 3 ] 2 + 2bcdf Cos[lon 1 ] Cos[lon 4 ] - 2acdf Cos[lon 2 ] Cos[lon 4 ] - 2c 2 de Cos[lon 3 ] Cos[lon 4 ] + c 2 d 2 Cos[lon 4 ] 2 + b 2 f 2 Sin[lon 1 ] 2 - 2abf 2 Sin[lon 1 ] Sin[lon 2 ] + a 2 f 2 Sin[lon 2 ] 2 - 2bcef Sin[lon 1 ] Sin[lon 3 ] + 2acef Sin[lon 2 ] Sin[lon 3 ] + c 2 e 2 Sin[lon 3 ] 2 + 2bcdf Sin[lon 1 ] Sin[lon 4 ] - 2acdf Sin[lon 2 ] Sin[lon 4 ] - 2c 2 de Sin[lon 3 ] Sin[lon 4 ] + c 2 d 2 Sin[lon 4 ] 2 ))))))])}, This equations is not only heinous, which makes it prone to transcription errors should anyone actually try to code it up, but it also involves and enormous amount of trigonometry and, worse, inverse trigonometry. Even today’s computers are little more than glorified adding machines, as such they are extremely good at arithmetic, and extremely poor at trigonometry. Consequently spherical trigonometry equations like the one above will bog down even the fastest computer. But things become much easier if one switches to 3-D Cartesian space, and unlike the transformation of the spherical Earth to the Euclidean plane the switch from spherical coordinates to 3-D Cartesian coordinates involves equalities. We’re still working with the sphere (x 2 + y 2 + z 2 = r 2 ) we’ve just changed coordinate system. Transforming the (lat, lon) coordinates of the sphere to (x, y, z) coordinates in Cartesian space involves a little trigonometry, but once in Cartesian space virtually everything one could want to know about regions on the sphere can be calculated using simple algebra. Spheres is a Java package written at NSIDC that does spherical trigonometry efficiently and accurately using algorithms based in Cartesian space. For example: determining if two spherical polygons overlap involves determining if any of the great circle arcs cross, determining if any of the great circle arcs cross involves determining where the parent great circles cross, and determining where two great circles cross means solving the following: x = (-by - cz) / a y = z((dc-fa)/(ea-db)) Let h = (dc-fa)/(ea-db) so y = hz x = z((-bh - c)/a) Let g = ((-bh - c)/a) so x = gz z = +- sqrt(r2/(g2+ h2 + 1)) JAZ: The JAZPanel (Java Area selection with Zoom) is a module we developed for our Java interfaces to handle user selection of their area of interest. The JAZ project is an effort to make that module easier to implement in other interfaces. We made the module a standalone applet, added javascript hooks so it could interact with an HTML interface, downgraded it to Java1 so it wouldn’t require the plugin, and, ironically, added the ability to draw and display lat/lon bounding boxes so it could be used with legacy systems. The big advantage of JAZ is it is projection aware. JAZ is currently capable of displaying 12 different projections at any resolution and adding another projection to the system is fairly straightforward. In addition to lat/lon bounding boxes JAZ can also be used to define areas using row/col bounding boxes (which are projection dependent) and spherical quadrilaterals (which are projection independent). The hope is that by making JAZ flexible it can be used by legacy systems that depend on the flat Earth paradigm, and ease the transition to a spherical Earth paradigm since the only change required by the interface would be a single configuration parameter. Mapx: Mapx is NSIDC’s in-house map transformation library. It was originally developed in C over ten years ago, ported to Java about 5 years ago, and revised extensively about 6 months ago to more fully take advantage of the object oriented nature of Java. It was mentioned above that adding a new projection to JAZ is relatively straightforward. This is because JAZ itself doesn’t know anything about map projections. Instead JAZ uses the Mapx package, so adding a new projection to JAZ entails writing a new projection class for Mapx, the guts of which is just three methods. The hope is that because Mapx makes the map transforms for a variety of projections just as easy to implement as the transforms for the Cylindrical Equidistant projection, developers with less cartographic expertise will be less inclined to rely exclusively on the flat Earth. For more information see The Spheres package currently contains methods for doing areal comparison on the sphere so it could be used to write spherical area comparison algorithms for a geographic database server, but both Oracle and Informix now have the capability of handling areal comparisons on the sphere natively, which is sure to give better performance for large geographic databases. The real utility of the spheres package is in assisting with the transition from a legacy “flat Earth” databases by helping to generate more accurate metadata to describe the coverage areas, at least for the problematic data types. One of the most problematic data types, satellite orbit and scene data, is also the most voluminous. On a flat Earth satellite scenes or partial orbits have an awkward shape, and defining the coverage of a scene with a lat/lon bounding box can create a lot of empty space which can lead to grossly inaccurate search results. Full orbits are even worse since they commonly cover every latitude and every longitude, but only a small part of the surface of the Earth, so two classes in the Spheres package deserve special attention. The Orbit class can be used to define orbits and obtain information about them. The Orbit class contains a simplified orbit model that does not use the two line elements but is sufficient for most earth science satellites. Similarly the Scene class can be used to define partial orbits and obtain information about them. While both Oracle and Informix can handle searches on spherical polygons natively those polygon methods break down when the polygon covers more than half the earth in any direction, and a lot of orbital data is stored in half- orbit, full-orbit, or even multi-orbit granules. The best way we have found to spatially search orbital swath data is to use the Backtrack Orbit Search Algorithm (see poster OS51B-0165) and the Orbit class of the Spheres package contains an implementation of the backtrack algorithm. Consequently the Spheres package can not only be used to implement the search, it can also be used to generate the metadata the algorithm searches on. (picture of a full orbit, and scenewith llBox ) For higher resolution instruments it is common to chunk the data into scenes that are much smaller than a half orbit to ensure the data file size is reasonable, and for those the polygon methods native to the RDBMS are highly efficient. Unfortunately simply converting a legacy lat/lon bounding box into a spherical polygon won’t have any impact on search accuracy if the lat/lon bounding box was grossly inaccurate to begin with. For a more accurate search one needs more accurate metadata. While satellite scenes are not spherical polygons, a spherical polygon is generally a much better fit than a lat/lon bounding box. Indeed, a scene is so nearly a spherical quadrilateral that just using the corner points of the scene to define the quadrilateral is often sufficient. For greater accuracy the Scene class of the Spheres package can be used to convert scenes into a spherical n-gons. For more information on the Spheres package see: For more information on tools, modules, and libraries available from NSIDC see: The Mapx javadoc documentaion shows the class structure of the Java version of Mapx.