Official Gargoyle Roadmap, calluh callay!
Currently, Gargoyle consists of 3 parts:
At the moment, only GPS is truly usable, and even that is to a very limited degree. A proof of concept for GPA was posted, and most of a v0.2 was written, but that codebase will be abandoned. GEAS is for now just a whole bunch of ideas without a single line of code.
What follows is a breakdown of what each component of Gargoyle is, what features are implemented, and what features are planned.
Gargoyle POI Server (GPS)
Priority features are marked with an asterisk. (A POI
is a Point of Interest
Gargoyle Extraction Agent Service (GEAS)
- Store and retrieve POIs via a REST interface
- GET access - 100% implemented
- POST access* - 20% implemented
- View POIs in multiple formats
- KML output - 100% implemented
- GeoRSS output* - 20% implemented
- JSON output - 20% implemented
- GPX output - 20% implemented
- Submit POIs in multiple formats
- KML input - 0% implemented
- GeoRSS input - 0% implemented
- JSON input - 0% implemented
- GPX input - 0% implemented
None of this is implemented.
Gargoyle Personal Agent (GPA)
- An interface for publishing data to GPS
- A JSON-based Domain Specific Language for defining questions about geospatial information.
- An Extractor template that answers the questions posed using the aforementioned DSL with a list of POIs, which get published to GPS. Here are some examples of questions that can quite easily be answered:
- What places are mentioned in Boing Boing posts?
- Where are the 4+ star rated Afghan restaurants on Yelp?
- Where are people I'm following on Twitter posting from?
- Where are the meetings in my Google Calendar located?
- Where are the other people that have their GPAs publish their location information?
- Where are people posting flickr photos from?
- Where are nearby Wikipedia pages?
In all these cases further relevant information can be attached to the POI in a description field, or perhaps any number of customs ones, since the CouchDB backend is very flexible.
This isn't actually a single application. Rather it is a suite of applications for multiple platforms, each with modular UIs.
- Query a positioning device (such as a GPS unit) and retrieve relevant POI lists. This is the main task.
- Maintain a cache of the nearby POI lists, and precache ones slightly further away intelligently.
- Maintain a list of user priorities (which can be interactively modified) that affects POI presentation.
Now here are the various alternative user interfaces:
- A Google Maps mashup that displays the nearby POIs. This can be run on the web, and thus be iPhone compatible.
- Display the POIs on whatever mapping tool a given device may have. On Google's Android Gargoyle will use Google Maps.
- Pronounce POI via Text-to-Speech if a bluetooth headset is available. This existed in the proof of concept which ran on the Nokia n800. Should be possible on various cellphones, perhaps Google Android.
- List nearby POIs linearly via some graphical interface.
In all cases, the client must intelligently be picking which POIs to bring up. For example, Wikipedia pages should not be announced until right next to the user, otherwise in some areas (e.g. NYC) the user would be utterly swamped with information. Whereas things like 5-star rated restaurants should be displayed even at some distance, especially when the user has indicated they are hungry.
- Implement GeoRSS support in GPS
- Create rudimentary exporter from GeoNames wikipedia data into GPS.
- Create Google Maps mashup which displays this data by reading it from GPS.
None of this is new, in that a Google Maps view of this data already exists. However, this will lay the groundwork for extending the system and creating open interfaces that allow rapid development of plugins and improvements.