Friday, September 7, 2007

Weekly Google Code Roundup: Learning to Remember The Milk offline, flying over Earth, and searching your feeds

| More

Google Code - Updates: Weekly Google Code Roundup: Learning to Remember The Milk offline, flying over Earth, and searching your feeds

On the back of the stream of developer releases last week, we had some interesting activity in the community, and from our own product teams.

Omar Kilani, of the Remember The Milk team, did a fantastic, thorough write-up of his experience getting his product working offline with Gears. The article moves past an introduction to delve into the design decisions around an offline-capable architecture, and user messaging and presentation of state. We learn why Omar decided to go with the explicit offline mode, and then the five steps to offline conversion.

The Google Mashup Editor team has also been churning out new features based on your feedback. As a developer you can now enable public read only $user feed so that applications can share $user feeds to create social applications, edit XML, CSS and HTML files uploaded into the editor, work with Gadget files, and much more.

The cool easter egg of the week goes to the flight simulator that is in the most recent Google Earth application. There is something special about flying around the grand canyon, or over manhattan. Give it a try.

Flying is cool, but we all love searching. The Google Reader team released the much anticipated feature of being able to search across your feeds. If you knew that you had read about something a few days ago but couldn't find it, now you can.

Sharing is a kin to searching, and the Google Book Search, which had a significant Ajax facelift a year ago, has joined the two. A summer intern added the ability to save snippets from public domain books, and embed them to your website. It is as simple as selecting the text you want, and how you want to show it (an image of just text).

Featured Media

Mark Stahl, tech lead of the Google data APIs, talked to us about GData, the history behind it, the parts and pieces, and how people are implementing applications on top of it.

Quicksilver is a keyboard-driven launcher that is the first application that I install when I get a new Mac. Nicholas Jitkoff, creator of Quicksilver, is a Google employee on the Mac team, and they finally got him to talk all about Quicksilver: past, present, and future.

Mark Utting came to talk about Model-Based Testing and he compares two different kinds of test model: black-box models and white-box models.

As always, check out the latest tech talks, subscribe to the Google Developer Podcast and visit the Google Code YouTube channel.


Thursday, September 6, 2007

[Gd] v2.88: Clickable Polylines & Polygons

| More

Official Google Maps API Blog: v2.88: Clickable Polylines & Polygons

In our latest release (2.88) of the API, we've added "click" events to GPolyline and GPolygon, much to the enthusiasm of developers in the forum. Since a few developers started speculating on how we implemented click detection in the API, we're giving you all the juicy details right here. (Warning: Algorithms ahead!)

Polyline Hit Detection

As polylines have no intrinsic width, detecting clicks on polylines is something of a judgment call. To detect polyline clicks, we need to determine two things: whether clicks are close enough to a polyline to count as a click, and which segment of the polyline is the closest to the click.

Overview of the Algorithm

Click detection begins by measuring the distance (in pixels) between the clicked point and the polyline. For each segment of the polyline, we compute the distance between the clicked point and the nearest point along that segment. We then take the minimum of these distances as the closest segment; if the distance is then small enough, we declare it a click on the polyline.

Reducing the Sample Set

Note that the simple algorithm has to look at every segment of the polyline. It can be quite slow for big polylines (such as driving directions). There are a few heuristics which drastically improve the simple algorithm:

  • Given the bounds of the currently visible map viewport, we discard points which are off screen. This can drastically reduce the number of points to consider.
  • As we zoom out from a detailed polyline, we also condense and "smooth" segments of the polyline into a simpler group of segments without noticeably changing its shape. In the example below, we simplify a polyline from 9 points at the highest zoom level to 4 points at a more zoomed-out level.

Using Bounds Trees

If we discern that a clicked point is far away from a segment, we discard it from consideration. We take advantage of this fact by precomputing the bounds of groups of segments; if a clicked point is far from these bounds, we skip computing distances for all of the enclosed polylines. By recursively combining these bounds for larger and larger groups of segments, we build a "bounds tree" that allows us to skip most of the segments when performing hit detection.

This dramatically speeds up polyline hit detection. For example, we can detect clicks for complicated polylines like the query Washington to San Francisco. This polyline has around 2000 points.

Polygon Hit Detection

Detecting whether a clicked point is within a polygon is more straightforward, and less open to interpretation. We first draw a straight line from the clicked point to the right of the screen. Each time this test line crosses a segment of the polygon, it changes state from being inside to outside or vice-versa. If the test line crosses an odd number of segments then the point is determined to be inside the polygon, whereas if the test line crosses an even number of segments then the point must be outside.

We can apply many of the same improvements for polylines in polygon detection, using the map viewport and zoom level to drastically reduce the number of segments to consider, and using a bounds tree to avoid performing unnecessary intersection tests.


[Gdev] GIQT

| More

Google Code - Featured Projects: GIQT

GIQT Screenshot
Google APIs used:
GIQT is a local database query tool using Gears.


Wednesday, September 5, 2007

Google Developer Podcast Episode Eight: The world of Google data APIs

| More

Google Code - Updates: Google Developer Podcast Episode Eight: The world of Google data APIs

Mark Stahl is a technical lead on the Google data APIs team. Many of the APIs that Google offers are part of the Google data API family, so we thought it would be prudent to get some time to chat with him, and discuss all things GData.

If you are new to GData, or want to learn more, listen to the podcast to hear:
  • What "Google data API" actually means (the parts and pieces)
  • What Atom, Atom Publishing Protocol, and other tech behind GData are all about
  • What GData adds to the mix on top of Atom and APP
  • How Atom compares to RSS
  • What are ETags? And how can they help me?
  • Why REST, the style, was chosen for these APIs
  • Where REST makes sense, and where it doesn't. Resource driven vs. RPC.
  • What the first GData APIs were
  • How the killer app of syncing data with Google Calendar
  • How you actually use the APIs? What do they need to learn? What tools do we give them?
  • Can you write APIs that implement the same GData APIs?
  • And much more.
You can download the episode directly, or subscribe to the show (click here for iTunes one-click subscribe).



Tuesday, September 4, 2007