The Yahoo! Internet Location Platform

I guess interesting stuff does come out of Where 2.0. Simply put, the Yahoo! Internet Location Platform creates an ID called WOEID (Where On Earth ID) for every location on earth and has an API to geocode back and forth from that WOEID.

In simple terms, the Service allows you to look up the unique identifier – called the Where on Earth ID, or WOEID – for almost any named place on the Earth; it also allows you to resolve a WOEID you have received from a third party – such as Fire Eagle’ or Upcoming – to the place it represents.

The API is accessed via HTTP GET; the following examples can be cut-and-paste into a web browser to view the results (note that these links do not work properly with IE6):

Find the WOEID of a significant landmark:‘sydney%20opera%20house’)

Resolve a WOEID to a place:

Find the WOEID of a specific place:‘northfield%20mn%20usa’)

Obtain a range of WOEIDs that match a given place, ordered by the most likely:‘springfield’);start=0;count=5

Find the parent of a given WOEID (and return a detailed record):

Return the Placename for a given WOEID in a specific language (where it exists):‘usa’)?lang=fr

To obtain the representation of a place in JSON format:

To obtain a list of geographies that neighbor a specific WOEID:

The Yahoo! Local & Maps Blog explains it as “a more elegant way to abstract the relationships of location, and unambiguously describe places in a permanent, language-neutral manner.”
One of the overused examples of a place in Arizona is the Grand Canyon so lets put that in the system and see what we get:‘grand%20canyon’)

I like the hierarchy here: In the above example, Grand Canyons Village’s parent is the county of Coconino, whose parent is Arizona, whose parent is the United States. These relationships should help users get more information out of places than they did before.

Dan Catt has some details on his blog about WOEID and how Yahoo! is using it.

A look at PostgreSQL and ArcSDE

Dave Bouwman has some thoughts on using PostgreSQL as a RDBMS for ArcSDE (or ArcGIS Server Enterprise as we should be calling it).

Thus far I’ve simply come to realize that I have a lot to learn. I need to grok a lot more about Postgresql and PostGIS to start, and then add ArcSDE into the mix.

While everyone is really excited about PostgreSQL support at 9.3, remember it won’t be as easy to administer as SQL Server is (at least to those who already use SQL Server). Just keep that in mind before abandoning SQL Server outright for PostgreSQL.

Developing in a Virtual Environment

I’ve asked the question on Twitter, but I’d like to get a more broad idea of what people think about developing applications inside a virtual environment. Results were pretty much on both extremes, either people love it, or people told me I need to get a new IT staff. We do have virtual servers running already, but the reality of actually developing inside a “virtual workstation” might be totally different. The upside of having different virtual environments available to me to use and not have any spillover into my “real” operating system seems greater than the downside of performance (especially on my laptop). But what do you guys think?

Total Recall

I sure as heck don’t want to end up like Arnold

The GIS Interchange File

All too often we have to request people resend datasets to each other because they get blocked by email, one important file gets left off or systems just don’t recognize a file type. I’ve run into a problem today where a company FTP site is rejecting a shapefile because it doesn’t recognize the .shp, .shx, .dbf extensions. I thought I could get around by zipping the data, but it appears to scan the zip file for extension types. So the “solution” was to zip the shapefile, change its extension to .doc and tell the recipient that they need to change the extension back to .zip.

This kind of stuff happens way too often. Personal Geodatabases have the problem of the .mdb extension that is rejected outright by most email systems and other formats aren’t readily usable by folks systems. The “old days” were easy because we all used coverages and shared them via the .e00 format that was almost always acceptable by everyone. Amazing how we take such steps back over time and you’d think data sharing would be easier than it was in 1995.

How do you folks share data? KML, GML, Etch A Sketch, e00, zip, web services, etc?

Update: Jason Birch has some ideas about using SQLite as an interchange format. Well worth the read.