3D Ski Slopes

In my last post I briefly mentioned photogrammetry-oriented web-services delivering data products that essentially hide the photogrammetric aspect of the data processing. But how about pre-packaged fused geospatial data products such as the 3D ski.com maps?

After seeing the post on these at All Things Digital, I checked out the site and was duly impressed. The ski maps fuse 3D terrain, vector data, and topo maps and package them up in a nice java-based viewer. There isn't any coordinate display but as a visualization tool the maps are excellent.

I suppose pre-packaged products are the distant cousin of web services. They aren't as sophisticated or flexible and the level of interactivity is limited (for example, you cannot interactively turn layers on and off in the ski maps), but they are dead-easy to use. It isn't an apples-to-apples comparison, but a lot of pre-packaged products seem easier to use than some of the services-oriented GIS web mapping implementations I've seen (although I won't pick on any in particular). Or the other way around, I think that presentation and usability need more attention in many geospatial web-mapping implementations.

Stereo Imagery as a Data Product

Considering the number of geospatial data products that can be derived from stereo imagery, it can seem surprising stereo images are not a widespread data product in their own right. Currently the main vendors of stereo data products are satellite operators such as DigitalGlobe (see here for their basic stereo pair product). Data derived from stereo imagery includes terrain, 3D vector data, and digital orthophotos: three of the most common products in the industry. Also consider that there are plenty of software packages on the market for creating orthophotos, generating and editing terrain, as well as working with vector data.


So why is it rare for stereo imagery to be sold as a "product"?

Personally I think there are a few reasons for this. These include:

• There's no practical standard for storing photogrammetry metadata (e.g. image exterior orientation parameters). Although there are efforts underway, photogrammetric metadata is typically stored in proprietary formats. This inhibits the ability of the data to move from system-to-system. For example, if the imagery was triangulated in System X and then provided to a person using System Y, they invariably have to go through some pain and suffering to ingest the data (running an import job at a minimum).

• Airborne flight operations are expensive. Data providers are typically contracted to fly specific jobs for clients such as regional authorities and so forth (here is an example). Times may be changing, but I haven't seen too many companies out there flying stock imagery and then reselling it. This is partly tied to the point above - without a common system for storing photogrammetric metadata, it is difficult for data vendors to deliver a one-size-fits-all solution.
  

• The workflow is perceived as being difficult. For example, you need specialized and expensive stereo viewing hardware, domain knowledge in photogrammetry, etc. It all depends on the application, but if you're not performing stereo work all day long as your primary job, then it is still possible to get high-accuracy results working in split-screen or anaglyph mode. As for the domain knowledge, once the imagery is triangulated, then derived products such as the ones above are very easy to create - although they can be time-consuming depending on the project size.

It will be interesting to see if stereo imagery develops as a data product or if there will be a migration to photogrammetry-oriented web-services that essentially hides the process from users. For example, perform server-side orthorectification with a catalogued RPC image and terrain model and then deliver the orthorectified image as a WMS or WCS. This kind of functionality is on the market now, and I think it could be poised for growth...

Los Angeles Web Mapping Service

In Monday's post I talked about processing image and LIDAR data for rapid response mapping. Around the time time as the exercise in China Lake, Leica Geosystems also flew downtown Los Angeles. A colleague and I had the opportunity to process the image data from raw imagery through to a final orthophoto (orthomosaic) product, and then we had it served up as a WMS using IWS technology.

Here is the WMS link:
http://demo.ermapper.com/ecwp/ecw_wms.dll?la?

If you have a decent web connection it is fairly straightforward to fire it up in ERDAS IMAGINE using the same workflow I walked through here. If you're prompted for a resolution or GSD, you can use 0.127 meters (this may happen if you have 9.2 SP1 loaded). Here's the entire project area loaded up in a viewer:

Since the imagery was flown relatively recently (late summer '07, I believe it was around August), it is quite a bit more recent then imagery in Google Earth or Virtual Earth. Check out the area just north of the Staples Center:

Google Earth (credits to Sanborn):No construction in the parking lot to the north of the Staples Center.

Virtual Earth (credits to USGS):Construction has started, mainly digging.

RCD105 WMS:Construction not yet complete, but buildings have started.

It is interesting to see the sequenced development over time. Which brings me to an enhancement request I've seen several times out there: Google Earth and Virtual Earth should really think about including the "date of image capture" as a displayable layer (or some other means). Right now it seems like guesswork to find out when an area was actually collected. This is "kind of" in version 4.3 of Google Earth - the dates of some images are displayed in the status bar, but not all (I think only satellite image collection dates are displayed). Since Sanborn is largely an aerial provider, there are no dates on their downtown LA imagery.

One of the interesting things I've noticed about the LA datasets in both Google Earth and Virtual Earth is that both seems to take the "high brightness, high contrast" approach to radiometric processing. This is good for making a pretty, visually appealing image, but tends to blow out some image detail in "light" areas (e.g. white and light colored areas). Here's and example from Google Earth (also downtown LA):
You can see that the RCD105 imagery looks quite a bit "darker", as I didn't bump up the brightness/contrast too much. It was also hazy on the day of data collection, which can also cause issues. However, keeping the brightness and contrast down allows for image details to be picked up - although I'm thinking of making a "pretty picture" version as well. Shows that radiometric adjustment is very much an art as well as a science!!

A few notes on the processing: the final orthomosaic for the project area in the RCD105 WMS was about 4.5 gigs. We used ECW compression (10:1) in IMAGINE to compress it down to a 220 megabyte ECW file, which was the final image used for the WMS layer. While is a lossy compression format, there is little visual difference between the IMG and ECW files. If you really zoom in close, it is possible to see some compression artifacts - but I suppose this is the trade off between speed and quality. For general purposes is seems like a decent method for prepping up imagery.

Accessing GeoBase Web Services

GeoBase, the Canadian government portal for free geospatial data, has made several GeoBase layers available as OGC-compliant WMS'. It is also worth noting that the data is free from most restrictions, as stated in the license agreement.

One of the new features in ERDAS IMAGINE 9.2 is the GeoServices Explorer. It is a new way to access web mapping services from desktop versions of IMAGINE and LPS.

Once you login to GeoBase, accessing their WMS layers is pretty straightforward. They send you the WMS service URL in an email, and that's all there is to it... In IMAGINE it is fairly simple to connect - just open a viewer, hit the "open layer" icon, choose a Web Mapping Service in the file type, and then hit the "Connect" button on the bottom right hand side of the interface.

After you hit the "Connect" button the GeoServices Explorer will open (see below). This will list all the WMS layers you can connect to once you have added the GeoBase services. There is a huge wealth of information available in GeoBase. The only thing I couldn't find that I had been hoping for was the SPOT 4/5 data that was made available for download earlier this year. I was able to download the SPOT data but unfortunately just didn't see it as an available layer to connect to...
In the example below I connected to the Canada-wide AVHRR composite - which was a breeze to connect to and display. It was also easy to display other layers such as roads and cities. They also have several layers outside Canada, covering the US, parts of Africa, and a few global datasets. I've included a screen capture of the IMAGINE viewer with the AVHRR data loaded in it.