5 ms·
The geo API seems rather... specific. Is there really a demand for it?
by aeharding 10y ago
The geo API seems rather... specific. Is there really a demand for it?
- joeblau 10y agoBack 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.
- antirez 10y agoIf 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.
- PaulRobinson 10y agoGeo 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.
- antirez 10y agoHey 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.
- marktangotango 10y agoI personally don't have a use right now, but that sounds incredibly useful!
- Doctor_Fegg 10y agoYes please! So much interesting stuff that this would enable.
- endijs 10y ago+1 from me. This would be good addition!
- rch 10y agoThe ability to query with polygons defined by transit isochrones would be broadly useful.
- tyre 10y agoThis 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.
- har777 10y ago+1. Would be an extremely useful addition !
- simonw 10y agoThat sounds amazing. Do you have a link to the lua script? UPDATE: found it https://github.com/RedisLabs/geo.lua https://github.com/RedisLabs/geo.lua
- masklinn 10y ago> 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)
- chipsambos 10y agoI 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?
- NatW 10y agoThe Geo API allows it to work like a search engine. On my wish list would be adding a bounding box query to return results within a map displayed on the current screen: e.g.: https://www.algolia.com/doc/javascript#search__inside-bounding-box https://www.algolia.com/doc/javascript#search__inside-boundi... or e.g.: http://postgis.refractions.net/docs/ST_MakeEnvelope.html http://postgis.refractions.net/docs/ST_MakeEnvelope.html