Subject: [Geopriv] Geopriv Policy Draft Update 2

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 10 Dec 2006 18:01:22 +0100

-- another try; my previous mail contained wrong links.

Hi all,

as discussed at the last Geopriv meeting I have compiled a draft update. 
Please find it here:
http://www.tschofenig.priv.at/drafts/draft-ietf-geopriv-policy-09.txt

I might need to clean-up the geospatial location part a bit as well but 
I wanted to submit the current version to give everyone the chance to 
send comments. James Winterbottom has already done a review. Thanks!

You can see the changes here:
http://tools.ietf.org/rfcdiff?url1=http://www.tschofenig.priv.at/drafts/draft-ietf-geopriv-policy-08.txt&url2=http://www.tschofenig.priv.at/drafts/draft-ietf-geopriv-policy-09.txt

Ciao
Hannes

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 10 Dec 2006 17:11:13 -0600

Briefly,

The update to use the revised civic object is good, but I question why you need to use the type rather than the element directly.  Why not simply reference the civicAddress element?  I understand that this is a limitation of the RFC 4119 format, which did not define an element, but that shouldn't be necessary any longer.

Why not use the shapes defined in geo-shape?  You could permit a range of shapes then, without necessarily imposing any additional implementation cost - indeed, if geo-shape is implemented, then this is less because those shapes can be interpreted in the same way.  (Yes, capabilities would be affected, but I don't see that as a major problem.)

The URN used in the example for crsName is not registered; why not use those already defined elsewhere?

Section 5.2.1 of geo-shape recommends that polygons are defined in a counterclockwise direction.  It would be helpful if this were consistent.  The example may need to be changed.

I also don't see any real benefit in showing the extra common policy elements in the examples.  The identity stuff doesn't add any value (a comment indicating the presence of other conditions would be sufficient).

Cheers,
Martin

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Monday, 11 December 2006 4:01 AM
> To: [email-masked]
> Subject: [Geopriv] Geopriv Policy Draft Update 2
> 
> http://www.tschofenig.com/drafts/draft-ietf-geopriv-policy-09.txt
> 
> http://tools.ietf.org/rfcdiff?url1=http://www.tschofenig.com/drafts/draft-
> ietf-geopriv-policy-08.txt&url2=http://www.tschofenig.com/drafts/draft-
> ietf-geopriv-policy-09.txt
> 
> Ciao
> Hannes
> 
> 
> 
------------------------------------------------------------------------------------------------
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: "Tschofenig, Hannes" <[email-masked]>
Date: Mon, 11 Dec 2006 00:36:04 +0100

# Hi Martin, 
 
# thanks for the quick comments. 

-----Ursprüngliche Nachricht-----
Von: Thomson, Martin [mailto:[email-masked]] 
Gesendet: Montag, 11. Dezember 2006 00:11
An: Hannes Tschofenig; [email-masked]
Betreff: RE: [Geopriv] Geopriv Policy Draft Update 2

Briefly,

# I wonder what the benefit would be expect that the element name would be different. 
Currently, I tried to have 
<gp:geo-location/>
And 
<gp:civic-location> 

With the change this would turn into

<gp:civicAddress>
And 
<gp:civic-location> 

I don't have a strong preference here. 

# James has provided these comments already. 

# You are referring to the usae of geo-shapes for the conditions element. Right? Not for the transformation? Are you OK with the transformation part? 
I was a bit concerned about the complexity but the idea has convincing arguments, I agree. 

In particular, you want todo the following: Take http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-geo-shape-02.txt. Reference one of the elements in geo-shapes from the child element of the <conditions> / <gp:location>. Which element should I reference to fully understand your proposal, i.e., what shapes would I support?

Would I have to wait for OCG to complete their work on geo-shapes or is there a simpler appoach? 

# That's a good point. This aspect would go away if we switch to geo-shapes. 

# We defined it first :-)
# I have no problem with it either way. 

# That's true. They do not provide additional value -- they just show the bigger picture. I thought that's useful. But I don't really have a strong opinion here either. I does not really matter. 

# Ciao
# Hannes

Cheers,
Martin

> http://tools.ietf.org/rfcdiff?url1=http://www.tschofenig.priv.at/drafts/draft-
> ietf-geopriv-policy-08.txt&url2=http://www.tschofenig.priv.at/drafts/draft-

---

From: "Thomson, Martin" <[email-masked]>
Date: Sun, 10 Dec 2006 18:30:39 -0600

Hi Hannes,

Comments inline...

> From: Tschofenig, Hannes [mailto:[email-masked]]
> Sent: Monday, 11 December 2006 10:36 AM
> To: Thomson, Martin; Hannes Tschofenig; [email-masked]
> Subject: AW: [Geopriv] Geopriv Policy Draft Update 2
> 
> # Hi Martin,
> 
> The update to use the revised civic object is good, but I question why you
> need to use the type rather than the element directly.  Why not simply
> reference the civicAddress element?  I understand that this is a
> limitation of the RFC 4119 format, which did not define an element, but
> that shouldn't be necessary any longer.
> 
> Why not use the shapes defined in geo-shape?  You could permit a range of
> shapes then, without necessarily imposing any additional implementation
> cost - indeed, if geo-shape is implemented, then this is less because
> those shapes can be interpreted in the same way.  (Yes, capabilities would
> be affected, but I don't see that as a major problem.)
> 
> # You are referring to the usae of geo-shapes for the conditions element.
> Right? Not for the transformation? Are you OK with the transformation
> part?

I was referring to conditions only.  On consideration, the transformation should probably mention that any value of 'r' should be added to any uncertainty (actually r/2 in either direction).  That could be tricky (but not impossible) for some shape types.  Maybe out would be easier to reduce this to horizontal and vertical.  Metres are easier to understand than a shift in degrees as well.

Some more discussion is probably helpful on this point.  

[[And to satisfy Note Well, there is a remote possibility that we could touch on Andrew-owned IPR in this area, maybe.]]

> 
> In particular, you want todo the following: Take
> http://tools.ietf.org/wg/geopriv/draft-thomson-geopriv-geo-shape-02.txt.
> Reference one of the elements in geo-shapes from the child element of the
> <conditions> / <gp:location>. Which element should I reference to fully
> understand your proposal, i.e., what shapes would I support?

I would recommend that the approach I recommended for LoST be taken.  Simply refer to gml:_Geometry in schema and leave the options open.  Then limit the mandatory shapes to just Polygon.

> Would I have to wait for OCG to complete their work on geo-shapes or is

I don't know about this, I haven't received an update on progress in a while.

> Section 5.2.1 of geo-shape recommends that polygons are defined in a
> counterclockwise direction.  It would be helpful if this were consistent.
> The example may need to be changed.
> 

:) I presume it was just an arbitrary pick; the order in geo-shape has a specific reason.

> 
> I also don't see any real benefit in showing the extra common policy
> elements in the examples.  The identity stuff doesn't add any value (a
> comment indicating the presence of other conditions would be sufficient).
> 
> # That's true. They do not provide additional value -- they just show the
> bigger picture. I thought that's useful. But I don't really have a strong
> opinion here either. I does not really matter.
> 
> # Ciao
> # Hannes
> 
> 
> Cheers,
> Martin
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 11 Dec 2006 23:09:04 +0100

Hi Martin,

> [[And to satisfy Note Well, there is a remote possibility that we could touch on Andrew-owned IPR in this area, maybe.]]

Nice.

> I would recommend that the approach I recommended for LoST be taken.  Simply refer to gml:_Geometry in schema and leave the options open.  Then limit the mandatory shapes to just Polygon.

You are referring to
http://www.ietf.org/internet-drafts/draft-ietf-ecrit-lost-02.txt

We don't make use of

gml:_Geometry

> I don't know about this, I haven't received an update on progress in a while.
But are we going to introduce a dependency here or not?

> :) I presume it was just an arbitrary pick; the order in geo-shape has a specific reason.
I guess I have to read the geo-shapes draft.

Ciao
Hannes

---

From: "Thomson, Martin" <[email-masked]>
Date: Mon, 11 Dec 2006 16:57:27 -0600

Hi Hannes,

I'll trim this down, it's getting hard to find the necessary pieces.

> > I would recommend that the approach I recommended for LoST be taken.
> > Simply refer to gml:_Geometry in schema and leave the options open.
> > Then limit the mandatory shapes to just Polygon.
>
> You are referring to
> We don't make use of gml:_Geometry

I just looked, and you have probably seen my comments on the ECRIT list.

> But are we going to introduce a dependency here or not?

I think that if you went with gml:_Geometry, then you would have the simpler approach.  That would allow the draft to progress.  An informational reference to geo-shape would be helpful to implementers, but if that were not possible, you could progress without it.  This means that you need to specify Polygon as a MUST, which only requires normative reference to the GML spec.

Cheers,
Martin

---

From: [email-masked]
Date: Mon, 11 Dec 2006 18:06:57 -0500 (EST)

To add to the information mix, I will be asking the OGC membership to
approve the GeoShapes document as an OGC Best Practices document. Doing so
will make the document and its technical content an official position of
the OGC and the membership. As such, the document and its content can be
viewed as a stable resource referenced as either normative or informative
by other standards organizations. An OGC Best Practices document is one
step below an official adopted OGC standard. That is the next step.

FYI, I am also asking the OGC Location Services folks to consider
GeoShapes as a component of the enhanced geometry model they are working
on in order to harmonize the OGC locations services interface work with
GML and OMA.

Regards

Carl
OGC

>> >> Would I have to wait for OCG to complete their work on geo-shapes or
>> is
>> >> there a simpler appoach?
>> >
>> > I don't know about this, I haven't received an update on progress in
>> a
>> while.
>> >
> I think that if you went with gml:_Geometry, then you would have the
> simpler approach.  That would allow the draft to progress.  An
> informational reference to geo-shape would be helpful to implementers, but
> if that were not possible, you could progress without it.  This means that
> you need to specify Polygon as a MUST, which only requires normative
> reference to the GML spec.
>
> Cheers,
> Martin

---

From: [email-masked]
Date: Wed, 13 Dec 2006 17:03:53 -0500 (EST)

Hannes -

Just to add to Martin's comments:

1. I think you need to be very clear that the encoding for geographic
coordinates is lat-long. This is in compliance with GML 3.1.1 and now the
(almost) ISO approved GML as well as ISO 6709.

2. crsName="urn:ietf:params:xml:ns:geopriv-policy:crs:wgs84" . The OGC
will be submitting an OGC URN proposal to the IETF - probably next week.
The OGC already has approved standards that document how to use the OGC
urn for expressing CRS. Also, there will soon be a publicly available
registry of CRSs (the EPSG ones). For consistency and correct usage,
perhaps the OGC URN CRS approach should be used.

3. I believe that altitude is actual height above the above the local
reference ellipsoid and not the sphere.

Cheers

Carl

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 14 Dec 2006 14:11:24 +0100

Hi Carl,

> (almost) ISO approved GML as well as ISO 6709.
Ok.

> perhaps the OGC URN CRS approach should be used.
Sounds very good. Looking forward to see the document.

> reference ellipsoid and not the sphere.
James wrote this paragraph. I will forward it to him.

Ciao
Hannes

---

From: "James M. Polk" <[email-masked]>
Date: Thu, 14 Dec 2006 17:48:20 -0600

>James wrote this paragraph. I will forward it to him.

I'm ok with ellipsoid in this regard