Georeferencing Images with EML2
Peter McCartney
peter.mccartney at asu.edu
Tue Jul 29 15:23:34 PDT 2003
I'll just address the questions that you didnt answer yourself :)
in any gridded data file there is one observation value represented for each
cell (Lets not worry about multiple bands for now). the value of the cell is
decribed exactly like any other observation. i origially defined a
<cellValue> attribute of type Attribute, but then decided it was simpler to
just keep the same structure as other entities and just use the attribute.
so the entry for attribute is the description of your cell value - in a DEM
it will be something like elevation above sea level, interval scale, meter
units, domain of 0 to 8500, etc.
in banded images, there are multiple observations but they all share the
same properties other than their domain which is described in the band
information section. its a bit awkward , but its also closer to the way ISO
and FGDC do things.
I originally intended raster to contain one attribute, not an attribute
list. However, in retrospect, i see it as potentially handy for describing
cubes where there are multiple observations per cell and the data types are
not all the same (like a GARP dataset).
Corner points are not the same as bounding coordinates. they serve very
different purposes. the former is to register a grid to a coordinate system,
the latter is to define the data coverage (in GEOGRAPHIC coordinates). as
you noted, the corner point requires identification of where within the
named cell, the actual point of reference is located.
providing only one cornerpoint is adequate to reference a grid only if the
grid is rectified to the coordinate system. others are needed if the grids
orientation does not match the coordinate systems axes.
CellSizeXDirection is the size of the cell in map units. NOT the number of
columns in the grid.
Most of what is in here is a fusion of FGDC and the more extensive ISO. It
looks like a lot, but its all relevant depending on the particular dataset.
-----Original Message-----
From: Dan Higgins [mailto:higgins at nceas.ucsb.edu]
Sent: Monday, July 21, 2003 11:46 AM
To: Eml-Dev (eml-dev at ecoinformatics.org)
Subject: Georeferencing Images with EML2
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
*******************************************************************
_______________________________________________
eml-dev mailing list
eml-dev at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/eml-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030729/7764df60/attachment.htm
More information about the Eml-dev
mailing list