DEV Community

Discussion on: Geo Crash Course

Collapse
jordonr profile image
Jordon Replogle • Edited

Thanks for the great slide deck. I've been thinking of doing a personal project that would rely on spatial data. On your slide 77, you mentioned relational databases and I was wondering if you had any experience/opinions on using NoSQL databases like MongoDB or ArangoDB?

Personally siding with PostGIS at the moment, but I haven't been able to decide.

Collapse
desgrangeremi profile image
Rémi Desgrange

I'll talk about my experience but I think it's biased. I think that for most geospatial stuff postgis is the tool. You benefits from all the awesome postgresql ecosystem + geospatial. Since postgresql is a "industry standard" (this is not my word but Paul Ramsey' ) you also have a lot of ressource on the web and a lot answer on stack overflow.

With Mongodb you'll be on you're own and you'll need to implement everything on the app, in this case, turf.js can help).

With Postgis, you have everything you need (did I say I was biased ? :-)) for exemple with this query you can select data directly in geojson:

SELECT st_asgeojson(the_geom) FROM my_geom_table;
Collapse
turnerj profile image
James Turner

While I don't know if it is remotely the same level of functionality as Postgis, MongoDB does have built-in geospatial support.

Collapse
ice_lenor profile image
Elena Author

Thank you for your question, Jordon!

Unfortunately, I haven't used mongodb or any other nosql databases for geo stuff, except for Elasticsearch (Lucene), which I mention on the next slide.

Personally, I would opt for a relational database, like PostGIS or MsSQL, because I know they're working well with geodata. Geo is a rather niche topic, and it definitely will be lower priority for database developers, plus it can be difficult to implement properly. This is why many databases don't have geo support. By using a database with not very well developed geo support, I feel like I would put my product at risk. So I'd have to weigh it very carefully.