looking for best approach to handle geo data

[Jim Woodgate <jd...@gmail.com>]

We have some data stored in WKT format and I was looking for a good
way to index the property for a view.  I saw a few existing
implementations, but they used an existing format and had things like
another database dependency that I didn't want.  In general I want to
use a geometry library to check for an intersection between two
geometry objects and hopefully also be able to group together entities
that are relatively close to each other to make the searches faster.

I was wondering what the best approach to take would be.  There is a
javascript project called OpenLayers that is able to handle the
format, I could possibly pull pieces out of that, but it wasn't
entirely obvious to me if I could load an external library for my
design doc.  Would that be possible if I attached the javascript as an
attachment to the design doc?  I also looked at writing an external
wrapper using geos, but looking at the external documentation, it
looked like it was more for handling an entire query by itself, where
I'm really just trying to plug into the view mechanism.  Has anyone
done something similar, use some kind of an external library (either
javascript or external) to help couchdb do something with the view
keys?

Thanks!

-- 
Jim Woodgate
jdwoody@gmail.com

Re: looking for best approach to handle geo data

[Nathan Stott <nr...@gmail.com>]

You can add the library code to your code in the view.  There are utilities,
like CouchApp, that will help with this.

On Fri, Nov 13, 2009 at 9:47 AM, Jim Woodgate <jd...@gmail.com> wrote:

> We have some data stored in WKT format and I was looking for a good
> way to index the property for a view.  I saw a few existing
> implementations, but they used an existing format and had things like
> another database dependency that I didn't want.  In general I want to
> use a geometry library to check for an intersection between two
> geometry objects and hopefully also be able to group together entities
> that are relatively close to each other to make the searches faster.
>
> I was wondering what the best approach to take would be.  There is a
> javascript project called OpenLayers that is able to handle the
> format, I could possibly pull pieces out of that, but it wasn't
> entirely obvious to me if I could load an external library for my
> design doc.  Would that be possible if I attached the javascript as an
> attachment to the design doc?  I also looked at writing an external
> wrapper using geos, but looking at the external documentation, it
> looked like it was more for handling an entire query by itself, where
> I'm really just trying to plug into the view mechanism.  Has anyone
> done something similar, use some kind of an external library (either
> javascript or external) to help couchdb do something with the view
> keys?
>
> Thanks!
>
> --
> Jim Woodgate
> jdwoody@gmail.com
>

Re: looking for best approach to handle geo data

[Volker Mische <vo...@gmail.com>]

Jim Woodgate wrote:
> On Fri, Nov 13, 2009 at 10:07 AM, Volker Mische <vo...@gmail.com> wrote:
>> Hi Jim,
>>
>> are the two objects you want to check the intersection of within one
>> document, or is every geometry in its own document?
>>
> 
> Each document has it's own geometry (which might be a single point or
> a closed polygon) and the search would be a geometry (more than likely
> a polygon) and I would only return documents where the geometries
> intersected.  I was also hoping to use a bounding box to order the
> documents.
> 

I don't see a way without using an _external handler for it. Actually
what you describe is a use-case why I created GeoCouch. I'd love to have
a way doing such things directly in CocuhDB, but it's a loooong way to
go to make it happen. Therefore I use an spatial database for these kind
of operations (SpatiaLite is basically only a R-Tree connected with GEOS
for stuff like intersections and PROJ4 for reprojection).

If you find another solution, or want to help getting this functionality
into CouchDB, please let me know.

Cheers,
  Volker

Re: looking for best approach to handle geo data

[Jim Woodgate <jd...@gmail.com>]

On Fri, Nov 13, 2009 at 10:07 AM, Volker Mische <vo...@gmail.com> wrote:
> Hi Jim,
>
> are the two objects you want to check the intersection of within one
> document, or is every geometry in its own document?
>

Each document has it's own geometry (which might be a single point or
a closed polygon) and the search would be a geometry (more than likely
a polygon) and I would only return documents where the geometries
intersected.  I was also hoping to use a bounding box to order the
documents.

-- 
Jim Woodgate
jdwoody@gmail.com

Re: looking for best approach to handle geo data

[Volker Mische <vo...@gmail.com>]

Hi Jim,

are the two objects you want to check the intersection of within one
document, or is every geometry in its own document?

Cheers,
  Volker

Jim Woodgate wrote:
> We have some data stored in WKT format and I was looking for a good
> way to index the property for a view.  I saw a few existing
> implementations, but they used an existing format and had things like
> another database dependency that I didn't want.  In general I want to
> use a geometry library to check for an intersection between two
> geometry objects and hopefully also be able to group together entities
> that are relatively close to each other to make the searches faster.
> 
> I was wondering what the best approach to take would be.  There is a
> javascript project called OpenLayers that is able to handle the
> format, I could possibly pull pieces out of that, but it wasn't
> entirely obvious to me if I could load an external library for my
> design doc.  Would that be possible if I attached the javascript as an
> attachment to the design doc?  I also looked at writing an external
> wrapper using geos, but looking at the external documentation, it
> looked like it was more for handling an entire query by itself, where
> I'm really just trying to plug into the view mechanism.  Has anyone
> done something similar, use some kind of an external library (either
> javascript or external) to help couchdb do something with the view
> keys?
> 
> Thanks!
>