couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Metson <>
Subject Re: Would CouchDB and Views suitable for Raw sensor data?
Date Tue, 13 Jul 2010 09:30:44 GMT
Upps! sorry, first one I hit from Google...

On 13 Jul 2010, at 10:27, Volker Mische wrote:

> Hi,
> just a quick note, the link to GeoCouch is quite outdated. GeoCouch  
> is now written in Erlang (for tighter integration with CouchDB).  
> More about it:
> Cheers,
>  Volker
> On 07/13/2010 10:08 AM, Simon Metson wrote:
>> Hi,
>> We're starting a project which aims to do similar things (store some
>> dimensions of a slope for a GPS location, possibly a photo too).  
>> We're
>> looking at geocouch for location indexing
>> (,CouchDB,Python,geo

>> ).
>> If you can write something that will index your sensor data I'd say  
>> this
>> was a good fit, you might need to use a custom (i.e. not javascript)
>> view server, depending on what that data is.
>> Cheers
>> Simon
>> On 13 Jul 2010, at 08:14, Charlie Chilton wrote:
>>> Hi,
>>> Recently I saw Aaron Miller has an Alpha of CouchDB running on
>>> Android, which has me very excited about the convergence of these  
>>> two
>>> technologies.
>>> One project where CouchDB on Android could help us would be for the
>>> logging of Bluetooth sensor data (such as GPS, and other external
>>> sensors, such as Weather).
>>> CouchDB is appealing here because of its replication technology;
>>> sharing the sensors DB's to other Android Devices in the area and  
>>> back
>>> to base over the mobile network would be great!
>>> After reading much about CouchDB, I was wondering if anyone could
>>> 'sanity check' the idea of putting raw sensor data into the  
>>> Database,
>>> and then writing views to extract meaningful information from it.
>>> Some of the sensor data would be binary, while other stuff such as  
>>> GPS
>>> would be text based NMEA strings. Regardless of the sensor data  
>>> output
>>> type, each raw insertion into the database would be a complete
>>> 'sentence' of input, so the views would have something
>>> reliable/predictable to work on.
>>> The other option is to decode the sensor data prior to insertion,  
>>> but
>>> this doesn't feel as fun!
>>> Any comments appreciated,
>>> Charlie

View raw message