As I posted on the GeoRSS Blog, we just recently relaunched the site using a CMS. Specifically, we’re using Drupal because of its excellent support of geospatial standards (and being the one who did the migration, it was very easy to setup – there are definitely other great GeoCMSs out there).

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

I was gone for 5 days to the Ontario Curling Association’s Colts Provincial Playdowns, the top-tier competition after playing down against 130 other curling teams. We held our own, but the competition was very stiff.

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.

The GeoRSS community has had a rapid-fire discussion on formats, standards, future and current status of some of the features in GeoRSS. One of the major points that has come out is the importance of reference implementations, or common libraries other developers can drop into their projects to add GeoRSS support in all its multitude of flavors.

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.

There is a discussion that crops up every once in awhile on the GeoRSS mailing list whether it is useful or appropriate to support ‘multiple locations’ in a single RSS item.

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?

Chris Haller has recently released a very cool new localized news video site, iCommunity.tv. The site allows users to upload and geotag videos of their own news media around the world.

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