I find this is a bit of a surprising action from Google. In 2005 they changed the mapping and geospatial web by providing a powerful, easy to use great API (eventually), and primarily free of charge slippy map platform. The term “GoogleMap” became synonymous with being able to pan and zoom through the entire world without any reloading of the page or poor user experience. Since then, there have been millions of sites that have used GoogleMaps to provide simple map views and location services. Assumedly this information has been of huge value to Google in understanding interest, spatial-context, and generally eyeballs to Google tools and content.

Google has also worked to monetize maps, often subtly through sponsored map markers, and other times more directly through in-map ads. Each of these decisions brought discussion and disent but it was difficult to argue with the fact that the tool was still free to use. Google has clearly put real value in content and engineering into Google Maps. The quality of geocoding, data availability and power of the API has always been extremely capable and arguably the best of breed.

Now, with a very direct pay requirement being imposed this will dramatically change the adoption of GoogleMaps. Developers will have to consider very carefully how they will afford the potential – and optimistically likely – fees that the service will require as it becomes successful.

Fortunately, there are still a few really good alternative options for developers of sites if they can’t afford the usage fees. MapQuest has really embraced the future of open by supporting and integrating OpenStreetMap into their sites. Microsoft Bing maps are very capable and there are many more – not least of which is a developer “rolling their own”.

This interesting change by Google also validates abstraction libraries such as Mapstraction. Mapstraction provides a common API where a developer can easily switch between map provider libraries without having to rewrite their code – something that would likely cost much more in the short term than paying for usage fees. On GeoCommons we use ModestMaps to be able to switch to any map data provider service.

I’m very interested to see the general developer reaction to this change.

libkml was originally “announced” about 6 months ago as part of the kick-off of the standardization of KML within the OGC.

libkml is interesting in several ways. KML itself is just an XML specification for geographic data. Nothing really special compared to other XML formats. However, as I’ve championed there is a big difference between types of developers that use and read schemas, and those that use libraries or simple examples and documentation to implement parsers or tools. This is justified in that developers (both consumers and producers as discussed here) are usually trying to solve some other problem and want to use a format like KML merely as a mechanism to publish and visualize their information. By providing a stable and full-featured library, developers are free to build tools around the library without having to deal with the intricacies and issues of the format itself.

Similarly to the effect of opening the standardization of KML to the OGC effected other organizations like Microsoft to embrace the format – an open-source library also encourages other implementations, or competitors, of KML applications. Google is primarily in the business of data organization and search – so the more tools that publish or utilize a format they can then index is a win.

Another implication of libkml is that a single library can grow with versions and features, again freeing the developer from having to track future versions or bug fixes to the format.

Lastly, libkml is written to be fast – which is essential for handling large KML documents, realtime visualization, and potentially even mobile/limited-resource clients. However, how small libkml can be made is left to be seen.

As Michael Ashbridge pointed out, this is a very “alpha release, not Beta in the Google sense”. In fact, in the documentation there is the very clear disclaimer: “THIS IS ALHPA SOFTWARE. Expect changes. We do not yet recommend use in production code.”

There are still a number of features that are not yet implemented that are forthcoming, or can be accomplished by the broader community. They’re looking for feedback from developers on the interface and functionality. The library is C++, with SWIG bindings currently in Ruby, Java, Python, Perl and PHP. There are examples for developers to get up and running quickly.

It’s released under the new BSD license. It is meant to be as open as possible for developers to use in both open-source and closed-source projects without worrying about interference with other licenses.

It’s great to see Google pushing on the open-{source,format} in geospatial. They’ve obviously done a lot to raise public awareness of placemarking and geospatial data with GoogleMaps and GoogleEarth – they’re now engaging the GIS community and helping them.

Hopefully people, at least developers and users in the know, can soon stop referring to KML strictly as “GoogleEarth format” or “GoogleEarth Layer”.

Dealing with Reality

An issue we commonly run into is the reality that there are a lot of KML and other data sources in the wild that are malformed. There is the common response “it works in GoogleMaps, why doesn’t it work elsewhere?”

libkml is able to handle, to some extext, ‘bad’ KML, but is very strict in outputting KML that is generated using the DOM API in the library. Hopefully this generally raises the quality of available KML.

lib{geo}

A potential extension to libkml that excites me would be the ability ingest a KML document and publish it out as other formats such as GeoRSS or GML. Especially if a higher-level interface was built onto libkml that abstracted away the specifics of KML and instead provided an interface for general geometry (and feature) creation and manipulation.

Unfortunately since my laptop hard drive died last week, I don’t have a development machine to build and play with this yet. But I expect to use this library in a number of projects.

Google Code Project: libkml.

It was a tough time to be away, a lot of amazing news came out. First and foremost is that Google adds support for GeoRSS. This is exciting news because it demonstrates the maturity and interest in the syndication of geographic content in blogs, CMS’s, sites, and news.

This will also add a little bit of more difficulty moving forward in GeoRSS. Now that a major company has added support, and assumedly a lot more developers will add support now as well, then the specification has to be much more cognizant of future changes, users, and upgrades. Before, the specification was really guided by the majority of developers using the standard itself. If some spec was changed, we all went out and updated our libraries. Now, however, we really need to denote versions, and how users can update their tools to accomodate both the new version and backwards compatibility.

On top of that exciting news, Google also open-sourced part of the GoogleMaps library. See the
gmaps-utility-library-dev FAQ. Currently this is limited to the GMarkerManager, but demonstrates their interest in opening the library up for interesting projects, ideas, and hacks.

Tags: googlemaps, programming, georss, geo, neogeography, javascript, open-source,

I disagree. If a mapping API vendor is required to (or tries to) stay within an agreed upon ’standard’ API, then that could stifle features/innovation. They would have to all agree on a standard to, say, add polygonal overlays, or moving objects (e.g. tracking realtime position of other vehicles)

However, when this ‘abstraction of API’ is relegated to other projects (as he points out Mapstraction, OpenLayers, and MyMap do this, they don’t just attempt it) then each of them can decide if they are a minimal set implementation (only allow what all allow), or a maximum set, or somewhere in between.

What is better if they just support mapping using data format standards. They should all consume open/non-partisan standards such as GPX, GeoRSS, GML, etc. That way someone doesn’t necessarily need to know the entire API if they can just load and map their common data source.

Is there a way to vote for the anti-request.

cross-posted from comments on Geonames

Tags: googlemaps, api, standards, geonames, georss, gpx, gml, ogc, google, marcwick, openlayers, mapstraction, mymap

Now GoogleBooks supports mapping of locations mentioned in books they’ve archived. See Lonely Planet USA for the locations mentioned in this travel guide. A great way to preview what locations the book focuses on and covers. (via hobu, via import cartography)

Or for fictional books, such as Neal Stephenson’s Quicksilver it can help you decipher what happened where.

Google has the benefit of being able to store and share the text for currently copyright material, which is a definite benefit. But the integration of maps really adds to the information and understanding of the material.

Tags: books, googlebooks, googlemaps, mapping, geo, maps, gutenkarte, copyright

His claim is that they take their bounding box parameters in different order: bbox=x1,y1,x2,y2. vs. box=x1,y1,x2,y2. However, based on my research of the API's, they look comparable. For example, Google Earth's view based refresh will do a bounding box request:

longitude_west, latitude_south, longitude_east, latitude_north

and the Flickr photo search expects the following BBox:

minimum_longitude, minimum_latitude, maximum_longitude, maximum_latitude

You can see that minimum_longitude is the same parameter as longitude_west, and so on. So I’m not sure why Dan Catt uses that as his explanation that the parameters don’t line up.

However, as Brady points out, what would really help everyone is if the services all spoke common languages, like Flickr outputting KML, or GoogleEarth consuming GeoRSS (since Flickr can output GeoRSS). My money would be on the latter, since there seems less impetus for a company like Flickr/Yahoo to export their data in a proprietary format.

Of course, the translation between the two formats, especially for basic geometry such as points, is trivial, so implementing both on both sides, or simple conversion utilities in the middle, would be straight-forward.

Extra Credit

For extra credit, implement said conversion utility to convert KML <=> GeoRSS using XSLT, or other language of your choice.

There are also various other Flickr/GoogleEarth utilities out there like displaying grids of the # of Flickr images in GoogleEarth.

Pleasant Surprise

While researching parts of this post, I found a new Flickr API method that I didn’t know existed before:

flickr.photos.getWithGeoData – “Returns a list of your geo-tagged photos.” However, you can’t do a search within this set other than by date. But at least now you can pull up a trail of your travels based on your photos.

“Where were you on the night of the 13th?!”

In the past, when using my Feed URL to get geotagged photos, I just made sure that photos had a tag “geotagged” and then grabbed all the photos with that tag.

Tags: flickr, google, googleearth, georss, kml, standards,

Now you can see the effect for your self. ocarto allows you to overlay 7 layers of maps from Google, Yahoo, MS Virtual Earth, and Terraserver.

Search for: 44.300572,-78.339096 in ocarto, and zoom in all the way. It’s the town of Peterborough, Ontario, Canada.

You can search for the nearby town of Royal Oak, MI to see a lot of new development, roads that don’t exist on many maps, existing on Google. (I’ll send them a cookie)

Tags: maps, ocarto, googlemaps, michigan

It’s Open-Source project hosting, with what seems like very advanced issue tracking. Fast, easy to understand, simple.

There are already some projects up, like Rails App Installer and Biometric API for Linux.

I assume all/many of the Google Summer of Code projects will end up hosted here. Also, I could see Google providing something like a Krugle source-code search for finding specific files and code snippets. Then why not go ahead and toss in a Code Snippets where anyone could highlight/mark source code as useful, and pulled out for others to then see these snippets easily.

Google Hosting FAQ

Tags: google, googlehosting, sourceforge, opensource, open-source, programming, codesnippets, oscon, oscon2006

The largest noticeable difference is that when you “zoom” it’s first just increases the resolution size of the current layer of tiles, and then replaces them with the actual higher-resolution (new) tiles as they come back from the server. The effect is a kind of disjointed ‘popping’. I like the idea that the zooming is better, but I don’t think they should zoom the text – which makes the popping more apparent.

There are other little flavorings are Web2.0-boxing of the ‘Search the map | Find businesses | Get directions’ tabs.

Ahh, I see there was a GoogleMaps Blog post titled, appropriately “Zoooooooom!”.

Interesting note, this is one of the first Google service in awhile that wasn’t rolled out as “Beta”. I guess it’s one thing for users to understand that their email/calendar/maps may be wrong. But don’t be messin’ with my money!

WebMonkey Review

While all of the food, drink, etc. is cute, and very much intended to keep employees at work, rather than wanting to go home, I feel that the overall effect was attained that Google is a dynamic, creative environment. There aren’t the age-old water coolers to flock around, but small kitchens, couch circles, and whiteboards. People are free to decorate their cubicles, and there are even “famed” cubicle decorations that are explicitly shown on the tour.

Overall, it seemed like a good effect for a large company to try and maintain a sort of “small-company”/startup feel. Of course, this is only on a 40 minute tour, and no experience actually working with the management and teams, but it still gave a good feeling. Everyone was smiling.

The Real Deal

After all of the “oohs” and “ahhs” of the campus (and getting to eat in the Google “No Name Bar”), we came to the real point of the day, Google strutting some geo-stuff.

Now, coming to Google, I wouldn’t have been able to pick out Sergai or Larry from a lineup. So I was surprised when 3 guys came up on the stage in the demo room, and 2 of them were introduced as such. My first thought, “wow, they look really young”. Not your typical ‘white-hairs’ (at least not yet), but guys that looked like it would be fun to hang out with.

New stuffses

As has been announced/discussed elsewhere, Google released a new version of GoogleEarth with yummy interface goodness, and the really cool ability to display nice models using textured 3D geometry and raster images. This is all handled by the new and improved KML 2.1, which is the XML geo-format Google inherited from Keyhole and competes with GML and GeoRSS.

One of the really strong messages from the demonstrations was “Where you look is where you search.” GoogleEarth is “just another browser”, like Firefox, though it is a much different paradigm.

As the program lead of GoogleEarth posed, consider the following situations. A user wants to find out about Shakespeare. They can:

• Navigate to Scotland and then search for Shakespeare. This would display important locations in Shakespeare’s plays
• Go to a Shakespeare website and find a map of pertinent locations

Both are valid means of search, with different basic paradigms of what a user wants to find out (spatially pertinent information)

Where are the Pixies

I managed to get myself into the Pixie Hunt, which was a photo scavenger hunt, geek style. Each team was fitted with a cellphone, GPS puck, and list of tasks they had to get their photo taken doing. Standard embarassing stuff like: Make a Human pyramid including at least one stranger, or have a team member give a stranger a rose using their teeth.

The new premise was that photos were uploaded after taking to a Flickr pool, geotagged, and scored by the server. Your team could also see the other pictures that had been taken by other teams for the same task.

The game was fun, as it involved lots of semi-tired, hopped up geeks running around San Jose generally menacing the population. Restaurant Maitre ‘d are incredibly useful in these situations. Utilize them.

However, there were some logistic issues, which illustrates why it’s worth having conferences like Where. The phone application was slow, and a little difficult to use (disclaimer: I was not the captain of the team, so I didn’t get to hold the phone. I just got to stand in awkward positions while the captain had to deal with the interface and slow camera). Also, we had a bluetooth GPS puck with us, which should have geotagged all of the photos. However, at the end of the hunt, we didnt’ see the results.

What should have happened was there should have been a Map display of all the teams routes, where they took pictures, and how they all overlapped. We would be able to see if we all took our photos of being thrown out of a restaurant at the same restaurant, or if we had our Guiness pint in a real Irish pub, or just some local pool hall dive.

It was still a fun game. It would be neat to have a “generic” scavenger framework where a user could quickly fill in their scavenger tasks, upload it all to any players’ phones, and the server would handle the responses. Perhaps YAP (Yet Another Project).

And so, after a full day of fun, its off to bed.

Technorati Tags: where2.0, where2con

I agree with Matt Croydon’s take on the 5/15-minute presentation schedule. It seems very “lightning round”, but also a really good way to get lots of ideas out and then move the interesting discussion to the sideline and various nightly gatherings.

In particular, the Birds of a Feather (BoF) meetings should be great. There is a Microformats meeting to discuss the possible directions microformat. also hope to meet with some of the GeoRSS developers and bloggers.

I’ve even secured a place at the Google Geo Developers day on June 12 – so I should get a chance to show off my cool mashup projects. Not to mention discussing other possibilities of visualizing geo-specific driving simulations in GoogleEarth.

I think my biggest concern about attending is wanting to meet everyone and discuss all the current ideas and possibilities in location information & mapping.

Of course, to get to California, I’m heading out of Vienna early, by way of Detroit, then on to San Francisco. Yay lots of time on a plane. Here’s to hoping for flying on something nice like an Airbus 330.

I agree with Matt Croydon’s take on the 5/15-minute presentation schedule. It seems very “lightning round”, but also a really good way to get lots of ideas out and then move the interesting discussion to the sideline and various nightly gatherings.

In particular, the Birds of a Feather (BoF) meetings should be great. There is a Microformats meeting to discuss the possible directions microformat. also hope to meet with some of the GeoRSS developers and bloggers.

I’ve even secured a place at the Google Geo Developers day on June 12 – so I should get a chance to show off my cool mashup projects. Not to mention discussing other possibilities of visualizing geo-specific driving simulations in GoogleEarth.

I think my biggest concern about attending is wanting to meet everyone and discuss all the current ideas and possibilities in location information & mapping.

Of course, to get to California, I’m heading out of Vienna early, by way of Detroit, then on to San Francisco. Yay lots of time on a plane. Here’s to hoping for flying on something nice like an Airbus 330.

Technorati Tags: google, mapping, maps, where2.0

What happens when users have the ability to hijack sites and how they expect to be used? For example, there are scripts to provide mapping functionality within Flickr!, or to compare book prices on Amazon.com with other vendors.

MapThis! overrides the “Map This!” link that shows up in GMail when an address is detected. Instead of linking to just a plain-ol’ googlemap, the link is “hijacked” to provide routing directions from the user’s geolocated position (using HostIP) to the address in the email.

This is useful, for example, if a friend sends you the address of their house, or that cool roller-rink with disco ball that you’re meeting up at and you want to quickly get directions.

It also demonstrates how a user isn’t limited by the interface a site-designer supplied, allowing them to customize and use the site as they wan.

Think Calendar and Traveling.

If you’re interested, and actively use (or will start using) GoogleCalendar, or an iCal program like Appl iCal, Sunbird, AOL Calendar, et al. then drop me an email at: testing@highearthorbit.com and I’ll let you in on the info.

The idea is I want to test with a small number of “cutting edge” users before releasing it public. It’s easier to fix bugs and answer support requests that way.

One of my entries, which may or may not actually be considered a “mashup”, is a Firefox GreaseMonkey script called GreaseRoute that creates map and route icons for an Microformat formatted adr or geo locations. These are often used in an hcard.

One of the cooler parts is that the extension automatically determines the location of the person viewing the page. Using the HostIP IP-to-Location database, the user’s location is automatically entered as the starting location. So when a user is viewing the webpage of, for example, a store or business, they can click the “route” link and get turn-by-turn directions to that location. No more copy & pasting street/city/state to a form or asking the person next to you “where are we?”

Microformats are a stepping stone on the way to the semantic web. They are a simple way to encode useful information for viewing and mining by users and other applications (ala mashups).

Example adr

The proper format of the adr is as follows:

<div class="adr">
 <div class="street-address">1517 N. Main St.</div>
 <div class="extended-address">Box 203</div>
 <span class="locality">Royal Oak</span>,
 <span class="region">MI</span>
 <span class="postal-code">48067</span>
 <div class="country-name">US</div>
</div>

which will then be displayed as:

Example geo

Instead of an address, one can instead just encode the latitude and longitude:

The Result

GreaseRoute has 2 version, the lite version and the embed version. The lite version displays a map and route icon next to the addresses found on the webpage:

The embed version displays a “route” link. When clicked, a pop-up map is displayed between the users location and the encoded address.

Give GreaseRoute a try and let me know what you think.

You can also go over to Userscripts.org, the GreaseMonkey script repository, and rate them and leave comments.

• UserScripts.org: GreaseRoute
• UserScripts.org: GreaseRouteEmbed
• UserScripts.org: MapThis!

Account Authentication for Installed Applications: The ClientLogin API lets you use programmatic login in your desktop or mobile applications. This API incorporates CAPTCHA for greater security against password trollers.

No more Error=BadAuthentication

For example the date is now its own tag:

<gd:when startTime='2006-04-17T15:00:00.000Z'
endTime='2006-04-17T17:00:00.000Z'></gd:when>


And the location is either as simple as a name:

<gd:where valueString='The best pad'></gd:where>


The format specifies possible advanced location encoding via GeoPoints, postal address, primary and alternate locations.

<gd:postalAddress>
   22646 Woodward Ave.
  Ferndale, MI  48220
</gd:postalAddress>

up to:

<gd:where rel="http://schemas.google.com/g/2005#event"
      valueString="Woodward Ave Brewers">
  <gd:entryLink href="http://local.example.com/10018/JoesPub">
    <id>http://local.example.com/10018/WoodwardAveBrewers</id>
    <category scheme="http://schemas.google.com/g/2005#kind"
        term="http://schemas.google.com/g/2005#contact"/>
    <content>Good beer</content>

    <link href="http://www.woodwardavenuebrewers.com"/>
    <gd:contactSection>
      <gd:postalAddress> 22646 Woodward Ave., Ferndale,
              MI  48220</gd:postalAddress>
      <gd:geoPt lat="40.75" lon="-74.0"/>
      <gd:phoneNumber>(212) 555-1212</gd:phoneNumber>

      <gd:email address="info@woodwardavenuebrewers.com"/>
    </gd:contactSection>
  </gd:entryLink>
</gd:where>

This makes it much nicer for parsing. The API even allows for adding new events to a calendar.

Update: you have to make sure and grab the full version of the Calendar feed and not the basic
version. The Basic version contains the same old wonkiness. However, the full version is the new yummy XML-ified version. You select this by changing the last tag on the URI.

Basic:

http://www.google.com/calendar/feeds/username@gmail.com/private-magicCookie/basic

vs.

Full:

http://www.google.com/calendar/feeds/username@gmail.com/private-magicCookie/full

I spent the weekend digging further into the Google Calendar tidbits and putting together a project. There are some odd things about the XML output.

The actual date and time of the event are stored as plain text in the summary node:

When: 2006-05-14 20:30:00 to 2006-05-14 22:30:00
Who: Where: Boston Logan Airport, Boston, MA
Event Status: CONFIRMED


Why didn’t Google use some form of XML, perhaps inspired by the Microformats hCalendar format? This is especially important because as Google demonstrated, it seems to change between using <br> to properly formed <br/> tags (breaking my parsing code).

What is even more puzzling are recurring events:

Recurring Event
First start: 2006-04-18 09:00:00
Duration: 5400
Who: Public,Where: Warren, Michigan
Event Status: CONFIRMED


There is no actual output of the ending date, or type of recurrance the appointment has. iCal specifies it as the following:


DTSTART;TZID=America/New_York:20060418T090000
DURATION:PT5400S
RRULE:FREQ=WEEKLY;BYDAY=TU;UNTIL=20060627T130000Z


which covers all the pertinent information for recreating the output. This is perhaps why the Google Calendar homepage add-in doesn’t yet support recurring events. It’s currently impossible to!

And don’t trying going to http://schemas.google.com/, which is where the schema tag points to.

Lastly, it would be very nice if the If-None-Match request-header was honored for updating the calendar RSS feeds.

Hopefully Google fleshes this out soon.

Create your calendar

You have numerous options for creating your calendar: iCal (Mac), Mozilla Sunbird (Mac, Windows, Linux), Outlook2iCal (Windows), etc.

Setup a public server to host your calendar

You have several options to publish your iCal calendar:

• Apple .Mac provides iCal hosting, but costs $$ (or £, ₪, 圓, ﷼, etc.)
• Setup WebDav on your own server to host calendars
• iCal Exchange is a free calendar sharing host
• Just FTP/Automator your iCal file to a public server

Publish your calendar

Using one of the prescribed methods above, you will then want to actually publish your calendar to the host (or upload via FTP/SSH/SFTP/carrier pigeon on 5.25″ floppy disk). You can turn on “Publish Changes Automatically” to have your changes on your computer automatically uploaded to Google Calendar.

Subscribe to your calendar in Google Calendar

Do the following:

1. Manage Calendars
2. then under “Other Calendars”, click “Add calendar”
3. Fill in the URL of your published calendar – this is probably supplied by the hosting server (like iCal Exchange, .Mac, or you can figure it out for your own server)
4. Click “Ok” and wait a little bit for it to be uploaded

Bask in the warming, glowing warmth…

You’re now done and have a Google Calendar version of your local iCal calendar. Unfortunately, at this point, Google Calendar doesn’t let you edit this “public” calendar, though you can add events from this calendar to one of your Google Calendar calendars (if that makes sense, you’re astute). Now you can just publish when you’ll be available to stop at the local pub for a brew!