Thoughts on Google Building Maker and 3D Building Extraction

Earlier this week Google introduced the Google Building Maker, which it bills as a simple tool for creating buildings for Google Earth. I gave it a whirl earlier today and while it is a relatively simple toolset, the direction is impressive and has some broad-reaching implications for the future.

The Concept

The general concept is fairly straightforward: using nothing but a browser, you can create a digital 3D representation of building structures using a very basic set of tools. Target buildings are located from a top-down view, and then buildings can be digitized from a series of oblique photos. Several oblique photos can be used to ensure your measurements are accurate from various angles. When you're finished digitizing your target building, you can save it to the Google 3D Warehouse. Upon saving, textures from the various photos are automatically applied to the model. Once the model is uploaded to the 3D Warehouse, you may download it as a KMZ or Collada file.

The Workflow

1) The first step is to launch the Google Building Maker.

2) Once the Building Maker is launched, you have to select a city to extract a model from. At present there are a few dozen cities in the USA, Canada, Mexico, Europe and Japan available. Why can't you extract buildings from your hometown? Most likely because the entire system relies on oblique aerial (not satellite) photography for making 3D measurements. The reason more cities aren't available is because oblique aerial photography is not cheap to acquire: so it makes sense that the currently available cities are clustered in the more prosperous regions of the world. Think hyperlocal advertising...

3) Once you've chosen a city, you are provided with the ability to zoom into a location until you can see a placemark. Once you're at the right zoom level, you can select/drag/drop the placemark to choose the building you wish to model. One interesting aspect of this process is that, in the initial view, you are provided with a color coded graphic overlay of the particular city you want to create a model in. The blue area, typically in the urban core, shows where buildings already exist. The white area shows the areas where Google doesn't have 3D buildings but does have all the ingredients (read: oblique photography) to create them.

Legend: Blue = Buildings Already Exist, White: No Buildings


Selecting an individual building

4) After you have dropped a placemark on a building, hit the "Start Building" button on the left. This will switch your perspective from a top-down imagery view to an oblique perspective view. You'll also notice a series of modeling tools on the top right. These include add box, add gable, and add vertical freeform block. There is also a tool for toggling the snapping of points and lines, along with a series of tools for where to place the new block (e.g. above selected, below selected, inline with selected, and unconstrained height). The tools are very rudimentary. For example, it isn't possible to model curves. However, I believe the idea for now is to collect the basic building structure. If it is an easy rectangular building then no further modeling is required, and if it is a complex structure you have the option to "refine your building" in Google SketchUp after hitting the save button. This isn't a particularly slick workflow, but it is fantastic step forward for users without access to photogrammetric tools or other methods for making measurement from photographs.

Perspective View Prior to Building Extraction

Extracted Building

5) Once you've saved your model to the Google 3D Warehouse, you may download it as a KMZ or Collada file. This is a win-win scenario that provides both you and Google with access to your model.

Extracted building in the Google 3D Warehouse

Photo-textured building displayed in Google Earth

The Implications: What Does This Mean???


Personally I think there are a lot of implications for this technology on a number of levels:

• Photogrammetry Software Vendors: can Building Maker replace proprietary COTS software for 3D feature extraction, such as solutions offered by ERDAS, BAE, and Intergraph (among many others)? In the short-term, no. The current Building Maker tools are simplistic and just scrape the surface in terms of functionality (e.g. no curves, no parallel lines, no attribution, etc). In the long term: Google is certainly setting the stage for a consumer-level system that may one day provide a robust system for 3D urban modeling. In that sense the Building Maker is a very disruptive move by Google.
• Crowdsourcing: An interesting aspect of the system is that Google denotes the areas they already have buildings for during the selection process. The implicit message for users is: collect buildings that we don't already have (although in fairness there are no restrictions on collecting existing buildings - but why would you?). The other item of note here is that the areas that have oblique coverage that do NOT have buildings already tend to be suburban areas outside the core that consist of low-rise buildings. I can't help but think that this is a clever idea by Google to acquire buildings for free in these areas rather than partner with a professional services company to do the job. But to give Google due credit, they provide users with access to their models. This means that, as a user, I now can use Building Maker to create as many 3D models as I want and then keep the output. And furthermore, I can do this without buying stereo imagery and the software required to perform stereo feature extraction - which can be a significant sum even when considering a small area. As an individual consumer, I now have access to a measurement toolset that was previously only available to professional businesses that had made the requisite investments in both the data and software packages...
• Is there a partnership between Google and an oblique vendor? Considering that Pictometry is the leading oblique vendor, I can't help but wonder if there is a partnership afoot. One thing to note here is that the oblique imagery is "Copyright 2009 Google".
• Can this lead to "browser-based photogrammetry"? In recent years I've been a proponent of developing systems that hide the photogrammetry and offer easy-to-use tools to enable 3D geoinformation solutions. I find it quite compelling that this is what Google has come to the plate with: a solution that anyone can use (consumer grade) that makes measurement from aerial photography very easy, and then provides value-added capabilities such as photo-texturing. While 3D feature extraction is only one aspect of photogrammetry, I believe it is a sign of things to come that a giant such as Google has already come to market with a functional solution that many vendors have only been thinking of...
• 3D measurements from mono imagery were commercialized initially (to my knowledge) by Geotango, which was subsequently acquired by Microsoft. This highlights the nascent competition between Google and Microsoft in this space.
• As mentioned in the Google Earth Blog, the big limitation is the fact that you have to choose from a list of available cities. One can only wonder what this will do for the oblique airborne photography market...

At any rate, kudos to Google for once again changing the game!

3D Buildings and Terrain in Virtual Worlds

One the the problems I've grappled with in the past is the challenge posed by modeling accurate photogrammetrically extracted 3D buildings in virtual worlds with a less accurate base terrain layer. The folks over at the Bluesky blog have outlined the same challenge in this post. Here's an example of the problem: when I import my KML 3D buildings into Google Earth, they float off the ground due to the accuracy of the base terrain layer. Here's a screen capture depicting the problem:
Even if you modify the terrain exaggeration the buildings still float. There's a few different methods for resolving this. One method suggested in the Bluesky blog post is to model terrain and imagery right into the KML file and then load it up in GE. This certainly works. Another method would be to take a look at a different system for visualizing the data.

The latest update to ERDAS TITAN has a good technique for sorting out this problem: it allows you to specify your own terrain layer. Once you add your data as layers in the viewer, you'll see a similar problem as depicted above - again due to the accuracy of the default terrain layer. The only difference is that instead of seeing floating buildings the buildings are embedded under the terrain layer, so that some of the smaller buildings are not visible. Here's a screen capture that displays the issue:

You can see that some of the buildings in the foreground appear very "flat", and there are others that are not even visible.

The solution is to add a terrain layer. In this case I processed my own digitial orthomosaic along with a terrain layer during the photogrammetric processing part of the project. I added the digital elevation models as layer, right-clicked on it and chose the "use as terrain" option.
The layer gets shifted to the terrain folder and the TITAN viewer updates to reflect the new base terrain. The result is that the buildings sit perfectly on top of the terrain. Here is the result, from the same perspective as the screen capture above:

In summary, take a look at TITAN if you're interested in this kind of workflow. The ERDAS TITAN Client is free, so you can download it from the ERDAS site and give it a whirl with your data.

China Earthquake Aerial Photography

There has been extensive media coverage of the recent earthquake in China. This was a major event: a magnitude 7.9 quake that did some serious damage. I noticed yesterday that Newsweek released created an interactive page showing some aerial shots of the damage. The images of Yingxiu and Dujiangyan show how the areas around the epicenter were absolutely flattened.

Here is a link to the USGS details page on the event. The "Maps" tab has several types of maps available, including a KML file of recent earthquake activity (in Google Earth below). It will be interesting to see if other geospatial datasets are made available of the disaster area in time - I would think there is a lot of aerial reconnaissance going on...

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.

Heading to Portland, Whereyougonnabe?

Later today I'll be traveling to Portland for the annual ASPRS Conference. The theme of the conference, "Bridging the Horizons - New Frontiers in Geospatial Collaboration", got me thinking about the new (beta) Facebook application called Whereyougonnabe? from Peter Batty and co at Spatial Networking. Whereyougonnabe is a service that allows you to enter in the "where and when" of upcoming trips and activities. The application then lets you know which of your friends will be close to you, making it handy for all kinds of reasons. This sheds some light on the company name: spatial instead of social in "Spatial Networking". I had a chance to play around with it a bit recently and was particularly impressed with the Google Earth support. The application allows you to click on a link that generates a KML file that you can use to fire up Google Earth (and other KML-supporting apps) and view your (and your friend's) trip pathes. See the screenshot below for my trip to Portland:


Not only is your path displayed, but it also has a timeline control. It also generates an icon out of your profile picture, which is useful as well.

Back to ASPRS: I will write some updates throughout the week, but if you happen to be going think about stopping by our UGM tomorrow morning, or come by the booth anytime! We'll be giving out some new ERDAS t-shirts and will also be have a draw for an Iphone between 3 and 4pm on Wednesday.

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...