[Geopriv] Comments on geopriv-loc-filters-01

(I meant to re-read this document before the Prague meeting, but good intentions don't always suffice.)

After reading through again, I'm impressed by the degree of consistency of the solution. However, I think that a few changes would make it easier to implement.

And yes, I've raised these points before, but I can't remember any specific conclusions being reached.

<movedHoriz> / <movedVert>

These elements are well defined, no real comments here.

<speedExceeds>

This element is likewise well defined. However, the #mps is likely to cause problems with GML processors, which will search for a definition. I'm not aware of a stable reference for this, so I suggest that you define a URI, maybe something like:
  urn:ietf:params:xml:ns:location-filter#mps
For reference, I've included a GML derived unit definition at the end of this email for metres per second.

<valueChanges>

No complaints except to point out that the examples all rely on a deprecated namespace. Please update this section to refer to "urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" (and http://tools.ietf.org/html/draft-ietf-geopriv-revised-civic-lo-05)

<enterOrExit>

This element uses the gml:FeaturePropertyType, which has a richer content model than is required for this purpose. My suggestion is to simplify this to use gml:GeometryPropertyType instead.

This would also obviate the need for the undefined <my:ParkingBuilding> elements, which only increase implementation complexity. With the current definitions implementations need to recognize arbitrary element content based on its derivation from gml:Feature, which requires a complete schema parse (and access to schema); or at a minimum, they need to make some assumptions about content model.

In essence the change is trivial: change the base type, and remove a few layers from the example.

   <location-filter>
     <enterOrExit>
x-> <my:Building>
x-> <gml:name>Building 10</gml:name>
x-> <gml:extentOf>
           <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326"

In order to support your use of external objects (which I think is very useful for this sort of application), the xlink:href attribute actually goes on the enterOrExit element consistent with GML usage (refer to section 7.5.3 of GML-3.1.1):
  
   <location-filter>
      <enterOrExit xlink:href="http://example.com/buildings.xml#10"/>
   </location-filter>

This doesn't prevent the use of parts of an external feature collection. It only means that the reference needs to point to the geometry object within a feature, rather than the feature object.

The containment part seems to only use the name part of the feature. Is this the reason that you have persisted with Feature rather than Geometry? You should know that Geometry also permits naming:

   <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4326">
     <gml:name>Building</gml:name>
     <gml:exterior>...</gml:exterior>
   </gml:Polygon>

What purpose do you see the name serving in this context? I don't think that using it as a form of key is appropriate. If the intent is to avoid echoing entire geometries, then perhaps that would be better served by using ID attributes or something similar.

You can update the reference to the geo-shape document after its adoption by the OGC (in xml2rfc reference form):

  <reference anchor="GeoShape">
     <front>
        <title abbrev="Geo-Shape">GML 3.1.1 PIDF-LO Shape Application
          Schema for use by the Internet Engineering Task
          Force (IETF)</title>
        <author initials="M." surname="Thomson" fullname="Martin Thomson">
           <organization>Andrew Corporation</organization>
        </author>
        <author initials="C." surname="Reed" fullname="Carl Reed, PhD.">
           <organization>Open Geospatial Consortium Inc.</organization>
        </author>
        <date month="December" day="26" year="2006"/>
     </front>
     <seriesInfo name="Candidate OpenGIS Implementation Specification"
       value="06-142, Version: 0.0.9"/>
   </reference>

Cheers,
Martin


p.s. A GML dictionary that defines metres per second is included below. Note: I don't have a stable reference for seconds either, so those are included as a base unit.
--
<gml:Dictionary xmlns:gml="http://www.opengis.net/gml"
                xmlns:xlink="http://www.w3.org/1999/xlink">
  <gml:description>Units of measure for use in location filters.</gml:description>
  <gml:name>geopriv-loc-filters units of measure</gml:name>
  <gml:dictionaryEntry>
    <gml:BaseUnit gml:id="s">
      <gml:description>A second, the SI base unit.</gml:description>
      <gml:name>second</gml:name>
      <gml:quantityType>Time</gml:quantityType>
      <gml:catalogSymbol>s</gml:catalogSymbol>
    </gml:BaseUnit>
  </gml:dictionaryEntry>
  <gml:dictionaryEntry>
    <gml:DerivedUnit gml:id="mps">
      <gml:description>Meters per second, used as a measure of speed.</gml:description>
      <gml:name>meters per second</gml:name>
      <gml:quantityType>Speed</gml:quantityType>
      <gml:catalogSymbol>mps</gml:catalogSymbol>
      <gml:derivationUnitTerm uom="urn:ogc:def:uom:EPSG::9001" exponent="1"/>
      <gml:derivationUnitTerm uom="#s" exponent="-1"/>
    </gml:DerivedUnit>
  </gml:dictionaryEntry>
</gml:Dictionary>
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]

_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Sun, 25 Mar 2007 19:05:37 -0500