This wiki page describes a simple observation catalog (ObsCatalog) and an initial google earth visualization product which is created by transforming the input data to KML.

See also ObsKML , XeniaPackage

Discussion

UPDATE October 16, 2006 - Please see the additional notes here regarding how this kml product can also be utilized with an xml supplied record instead of csv.

I recently(June 2006) attended a 2 day conference at WHOI organized by the Coastal Services Center to try and organize a very simple ocean observing system catalog of existing or planned observation types. This resulted in the following documentation which is some general discussion items and a spreadsheet of the catalog record content we are trying to capture.

I've moved forward with developing this out some. The required spreadsheet elements are listed below and a corresponding owl file with codelist lookups is shown here.

version
operator
regionalAssociation
modifiedDate
localPlatformName
longitude
latitude
z
zPlaneOfReference
westboundLongitude
southboundLatitude
eastboundLongitude
northboundLatitude
plannedStartDate
plannedEndDate
operatorURL
platformURL
dataURL
observationName
observationStatus
comments

For now, I'm representing this record format using a CSV(Comma Separated Value) file.

Usage

The following scripts allow a user to use their browser and reference a php webpage ( http://nautilus.baruch.sc.edu/gearth/catalog/csv2kml.php ) with the supplied http argument of the CSV catalog record input file (csv_url argument, example file listed here) which returns a KML file (example file listed here)) for visualization in Google Earth ( http://earth.google.com ).

For example the following link
http://nautilus.baruch.sc.edu/gearth/catalog/csv2kml.php?csv_url=http://carocoops.org/gearth/catalog/perl/catalog_in.csv

will return the following kml file and it's visualization

Note the following details in how the catalog information is presented in Google Earth(GE).

Basic GE usage

GE data layers are organized using a select/expand/collapse folder convention in the left hand sidebar labeled 'Places'. To expand/collapse a folder click on the associated folder arrow to the left hand side of the folder label. To select/deselect an entire folders contents or individual folder items use the checkbox to the left hand side of the folder label. To see the information available at a placemark, click on the placemark or it's label in the sidebar.

Catalog specific usage

The observation catalog information is presented via two lists/folders.

The first folder is by operator which lists all platforms by their associated operator. Each platform when selected will display all observations and associated links available for that platform.

The second folder is by observation which lists the observation types supplied earlier in the input files. When an observation type is selected, platforms which contain that observation will be displayed. Selecting an individual platform only shows the links associated with that particular selected observation.

Placemark icons and area coverages use the following color coding:
green = Operational
red = Offline
yellow = Planned

For the by operator list, the platform status(Operational,Offline,Planned) assumes the same status as the last alphabetically listed observation type.

For the by observation list it's advised to only select one observation at a time as most observations overlap at the same platform.

CSV catalog record input file recommendations

• The first field must be '_1.0' which is the initial version for this record format. If a record starts with anything else it will be ignored.

• Since the input file is CSV(Comma Separated Value), don't use commas in the 'comments' field or anywhere else unintentionally.

• Try to stay within the specified codelists for the field values listed here until a 'blessed' version is available.

• A coverage area will be created whenever the 'bounding' arguments(westboundLongitude, southboundLatitude, eastboundLongitude, northboundLatitude) are supplied. If you don't require a coverage area for the observation leave these fields empty. Note also that coverage areas don't have any associated description or links - these should be described with the originating platform/data links.

• For the some of the sample records I've listed the platformURL and dataURL as the same, but it's better to be more specific with the dataURL if applicable which is listed as the observation type link within the visualization.

Community usage

This type of tool allows several methods for aggregation and display:

• Users might use the tool for a quick visual validation of their own csv files.
• Users might append several supplied csv files together to create one larger kml file.
• Users might append sevaral supplied kml files together to create one larger kml file.
• Note that kml files can be zipped(compressed) to kmz files

This tool is also observation domain non-specific in that none of the underlying codelists/functionality are hardcoded or validated to the ocean observation domain. Someone in the terrestrial or other domain could supply similar csv files and an observation types list to produce a kml visualization.

Note also that using the tool as a general discovery mechanism for operators/observations and their associated links that it would be preferable to keep the usage of observation types very general, not necessarily requiring a fixed or narrow definition for each observation type.

Note also that this solution does not resolve possible duplications of supplied platforms or observations.

Technical flow

The [[http://nautilus.baruch.sc.edu/twiki_dmcc/pub/Main/ObsCatalog/csv2kml.php.txt][php page] supplies the http argument for the source csv file to the underlying perl script. The perl script transforms the csv files into the returned kml file.

Also used by the script are the following png image files red icon, green icon and yellow icon.

Why KML ?

My primary reason for focusing on Google Earth for an initial visualization (besides that it's easy to do and looks great) is that Google Earth is driven by KML (Keyhole Markup Language http://earth.google.com/kml ) which is an XML format(Hooray!). If folks prefer something else they can use XML tools (XPath, XSLT,etc) to remap the KML output to something of their preference or use the source catalog records.

The secondary reason is that Google is in the process of better supporting KML within their google maps service (see the following links
http://maps.google.com/support/bin/answer.py?answer=41136&topic=1475
http://maps.google.com/maps?q=http://kml.lover.googlepages.com/my-vacation-photos.kml
http://www.juiceanalytics.com/weblog/?p=200 )
which means that it may eventually be possible to display most of the same 2D KML described data within a generic browser interface.

Long-term I'm hoping to supply more KML and less effort maintaining my own specific GIS portals and technology. Users can select and share their KML data layers/collections as needed.

Possible development

Placemark Icons

I've created some basic colored circle icons which are png files with a transparency layer. No problem to substitute a different image or add other placemark type icons as needed.

Polygon area coverage

The current bounding box for observation coverage areas is actually described as a polygon in the kml. The input file could use say tab separated fields and allow the coverage area to be more detailed description as a polygon area.

<Placemark>
  <name>$operator\_$localPlatformName\_$observation\_coverage_area</name>
  <styleUrl>#$styleUrl</styleUrl>
<Polygon>
   <outerBoundaryIs>
      <LinearRing>
        <coordinates>$westboundLongitude,$southboundLatitude,0,$westboundLongitude,$northboundLatitude,0,$eastboundLongitude,$northboundLatitude,0,$eastboundLongitude,$southboundLatitude,0</coordinates>
      </LinearRing>
   </outerBoundaryIs>
</Polygon>
</Placemark>

Web form tool for add/edit catalog records

While the existing CSV based input file record format is fairly simple, it would be fairly easy to develop a web form based tool to add/edit these same types of records. An excel based forms tool has also been suggested for development by Coastal Services Center.

XML based catalog records

The existing CSV based file could also be represented as an xml document with a reference xml schema and controlled vocabulary URI references for validation. I've been working with Luis Bermudez at http://marinemetadata.org and using the Protege ontology editor to develop something more along these lines with the latest developed valid owl document here

-- JeremyCothran - 04 Jul 2006
to top