From higgins at nceas.ucsb.edu  Mon Jul  7 13:31:44 2003
From: higgins at nceas.ucsb.edu (Dan Higgins)
Date: Mon, 07 Jul 2003 13:31:44 -0700
Subject: [Fwd: Questions concerning spatialRaster entities?]
Message-ID: <3F09D8B0.8060703@nceas.ucsb.edu>

Hi Scott,

    Matt Jones suggested that I might contact you directly with some 
questions that I have about the spatial modules in EML2. In particular, 
have you created any example EML2 documents that use the spatialVector 
or spatialRaster modules? If so, could I get copies of some of these as 
examples?

    I had a number of other detailed questions which I had previously 
sent out to the eml-dev group which I am reproducing here (since I 
didn't get any responses :-) ).

    Thanks for whatever help you may be able to provide.

Dan

-- 
*******************************************************************
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
*******************************************************************

-------------- next part --------------
An embedded message was scrubbed...
From: Dan Higgins <higgins at nceas.ucsb.edu>
Subject: Questions concerning spatialRaster entities?
Date: Fri, 13 Jun 2003 13:26:51 -0700
Size: 7738
Url: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030707/f06663b3/QuestionsconcerningspatialRasterentities.eml

From peter.mccartney at asu.edu  Mon Jul  7 18:12:05 2003
From: peter.mccartney at asu.edu (Peter McCartney)
Date: Mon, 07 Jul 2003 18:12:05 -0700
Subject: [Fwd: Questions concerning spatialRaster entities?]
Message-ID: <C070FF48FA66124C8E4BBB5AF901A90216B17A@ex2.asurite.ad.asu.edu>

Hi dan. We have a number of spatial files in EML in our SEINet catalog.
http://seinet.asu.edu. You may find it easier to browse the metadata through
one our GIS apps, the eAtlas http://cochise.asu.edu/eatlas which letsyou see
the list of source files used for a map and then click to view the metadata
from SEINet.

I do have to admit thought that many of these still need cleaning and are
not really fleshing out all of the elements for spatial raster and spatial
vector. Ive asked Radha to identify the ones she feels are complete and I
wll let you know which ones she suggest to look at.

Peter McCartney (peter.mccartney at asu.edu)
Center for Environmental-Studies
Arizona State University
 


-----Original Message-----
From: Dan Higgins [mailto:higgins at nceas.ucsb.edu] 
Sent: Monday, July 07, 2003 1:32 PM
To: Scott Chapal
Cc: Eml-Dev (eml-dev at ecoinformatics.org)
Subject: [Fwd: Questions concerning spatialRaster entities?]


Hi Scott,

    Matt Jones suggested that I might contact you directly with some 
questions that I have about the spatial modules in EML2. In particular, 
have you created any example EML2 documents that use the spatialVector 
or spatialRaster modules? If so, could I get copies of some of these as 
examples?

    I had a number of other detailed questions which I had previously 
sent out to the eml-dev group which I am reproducing here (since I 
didn't get any responses :-) ).

    Thanks for whatever help you may be able to provide.

Dan

-- 
*******************************************************************
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
*******************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030707/3d2c3df3/attachment.htm

From higgins at nceas.ucsb.edu  Tue Jul  8 12:53:35 2003
From: higgins at nceas.ucsb.edu (Dan Higgins)
Date: Tue, 08 Jul 2003 12:53:35 -0700
Subject: [Fwd: Questions concerning spatialRaster entities?]
In-Reply-To: <C070FF48FA66124C8E4BBB5AF901A90216B17A@ex2.asurite.ad.asu.edu>
References: <C070FF48FA66124C8E4BBB5AF901A90216B17A@ex2.asurite.ad.asu.edu>
Message-ID: <3F0B213F.3090105@nceas.ucsb.edu>

Peter,
    Thanks for the references. I can see spatial metadata for some of 
the data on the seinet link, but it is only in html. Is there a way to 
get the actual eml xml file? (Am I missing something?)

Dan

Peter McCartney wrote:

> Hi dan. We have a number of spatial files in EML in our SEINet 
> catalog. http://seinet.asu.edu. You may find it easier to browse the 
> metadata through one our GIS apps, the eAtlas 
> http://cochise.asu.edu/eatlas which letsyou see the list of source 
> files used for a map and then click to view the metadata from SEINet.
>
> I do have to admit thought that many of these still need cleaning and 
> are not really fleshing out all of the elements for spatial raster and 
> spatial vector. Ive asked Radha to identify the ones she feels are 
> complete and I wll let you know which ones she suggest to look at.
>
> Peter McCartney (peter.mccartney at asu.edu)
> Center for Environmental-Studies
> Arizona State University
>  
>
>
> -----Original Message-----
> From: Dan Higgins [mailto:higgins at nceas.ucsb.edu]
> Sent: Monday, July 07, 2003 1:32 PM
> To: Scott Chapal
> Cc: Eml-Dev (eml-dev at ecoinformatics.org)
> Subject: [Fwd: Questions concerning spatialRaster entities?]
>
>
> Hi Scott,
>
>     Matt Jones suggested that I might contact you directly with some
> questions that I have about the spatial modules in EML2. In particular,
> have you created any example EML2 documents that use the spatialVector
> or spatialRaster modules? If so, could I get copies of some of these as
> examples?
>
>     I had a number of other detailed questions which I had previously
> sent out to the eml-dev group which I am reproducing here (since I
> didn't get any responses :-) ).
>
>     Thanks for whatever help you may be able to provide.
>
> Dan
>
> -- 
> *******************************************************************
> 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
> *******************************************************************
>


-- 
*******************************************************************
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
*******************************************************************




From scott.chapal at jonesctr.org  Tue Jul  8 14:12:37 2003
From: scott.chapal at jonesctr.org (Scott Chapal)
Date: 08 Jul 2003 17:12:37 -0400
Subject: [Fwd: Questions concerning spatialRaster entities?]
In-Reply-To: <3F09D8B0.8060703@nceas.ucsb.edu>
References: <3F09D8B0.8060703@nceas.ucsb.edu>
Message-ID: <qkr850en96.fsf@mail.jonesctr.org>

Dan,

I have to agree that examples of EML-documented spatial data would be
really helpful.  I too, have been hoping to see a *complete* example,
especially since your initial email came through eml-dev last month.

We started to test the spatial modules shortly after EML 2 was
released, but were not able to make much progress with just the EML
documentation as our guide.  In fact, the ambiguities you report in
your email below remind me of some of the questions we had.  (I'll
admit to less than hurculean effort in trying to interpret the EML
spatial module docs though).

I would have recommended that you contact Peter, since he is ahead of
the pack in terms of implementation (and was the design influence of
most consequence for the spatial components)...but he already
responded.

For me, like the rest of EML, it isn't fully understandable until I
see an actual instance document.

Sorry for that non-help.

-Scott

BTW, I learned last summer that lack of response on eml-dev doesn't
mean lack of interest.

Dan Higgins <higgins at nceas.ucsb.edu> writes:

> Hi Scott,
> 
>     Matt Jones suggested that I might contact you directly with some
> questions that I have about the spatial modules in EML2. In
> particular, have you created any example EML2 documents that use the
> spatialVector or spatialRaster modules? If so, could I get copies of
> some of these as examples?
> 
> 
>     I had a number of other detailed questions which I had previously
> sent out to the eml-dev group which I am reproducing here (since I
> didn't get any responses :-) ).
> 
> 
>     Thanks for whatever help you may be able to provide.
> 
> Dan
> 
> -- 
> *******************************************************************
> 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
> *******************************************************************
> 
> From: Dan Higgins <higgins at nceas.ucsb.edu>
> Subject: Questions concerning spatialRaster entities?
> To: "Eml-Dev (eml-dev at ecoinformatics.org)" <eml-dev at ecoinformatics.org>
> Date: Fri, 13 Jun 2003 13:26:51 -0700
> Reply-To: higgins at nceas.ucsb.edu
> Organization: NCEAS
> 
> Hi All,
> 
> I have come up against a number of questions about EML (and FGDC) for
> Spatial Data in my attempt to built an XSLT system for converting EML2
> to NBII/FGDC. Most, if not all, of these questions are probably due to
> my own ignorance regarding the handling of spatia data. I thus solicit
> comments and examples from anyone who may have the time and energy to
> respond.
> 
> 
> I would really like to see some examples of EML2 documents which
> describe spatial data sets. In particular, I would like to see an
> example that has a georeferenced spatial image (i.e. a spationRaster
> EML2 entity). And it would be very helpful if someone had an FGDC
> metafile for the same image. Does anyone have such examples? Dan
> 
> 
> ----
> 
> Questions about EML (and FGDC) for Spatial Data     Let me be more
> specific about some questions. Assume that I want to create metadata
> for a scanned image (a photo from a satellite or aircraft) and I have
> the georeferenced bounds of the scan in latitude and
> longitude. (Assume a single such image for simplicity.)
> 
> 
> It seems that the spatialRaster entity branch of the EML2 tree is
> where this image would be described. The entities 'rows' and 'columns'
> are the obvious place for the number of pixels in the x- and y-
> directions. 'rasterOrigin' (e.g. with a value like 'upperLeft') is
> also obviously needed.
> 
> 
> Now, if one sets the 'cellSizeXDirection' and 'cellSizeYDirection' to
> some numeric value "expressed in the units declared in the
> spatialReference module" (from EML documentation), I would assume that
> the numeric value is the pixel size in units of lat/long. (The
> 'cellGeometry' attibute supplies me with some more info on the pixel.) 
> There does seem to be an assumption here that all pixels are the same
> size.) But where does one actual set the units in EML2? Where does one
> say that the values are latitude and longitude? My thought is that we
> must set the unit in the attributeList subtree, since there are
> detailed nodes for setting the measurementScales and units there? We
> map attributes to columns in a table in the datatable entity, assuming
> the order of the attributes is the order they appear in a table. How
> do we do it in spatialRaster (x, y, z?). [I now notice that the eml
> documentation does say the unit is defined in the 'spatialReference'
> module, not in the 'attributeList'. Where do we put this info? What if
> input conflicts?]
> 
> 
> But I notice that there is an optional element in spatialRaster called
> 'georeferenceInfo'. This element allows one to set the x and y
> coordinates of corner points of a raster. I can see that this
> information is needed if one assumes that the cell size information is
> relative to the declared rasterOrigin (e.g. the cellSizeXDirection
> might be in km. X-distance from the origin is the pixel row count
> times the cellSizeXDirection.) But the units used to define the
> georeferenceInfo corners are not neccesarily the same as those used
> for cellSize (or are they?). In fact, according to thw EML
> documentation, the units are those defined "on the coordinate system
> defined in the spatial reference module".
> 
> 
> Now, the geogCoordSys element in the spatialReference element does
> have element called 'unit'. A look at the spatialReferenceDictionary'
> shows that this element typically has a value of 'degree' but
> sometimes something like 'Foot_US' or 'meter'. Shouldn't this unit be
> treated the same way as the unit for attributes with a link to the
> eml-unitDictionary? (Currently is just a string.)
> 
> 
> Also, I see that the spatialReferenceDictionary contains a large
> collection of named horizontalCoordinateSystems. I don't have a clue
> as to which one I should pick if I just want to define a georeferenced
> image in terms of lat/long.???
> 
> 
> But wait ! I also notice that spatialRaster, like all eml entities,
> has a coverage subtree, one element of which is geographicCoverage.
> This element has required bounding coordinates specified to be in
> lat/long. 'coverage' is optional in spatialRaster but spatialReference
> is required. geographicCoverage could be used to specify the
> boundingBox for the image, or is it meant to be used for something
> else inside the spatial entity elements? And if it is used, is the
> georeferenceInfo element needed?      Now consider briefly the
> NBII/FGDC standard. Where would information about a georeferenced
> image go? Well, under the 'Identification Information' section, there
> is a Spatial Domain element (spdom - 1.5) that has bounding
> coordinates in lat/long degrees. This seems to correspond most closely
> to the geographicCoverage element in EML. Raster data like rowCount
> and columnCount would seem to go under the 'Raster Object Information'
> element (3.4). Spatial Reference Information is in Section 4 of FGDC,
> but I cannot find an equivalent of eml's 'georeferencedInfo' element
> that explictly defines cornerPoints for a raster? [But I can just
> divide the difference between the right and left bounds by the number
> of pixels in a row to get the pixel size in degrees.]
> 
> 
> -- 
> *******************************************************************
> 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
> ----------
> 

-- 
\SEC


From brooke at nceas.ucsb.edu  Thu Jul 10 09:22:09 2003
From: brooke at nceas.ucsb.edu (Matthew Brooke)
Date: Thu, 10 Jul 2003 09:22:09 -0700
Subject: Jalama Project - Alpha Software Release for Review by Data-Managers and Developers
Message-ID: <A79E7AA6-B2F2-11D7-BBAC-000393565108@nceas.ucsb.edu>

The Jalama project (http://jalama.ecoinformatics.org) is pleased to 
announce its first software release (0.1alpha1) for review by 
data-managers and developers.  This release is a proof-of-concept in 
creating user-interfaces that are described in a declarative XML syntax 
(XUL) and rendered from within a Java desktop or handheld application 
(such as future versions of Morpho).

This alpha release displays a simple XUL wizard, which guides the user 
through the steps necessary to create a simple EML dataset document 
(intended to be compliant with the EML 2.0.0 schema - see 
http://knb.ecoinformatics.org/software/eml/).  As such, it may be 
useful to data managers for creation of simple EML documents, but we 
would reiterate that this is an alpha release, and there will be issues 
and bugs that have not yet been addressed.

Binaries are available for Windows 2000/XP, Mac OS X 10.2.x and Linux 
(RedHat 7.2 to 9.0) - see the software download page 
(http://jalama.ecoinformatics.org/software/index.html),  which also 
contains a downloadable compressed archive of the source files.

We would welcome any input or suggestions (email jalama-dev at 
ecoinformatics.org), most notably:

1) Installation issues for the various target operating systems
2) Compatibility with (i.e. the the ability to run on) the various 
target operating systems
3) Validity of output EML (which may be checked using the online 
validation service at 
http://knb.ecoinformatics.org/emlparser/index.html). If reporting 
non-valid EML documents, please provide a copy of the EML output if 
possible.
4) Feedback on usability of various widgets (such as lists, or radio 
button choices. Note there are known issues with radio buttons not 
displaying the "selected" mode, although they still function correctly)

* Please consult the README file for a list of known issues before 
reporting bugs *

The long-term goal of the Jalama project is to create a flexible, easy 
to use system for developing metadata and data entry forms for use in 
lab and field environments for ecology. The system will use a 
metadata-driven approach to form generation, and software products from 
the project will target both desktop and handheld computer.  These 
applications will simultaneously enable researchers to provide critical 
structured metadata in order for their work to participate in a 
distributed "Knowledge Network for Biocomplexity" 
(http://knb.ecoinformatics.org).

The Jalama Project (pronounced "hah-LAH-mah") is managed through the 
Marine Science Institute at the University of California, Santa 
Barbara.  It is a collaboration between the National Center for 
Ecological Analysis and Synthesis (NCEAS - http://www.nceas.ucsb.edu) 
and the Partnership for Interdisciplinary Studies of Coastal Oceans 
(PISCO - http://www.piscoweb.org).  However, products resulting from 
this project are released as open source, and further collaborations 
and contributions are welcome.



-------------------------------------------
Matthew Brooke
National Center for Ecological Analysis and Synthesis
735 State Street, Suite 300
Santa Barbara, CA  93101-3351
Phone:  805-892-2503
FAX: 805-892-2510
http://www.nceas.ucsb.edu



From berkley at nceas.ucsb.edu  Thu Jul 17 09:01:16 2003
From: berkley at nceas.ucsb.edu (Chad Berkley)
Date: Thu, 17 Jul 2003 09:01:16 -0700
Subject: new IRC server
Message-ID: <3F16C84C.70603@nceas.ucsb.edu>

Hi,

We have installed a new IRC server.  This new server has no IP address 
restrictions on it, so anyone can connect at anytime without us having 
to authenticate you.  We have changed the DNS record so that 
irc.ecoinformatics.org is now pointed at the new server, however it may 
take up to 24 hours for the DNS information to propegate out to all of 
the nodes.  We will leave the old server up for a day or two.

Within 24 hours, please disconnect yourself from the irc server and try 
reconnecting.  Make sure you are connecting to irc.ecoinformatics.org 
and not dev.nceas.ucsb.edu.  You can discover whether you are on the new 
server by using the /list command.  If you see the chat room 
"#newserver" then you are on the new server.  If not, wait a few hours 
and try reconnecting.

Let me know if you have any problems.

chad

-- 
-----------------------
Chad Berkley
National Center for
Ecological Analysis
and Synthesis (NCEAS)
berkley at nceas.ucsb.edu
-----------------------



From higgins at nceas.ucsb.edu  Thu Jul 17 13:52:51 2003
From: higgins at nceas.ucsb.edu (Dan Higgins)
Date: Thu, 17 Jul 2003 13:52:51 -0700
Subject: Is this legal?
Message-ID: <3F170CA3.3080001@nceas.ucsb.edu>

Hi All,

    In the spatialRaster module of eml2, we have the contruction shown 
below where georeferenceInfo is followed by a choice of one of 3 
elements (cornerPoint, controlPoint, or bilinearFit. But cornerPoint and 
controlPoint are defined with caridinalitiies greater than 1!  Is this 
legal? (or meanngful?)  Since the Choice element has a cardinality of 1, 
doesn't this mean that only ONE child is allowed? If so, one cannot have 
multiple cornerPoint or controlPoint elements (unless they are placed 
within a Sequence)?




Dan

-- 
*******************************************************************
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
*******************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030717/01d176e7/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: isThisLegal.gif
Type: image/gif
Size: 1697 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030717/01d176e7/isThisLegal.gif

From berkley at nceas.ucsb.edu  Thu Jul 17 14:04:51 2003
From: berkley at nceas.ucsb.edu (Chad Berkley)
Date: Thu, 17 Jul 2003 14:04:51 -0700
Subject: Is this legal?
References: <3F170CA3.3080001@nceas.ucsb.edu>
Message-ID: <3F170F73.3030500@nceas.ucsb.edu>

would this be a choice between 1..n controlPoints, 1..4 cornerPoints or 
1 bilinear fit?  So, it should validate if you do something like:

<georeferenceInfo>
   <controlPoint/>
   <controlPoint/>
   <controlPoint/>
   <controlPoint/>
   <controlPoint/>
   <controlPoint/>
</georeferenceInfo>

or if you do

<georeferenceInfo>
   <cornerPoint/>
   <cornerPoint/>
</georeferenceInfo>

or

<georeferenceInfo>
   <bilinearFit/>
</georeferenceInfo>


but not if you do this:

<georeferenceInfo>
   <cornerPoint/>
   <cornerPoint/>
   <cornerPoint/>
   <cornerPoint/>
   <cornerPoint/>
</georeferenceInfo>

or

<georeferenceInfo>
   <controlPoint/>
   <controlPoint/>
   <cornerPoint/>
   <cornerPoint/>
   <cornerPoint/>
</georeferenceInfo>

or

<georeferenceInfo>
   <bilinearFit/>
   <bilinearFit/>
</georeferenceInfo>

it's kind of weird, but now that I look at it, it seems ok...at least 
from looking at the picture.  I don't know what the schema looks like.

chad

Dan Higgins wrote:
> Hi All,
> 
>     In the spatialRaster module of eml2, we have the contruction shown 
> below where georeferenceInfo is followed by a choice of one of 3 
> elements (cornerPoint, controlPoint, or bilinearFit. But cornerPoint and 
> controlPoint are defined with caridinalitiies greater than 1!  Is this 
> legal? (or meanngful?)  Since the Choice element has a cardinality of 1, 
> doesn't this mean that only ONE child is allowed? If so, one cannot have 
> multiple cornerPoint or controlPoint elements (unless they are placed 
> within a Sequence)?
> 
> 
> geoReference
> 
> Dan
> 
> -- 
> *******************************************************************
> 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
> *******************************************************************
> 


-- 
-----------------------
Chad Berkley
National Center for
Ecological Analysis
and Synthesis (NCEAS)
berkley at nceas.ucsb.edu
-----------------------



From jones at nceas.ucsb.edu  Thu Jul 17 14:08:59 2003
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Thu, 17 Jul 2003 13:08:59 -0800
Subject: Is this legal?
In-Reply-To: <3F170F73.3030500@nceas.ucsb.edu>
References: <3F170CA3.3080001@nceas.ucsb.edu> <3F170F73.3030500@nceas.ucsb.edu>
Message-ID: <3F17106B.6040302@nceas.ucsb.edu>

Yep , i agree.  seems fine as an XML Schema construct.  I hadn't 
realized that we used schema constructs that were incompatible with DTDs 
and XML 1.0 validation.   Kind of a bummer, but I guess we live with it now.

Matt

Chad Berkley wrote:
> would this be a choice between 1..n controlPoints, 1..4 cornerPoints or 
> 1 bilinear fit?  So, it should validate if you do something like:
> 
> <georeferenceInfo>
>   <controlPoint/>
>   <controlPoint/>
>   <controlPoint/>
>   <controlPoint/>
>   <controlPoint/>
>   <controlPoint/>
> </georeferenceInfo>
> 
> or if you do
> 
> <georeferenceInfo>
>   <cornerPoint/>
>   <cornerPoint/>
> </georeferenceInfo>
> 
> or
> 
> <georeferenceInfo>
>   <bilinearFit/>
> </georeferenceInfo>
> 
> 
> but not if you do this:
> 
> <georeferenceInfo>
>   <cornerPoint/>
>   <cornerPoint/>
>   <cornerPoint/>
>   <cornerPoint/>
>   <cornerPoint/>
> </georeferenceInfo>
> 
> or
> 
> <georeferenceInfo>
>   <controlPoint/>
>   <controlPoint/>
>   <cornerPoint/>
>   <cornerPoint/>
>   <cornerPoint/>
> </georeferenceInfo>
> 
> or
> 
> <georeferenceInfo>
>   <bilinearFit/>
>   <bilinearFit/>
> </georeferenceInfo>
> 
> it's kind of weird, but now that I look at it, it seems ok...at least 
> from looking at the picture.  I don't know what the schema looks like.
> 
> chad
> 
> Dan Higgins wrote:
> 
>> Hi All,
>>
>>     In the spatialRaster module of eml2, we have the contruction shown 
>> below where georeferenceInfo is followed by a choice of one of 3 
>> elements (cornerPoint, controlPoint, or bilinearFit. But cornerPoint 
>> and controlPoint are defined with caridinalitiies greater than 1!  Is 
>> this legal? (or meanngful?)  Since the Choice element has a 
>> cardinality of 1, doesn't this mean that only ONE child is allowed? If 
>> so, one cannot have multiple cornerPoint or controlPoint elements 
>> (unless they are placed within a Sequence)?
>>
>>
>> geoReference
>>
>> Dan
>>
>> -- 
>> *******************************************************************
>> 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
>> *******************************************************************
>>
> 
> 

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------



From higgins at nceas.ucsb.edu  Mon Jul 21 11:46:02 2003
From: higgins at nceas.ucsb.edu (Dan Higgins)
Date: Mon, 21 Jul 2003 11:46:02 -0700
Subject: Georeferencing Images with EML2
Message-ID: <3F1C34EA.1030406@nceas.ucsb.edu>

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
*******************************************************************




From jones at nceas.ucsb.edu  Tue Jul 29 10:09:27 2003
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Tue, 29 Jul 2003 09:09:27 -0800
Subject: units dictionary
Message-ID: <3F26AA47.5070705@nceas.ucsb.edu>

Hi,

I recently discovered your initiative to create UnitsML 
(http://unitsml.nist.gov), and wanted to find out the status of this 
project.

I am active in the development of Ecological Metadata Language (EML) 
[1].  You may have seen the presentation on EML that Bill Michener gave 
in Santa Fe at the Sixth Open Forum on Metadata Registries.

In this language we have a need for unit definitions for ecological 
data.  The current version of EML uses the STMML approach for defining 
and referencing units.  We have a unit dictionary [2] containing 193 
unit definitions used in measurements in ecology and environmental 
science.  We have quickly come to realize that we need a mechanism for 
extension, because the number of units in use is much larger. Many units 
in use are quite idiosyncratic to particular subdisciplines of ecology 
or particular sites.  We have considered creating a repository for 
submission of unit definitions, just as you have proposed.

So...

1) Is the UnitsML project active? Do you have a projected schedule for work?
2) Why aren't you using STMML as the base of your work, given that Peter 
Murray-Rust is involved in your work?  Is there a fundamental flaw with 
STMML that you are trying to address?
3) Do you have interest in contributions and expertise from other 
disciplines that are actively grappling with unit definition issues?
4) Could we participate in the design and development of a repository 
for unit definitions?

Thanks,

Matt Jones

[1] http://knb.ecoinformatics.org/software/eml/
[2] 
http://cvs.ecoinformatics.org/cvs/cvsweb.cgi/~checkout~/eml/eml-unitDictionary.xml?rev=1.36&content-type=text/plain

-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------



From jones at nceas.ucsb.edu  Tue Jul 29 10:44:42 2003
From: jones at nceas.ucsb.edu (Matt Jones)
Date: Tue, 29 Jul 2003 09:44:42 -0800
Subject: [Fwd: xslt from eml to nbii]
Message-ID: <3F26B28A.80301@nceas.ucsb.edu>

Hey,

I had a chat with Derek Lane from the EPA about mapping from EML to 
NBII.  Sounds like the EPA expects to get some EML documents from their 
contributors.  Interesting.  At any rate, I think it is important that 
we try to make the eml2nbii XSLT style sheet work well, and so would 
like to invite members of eml-dev to review the stylesheet and check if 
its output is correct and complete.  I think Dan is still having 
difficulty with the spatial data sections and would appreciate help from 
those of you who know it well (Peter :)

Thanks,

Matt
-- 
-------------------------------------------------------------------
Matt Jones                                     jones at nceas.ucsb.edu
http://www.nceas.ucsb.edu/    Fax: 425-920-2439    Ph: 907-789-0496
National Center for Ecological Analysis and Synthesis (NCEAS)
University of California Santa Barbara
Interested in ecological informatics? http://www.ecoinformatics.org
-------------------------------------------------------------------
-------------- next part --------------
An embedded message was scrubbed...
From: Lane.Derek at epamail.epa.gov
Subject: xslt from eml to nbii
Date: Tue, 29 Jul 2003 12:09:15 -0400
Size: 1555
Url: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030729/ff0db123/xsltfromemltonbii.eml

From peter.mccartney at asu.edu  Tue Jul 29 15:23:34 2003
From: peter.mccartney at asu.edu (Peter McCartney)
Date: Tue, 29 Jul 2003 15:23:34 -0700
Subject: Georeferencing Images with EML2
Message-ID: <C070FF48FA66124C8E4BBB5AF901A90216B1A2@ex2.asurite.ad.asu.edu>

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

From higgins at nceas.ucsb.edu  Wed Jul 30 09:02:35 2003
From: higgins at nceas.ucsb.edu (Dan Higgins)
Date: Wed, 30 Jul 2003 09:02:35 -0700
Subject: Georeferencing Images with EML2
In-Reply-To: <C070FF48FA66124C8E4BBB5AF901A90216B1A2@ex2.asurite.ad.asu.edu>
References: <C070FF48FA66124C8E4BBB5AF901A90216B1A2@ex2.asurite.ad.asu.edu>
Message-ID: <3F27EC1A.1010001@nceas.ucsb.edu>

Peter,

    Thank you very much for your comments. They help my understanding 
greatly.

    Perhaps you can help with one other question that I have been unable 
to figure out. Is there an equivalent for 'corner points' in FGDC? There 
are certainly bounding coordinates, but I cannot seem to find any 
elements that register a grid to a coordinate system.

    Thanks again,

Dan

---

Peter McCartney wrote:

> 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
>


-- 
*******************************************************************
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
*******************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030730/51133127/attachment.htm

From peter.mccartney at asu.edu  Thu Jul 31 12:41:01 2003
From: peter.mccartney at asu.edu (Peter McCartney)
Date: Thu, 31 Jul 2003 12:41:01 -0700
Subject: Georeferencing Images with EML2
Message-ID: <C070FF48FA66124C8E4BBB5AF901A90216B1A3@ex2.asurite.ad.asu.edu>

Nope, not to my knowledge. FGDC was very poorly thought out when it came to
dealing with gridded data. Depending on the file format the data are stored
it, the registration of the grid to the coordinate system is often handled
internally (ESRI Export format, Erdas Imagine) or in an associated "world"
file (GeoTiff, etc). In this case, the corner points arent needed - the
enduser simply has to use an application that knows how to deal with the
file type (in the same way we now assume the enduser will know now to open a
"dbf" format file for tabular data). So when outputting fgdc files from eml,
you'll basically have to throw away this information.
 
I skimmed over your xsl, but i really need to try it on a few files before i
can make any helpful suggestions. I also want to get some advice from you on
using your reference-resolving code - i tried in in one of our xsl's and
cant tell if it was me or Sylus studio that was having a problem.
 
 
Peter McCartney (peter.mccartney at asu.edu <mailto:peter.mccartney at asu.edu> )
Center for Environmental-Studies
Arizona State University
 

-----Original Message-----
From: Dan Higgins [mailto:higgins at nceas.ucsb.edu] 
Sent: Wednesday, July 30, 2003 9:03 AM
To: Peter McCartney
Cc: Eml-Dev (eml-dev at ecoinformatics.org)
Subject: Re: Georeferencing Images with EML2


Peter,

    Thank you very much for your comments. They help my understanding
greatly.

    Perhaps you can help with one other question that I have been unable to
figure out. Is there an equivalent for 'corner points' in FGDC? There are
certainly bounding coordinates, but I cannot seem to find any elements that
register a grid to a coordinate system.

    Thanks again,

Dan

---

Peter McCartney wrote:


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
<mailto:higgins at nceas.ucsb.edu> ] 
Sent: Monday, July 21, 2003 11:46 AM 
To: Eml-Dev (eml-dev at ecoinformatics.org <mailto: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
<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
<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
<mailto: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
<mailto:higgins at nceas.ucsb.edu>  
http://www.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 <mailto:eml-dev at ecoinformatics.org>  
http://www.ecoinformatics.org/mailman/listinfo/eml-dev
<http://www.ecoinformatics.org/mailman/listinfo/eml-dev>  



-- 

*******************************************************************

Dan Higgins                                  higgins at nceas.ucsb.edu
<mailto:higgins at nceas.ucsb.edu> 

http://www.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

*******************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030731/f0d47b41/attachment.htm

From dblankman at lternet.edu  Thu Jul 31 18:38:17 2003
From: dblankman at lternet.edu (David Blankman)
Date: Thu, 31 Jul 2003 19:38:17 -0600
Subject: measurmentScale/precision - what definition? how to handle?
Message-ID: <3F29C489.9000503@lternet.edu>

Matt & IMs & EML-Dev

*
How to Handle Missing Precision Information*
Most of the metadata files that I have been working with and most of 
those from sites like NTL do not have precision information. While XML 
Spy seems to validate empty elements, the EML Validator service does a 
better job and will not allow empty elements.

Because many, if not most, of the LTER Information Managers have told me 
that they need to check with researchers to get precision informaton, it 
may be some time before we are able to get precision information.

Initially I thought that we could handle precision by just using empty 
elements but that seems not possible.

It seems to me that we have two alternatives:

   1. Use a precision of "0" to indicate that precision is missing.
   2. Put in metadata without dataTable.

*Perhaps the problem with precision is that different people are 
interpreting precision differently. *

The eml documentation states:
<doc:description>The precision element represents the precision
        of the measurement, in the same unit as the measurement. For
        example, for an attribute with unit "meter", a precision of "0.1"
        would be interpreted as precise to the nearest 1/10th of a
        meter, and a precision of "1" would be interpreted as precise
        to the nearest 1 meter.
</doc:description>

This description does not help since it does not defiine precision, but 
rather assumes that you know what precison means.  I remember that we 
discissed the definition, but I cannot remember what definition we 
decided to use.
*
Some definitions:*
*b.* The number of significant digits to which a value has been reliably 
measured.


*precision: 1.* The degree of mutual agreement among a series of 
individual measurements, values, or results; often, but not necessarily, 
expressed by the standard deviation. *2.* With respect to a set 
<http://glossary.its.bldrdoc.gov/fs-1037/dir-033/_4806.htm> of 
independent devices of the same design, the ability of these devices to 
produce the same value or result, given the same input 
<http://glossary.its.bldrdoc.gov/fs-1037/dir-019/_2740.htm> conditions 
and operating in the same environment. *3.* With respect to a single 
device, put into operation 
<http://glossary.its.bldrdoc.gov/fs-1037/dir-025/_3691.htm> repeatedly 
without adjustments, the ability to produce the same value or result, 
given the same input conditions and operating in the same environment. 
/Synonym (for defs. 1, 2, and 3)/ *reproducibility. 4.* In computer 
science <http://glossary.its.bldrdoc.gov/fs-1037/dir-008/_1196.htm>, a 
measure of the ability to distinguish between nearly equal values. (188 
<http://glossary.its.bldrdoc.gov/fs-1037/dir-001/_0063.htm#188>) *5.* 
The degree of discrimination with which a quantity is stated; for 
example, a three-digit 
<http://glossary.its.bldrdoc.gov/fs-1037/dir-011/_1632.htm> numeral to 
the base 10 discriminates among 1000 possibilities.

* <mathematics>* The number of decimal places to which a number
is computed.

What concept are we trying to capture?

Can the precision be simply a statement of the number of decimal points 
in the data, e.g. unit = meter
DATA
1.75
10.6
11.765

Can we say that the precision is .001 without knowing anything about the 
source of the data?

Or are we making a statement about the number of significant digits, for 
example, a data logger can record 4 digits, e.g.

The following can be recorded:

12.75
127.5
1.275
1275

but NOT 127.53

Is the precision here also .001?

If the data is derived data, is the precsion depenmdent on the precision 
of the original data, e.g. an instrument can only discriminate to .1 
meter, but the data involves some statistical operation and the data is 
reported with additional decimal places.

unit = meter

Original Data

12.1
11.5
26.4

Reported/Derived DATA
11.75
10.6
21.765

Is the precision 0.1 or 0.001?

David


-- 
David Blankman
EML Integration Developer
LTER Network Office
801 University, SE #104
Albuquerque, NM 87106
(505) 272-7346

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/eml-dev/attachments/20030731/b035b53a/attachment.htm

From tao at nceas.ucsb.edu  Thu Jul 31 16:08:32 2003
From: tao at nceas.ucsb.edu (Jing Tao)
Date: Thu, 31 Jul 2003 16:08:32 -0700 (PDT)
Subject: Metacat 1.3.0 Release Announcement
Message-ID: <Pine.LNX.4.33.0307311602540.21063-200000@hyperion.nceas.ucsb.edu>

The Knowledge Network for Biocomplexity project (http://knb.ecoinformatics.org) 
is pleased to announce its new release of Metacat (1.3.0). Metacat is a 
flexible database storage system for XML formatted documents. In this release, the
main new feature is that it can support EML 2 documents. Please
see the attached README file for more new features and details.

Source code is available for Linux (RedHat 7.2 to 9.0), Unix and
Windows 2000/XP - see the software download page
(http://knb.ecoinformatics.org/software/download.html#metacat).

We would welcome any input or suggestions (email metacat-dev at
ecoinformatics.org).

-- 
Jing Tao
National Center for Ecological
Analysis and Synthesis (NCEAS)
735 State St. Suite 204
Santa Barbara, CA 93101
-------------- next part --------------
#
#  '$RCSfile: README,v $'
#   '$Author: tao $'
# '$Revision: 1.28 $'
#     '$Date: 2003/07/31 01:33:37 $'
#

Metacat: XML Metadata Database
------------------------------

Version: 1.3.0 Release

Send feedback and bugs to: metacat-dev at ecoinformatics.org
                           http://bugzilla.ecoinformatics.org

Contributors: Matt Jones (jones at nceas.ucsb.edu)
              Chad Berkley (berkley at nceas.ucsb.edu)
              Jing Tao (tao at nceas.ucsb.edu)
              Jivka Bojilova (bojilova at nceas.ucsb.edu)
              Dan Higgins (higgins at nceas.ucsb.edu)

Metacat is a flexible database storage system for XML formatted
documents. Metacat models the structure of the XML document, therefore
allowing storage of XML documents with arbitrary schemas. Metacat supports
several databases on the back-end, including Oracle, PostgreSQL and SQL
Server.  The server supports XML document storage, retrievel, query,
validation, and transformation (using the XSLT stylesheet language).
In addition, there is a mechanism for replicating the database
to other metacat instances for backup and load balancing purposes.
Metacat currently uses an LDAP database for authenticating users, but
was written to accomodate other authentication services as well.

Release Notes

In this release, the structure of the xml_access table was changed and a new
table, xml_accesssubtree was added. If you try to update a previously 
installed Metacat, you should run a script file to updated the table structure 
before installation.
For Oracle user: At the SQLPLUS prompt type the following -
@src/reviseformetacat13.sql
For Postgresql user: At install directory prompt type the following -
psql exp < src/reviseformetacat13_postgres.sql
(where 'exp' is the database name).

After installation, user should run "ant schemasql" command to register EML2
schema in xml_catalog table.

If you are a new Metacat user, this step is unneeded.

Note: 1) We recommend to use Tomcat 4 and JAVA 1.4 to run Metacat. Otherwise, 
         it will cause potential replication issues.
      2) Delete the xercesImpl.jar and xmlParserAPIs.jar files 
         which are in $CATALINA_HOME/common/endorsed. They are old version and
         don't support XML schema validation.

New Features in 1.3.0
  1) Partialy support EML2 document. User can store, query, read and write
     EML2 documents. However, Metacat only support access control in resource
     level. The subtree level access control will be ignored.
  2) Support other xml document base on namespace/schema.
  3) Support query for attribute value
  4) Assign MIME type to data file base on metadata when user try to read it.
  5) Owner can assign access rules to a document which does not have access 
     document to apply it.
  6) Support exporting single file, not only whole package
  7) Resupport Microsoft SQL Server.

Fixes in 1.3.0:
  1) Couldn't finish delta T replication for large set of documents.
  2) Couldn't create access control during delta T replication.
  3) Eorr will be written to a seperated log file if some documents
     were failed in replication.
  4) Decrease the time to create access rules during insert or update 
     a package.
     
Installation
------------
See the file "docs/user/metacatinstall.html" for detailed instructions.

Documentation
-------------
See the docs directory for detailed documentation and installation
instructions.

Details of the Metacat architecture can be found on the website for
the Knowledge Network for Biocomplexity (KNB):

  http://knb.ecoinformatics.org/software/metacat/

Contributions to this work are welcome.  Please see the above web site
for details on how to contribute.

Major Known Bugs or Feature Requests (see http://bugzilla.ecoinformatics.org)
-----------------------------------------------------------------------------
If you discover a bug
please report it, either by email (above) or by using our bug tracking
system (http://bugzilla.ecoinformatics.org). There is a list of currently
unimplemented features in Bugzilla that we are working on for the next
release (no, we don't have a date yet!).

Legalese
--------
This software is copyrighted by The Regents of the University of California
and the National Center for Ecological Analysis and Synthesis
and licensed under the GNU GPL; see the 'LICENSE' file for
details.

This material is based upon work supported by the
National Science Foundation under Grant No. DEB99-80154 and DBI99-04777.
Any opinions, findings and conclusions or recomendations expressed in this
material are those of the author(s) and do not necessarily reflect
the views of the National Science Foundation (NSF).

This product includes software developed by the Apache Software
Foundation (http://www.apache.org/). See the LICENSE file in lib/apache
for details.

The source code, object code, and documentation in the com.oreilly.servlet
package is copyright and owned by Jason Hunter. See the cos-license.html file
for details of the license.  Licensor retains title to and ownership of the
Software and all enhancements, modifications, and updates to the Software.

