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.

Between Sensors and GIS Content

One of the things that has always struck me as unusual is that there does not seem to be a lot of insight into the role of photogrammetry in the broader geospatial community. For example, google “GIS data” and you’ll get a lot of hits on various GIS data sources, including street maps, census data, building footprints, cadastral data, and so forth. However, it is important to keep in mind that this data typically is not first generation, but rather a derived product. Often the data lineage is not tracked (or at least not tracked back directly to the sensor), so users making business decisions based on the data do not have insight into how the data was developed, potential problems with the data, the true accuracy, and other issues…

At any rate, the point of this post is that photogrammetric processing provides the link between satellite/airborne sensors and GIS data. How and why? This is because geospatial data frequently derived from some sort of sensor, be it airborne imagery, satellite, LIDAR, GPS, or any other of the measurement sensor technology. This is how we get the “Geographic” part of GIS. All that great orthorectified imagery you see as a layer in a commercial GIS or in Google Earth, Microsoft Virtual Earth, and ERDAS TITAN typically goes through some sort of photogrammetric processing. The Virtual Earth 3D blog has a good post on how UltraCamX sensor data is processed for delivery in Virtual Earth. The post doesn't contain the technical details of exactly what sort of processing is applied, as the exact nuts and bolts of the workflow is likely a Microsoft/Vexcel trade secret at the moment. The general workflow is fairly well-known though, as photogrammetric processes can produce all sorts of primary base map and other data (mainly orthos, terrain, and 3D feature data) as input into a spinning globe app or a GIS...

Stay tuned for the next post and I will walk through an "photogrammetry to GIS" technical example...