OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [emergency] FYI: Discussion of the OSAIS GML where profile and the OGC GML Simple Features profile.


Carl, 

Thanks for this update and summary of the issues and status of the candidate standards and profiles for the TC to consider going forward. 

I encourage everyone to review this material as well as the posts Carl has made to the document repository.  This is core information in all of our EDXL work and we need to be sure to understand the issues and available paths forward in order to make a decision going forward. 

Regards,
Elysa

At 08:40 PM 11/8/2010, Carl Reed wrote:
At the last OASIS EM TC GIS Subcommittee call, we had an excellent discussion on encoding requirements for geospatial content in OASIS EM standards. The discussion included new requirements, such as geopolitical boundaries with attributes (properties), what the OASIS GML "where" profile supports and does not support, and what NENA and the IETF have been doing. I also spoke briefly about the OGC Simple Features GML profile. The attached document discusses the key concepts related to the GML information model: Geometry and Feature. Please read this document before moving onto the following discussion.
 
The OASIS GML Where profile as implemented according to OASIS EM requirements (also attached) is a set of geometry elements. There is no concept of feature (although the schema could be easily extended to include the feature model). Since feature is not part of the OASIS GML where profile as defined, you can only encode geometries and some metadata (coordinate reference systems) and not features. So, layers of map data such as geopolitical boundaries that include names and other attributes cannot be encoded using the OASIS GML Where profile. A separate encoding would be required.
 
Conversely, if a GML profile includes the feature model, then not only geometries but features can be encoded. So geopolitical boundaries with names and other attributes (population, contact names, etc) or a plume geometry could also include time and date stamps, plume type, plume direction, model name used to generate the plume model, and so for than be encoded using GML.
 
The OGC has an existing standard called OGC GML Simple Features profile. This profile is available for GML 3.1.1 and GML 3.2. GML 3.2 is the joint OGC/ISO standard. The profile support numerous geometries as well as the full feature model. The geometry types supported are: points, multipoints, linestrings, curves, polygons (surface), multicurve, multisurface, and agregates (combinations of all of these types). The only type as specified in the OASIS EM requirements for a geospatial encoding that is not supported is type "circle". GML supports multiple methods for expressing circles but the Simple Features profile does not include that element. However, there is already an OGC change request to add circle to GML Simple Features. http://portal.opengeospatial.org/files/?artifact_id=39853 to download the OGC standard.
 
Now, obviously, GML Simple Features would introduce additional complexity in that more types as well as the Feature Model are supported. However, the standard actually specifies three conformance levels. These are described at the bottom of the attached document on GML. The most restrictive level is level 0. Level 0 is fairly lightweight and fairly easy to implement.
 
An example of the use of the GML Simple Features standard is the XML schema and encoding data for the NENA NG 911 GIS model. Last Friday I uploaded these documents to the OASIS document archive and sent an email with the links. NENA decided os this approach because ALL of the geospatial technology providers that sell GIS solutions to the local government in the US and Canada support the ability to ingest GML encoded payloads. The NENA GIS model includes geopolitical (jurisdictional) boundaries.
 
There are a number of other important aspects of GML SF. These include support for feature collections, internationalization, metadata, measurements, and dictionaries (code lists). An example of a GML SF encoding is included in the NENA documents.
 
Regards
 
Carl Reed, PhD
CTO and Executive Director Specification Program
Open Geospatial Consortium
www.opengeospatial.org
 
The OGC: Making Location Count!
 
---------------------
 
This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender  immediately by return email and delete this communication and destroy all copies.
 
"The important thing is not to stop questioning." -- Albert Einstein
"Security is mostly a superstition. It does not exist in nature. Life is either a daring adventure or nothing." -- Helen Keller


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]