Ryan Sarver shares the info on Twitter’s new location API. Looks really simple, and really nice.

curl -u USERNAME:PASSWORD -d location="Arlington, VA" http://twitter.com/account/update_location.json

You can even use GET, which means bookmarkable location settings (similar to FireEagle)

http://username:password@twitter.com/account/update_location.xml?location=Paris,+France

There has been a number of GeoTwitter clients and applications show up. And a lot of discussion on alternate picoformats for location markup.

By extracting this away to Twitter proper, it means any application can set this information how they want, and have it updated in the user’s profile. One thing that is lost is the ‘home’ location of that user as their profile potentially becomes very temporal.

FireEagle as the central store is a good option, however it is just one location store and Twitter’s location will no doubt serve as the centralized location store for a number of new applications. As more social or personal applications gain location storing and sharing support, there is a question of how synchronization between these services will easily happen.

I don’t want to have to set my location in multiple services. This is the same problem that troubles social bookmarking sites such as del.icio.us and magnolia. This may become especially problematic if there were automatic updating services that detected a change in FireEagle and then updated your Twitter location, and vice versa - which then updates FireEagle from Twitter. Perhaps causing an implosion of the GeoWeb.

There has been a meme floating around about the new “Geotag Icon” that was originally proposed here and now has an officious site: Geotag Icon Project

There has been a lot of dialog. Sean discusses a lot of his thoughts about semantic interoperability and formats. There has also been a number of discussions on the design itself - everything from the color, to the pushpin being indicative of points only - maybe reinforcing the “red dot fever” that plagues many maps.

These are really minor quibbles. Overall I think it’s a decent design that gives some simple meaning to what the icon conveys. However, the problem I do have is the Usage guidelines & examples. Essentially, they are saying it should be used for all geospatial formats.

Example from the site:

Bruce defends this:

Whereas the Geotag Icon describes a general concept (”This item is geotagged”) the KML icon and GeoRSS favicon each proclaim a file format. This is analogous to the Feed Icon: can you imagine having a different orange icon for each web feed format? There’s no reason why the Geotag Icon can’t sit side-by-side with file format icons if that’s what folk wish to do. But a well-recognized Geotag Icon (in time!) adjacent to the text description “Download KML file (opens in Google Earth)” could well be more informative to the majority users than what is otherwise sure to be a growing set of vaguely-related file format icons with which to become familiar. The power of de facto standard icons is in instant recognition—and the fewer the merrier!

I disagree, he’s proposing this one icon should be used for a multitude of different formats that each have different capabilities and uses. It’s not like the difference between RSS and Atom, it’s the difference between HTML and RSS or CSS. Or a Video and a Photo. Sure, they’re both images, but they’re also very different in what they do.

He’s creating additional confusion by using the Geotag icon for GeoRSS. GeoRSS isn’t even a file format, it’s an extension to another file format: RSS / Atom, and they already have a recognizable icon that has meaning to users. I wouldn’t want to put yet another icon in front of them that meant something slightly different. And KML is a visualization format, similar to HTML + CSS. GPX is a very specific format that works for handheld GPS units and PND’s. I’m surprised the Geotag Icon wasn’t proposed to be used for Geo and Adr Microformats, since it matches this formula of all things geo.

This is the follie of the greater GIS community - assuming something is primarily geo first, and general information second. I’m surprised this is idea is also followed by people outside the GIS world.

So I only ask that the Usage guidelines of the Geotag icon be scaled back. It’s interesting that it’s been incorporated into Minimap Sidebar - good idea, but perhaps again confusing application with format? Using it in a photograph or video is nice because it’s clear to me that the format is a video (and I don’t care if it’s mov, fla, et al.) and useful to be alerted that it has geocoded content inside. I also think it could be useful as a link to a page of Geospatial formats. Why not even use it like the Share this on… on the Geotag project page itself?

GPX icon is from Garmin’s Communicator Plugin. You could optionally replace the format names (like KML) with suggestion applications, but I find this a little to vendor specific. Don’t you dislike it when people say things like “I opened the Internet Explorer page…”?

I think this set of links is how I would do it in GeoPress. But don’t suggest that Geotag Icon become the over-arching marker for other formats that happen to contain geo-data. Otherwise, I’ll be suggesting a family of icons like Timetag, and Titletag.

There is a lot of discussion, and projects, about developing solutions that address people being able to engage with HyperLocal information. In fact, the project names speak for themselves: UpYourStreet, EveryBlock, etc.

Having lived primarily in the suburbs or small towns that have a less diverse, or at least small scale distinctly diverse, culture to them, I could understand, but not relate, to this concept. From my background, one block was nominally the same as the next, there was little direct difference between them and granularity was limited to the “area of the city”.

But having lived the last month in San Francisco, and more directly, in the Tenderloin, I learned very intimately about this concept - but also think it falls short and is potentially too expansive in it’s area.

The Tenderloin has a reputation for being rough and tumble, or edgy. What this translates to is that the various streets and alleys are filled with vagrants and drug abusers. The Tenderloin purportedly gets it’s name from cops that worked the area and would take bribes for shady deals - and as a result they could afford better cuts of meat from the butcher.

The on the ground reality is that the Tenderloin looked at as a single entity has shady aspects. However, it very much depends on which street - and even which part of the street, side, and facing direction. From the apartment I lived in, one chose their routes based on time of day. Heading east and north were through safe streets, past hotels and restaurants - but south and west were past shady dealers, well frequented liquor stores, and generally unsafe situations.

Looking out from from my apartment I could see 270 degrees - to the north was a Hilton, the west was a church, and south were liquor stores and constant groups of impoverished and drug abusers. Across the street from the Hilton on the south side is a Cuban Restaurant and a shop selling X-rated videos, and to the west is a upper-end wine store and chic Vietnamese-Fusion restaurant.

This is just a single viewpoint in one area of the neighborhood, but summarizes the general topology of the Tenderloin.

View the entire Mapufacture Feed

A View of Two Services

This was most succinctly demonstrated right outside my window. I overlooked the Glide Memorial Church, on the corner of Taylor and Ellis - a gorgeous building that made my view one of the best in the area. Glide is renowned for it’s Sunday ‘Celebrations’ that are more like group concerts than church services.

The services are so well attended, a line starts 30 minutes before the doors open, lining up along Taylor heading north.

Glide also serves a vital service to the community in providing meals and shelter for vagrants. The line for people to line up to receive meal tickets, or to head in for the night, lines up along Ellis heading west.

So at 11AM on a Sunday morning I would look out my window and see from a single perspective two very different worlds, on one corner you had low, middle, and upper class families from the city, as well as tourists and visitors waiting to attend services - and on the other corner was a mirror reflection of low and impoverished people lining up for food.

Tenderloin National Forest

The Tenderloin was always full of surprises. One morning on an expedition from the east corner of the Tenderloin, to the far west end heading to the Scone Factory, Corrie and I were astonished to stumble across a true hidden gem: The Tenderloin National Forest, tucked into Copland alley.

While the various neighborhood projects are doing great work, as Steven Johnson points out it’s also difficult to provide a nationwide interface to what are very local issues and perspective. So local that if you geocode to the wrong side of the street or around a corner, you have completely changed the context of that information.

Fortunately, there is a project underway to enable the community map the neighborhood. In a small area that has such variety and required local knowledge, it is vital for them to mark viable business and residential areas in order to encourage development. I think projects like this are vital to fill-out the localized aggregation services and provide a truly super-hyper-local perspective.

SuperHyperLocal Tenderloin - a photoset on Flickr

A commonly requested feature addition to GeoRSS has been multiple locations per entry. Currently, GeoRSS only adds a single geometry per RSS or Atom entry. This was pragmatic and served the general goals of GeoRSS.

There are several commonly encountered use cases. News reports typically mention several locations. Bloggers using GeoPress may tell a story about a trip and want to reference several spots along their trip - especially if they are documenting a tour that includes a path and sites along that path such as in EveryTrail. Dan Schultz talks about why “One Location Doesn’t Cut It”, citing other examples from news journalism.

Adrian and I recently sat down together to quickly brainstorm on what this may look like. The features we were looking to add were: multiple geometries, excerpt for that geometry, and toponym for that location (venue, city, etc.) Additionally, we didn’t want to break current compatibility.

Other services are already including multiple locations in different ways. Flickr outputs a single location in two different formats of GeoRSS: Simple, and some odd form of deprecated W3C. MetaCarta’s RSS-to-GeoRSS converted currently just dumps multiple locations into the entry, but without identifying if these are unique locations, or just variations in format type or hierarchy.

We wanted to call out that this is in fact a different type of geometry - a multi-geometry. Both KML and WKT support multi-geometry, but without being able to reference what the points are individually about. That’s useful if you are, say, marking all the holes in a field, but not for narratives.

Another feature we wanted to try and support was to be able to reference geometries stored elsewhere. Currently in GeoRSS feeds you’ll typically see references to a City or Country just include a point to the center of that geography. Not really indicative of what the article was about, or useful when trying to find all the geographic data about an area. So it’s important to include lines and areas as appropriate. However, including huge outlines of states or nations, potentially multiple times within a single feed, can have drastically bad consequences of increasing feed file size and complexity.

Here is a snippet of what we are proposing:

The first part to notice is that we wrapped the multiple geometries in a georss:collection. This allows current parsers to not be confused by encountering multiple georss elements unwrapped and being unclear if they are multiple representations of the same geometry, or different geometries.

We also included a excerpt attribute that allows you to include some text referencing what this location is specifically about. This can be text from the article itself, or some other useful information. One concept we had considered was using some reference to the text wrapped in the article itself, but this seemed burdensome and prone to problems using an attribute of one element to embedded text in another element.

The second element is a georss:polygon that includes a src reference to the geometry stored elsewhere. The rel tag specifies that it is the geometry of this element, and the type helps the tool know what the representation is of the stored geometry. This way a tool that is consuming the GeoRSS can go and fetch the geometry if it wants, or if it already has a cached version, say referenced elsewhere in this same feed, then it doesn’t have to request it again.

Of course, with a standards development, it is useful to consider how a user interface might provide for including multiple locations in an entry. Here is a mockup of how I imagine a simple interface would appear, and probably how we’d implement it in something like GeoPress:

Article: We went to visit downtown Cedarburg before the conference. Had some great sandwiches at Joe’s. If you haven’t been to Cedarburg, Wisconsin, then you haven’t really experienced the MidWest…

Locations:
- Excerpt: Went to visit downtown Cedarburg…
- Type: Point
- Geometry: 43.296700 -87.987500
- Name: Cedarburg, Wis.

To promote ideas and discussion around these and other proposals, I’ve created proposals at GeoRSS.org on multiple location and referencing external geometry. Please let us know what you think about the idea and format. We know that we can’t please everyone, but like the origins of GeoRSS, we’re just trying to address a real need with a simple format.

Yahoo Brickhouse finally released their new shiny FireEagle service. If you haven’t heard of it before, FireEagle is a user location brokering system. No more, no less. It provides a secure authorization system and interface to allow third-party applications to update a user’s location, or query a user’s location.

There have been, and are, other location sharing systems. Most recently, Plazes, TwitterVision, my.loki, Loopt, Dodgeball, and more coming online soon. However these systems were either hampered by being too much, not providing good interfaces, unclear security and authorization, and worst of all, user lock-in or siloing. Those services have great purpose and use and communities, but they aren’t the cross-application interfaces they could be.

What’s incredibly exciting about FireEagle is that it does one thing really well - and provides excellent hooks for using this information. It’s a service about user-geolocation enabling other applications. Its one of those services that a user comes to for signing up, but after that never needs to come back to FireEagle at all. Applications build in authorization, publishing, and accessing their location into their own interfaces.

And even better, you can publish your location from one system, say a mobile device, and have other applications access this, say from a social network site.

This concept follows the concept of loosely coupled systems. Other location sharing systems typically required all potential users to be members of that particular service, using that interface. For example, I can’t view locations of my twitter contacts in Plazes, or from a single mobile app - where a combined interface has utmost importance.

I’ve recently updated my blog, and included in the header my current location from FireEagle. I can now set my location via Dopplr, mobile phone, dashboard widget, or whatever cool next generation shoe tracking service, and have my site automatically get this - or view in FaceBook.

FireEagle will do for geolocation what GoogleMaps did for online maps, or Twitter did for small messaging exchange: Provide an underlying framework that developers can innovate on top of.

I explained before why the iPhone doesn’t need a GPS, and FireEagle makes this especially true. In the end, I just want it to be easy for me to share locations with people and use this for finding things around me. I don’t really care how that happens, I just want it to happen. And loosely coupled systems like FireEagle abstract away the geolocation method from the geolocation-sharing.

Unfortunately the blog is agog so far today with numerous posts by misunderstanding newszines that see it useful to bash FireEagle and comment on “lack of apps”, or “user base”. They’re not understanding the concept that FireEagle is a tool, not an endpoint.

I hope FireEagle doesn’t get feature-itis. Users and devs are asking for social networks, stored location names, and other features that each have their uses, in specific application spaces. But FireEagle is powerful for just the reason that it doesn’t do all these things. It’s like saying Amazon’s S3 needs to have “Friending”. External applications should be innovative with how they use and extend FireEagle.

You’re already seeing applications add integration. Dopplr will set your location once per day based on your trips, PresenceRouter helps join FireEagle into the other geolocation services. Dangerday is a Twitter bot that will allow you to publish to FireEagle from the plethora of Twitter applications and sites out there. FireWidget is a Mac OS X dashboard widget, and FireWrench is a GreaseMonkey script for polling your location in Firefox. There are a couple of other really exciting applications and interfaces to FireEagle that can be found with some lurking around (I leave this as an exercise to you the reader until the apps officially announce themself).

We’ve also built in FireEagle support into Mapufacture and will soon be showing off some of the really interesting things FireEagle lets us do for our users.

Jesse Newland has a very good ruby library, and I believe the Yahoo Developer Network will be putting up libraries for PHP, Python, Javascript, Java, Objective-C, and C#.

FireEagle is also using the new OAuth specification - one of the first large scale service to do so. Along the way they’ll have to do a lot of developer education on how to use OAuth, but it’s a leap in the right direction. Using OAuth it makes it simple to connect to multiple services without having to cater to as many unique authentication mechanisms. The pain is early in development but pays off in the end.

So developers - this is a call to you, go out and build cool stuff with FireEagle!