top | item 41013542

(no title)

Bencarneiro | 1 year ago

OK holy jeez I think I got the server back up. We now have 8X the ram and I'm not sure how, but we broke postgres....

discuss

order

et-al|1 year ago

Not to sure how your backend is set up, but it looks like you're generating GeoJSON on the fly and the JSON serialization for this amount of data can be slow.

In typical HN fashion, I would suggest looking into using Tippecanoe to generate some vector tiles of the data and host that on S3. Then the DB can fall back to performing simple lookups via the accident ID. Filtering by time will need to move to the frontend, but that should be fine (if not, look into clustering the data at further zoom levels).

https://github.com/mapbox/tippecanoe

Bencarneiro|1 year ago

This is very helpful

carderne|1 year ago

You’ve had some other recommendations already but I’d suggest also looking into FlatGeobuf [0] for this use case. Have a look at the MapLibre example with a 12GB example [1]. You don’t need a server at all (unlike MBTiles) and will be able to load far more points at once than your current solution. Can easily generate it with QGIS/GDAL/PostGIS. Not sure what your plans are for the project but would be happy to donate some time to get something like that working.

[0] https://github.com/flatgeobuf/flatgeobuf

[1] https://flatgeobuf.org/examples/maplibre/large.html

munch117|1 year ago

I was trying out different time periods (comparing 2003-2013 to 2013-2023, to see a rough trend), and I noticed that every click to change the year by one seemed to generate a refresh. Perhaps it would help to lower the load if you change the date selector widget to only refresh after the date selector is closed.

ppbjj|1 year ago

godspeed, soldier

winrid|1 year ago

Remember to increase the buffer pool size to use that ram!

NwtnsMthd|1 year ago

> I mapped almost every USA traffic death in the 21st century

Is your server on that list?

j/k, I’m sorry, I’ll see myself out XD

mastersummoner|1 year ago

I'm not a fan of cheap puns, but that was excellent.

kazinator|1 year ago

Postgres didn't look both ways before stepping off the curb.