[auscope-geosciml] GeoSciML Thematic View schema - callfor feedback

Alistair Ritchie alistair.bh.ritchie at gmail.com
Thu Sep 30 21:15:22 EDT 2010


It is important that we don't allow choices for how to represent age values
we provide (that is how I read "if providers don’t want to use it they don’t
have to"). The primary use case for the htttp-uri properties is allowing
consistent thematic mapping across multiple services. To do that we need to
be very clear about how a service provides age data if it is available -
this discussion isn't providing that clarity.

If one provider chooses to only deliver single representative ages, and
another only uses ranges, then there's no common means of creating a
thematic map. There will be holes where the thematic queries 'fail' because
an expected property isn't populated.

We have three choices (the following examples assume the value stored in the
database is a range: 'lower ordovician'; 'upper ordovician'):

1) Deliver one age:
     representativeAge = 'http://resource.geosciml.org/lazy-uri/ordovician';
2) Deliver two ages (a range):
     representativeOlderAge =
http://resource.geosciml.org/lazy-uri/lower-ordovician';
     representativeYoungerAge = 'http://resource.
geosciml.org/lazy-uri/upper-ordovician';
3) Deliver all three:
     representativeOlderAge =
http://resource.geosciml.org/lazy-uri/lower-ordovician';
     representativeYoungerAge = 'http://resource.
geosciml.org/lazy-uri/upper-ordovician';
     representativeAge = 'http://resource.geosciml.org/lazy-uri/ordovician';

All options assume that *if you have an age value* you will have to
propulate all the age fields (so for option three, if you only have one age
value all properties will have the same value).

I prefer 1) then 3). Everyone?

*Alistair Ritchie*
*GEOSCIENCE VICTORIA* | EARTH RESOURCES DIVISION
Department of Primary Industries | Melbourne, Victoria, Australia
Tel: +61 3 9658 4512 | Fax: +61 3 9658 4555


On 30 September 2010 19:49, Laxton, John L <jll at bgs.ac.uk> wrote:

>  Hi Bruce,
>
>
>
> Potential misuse is a problem with all aspects of the model – all you can
> do is document everything and hope people will use it correctly (people
> could put a range in lower or upper age for example). The snag with not
> having a representativeAge as well as lower and upper age is you cannot then
> provide both the legend and map face information, which will be a pretty
> common requirement of a simple map focussed schema. I can’t really see any
> problem with including a representativeAge – if providers don’t want to use
> it they don’t have to but I think many will want to use it.
>
>
>
> John
>
>
>
> *From:* auscope-geosciml-bounces at lists.arcs.org.au [mailto:
> auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of *
> Bruce.Simons at dpi.vic.gov.au
> *Sent:* 25 September 2010 09:16
>
> *To:* auscope-geosciml at lists.arcs.org.au
> *Subject:* Re: [auscope-geosciml] GeoSciML Thematic View schema - callfor
> feedback
>
>
>
>
> John,
> Indeed, but on maps the 'representative age' is usually restricted to a
> single Period (sorry I used Era by mistake), whereas the legend has an upper
> and lower age. So the tension we are trying to resolve is between wanting to
> show the map age vs the legend age.
>
> As the data consumer (client) doesn't have control over what the data
> provider delivers they could put anything (including a range) in the
> 'representativer age', which would make using it in a portrayal very
> difficult.
>
> Similarly we don't have control over what the client application chooses to
> use for display, so it could still portray any of the Lower Age, the Upper
> Age or the Representative Age (or any combination) and the data provider has
> no say in it.
>
> The problem is if you provide all three (lower, upper and representative)
> then different data providers will populate them differently and different
> clients will use them differently - the worst of all possible worlds.
>
> Alternatively, only providing the capacity to deliver a single age, the
> 'representative age', will encourage those who have an upper and lower age
> to provide this as a text range, which is not easily portrayed.
>
> It is therefore probably  best to allow for a lower and upper age, which
> makes it explicit what these are. It meets the requirements of those who
> want a minimum and maximum age. Those who want to deliver a single
> representative age can populate both with the same value, forcing clients to
> use this value.  The data provider can decide what age they want portrayed,
> and those clients with the capacity to display the age based on various
> ranges will have the information to do so.
>
> Cheers
> Bruce
>
> Ph: +61-3-9658 4502
> Fax: +61-3-9658 4555
> Mobile: +61 429 177155
>
>   *"Laxton, John L" <jll at bgs.ac.uk>*
> Sent by: auscope-geosciml-bounces at lists.arcs.org.au
>
> 23/09/2010 05:55 PM
>
> Please respond to
> auscope-geosciml at lists.arcs.org.au
>
> To
>
> "auscope-geosciml at lists.arcs.org.au" <auscope-geosciml at lists.arcs.org.au>
>
> cc
>
> Subject
>
> Re: [auscope-geosciml] GeoSciML Thematic        View        schema        -
>        callfor        feedback
>
>
>
>
>
>
> Yes I agree – that is just what I was saying!
>
> John
>
> *From:* auscope-geosciml-bounces at lists.arcs.org.au [mailto:
> auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of *
> Bruce.Simons at dpi.vic.gov.au*
> Sent:* 23 September 2010 00:56*
> To:* auscope-geosciml at lists.arcs.org.au*
> Subject:* Re: [auscope-geosciml] GeoSciML Thematic View schema - callfor
> feedback
>
>
> John,
> The trouble is that all age representation are ranges (even a single term
> such as Silurian actually represents a range.) Because of the almost
> infinite age range combinations possible, the usual practise is to have the
> geologist pick a single age era term as the representative age for
> symbolising based on the appropriate age era, irrespective of the actual age
> range shown in the legend.
>
> Perhaps a Thematic View age labelled "representative age era" would meet
> the 1GE user requirements and allow the application to know it will be one
> of the ISC eras?
>
> Cheers
> Bruce
>
> Ph: +61-3-9658 4502
> Fax: +61-3-9658 4555
> Mobile: +61 429 177155
>
> *"Laxton, John L" <jll at bgs.ac.uk>*
> Sent by: auscope-geosciml-bounces at lists.arcs.org.au
>
> 22/09/2010 06:27 PM
>
>
>
> Please respond to
> auscope-geosciml at lists.arcs.org.au
>
>
>
> To
>
> "auscope-geosciml at lists.arcs.org.au" <auscope-geosciml at lists.arcs.org.au>
>
> cc
>
> Subject
>
> Re: [auscope-geosciml] GeoSciML Thematic View schema        -
>  callfor        feedback
>
>
>
>
>
>
>
>
>
>
> Hi,
>
> In 1GE this was a portrayal issue. Ages were given as a term range but
> because we wanted to portray age in one of the services we arbitrarily
> decided this would be on the basis of lower age, which could clearly give
> misleading results for units covering a long time period. Alternatives would
> have been to go up the age hierarchy tree until we had a geochron unit that
> included the whole time period of the unit, but that could mean loss of a
> lot of resolution, or a geologist choosing an appropriate representative
> age. The latter would have been best but we decided against it because of
> the geologist time involved as I recall. In developing a data structure
> designed for portrayal a single term ‘representative age’ would be useful.
>
> John
>  *
> From:* auscope-geosciml-bounces at lists.arcs.org.au [mailto:
> auscope-geosciml-bounces at lists.arcs.org.au] *On Behalf Of *Tellez-Arenas
> Agnes*
> Sent:* 22 September 2010 08:27*
> To:* auscope-geosciml at lists.arcs.org.au*
> Subject:* Re: [auscope-geosciml] GeoSciML Thematic View schema - callfor
> feedback
>
>
> Hi
>
> Thanks for this answer.
>
> Another question/comment.
>
> Regarding gsmltv:representativeLowerAge_uri  and
> gsmltv:representativeUpperAge_uri, I remember that in 1GEurope project, some
> partners were not happy with having to choose between upperAge or lowerAge
> for portraying the data, they would prefere a representativeAge (If I am not
> wrong...). We had a lot of discussion on that subject. It was an issue also
> because of the harmonization between several country. I am honnestly not
> able to explain why and what! I think John would be able to give more
> explanation.
>
> (or maybe I am totally wrong!)
>
> Agnès
>
>
>
>
>  ------------------------------
>
>
> *
> 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é :* mercredi 15 septembre 2010 16:57*
> À :* auscope-geosciml at lists.arcs.org.au*
> Objet :* Re: [auscope-geosciml] GeoSciML Thematic View schema - callfor
> feedback
> Agnes--
> here's some examples of a structured approach to the text strings that
> might be used in a flat file format to summarize the lithology and geologic
> history
> steve
>
>
> LITHOLOGY COMPOSITION (Text) – Composition of the mapped unit in terms of
> rock types from the standard lithology vocabulary, along with a proportion
> value for each constituent. Encoded as a set of {lithology:proportion}
> tuples. Rock types will be specified with preferred names from a CGI
> lithology vocabulary. Proportion values will also be specified from a
> controlled vocabulary, and definition for these terms will be accessible
> through the same mechanism as the lithology vocabulary.  The format will be
> “Lith1:prop1;Lith2:prop2”. The lithology vocabulary includes some hierarchy,
> and the lithology terms could encode the hierarchy from most general to most
> specific (granitic rock/granodiorite). The first lithology listed will be
> considered the most abundant and used for symbolization in a lithology map
> portrayal.
>
> GEOLOGIC History (Text) – Text string for geologic age of event(s) in
> genesis of unit.  Specified as “Age(NNN.N)[?][-Age(NNN.N)[?]]:Event” tuples,
> with multiple values separated by semicolons. If two age values are
> included, separated by a hyphen, for an event, the event occurred during an
> age range. Older age bound of range is listed first. If a numeric age is
> known, it should be added after the corresponding stratigraphic age term in
> parenthesis. Numeric age values are in millions of years before 1950 (Ma).
> Hierarchy of stratigraphic ages is indicated from most general to most
> specific, with the named eras separated by ‘/’. To reduce the likelihood of
> the age string exceeding 255 characters and being truncated in shapefiles,
> stratigraphic era names do not need to be repeated if they have already been
> used. The confidence term is optional, defaulting to ‘std’, indicating that
> the age is considered reliable with a *st*andar*d* level of confidence.
> Other values allowed are ‘low’, used to indicate that the associated age
> assignment is uncertain, and ‘unk’ to indicate unknown reliability.
> Examples: “Phanerozoic/Mesozoic/Jurassic-Cretaceous:Deposition”,
> “Phanerozoic/­Cenozoic/­Neogene/­Miocene(12.5):Eruption”,
> “Precambrian/­Proterozoic/­Paleo­protero­zoic­(1750):­Eruption;
> Mesoproterozoic(1420):Intrusion;
> Phanerozoic/­Mesozoic/­Jurassic­(165):­Intrusion;
> Cenozoic/­Paleogene/Eocene?-Neogene/Miocene:Metamorphism; Miocene:­Cooling”.
>
>
>
> On 9/15/2010 12:52 AM, Tellez-Arenas Agnes wrote:
> Hi,
>
> A first question.
>
> I understand that gsmltv:geologicHistory (concat value YES) represents
> several attributes that are concatenated.
> But what if there are several geologicHistory?
>
> For gsmltv:lithology, I guess that if there are several compositionPart,
> all the lithologies are concatenated, without role and proportion?
>
> Thanks for this work!
>
> Best regards
>
> Agnès
>
>
>
>
>  ------------------------------
>
>
> *
> De :* auscope-geosciml-bounces at lists.arcs.org.au [
> mailto:auscope-geosciml-bounces at lists.arcs.org.au<auscope-geosciml-bounces at lists.arcs.org.au>]
> *De la part de* Alistair Ritchie*
> Envoyé :* mercredi 15 septembre 2010 03:43*
> À :* AuScope-GeoSciML*
> Objet :* [auscope-geosciml] GeoSciML Thematic View schema - call for
> feedback *
> BACKGROUND*
>
> The lack of a thematic map or portrayal model that could be easily deployed
> in the current generation of web map services (be they OGC or Google or ...
> ? ... services) has long been recognised as a problem in GeoSciML. At the
> Rome IWG meeting the group moved to develop a schema that defined GeoSciML
> compatible map layers for simple map services (meeting note<https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/RomeF2FModelDesignMeetingNotes#14_Portrayal_classes_in_GeoSciML>,
> TWiki overview<https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/GeoSciMLThematicView>).
> Broadly speaking the intent is to promote:
> 1.        a consistent interface to web map data;
> 2.        the widespread us of controlled vocabularies in thematic
> mapping;
> 3.        the ability to share thematic mapping tools such as SLDs between
> map services and clients to allow simple map query and display use cases
> ('show me all units coloured by their lithology', ' show me all units that
> contain sandstone');
> 4.        provide a very simple entry level to the GeoSciML world,
> introducing the concepts of mapping to community defined vocabularies and
> understanding the full GeoSciML model.
> The primary result of this work will be a GML application schema that
> conforms to level 0 of the Simple Features Profile for GML (SF). It is a
> denormalised *view* of GeoSciML that corresponds to a GIS layer (one
> record per geometry) and can be used for portrayal and thematic mapping
> purposes.
>
> While it has been harmonized with GeoSciML (consistent naming conventions,
> broad mapping of properties) it is a schema in it own right. It  not a SF
> level 0 profile of GeoSciML, is not intended as a basis for setting up
> simple GeoSciML Web Feature Services, and is not intended as a simple query
> interface to GeoSciML. It is solely for representing geological features in
> simple map clients using simple map services.
> *
>
> REQUEST FOR COMMENT*
>
> An initial skeleton of a model has been compiled based on existing WMS
> layers (GeoScience Victoria and Arizona Geological Survey) and feedback from
> participants at the Rome meeting. Tables summarising the proposed layers
> have been posted here:
>
> https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/GeoSciMLThematicViewModelDiscussion
>
> We need feedback from a much broader group and invite interested parties to
> comment on the model and suggest changes where necessary. At the end of
> October a release candidate schema will be produced and tested as part of
> Testbed 4.
>
> We look forward to your feedback.
>
> Thanks*
>
> Alistair Ritchie**
> GEOSCIENCE VICTORIA* | EARTH RESOURCES DIVISION
> Department of Primary Industries | Melbourne, Victoria, Australia*
> Tel:* +61 3 9658 4512 | *Fax*: +61 3 9658 4555
> P* **Pensez à l'environnement avant d'imprimer ce message*
>       *Think Environment before printing*
> Le contenu de ce mél et de ses pièces jointes est destiné à l'usage
> exclusif du (des) destinataire(s) désigné(s) comme tel(s).
> En cas de réception par erreur, le signaler à son expéditeur et ne pas en
> divulguer le contenu.
> L'absence de virus a été vérifiée à l'émission, il convient néanmoins de
> s'assurer de l'absence de contamination à sa réception.
>
> The contents of this email and any attachments are confidential. They are
> intended for the named recipient(s) only.
> If you have received this email in error please notify the system manager
> or  the sender immediately and do not disclose the contents to
> anyone or make copies.
> eSafe scanned this email for viruses, vandals and malicious content.
>
> _______________________________________________
> auscope-geosciml mailing list *
> *auscope-geosciml at lists.arcs.org.au *
> *http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
> P* **Pensez à l'environnement avant d'imprimer ce message*
>       *Think Environment before printing*
>
> Le contenu de ce mél et de ses pièces jointes est destiné à l'usage
> exclusif du (des) destinataire(s) désigné(s) comme tel(s).
> En cas de réception par erreur, le signaler à son expéditeur et ne pas en
> divulguer le contenu.
> L'absence de virus a été vérifiée à l'émission, il convient néanmoins de
> s'assurer de l'absence de contamination à sa réception.
>
> The contents of this email and any attachments are confidential. They are
> intended for the named recipient(s) only.
> If you have received this email in error please notify the system manager
> or  the sender immediately and do not disclose the contents to
> anyone or make copies.
> eSafe scanned this email for viruses, vandals and malicious content.
>
>
>
> --
> This message (and any attachments) is for the recipient only. NERC
> is subject to the Freedom of Information Act 2000 and the contents
> of this email and any reply you make may be disclosed by NERC unless
> it is exempt from release under the Act. Any material supplied to
> NERC may be stored in an electronic records management system.
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
> "D卌#9ߓM4­Ÿԅ8Ԭ7 㓽‑[1]8b隊Vu?rۦk'(֢)ߢ*'ʞʧjW(z{bjPQ蚖\+╨‑uݾܢ mSLSM??⪓h?.֞ꫡۜy֝
> j^vܢi'翔㓔㓽‑[1] *+¸霢{‑ڟ m ޯ?ŸԿ<?"ͭ8ԟiǀ&"جzʨțXʇ텪޲*bz{mȞrG譩ݭ騽뢮랳?ŸԿ<?ڱૉl7!zz+޶آ
> 隊Xz讙^jǧ؟ʘ^靺?wj)]zWz+_ꬊ˞ݵ뭮'('b騵Ⱨm랲xjרʉ텨~檘ʧyاzf?ϼSM??⪗(??҈{c幫‑r쉗y֞~ަ
> )඘zf?ϼSM??⪛"ͭ 㓝)? _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
> ------------------------------
> Ÿԟiǀ&,ޘڭǿ㓔㓲ܥx[1](dNPЂ8}4ӀQSLSNȳ{aN57ڱૉS+‑jwZ&!魲fr?❺+b{ajجꬢvr߉ק&^eʚ⾩^皝ߨʩʸ
> ߅8ԅ8ԟiǀ&6Zڟۡ靭Ꞧǝi֩稭ʦ颱^w񎵱N57ڱૉpبۡz⢼+۞ʧ魡ayʩʸڰ꿔㓼SO󏔣S,ޘSM??⪒-ˡz
> 쉸ܨ~؞碦'ڜ社ڝڞ޾*?㓼SO󏔣S}‑[1]ȳ{b­ʋj??筆+‑w镦zz-랝׫o*޶ꧺfץzע蛪.̬隝מڨɩ
> 򲊢zƨޞZب+‑vڮ稚kƭz뺜؞w讦ܢ{Zw{aǦj) 㓼󅸔ߩǀ&rhMW稞ȝzay鯊'魭稭꫊{b
> aǦj) 㓼󅸔ߩǀ&,ޛ񎵹۲Ͼv짳ϝ)
>
> _______________________________________________
> auscope-geosciml mailing list
> auscope-geosciml at lists.arcs.org.au
> http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20101001/7b2b621a/attachment.htm>


More information about the GeoSciML mailing list