RE: Measurements of other things besides location

[haitao.tang@nokia.com]

Hi,
 
"Mass", "Temperature"... ;-).  I don't think the SLoP or the current SLoP
needs to deal with them.
 
It is good to see so many interesting thoughts these days. I guess some
people may have mixed the applications over SLoP with SLoP itself. I think
only spatial location (with time...) and its related things are crucial for
SLoP. Even if certain payload may be carried with (the current) SLoP, I see
it as only optional. Plus, it is not need for SLoP to "understand" the
"extra" and  to "take the role of" the possible applications over it (and
maybe over the others).
 
I guess the discussed charter proposal (
http://www-nrc.nokia.com/ietf-spatial/charter-items-v031.txt)
<http://www-nrc.nokia.com/ietf-spatial/charter-items-v031.txt)>  has made it
clear. It is further clarified by
http://www-nrc.nokia.com/mail-archive/ietf-spatial/msg00663.html
<http://www-nrc.nokia.com/mail-archive/ietf-spatial/msg00663.html>  and its
follow-up discussion.
 
Thanks.
 
Haitao  

-----Original Message-----
From: EXT James M. Polk [mailto:jmpolk@cisco.com]
Sent: 11 July, 2000 19:56
To: EXT pbabern@au1.ibm.com; ietf-spatial@research.nokia.com
Subject: Re: Measurements of other things besides location


Indulis

>imagine a system which allows the weather bureau to query a
>network of phones on boats to obtain an instantaneous grid of temperature
>readings.  

Does your Cell phone have a thermostat or a Compass on it now? I'd like to
get one of what you have. I don't mean to be rude, but your asking us to
design a Protocol for specific capabilities that are unforeseen yet.  Haitao
and John, you work for Nokia, do you have plans to put these capabilities
into your Phones? If the answer is no -- then let us design a Protocol which
is extensible to allow for futuring our Protocol. You ask for this -- and I
believe we are doing this. Extensibility can also allow specific Vendors to
VALUE ADD features which are not within the base Protocol. 

At 02:01 PM 7/11/2000 +0800, EXT pbabern@au1.ibm.com wrote:
>Some of the discussions going on about what is appropriate to send (compass
>bearing, temperature etc etc) is interesting.
>
>Once there is a protocol for moving spatial information with a given amount
>of precision to an authorised requester, then why would it be any harder to
>send *any* information available at the client device?
>
>The spatial location is obtained (who cares how), but the key point is that
>it is only transmitted to devices authorised to receive that information.
>If this can be done with spatial location, then why is it so ridiculous to
>ask for compass bearing?  Bearing may be useful for a device on a boat
>(thinking beyond mobile phones here).  What about battery condition?
>Temperature- imagine a system which allows the weather bureau to query a
>network of phones on boats to obtain an instantaneous grid of temperature
>readings.  Anything a device can usefully supply could be made available.
>If there is a watch with a compass why not a phone?
>
>If the information is available, then why not allow it to be queried?  Same
>type of security requirements as sending location information...  Seems to
>just need an extendable XML specification whcih can start off with
>location, and build to more.
>
>I'd implore everyone working on this to not limit the usefulness of the
>work being done by forcing the protocol to just provide location
>information.  IMHO the protocol could be designed from day 1 to be
>extendable, and the first implementation is for location (probably the
>hardest and most difficult for privacy issues).  THinking about a way to
>make the protocol easily extendable means that unknown future applications
>of "retrieve data X from client" will be possible, and potentially useful.
>
>Cheers,
>
>Indulis
>
>Indulis Bernsteins
>Senior IT Analyst
>IBM Perth, Australia
>Phone:    +61 8 9261 8524
>Fax:      +61 8 9261 8536
>Mobile:   +61 411 208 178
>Internet: pbabern@au.ibm.com
>VPbuddy:  pbabern@au1.ibm.com
>*** Note timezone of Perth when calling, GMT+8 ***
>
>
>"EXT James M. Polk" <jmpolk@cisco.com> on 11/07/2000 10:12:21
>
>Please respond to "EXT James M. Polk" <jmpolk@cisco.com>
>
>To:   "EXT Kenji Takahashi" <kt@nttlabs.com>, "David Nordfors"
>      <david@nordfors.com>, "EXT Rohan Mahy" <rohan@cisco.com>
>cc:   haitao.tang@nokia.com, paf@swip.net, ietf-spatial@research.nokia.com
>      (bcc: Indulis Bernsteins/Australia/IBM)
>Subject:  Re: Fwd: Proposed Simple Text Format
>
>
>
>
>
>All
>
>Mass of the Target??  Temperature of the Target??  I have confidence people
>are
>kidding here.... right?
>
>;-)
>
>At 10:10 AM 7/3/2000 +0900, EXT Kenji Takahashi wrote:
>>Sounds interesting.  How about temperature of the target?
>>
>>Kenji
>>----- Original Message -----
>>From: "EXT Rohan Mahy" <rohan@cisco.com>
>>To: "David Nordfors" <david@nordfors.com>
>>Cc: <haitao.tang@nokia.com>; <paf@swip.net>;
>><ietf-spatial@research.nokia.com>
>>Sent: Monday, July 03, 2000 9:27 AM
>>Subject: RE: Fwd: Proposed Simple Text Format
>>
>>
>>> Hi,
>>>
>>> I don't think what you are asking for is in scope for the simple text
>>> format I proposed (my opinion).  However, I am about to propose a format
>>> for carrying generic measurements.  With this format, you could convey
>>> mass, velocity, accelleration, number of molecules in a solution, number
>>of
>>> weeds in my lawn, etc.  You would specify the unit of measure, and what
>>you
>>> are measuring relative to, for each measurement.
>>>
>>> Some examples:
>>>
>>> a) time in years relative to the beginning of Common Era
>>> b) time in milliseconds since my previous measurement
>>> c) my mass in kilograms
>>> d) distance in meters relative to a point of reference as defined by a
>>> straight line in 3-space
>>> e) distance in kilometers to a point of reference as defined by a 2d
>line
>>> on a mercator projection.
>>> f) average received signal strength in db from reference signal
>>>
>>> I hope this concept is useful for your purposes.
>>>
>>> thanks,
>>> -rohan
>>>
>>>
>>> At 12:10 AM 7/2/00 , David Nordfors wrote:
>>>
>>> >Seem attractive from a laymans point of view to have a "simple mode"
>>which
>>> >is default working with milliseconds and millimeters, and which is a
>>> >subset of a "scientific mode" that allows infinite accuracy.
>>> >
>>> >If rightly understood, this means that the time and position are in the
>>> >format n.nnnEk , where k_default= -3. Correctly understood?  Would it
>>simplify?
>>> >
>>> >Another thought
>>> >is it possible/attractive to somehow include other relevant physical
>>> >parameters, like mass, acceleration and velocity?
>>> >
>>> >This way it is not only possible to relate objects with each other
>>> >according to their positions, but also according to dynamical
>properties,
>>> >e.g make it simpler inserting the objects in real-time differential
>>> >equations for (for example) avoiding intercepting trajectories within
>>> >groups of rapidly moving objects. More airplanes could fill the
>airspace.
>>> >
>>> >Of course, the velocity, acceleration etc. can be calculated from
>>> >measuring the change in position with time, but it would be simpler to
>>get
>>> >it with the data package. Mass can however not be figured out (for
>>> >advanced purposes mass tensor). In a further perspective, including
>other
>>> >physical parameters, a location dependent real-time protocol could be
>of
>>> >great use for several applications which are difficult today, e.g.
>>> >balancing powergrids etc.
>>> >
>>> >cheers,
>>> >
>>> >/David N
>>> >
>>> >
>>> >At 13:58 2000-07-01 +0300, haitao.tang@nokia.com wrote:
>>> >>Hi,
>>> >>
>>> >>Yes, it would be very good if the time & space could be specified in
>>such a
>>> >>way that it allows infinite accuracy.
>>> >>
>>> >>We may realize it by two parts. We may have certain default accuracy
>>(i.e.,
>>> >>to the level of mm & ms). The further accuracy is only optional. For
>>many
>>> >>cases, the default accuracy may be enough already. Thus, we may need
>to
>>> >>limit the message/packet size, when the optional accuracy is not used.
>>> >>
>>> >>Haitao
>>> >>
>>> >> > -----Original Message-----
>>> >> > From: EXT Patrik Fältström [ mailto:paf@swip.net
<mailto:paf@swip.net> ]
>>> >> > Sent: 01 July, 2000 11:11
>>> >> > To: EXT Rohan Mahy; EXT David Nordfors;
>>> >> > ietf-spatial@research.nokia.com
>>> >> > Subject: Re: Fwd: Proposed Simple Text Format
>>> >> >
>>> >> >
>>> >> > At 11.49 +0200 00-06-30, EXT Rohan Mahy wrote:
>>> >> > >The time accuracy that you propose is more suitable to NTP
>>> >> > (Network Time
>>> >> > >Protocol), as it takes into account network transit times.
>>> >> >
>>> >> > Well, this protocol is doing a different thing than NTP. NTP
>>> >> > transfers the time itself, while this protocol is to transfer
>>> >> > information about when a specific event happened. It might be the
>>> >> > case that in some applications it is very important to know very
>>> >> > exactly when this point in time is, so I don't see why we should
>>> >> > limit the amount of accuracy possible in this protocol.
>>> >> >
>>> >> >    paf
>>> >> >
>>> >
>>> >
>>> >========================
>>> >David Nordfors, Ph.D.
>>> >Nordfors Creative
>>> >Email: David@Nordfors.se
>>> >Web: http://www.nordfors.com <http://www.nordfors.com/> 
>>> >
>>> >
>>>
>>>
>>
>>
>
>*************************************
>"At the end of the day... the most committed win!"
>
>James M. Polk
>Sr. Product Manager, Multiservice Architecture and Standards
>Enterprise Voice Business Unit
>Cisco Systems
>Dallas, Texas
>w) 972.813.5208
>f)  972.813.5280
> www.cisco.com <http://www.cisco.com/> 
> - att1.htm
>
>
>
>

*************************************
"At the end of the day... the most committed win!"


James M. Polk
Sr. Product Manager, Multiservice Architecture and Standards
Enterprise Voice Business Unit
Cisco Systems
Dallas, Texas
w) 972.813.5208
f)  972.813.5280
www.cisco.com <http://www.cisco.com/>