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 have recently redoubled my efforts to get my installation of the WinAPRS mapping application fully configured with as many maps and database files as I think could be of use for general Ham radio use and emergency use in particular. I have loaded the latest TIGER maps for roads, political divisions and so on; the ancient USGS DEM files for the color terrain map, and various locations (EOCs, Red Cross sites, etc.), and a few other things.

My longstanding desire has been to overlay the current NEXRAD weather radar over all of this, but I have long been stymied by the seeming absence of imagery that was ready-made for GIS-type overlays. It seemed as if this would be impossible to achive, until I found something that is but one painful step away from working.

(more…)

I’ve just installed my ScanJet 4670, and pressing the scan button on the unit presents me with a dialog box that allows me to choose among all of the programs installed on my system that can interface with the scanner. So here’s the list:

• Canon ZoomBrowser EX
• hp scanning software
• Microsoft Office Publisher
• Photoshop
• Photoshop
• Photoshop
• Photoshop

First, the non-obvious. I have Adobe Creative Suite CS2 Professional. So then, why is Publisher listed, but not Adobe InDesign? And why is the rest of Office 2003 missing? Word, PowerPoint, Clip Organizer, Excel, and Office Imaging all support scanning, yet aren’t listed.

As for PhotoShop, since I upgraded from CS to CS2, some of these four on the list are CS, and some are CS2, but the dialog box doesn’t tell me which is which. And why four? I only have two versions installed here.

I’ll have to investigate this further, when I’ve taken care of higher-priority items.