Subject: RE: [Geopriv] PIDF-LO needs a "derived from another form" method

From: "Abbott, Nadine B" <[email-masked]>
Date: Thu, 21 Jul 2005 09:42:30 -0400

The Short:
I agree with Marc's position that you should always include the
original. And I also agree that if converted/transformed location
information is included, it should be possible to distinguish it from
"original."
Is it worth considering a way to include it in ADDITION to the mechanism
used to identify the Method by which the location information was
acquired?

Longer digression:
>From the point of view of the entity receiving the location information,
when an endpoint acquires location information from a third party--using
DHCP, LLDP-MED, application layer (e.g., HELD), or whatever--the method
is of some interest in distinguishing location that was ACQUIRED this
way from location that was MEASURED by the device or that was entered
locally by a human user or device.  Distinguishing the method also may
provide for some sense about the potential for accuracy (with various
methods, the endpoint may be more or less closely associated with the
location of the access point in the wiremap).

However, when location is acquired via DHCP (or LLDP-MED or HELD) from a
third party, the method doesn't really tell you how the location
information was created in the first place. The location information
maintained by the third party in its "wiremap" may have been populated
in various ways that may affect its relevance/accuracy.  For example: it
may have been derived from a wire map maintained meticulously by a
dedicated IT staff or it may have been guesstimated from floor plan; it
may have been "measured" at the access point (e.g., wall jack) by a tech
with a handheld GPS device; in non-enterprise scenarios, it may have
been derived using automated mechanisms involving
communications/associations among multiple organizations/entities.  Both
civic AND geo may be "original".  So, when location information is
acquired, knowing the way the location information was created
(measured, manual entry) may have at least as much to do with how useful
the data is as the method by which it was acquired.  
One possibility is a data creation parameter (e.g., manual entry,
measured, converted);
Another possiblity might be replacing "DHCP" (or "LLDP-MED" or "HELD")
method with something like "acquired-manual", "acquired-measured,"
"acquired-converted"?  
This might also apply to the case when the method is user/manual entry.
The user may have looked at a map, measured with a handheld device or
used a conversion program. 
I suppose this could mushroom if we had to apply it to other methods as
well.
The more complexity, the more room for error, and the more likely it is
to get ignored.
May be simpler to just add another parameter to mark
converted/derived/transformed location.

Nadine Abbott  

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ted Hardie
Sent: Wednesday, July 20, 2005 7:02 PM
To: Marc Berryman; Brian Rosen; GEOPRIV
Cc: Cindy Clugy
Subject: RE: [Geopriv] PIDF-LO needs a "derived from another form"
method

At 4:29 PM -0500 7/20/05, Marc Berryman wrote:
>Give me the original, unadulterated, raw, un-massaged data, and give it

>to me in a way I can tell it is the original data. I think that will be

>a rallying call from the majority of the PSAP's.
>
>The PSAP's know their local area better than anyone else (except maybe 
>the firemen), they will (probably) not want any helpful service doing 
>the translation for them, when they know their area and the day-to-day 
>changes to the local geography.
>
>
>Marc B

Please remember that PIDF-LO will be used in many contexts outside
emergency services; having a mechanism that fits those contexts need not
impact the emergency service context at all. The transformation method
may well end up being more prominent in those use cases than in
emergency services.

			regards,
				Ted

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

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

---

From: Andrew Newton <[email-masked]>
Date: Thu, 21 Jul 2005 11:45:29 -0400

Nadine,

This is well stated, and I agree with what you are saying.

> converted/derived/transformed location.

If I acquire location via DHCP, what I know is that I got it from  
DHCP.  Not that it was converted or derived.

So I'm not really sure these will be used.

I do agree that if there are two pieces of information, and one is  
the original and the other is derived, then they should both be sent  
and both marked appropriately as to what they are.

I guess I'm just not understanding Brian's use case of when this  
derivation occurs.

-andy

---

From: "Brian Rosen" <[email-masked]>
Date: Thu, 21 Jul 2005 12:00:31 -0400

While I don't think it will often occur if location is obtained via DHCP, it
could happen.  A more common case I expect is where location is obtained
from the application level protocol being discussed.  I think that some
implementations will try to be helpful, and return both a civic and a geo.
One of them will be the "original", and one they will derive from the
original.  The argument goes that the users of location are varied, and some
would prefer civic, some would prefer geo, and some actually need both.  An
example of the latter is, "find the nearest Pizza Hut, and deliver a pizza".
"Find the nearest" is best done with a geo.  "Deliver" is best done with a
civic.

We need to know which data is the original data, and which was derived from
the original data.  We have to mark them clearly.

Now, I personally don't think sending both is a good idea, primarily because
I think the recipient will have no idea what the quality of the conversion
is, and we know quality of geocode databases varies considerably.  I think
they would prefer to take the original, and convert it themselves, with a
database they understand the quality of.  But that is not a belief shared by
all, and if we are going to permit sending both, we need to mark them
appropriately.  That's what I'm asking for.

Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Andrew Newton
Sent: Thursday, July 21, 2005 11:45 AM
To: Abbott, Nadine B
Cc: GEOPRIV
Subject: Re: [Geopriv] PIDF-LO needs a "derived from another form" method

Nadine,

-andy