Georeferencing Images with EML2
Dan Higgins
higgins at nceas.ucsb.edu
Mon Jul 21 11:46:02 PDT 2003
Hi All,
I put some thoughts on how to create a simple georeferenced raster
description in EML2 in the memo below, along with a sample EML2
document. Comments, questions, corrections, etc. always welcome.
Dan
--------
Dan Higgins
July 21, 2003
Georeferencing Images with EML2
As part of an effort to build an EML2 to FGDC/NBII translator, I came up
against the question of just how one would describe a georeferenced
image using EML2. There seem to be several alternative possibilites
which I will outline here.
Consider first a specific example. Assume that we have a simple JPEG
image of a Mercator projection of a world map. How would one describe
this image in EML2 and reference it to a specific geographic location?
Almost all the work at NCEAS has used 'dataTable' entities. This
includes the insertion of images in datasets even though the 'dataTable'
entity is primarily designed for use with tabular data. To insert an
image, one inserts information in the 'physical' subtree which describes
an image format. For example, one can set
'physical/dataFormat/externallyDefinedFormat/formatName' to a value of
'JPEG' or "GIF'. Alternatvely, one can describe arbitrary raster data in
'physical/dataFormat/externallyDefinedFormat/binaryRasterFormat'. But
then how is this raster image data georeferenced? And what do other
required fields (like 'attributes') mean?
One could use the
'dataTable/coverage/geographicCoverage/boundingCoordinates' fields to
supply georeferencing coordinates for the image. This would seem to be a
reasonable use of the 'coverage' subtree that is within the 'dataTable'
entity, since there is a higher level 'coverage' node under 'dataset'
that could be used for the overall package. However, it is not clear (to
me) just what 'attribute' value (one is required) would be attached to
such a dataset.
But the 'spatialRaster' entity is certainly a more appropriately named
place for storing georeferenced raster metadata. Now, the
'spatialRaster' entity has 'physical' and 'coverage' subtrees just like
'dataTable'. But it also contains a number of required fields
specifically for spatial raster metadata. For example,
'spatialRaster/spatialReference' is a required subtree. One can fill in
the geographic coordinate fields of 'datum', 'spheroid',
'primeMeridian', and 'unit' under 'spatialReference', or simply enter a
'horizCoordSysName' from the spatial reference dictionary
("eml-spatialReferenceDictionary.xml"). [Understanding all the
information in this dictionary is a bit formidable due to the large
number of items; for the simple example being considered here, there is
an entry for a Mercator coordinate system. The entry is as follows:
<horizCoordSysDef name="World_Mercator">
<projCoordSys>
<geogCoordSys name="GCS_WGS_1984">
<datum name="D_WGS_1984"/>
<spheroid name="WGS_1984" semiAxisMajor="6378137"
denomFlatRatio="298.257223563"/>
<primeMeridian name="Greenwich" longitude="0"/>
<unit name="degree"/>
</geogCoordSys>
<projection name="Mercator">
<parameter name="False_Easting" value="0"/>
<parameter name="False_Northing" value="0"/>
<parameter name="Central_Meridian" value="0"/>
<parameter name="Standard_Parallel_1" value="0"/>
<unit name="meter"/>
</projection>
</projCoordSys>
</horizCoordSysDef>
The 'horizCoordSysDef' defines a coordinate system. The optional
'georeferenceInfo' subtree then supplies information on how to position
the raster grid within that coordinate system. This can be done in
several ways, with the simplest being 1 to 4 'cornerPoint' fields. For
example, one can define the upperLeft conrner point of the raster in
terms of x- and y-Coordinates.
Now, one can define the 4 corners of a rectangular raster (although only
the 2 diagonal points are really needed). But 'spatialRaster' also has
required elements called 'cellSizeXDirection' and 'cellSizeYDirection'.
I interpret these field values to represent pixel sizes (in degrees
latitude and longitude) for our example. Thus, the 'cellSizeXDirection'
for a world map is 360/(number of pixels per row) when the image is 360
degrees wide. Similarly, 'cellSizeYDirection' = 180/(number of pixels
per column). Thus, if one defines 'cornerPoint' information for the
upper left corner of the image and the cellSize values, the image's
geospatial position is completely specified.
It thus appears that there are more that sufficient fields as part of
the 'spatialRaster' entity to define at least simple georeferenced
images. In fact, one has to wonder why 'attributeList' is required here
with at least one 'attribute' and if one defined
'coverage/geographicCoverage/boundingCoordinates' values under this
entity, just what would these boundingCoordinates mean? (i.e. would they
mean the same as 'cornerPoint' data? if so and both appear, do they need
to be consistent? which has preference?)
----
Example EML2 document using spatialRaster Entity
----
<?xml version="1.0"?>
<eml:eml xmlns:stmml="http://www.xml-cml.org/schema/stmml"
xmlns:ds="eml://ecoinformatics.org/dataset-2.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:eml="eml://ecoinformatics.org/eml-2.0.0"
xsi:schemaLocation="eml://ecoinformatics.org/eml-2.0.0 eml.xsd"
system="knb" packageId="meredith.5.3">
<dataset scope="document" system="" id="">
<title>Georeferenced Spatial Raster</title>
<creator scope="document" system="" id="">
<individualName>
<salutation>Mr</salutation>
<givenName>Dan</givenName>
<surName>Higgins</surName>
</individualName>
<address scope="document" system="" id="">
<deliveryPoint>735 State Street</deliveryPoint>
<city>Santa Barbara</city>
<administrativeArea>CA</administrativeArea>
<postalCode>93105</postalCode>
<country>USA</country>
</address>
<electronicMailAddress>higgins at nceas.ucsb.edu</electronicMailAddress>
</creator>
<contact scope="document" system="" id="">
<individualName>
<surName>higgins</surName>
</individualName>
</contact>
<spatialRaster scope="document" system="" id="">
<entityName>Spatial Raster test entity</entityName>
<physical scope="document" system="" id="">
<objectName>world_20k.jpg</objectName>
<size unit="bytes">28173</size>
<dataFormat>
<textFormat>
<attributeOrientation>column</attributeOrientation>
<simpleDelimited>
<fieldDelimiter>N/A</fieldDelimiter>
</simpleDelimited>
</textFormat>
</dataFormat>
</physical>
<attributeList id="">
<attribute scope="document" system="" id="">
<attributeName>Raster
Description</attributeName>
<attributeDefinition>This is a simple raster
image(map) of the entire earth</attributeDefinition>
<measurementScale>
<nominal>
<nonNumericDomain id="">
<textDomain>
<definition>any text</definition>
</textDomain>
</nonNumericDomain>
</nominal>
</measurementScale>
</attribute>
</attributeList>
<spatialReference scope="document" system="" id="">
<horizCoordSysName>World_Mercator</horizCoordSysName>
</spatialReference>
<georeferenceInfo>
<cornerPoint>
<xCoordinate>-180.0</xCoordinate>
<yCoordinate>90.0</yCoordinate>
<pointInPixel>upperLeft</pointInPixel>
<corner>Upper Left</corner>
</cornerPoint>
</georeferenceInfo>
<horizontalAccuracy>
<accuracyReport>unknown, but consider the number of
pixels and the region being represented</accuracyReport>
</horizontalAccuracy>
<verticalAccuracy>
<accuracyReport>Not applicable</accuracyReport>
</verticalAccuracy>
<cellSizeXDirection>0.4806 (360 deg / 749
columns)</cellSizeXDirection>
<cellSizeYDirection>2.078 (180 deg /. 374
rows)</cellSizeYDirection>
<numberOfBands>1</numberOfBands>
<rasterOrigin>Upper Left</rasterOrigin>
<rows>374</rows>
<columns>749</columns>
<verticals>
</verticals>
<cellGeometry>pixel</cellGeometry>
</spatialRaster>
</dataset>
</eml:eml>
--
*******************************************************************
Dan Higgins higgins at nceas.ucsb.edu
http://www.nceas.ucsb.edu/ Ph: 805-892-2531
National Center for Ecological Analysis and Synthesis (NCEAS)
735 State Street - Room 205
Santa Barbara, CA 93195
*******************************************************************
More information about the Eml-dev
mailing list