After striking out on finding a stand-alone source for California’s fault lines, I decided to try the USGS National Map, which I had forgotten about. It’s somewhat klunky in its speed and user interface, but it keeps getting a little bit better each time I try it.

I was pleasantly surprised to find a layer for fault lines under the geology group. But alas, when I checked this layer for display, nothing of the sort was visible. And when I found something else interesting that I’d like to add to my APRS maps–a coarse NOAA depth contoru map of the SF Bay, I could display a beautiful, colored picture of the bay and ocean waters, but when I went to download this data, it was not available.

Since the USGS Menlo Park office is so close, I think I might take a trip down there today to find out why it’s so hard to gather this data in a usable form, and find out if they can help me find dam failure inundation maps, tsunami hazard maps, and mudslide hazard maps, all of which should be easily available to the public, and especially ham radio operators.

I now have a reply back from the author or WinAPRS on support for ESRI world files. He is working on it, but has one last problem to figure out before it will work. In researching the standard, I came upon an old problem I learned about many years ago, but which never spent the time to find the proper solution for.

While the full-blown GeoTIFF raster image format includes not only the basic georeferencing information but the projection, datum, and units. The commonly used ESRI-created World File (.jpw for JPEG images) lacks the latter three items, and includes only pixel size, image rotation, and origin.

So, when using a world file with a JPEG, GIF, PNG, or other image that lacks the georeferencing capabilities of GeoTIFF, you must also use a projection file (.prj) that includes all this missing information. This has also been defined by ESRI, and has had several flavors over the years. The original format was a multi-line one, used by Arc/Info 7.x, but that has been replaced by a new .prj format originally defined by the OpenGIS consortium as the Well-Known Text (WKT) format, and has since been revised slightly by ESRI, and it’s not clear if WKT has been updated to match the ESRI changes.

But guess what? The National Weather Service doesn’t include a .prj file with its georeferenced weather radar images. And now that I know about this little item, I suspect that most of the so-called georeferenced files floating around are also lacking this important metafile.

Now that I’ve found a source of georeferenced weather radar images, I thought the next useful bit of data would be a vector overlay of all the fault lines in the Bay Area. This should be simple, right? After surfing for a couple of hours, the closest I’ve found to usable GIS data is a Google Earth KML file of just the Hayward fault. After another hour of fiddling around with conversion utilities, I have managed to convert this KML file to a GPX file (an open XML standard for storing GPS waypoints, track logs, etc.) using Fish-Track’s KML to GPX converter, but since WinAPRS can’t read GPX files, I need to convert this data to something it can, such as raw NMEA sentences, which another conversion utility, gpsbabel, fails at.

It looks like I have another feature request for the WinAPRS authors…GPX support.

I’ve downloaded and “installed” the GlobeXplorer ImageConnect utility for AutoCAD, but already am getting the impression I won’t like it much. It is labeled prominently as “free”, but when you find the real meaning of the word, it means “free 14-day trial” with watermarked imagery.

And “installed” means putting the files in the Program Files directory, telling you they’re installed someplace else (C:\GlobeXplorer\ImageConnect), and then telling you to add that incorrect path to AutoCAD’s search path. Oops.

And what’s this with the length of the actual path? C:\Program Files\GlobeXplorer\ImageConnect for AutoCAD?

And even after ignoring those disjointed directions and using APPLOAD to load the LSP and ARX files, I’m still having no success. Ahh, the problem becomes clear. The program was last updated in 2003, explicitly mentions support for AutoCAD 2000, 2000i, and 2002. I’m running 2005.

I’ve left a message for Tech Support, so we’ll see what happens tomorrow.

I’ve explored the Earth Explorer application just long enough to discover it doesn’t have any application for anyone doing civil planning of any kind. Max resolution is 1km, and there is no georeferencing support in it at all. It also doesn’t support the SpaceBall, so it’s been uninstalled.

Trying Keyhole NV, I’m also disappointed that it doesn’t support the SpaceBall for 3D navigation, doesn’t offer any of the high resolution aerial photos I’ve found on the USGS site, and although allows me to overlay images I already have, doesn’t support GeoTIFF, thus requiring me to manually register the image by changing its transparency and fiddling with the image handles at the edges and corners. Yuck. On the plus side, it’s got a plethora of vector and POI overlays, including accurate local roads, gas stations, schools, etc. This feature will be a big help in planning for Field Day, and will speed up one of the data collection efforts—building a location overlay for our APRS mapping with the local hospitals, fire departments, police stations, ATMs, restaurants, and a few other things that might or might not be in the Keyhole database.

GlobeExplorer looks a bit more promising. It is not a 3D program, and its primary interface is a difficult-to-use Web page that lets you order prints and electronic images at somewhat reasonable rates. But the images are JPEGs, not GeoTIFFs and there is no indication if they are provided with georeferencing data. On the plus side, the company offers plug-ins for CAD and mapping software that might just offer that functionality, so I’ll be taking a closer look at its ImageConnect software for AutoCAD later this week, hopefully.

For now, though, I need to recover from the late night at the WordPress launch party.

Somewhere last week, I found a link to a cool NASA software project—World Wind—which appears to be a revival of the Blue Marble Viewer (for the Blue Marble project) with a different code base.

The ability to view and zoom in on a 3D globe of the Earth is wonderful, but the program only works on Windows, and since its code base is C# and DirectX, instead of C++ and OpenGL, it will be very difficult to port to other platforms. I applaud NASA for creating this, but since our tax dollars are being spent, they should be spent on tools that work on Windows, Mac, and Linux, to ensure equal access.

And the UI is also as frustrating and confusing to use as The National Map. Even though the whole thing is rendered in 3D, there is, of course, no support for either 3D mice such as the SpaceBall or stereoscopic viewing.

I’ll be testing this tool this week, comparing it with the commercial competition—Keyhole, GlobeXplorer, and Earth Explorer. (I might also take a NOAA thingie for a spin.) In software like this, I would expect to be able to extract geo-referenced images easily, view the content in stereo, and use my SpaceBall to manipulate the view.

This might keep me busy long enough to get an answer from Autodesk and Bentley about including their mapping software in the Field Day mapping project/software review.

I’ve installed @Last Software’s SketchUp application, with a goal of determining how suited it is to the task of site planning. Having spoken with the company at MacWorld, I’m not sure it has the necessary features yet, but they are planning on expanding the ways in which the application can be used, and this will make a good benchmark for that task.

Launching it for the first time, I’m presented with a Windows Firewall warning that the application is requesting access to the Internet. I’ve not seen this warning before with any other CAD software, so we’ll have to see what feature triggered the warning.

I’m able to import both the GeoTIFF and DXF contour files, but there are no provisions for aligning them or even ensuring their coordinates are preserved. This was expected, given my conversation with the company. The SketchUp ESRI ArcGIS extension does offer the ability to georeference SketchUp models in real-world coordinates, but since I don’t have ESRI’s GIS software, that doesn’t do me any good at the moment.

So, at the moment, SketchUp’s capabilities are not sufficient for me to use it for this phase of the Field Day planning. I’ll give it another try down the road, though.

From briefly exploring the four different digital map download interfaces the USGS offers, I have pretty much ruled out DigitalEarth and the National Atlas. The former has a user interface so cumbersome to use for the casual browser that it’s useless, and the latter simply doesn’t have the data I’m looking for. So that leaves The National Map and the SDDS.

The National Map has a home page that is more visually appealing, has a clearer description of what its purpose is, and even sports a nifty logo.

Using the map at first seems to be simple. You’re presented with a relief map of the U.S. and can zoom and pan in it, with the default layers including highways, surface streets, and a grayscale shaded relief. Unfortunately, the layer control is in a frame that can’t be resized (frames are evil!), which makes navigating the layers a little difficult. Turning on road labels and a few hydrology layers results in a better understanding of the map, and a fairly reasonable presentation. Unfortunately, there is no way to capture a vector version of the current map view, as SVG or DXF, for example.

I found it easy to get the DRG quad images to appear, but there is no control over the order in which the layers are drawn, so it’s impossible to specify that the shaded relief be drawn on top of the photos, or blended with them. And this time, I found two different, but nearly identical high-res color images, clearly made from the same original. One (San Francisco-Oakland 2004) was sharper, but the other (Urban Areas) had richer colors. Selecting both the NED elevation data and the color photo for download proved impossible, and selecting each individually still required downloading two files separately—the metadata and the actual image. The link to the metadata failed, and since the download is always of the current display and the image was wider than I wanted, the raster image download was delivered in two pieces, split right in the middle of my desired area. Moving the split required me to “center” my desired image on the right side of the rectangular window. I can’t get rid of the split because each half of the image is 83MB, and the download limit is 100MB.

I selected one of the elevation files for downloading, but doing so opened the ZIP archive directly in WinZIP instead of asking me what directory I’d like to save it in.

Now that I understand how the game works, I’ve figured out how to get the map window to be the size I want (answer: resize the browser window, pan the image, repeat until satisfied), and have re-specified all the options. To download the raster image, and the elevation data in both TIFF and ArcGrid formats only took me 3 more modifications of the data request. So I’ve now got the 75MB TIFF image, and two flavors of the NED and SRTM elevation data.

Time for lunch.

The USGS has collected some amazingly useful digital images. The problem is that some of the data is accessed via FTP sites or Web sites that are little more than alphabetical lists. Others are found in graphical web mapping interfaces that are perhaps the best proof of why the move to Web-based software is detrimental to usability and our society’s technical capabilities.

A further problem is that our tax dollars have already paid for the collection of this data, yet the USGS seems intent on making most of it available only for fees to be determined by the private companies that have access to the best data.

For this project, I need a color aerial photo of the Bayfront Park, and terrain data for the 4 kilometers surrounding the park (for RF propagation).

Confusingly, the USGS has numerous methods for downloading this data, including The National Map, the National Atlas, the EarthExplorer, and the Seamless Data Distribution System, with no clear indication of which system is the best for any particular purpose or data type. And with all of them, there is very little information about what each type of data offers; at least not presented in a way that is quick and easy to digest.

What is extremely troubling is that the USGS is about to delete vast amounts of data from its online database—the entire Digital Elevation Models (DEM) and Digital Line Graphs (DLG) data sets. While these are ostentiably being replaced by newer, better data, the removal of historical data is always troubling, not all current software can handle the new SDTS data format, and there is some question as to whether the newer data—specifically, the NED data set—is as good as the older data.

In the following posts, I’ll comment on how easy it is to download data in useful data formats from these sites.

Since I knew vanilla AutoCAD wasn’t up to the task of merging 2.5D contours with an aerial photo to create a cool 3D map, I set about deciding what program should be the first obvious candidate to test.

Since I was ultimately getting the imagery from the USGS, it made sense to see what they offered. The answer is not much—dlgv32 Pro is an upgrade to the earlier dlgv32 software the agency previously offered. Although the free package will do some of the things I need, its inability to export the results made it clear that its commercial sibling was the next logical choice.

GlobalMapper sells for $219, and should allow me to create many of the initial maps I need for planning, as well as providing some much-needed data conversion.

After cleaning up the contours in AutoCAD (deleting the text and filling in the resulting gaps, and correcting a few contour elevation values) I’ve exported them as a DXF file, but since there is no projection or datum information stored in an AutoCAD drawing, and since the city engineer that provided the contours couldn’t tell me either, I’m forced to resort to assume a few things and find the correct values elsewhere.

So I’ve assumed State Plane Coordinates, with the NAD27 datum, and California Zone 3. If I’m wrong, and it’s really NAD83, then I’ll have to re-do all this later. For the aerial image, I had to go digging through the USAPhotoMaps documentation to determine that the exported image was UTM Zone 10, NAD83 datum.

Yep; I’m wrong. When I specify NAD83 as the datum, the DXF file matches up with a lower-quality GeoTIFF I have of the site. I still can’t get the JPEG from USAPhotoMaps to register, so I must have guessed wrong there as well. But that task can wait until tomorrow.