Hey, Great to see this conversation happening, hope to be able to contribute. My two bits inline -
On Sun, Mar 2, 2014 at 3:15 PM, Gora Mohanty <[email protected]> wrote: > On 2 March 2014 14:51, Sajjad Anwar <[email protected]> wrote: > [...] >> Hey, you don't necessarily need geodjango for these. You can write simple >> spatial queries in PostGIS. >> And they aren't very expensive. For example - >> http://postgis.refractions.net/documentation/manual-2.0/ST_Within.html > > GeoDjango queries translate to postgis if one is using a postgresql > back-end, so I do not think that there is much overhead there. GeoDjango > also does a lot more, including providing an abstraction layer for GIS, so > that I would prefer using it to coding directly in postgis. The alternatives > that I was thinking of were along the lines of spatial search with > Solr/Lucene. > These should be faster in principle, but we have not yet benchmarked > them against postgis/GeoDjango. > I wouldn't worry about performance before it's a concern - I think PostGIS is fairly performant. If one does land up hosting a lot of data, I'd highly recommend ElasticSearch for its geo support and scalability, but there's probably a few options. I'd also highly recommend django-haystack [0] - in most cases, this should let one fairly easily build out your django project, and add a performant search indexer when one needs it. I'll be glad to help. Any-how, my two bits would be "don't premature optimize" - I think building something out using GeoDjango should be fairly clean and straightforward, and I think django-haystack provides a clean migration path forward if one does need to scale / use a specialized indexing tool like Lucene. Also, for Django APIs, I've been looking at django-rest-framework [1] recently, and am quite liking it. It seemed a bit of overhead as compared to just writing vanilla view functions for end-points, but gives a really nice, auto-documented API frame-work with a nice in-browser testing page, multiple formats, etc. I had to do some tweaking to get it to output GeoJSON - any-how, if you are going down this path and want a hand / second set of eyes, let me know. > I would again argue that the first thing to do would be to have a stable > system > that provides an API layer over raw data pulled from various sources. GIS, > and such queries would be meta-queries over such raw data, and should be > done later, IMHO. > About other sort of aggregation / meta-queries, I agree, but I think basic GIS data can be quite fundamental to this sort of data. Its nice to be able to query location data, and for data-sets that have location data, I think would be nice to support? Thankfully, adding basic geo support using GeoDjango is fairly straightfoward - I agree that performance maybe an issue, but I think if the site is getting that many users / has that much data, one could work out more complex solutions then? Anyways, let the bike-shedding not get to you, Thej :) - do whatever's easiest / makes sense - do let me know if I can help / contribute / when there's code up, etc. All the best! -Sanjay [0] http://haystacksearch.org/ [1] http://www.django-rest-framework.org/ -- For more details about this list http://datameet.org/discussions/ --- You received this message because you are subscribed to the Google Groups "datameet" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
