From user-return-4134-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Sun Mar 22 23:08:24 2009 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 28340 invoked from network); 22 Mar 2009 23:08:23 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 22 Mar 2009 23:08:23 -0000 Received: (qmail 28761 invoked by uid 500); 22 Mar 2009 23:08:22 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 28666 invoked by uid 500); 22 Mar 2009 23:08:22 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 28656 invoked by uid 99); 22 Mar 2009 23:08:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Mar 2009 23:08:22 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of volker.mische@gmail.com designates 209.85.220.163 as permitted sender) Received: from [209.85.220.163] (HELO mail-fx0-f163.google.com) (209.85.220.163) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 22 Mar 2009 23:08:13 +0000 Received: by fxm7 with SMTP id 7so1843709fxm.11 for ; Sun, 22 Mar 2009 16:07:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=SrE4cCo0WHx2DMAt99kQVEABAQN7atedyLIk88pJdaU=; b=jf/LBxcMV+BLalSD+xL7ymSB7BvKC0hT29NHY6i7AlnSvviFy618cb2tAWi21kH8vk i3yDJV9Njas6i4qPypOHSoSA98bdC57SAN+Ul0PjgGtQMVicq6drvzqVlbrj72vB7G3H jI7l3rLltQoZUvBXmuZfE/ybxfMzRrUtnx27A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=jX8t9pZfFnWemMqKS6AJKSLswHWMed2PvPtaw+A/8MR9CrtDHy4sbosxRc0FCVqpdZ 5Ua0UkxOug2XL3T8yNM3ORQzWhAuq9xNT6+OGsXQ+IBugxFvV22k+Z0Mq/joGlKb3LBp xSY8YkAmtWG6gSpS04WJX/duP5FY9vqWZJn+M= Received: by 10.86.95.20 with SMTP id s20mr3156497fgb.40.1237763272211; Sun, 22 Mar 2009 16:07:52 -0700 (PDT) Received: from ?192.168.0.136? (dslb-088-064-094-136.pools.arcor-ip.net [88.64.94.136]) by mx.google.com with ESMTPS id e20sm2418961fga.24.2009.03.22.16.07.50 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 22 Mar 2009 16:07:51 -0700 (PDT) Message-ID: <49C6C4C2.6080202@gmail.com> Date: Mon, 23 Mar 2009 00:07:46 +0100 From: Volker Mische User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: user@couchdb.apache.org Subject: Re: using couchdb for 100GB geodata from openstreetmap References: <186b32bc0903221439k7bdc1c15vf1a960aa2047d4c1@mail.gmail.com> <49C6BC80.4090504@gmail.com> <186b32bc0903221545k7f41a2ccl62b55902cf740557@mail.gmail.com> <49C6C1B8.9090605@gmail.com> <1C3347CF-EBFE-47A1-A2CE-EA5681AD343E@apache.org> In-Reply-To: <1C3347CF-EBFE-47A1-A2CE-EA5681AD343E@apache.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Is there a difference between a custom view engine and the approach I try to pursue with GeoCouch? It still comes down to the fact that you need to store the spatial information in some kind of (external) spatial index. Cheers, Volker Damien Katz wrote: > Random idea: a custom view engine for geospatial data > > Store the documents like normal and have the custom engine index them > for geospatial queries. Then you query the view engine (GET > /db/_geo?yada=... ) > > -Damien > > On Mar 22, 2009, at 6:54 PM, Volker Mische wrote: > >> pablo platt wrote: >>> On Mon, Mar 23, 2009 at 12:32 AM, Volker Mische >>> wrote: >>> >>>> Hi, >>>> >>>> I'll only reply to the GeoCouch bit: >>>> >>>>> I've read about geocouch - >>>>> >>>> http://vmx.cx/cgi-bin/blog/index.cgi/geocouch-geospatial-queries-with-couchdb:2008-10-26:en,CouchDB,Python,geo >>>> >>>>> and my question is if a geo aware couchdb can be built without any >>>>> python >>>>> and SpatiaLite code? >>>>> >>>>> If I want to be able to make proximity searches - find banks in 3km >>>>> range >>>>> from st some-street >>>>> do I need to create some kind of index docs for the views? >>>> The problem is that proximity searches are kind of dynamic. CouchDB >>>> views are like precomputed result-sets, but you can't precompute all >>>> possible values, as the center of the search could possibly be >>>> anywhere. >>>> Therefore you need something that makes such dynamic requests possible. >>>> >>>> Pure CouchDB could be used if you constrain your searches. You would >>>> need to restrict to things like, a certain number for the center of >>>> searches, only a fixed number of radii, and a fixed number of location >>>> types (like banks, restaurants etc). >>>> >>>> Cheers, >>>> Volker >>>> >>> >>> I've asked on the #couchdb channel and got the same answer. >>> >>> The 'Name Finder' on OSM >>> http://wiki.openstreetmap.org/index.php/Name_finder >>> divides the map to region and add a field to each element(place) >>> indicating >>> what region it belongs. >>> When you make a search "banks near someRoad" it find in which region >>> someRoad is and find all the banks in that road. >>> So you are limited to predefined distances but the above design will >>> work in >>> couchdb as well. >>> There is an assumption that they used this design because they used >>> MySQL >>> but I can't verify that. >>> >>> My question is if arbitrary distances are not a requirement of my >>> app, is it >>> better to use couchdb for storing the geodata >>> or is it better to use a spatial db like postGIS in any case. >>> >>> Thanks >> >> As much as I love CouchDB, your application sounds like a typical case >> for PostGIS. The tools to import OSM data into PostGIS are there, and >> you have a spatial index. Though you would obviously lose all the other >> nice CouchDB features (like replication etc). >> >> Cheers, >> Volker >> >> >> >