[OSGeo-Standards] Single Simple Feature Metadata
Landon Blake
lblake at ksninc.com
Fri Nov 13 17:25:46 EST 2009
I posted a message today about single simple feature metadata creation
and management to the metadata mailing list at GeoComm.
I thought I would post it here. Some of you may be interested in the
issue I am discussing.
Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
-----Original Message-----
From: Landon Blake
Sent: Friday, November 13, 2009 2:24 PM
To: metadata at lists.geocomm.com
Subject: RE: [metadata] Single Simple Feature Metadata
John,
Thanks for the quick response.
You wrote: "Your sample is pretty verbose."
Probably not as verbose as XML. :]
I wanted something that was human readable and structured. I don't mind
the length. Obviously it would be more compact in a database. Most
people would probably store single feature metadata in a database. I may
do that at some point in the future, but at this time I'm interested in
getting a relatively simple text format that is easy to share with other
organizations and clients.
You wrote: "I can encode this in ISO 19139 tags .... the <hierarchy
level>
would be "10. feature" its pretty straight-forward"
I have concerns about using ISO 19139. I'm doing this work on a
volunteer basis, and I can't fork out the money for the spec. If there
is a freely available standard for this type of metadata I would use it,
but paying for the ISO 19139 standard isn't really an option.
You wrote: "... how many features do you have?"
I don't have a lot right now. I'm going to be creating the features as
part of my project. I wanted to get the metadata format nailed down
before I had a bunch of existing features that needed metadata. The idea
is to create it as I move forward and to update it as I make changes to
the dataset.
You wrote: "The only downside here is the potential massive amount of
data and resulting slow speed of searches, displays, transformations,
etc ...."
I'm not running an operation on a massive scale like some players. I'm
not dealing with enterprise GIS or millions of features. Both of my
current projects are volunteer projects. I'll be creating a couple
thousand features over the course of the next couple of years in an open
source desktop GIS program.
If I run into speed/scalability problems I can migrate to a database,
or, more likely write some Java code that converts the text files to a
binary file format.
You wrote: " Its friday afternoon, 15 min from going home ... if you
will email me with a more concise description of your issues, I can take
a stab at it on monday ..."
Let me briefly describe my first project. I'm working with the local
association of land surveyors to locate, catalog, and maintain the
network of Public Land Survey System monuments in our County. We will be
tackling this project one township at a time. I'm taking the PLSS layers
available from the BLM/GCDB and improving them using local surveying
data and field inspections.
In some sense I am operating strictly as a data creator and provider. My
primary target audience isn't necessarily advanced enough to run there
own enterprise relational data base, but they are very comfortable with
text files.
At any rate, I was mostly poking around to see if others had tackled
this problem of tracking the creation and edits of individual features.
I know most people are using a RDBMS for this, but those can be hard for
less technical users to manipulate and share.
I suppose I am a little bias, as I'm not a huge fan of relational
databases as a programmer, either. They are just overkill and too
complicated for a lot of the computing problems I am trying to solve.
Landon
Office Phone Number: (209) 946-0268
Cell Phone Number: (209) 992-0658
-----Original Message-----
From: John.Tucker [mailto:John.Tucker at noaa.gov]
Sent: Friday, November 13, 2009 1:16 PM
To: Landon Blake; metadata at lists.geocomm.com
Subject: Re: [metadata] Single Simple Feature Metadata
Landon,
Your sample is pretty verbose.
I can encode this in ISO 19139 tags .... the <hierarchy level>
would be "10. feature" its pretty straight-forward ... how many features
do
you have? The only downside here is the potential massive amount of
data and
resulting slow speed of searches, displays, transformations, etc ....
Its friday afternoon, 15 min from going home ... if you will email
me
with a more concise description of your issues, I can take a stab at it
on
monday ...
JohnT
Landon Blake wrote:
> Forgot the attachment. :]
>
> Landon
> Office Phone Number: (209) 946-0268
> Cell Phone Number: (209) 992-0658
>
>
> -----Original Message-----
> From: metadata-bounces+lblake=ksninc.com at lists.geocomm.com
> [mailto:metadata-bounces+lblake=ksninc.com at lists.geocomm.com] On
Behalf
> Of Landon Blake
> Sent: Friday, November 13, 2009 12:37 PM
> To: metadata at lists.geocomm.com
> Subject: [metadata] Single Simple Feature Metadata
>
> I have a couple of GIS projects for which I need to create and
maintain
> metadata at the single feature level, as opposed to the dataset or
layer
> level. The features I am documenting are basically OGC simple
features.
> I need to track the sources of feature geometry and attributes values,
> and I need to track changes to these.
>
>
>
> I am working on a simple text file format for this purpose, and I have
> started tinkering with a Java API to read and manipulate these files.
>
>
>
> I would like to know if there would be any interest in collaborating
on
> a file format for metadata of individual features. If there is
interest,
> I would like to move discussion of the format to the OSGeo standards
> mailing list. I plan on releasing my Java code under the GPL, if that
> makes a difference to anyone. I'd also consider working together with
> others on a RDBMS schema for this purpose, although my primary
interest
> is in working with the text file form of the metadata.
>
>
>
> Of course, if there is a similar existing standard that will allow me
to
> accomplish my purpose, I should consider using that instead. I haven't
> found anything yet. Please let me know if I am missing a metadata
> standard for single features.
>
>
>
> I have attached a sample metadata file for a feature that represents a
> United States Public Land Survey Section in a project I am working on.
> The file format is just preliminary.
>
>
>
> Thanks,
>
>
>
> Landon Blake
>
> Project Surveyor
>
> California PLS 8489
>
> Office Phone Number: (209) 946-0268
>
> Cell Phone Number: (209) 992-0658
>
> lblake at ksninc.com
>
> 711 North Pershing Avenue
>
> Stockton, California, 95203
>
>
>
> Warning:
> Information provided via electronic media is not guaranteed against
> defects including translation and transmission errors. If the reader
is
> not the intended recipient, you are hereby notified that any
> dissemination, distribution or copying of this communication is
strictly
> prohibited. If you have received this information in error, please
> notify the sender immediately.
> _______________________________________________
> metadata mailing list
> metadata at lists.geocomm.com
> http://lists.geocomm.com/mailman/listinfo/metadata
>
> _____________________________________
> This List is brought to you by:
> The GeoCommunity and The GISDataDepot
> http://www.geocomm.com/ | http://data.geocomm.com/
>
>
------------------------------------------------------------------------
> Name: Sample_Metadata_File.txt
> Sample_Metadata_File.txt Type: Plain Text (text/plain)
> Encoding: base64
> Description: Sample_Metadata_File.txt
>
>
------------------------------------------------------------------------
> _______________________________________________
> metadata mailing list
> metadata at lists.geocomm.com
> http://lists.geocomm.com/mailman/listinfo/metadata
>
> _____________________________________
> This List is brought to you by:
> The GeoCommunity and The GISDataDepot
> http://www.geocomm.com/ | http://data.geocomm.com/
Warning:
Information provided via electronic media is not guaranteed against defects including translation and transmission errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this information in error, please notify the sender immediately.
-------------- next part --------------
Feature Metadata File
File Format Version: 00.10.00
Feature Metadata
Version: 1.0
Primary Identifier: A13 T1S R7E
Feature Type: Public Land Survey System Corner
Geometry Type: Point
Feature Creation
Date and Time Created: 2009-11-05 09:32:00
Primary Geometry Source: Feature Geometry from the United States of America Bureau of Land Management ->
Geogrpahic Coordinate Database Public Land Survey System Sections (Or "alt_first") GIS data layer.
Alternate Geometry Source:
Geometry Creation Process: Geometry Created From Other Feature Geometry
Geometry Creation Comments: The feature geometry for this PLSS corner was created based on the location->
of nodes in the polygon representing the boundaries of PLSS sections in the primary geometry source ->
listed above. Note: The polygon representing the boundaries of PLSS sections may have been corrected ->
or modified as part of the cleaning/data quality improvement process performed as part of the California ->
Central Valley Chapter PLSS Maintenance and Improvement Program. These changes to the PLSS Sections ->
GIS data layer may impact the location of feature geometries representing PLSS corners.
Attribute Value Sources
- Attribute Source
Attribute Name: oic
Attribute Primary Source: CLSA Cvc PLSS MIP Volunteer
Attribute Creation Process: Human Data Entry
Attribute Creation Comments: None
- Attribute Source
Attribute Name: fic
Attribute Primary Source: CLSA CVc PLSS MIP Volunteer
Attribute Creation Process: Human Data Entry
Attribute Creation Comments: None
- Attribute Source
Attribute Name: ftc
Attribute Primary Source: CLSA CVc PLSS MIP Volunteer
Attribute Creation Process: Human Data Entry
Attribute Creation Comments: None
- Attribute Source
Attribute Name: ts
Attribute Primary Source: BLM/GLO Township Plat
Alternate Attribute Sources
Attribute Alternate Source: Filed Survey Maps in San Joaquin County
Attribute Creation Process: Human Data Entry
Attribute Creation Comments: None
- Attribute Source
Attribute Name: tn
Attribute Primary Source: BLM/GLO Township Plat
Alternate Attribute Sources
Attribute Alternate Source: Filed Survey Maps in San Joaquin County
Attribute Creation Process: Human Data Entry
Attribute Creation Comments: None
- Attribute Source
Attribute Name: rs
Attribute Primary Source: BLM/GLO Township Plat
Alternate Attribute Sources
Attribute Alternate Source: Filed Survey Maps in San Joaquin County
Attribute Creation Process: Human Data Entry
Attribute Creation Comments: None
- Attribute Source
Attribute Name: ip
Attribute Primary Source: CLSA CVc PLSS MIP Volunteer
Attribute Creation Process: Human Data Entry
Attribute Creation Comments: None
- Attribute Source
Attribute Name: fn
Attribute Primary Source: Other Feature Attribute Values
Attribute Creation Process: Calculated From Other Feature Attribute Values
Attribute Creation Comments: None
Feature Creation Comments:
Feature History
- Metadata Entry
Metadata Entry Type: Geometry Edit
Geometry Edit Type: Point Position Modified
Purpose: Data Quality Improvement
Metadata Entry Comments: Since this feature represents a 1/4 section corner, it was ->
moved to the actual mid point of the section line. The original polygons representing ->
the boundaries of the PLSS sections which this quarter section control had a node
that was not at the true mid-point but near the north lines of the sections.
- Metadata Entry
Metadata Entry Type: Attribute Value Edit
Attribute Name: fic
Attribute Value Edit Type: Value Change
Purpose: The value of the fic attribute was changed from false to true after the field ->
inspection had been completed by CLSA CVC PLSS MIP volunteers.
Metadata Entry Comments: The field inspection for this PLSS corner was completed ->
on Thursday, November 5, 2009.
More information about the Standards
mailing list