Entries in bug (4)

Tuesday
May042010

Google Maps Earth View: Observed Behavior (and a bug)

UPDATE: 20100801 The looping bug outlined below has been fixed.

 

First, it should be said that adding “Earth View” to Google Maps is a stroke of genius.

  • No need to install the Google Earth application 
  • Links and live embeds to Earth view maps work also

While testing Earth View in the context of my Little Colorado Fly-through Tour, I found a problem with the way Google Maps pans and/or zooms to make a selected place-mark visible. But first, here’s an Earth overview of my user map in progress. Earth tip: try moving the pointer while the button is pressed, and use the Control and Shift keys to change the behavior (rotate compass, tilt camera up, etc.)


View Little Colorado (Grand Canyon) Tour in a larger map

In experimenting with “user maps” using the Earth View feature, it is clear that the Maps place-marks lack the control that the “micro-format” .kml provides — specifically, the view parameters specified in the “lookat” object.

<LookAt id="ID">
  ...
   
  <!-- specific to LookAt -->
  <longitude>0</longitude>            <!-- kml:angle180 -->
  <latitude>0</latitude>              <!-- kml:angle90 -->
  <altitude>0</altitude>              <!-- double --> 
  <heading>0</heading>                <!-- kml:angle360 -->
  <tilt>0</tilt>                      <!-- kml:anglepos90 -->
  <range></range>                     <!-- double -->
  <altitudeMode>clampToGround</altitudeMode> 
          <!--kml:altitudeModeEnum:clampToGround, relativeToGround, absolute -->
          <!-- or, gx:altitudeMode can be substituted: clampToSeaFloor, relativeToSeaFloor -->

</LookAt>

While the view details above can be captured with “link” and “embed,” they are not easily captured in a Map place-mark, except by placing a full Google Maps “permalink” URL inside the placemark. 

The default orientation for viewing placemarks in Earth View is due north, where the compass at top left has N at the top (a.k.a. “heading” or “yaw”) at the current zoom level (altitude), and the default camera angle is approximately 45 degrees “up” from straight down (“tilt”)

Casual URL decoding of Google Maps permalinks reveals

“&ecpose=36.18409487,-111.79393673,1482.19,-2.755,44.995,0”

which as expected seem to represent (most of) the six degrees of freedom:

  • latitude (X)
  • longitude (Y)
  • altitude (Z)
  • yaw (Z rotation)  “heading” i.e. rotation of compass
  • pitch (X rotation) “tilt” or camera angle measured from “straight down”
  • roll (Y rotation)  usually zero, i.e. the horizon is at an angle
  • the last parameter may or may not represent “range”

Problems with the Little Colorado river include the narrow canyon, steep walls, and the narrow body of water. Default behavior in Google Maps includes “automatic” view adjustment based on the user’s selection. In the case of the placemark below, many usage patterns leave the placemark invisible, and the algorithm for adjustment often loops and loops and eventually fails, with the view left as shown below.

The addition of Earth View means any place-mark may be invisible in a given view, and the automatic “pan/scroll/zoom” algorithm isn’t quite smart enough yet to handle a few odd cases.

  • terrain (elevation) data — a mountain comes between the view and the place-mark
  • zoom level of the view — at low altitudes (high zoom), elevation data starts to obscure things
  • “heading” (compass rotation) — The view may see the place-mark only if oriented properly 

 

Observing the long looping period it seems what is attempted by the algorithm includes coming closer to the placemark and changing the “pitch” or camera angle. Unfortunately, the “due North” default and maintaining the “zoom” (or altitude) are both problematic.


View Little Colorado (Grand Canyon) Tour in a larger map

Other minor Earth View oddities include the “zoom level” indicator which is always in the center in Earth View, and the fact that “zoom in/out” via the embedded control behaves differently than scroll up/down (the “mouse” equivalents for zoom.) Using a scroll wheel maintains the camera tilt, even if you run into a wall. The zoom out control un-tilts as the altitude increases, and zoom in does the reverse, remembering the tilt that was in effect.

In the process of making many custom user maps, some quirks and deficiencies in Google map making are apparent. Here is a quick list of some pet peeves. 

  • There is no way to make a placemark that is specifically a “Street view” or “Earth view” flavor. Capturing the “map mode” and view details via permalink URL inside a placemark does work but has problems: there is no other way to switch modes or change the view, and there is no way to tell if you are looking at the exact thing described by the URL.
  • There is no way to specify a “place-mark” that includes view parameters other than latitude and longitude.
  • Map making is frequently tedious because the tools are unavailable in Street View and Earth View modes. Context is often lost when switching to “regular” map mode.
  • User photo icons are vanishingly small in the Earth view mode.

 

Monday
Apr262010

Google street view trash (cleanup on aisle 101)

This is pretty amusing, because it’s a supposed to be a street view segment in front of Google’s building 900, and instead shows trash piling up along highway 101.  The segment continues apparently right across highway 101 in a vector that surely would have killed the vehicle operator. The second live map embed shows how everything goes wrong as Alta Avenue is crossed. Google’s reputation as an environmentally-aware company suggests they should “adopt-a-highway” and clean up the trash (assuming it hasn’t been already.)

 


View Google maps - anomalies errata & candid moments in a larger map


View Google maps - anomalies errata & candid moments in a larger map

Tuesday
Apr132010

Google street view: Street view at night (Mexican Hat, UT)

UPDATE: night segment removed 

That was quick! The entire segment has been removed as of one day later.

Gray man will return to yellow if/when segment is re-done

UPDATE: reported via “proper” channels

“Hello, According to our records, you recently submitted a report regarding an inappropriate image in Street View on Google Maps. We’re currently reviewing the material you reported to determine whether the image should be removed from the product. We appreciate your assistance. Sincerely, The Google Maps Team”

This “inappropriate” street view segment probably includes thousands of images.

Street view at night shown here. Ok, so who’s the wise guy that thought no-one would notice?


View Larger Mexican Hat, UT Map

Wednesday
Mar112009

Yahoo Pipes OPML FAIL (Google Reader)

Go to My Yahoo Pipes if you want to verify or play along: “BROKEN Fetch OPML -do aggregate …”

I went to add a simple feature on this site: a list of entries from blogs I like. Also known as a widget showing a magic RSS feed. Enter Yahoo Pipes. Should be simple enough, except I discovered that almost every OPML parser in use is broken with regard to google reader. I have many many subscriptions, so I create a number of folders for organization. Because I use google reader as my "master" feed subscription list, I think it's important to get these basic tools right. I'm going to solve this step by step,  starting with a better  method for parsing the xml, to handle "nested" OPML a la google reader. Folders are empty parent items with a no URL or "type=rss", just "text", "title", and children.
<?xml version="1.0" encoding="UTF-8" ?>
<opml version="1.0">
  ...
 <body>
  <outline title="arts" text="arts">
   <outline text="Civic Center" title="Civic Center" type="rss" xmlUrl= ... 

So, to summarize: FetchData & Yahoo Pipes Help are deficient, and all the OPML aggregation examples I’ve tested are broken. They use FetchData to make an item list out of body.outline, so you get a list of “folders”, instead of the actual feeds. yahoo-pipes-opml-fail1