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

[Meadhbh Hamrick <[e-mail]>]

cool. before leaving this topic though, i'd like to synthesize the
messages in this thread and try to make some assertions regarding the
problem domain of virtual world locations.

i think these are non-controversial.

1. we're discussing the representation of locations within the virtual
world as expressed in the protocol.

1.1. individual implementations may choose to define points in space
using a representational system of their choosing, but the protocol
will define at least one default representation that all systems
should comprehend.

1.2. "locations within the virtual world" are represented as points in
a multi-dimensional space. points are partitioned into "regions" for
administrative and/or performance reasons.

1.3. there may be two forms of location representation: absolute
position within the virtual world (as denoted by a single point in
space) or relative to the origin of a region.

1.4. the statement above (1.3) implies there is a public service
available to map between points in the absolute space of the virtual
world and points relative to a region.

2. representations of locations in a virtual world are used for at
least these purposes:

2.1. to define the origin and bounds of a region in a virtual world.

2.2. to define the location of an object in the virtual space.

2.3. to define the destination of a teleport request.

2.4. to define the destination of spatial chat / voice

3. "the" representation of locations in the virtual world should be
extensible to allow implementers and deployers the ability to add
experimental or implementation specific information to the locational
reference.

3.1. implementations that process location references should retain
location data they do not recognize. that is, an implementation that
receives a location reference including information it doesn't
understand, it should not discard that information. rather, it should
retain that information in case it must pass on that location
reference to an implementation that does recognize it.

4. the protocol must not REQUIRE a single service that maps between
points relative to the origin of the "world" and points relative to
the origin of an individual region.

On Fri, Jan 22, 2010 at 8:35 AM, Joshua Bell <[e-mail]> wrote:
> 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
>
>
> _______________________________________________
> ogpx mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ogpx
>
>