PostGIS at 20, the Beginning | Hacker News Reader

PostGIS at 20, the Beginning

blog.cleverelephant.ca

302 pointsjkatz0532 comments

PostGIS is one of those tools (along with Postgres as a whole, Redis also comes to mind) that has been a fucking pleasure to use and depend on. It works, brilliantly, is performant and fairly (relative to complexity) easy to use. If it wasn't for PostGIS I'd have been so far up shit creek at one point, I'd have needed climbing gear to go back down.

Big thanks to all the folks who have spent their time on it. You've created something truly fucking helpful <3

It has also taken a whole subfield, GIS, which was seen as difficult, expensive, and specialised, and made it possible to easily include geospatial functions in all sorts of projects.

I always love these little snippets of the history of how these projects come about. When you use something as established as PostGIS these days it’s easy to forget those few individuals that planted the seeds from which it formed.

It’s an absolutely wonderful project - hat tip to everyone who has made it was it is.

```When Dave had a working prototype, we hooked it up to our little applet and the thing sang. It was wonderfully quick,```

This is the thing that I most love about programming. Given a little time, making something just fly that wasn't possible before.

Much of the interesting work I've been able to do in the last five years is entirely due to the hard work put into PostGIS to make it an excellent open-source GIS platform.

Kudos to all involved, and especially Paul for his work spearheading and maintaining it for so many years!

I recently had to start working with GIS data and also didn’t want to be bound to anything ESRI related. I picked up PostGIS (along with the SQLite one Spacialite) and it’s really a dream to use. This history bite is really cool!

I migrated my LAMP stack app to postgres+postgis in 2005, and met with Refractions folks in Victoria for advice, I have nothing but glowing reviews and its only gotten better since.

Now I need something like that but in N dimensions...

PostGIS is popular and fine, but is there a front end framework available designed to work with it, so that one can fully avoid the proprietary ESRI stack?

QGIS or Geoserver, or GDAL for lower level stuff.

There's https://www.qgis.org/en/site/ but when I've worked with web based projects we've used Django and made a custom UI for it. It depends on what type of data you want to display though, for us it was map data so we just used https://leafletjs.com/

For quick stuff at work our default is geopandas + Plotly.

there are plural resources, not one winner-take-all right?

Mapbox is the probably the best GL based mapping client but it is no longer free on the latest version. Although, its not designed to work with PostGIS explicitly you definitely can. (i.e. querying mvts, map tiles, through PostGIS)

Leaflet as others have said is another good option, but is really made for old slipply map tiles.

Most of the ESRI based web clients I think look and feel terrible IMO. Rendering just looks off. What features are you looking for in a mapping client?

Esri's JavaScript API 3 has poor performance, but I've been very happy with version 4.

If you are doing analysis and exploration, or creating offline reports, QGIS is worth learning. It can connect to and query a PostGIS backend directly, and doesn't need to do any sort of intermediate translation and storage that I've seen other packages require. It's scriptable, and extremely flexible -- I've used it to create reports and artifacts to share externally. Overall a solid example of spectacular open source software.

While QGIS is ok, for many applications including analysis and making reports. It is not particularly suited if you want to embed a map view in another application, or to build a full custom front end to render map views.

PostGIS is now basically the "industry standard", so most third party tools work with it, even Esri! Here's some open source parts:

Desktop: https://qgis.org

Middleware: https://mapserver.org, https://geoserver.org, https://mapnik.org, https://github.com/crunchydata/pg_tileserv, https://github.com/crunchydata/pg_featureserv

Web UI: https://openlayers.org, https://leaflet.org, https://www.mapbox.com/mapbox-gljs

much to some grumpiness from the home office, we even used postgis at esri's Portland R&D center.

it was a pleasure to use, and pramsey is definitely a stand up person.

I recently built a prototype with GeoDjango & it seems productive.

Queries & plots are relatively straightforward. Creating custom forms to edit map data is harder to figure out. The tutorials I found focus on the Django admin, but don’t explain how to create user-facing forms for site visitors.

Anyone know of good GeoDjango tutorials (or well documented examples) for forms?

- update the location of a point with drag and drop

- add waypoints to a line

PostGIS can write to GeoJSON so you can have a simple flask or bottlepy webserver to query the db. Then use leaflet GeoJSON layer to pull down the data and render it on map.

There is of course the newer vector tiles which is a better solution in many situations but a bit more complicated to get going. Crunchy Data have made some good examples and a nice tile server for this.

Leafletjs was the only oss frontend option back in 2015-2016 when we ditched Esri and created our own in-house app, based on Electron. Apart from Mapbox, which was freemium.

Did you consider OpenLayers?

It's been around for a long time and is really powerful when compared to other open source web-based mapping/GIS options - unfortunately I never really need the advanced features in the projects I tend to work on.

https://openlayers.org/

Edit, my favourite from their list of examples: https://openlayers.org/en/latest/examples/sea-level.html

I think OpenLayers had come up as an option back then, but Leaflet was just easy to adopt, I guess.

Thank you Paul!

I co-built a small company on GeoDjango (Django + PostGIS) and it was a real pleasure to be able to have such a well-working piece of technology in a very fragmented and messy space.

It's a real gem in the world of geospatial data.

I love PostGIS. I have used it in many projects.

PostGIS raster is really interesting to me but the general sentiment is that it's a bit slow and only use it if you need to. It just seems so powerful to combine raster and vector with SQL. What would the alternative be for raster query vertical and horizontal combined with vector? GRASSGIS Timeseries tools look interesting but I've not tried those. Any other ideas?

I remain pretty leery of raster in the database, for the reasons you list, but the power of GDAL to reach out over networks for raster access makes me a little more excited about some raster/vector use cases. It's not a panacea, but it's something.

https://blog.crunchydata.com/postgis-raster-and-crunchy-brid...

I read that blog post. Such a good example. But there is even a comment in there warning about raster via database. I am going to try it out as well with some MODIS data. I wonder what needs to be done to make raster more performant in POSTGIS?

I just realised you are the author, so thankyou!

There's some work to be done to make all functions parallelizeable. After that it gets harder. For large scale raster analysis, moving the processing closer to the data becomes paramount. I feel like purpose-built raster processing will always be better. Maybe something with FDW or other client/service architecture, where the database sends off the request and the bulk processing happens close to the data. Also, the row-based model of SQL sort of breaks down against raster where the model expects much much larger objects and presenting the tiled-up model to users just adds complexity without getting back performance or flexibility in return.

I have to admit I was quite happy to use sqlite/spatialite and load actual map data into it, it was not easy but manageable.

I'm really looking forward making explorable a 3D world and cities from GIS data, it seems like it's quite ambitious and there are people already doing it, but for gaming it would mean having a very large world and require less 3D artists.

Great historical background - thanks Paul!

Agreed - what a great story!

Reply on news.ycombinator.com