Thanks for the response. I see what I was actually looking for was on http://tile38.com/topics/object-types/ Right there on the front page, and not in the docs tab where I was looking.

For the GeoJSON, does it support properties? Meaning can I store a a whole document in there? Or would it be best to just store an ID and lookup the ID in a DB or something?

> For the GeoJSON, does it support properties?

Yes, Tile38 has full GeoJSON support including properties for Feature objects. Though there is one exception, the CRS key is ignored because WGS84 is assumed.

> Meaning can I store a a whole document in there?

Yes, as long as the document conforms to http://geojson.org/geojson-spec.html. Though JSON keys that are not defined in the spec will be stripped out of the document prior to storing in memory. For example, a "properties" key of a type that is not a "Feature" will be stripped, and requesting that object at later time will result in a JSON document that does not include the "properties".

The RFC also limits GeoJSON to WGS84 by the way. https://tools.ietf.org/html/rfc7946

Thanks for sharing. The draft RFC at the beginning of the year included the CRS key so it must've be a recent decision.

> Tile38 uses the Redis protocol

Under the hood, is Tile38 a distribution of Redis with a Tile38 Redis module?

If so, could the Tile38 module be used in "regular" Redis alongside other Redis modules?

It's custom. I explored a Redis fork months ago, prior to the ability for modules. https://github.com/tidwall/redis-gis

I then tried to make a module but redis modules do not support hooking into the pubsub tooling, so Tile38 live geofencing and webhooks were not possible.

Lol looks like this database needs its own database. Yeah seems like it should be a plugin or library not sure why it's standalone if it's just backed by redis.

It's not backed by Redis. It's fully standalone. I wish I could have made a redis module back when I started the project, but I'm plenty happy how Tile38 has matured.

Eh, fair enough then. If you don't have to setup redis yourself it doesn't really matter

> but I would conservatively use 128-bytes per point as a general rule.

why not store close items together in a small block and use offsets + delta encoding ?

Thanks for the suggestion, I'll need to investigate further. Right now, under the hood Tile38 uses an 3d rtree. Each node clusters 8-16 objects together. I'm always looking for a better way.