RE: AW: [Geopriv]Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

["Abbott, Nadine B" <[e-mail]>]

My two cents...

Altitude/floor are needed for dispatch purposes, so they need to be
carried with the call.
I think it makes sense to allow civic floor to be carried with geo
coordinates, if it is available.
GPS coordinates are going to be determined using devices with various
capabilities.  Not all GPS devices even calculate altitude.  It makes
sense to me to allow this information to be supplemented with floor
where it is known.  In addition to the problem of definition of altitude
relative to the geoid, as Marc Berryman reminded us, calculating floor
from altitude is not uniform, but structure dependent--floor heights are
not uniform.

While we have postulated the possible use of altitude/floor to assist in
routing determination at some point in the future, at least right now in
North America altitude/floor are not part of any existing validation or
call routing/mapping data.  When/if altitude/floor are used for call
routing/mapping determination, probably both would need to be supported
in the routing/mapping database, but it may make sense to say that only
one or the other should be included should be included with
latitude/longitude coordinates in the mapping request.  

:) Nadine 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On
Behalf Of Brian Rosen
Sent: Wednesday, July 13, 2005 5:38 PM
To: 'Marc Linsner'
Cc: 'GEOPRIV'
Subject: RE: AW:
[Geopriv]Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00


A) I take issue with your argument.  I do not think it is possible to
obtain a geo with a floor measurement except by conversion from a civic
or some mashing of a civic and a geo; no device would measure such a
thing.  You can compute accurate altitude reasonably easily; just do
that.  I don't like conversion, but if you do it, do it with an accurate
conversion, and get accurate altitude.

Knowing that I am at 32 23 12N 12 27 15W has few uses unless I had
access to/knowledge of the surveyor/engineering plans for the structure
and an accurate internal floor plan.  Add altitude and nothing changes.

B) 1)Agree that maintaining civic databases (which is an ecrit, not a
geopriv issue) has costs.  Maintaining a GIS with accurate floor plans
and surveyor accurate structure locations, all correlated, has more
costs.  I like the idea that we get to the latter, but we have the
former, and maintaining it for a while seems like a no brainer compared
to creating the latter.

2) Agree that civic needs precision to be unambiguous.  Agree that
validation databases are a necessary evil until we have GIS systems that
have parcel, altitude and floor plans.  Again, we have the civic
databases, we don't have the GIS systems.  Unless you want to wait until
we do, give up now.

3) I'll accept the argument that geopriv needs to support both geo and
civic.  The argument here is whether geo needs to support floors.
Henning, and I, say no, it doesn't.  

4) Agree that precision is part of a geo spec.  Uncertainty, as you
know, is a more complex issue, for which simple bits of precision is
inadequate.  Yet another problem with geo.  I'm not an expert, so me
offering solutions is probably pointless.

5) Agree geopriv doesn't care if you have a GIS

Conclusion: Geopriv has to handle civic and geo in all use cases.
Choice of formats is up to the use case, and not up to geopriv.  Arguing
one is better than the other is pointless.  

However, altitude expressed in floors within a geo is an idea whose time
will never come.

Brian



-----Original Message-----
From: Marc Linsner [mailto:[e-mail]] 
Sent: Wednesday, July 13, 2005 10:10 AM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv]
Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00

Brian,

We are talking two different issues.

A) This thread started with Henning wanting to 'deprecate' the use of
the floor measurement unit in the proposed standard RFC-3825.  My
argument against this is the use case of a multistory building operator
wanting to express location in lat/long/alt.  The very reason for the
floor measurement unit in RFC-3825 is to solve the issue of floor number
to altitude value. Armed with this information, in it's raw form, one
*could* find the quadrant/floor of a structure (better than most ALI
records today!). Knowing that I am 54.2 meters above datum has no
correlation to what the floor number is in a building unless you have
access to/knowledge of the surveyor/engineering plans for the particular
structure.

I can only guess that Henning's motive for wanting to deprecate the
floor MU is due to being too close for too long to the 'civic is the
only thing we understand' argument coming from the public safety sector.
I believe this public safety mantra will change as more of them take a
closer look at 'the dark side' - geo.

B) Now, for your argument.

1) Supporting all the various MSAG, USPS, municipal, etc. civic
databases cost money.  Operating a 'validation' service costs money.
They cost the end-user money directly due to having to support the
validation process. They cost the end-user money indirectly due to
having to support 'someone' maintaining the various databases.  You
would be hard pressed to convince me this is free even in/on Mars! ;^)
Would this money be better spent converting to geo?

2) Why do we need #1???  Because civic is ambiguous (ST vs. STREET; N.
Main vs. Main).  Geo is not ambiguous.

3) Your mantra of never geo-coding is, IMO, out-of-scope for GeoPriv.
This WG has never been dealing with, nor should they, how you arrive at
the value you're expressing in the location object.  RFC-3825 was never
intended to deal with this subject.  RFC-3825 assumes that you know the
numbers.  The binary (bit-length) indicator of precision defined in
RFC-3825 was for that sole purpose, indicate the length of believable
bits of the value expressed. Some have attempted to interpret the
precision mechanism as a way to convey the dilution of precision
expressed by current-technology geo measurement equipment.  This is not
the intention, nor does the RFC-3825 mechanism provide an adequate way
to express such.  As stated in the RFC, this was never meant to support
mobile/wireless devices (and ever-changing location values/DOP).  Again,
RFC-3825 assumes you know the numbers.

4) If we need a LO to transmit DOP, then state the use case and design
it!

5) The protocols that GeoPriv assembles, cannot take into account
whether the receiver of the LO has a poor, good, or excellent GIS'
interpreting the data.  Not a GeoPriv problem!

My mantra is based on the fact that geo is not ambiguous, works
globally, and the values expressed are small and easy to pack into
communications protocols.  As experienced in this WG's efforts, civic
has huge problems within national jurisdictions, and even bigger
internationally.

Conclusion: Geo is an excellent way to communicate location values from
machine to machine.  If a human cannot interpret geo values, buy a GIS
software package.  Welcome to the 20th century!

If anything *needs* deprecated, it's the use of civic!

-Marc-

 

> -----Original Message-----
> From: Brian Rosen [mailto:[e-mail]]
> Sent: Wednesday, July 13, 2005 8:37 AM
> To: 'Marc Linsner'
> Cc: 'GEOPRIV'
> Subject: RE: AW: [Geopriv] 
> Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00
> 
> Maybe I've been asleep.
> 
> I don't know about any costs associated with civic addresses. I know 
> about costs associated with maintaining things like wiremap tables 
> that figure out where a wall jack is when you change a patch cord.
> 
> I go back a refrain:
> 	If you have some device that MEASURES location, use it
> (that's geo)
> 	If you are having someone type in location, use civic
> 
> Ambiguity is not something we have discussed much with regard
> to civic location.  There are the issues of "numbering" (how 
> the authorities assign addresses), that, if you don't follow 
> the rules, leads to ambiguity.  I get that.  There is history 
> (multiple streets with the same name in a city). 
> So, yes, civic has ambiguity.  This has been solved (mostly 
> by some sort of unambiguous code, like a postal code), but 
> there is some cost to it.
> We have addressed these issues with the civic location 
> formats we have chosen.  If you use them, you should not have 
> ambiguity.  I'll agree that geo does not have ambiguity.
> 
> The problem is, how do you get that geo?  If you measure it,
> then we can talk about measurement accuracy.  If you convert, 
> then we have to talk about the quality of the database you 
> used to convert.  Generally, I think it's a bad idea to 
> convert (or at least, if you do convert, send the original 
> also so that the recipient can ignore your conversion).
> 
> A GIS system that can tell you where you are in a building
> can tell you what floor you are on given altitude.  It would 
> have to have the interior building plans, and that would 
> include vertical planes.
> 
> Brian
> 
> -----Original Message-----
> From: Marc Linsner [mailto:[e-mail]]
> Sent: Tuesday, July 12, 2005 7:38 PM
> To: 'Brian Rosen'
> Cc: 'GEOPRIV'
> Subject: RE: AW: [Geopriv] 
> Quickrandomcommentsondraft-ietf-geopriv-pdif-lo-profile-00
> 
> In-line...
> 
> 
> > I don't understand this question.
> 
> Civic has all the problems, plus associated costs ($$), that
> we've been discussing for over 2 years. Ambiguity. Geo is not 
> ambiguous.
> 
> > 
> > First of all, it is far easier to use civic in a multistory
> building
> > -- 35th floor, suite 3510, Room 25 (or cubicle 25-6).
> 
> As long as I state it in your format, then verify that your
> format doesn't change at some frequency prescribed by you.  
> Hence, my statement that civic has baggage associated with it.
> 
>  Certainly, until we get accurate floor plans,
> > accurately aligned to GPS coordinates, we would strongly
> prefer civic.
> > 
> > Secondly, if you do have a way to measure accurate lat/lon inside a
> > multistory building, you could get accurate altitude.
> 
> Not necessarily.  Besides, take your GIS system and tell me
> what floor equates to 83.4 meters?
> 
> -Marc-
> 
> > 
> > For the foreseeable future, if your device measures lat/lon, by all
> > means send that.  If not, please send civic.  Never 
> convert.  If you
> > know you are on the 35th floor, in Suite 3510, Room 25, and you are
> > looking at some sort of map that would tell you what the 
> lat/lon is,
> > you are converting.
> > Don't do that. If you have a WiFi mechanism that is
> triangulating, and
> > the only reasonable output is lat/lon, please make darn
> sure your base
> > station location is accurate, and send geo.
> > 
> > Brian
> > 
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On 
> > Behalf Of Marc Linsner
> > Sent: Tuesday, July 12, 2005 4:59 PM
> > To: 'Henning Schulzrinne'; 'Tschofenig, Hannes'
> > Cc: 'GEOPRIV'
> > Subject: RE: AW: [Geopriv] Quick 
> > randomcommentsondraft-ietf-geopriv-pdif-lo-profile-00
> > 
> > Henning,
> > 
> > > 
> > > Given that we have very limited deployments (to put it
> > > generously) of either civic or geo options, another path
> forward to
> > > consider: Deprecate the use of floors in the geo DHCP
> > option and don't
> > > carry it in PIDF-LO unless it is part of the full civic option.
> > > Logically, floors were always a bad fit for the geo option, but 
> > > necessary until we had others.
> > > 
> > > The geo floor option has known problems (cannot represent certain
> > > floors) and I can't picture a scenario where the floor (and
> > > geo) is known, but the street address isn't. Having to
> > merge floor and
> > > country information from geo and civic just adds complexity
> > and error
> > > cases, for no increase in functionality.
> > > 
> > 
> > I can't agree with 'Deprecate the use of floors in the geo
> DHCP option
> > and don't carry it in PIDF-LO unless it is part of the full civic
> > option.'
> > 
> > With all the extraeous baggage associated with supporting civic
> > addresses, why would you want to force the operator of a multistory 
> > building to support only civic???
> > 
> > Geo is simply easier/cheaper to support.
> > 
> > -Marc-
> > 
> > 
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail] https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> > 
> > 
> > _______________________________________________
> > Geopriv mailing list
> > [e-mail] https://www1.ietf.org/mailman/listinfo/geopriv



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

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