Subject: [Geopriv] building GML in PIDF

From: Robert Sparks <[email-masked]>
Date: Fri, 29 Feb 2008 14:34:51 -0600

I've spent the last couple of days reading and re-reading the binary- 
lci related threads.

I'm thinking hard about how the group can make progress, and what the  
truly important things to make progress are on here.
Feel free to help me figure that out (change the subject line if  
that's what you are responding to - this subject is for the rest of  
the message).

Agreement about one thing in this thread is clear: GEOPRIV needs to  
clearly state how to build a PIDF document when handed a bare pair of  
lat/long coordinates.

There are a bunch of other things in those threads, but lets focus on  
that one thing for a moment.

To help separate this from DHCP and the discussions around the  
clarifications in the binary-lci document, let me put forth this use  
case.
It's a little (but only a little) contrived, but I hope it teases out  
one of the things we need to get clarity on.

Imagine an operator getting a call from someone where the transport  
or source of the call gave them no help on identifying where the  
problem spot was.
The only way that information is conveyed is verbal.
This could be someone radioing in from a boat, or someone with an old  
CB radio talking to a family member with a land line - whatever.
The person with the problem has some way to know their lat/long  
(lunars and declinations, an old GPS, something scribbled on the  
brass in the rock, again, whatever).

The operator gets, verbally, that the problem is at 49.0N, 114.0W.

What should the system the operator feeds that into emit (as a PIDF- 
LO in, for example, a LOST query)?

How is the answer different if operator gets 49.03N, 114.00W?

(For those who haven't followed the threads, there's growing  
understanding that simply putting those values in as
GML 3.0 points isn't the right thing to do, and we're trying to  
figure out what the right thing is).

Thanks,

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

---

From: "Brian Rosen" <[email-masked]>
Date: Fri, 29 Feb 2008 17:04:07 -0500

I don't think that you are actually helping us with the problem at hand.  I
think everyone would agree that if all you have is a lat/lon, you construct
a PIDF with it (meaning a point, with no value for confidence/uncertainty)
and press on.  I think everyone would agree that you send what you have, so
that if you have 49.03, 114.00, you send that, and don't drop significant
digits.  You shouldn't add any either, conversion from binary to floating
point to strings notwithstanding.

I think the problem really is DHCP.  It's what changes, if any, we should
put into DHCP, and how we describe how you make a PIDF from the data.

I think everyone agrees that if the docs are left as they are, that the
algorithm to create a PIDF from the DHCP result is obvious: a point with no
value for confidence and uncertainty.  The problems we are discussing are
that we differ on what ought to be in the DHCP return and we don't agree on
how we describe what we are sending via the protocol.

I'm not sure if James/Martin/Martin et. al. would agree that if DHCP
communicated a proper confidence and uncertainty that the current binary
point mechanism ought to stay as it is.  I personally think it should.
Marc/John assert that what is in there now is sufficient for the realistic
use cases.  I disagree, but I do think, from a practical matter, that
confidence and uncertainty won't be available in the measurements that the
likely users of the DHCP mechanism will have.  I just feel that it's proper
to include confidence and uncertainty, and the protocol ought to allow it.

It also seems to me that the obvious compromise is leave the binary point
mechanism, possible improve the wording describing what it means, and add
the ability to communicate confidence and uncertainty.  Confidence and
uncertainty would have to be optional.  I don't think there is any harm in
communicating significant binary bits.  

I think we remain wrapped around the axle in explaining what the
significance of those bits are with and without confidence and uncertainty.

Brian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Robert Sparks
> Sent: Friday, February 29, 2008 3:35 PM
> To: GEOPRIV
> Subject: [Geopriv] building GML in PIDF
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 01 Mar 2008 09:09:33 +0200

Thanks for the nice summary.

There are essentially three ways to solve this issue (based on my 
understanding):

(a) Express RFC 3825 information in GML
(b) Provide rules on how to transform RFC 3825 parameters into GML
Example can be found in 
http://tools.ietf.org/html/draft-ietf-geopriv-pdif-lo-profile-05#appendix-B
(c) Provide a way to make the translation simple
Example can be found at 
http://tools.ietf.org/wg/geopriv/draft-tschofenig-geopriv-dhcp-circle-00.txt

Case (a) is essentially telling the GML folks that they were wrong with 
what they did in the past. I would be interested to see how they react.

Case (b) leaves us with a fairly simple description but with some errors 
as that version of the PIDF-LO document explained.

Case (c) requires more work.

None of the approaches sound particularly great to me.

Ciao
Hannes