To anyone coming here wondering WTF is Tile38? First I'll tell you what it's not. It's not a replacement for PostGIS, and it's not built on top of Redis.
In my opinion PostGIS is the Swiss Army Knife of spatial data management. It's awesome! Especially for large datasets and complex queries. I use it all the time.
Tile38 uses the Redis protocol for network transport. There're some commands that loosely resemble Redis like SET and GET, but it's otherwise a completely different project. I originally forked Redis and built the functionality on top of the C codebase. https://github.com/tidwall/redis-gis, but scrapped that project.
What Tile38 is good for is very dynamic datasets where the application needs fast and simple point-in-polygon queries and streaming geofence notifications. Like vehicle pickup services, bus route services, proximity social apps, etc.
Inevitably this will be compared to PostGIS so maybe you could put a paragraph in the README on how it compares to it what is the usecase where Tile38 would serve you better. I must admit I don't see one for my own needs.
I had been following tidwall/tile38 for a while already, too without a clear use case for actually using it. When we refactored a main part of our code base the use case finally arose;-)
At this point we're about to release tile38 to our staging environment. We opted for it basically for its capability to cache and spatially query geojson directly. Plus this can be done without the serialisation/deserialisation overhead. Another advantage for us is the ability to use the python-redis bindings. This let's us execute commands like this to retrieve data for a tile x,y,z request:
res = client.execute_command(
"INTERSECTS", our_key, "WHERE", "minzval", 1, z,
"LIMIT", LIMIT, "TILE", x, y, z
)
Using its geofencing, which is awesome! Not ready for prod yet, and I'll open-source the code;
I started building a generic geofence gRPC framework on top of tile38. You get a gRPC service that abstracts away the Redis API from you, and is generic enough to run multiple applications from the same tile38 server. It works by namespacing keys into their own collection. The namespacing is done through authentication with the header metadata, so it becomes transparent to the gRPC client.
I'm
* sending a notification every time the bus is x km/miles from someone (static geofences),
* triggering certain actions when user's at a train station (in conjunction with Google/Android geofencing)
I have been trying to use roaming geofences, but don't really have much use for them at the moment.
at https://www.weenect.com we're currently experimenting with it in order to replace our mongodb, I think I will go with this and a mix of postgresql for historical data.
the realtime geofencing capabilities will be a very good plus for us, as that's one of the main feature of our products, i.e being able to know when your cats or dog is going too far.
It's nice but it's kind of limited to simple apps. No polygon or geocorridor points of interest and you'd need a database anyway to store historic data. For anything more complex tgan point on map apps, I'd use PostgreSQL + PostGIS.
Web-based notification is pretty much trivial after that since you need a database client written in a language of your choice that forwards the notification via HTTP to some endpoint. It's not as trivial as the tile38 but it can be more powerful since you can add any type of geometry to your POI. For instance you want to be notified when a vehicle crosses state borders.
I've been using a similar geometry library 'S2'[1], by Google. It's mainly used for fast spatial indexing and comparison functionality, albeit more 'approximate'[2] than Tile38 seems to be.
I believe indexing with S2 can be made absolute if a polygon's boundary coverage cells contain a slice of the original shape. It's a bit more expensive on memory and insert times. But very fast and accurate queries. I've been experimenting with this method.
S2 can also output interior coverings, which will return only the cells in a covering that are fully contained in a polygon. So if you encounter a point (or any cell) whose parent is in an interior covering, you don't have to do any additional checks to produce an exact result (whereas on the boundary, you may want to do a point-in-polygon test to be exact).
Some people may not read the link because it appears grayed out in some browsers (the link has been posted before and so it appears in the browser history as visited). Maybe it's better to link to the changelog page, since this was reposted because a new version has been released [1].
In my opinion PostGIS is the Swiss Army Knife of spatial data management. It's awesome! Especially for large datasets and complex queries. I use it all the time.
Tile38 uses the Redis protocol for network transport. There're some commands that loosely resemble Redis like SET and GET, but it's otherwise a completely different project. I originally forked Redis and built the functionality on top of the C codebase. https://github.com/tidwall/redis-gis, but scrapped that project.
What Tile38 is good for is very dynamic datasets where the application needs fast and simple point-in-polygon queries and streaming geofence notifications. Like vehicle pickup services, bus route services, proximity social apps, etc.