Thanks for that work - i will incorporate it soon into a new revision.
Some comments inline
> <figure><artwork><![CDATA[
> p = crsp / uncertaintyp / parameter
> uncertaintyp = ";uncertainty=" pnum
> num = [ "-" ] pnum
> pnum = 1*DIGIT [ "." 1*DIGIT ]
> ]]></artwork></figure>
What about shortening the "uncertainty" parameter name for brevity, for
example to "u"?
> <!-- BTW, this is needed for extensibility: crsp = "wgs84" /
> 1*( alphanum / "-" ) -->
Well. This circles around the issue of "allowing" vs "not precluding". I
deliberately left that out of the current specification, and would have
expected documents adding new CRSes to update the "crsp" component of
the ABNF - and would remove the need for a "crs" parameter value
registry at this point (with being just one CRS defined).
This is a question how "open" we want to be at this point.
> <!-- New section above 4.4.3 -->
>
> <section title="Location Uncertainty">
> <t>The 'uncertainty' parameter indicates the amount of
> uncertainty in the location as a value in meters. Where a
> geo URI is used to identify the location of a particular
> subject, uncertainty indicates the uncertainty with which the
> location of the subject is known.
> </t>
>
> <t>The 'uncertainty' parameter is optional and it can appear
> only once. If no uncertainty is specified, this indicates
> that uncertainty is unknown or unspecified. If the intent is
> to indicate a specific point in space, uncertainty MAY be set
> to zero. Zero uncertainty and absent uncertainty are never
> the same thing.
> </t>
> </section>
Can we refer to some previous work on how "uncertainty" is defined?
> <!-- BTW, you need to s/EPSG:6.6:/EPSG::/g - the "6.6" is
> not used in PIDF-LO [RFC5491] -->
Ack.
> <!-- Comment on Section 7
> There is a great deal of duplication here - the mappings
> are effectively duplicated throughout. The from geo to GML
> are exactly the same as the from GML to geo sections with the
> order inverted. I don't think this adds value. -->
Ack. Will change.
> <!-- Second comment on Section 7
> It's worth noting in general that GML uses the 'double' type
> from XML schema and that these examples assume that numbers
> in the form 3.59233e2 in GML are properly converted to
> decimal when placed in the 'geo' URI.
> -->
Ack.
> <!-- Section 7 -->
>
> <section title="2D GML 'Point'">
> <t>A 2D GML <xref target="RFC5491">'Point'</xref> is
> constructed from a 'geo' URI that has two coordinates and an
> uncertainty parameter that is absent or zero. A GML point is
> always converted to a 'geo' URI that has no uncertainty parameter.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <Point srsName="urn:ogc:def:crs:EPSG::4326"
> xmlns="http://www.opengis.net/gml">
> <pos>%lat% %lon%</pos>
> </Point>
> ]]></artwork></figure>
>
> <t>Note that a 'geo' URI with an uncertainty value of zero is
> converted to a GML 'Point', but a GML 'Point' cannot be
> translated to a 'geo' URI with zero uncertainty.
> </t>
You saying that the uncertainty parameter must be left out, because GML
does not specify it?
> </section>
>
> <section title="3D GML 'Point'">
> <t>A 3D GML <xref target="RFC5491">'Point'</xref> is
> constructed from a 'geo' URI that has three coordinates and
> an uncertainty parameter that is absent or zero. A GML point
> is always converted to a 'geo' URI that has no uncertainty parameter.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%,%alt%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <Point srsName="urn:ogc:def:crs:EPSG::4979"
> xmlns="http://www.opengis.net/gml">
> <pos>%lat% %lon% %alt%</pos>
> </Point>
> ]]></artwork></figure>
>
> </section>
> <section title="GML 'Circle'">
> <t>A GML <xref target="RFC5491">'Circle'</xref> is
> constructed from a 'geo' URI that has two coordinates and an
> uncertainty parameter that is present and non-zero.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%;uncertainty=%unc%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4326"
> xmlns:gml="http://www.opengis.net/gml"
> xmlns:gs="http://www.opengis.net/pidflo/1.0">
> <gml:pos>%lat% %lon%</gml:pos>
> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
> %unc%
> </gs:radius>
> </gs:Circle>
> ]]></artwork></figure>
>
> </section>
>
> <section title="GML 'Sphere'">
> <t>A GML <xref target="RFC5491">'sphere'</xref> is
> constructed from a 'geo' URI that has three coordinates and
> an uncertainty parameter that is present and non-zero.
> </t>
> <figure><preamble>'geo' URI:</preamble>
> <artwork><![CDATA[
> geo:%lat%,%lon%,%alt%;uncertainty=%unc%
> ]]></artwork></figure>
> <figure><preamble>GML document:</preamble>
> <artwork><![CDATA[
> <gs:Sphere srsName="urn:ogc:def:crs:EPSG::4979"
> xmlns:gml="http://www.opengis.net/gml"
> xmlns:gs="http://www.opengis.net/pidflo/1.0">
> <gml:pos>%lat% %lon% %alt%</gml:pos>
> <gs:radius uom="urn:ogc:def:uom:EPSG::9001">
> %unc%
> </gs:radius>
> </gs:Sphere>
> ]]></artwork></figure>
>
> </section>
>
> <-- I think that's it. I'm in two mins on the need for
> including anything special in comparison. On the one hand, I
> don't like the idea that each parameter gets special
> treatment. And special treatment is not possible for any
> extensions made to the format, making this a form of
> favouritism. On the other hand, numerical comparison makes
> sense for this parameter... -->
Yes, it's a hard issue. But given that we cannot foresee what future
parameters will be created, i don't think we can create generic language
on parameter comparison (unless we reduce it to textual comparison on
_all_ parameters).
Thanks again for the great (and amazingly quick!) work.
Alex
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
