thinking of geofeeds where feed paging does not take you back in time, but increases the search radius. but how to specify paging semantics?

My first feeling is that ‘zooming out’ is not really a link. Pagination is just a crutch to deal with returning the full set of a single query in meaningful window sizes due to server response, bandwidth, client parsing, and maybe human interface. Zooming out implies actually performing a different search and would be a function of a client interface.

This mechanism is provided by OpenSearch-Geo, which communicates how a client would use a bounding box or polygon search. Therefore a client interface could choose how to zoom out or in and has the capability to query the system this way.

Feed Clusters

However, I still could imagine more specific uses for such a concept. Erik’s original idea is perhaps thinking more about using geography as a way to indicate limiting search set results. This might be done using clustering mechanism, such as k-means, similar to how one might view dense data on a map in clusters, but in search result feeds. The link elements would provide looking into any of these clusters, or zooming in.

<feed>
    <title>Search for 'coffee'</title>
    <georss:box>38.87,-77.2,38.89,-77.0</georss:box>
    <entry>
        <title>8 results</title>
        <georss:box>38.87,-77.2,38.91,-77.1</georss:box>
        <link rel="self"
          href="http://server/search.atom?q=coffee&amp;bbox=38.87,-77.2,38.91,-77.1<"/>
    </entry>
    <entry>
        <title>15 results</title>
        <georss:box>38.87,-77.1,38.9,-77.05</georss:box>
        <link rel="self"
          href="http://server/search.atom?q=coffee&amp;bbox=38.87,-77.1,38.9,-77.05"/>
    </entry>
</feed>

Structured clustering

Another way this concept could work more literally would be to utilize a hierarchy, or several hierarchies, that a client may be able to easily snap to in order to query larger or smaller geographic areas. These hierarchies are not apparent in a simple search template and can provide more semantics to indicate the larger area rather than just simply “zoomed out”.

For example, using the GeoNames GeoTree or GeoPlanet woeid’s, a search result could provide links from the specific bounding box query up to regional or districts that contain this query – as well as perhaps subsets contained within the bounding box.

<feed>
    <title>Search for 'coffee'</title>
    <georss:box>38.87,-77.2,38.89,-77.0</georss:box>
    <link rel="up"
        href="http://server/search.atom?q=coffee&amp;woeid=2347605"
        title="Search Virginia for 'coffee'" />
    <link rel="down"
        href="http://server/search.atom?q=coffee&amp;woeid=12590311"
        title="Search Arlington County for 'coffee'" />
    <link rel="down"
        href="http://server/search.atom?q=coffee&amp;woeid=12590343"
        title="Search Fairfax County for 'coffee'" />
    <entry>...</entry>
</feed>

Written on no wifi, sitting in the Detroit airport after a red-eye flight from WhereCamp.

The GeoCommons team is expanding and we’re looking for some cutting-edge developers and designers to join us. We’re using a wide range of technologies to build an easy-to-use and incredibly powerful geodata sharing, visualization, and collaboration platform that is being used in organizations from the government, to enterprise, to international NGO’s, to local communities and groups.

With GeoCommons, we’re integrating Neogeography with GIS to provide powerful tools to users: if you can make it fun on the web where users aren’t required to stay, then customers will love you. And by integrating with other tools that each user is comfortable with, whether it is Excel, Notepad, GoogleEarth, or ArcGIS Desktop and QGIS; we help bring GeoCommons to them rather than making them come to GeoCommons. We’re also pushing the next generation of GeoWeb standards: KML, GeoRSS, GeoJSON, and making them more powerful and supported. These are ideas we started with Mapufacture and are quickly integrating with Finder!, Maker! and the rest of the GeoCommons suite.

As a part of our team, you would investigate large-scale data sharing and linking, geospatial and data visualization mechanisms and tool development, web native API integration and community building. We’re working with many other groups in the open-source as well as GIS communities to help integrate data and tools to broadly disseminate all this quality data that has otherwise been inaccessible and make it easy to visualize and use in decision-making.

We’re looking for developers with real programming chops – you should be comfortable considering Mongrel and Nginx versus Passenger, know when to use unobtrusive Javascript or call ActionScript Flash hooks, have played with ActiveMQ and Stomp, beanstalkd, Starling or other queueing systems, read technology news and blogs and preferably have a site yourself where you share your experiences and code with the world. We’re looking for community members and developers that like working in teams, attending programming groups, and are comfortable sharing their ideas. We encourage you to have hobbies and side projects – we’ve built quite a few ‘lab’ tools ourselves such as context-free music and touchscreen whiteboards. And you don’t have to be an Apple user, but it helps.

Welcome to Washington, DC

FortiusOne is located in Arlington, VA – directly above the Courthouse Metro on the Orange line into DC, and a short walk into the district directly. The DC area is on an incredible spike of growing technology community. Where else can you live in a “metro area” that encompasses at least 3 states, all of which are metro accessible? The area is also renowned for it’s bike accessibility. The recent election has cast a spotlight on the future of technology in the government with President-Elect Obama’s Change.gov initiative. The upcoming inauguration is sure to be an incredibly historic event and you could be here to help map it.

As for the community, there are at least three Ruby-specific groups, a NOVALang where learning new programming languages is the prime objective, RefreshDC, TwinTech, and one of the most open governments to geodata standards and sharing. We’re also quite big fans of the local beer selection and hard to beat the food variety.

Let us know

So if this sounds exciting to you, and you’re interested in joining the team – please let us know! You can also check out the formal listing.

Dave Troy has put together a solid backend that is aggregating together Twitter, SMS, voice, iPhone and Android native applications, and even YouTube. Others have built the iPhone specific applications. I’ve been working on the mapping and data sharing side of the project. The first goal was to provide a number of mechanisms to share the data that we’re gathering with everyone. Additional mashups and visualizations are free to use the data streams to pull all the data that VoteReport itself has – so definitely go wild with your ideas. A quick breakdown of what’s available:

OpenSearch – http://votereport.us/opensearch.xml

This is the OpenSearch description document that outlines all of the feeds and various filters that you can use when getting to the data. Always check this as we’ll update it with new parameters or data streams. In addition, the various responses discussed below include OpenSearch styling pagination so you can walk through the entire database of reports without having to drink right from the firehose. This also includes the OpenSearch-Time extension.

KML – http://votereport.us/reports.kml

Getting the reports.kml will give a Network Link – this is useful for GoogleEarth and other KML clients to automatically update every 60 seconds with new reports. You can append live=1 to get the full KML document. I have included all the useful attributes in the ExtendedData element of all the Placemarks. Each Placemark also has an id for easy reference.

GeoRSS-Atom – http://votereport.us/reports.atom

Just want to subscribe to the feed in your RSS reader, this feed is useful for getting updates.

GeoJSON – http://votereport.us/reports.json

JSON is super nice for doing client-side mashups and visualization. This is what the VoteReport Map itself is using. It includes a lot of information for each report, including reporter, icon, location.

All of these feeds even can take a dtstart= with an ISO-8601 date for getting reports after a certain time (and optionally dtend= for getting time-bounds of reports). A useful geographic filter is to use state= with the capitalized two-letter state code to just get reports within a state. So for example http://votereport.us/reports.atom?state=VA is a GeoRSS feed of reports in Virginia. As I mentioned, I did build a quick map that you can view at http://votereport.us/reports/map.

We’re continuing to build it out with new features as more data comes in. You can easily embed the map in your site using (and optionally remove the state=):

The difficulty with creating more visualizations is the lack of pre-election data. This system has been built to primarily capture a huge amount of valuable information for one day. We’re not sure before hand what this data will look like, coverage or attributes. Typically visualizations are made by exploring and playing with the data to see what emerges. In this case, we’re making estimates (and guiding via the tutorials) on what data we’d like. Therefore, the map itself has simple mechanisms for styling markers based on the user-supplied report. But the data is far to dispersed so far for something like a heatmap.

Fortunately, the team consists of a large number of public advocates that are spreading the word which should encourage more citizens to use the system and contribute both good and bad reports. Andy Carvin of NPR put together this NPR coverage, and we’ve also received coverage from Time, Huffington Post, New York Times, TechCrunch and even Craig Newmark. Check out the TVR press page for more coverage links.

And if you would like to help contribute to the project, check out the VoteReport Wiki. I imagine there will also be a number of post-election visualizations and analysis to come out of the reports.

The very first session I attended was moderated by Peter Corbett from iStrategyLabs and Dmitry Kachaev of the Office of the CTO for DC talking about open data from the government.

The Princeton research paper “Government Data and the Invisible Hand” proclaims the need for government agencies to first and foremost share their data via open and broadly used standards (via Ars Technica).

The DC government is already sharing a large amount of data via a variety for formats: GeoRSS, KML, CSV, Shapefiles. Check it out at http://data.octo.dc.gov and also CapStat: Building a City That Works

Information. Knowledge. Progress. Welcome to CapStat, your resource as a District of Columbia resident to track how District Government is working for you. You can use these pages to track the performance of individual agencies, find neighborhood statistics and learn how your government is responding to the city’s most pressing challenges. As the District of Columbia works to become a world-class city, visit this page to follow its progress and find out how you can become part of the solution.

When the Office of the CTO for DC wanted to update their site and services they brainstormed how to do this – the typical method of hiring a very expensive contractor to build a complicated tool that would be poorly implemented – or open up the system for the community and see what emerges.

Fortunately they chose the latter and recently launched Apps for Democracy – a contest that anyone can submit an entry for a mashup or application using the DC data services.

Data stream of data

One comment that came up was the desire for a feed of the available data and updates. Right now there is a web page and some of the data is available as GeoRSS – so continually updated. However, what would really be great and facilitate federation would be a published GeoRSS feed of datasets that links to each of the available formats, updated times, filesizes, metadata, etc.

By comparison, this summit was meant as a brainstorming around geo and search interfaces and responses. Pulling from the announcement:

We would as much as possible like to bound the discussion to: 1) common ground for geospatial search for web resources and 2) integrating spatial search into search protocols. As part of the discussion we would also like to get advice from the other communities about which catalog/registry search protocol is the ‘mainstream’ one (or more?) that we (OGC) should align with and in turn, be sure that spatial search is supported in a thoughtful but not cumbersome way by the broader IT standards community.

You can see a partial list of attendees here.

There was a good overview of existing, albeit often quite complex, search interfaces. As is potential in meetings like this where attendees have their own history, investments, and beliefs in standards, the discussion can become difficult to easily resolve.

A couple of interesting agreements came out of the meeting. Foremost was the understanding for guidance of using simple, common formats as they already exist when appropriate. This means using OpenSearch as a base URI templating mechanism and follow GeoRSS-Simple specification for geographic data. Of course, a format can expand upon this and offer more complex formats that conform to more complex specs. But by at least providing a common baseline means that almost any service can easily interconnect with another service.

One difficult mechanism that is missing is a way for geographic search to specify the type of spatial operation. Typically most services assume a “within” or intersects”. For example, what restaurants are within a 5-mile radius of my position. However, it’s apparent that this can be confused based on assumptions and also does not provide for any other type of operations. Again, for example, find me all the hospitals that are not within the hurricane path.

A long-standing model for this is called the DE-9IM spatial operation set. It was presented by Eliseo Clementini, and also frequently attributed to Egenhofer. You can read more about it. Granted, a majority of geospatially-capable search interfaces may not require this, but it’s nice that there is a relatively straight-forward model that everyone can agree on.

I hope more attendees share their thoughts and outcomes. There are definitely many who point out the problems of designing standards in a smoke filled room, and I much rather bringing the discussion out into the open where more people can chime in and contribute.

During our trip to China in December Corrie and I definitely felt the effects of the poor air quality. This has also been the discussion for over a year leading up to the Beijing Olympics that start tomorrow. China has been trying a variety of mechanisms to cut down on pollution including removing all cars from the roads for 2 weeks and seeding rain clouds to pull the particulates out of the air.

The Olympics are finally here and the question still remains about the air quality and it’s effect on the athletes. One even wonders what the availability of this data is on the ground there. So to help out, I built a Mapufacture map that pulls the daily data reports from the Beijing Municipal Environmental Protection Bureau. You can also get the GeoRSS and KML.

As part of the new partnership we’re looking at the combination of geospatial data with dynamic information and brought in the Olympic venues as additional map layer.

Thanks to Corrie for the environmental analysis.

View the Beijing Air Quality during the Olympics map.

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 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.

In the talk announcing KML submission to OGC, the phrase “KML is HTML for the geospatial web” was used. I think this is a perfectly apt analogy. To complete the analogy, (taking you back to your SAT days)

HTML : RSS :: KML : GeoRSS

The purpose of the following examples is to illustrate the use of GeoRSS to syndicate KML content, similar to RSS support in HTML. GeoRSS merely adds a geographic component to the common RSS that syndicates web content. KML similarly offers a geospatial alternative representation of HTML content.

Syndication

Therefore, as appropriate, GeoRSS should be used based on existing usages of RSS. This means providing a rel=”alternate” link in both HTML and KML files. Conversely, an Atom or RSS feed requires use of a ‘link’ element to reference the originating content of the syndication. A rel=”alternate” can then be used in a GeoRSS feed to reference the KML version of that content.

Within a GeoRSS file, the entire feed, or channel, can link to the content in type=”text/html” and type=”application/vnd.google-earth.kml+xml”. Within a single entry, the GeoRSS feed can then link to the specific anchor, or element, within the original HTML or KML content using an anchor in the href.

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>KML GeoRSS Example</title>
  <link href="http://example.org/"/>
  <updated>2007-06-04T12:34:02Z</updated>
  <author>
    <name>Andrew Turner</name>
  </author>
  <id>urn:uuid:60a76c80-d399-11d9-b93C-0003939e0af6</id>
  <link rel="alternate" type="test/html"
    href="http://example.org/"/>
  <link rel="alternate" type="application/vnd.google-earth.kml+xml"
    href="http://example.org/kml_georss.kml"/>

  <entry>
    <title>This is my first article</title>
    <link href="http://example.org/2007/06/04/article"/>
    <id>urn:uuid:1225c695-cfb8-4ebb-aaaa-80da344efa6a</id>
    <updated>2003-12-13T18:30:02Z</updated>
    <summary>
      KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you're here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark" type="application/vnd.google-earth.kml+xml kml">favorite park</a>.
    </summary>
    <link rel="alternate" type="application/vnd.google-earth.kml+xml"
     href="http://example.org/kml_georss.kml#article1"/>
  </entry>
</feed>

Documentation

Within an HTML file, the <head> element can contain alternate links to the KML representation as well as the GeoRSS syndication. Similarly, KML 2.2 can contain an <atom:link> alternate representation back to the original HTML content and GeoRSS syndication of the geospatial information. By using these links, a resource can offer multiple formats as appropriate, syndication for alerting users of updates to the content, or visualization for a richer geospatial view.

For a specific KML Placemark, an <atom:link> can be used to link to the original HTML element using the anchor support in the href. Conversely, the HTML element, similar to a GeoRSS item, can use an <a> element to link to the specific KML Placemark representation. This similarly allows for the documentation element to reference the richer visualization of the feature. Clicking this link would either launch a KML viewer, or the original HTML renderer could render the KML element inline, within the browser.

<html>
<head>
  <title>KML GeoRSS Example</title>
  <link rel="alternate" type="application/rss+xml"
    href="http://example.org/kml_georss.rss" title="GeoRSS feed for My Page">
  <link rel="alternate" type="application/vnd.google-earth.kml+xml"
    href="http://example.org/kml_georss.kml"/>
</head>

<body id="kml_georss">
    <h1>Example of KML, GeoRSS, and HTML being used together</h1>

    <h2 id="article1">This is my first article</h2>
    <p>KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you're here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark"    type="application/vnd.google-earth.kml+xml">favorite park</a>.
    </p>

</body>
</html>

Notice that by using the type attribute in the <a> we can link to other KML elements, similar to an HTML document linking to elements in other HTML documents.

Visualization

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://earth.google.com/kml/2.2" xmlns:atom="http://www.w3.org/2005/Atom">
<Document>
  <name>kml_georss.kml</name>
  <atom:link type="text/html"
    href="http://example.com" title="My Page"></atom:link>
  <atom:link rel="alternate" type="application/rss+xml"
    href="http://example.com/kml_georss.rss" title="GeoRSS feed for My Page"></atom:link>
  <Placemark id="article1">
    <name>This is my first article</name>
    <atom:author>
      <atom:name>Andrew Turner</atom:name>
    </atom:author>
    <atom:link href="http://example.org/kml_georss.html#article1"></atom:link>
    <description>
      KML is the HTML of the geospatial web, used to visualize content, and GeoRSS is the syndication of that content. 

      While you're here, make sure to check out my <a href="http://example.org/myspots.kml#favoritepark" type="application/vnd.google-earth.kml+xml">favorite park</a>.
    </description>
    <Point>
      <coordinates>-122.370533,37.823842,0</coordinates>
    </Point>
  </Placemark>
</Document>
</kml>

Together, these suggestions allow for parallel use of KML and HTML for content, and GeoRSS for syndication (notification of updates) to that content. It keeps the GeoRSS as a pure markup of the new information, and keeps styling information in HTML and KML.

Here is a spiffy diagram to help illustrate linking the documents and articles together:

A last consideration about linking HTML content and KML content. Both formats are merely markups for storing and rendering information and not bound to a specific renderer (e.g. Firefox or GoogleEarth). However, it is still beneficial to link to a richer geospatial markup from an HTML file. <a> elements can optionally utilize the type attribute to specify the link follows to a KML file. It should explicitly noted that opening a link to a KML type should not necessarily open in GoogleEarth. Again, KML is just a richer geospatial markup of information.

For example, if a user is viewing a location from a GeoRSS file loaded in a 2D map representation, and link in the content points to a KML type, clicking this link should first open the location in the same 2D map representation. If the link is clicked in an HTML file, the appropriate MIME-type handler should be invoked. This is similar to a user clicking a link in an HTML document and opening the link in the HTML renderer.

Depending on the 2D map rendered, an optional "view in 3D" link could be offered to open the Placemark in GoogleEarth or other KML renderer.

OpenSearch

This proposal is just a suggestion, and doesn't require a change to any of the included formats. In fact, it is just a recommendation for a common usage of these formats to provide for better user experience and linking together your content. Additionally, my previous discussion on OpenSearch Geo fits perfectly with this as you can specify search mechanism for the same content-types. So if you just want the recent changes, request the RSS. Then you could use those results (page) to query specific KML rich placemarks for visualizing.

To use it you can just click on the map, or enter a location in the form field. Then click on the link for the format you want to see. Read more about it on Mickaël’s blog. One of the neatest improvements, and very useful for integrating into another application, is the webservice:

• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=georss
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=w3cgeo
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=machine
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=geo
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=geojson
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=gml
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=html
• http://geotruc.net/gt.php?q=Detroit,%20Michigan&format=kml

What is really great about geo:truc is that it provides a very simple and easy to use tool for users to get somewhat complex information. I believe his primary purpose was to provide scientists a mechanism for geocoding their specimen identification experiments. These are non-GIS users who want to store geographic information. Now, they can do it and include it on their websites/documents and share with the world.

But why geo:truc? Mickaël’s reasoning behind the name explains it very well:

“Truc” is a french word meaning an undefined thing, so I joked by calling it “geo:truc”.

Tags: geo, neogeography, geodata, formats, geotruc, mickaëlgraf, korbinus, standards, georss, w3c, kml, machinetags, html, gml, geojson, webservice

One of the main purposes behind moving to a more dynamic CMS was to involve the community in helping to document and forward the standard. Since there are now more people interested in GeoRSS, there have been lots of questions on format, examples, libraries, and so on that can now be easily added to the site.

In addition, there are typically very long discussions on email on adding new features to the standard. These usually get a really good discussion going, but then kind of fade out without any resolution. While it’s good for a standard to be ’stable’, it’s not good for it to be ’stagnant’ – or just overly frustrate people who are trying to extend it.

Therefore, we’re trying out a new process by which anyone can add a Proposal for extension to GeoRSS. The community can comment and finally vote on it (any member of the community can vote, this means you too!). Even if the proposal is not accepted, the proposal remains as a central point of documentation of the discussion, decision, reasons, and how users implemented the standard for their own uses (you still need to finish your projects).

Then, if and when the proposed addition is accepted, the page can serve as documentation on how to migrate from the proposed format to the finally accepted format.

Anyways, hop on over to the new GeoRSS Site, let me know if you see anything ‘funny’ (e.g. missing images, dead links, etc.) and get yourself an account (they’re free and come with a scoop of ice cream).

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,

To this end, I started up a GeoRSS Implementation Matrix. Please let me know what other libraries exist for consuming or publishing (I probably need to add that distinction to the matrix) GeoRSS and what formats it supports.

Hopefully we should soon be able to point developers at libraries they can use, or at least reference, for using GeoRSS and at a higher level we could point users and devs to existing modules (such as for blog and CMS engines) that they can use in their apps.

Tags: georss, format, standards,

For example, currently you can only embed a single point, line, or polygon in GeoRSS Simple:

45.256 -71.92

GML adds a bunch of features, but “location collection” still isn’t one of them.

What this means is, every item can have one, and only one, location. But what happens if you are, for example, writing about all of the hospitals in a city, or telling about your trip and a couple of hikes or cities you visited?

I would like to see something along the lines of this as a pseudo-example:

     
We had a great time in
Auckland and
Hokitika.
     
          -38.333332,176.00
          -42.709,170.97
     

GeoRSS doesnt’ currently support that type of functionality. The current solution is to put each of these locations in a separate item, but that isn’t really coincident with the idea that you’re writing a single ‘item’.

Another possible solution is to use Microformats within the post content to actually markup the locations or tracks, but that doesn’t really solve the problem since Microformat adr and geo have a hard time specifying the associated content, and it definitely doesn’t handle complex geometries like line or polygon.

GeoRSS is an open-standard, it is live and changing, and open for discussion. However, like any decent standard it is built on what users want and use. And working with GeoPress, I’ve been constantly, and pleasantly, surprised what some people are using geoblogs for that I wouldn’t have originally thought of.

SMS your vote in now

So my question to you is, do you see a need for this type of functionality? What do you currently do? Or am I just chasing an arbitrary idea?

Tags: georss, question, lazyweb, geo, formats, standards

iCommunity.tv is a fore-runner in providing video media primarily centered around geography in addition to focusing on citizen journalism , and not just videos of crazy stunts and movies served up by other media sites. Users can create custom channels and collections based on their interests and locations.

They offer a GeoRSS feed and a KML feed of the postings – which means it works very well in your Mapufacture Maps. See the feed map. Now you can add the feed to any of your Mapufacture maps to get update when a new video shows up in your community (or area of interest, for example where your family lives or you’re going to take a vacation)

Lastly, under the hood, iCommunity.tv is built on top of the Drupal CMS platform and is an excellent example of the power behind building a GeoCMS. In the future, Chris possibly plans to offer the ability for users to aggregate their video blogs through the service to allow for easier posting.

iCommunity.TV is a service of eParticipation.com

Geoblogging is just becoming more common, and the tools around it are figuring out what the user should be able to do. GeoPress provides a web interface for making maps and location for posts, but doesn’t yet support additional metadata for setting the location via the XML-RPC interface that a blogging client would use.

One tool that adds geoblogging capabilities to ecto is this very informative Wiki on Geo-blogging extensions on Mac that works for Blojsom based blogs. The site is a great resource on various tools and accessories for posting KML and GoogleEarth and GoogleMaps for geoblogging.

The tool works by bringing up GoogleEarth where you can spin, point, or reference an existing waypoint to choose the posting location. The plugin will then add the location metadata, a GoogleEarth KML Link, and also a screenshot of the location. Check out the Screencast for a demo of how to use the geoblogging toolkit and its functionality.

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,

Tags: georss, geopress, geo, metadata, feedback

Specifically, he outlines how to get photos at a location by a simple url:
http://www.flickr.com/map/Detroit

Flickr outputs proper Microformats geo for latitude & longitude.

And you can get a GeoRSS feed (more on this soon).

Tags: flickr, yahoo, maps, geo, georss, microformats, photography

PlaceBlogger is apparently just about to start. It’s an aggregation of localized blogs. Blogs with posts about specific locations, like the neighborhood or suburb rather than just a larger metro area – dubbed hyperlocal. You can see a mockup here. It’s like a Yahoo frontpage, but centered around neighborhoods or areas of interest. (via Susan Mernit

Another site is outside.in (read the announcement and some thoughts here) which is already released and has data. At first it wasn’t quite apparent how to start contributing to the site or marking up locations. They refer to the GMAP format, but I’m not sure what that really means.

All of these sites and tools are really exciting. This is the purpose behind tools I’ve been working on like GeoPress and Mapufacture. I hope these other local-news aggregators also use and support broader, open formats that we can all share and play along together.

Also check out LocoBlog, which is a mobile-phone blogging application and site as well.