Simulator GIS – Darb Dabney’s OpenSim

It’s been a rainy finish here to the Thanksgiving weekend, and I’m busy detailing a course syllabus. It gets the creative juices flowing and connects a few more ideas. One that inspires this post regards how best to represent dense and accurate parcel ownership in an SL server.

At the present time, parcel ownership on one sim (64K sq. meters, or 16 SL acres) is limited to some 255 unique owners (8-bit flags, anyone) with parcel areas described using 4-meter grid blocks. This explains some of the nefarious 16 sq. meter, 3 prim-capable advertising spots as the minimum parcel size.

To better translate RL parcel polygons into dense SL parcels, the GIS-oriented inclination might be to link together some prims to make a parcel polygon. Since the current max dimensions of a SL prim appear to be 10 meters, this could involve a lot of 10 m by 10 m areas with awkward-to-construct angles at the property lines.

Enter the (physically) relevant land surveying model of a boundary line survey. When reduced to coordinates, it is far cleaner to build a boundary fence from a vertical sheets (1 cm-wide cube, 1 m tall and 10 m long) that connect corner points. This fence would not be owned by either parcel, but when viewed would greatly clarify how the blocky 4 meter grid representation of the original parcel polygons fits the GIS parcel polygons. Some coordinate geometry (at least with radii up to 5 meters) can be built from cylinders. There may also be clever ways of using spirals that I haven’t figured out yet and handle larger radii, because they do occur often. Short of that precise fit, the GIS vertex-and-straight-line model will probably always be adequate for SL property fences.

What seems from the GIS perspective to be missing from SL primitives is the polygon. But I do suspect that this is just something that we’ll work around and be happy doing–kind of like getting over the drag-a-box zoom-in (and zoom-out) paradigm so familiar to GIS and CAD people but simply not needed in Google Maps.

The maximum dimension for SL prims is 10 meters, minimum is 1 cm. Maximum span for linked prims is about 30 meters, and maximum count is 255 prims linked. Each region has 64K square meters, and 15000 prims.
http://secondlife.com/app/help/rules/index.php
http://secondlife.com/app/help/land/moreprims.php

To build the fences, we’ll start with a parcel boundary line feature class, then use something like ESRI’s PLTS tools for creating supplemental vertices on no more than 10 meter intervals along the boundary lines.
Next, I think that the original and supplemented vertices can be used to segment the boundary lines–so that all boundaries are expressed in no more than 10 meter-long segments.
From there, the segmented boundaries can have their midpoints identified, and those points can be attributed with their X and Y positions, their underlying Z value from our terrain model, and the azimuth of the boundary segment at its midpoint from the IAN-KO calc scripts. (by Ianko Tchoukanski and found at http://www.ian-ko.com/)
Finally, and I haven’t seen a Ianko calc script for this one, the Z values from the endpoints of each segment and the segment length must be used to estimate the vertical angle for that boundary segment. On steep slopes these fences may not all fit together seamlessly at each vertex, but the fence segments should be visible along the terrain surface with a much smaller height.

Some have suggested that translating a real-world model into SL can be done more economically by reducing the scale to say 1:2 and using 1/4 as many sims. I wonder if that would cause the current density of prims to be not enough to fill 64K square meters?

This is hoped to be the start of a new direction for spatial sloggers: the new world of 1:1 scale immersive mapping. In it, we hope to transcend the scale of mapping that has been a given for centuries, and through the proxy of a user’s avatar, go into and explore the map at full 1:1 scale.

Those who are professionals in the field of geographic information systems, managers of facilities CAD drawings, and government mapping agencies concerned with parcel-scale efforts are welcome to join us and help to pioneer the driving of data along the Trans-Metaversal railroad—getting high quality map data into a persistent 3-d world such as Linden Labs’ Second Life metaverse, so that detailed mapping of streets, sidewalks, curbs, trees, fire hydrants, parcels, buildings and more can be experienced immersively through an easy to use application such as the Second Life client.

Compared to the wondrous entertainment and commercial offerings that grew in Second Life (SL) between 2003 and late 2006, putting real cities into SL must at first seem mundane or perhaps even pedestrian. Yet in the early months of 2007 we will quickly be converging toward a world where the best municipal mapping has so many layers with such detail that the most natural way to experience, provide certain data quality assurance, and even develop a customer service interface will be to load all the physical features up into a single metaversal space such as SL, and then go into that space via avatar and just be in the map.

Much change in the real life (RL) GIS world will come of this, and much good in terms of publishing reference- grade civic models for general use. What it will require in terms of development are tools to translate our 3-d real surface models into SL terrain, translate our parcels into 4-meter grid representations, convert building footprints into low-primitive (prim) approximations for starters, and identify the bottlenecks in how we will be converting our point, line, and polygon features into 3-d shells of cubes, sphere, cylinder and related objects, sections, and twists in some automated ways.