Erik Wilde was pondering:

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.

Excited about the GeoWeb? Want to help build the next generation social mapping tools and work on some really awesome technology?

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.

Over the past two weeks I’ve been working with a great team of people helping to build VoteReport – an open public reporting system to be used during the 2008 US Election to track the situation as citizens cast their ballots. The simple goal is to make it easy for anyone to send in a report describing the wait time, overall rating and any complications that are impairing their ability to participate in the election. For more information check out http://twittervotereport.com.

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.

Last Monday I participated in a Geospatial Search Summit hosted by the OGC as part of the quarterly Technical Committee (TC) meetings. The TC’s are primarily about various working groups discussing progress and status of standards or interoperability demos.

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.