[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Fwd: Proposed Simple Text Format
James,
I think there are two issues here:
what is the minimum set of information i need to identify my probable
near-earth location at a certain time? i think that is a good way to
describe the default format (perhaps payload is a better word) for
SLoP. with this minimum set of information I can compare two point
locations, i can look up features on a map, i can do a lot of useful
things. i don't need mass, temperature, orientation/direction, etc to do that.
when targets/servers don't know that information, what information do they
have that could be used to calculate their location? depending on the
situation, there are a whole bunch of useful quantities you could
consider. is it useful to solve that problem? OH, YEAH! if you wanted to
solve that problem, how hard would it be to allow SLoP to carry that kind
of information? well, you almost get it for free. if we allow multiple
formats (payloads) for the reasons i described earlier, you can just build
a new one, and carry that payload over SLoP.
thanks,
-rohan
At 09:39 AM 7/11/00 , James M. Polk wrote:
>Rohan
>
>I believe you misunderstood my comment. I am very aware of how to
>calculate Altitude, as well as temperature from a device (a plane for
>example) -- I just don't see why people are discussing SLoP doing this. Do
>you believe this should be a functional parameter of SLoP?
>
>I hope not. But if you are, and since Mass (and size) of a object/Target
>has been mentioned, I'd like to discuss its use on an airplane for a
>moment. What would the SLoP or WGS84 coordinate position of a Boeing 747
>be? Is it the location of the Target (Server) electronics within the 747
>without regard to the height or wingspan? Is it the location of the
>cockpit without regard to the size of the Target (Server)? What happens
>when the Target is the Aircraft Carrier "Enterprise", which I believe is
>just over 1000 ft long? Where would SLoP say that boat is? Discussion has
>occurred recently indicating that an accuracy of at or greater than 2.3
>meters is not good enough for SLoP.... I believe EVER airplane and
>Aircraft Carrier is larger than that; so where it an accuracy reply of 2.3
>meters for either of these situations 'not' good enough? These are
>outrageous examples, but most automobiles are just less than 2.3 meters in
>width, and much longer in length. Do we expect SLoP to deliver an accuracy
>value which can determine with lane of the 101 Freeway your car is in my
>friend? I'm not sure....
>
>The basis of my concern is to what level of 'Fields' shall SLoP support in
>Phase I? IMO Size is more important than Mass -- because location (our
>primary goal, BTW) is affected by Size, not Mass. Movement might be
>affected by Mass, but that I thought, we basically decided velocity and
>vector were applications which derive this information from SLoP, not
>within the Protocol itself. Or am I wrong here?
>
>At 08:59 AM 7/11/2000 -0700, Rohan Mahy wrote:
> >James,
> >
> >You can calculate your altitude in a plane using measured barometric
> >pressure, but temperature is a secondary variable. Mass is an important
> >variable in calculating speed, and therefore position, in space
> >flight. Not the most commonly used location systems, but they are valid.
> >
> >thanks,
> >-rohan
> >
> >At 07:12 PM 7/10/00 , James M. Polk wrote:
> >>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]
> >> >> >> > 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
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>*************************************
> >>"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
> >
>
>*************************************
>"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