Subject: Re: question about GML 3.0

From: [email-masked]
Date: Wed, 02 Jul 2003 18:22:53 -0600

Jon -

The following feedback from two GML guru's from Galdos. Hope this is of use.

Cheers

Carl

Comments  by David Burggraf (Galdos) on:
---------------------------------------
2.2.1 'location-info' element
"...In order to ensure interoperability of GEOPRIV implementations, it is
necessary to select a baseline location format that all compliant
implementations support (see REQ 3.1). At this time, there is not sufficient
working group consensus within the GEOPRIV WG to award this distinction to
any particular location format. Without applying any particular selection
criteria (apart from REQs 2.5.1), this document works from the assumption
that GML 3.0[14] will be this mandatory format (MUST implement for all PIDF
implementations supporting the 'geopriv' element).

The Geography Markup Language (GML) is an extraordinarily thorough and
versatile system for modeling all manner of geographic topologies and
objects. The simplest package for GML supporting location information is the
'feature.xsd' schema. Various format descriptions (including
latitude/longitude based location information) is supported by Feature (see
section 7.4.1.4 of [14] for examples). This resides here:

urn:opengis:specification:gml:schema-xsd:feature:v3.0
</xs:schema>

Note that by importing the Feature schema, necessary GML baseline schemas
are transitively imported.

Complex features (such as modeling topologies and polygons, directions and
vectors, temporal indications of the time for which a particular location is
valid for a target) are also available in GML, but require importing
additional schemas. For the purposes of this document, only support for the
feature.xsd GML schema is REQUIRED."
----------------------------------------

[Galdos-DB] I think a GML Profile similar to GML4XLS.xsd, which is a GML
profile used by OGC Location Services schemas (OLS/XLS schemas) may be
appropriate here. In short, a profile of GML allows one to select only the
pieces of GML and their dependencies that are needed for a particular
application domain. This would allow one to keep some of the more richly
descriptive part of GML and prune off additional baggage that is carried by
importing one or more of the 28 GML core schemas.

Diagrammatically the idea is as follows:

GML3  --select & restrict --> GML4LocationObject profile -- extend &
include -->
Location Object schema

A GML profile acts as a restriction of GML to produce types and elements
consistent with the complete GML 3 but restricting out some optional
particles. The application schema can then use these types as a common base
to
create new types and elements by extensions or inclusion.

A brief summary of the rules for a profile (from the GML3 specification)
are as follows:

1.      A profile of GML is a logical restriction of a subset of GML.

2.      A profile must not change the name, definition, or data type of
mandatory GML elements or attributes.

3.      The relevant schema or schemas that define a profile must use in
the core gmlnamespace http://www.opengis.net/gml.

4.      An application schema may extend and use types from the profile,
but must do so in its own namespace, and not use http://www.opengis.net/gml.

The functional test of these rules is:

In any instance document for an application schema using a GML profile
will be valid against the same application schema if the GML profile is
replaced by the complete GML schema. Further, the interpretation of that
document would be the same regardless of which of the two schemas were
used.

General questions from Ron:
Hi Carl:

A few of issues.
I assume that they selected feature.xsd because it contains the very
extensive (too extensive in my view) location property - and the objects
LocationString and LocationKeyword. In effect it seems that they only need
LocationString, LocationKeyword and Point ?  (Since we failed in our attempt
with address).  They can use ONLY these objects and not create a feature.
Do you have any idea whether they need a feature?  Do they see their
location object as a feature? (I would argue it is not!).
On the size issue of course this is generic to XML.  We can propose a binary
encoding of the GML (e.g. BIM as in MPEG-7) - BinXM. This reduces the size
by a factor of 5-7 or in some cases more.
David B. has suggested they profile GML for their purposes and I think this
is a good idea - although picking out ONLY the elements they need and the
dependent ones is even better.
Cheers

Ron

----- Original Message -----
From: "Peterson, Jon" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 30, 2003 5:04 PM
Subject: RE: question about GML 3.0

>
> Thanks, Carl, I've had a look at this. The Address ADT does look like a
> useful starting point for us.
>
> - J
>
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Monday, June 30, 2003 8:18 AM
> > To: Peterson, Jon
> > Subject: Re: question about GML 3.0
> >
> >
> > Hi Jon -
> >
> > Sorry for the slight delay.  The OGC Membership has done a
> > fair amount of
> > thinking and work on a geospatial service called "geocoding".
> > Geocoding is
> > the process of transforming a textual string, such as an
> > address, into a
> > geometry (location/x,y coordinate). Obviously, in order for
> > the service
> > interface to operate and be usable internationally, the issue
> > of defining an
> > abstract data type (ADT) "address" has been of considerable
> > thought. The OGC
> > itself has not and will not define an address content
> > standard. However, our
> > interfaces need to be able to deal with addresses from any country.
> > Therefore, the need for an ADT.
> >
> > I have attached a document that defines our newest set of
> > adopted OpenGIS
> > interface specifications. These interfaces were originally
> > defined for the
> > location services market space but will work in just about
> > any context.
> > Embedded in this document is a discussion of address, the
> > address ADT, and
> > GML/XML schema for type "address". I removed a number of
> > figure to keep the
> > file size reasonable :-)
> >
> > There is also a public OGC discussion paper on geocoding (also good
> > discussion of address) from our web site (www.opengis.org).
> > On the home
> > page, follow the Discussion Paper link and look for Geocoding.
> >
> > Hope this is of use -
> >
> > Cheers
> >
> > Carl
> >
> > ----- Original Message -----
> > From: "Peterson, Jon" <[email-masked]>
> > To: <[email-masked]>
> > Sent: Thursday, June 26, 2003 3:47 PM
> > Subject: question about GML 3.0
> >
> >
> > >
> > > I have a question about GML 3.0 that I hope you or your
> > associated in
> > > OpenGIS might answer - is there a gml:StreetAddress schema
> > or similar
> > > feature for civil location? I've seen some web references
> > that suggest
> > that
> > > this was at least considered for GML 3.0, but I don't see
> > anything in the
> > > main document about it.
> > >
> > > - J
> >