Hacker News Reader

Comment by dbetteridge | Hacker News Reader

A fun tip, if you're using PostGIS you can actually generate the Geojson directly in the SQL query with http://www.postgis.org/docs/ST_AsGeoJSON.html

and if you're running a version of PostGIS with protobuffers enabled (Not AWS RDS) you can generate vector tiles on the fly with https://postgis.net/docs/ST_AsMVT.html which are great for displaying large datasets.

View on HN

RDS now supports libprotobuf-c, so AsMVT will work (at least on some postgres versions)

Well thats the best news i've had today. Thanks!

https://dba.stackexchange.com/questions/202049/support-for-l...

v10.5 of postgres by the looks of it, don't know how I missed that.

The vector file seems really useful. I ran a query that resulted in a 1.5 GB geojson file... much too big for Leaflet. Maybe the Vector tile would be compact enough? Thanks!

You could try to reduce the size with TopoJSON

https://github.com/topojson/topojson-simplify

https://medium.com/@mbostock/command-line-cartography-part-1...

Yeah I know that pain.

You'll need the MapboxVectorTiles plugin for leaflet but you can definitely improve the sizes by a fair bit.

When you're doing tiles, you need to simplify to highest resolution actually discernible in that tile. So, for each zoom level, generate bbox tile bounds, and then simplify or cluster everything in each tile for the pixel resolution you want. That way you will never have 1.5GB tile. After all, all that data is wasted space if it can't be seen.

I've done this for GeoJSON tiles for a long time, before the MVT tiles. The MVT tiles pack way more data though, but are not a solution to the O(n2) problem.

Reduce the precision, 15 decimal places are useful for picometers, not a web map. Try 5-6.

It never seems worth the effort in my testing, as you have to come up with your own loop to do the truncating, and the benefit is marginal. In this case he’d have 1.2gb file, I doubt that fixes the problem.

for what it's worth, ST_AsGeoJSON lets you specify decimal precision as an optional argument, so you at least don't have to write a truncating loop.

Another good option with many polygon geometries is Base64 encoding the output of ST_AsGeobuf -- it is many times smaller than GeoJSON and still pretty easy to handle from Javascript. (Needs libprotobuf-c on the PostGIS side and geobuf.js+pbf.js on the JS side)

Thats cool, I should try AsGeobuf as a soft upgrade to one of the older tile GeoJSON site :)

Does GCP Cloud SQL have protobuffers enabled?

Reply on news.ycombinator.com