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

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Jul 2005 10:10:01 -0400

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:[email-masked]] 
> 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:[email-masked]]
> 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: [email-masked]
> > [mailto:[email-masked]] 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
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/geopriv
> > 
> > 
> > 
> > _______________________________________________
> > 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: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jul 2005 11:00:34 -0400

> floor measurement unit in the proposed standard RFC-3825.  My argument

This is an incomplete statement and seems to lead to the useful 
geo/civic discussion, iteration 17. I don't think any minds are being 
changed here.

What I proposed is different: Within buildings, you SHOULD provide 
either civic only or both civic and geo, but not geo + just floor.

I have yet to hear a convincing argument why this would be a problem. 
Following this approach avoids carrying incomplete civic addresses and 
provides additional context to the recipient (such as building names).

> within national jurisdictions, and even bigger internationally.

What "huge" problems?

Henning

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Jul 2005 11:52:47 -0400

> > within national jurisdictions, and even bigger internationally.

Lat
Long
Alt (and maybe MU)
Datum
DOP

vs.

http://www.ietf.org/internet-drafts/draft-ietf-geopriv-dhcp-civil-06.txt

The pages (and subsequent quantity of variations of representations) of
Sections 3.4 & 4

And we still need a validation process and jurisdiction specific rules that
ecrit has yet to figure out in order to make global use of the data (if
country = Japan, do this; if country = New Jersey, do this).

-Marc-

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 13 Jul 2005 11:59:16 -0400

> country = Japan, do this; if country = New Jersey, do this).

ECRIT elements will not need to understand the meaning of any of the 
civic elements - they are just labels in a defined hierarchy. Thus, the 
actions of the protocol won't depend on the country. Obviously, 
countries will have to decide how to encode this information, but that's 
a local matter, outside the concern of GEOPRIV.

New Jersey has not yet seceded from the US, although it may join the 
United States of Canada at some point 
(http://www.jesusland.com/images/mapthumb2.gif)

---

From: "Marc Linsner" <[email-masked]>
Date: Wed, 13 Jul 2005 12:06:59 -0400

> 
> New Jersey has not yet seceded from the US, although it may 
> join the United States of Canada at some point

I was referring to the fact that most US citizens outside of New Jersey has
yet to accept it as a state.

-Marc-

---

From: "Brian Rosen" <[email-masked]>
Date: Wed, 13 Jul 2005 17:37:39 -0400

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:[email-masked]] 
Sent: Wednesday, July 13, 2005 10:10 AM
To: 'Brian Rosen'
Cc: 'GEOPRIV'
Subject: RE: AW: [Geopriv]

Brian,

-Marc-