Geo is insanely useful when you're after stuff within x miles of a known location - so a lot of mobile apps.
My problem with many existing geo implementations is they assume that a circular radius is the query type I care about, and longitude and latitude is sufficient to know where I actually am in terms of jurisdiction, etc.
Being able to add fine grained polygons to represent national, state, county or town boundaries and being able to identify the relationships between my co-ordinates and those entities is still far more complex than I would like.
Adding polygon support might be an interesting exercise, actually.
Hey Paul, we have this feature added as a Lua script, but adding it in a native way could be interesting actually. Itamar Haber wrote the Lua script and was pushing for adding it in a native way, I wanted to check after the release the actual demand for it.
This would be extremely helpful. We work with local governments and they have a cornucopia of geo-boundaries to query across. PostGIS works really well, but providing a cache-layer on top via Redis for simple counts would be amazing.
I work on a SaaS spatial product and had to come up with a solution to the same point/boundary problem. It needed to be 'fast' (ideally <3s) when filtering, rendering, styling and summarising 100k points within 43k polygons (so say 100k shop locations within many state, county and zip/zcta codes in US). DB is Oracle 11g for several reasons: product is larger and older than this requirement, small team has solely expertise with oracle and zero commercial experience with nosql dbs (good devs though and have showed interest in and toyed with nosql dbs) plus standard budget/time constraints.
Solution was to add a hidden column for each administrative category (e.g. for US: region, state, county, zcta) to each point record to replace spatial searches with filtering.
Would something like that work for you? What kind of numbers of points and polygons are you looking at and how quickly do you need to solve the problem?
> My problem with many existing geo implementations is they assume that a circular radius is the query type I care about
Really? Wouldn't most GIS implement something like OGC Simple Features? AFAIK all SQL GIS implementations follow that (to various levels of completeness, but even MySQL has shapes support since 5.6)
If you think to geo-aware mobile applications, many are of the kind "show me XYZ near me". So that's the main use case basically. According to the fact a lot of people switched to 3.2 while it was yet not stable in order to use this feature I believe there is a big demand.
Back 5 years ago, this would have helped us at our company. We were doing realtime data analytics and we had to dump our data to Postgres to run any geo queries.
My problem with many existing geo implementations is they assume that a circular radius is the query type I care about, and longitude and latitude is sufficient to know where I actually am in terms of jurisdiction, etc.
Being able to add fine grained polygons to represent national, state, county or town boundaries and being able to identify the relationships between my co-ordinates and those entities is still far more complex than I would like.
Adding polygon support might be an interesting exercise, actually.