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: geopriv-bounces@ietf.org [mailto:geopriv-bounces@ietf.org] 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
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www1.ietf.org/mailman/listinfo/geopriv
Received on Thu, 21 Jul 2005 09:42:30 -0400
This archive was generated by hypermail 2.1.8 : Thu Jul 21 2005 - 09:52:45 EDT