The MetaVerse : Maps and Location

So to carry on from the last article, how do we get the MetaVerse up and running? There's a list of components to build before we can really have it:
  1. A way to correlate a Physical Location to an Internet Server.. This is required to find the host for the tracking map, and to coordinate servers that could provide augmented content.
  2. A server architecture for hosting this map. It has to support special protocols to provide regional map information, because the full map is probably too big so we need the ability to chunk spatial information up and down in something like Octree arrangements. It also has to support user contributions for map updates, which the server will consolidate into the canonical truth map.
  3. API Contracts for how this server will notify both users and relevant servers/applications of important map updates. E.g. New areas are discovered, areas change significantly, or users enter/exit an area of interest.
So let's start with the first one: How do we correlate a Physical location to an Internet Server? This internet server serves two primary functions:
  • Providing the map that can be used for tracking, and for rendering (for remote attendees)
  • Providing coordinate information for augmented content.
We already have services like DNS that can convert a readable name into an Internet Server address.. So how do we get geospatial location into this? Things like GPS can give us coordinates, but there's so much noise and so many digits that trying to map it would be difficult. That is, if it wasn't already done for us.
Introducing Google Plus Codes. A free opensource system from Google that can turn a Physical Address (Street Address or Lat/Long) into a short 5+2 format code. For example, my local WalMart is 8P3F+Q7 (Among many others). Google Plus codes get you a space about half the size of a basketball court, which is plenty for any location tracking system I'm familiar with.
So what we need is something that can calculate the Plus Code for your location, and reconcile that Plus Code against a list of Map Servers to get you started in your space. Note that not all Map Servers will be available to all users. Some map servers will be restricted behind company firewalls or authentication requirements and such, due to privacy or company IP concerns.. That's fine, we want to support that.
This same system can also provide information on servers that provide content for the area. These servers would effectively be webservers for Augmented content, running applications and providing content anchored against their corresponding Map server.
Some important points to remember
  1. Just because you're in the right plus-code, you may not be able to use any provided map. A plus code could cross a boundary between an indoor and outdoor space, or your Geolocation could be inaccurate and provide you a bad map server at first.
  2. Your device needs to be able to handle multiple maps. If you're outdoors but walk into a location, you need to be able to recognize that transition boundary and handle it. In addition, a space may have an owner-provided map and then there's a separate "community built" map, which are slightly different. I expect this will happen a lot at first in retail locations, where venue owners provide high-resolution maps built from Lidar or other specialized hardware and reject incoming updates, so there will be lower-resolution but more frequently updated community built maps. Think the early days of MapQuest vs OpenStreetMaps.
  3. In a true MetaVerse scenario, users need to be able to handle multiple maps and multiple content providers simultaneously. E.g. if I walk into a Walmart while I'm waiting for my Uber to arrive, I need both my Uber Status and the relevant store content simultaneously, which will come from 2 different providers and reconcile to 2 different map.
So what does this look like to a user? You walk into a space and, either automatically or explicitly via a "Find a MetaVerse" function, geolocate your position roughly and find your Plus Code. You then communicate with a centralized Spatial Mapping Index Server to find a list of Map Servers available for your location. Your device can then either prompt you to select one, or perhaps it just tries them all in parallel to see which ones work. Once it's verified it has access to the map servers (remember, firewalls & authentication requirements) it looks to see what content servers are available for the functional maps. Once the list of available content is compiled, it can either be presented to the user ("Select your Metaverse Content"), or possibly automatically enabled based on user preferences (e.g. I'm a frequent Lyft user, so I turned Lyft content to "Always On").
There's a whole host of fine details in here too:
  • Who runs these Spatial Mapping Index Servers? And how do you verify them as safe? I assume a group like ICANN will have to be stood up to manage the "big ones", and several of the big internet companies will join in and offer alternatives and replicas. Individual companies will stand up their own, just like they do today for internal networks. Fun thought: Can you imagine what Split Horizon will look like for this?
  • Access Controls - How do you manage which users have access to which maps? And which content? And which content has permissions to which maps? And which users's information?
  • Verification - How do I verify that content coming from a server is actually tied to a specific vendor? There are things like SSL Certificates and such that help here, but they need to be extended a bit.
  • Map ownership - How do I know that a map server is actually providing a useful map of a space? Things like Chain of Trust and rating/expiration systems can help here.

All of that together is enough to get a user into a space, with maps they can use for tracking and basic information on what content is eligible for them to view... Once they have that, how do they actually get content? And how to developers create it? We'll save that for next time...

comments powered by Disqus