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.

I’m currently looking for a better way of mounting a number of different gadgets to my car, including my iPod, two ham radio remote heads, my Garmin eTrex GPS, and perhaps a few more. Since many of these devices will be upgraded over time, I need any mounting system to be standard enough and interchangeable enough to make this a no-brainer. It appears that there are at least two standard mounting systems that would help me—the AMPS and NEC mounting hole patterns. These are common on many of the mounting brackets on the market, including those from Pro-Fit International, Panavise, and RAM Mounts. Some have both, though the AMPS pattern is more common.

It’s not just these three companies that use AMPS—it is found on some GPS navigation systems (Magellan, at least), many XM radios, and many automotive mobile phone mounts.

Yet despite knowing part of the AMPS specification (a rectangular hole pattern measuring 1.496 by 1.181 inches on-center), I can find no verification or definition of the standard; nothing that comes close to a citable source or reference document. I asked Pro-Fit International’s product designer (co-incidentally a fellow ham) about this, and he knows that it was a Motorola-originated standard, but has never seen a specification either. And there is no agrement on the spacing, either. One drawing from RAM Mount Systems shows 1.50″ × 1.188″ with a hole diameter of 0.218″, and nowhere can I find any mention of what size screw or bolt and thread count is to be used when designing female threads into a device.
AMPS appears to be a long-lived mounting system for the mobile electronics industry, but with no technical documents to reference, its specifications and existence seem to get passed around by word of mouth. This is insane. And it has now become one of the acid tests for CADJournal. If you make a product designed to go in a car—or a CAD tool used to design them—that I wind up reviewing, support for the AMPS pattern (along with other interface standards) will be one of the items I grade on.

Today’s task is something that should be simple–I have our radio club logo in vector form as an Illustrator CS2 image (with nothing but vectors, arcs, and text) and need to a scalable vector version that can be used in applications such as PowerPoint. Windows’ Enhanced Metafile (EMF) is the perfect choice for this, since it can support all of these drawing elements correctly, and with 32-bit precision.

WMF, the older 16-bit Windows Meta File standard from Windows 3.1, is not as capable, and is not capable of rendering the line joins correctly, and doesn’t even support arcs and circles. The Windows 95 version of WMF does support arcs and circles, but is still problematic.

Exporting the logo from Illustrator is easy enough, with the Export command. And using Windows XP’s Preview feature in Windows Explorer shows the result to be a perfect copy of the Illustrator file. However, when placing that EMF in Word or PowerPoint (Office XP), the line joins are incorrectly beveled, making the logo ugly and incorrect.

One problem with Illustrator is that it doesn’t let you choose between the two flavors of EMF–the original GDI based EMF from Windows 2000, or the enhanced GDI+ based EMF from Windows XP.

Since Windows XP’s image preview handles the EMF logo just fine but the Office XP applications don’t, I’m fairly confident that the problem lies with Microsoft’s code, not Adobe’s.

There needs to be a reliable way to include high-quality, scalable company logos in a wide range of software that design firms use in their communication and marketing efforts. For at least the Windows platform, this means EMF, so let’s get this right folks!

To borrow a phrase from a former co-worker and tech editor of mine, the Mobile Web “sucks dead bunnies”. Unlike other technologists who believe that WAP was a solution looking for a problem, I’m a firm believer that just reformatting Web pages designed to be used on desktop and laptop computers is not sufficient for providing a fully useful Internet experience to PDAs and mobile phones.

What went wrong, and must be fixed to make the Mobile Web happen for more than just those with deep enough pockets to tie themselves in with the carriers? Something very simple called content negotiation. Every WAP browser I have ever tried makes the same fatal error of claiming to support both (X)HTML and WAP in the header they send to Web servers, and not specifying a preference. When visiting a server that is properly configured for content negotiation with both (X)HTML and WAP pages, the server will properly send the higher-quality file–the desktop (X)HTML one–that most mobile phones can’t handle (either in a usable manner or more oftent not at all). This is relevant for anyone involved in the CAD or design markets because of the coming of SVG and location-based services to mobile phones. Before these can be widely deployed though, this fundamental (and extremely easy to fix) flaw must be corrected.

So the acid tests begin now. My latest site, PDAcritic.com, is properly configured with most pages available in both XHTML and WAP versions. All of the content there fully complies with the IETF and W3C standards, so if a desktop browser (sorry, Microsoft) or WAP browser (sorry, Nokia, Motorola, Samsung, SonyEricsson, et. al.) can’t even load the site, don’t blame me–ditch that browser and go find one that works.

I’ll provide updates as I test browsers, phones, and PDAs for compatibility with this and other technologies of interest to this community. And you’ll know who the winners and losers are, because I’ll be handing out letter grades that won’t pull any punches. Sony Ericsson is the first, and their S710a earned a D−.

One of the tasks for the ham radio club I’m involved with is updating the membership “database”. Not updating in the sense of adding and revising records, but updating its structure from an Excel spreadsheet to a proper database. This has been actually been a multi-phase process.

The first time I got involved last year, it was because of the need to quantify the percentage of our members who are also current ARRL members (a requirement for club affiliation with the ARRL is 51% membership among the club members). Part one was straightforward–converting text entries of dates to date values, for example. But then adding all the data needed to be able to calculate paid/unpaid members, voting elegibility, and the other needed calculations proved difficult to do. I wound up adding 10 columns to the spreadsheet, each with complex formulas that resulted in either a 1 or 0 that could then be counted and used in other calculations. It wasn’t the right way, but the most expedient because the maintainer was most familiar with Excel and we needed to put more thought into our database needs.

We’re now in that phase, and I’ve been playing around with a trial copy of FileMaker Pro 8, expecting it to be a snatch to migrate the data and design a proper database. (The two members who will be maintaining the database already have FileMaker, so it’s the obvious choice.)
Hah! The first problem is that FMP imports all 65,484 rows of the Excel spreadsheet as records, even though all but a few hundred are empty. (Selecting and naming a range didn’t help, because FMP doesn’t let you specify ranges, named or otherwise.) Fortunately, deleting all of the blank ones only required 5 separate steps. Of course, FMP imports all fields as type “Text”, so you have to go re-define all the number and date fields that already had been marked as such in Excel.

After all of this nonsense, I decided to design the database from scratch, then import from Excel. Since my Excel and database field names are slightly different, FMP doesn’t get the mapping quite right. And although the import dialog allows me to reorder the fields, the design completely fails if I only need to fix one field, since dragging it into position forces everything below it that had been correct to be off by one. Talk about fencepost errors!

After working around all these problems, I have a rough database design that I like. I still have to fix some of the formatting (some membership numbers are showing up as 2.0001e+09), convert a few fields to a Boolean type, define pick lists, and restructure a few other fields, then I can enjoy the fun of figuring out how to do a mail merge in yet another application, and discovering if this FileMakre Pro 8 database will work with older versions.

I was experimenting with a new web service this morning for our local ham radio club, and the profile page requested an icon of a very specific size: 48 pixels square. Since I have our club logo as an Illustrator vector image, this should have been an easy, one-step process. Right?

Wrong. Although the Save for Web command in Illustrator allowed me to save the vector image to a PNG raster image directly, I could only resize the aspect ratio that Illustrator had chosen (48×30). Getting the simple square image desired required me to open the image in Photoshop, change the canvas size and specify on which edge(s) blank pixels were to be added to fill in the rest of the space.

Needing to save vector artwork to very specific image sizes is so common–in creating icons, Web ads, and many other tasks, that I’m amazed the ability to specify the export size and dimensions has not been a part of Illustrator for years.