RE: PostGIS data loader / dumper - GSOC 2022 Idea

This would require the user to have PostGIS command-line tools and PostGIS
in database installed to use it and the binaries in the PostgreSQL bin
folder.
For windows these files are always installed in PostgreSQL bin when PostGIS
is installed. I think on Linux they are installed in system.

We could probably come up with a sensible way of setting the path with reasonable defaults. I'd be inclined to have that as a separate setting from the normal binpath (as we likely wouldn't have per-server versions, except on Windows).

[Regina Obe]

I was thinking of that too, but wasn’t sure if that was asking for too much. BTW when I brought this idea up, others had similar wishes

Like pgPointcloud loading ogr2ogr (used to load/read 1000s of other spatial vector and non-spatial data) (which is often installed if you have postgis_raster installed). So we might have some others coming down the pike if this is successful, and might to just add these as additional tabs aka a “PostGIS gui”

Do you see any issues with the idea I've outlined in Idea 2:

https://trac.osgeo.org/postgis/wiki/GoogleSummerCode2022

I haven't looked that closely at how those pieces in pgAdmin4 work so not
sure how difficult the task and if it makes sense for a GSOC project.

It's certainly feasible for someone to do. We have infrastructure for running external tools, so that part is easy. Adding a PostGIS binpath would also be very easy. Most of the work would be designing and building the wizard that the user would complete to generate the command that would be run by the process manager. I don't know the intricacies of those commands though, so I have no idea if this is a simple flow or something that's complex with lots of inter-dependencies between options.

[Regina Obe]

For shp2pgsql and pgsql2shp both just need a database connection. There isn’t that much inter-dependency between the options that couldn’t be handled with one screen.

shp2pgsql generates a psql/sql data which can then be piped to psql. That is the only flow where more than one commandline is needed

pgsql2shp needs a connection to the database and then dumps 2-4 files or for each table in the target folder. So for postgis tables it would have a .dbf, .shp, .shx, .cpg

For regular tables (no postgis columns) – it would have a .dbf and .cpg (the cpg just has character encoding information so not really necessary)

My main concern with this project would be on the mentoring side. How familiar are you and Sandro with the pgAdmin codebase, particularly with the newer React framework we're moving to now (which you should probably add to your skills required list in place of Javascript)? The team can offer advice and guidance of course, but if a student ends up needing a lot of hand-holding, that might become more difficult.

[Regina Obe]

I’ve updated the required skill list.

I’ve lurked in the code base but haven’t spent much time looking at it.

No neither Sandro or I are familiar with React. It has been on my list to learn, since many of my clients use it.

I’ve mostly used Angular, JQuery, Bootstrap for my web projects. I’m guessing React wouldn’t be too hard for me to pick up.

Thanks,

Regina