Archive for the 'Making Parcels' Category

Aug 27 2010

Marin County Topo-Bathy Surface “tbsm45cm” Released as 2010.08

Blemishes notwithstanding, nearly six months of back-burner work has reached a threshold of readiness and is outward bound to some engineering firms, flood mappers at FEMA, and interested parties within the county. A handful of known issues remain unresolved. Proper name is “tbsm45cm_20100823”, proper edition is “2010.08”.

This is the third version of the terrain. Second version was “2010.01” and included multiple LiDAR data sets, but fewer than presently used, and was a topographic model only. First version was “2009.09” and was mainly photogrammetry and FEMA LiDAR, and was the last version to be developed in California Coordinates. Once the massive NCALM LiDAR data sets were processed, it became easier to move everything into WGS84 UTM zone 10 north meters projection, WGS84 NAVD88 CONTUS Geoid 2003 vertical position.

The NOAA utility program VDatum, a brilliant Java-based application able to stream-process data sets of near-infinite size, brought the NCALM data to heel, and opened up decades of NOAA depth surveys to our use in integrated topographic-bathymetric surface modeling.

First-return NOAA ALACE LiDAR swaths were fused along the outer coast, as bare-earth filtered versions were not produced in 1997–2002; the benefits of LiDAR detail along the rocky coast do seem to outweigh the distracting appearance of structures near Rodeo Lagoon, Stinson Beach, and outboard Bolinas.

When ArcGIS 9.4 beta 2 reached its limit in ability to render the terrain dataset into 45cm grid over the full extent, the clipping quadrants created to resolve this problem ended up chopping a very small portion of Sonoma county that drains into Estero Americano; the full watershed remains intact in the 1-meter version of the terrain grid under analysis for county-wide hydrology. Likewise, the tighter clipping quadrants lost a few hundred meters of San Pablo Bay bathymetry just west of where Marin, Sonoma, Contra Costa, and Solano counties meet. Also, tighter clipping quadrants snipped a portion of the San Francisco Bar southerly of San Francisco’s Seal Rock that was intended to be part of the model. All of these areas exist in the 100cm grid, and will be part of drainage analysis.

Happily, we have updated the workstation to ArcGIS 10, and have been enjoying such great speed gains with Spatial Analyst that our ERDAS use has been noticably reduced. Finally, Spatial Analyst is often showing performance nearly on par with ERDAS. Thank goodness that the Raster Calculator survived the transition to version 10 ArcGIS!

Painfully, the existence of unutilized bathymetric data sets for upper broad-channel Corte Madera Creek and Bolinas Lagoon have been revealed this week. Hey, there’s already something to look forward to for the next build!

The new terrain is getting some immediate use in support of an effort to participate in ESRI’s Community Maps Program for large-scale topographic mapping. The Program provides a template geodatabase with 36 vector feature classes and two raster, into which local agencies may pour their data. Once tucked into a conforming schema, a template multi-scale map document is provided with 120 layers—30 at each of four large scales that correspond to Google Maps and Bing Maps projection and cache tiling schema. The difference is that the template document makes use of ESRI tools to allow much more local detail to be packed into a map designed with notably more sophisticated cartography than either Google or Bing maps now have. The Community Maps Program concept is that local agencies may publish their local detailed content in a fairly uniform style, while retaining a world-wide seamless context for their surrounding area.

Qualitatively, the effect is that, when viewing the ArcGIS.com topo map alongside either Google or Bing maps (on two monitors, with comparison made at the same scale), the ArcGIS.com map looks to be a larger scale. It isn’t, and I’ve measured the size of features to convince myself, but my mind insists that I’m zoomed farther in on the ArcGIS.com map for some reason. My guess is that it is a perceptual effect of the much greater amount of information that is cleanly displayed in the ArcGIS.com map versus the much sparser Google and Bing content at these large zoom levels. Try it out—it’s like a carto version of an optical illusion!

The 120 layers in the template large-scale topographic base map from the ESRI Community Maps Program are arranged to provide four precise cartographic designs for Google/Bing map cache levels 16 through 19, which correspond to these display scales
1:15000–1:6001 (level 16, a.k.a. ~9k)
1:6000–1:3501 (level 17, a.k.a. ~4.5k)
1:3000–1:1501 (level 18, a.k.a. ~2k)
1:1500–1:501 (level 19, a.k.a. ~1k)
One of the most attractive areas currently online is Toronto, ON where at levels 18 and 19, individual building outlines are graced with street addresses.

Anyhow, the new tbsm45cm model will serve County of Marin’s effort at large-scale topographic mapping several ways. First, it has made possible a very detailed hillshade that helps emphasize the grading around each hillside structure in the county. Second, it helps us to create the required metric topographic contours. These are necessary to meet world-wide mapping standards, and throughout this weekend, contours are being generated from a related (smoothed version) of the terrain on 50cm vertical interval. Needless to say, most of these won’t get used in the map renderings, but the ESRI cartographers have shared a very clever indexing scheme that will help us use this single set of metric contours to support the requirements for all four of our topographic map scales.

No responses yet

Nov 27 2006

boundary fences instead of parcel polygons

Published by under Making Parcels

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.

No responses yet