Google Earth: The New Acceptance Criteria for 3D buildings

It was over five years ago when we came up with the initial Acceptance Criteria for photo-textured 3D buildings in Google Earth. Since then, we’ve learned many things and have also made many improvements to the 3D modeling process—including the release of Building Maker and two updated versions of SketchUp. Given all of these changes, we realized that our Acceptance Criteria were due for an overhaul.

Our new Acceptance Criteria have been completely rewritten with the goal of making them clearer and easier to follow. Issues relating to photo textures, permanence of structures, splitting, and entourage have proven to be the most common areas of confusion in the past:

Photo Textures

Our new minimum requirement for photo textures is more lenient than it’s been in the past. Photo textures are only required on upward facing surfaces of the model and on the main facade. We encourage you to photo texture the entire model, but we also understand that it may be difficult to get accurate imagery on every side of some buildings. Any remaining, non-photo-textured faces in your model should be painted with realistic-looking textures that match the color and look of the building in real life.

Permanent Structures

Beginning today, only permanent structures will be accepted. As we constantly refresh our satellite imagery, temporarily-positioned entities like vehicles and people don’t belong in Google Earth’s 3D Buildings layer.

Model Splitting


From now on, all submitted models should contain only one structure each. Each structure should be uploaded as a separate model file. This includes properties that have multiple buildings on them such as a house and a shed or garage. If buildings are all connected in a city block, they should be split into separate models based on building type, function or address. When our review team is assessing connected block models for splitting issues, we will look at the facade and roof textures to see if there are changes in material that signify where a split should have occurred.

Entourage


In addition to splitting buildings, we are now requiring all models of trees and other permanent entourage (such as signs, light posts and benches) to be uploaded separately from the buildings with which they may be associated. This ensures that when another building is uploaded in the same location, we are only judging the quality of the new building model versus the original. It’s a shame to have to remove good tree models just because they’re attached to a building model when a better building model is submitted that doesn’t contain trees.

Also, multiple, related trees and other entourage objects can be grouped into a single model as long as they are located in a relatively concentrated area. This means a single model can contain all the trees for a block or a park, but it shouldn’t contain all the trees for multiple blocks or an entire city. Remember that only permanent entourage is acceptable—cars and pedestrians move around, and thus don’t belong in Google Earth’s 3D Buildings layer.

Other improvements

One other big improvement we’ve made is the addition of tips and suggestions to each of the thirteen individual Acceptance Criteria. If a model you submit isn’t accepted, you’ll receive an email notification (opt into these emails via your preferences) that includes a direct link to concrete information about how you can improve it before you re-submit.

What about models that have already been accepted?

To help make this transition easier, we won’t be going through all the models we’ve already accepted in order to remove ones that fail to meet the new Acceptance Criteria. If your model has already been accepted, it will stay in the 3D Buildings layer until and unless it is sent through the evaluation process again. There are four actions which can cause a model to re-enter this process:

  1. You make an edit to your model and re-upload it to the 3D Warehouse, replacing the previous version.
  2. Someone else submits a model in the same location as your model.
  3. Periodic terrain and aerial imagery updates cause your model to go through our automated alignment process.
  4. Someone clicks the “Report a problem” link for your model in Google Earth.

It’s still a bit of a subjective process

Keep in mind that judging 3D models is still a difficult task and is prone to subjectivity. All submitted models are reviewed by real human beings who take time to ensure that they meet our standards. Because human beings sometimes make mistakes, we have a way for you to appeal negative judgements. If, after reviewing the Acceptance Criteria, you feel we’ve made the wrong decision, use the “Tell us why we’re wrong” link (at the bottom of the model’s 3D Warehouse page) to ask us to take another look. You’re encouraged to include links to photos of the actual building or other online resources to will help us to understand your point of view.

We know how much time and love goes into making beautiful 3D models for Google Earth, and we greatly appreciate all the effort you put into your work. Here’s hoping that the changes we’ve made will make for a smoother, more enjoyable geo-modeling process for everyone.

Jordan on Failing to Succeed

“I’ve failed over and over and
over again in my life. And that is
why I succeed.

–Michael Jordan (1963 – )
American basketball player

The 2011 NCAA Men’s Basketball Tournament concludes on Monday with the Final Four starting tomorrow night (04.02) at 6 pm EDT.

The quote above is from a commercial by Nike (30 seconds). When you need a well-earned break, enjoy this 4.5 minutes with Michael Jordan in “What is Love?” Great even if you’re not a basketball fan.
_____

Geek Time with Chris DiBona

The end of the year is always a great time to take a moment and look back at the developments of the past twelve months. Two members of the Google Open Source Programs Office, Chris DiBona and Jeremy Allison, sat down together for a review of open source accomplishments in 2010, and the conversation is shared with you here. Chris is the Open Source Programs Manager at Google, which means he directs Google’s open source compliance, releasing, and outreach efforts. He reveals lots of insights into Google’s approach towards open source and the influence of open source on technology and business.

The video of their discussion is separated into five parts, with descriptions below.

Part 1
Chris and Jeremy discuss their favorite open source projects of 2010, including GoogleCL, Android, Chromium, Chrome OS, and WebM. Together they ponder the future of computing, debating whether or not 2011 will be “the year of the Linux desktop.”

Part 2
Chris explains how Google decides what software to open source and under which licenses. He also mentions tools such as Make Open Easy (MOE) that are used to help engineers release and maintain their code. The topic eventually turns to license defragmentation, and Chris describes his efforts to streamline the number of licenses that Google releases under. In the process he shares his theory about what makes open source projects succeed.

Part 3
Chris and Jeremy talk about Google Summer of Code, its history, and the impact it has on the open source community.

Part 4
Chris and Jeremy are old friends who met in the 90’s at a Silicon Valley Linux Users Group meeting. While reminiscing about the early days of Silicon Valley, they discuss the modern role of user groups, both here and abroad. Chris visited Qatar, Egypt, and Jordan earlier this year, and he compares the tech atmosphere in those countries to Silicon Valley in the late 90’s, with both open source and entrepreneurship developing simultaneously.

Part 5
Chris gives an overview of his career and explains how he came to be the Open Source Programs Manager at Google.

Happy New Year, and see you in 2011!