There are a lot of database/search products that allow you to do geospatial queries. Stuff like this is nice if you are implementing your own version of that but using it as part of a regular web server or batch toolset is probably a bad idea unless your data set is small.
Some examples:
- redis has support for geospatial. Good for radius searches.
- elasticsearch/opensearch have pretty elaborate options for disance search, ranking, aggregating, etc. It can also deal with geojson geometry and do polygon intersection/containment queries, etc.
- mongodb has similar features for geojson but is probably a bit more limited for querying/ranking/aggregating.
- postgis is a bit of a beast but a goto solution for doing complex geospatial work.
There are many more options of course. Just making the point that this isn't a wheel that is in a lot of need of reinventing.
Your critique is valid, but whatever happened to letting developers build cool technical projects for their own sake?
The author does not claim this should be used in production. As far as I can tell, this appears to be more of a novelty technical demo more than anything. Saying that the author is trying to reinvent the wheel of production-grade databases is uncharitable at best.
ClickHouse has Geo data types and functions (such as import and export from WKT, GeoJSON) and special features to accelerate geospatial queries.
For example, polygonal dictionaries allow doing coordinate-to-region lookups using the indexed data structure. It is used for mobile app analytics and ride-sharing apps.
Reverse geocoding is a task requiring quite sophisticated algorithms to implement it optimally. It's worth a dedicated blog post... You can check the source code: https://github.com/ClickHouse/ClickHouse/. See src/Dictionaries/Polygon Dictionary Implementations.h
I actually think there’s a fairly large gap for new and innovative geospatial tools/solutions in the open-source space.
It’s true that alot of databases that have “Support for Geospatial” - but that can mean a a lot of things, often with little overlap in functionality, or very specific, inflexible access patterns that breakdown with even small variations in the problem.
I don’t think it’s too uncommon to find that none of the available solutions work for particular real world problems, and often it comes down to handcrafted solutions like this.
elasticsearch also has native support for vector tiles output, perfect for rendering maps in web/mobile apps. In general, any geo-app, it's not just about doing the searches/computations quickly, half the battle is efficiently delivering the data to the client.
Some examples:
- redis has support for geospatial. Good for radius searches.
- elasticsearch/opensearch have pretty elaborate options for disance search, ranking, aggregating, etc. It can also deal with geojson geometry and do polygon intersection/containment queries, etc.
- mongodb has similar features for geojson but is probably a bit more limited for querying/ranking/aggregating.
- postgis is a bit of a beast but a goto solution for doing complex geospatial work.
There are many more options of course. Just making the point that this isn't a wheel that is in a lot of need of reinventing.