[Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Fri Oct 9 13:53:25 EDT 2009

My vote is to go for the full thing IIF we can provide stored queries. If the query is bound to the serialisation , I'd rather have the simpler form than having to explain user they have to write 1 yard long xpath to filter by age.
Eric (who still has to write a stored query implementation strategy for WFS 1.1.0)


De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Stephen M Richard
Envoyé : 9 octobre 2009 12:33
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]

The silence has been resounding!
So, any opinions about whether to use the simpler, but home-brewed CGI_NumericAge or the existing, more complex StratigraphicDateEstimate for CGI_NumericAgeRange?

CGI_Numeric age provides simpler approach, but less inherited architecture for detailed linkages with metadata and GeologicTime elemetns for connection to geologic and observation foundation of age estimate.

StratigraphicDateEstimate is more complex, requires overlay of schematron or profile rules to really be interoperable, but allows much richer data content and linkage to GeologicTime model. May require GML 3.2....?


Stephen M Richard wrote: 

	Please see discussion of this on TWIKI at https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/NumericAgeDate
	Simon Cox wrote: 

		Oh dear. 
		There appears to be a misunderstanding here, and I completely disagree with
		the conclusion: 

			TM_Coordinate. BUT... there is a mandatory association with TM_CoordinateSystem
			which involves defining a timescale based on clock and calendar. (See attached
			picture to see the TM classes involved). Not very applicable to defining
			the geological time frame.

		TM_OrdinalReferenceSystem, TM_CoordinateSystem, TM_Clock and TM_Calendar
		are the four different kinds of TM_ReferenceSystem. 
		I.e. they are alternatives - there is no dependency from TM_CoordinateSystem
		to TM_Clock or TM_Calendar. 
		TM_CoordinateSystem is _exactly_ what you need to define the scale described
		in the quote from the NAm Strat Code - i.e. an origin and a standard unit.
		Perhaps missing is the ability to say 'positive backwards' but this would
		be a minor extension to the ISO TM_CoordinateSystem class. 

Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA

Office: (520) 209-4127
Reception: (520) 770-3500 
FAX: (520) 770-3505

email: steve.richard at azgs.az.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091009/18f27e57/attachment.htm>

More information about the GeoSciML mailing list