Well, it’s official. And as reported here: “The whole process is anticipated to take less than a year.” 363 days later, that statement holds true.

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

At the OGC Technical Committee meeting today in St. Louis, Google pushed out the initial release of an open-source library for parsing and publishing KML. Read more about it on the Google Open Source Blog.

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.

As part of some continuing work with clients and heading to the OGC Technical Committee meeting to wrap up the OGC Web Services KML initiative (OWS-5 Agile Geography) - taking a very quick trip to Ann Arbor (2 days) and St. Louis for 3 days.

Stopping in Ann Arbor was really great. It’s the first city I’ve lived in long term that wasn’t attached to my attending school. When visiting my other alma maters I am primarily faced with nostalgia, but disconnect since all my acquaintances were transient like me and I know few people remaining in the town.

Ann Arbor, however, is like coming home. By contrast to my previous residences, as I wrote before I was fortunate to connect into a great community that is thriving here. Within an hour of sitting in a coffee shop I serendipitously connect with two great people - and had meetings, coffee, or hop tastings with many others. It’s great to be able to so quickly feel comfortable when traveling. I’ve understood one of the primary reasons of chains like Starbucks or Subway is to be familiar to travelers as they find themselves in otherwise unknown locales.

One goal of local search of user-generated is to give outsiders a view into the local life. However, they haven’t yet been able to breach the feeling of familiarity and reward that comes with visiting an old favorite restaurant or brew.

While our plans are still undecided for the future - it’s a great comfort to know I can stop into a great town like Ann Arbor and feel so welcome.