One feature request I get fairly often is a better printable roads layer, primarily from SARTopo users for use in both urban searches and disaster response. The USGS layer is out of date, MapBuilder doesn’t show enough street names, and OpenStreetMap gets shrunk to the point of illegibility when printing. I’ve always assumed that the proper answer was to bring the default OpenStreetMap style into the MapBuilder rendering stack, which would allow scaling it to match a PDF’s resolution – but because that introduced a number of complications, I kept kicking the can down the road.
Necessity is the mother of invention, and a little over a week ago I was called to the Camp Fire in my role as a SAR team member and found myself needing to generate a lot of street maps. One requirement was that they display as many street names as possible, so that responders from around the state could use them for navigation despite not being familiar with the area or having a cell signal. A clean white background was also important to allow marking up maps in the field. Fortunately I’d just wrapped up a MapBuilder import and had a second rendering server sitting idle with the new database, so I was able to hack together a new layer style quicker than expected.
There are a lot of lessons learned from trying to apply my wilderness SAR background to an urban disaster, but one of those is that the new roads layer is here to stay, and I’m sorry I didn’t have one out sooner. It will probably get tweaked further and eventually added as a primary layer, but for now it’s only available as a custom MapBuilder layer (pro level account or higher required):
Check “compress text”. Recommend setting roads to “thin lines”.
With the “compress text” box checked, a number of changes are made to support showing as many street names as possible:
Suffixes are dropped (drive, road, street, etc)
Font size for road labels is reduced
Labels are allowed to bend more
Labels are spaced closer together
The Oakland hills with most streets labeled at a1:12k scale
The result isn’t exactly pretty compared to something like Google Maps, but it’s fairly effective as a first response tool since it will show a lot of street names at usable map scales like 12-24k.
San Francisco at 1:12k
Even at 1:24k, a lot of Berkeley street names still get shown
The layer didn’t exist 10 days ago, and hasn’t seen a lot of careful development or evaluation, so feedback and suggestions are definitely welcome.
A new version of CalTopo Offline and SARTopo offline has just been released (4151), with several major improvements:
1. Real-time syncing between offline and online versions. All of your maps from the website will show up in the offline version, and changes will automatically sync between the two. If you make a change while offline, it will be queued until you regain internet access. This is helpful both when starting a project online and then taking it into the field, and also when working in an area with unreliable internet, so that you can keep changes synced to the outside wold without being at risk if the internet dies.
2. New map downloader that downloads offline map data within Cal/SARTopo Offline. This makes it much quicker and easier to download large areas than the old web-based downloader. Because the new downloader offers multiple resolutions and is built on a 15×15 minute grid, it also gives you more control over how large your offline maps are.
3. Revised layer selection. Elevation, slope and aspect data are all rolled into a single layer. Shaded relief and slope angle shading are automatically computed from elevation data, and no longer need to be downloaded separately. Most excitingly, MapBuilder Topo, Hybrid and Overlay layers now have full coverage for the contiguous US.
4. Layer caching. Map areas viewed in the offline version when you do have internet access are cached for later use offline. So even if you haven’t pre-downloaded an area, it may still be available when offline.
When I added the weather forecast layer this summer, I mentioned my frustrations with the way the NWS requires you to bring up endless point forecasts to get an accurate picture of local precipitation amounts. With the Northern California fires, I’m running into the same issue with wind – I’ll read about a forecasted red flag warning, but the Napa and Santa Rosa forecasts barely hit double digits. I’ll admit that I had no idea wind speeds were so locally variant – or at least, no idea that the NWS forecast grid captured such small-scale variations.
24hr wind gust plot. From 15mph in St Helena to 50mph on Mount Hood just 3 miles away.
Fortunately I already had wind speed mapping on the back burner – it didn’t get deployed along with the earlier temperature and precipitation work, but most of that code was reusable. I can’t show wind direction – even if I were to render directional arrows on the map, frequent direction changes make it impossible to show a single meaningful 24hr or 36hr wind direction. However peak forecasted wind speeds and gusts are shown for 1hr, 6hr, 12hr, 24hr and 36hr intervals, using the same green-yellow-orange-red-purple-blue-black gradient scale as the temperature layer.
One option that does provide wind direction is the crowd favorite windy.com. However, windy does not reflect the small-scale variations in the NWS forecast grid (see below). As with temperature and precipitation, it’s an open question as to how accurate the NWS grid variations are, but I like to provide as much raw data as possible and let users draw their own conclusions.
Windy.com plot of the same location
The wind layer is a checkbox option alongside temp and precip:
The forecast grid option immediately below will also show point speeds (remember, the point is simply the center of a grid square, and the forecast applies to the entire square), and clicking on a point will bring up the hourly weather chart.
I feel like I’ve pretty much run through the backlog of fire-related items I had sitting around, so I think this will be the last major layer change in response to the Northern California fires.
Update: there are now two wind layers, the “max wind speed” layer as described above, and a “wind plot” that provides forecasted directions and speeds for specific points in times, at 3 hour intervals to 12 hours, and then 6 hour intervals to 36 hours. The same color chart is used for speed, with short lines tracing direction. The length of the lines has no meaning.
Thanks to a generous offer from a contact on the Google Crisis Response team, CalTopo is temporarily displaying high-resolution imagery for portions of the fire-affected areas in Napa and Sonoma counties. This imagery was taken by DigitalGlobe on Wed the 11th, and although the fires are still ongoing, it provides some degree of insight into what had burned by that point. While there is a lot of smoke present, in many areas it’s clear enough for a house-by-house assessment.
Because the original imagery is false-color infrared (which gives vegetation a strong red tint), I’m converting it to black-and-white to avoid any possible confusion between the red tint and currently burning areas. I’m told that true-color imagery will be available at some point on Fri, and hopefully I’ll be able to upgrade the layer to match.
Available imagery footprints, with fire outlines shown in red.
Step 2: Enter your address in the search field at the top of the page and click GO:
Step 3: Use the zoom control at the top left of the map to zoom in:
Step 4: Mouse over the layer selector at the top right (it should read “Hybrid +1”), and in the window that comes up, adjust the “NorCal Fire” opacity slider to expose the pre-fire imagery:
It may also be helpful to temporarily turn on the “Current Fire Activity” checkbox in order to see the fire perimeters:
I’ve put some temporary infrastructure in place to help handle this project, but if the site is impacted too much, I may need to make some changes. The shortlink at the top of this article (https://caltopo.com/l/16PD) will always point to the right place – if you share a URL, please share that.
This morning I deployed a bunch of new layer changes, some of which have been in progress for a while. From small to large:
First up, the 40′ contour layer has been redone to use MapBuilder-based contour lines. This allows for clean, accurate contour lines even when zoomed way in, instead of the pixellated lines that used to exist when going past zoom level 16. It also improves contour printing, since MapBuilder layers are custom-rendered for each PDF’s scale; imagery-contour maps will no longer print with dense, tiny and unreadable contour lines.
Contour lines displaying cleanly atop high-resolution Google satellite imagery.
The downside is that this means a temporary loss of contour coverage for parts of Alaska, pending MapBuilder’s expansion to AK, HI and parts of Canada. The old layer is still available as a custom source, however. Choose Add New Layer -> Add Custom Source and choose “40ft Contours” from the prefill dropdown. Use the “save to account” link at the bottom left of the dialog to save this to your account for easy future access.
CalTopo has a lot of powerful features, but they also tend to be obscure and awkward to use. This is particularly true of some of the custom layers, such as MODIS satellite imagery and sunlight analysis, since they require using the Add Layer dialog and going through a handful of steps to tweak a single parameter. The hiccup to improving this has been adding configurability to the layer UI, which is now done – both base and overlay layers support dropdowns for additional configuration options.
The simplest implementation of this is slope angle shading – fixed and gradient are now condensed into a single checkbox with a selection dropdown. Some people might consider this a step backwards, since it potentially requires two clicks rather than one. However a consistent issue I’ve seen with new users is turning on both fixed and gradient shading at once, rendering the underlying map unreadable. The rationale for collapsing them is partially to save users from that mistake and partially to save space in the ever-growing layer list.
Configurability also allowed me to move the sunlight analysis out of the “add new layer” menu and into the standard layer list. Check the Sun Exposure layer box and you get two dropdowns – a time of year and a time of day.
These mimic the Add New Layer -> Add Sunlight Analysis dialog, but make it far easier to walk the time-of-day selector up or down to see how sunlight and shading vary throughout the day. This has been covered previously, but just for grins here’s another example, showing the current sun exposure on Mt Whitney at 8AM:
Daily satellite imagery has been another hard-to-access feature. I’ve had a “latest MODIS” layer for some time, but if the most recent exposure happened to be cloudy, dialing back the clock using the archived MODIS feature was a pain – not just having to add a custom layer, but also needing to iterate through the cycle multiple times just to find a clear day.
The “latest MODIS” layer has now been replaced with a daily satellite group that has three different layers – daytime, daytime w/ shaded relief, and nighttime. After you choose the layer, you can quickly change either the observing satellite or the date of the capture:
Prior-year options provide two dates spaced several days apart, in order to increase the chances of finding a clear day. The VIIRS satellite has also been added to the satellite list alongside MODIS’s Aqua and Terra.
One difficulty I’ve had with MODIS satellite imagery is figuring out exactly what I’m looking at. To facilitate that, the “Day (Relief)” layer automatically blends in the enhanced (aka multiply-blend) relief shading:
View of the Yosemite-area high country from a recent clear day. The relief shading makes it easier to identify terrain features.
Although probably of little practicality, there is also a nightly capture from VIIRS:
Laugh now, but when the apocalypse hits, this will be a critical datapoint for charting the downfall of civilization.
With those layers out of the way, it’s time for the big news of the day: weather mapping. If you’re like me – and I readily accept that the average American is definitely not – you’ve probably spent a fair bit of time with the NWS’s point forecast tool. Want to know how cold it will be overnight? One grid will be 1000′ below where you want to camp, while the neighboring one is 2000′ above. Wondering how to dodge an incoming storm while still getting after it? I’ll often look up forecasts for at least a dozen places to get a sense of where the storm is tracking or how strong the rain shadow effect will be.
The best products are the ones you build to solve your own problems, and while they have yet to see much real-world validation, so far I’m pretty happy with the three new weather layers.
The temperature layer interpolates from the NWS forecast grid using CalTopo’s elevation data and the 3.5 degree per thousand foot rule of thumb. It’s certainly not perfect: I have to guess at the elevation the NWS is using for each forecast grid square, there are cases where the 3.5 degree rule doesn’t apply, such cold air settling in mountain valleys, and mountain weather forecasting is difficult and imprecise to begin with. However, it still provides a useful visual of the daily highs and lows.
It’s definitely summer out there, folks
The color gradient is good for a big-picture overview, but it lacks precision. For that, the “from” and “to” dropdowns let you set minimum and maximum cutoffs. To see everything with an overnight low of 40 or higher, set the from field to 40:
The precip layer will show forecasted precipitation for the next 24 or 48 hours, with options for both rain and snow. While it will probably see some revisions when winter rolls around and I have additional datasets to play with – both larger and colder storms – it’s still a useful big-picture indicator as is. This February, a planned Ouray ice climbing trip was scrapped at the last minute due to unseasonably warm conditions, leaving me with a few extra days of mountain biking in the southwest while en route to Silverton. With rainy weather rolling through, it took a while to wrap my head around the forecasts for the entire Southern UT / Northern AZ / Northwestern NM region. A visualization like the one below would have come in useful:
Lacking such quality weather info, I found myself rained out in Moab and had to make do with a pair of backcountry days in the La Sals, which were nothing short of amazing. So perhaps there’s such a thing as over-planning and over-analyzing and we should all just go with the flow. Except that were it not for CalTopo’s planning tools, I’d probably still be trying to extricate myself from some of the dense growth we bushwhacked through.
Both of these layers have their quirks. In the temperature screenshot above, you can see that the South side of Giraud (unshaded area at the bottom of the image) appears inexplicably colder than the North side. In the precipitation screenshot, the storm appears to be very respectful of the New Mexico state line, presumably because each side is coming from a different forecast office. In these situations, it’s sometimes best to go straight to the source.
The “NWS Forecast Grid” layer is an interactive data layer showing the center points of the NWS forecast grid squares. At zooms 12 and above, there is a dot for each grid square; at 11 and below, only a portion of the squares are shown. Mousing over a grid point shows the elevation I’m using for temperature interpolation, which is just a guess based on averaging points in the grid and will precisely match the elevation the NWS uses. Clicking on a point opens a new tab with the NWS hourly weather chart:
Going back to the Giraud example, let’s take a look at the source forecast data:
Remember that the temperature is representative of the entire 2.5km grid square and not that exact point, but the North side is forecast to be warmer, at higher elevations, than the South side. Mousing over the 47 degree point shows that I’m estimating it as 11375′; clicking on it, the NWS shows 11132′. I estimate the 37 degree point South of that as being at 10325′, and NWS says 10696. So it’s not just a quirk in my interpolation – they are forecasting the North side to be significantly warmer, despite being higher.
Is that an accurate reflection of reality? I couldn’t say, but I would guess the NWS forecast lacks that level of pinpoint precision. But I do know that I’d rather have all the data from which to make my own informed decision, than a somewhat arbitrarily chosen point forecast or two.
Team accounts are a new feature designed to both improve data sharing within an organization, and allow organizations to buy a single subscription covering all their members.
Maps can be saved to either an individual’s account or the team account, and both sets of data are rolled together in a user’s account dialog. Because the “your maps” table is sorted chronologically, new work saved to the team account will automatically bubble up and be visible to other team members:
Icons and custom map layers saved to the team account will automatically be visible to all team members as well; if you regularly use specialized icons or custom layers, this is also a great way to push them out to team members – no more emailing around GPX files with the latest copy of your team’s customizations.
Team accounts come with a dual pricing scheme – $500/yr for organizations consisting primarily of unpaid volunteers, and $2000/yr for organizations primarily made up of paid professionals. Both versions cover organizations up to 100 people; for larger organizations, please email email@example.com. If there is interest, I may be able to add a cheaper small-business option for companies with only a handful of employees.
Beyond data sharing and customization, this price includes pro-level features for all team members, and a site license for offline use covering both team computers and personal computers owned by team members.
https://i0.wp.com/blog.caltopo.com/wp-content/uploads/2017/07/group-map-list-1.png?fit=1024%2C312&ssl=13121024mtjacobs58https://blog.caltopo.com/wp-content/uploads/2019/10/caltopoLogo_menu1.pngmtjacobs582017-07-20 00:33:002021-05-24 13:36:37Announcing Team Accounts
Most newer GPSs support USB Mass Storage, which means that when plugged into your computer, they show up as a drive with all your routes, tracks and waypoints saved as GPX files. Older models, such as the Garmin 60csx still widely used in SAR, require a special protocol to transfer your data.
For websites like CalTopo, the only option for getting data off older Garmin GPSs, and the most convenient option for newer ones, was the Garmin Communicator Plugin (GCP). Browsers have slowly been dropping support for the NPAPI plugin architecture on which GCP was based, but the final nail in its coffin was Garmin not only discontinuing support, but deciding to no longer issue new API keys. Since I only had an API key for http://caltopo.com/, when a Google Chrome security change forced me to move most traffic over to https several months ago, GCP became largely useless.
That was motivation enough to wrap up a long-simmering project: the GPSIO browser extension. Compatible with both Chrome and Firefox, GPSIO acts as a conduit between your browser and the open-source GPSBabel program, which does the actual hard work of talking to your GPS.
GPSIO is still a little rough around the edges, but you are cordially invited to take it for a spin, report any problems, or – since it’s open source – fix them yourself. Although GPSIO only supports Garmin GPSs at the moment, I would welcome code contributions to expand it to work with the wide range of GPS types that GPSBabel supports.
CalTopo has been having some performance issues lately, no point in trying to pretend otherwise.
Behind the scenes, there two different platforms: a Python/Mapnik/PostGIS stack that powers MapBuilder and auto-routing, and a Java app for everything else. MapBuilder has been struggling for a while, but lately that started bleeding over into the rest of the site’s operations – as the number of pending MapBuilder requests grew and grew, the Java side of the house (which proxies the requests) would eventually get overwhelmed and pages would stop loading. A week ago I rolled out a new server and a new copy of the MapBuilder database with fresh OpenStreetMap updates, and everything pretty much came screeching to a halt.
This left me in a bit of a pickle. If I rolled the deployment back, things would temporarily improve, but my production environment would be out of sync with my new development laptop, which would make it harder to debug the issues and arrive at a permanent fix. If I didn’t roll the change back, fixing the problem would be a lot easier, but it would be a rougher ride until then. I bumped the primary EC2 instance up to a $100/day m4.16xlarge to buy some slack, rolled up my sleeves, and got to work.
What followed was a blurry week of long hours, coffee, beer, testing in production, and marathon coding sessions that produced results brilliantly functional yet barely understandable when re-examined the next day. Kind of like being a CS undergrad during end-of-semester crunch time.
At any rate, the MapBuilder rendering stack has been almost completely rewritten, sorry for any inconveniences over the past several weeks, and I’m confident at this point that the latest round of performance issues are solidly in the rear view mirror. At least, confident enough to roll out two new features that were waiting on this.
First, as a subscriber-only feature (all levels), CalTopo now offers Retina/HiDPI tiles for most layers. Rather than rendering out a separate 512px tileset, my server pulls 4 tiles from the next zoom level down and rolls them up into a single tile. As soon as you sign in to your account, the map viewer will automatically pull 512px tiles instead of the standard 256px ones. If this is problematic for some reason (requests get routed though my server rather than direct to S3, so there are potential speed implications), it can be disabled via the config menu – look for the “Retina/HiDPI” option at the bottom of the Display group.
The other big news is the addition of a “hybrid shading” option to MapBuilder, and a new prefab layer based on it named MapBuilder Hybrid. Hybrid shading blends the green-gradient canopy shading used by MapBuilder Topo with aerial imagery, producing a backdrop that shows you much of the detail you’d get from imagery, but with less of the visual noise that makes it hard to pick out other map features.
MapBuilder Hybrid, Tuolumne Meadows.
Zooming in, you can make out individual trees, but they don’t overwhelm the image or distract from the trails and contours.
Example from the Casacades
Produces a nice visual effect at wide zoom levels, too.
Admittedly I’m both biased and a little loopy from the past week, but I have the MapBuilder Hybrid layer loaded on a 4k monitor and I can’t stop staring at it. I’ve been wanting to add this for a while and am psyched to get it live, although this is an early version that will probably see stylistic tweaks over time.
https://i0.wp.com/blog.caltopo.com/wp-content/uploads/2017/04/Screen-2BShot-2B2017-04-16-2Bat-2B5.38.29-2BPM-1.png?fit=1024%2C686&ssl=16861024mtjacobs58https://blog.caltopo.com/wp-content/uploads/2019/10/caltopoLogo_menu1.pngmtjacobs582017-04-17 01:07:002021-05-24 13:36:38MapBuilder: It’s Back And Better Than Ever
In the very beginning, I started what would ultimately become CalTopo as a hobby project focused on offline environments – a command post or tailgate somewhere off in the woods far away from the nearest internet connection. As CalTopo grew, that ability for entirely self-contained operation has remained as a little known but fundamental building block of the codebase. Flip out a few of the underlying bits – Google Maps with OpenLayers, a standalone database with HSQLDB, Tomcat with Winstone – and you’d get a free-standing Java web app with no external dependencies.
For search and rescue, those who knew the secret handshake could get a similarly configured copy of SARTopo, delivered via physical thumb drives along with statewide map data. While this system worked for a while, it’s been chugging along on a donut spare and one headlight for some time. Although releasing copies of a subscription-driven website into the wild feels a bit risky, it’s past time to make the offline functionality a supported feature that doesn’t require my involvement with every install.
Welcome to CalTopo (and SARTopo) Offline.
Due to the costs of delivering map data and the extra support footprint it will present, there was no way I could roll the offline functionality into the existing subscription levels. Instead there is now a $100/yr offline subscription level that also includes all pro-level features. First responders who have upgraded to a SAR account will see a $50/yr offline upgrade option.
After upgrading, your account dialog will have an offline access tab with links to downloading both map data and a copy of the program:
Map data is provided in 1 degree by 1 degree blocks, in MBTiles format. Available layers include USGS 7.5′ topos, forest service maps, slope angle shading, elevation data for profiles and viewsheds, and NAIP aerial imagery down to 1 meter resolution; most blocks include 2 years’ worth of imagery.
Each account is allowed 300GB worth of map downloads per year, with no geographic restrictions other than being limited to the lower 48 states. It’s up to you whether you want to skip the imagery and cover a larger footprint, or get 2 years worth of 1 meter imagery for a smaller coverage area. Coverage is available for the contiguous US:
I’d post some screenshots, but there’s not much to show – the offline version looks very much like caltopo.com. For more information on how this all works, check out some of the very thorough documentation written Patty Lindsay (there is hopefully more documentation of this caliber coming to help.caltopo.com).
In my last blog post, I mentioned that I spent the tail end of 2016 cooking up some new map layers. Well, here we go.
Terrain Shading and Custom Relief In SAR, it’s not uncommon to have a group of people huddled around a large-format map, looking at it from all angles. While relief shading helps terrain features pop, it only works when the map is viewed from the bottom – standing at the top will cause features to invert with peaks looking like valleys.
One alternative is terrain shading (for lack of a better word), where the relief is generated using a number of different light sources, rather a single 315 degree (NW) angle. Because of the multiple angles used, there is no “up” or “down”, and the map can be viewed from any angle without playing tricks on the eye. The downside is that in some areas it can be hard for the eye to quickly tell up from down.
For CalTopo’s terrain shading, I tried to balance these tradeoffs by using 6 evenly spaced light sources plus an additional one at 315 degrees, proving a slight amount of orientation.
CalTopo enhanced relief, which uses a multiply blend filter but retains the standard 315 degree light source
CalTopo terrain relief, which uses a 7 different light sources
If the out-of-the-box terrain shading doesn’t quite work for you, there’s now an “Add Custom Relief” option under the Add New Layer menu. Pick an azimuth (compass direction) and zenith (angle above the horizon) and click “Add Lighting”. Mix and match multiple combinations to reach your desired effect.
FSTopo 2016 The FSTopo maps behind the “US Forest Service” map layer have been seeing regular updates, but it’s not all forward progress. While the newer maps gained vegetation shading and better road/trail data, the delineation between public and private property moved from light, transparent gray shading to a heavy-handed gray that completely obscured all vegetation shading. I wasn’t happy with the way this looked, and wasn’t happy dropping public/private land boundaries, so I did things the CalTopo way: create a new layer. And thus the USFS 2016 layer was born.
For most purposes the now-renamed “FSTopo (2013)” and “FSTopo (2016)” layers will be interchangeable. The old layer is better for locating land boundaries, and its white background works well for blending with aerial imagery or slope angle shading. With its vegetation shading, the new layer is probably better suited for standalone use.
The same map as above, but this time using the “FSTopo (2016)” layer.
Expanded Alaska DEM Coverage
While not a new layer per se, I’ve been slowly expanding CalTopo’s Alaska coverage. Although the national elevation dataset (NED) still only covers a portion of the state, that portion has been growing, and it’s time to catch up. The NED isn’t a first-class layer, but a powers a lot of other ones, including normal relief, enhanced relief, 40′ contours, fixed and gradient slope angle shading, custom DEM shading, and cursor point elevations.
The current state of NED-based layer coverage in Alaska.
Note: I’m still patching up a few small errors in the dataset, but didn’t want to hold this announcement up until those were fixed.
New NAIP Imagery Layer
The new layers based on the National Agriculture Imagery Program (NAIP) dataset are probably worthy of a blog post all their own. But before I get into the good stuff, know that all this layer creation doesn’t come cheap, and high quality imagery is definitely the worst offender. Not that I’m complaining or looking for your sympathy, but lest there be any doubt as to whether your subscription dollars are getting rolled back into CalTopo development:
By way of background, while Google’s Satellite layer is great, I can’t do any server-side manipulation on it, whether that’s generating PDFs or combining it with enhanced relief shading. Although a secondary issue, I also can’t provide offline copies of it for use by SAR teams in remote environments.
NAIP data has always been public, but in the past, acquiring it was a bit awkward, requiring the mailing of many terabytes of drives back and forth. I tried to skirt around this by stitching the aerial backgrounds from the USGS’s new “USTopo” maps into a seamless layer called USTopo Imagery. This worked, but the quality wasn’t great, and update cycles were delayed vs going directly to the source. I’ve been on the hunt for some time, and as drive costs dropped, was seriously considering biting the bullet and acquiring a physical copy.
Then Andrew Johnson from Gaia GPS pointed me at the aws-naip public S3 bucket, and it was off the races. Yes, this was expensive. Yes, it’s a roll of the dice when big-name companies like Google, MapBox and ESRI have better datasets out there. From a business perspective, maybe it won’t work out. But I believe that high quality aerial imagery that I can repurpose as needed is strategically vital to CalTopo’s future, so I decided to roll the dice and here we are.
The biggest difference between the NAIP and USTopo Imagery layers is quality. The NAIP layer goes to zoom 17 (~1m per pixel) while USTopo Imagery went to 16 (~2m per pixel), but even at zoom 16 there’s a noticeable quality difference between the two.
USTopo Imagery view of “Half Dome Village” aka Curry Village, Yosemite NP
Same location viewed using the NAIP layer
NAIP is generated in 3 year cycles, i.e. one third of the continental US is overflown each year. Not content with a single NAIP layer, I generated two versions – one for 2011 to 2013 and one for 2013-2015. Most places in the continental US should have two different dates available, either so that you can see how things have changed with time, or in case one revision has too much snow, shadows in the wrong place, etc. Long term, I hope to grow the date range.
Prior imagery of the same location. In this case, it’s not much different.
NAIP is also distributed as 4-band imagery, with a near infrared channel in addition to the standard red, green and blue. I captured this and rendered it out into a separate layer, which allows for some interesting data processing. Right now, I’m still conflicted as to whether it’s actually useful or just a neat party trick.
The Aerial Imagery section of the layer dropdown now has a “False Color IR” option. This uses the near IR channel for red, red for blue, blue for green, and drops the green entirely. As a result, the difference between near IR and IR is accentuated, drawing stark contrast between vegetation and manmade, dirt or rock surfaces, regardless of actual color.
False-color IR view. No, it’s not some weird 3D glasses thing.
The computed difference between red and near IR is also available as a vegetation shading option for custom MapBuilder layers, called “Infrared Reflectance”. With this option you can generate traditional looking topo maps with super-accurate vegetation shading, but as always there’s a catch: areas that were shadowed in the original image show as white rather than the appropriate vegetation shading.
Custom MapBuilder layer with the IR Reflectance background. Note the white band in the meadow at the top of the picture, which is shaded in the original image, not actually vegetation-free.
Deprecation of Existing Layers
With the layer dropdown getting increasingly complicated, this was also a good time to clean house. The “ArcGIS Topo” option isn’t as clean as my USGS map scans, but I originally included it because it covered Alaska. That’s no longer an issue, so it’s gone. USGS 1:250k maps aren of limited utility with Google Terrain and MapBuilder Topo; gone. USTopo Imagery is inferior to the NAIP layer in pretty much every way; gone. CA Visitor Maps had some visitor maps that can’t be found elsewhere, but I need to move past state-specific layers in the dropdown, and I hope to grow the NPS and USFS visitor maps soon to help make up the gap.
All of these layers are still accessible in two ways. First, any existing maps or links that referenced them will continue to work, although they won’t display properly in the layer dropdown. Second, they’re all available as prefill custom sources. Click on Add New Layer -> Add Custom Source, and choose the layer you want out of the “prefill with” dropdown.