Re: [ogpx] URI schema for virtual world locations?

[Joshua Bell <[e-mail]>]

Agreed. When something needs to be specified, it should be done to enable
interoperation between actual systems and can be implemented and proven by
running code. If coordinates-within-regions are necessary to specify, x/y/z
coordinates in meters with IEEE 754 64-bit floats appear to be completely
sufficient for current systems.

That said, I think part of the challenge for the VWRAP WG is to determine
what can be left *unspecified* yet *not* get in the way of interop
envisioned by this group. (Which is one of the topics I want to discuss at
length in Anaheim). As an example, if there are places where data can be
relayed between two endpoints by a third party without specification in the
protocol itself, and the burden is on those endpoints to have out-of-band
agreement on the format, that simplifies VWRAP and enables scenarios we
hadn't thought of. (I'm not sure that's applicable to this example, just
throwing it out.)

On Fri, Jan 22, 2010 at 8:02 AM, Meadhbh Hamrick
<[e-mail]>wrote:

> it's important because one of the functions of the protocol will be
> for clients to inform servers where they wish their avatars to appear
> in the virtual world. virtual objects will be moving as well, and
> simulators will need to communicate with user agents the moral
> equivalent of "box number 5 just moved to location <x,y,z>."
>
> VWRAP is a protocol for interaction between systems that have
> characteristics similar to OpenSimulator and Second Life. Both systems
> use meters in a rectangular coordinate system to describe position.
>
> There has been discussion in the past about supporting multiple
> coordinate systems, but the implementers believed it would introduce
> unneeded complexity. Requiring that ALL compliant systems support ALL
> possible representational systems seemed like an invitation to
> incompatibility.
>
> VWRAP does not mandate what coordinate system your implementation uses
> internally, it only mandates what coordinate system you use to
> communicate with other systems. If you wish to use polar coordinates
> measured in femtoparsecs in your implementation, that is your
> business. but when it's time to communicate with the outside world
> (using VWRAP), you'll have translate into/out of meters in a
> rectangular coordinate system.
>
> this is not because we're rectangular bigots, it's because many of us
> believe that picking a single representational system will reduce
> complexity of the protocol.
>
> -cheers
> -meadhbh
>
> On Fri, Jan 22, 2010 at 7:22 AM, Richard L. Barnes <[e-mail]>
> wrote:
> > It's not clear to me why the protocol needs to define coordinates,
> > especially given that different servers might have different notions of
> > place.  One server might think of space in terms of coordinates in
> meters,
> > another in polar coordinates, another in terms of polygons that represent
> > some construct known only to the server.
> > So when we're talking about referring to points in space, it seems like
> it
> > would make sense to have two parts: One piece of information that gets
> you
> > to the right server, and one that tells the server what location is being
> > referenced (in whatever frame it thinks in).
> > To make an analogy, in the HTTP URI <http://example.com/this/is/a/path>,
> the
> > authority part "example.com" gets you to the right server, and the
> meaning
> > of the path component "this/is/a/path" is completely up to the server (it
> > can be opaque to the user).
> >
> > --Richard
> >
> >
> > On Jan 22, 2010, at 9:25 AM, Frans wrote:
> >
> > I like this idea too, makes a lot of sens. +1
> >
> > On Thu, Jan 21, 2010 at 10:10 PM, Meadhbh Hamrick
> > <[e-mail]> wrote:
> >>
> >> hmm. i kinda like this idea.
> >>
> >> we may want to choose a rectangular coordinate system as the default.
> >>
> >> so yeah, maybe the mapping service is "the thing" that defines what
> >> we're now alternately calling a virtual world, grid or instance. so we
> >> could have a simple service like this that describes the grid:
> >>
> >> %% grid/info
> >> << {
> >>  grid_name : string,
> >>  coordinates : string,
> >>  map_service : uri
> >> }
> >>
> >> and you could plug in values of "spherical" or "cylindrical" in the
> >> coordinates entry, but have "rectangular" be the default. the
> >> "map_service" URI could be the URI used to convert a region name +
> >> point in space into a URI for requesting services like teleport, map
> >> tiles, spatial chat, etc.
> >>
> >> so... for example... i could have a grid/info entry for SL's vaak test
> >> grid at http://util.vaak.lindenlab.com/. when you did a HTTP GET on
> >> it, you would get the blob:
> >>
> >> <?xml version="1.0"?>
> >> <llsd>
> >>  <map>
> >>    <key>grid_name</key>
> >>    <string>vaak</string>
> >>    <key>map_service</key>
> >>    <uri>http//util.vaak.lindenlab.com/services/map</uri>
> >>  </map>
> >> </llsd>
> >>
> >> the map service at http//util.vaak.lindenlab.com/services/map could be
> >> queried to get information and/or caps to access locations. so you
> >> could construct a service like:
> >>
> >> %% location/info
> >> << {
> >>  teleport_cap : uri,
> >>  map_tile : uri,
> >>  spatial_chat_cap : uri
> >> }
> >>
> >> so when you did a get on
> >>
> >> http//
> util.vaak.lindenlab.com/services/map?location_x=128&location_y=128&location_z=32&region_name=Ahern
> >> you might get a response like:
> >>
> >> <?xml version="1.0"?>
> >> <llsd>
> >>  <map>
> >>    <key>teleport_cap</key>
> >>
> >>  <uri>
> http://sim1.vaak.lindenlab.com/c/0953E063-5B31-4B62-B218-A7C0CE1FC391
> </uri>
> >>    <key>map_tile</key>
> >>    <uri>http://s3.amazonaws.com/foo/bar/ahern.jpg</uri>
> >>    <key>spatial_chat_cap</key>
> >>
> >>  <uri>
> http://sim1.vaak.lindenlab.com/c/4AFA1BAF-4FAD-45A5-A683-6244BC81A660
> </uri>
> >>  </map>
> >> </llsd>
> >>
> >> and the teleport_cap would be the one that gets used if someone wanted
> >> to teleport to the location.
> >>
> >> hope this makes sense.
> >>
> >> -cheers
> >> -meadhbh
> >>
> >
> > --
> > Jeroen Frans
> > Virtual World Technology Specialist.
> > TheVesuviusGroup.com
> > SL: Frans Charming
> > _______________________________________________
> > ogpx mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/ogpx
> >
> >
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>