Role of volumes in FGDB export using temporary webmapp/gdal-docker container

This isn't an issue per se, more of a thought that I want to write down to discuss with @td928 when he gets back from El Salvador.

It turns out that volumes are necessary to export geodatabase files via the webmapp/gdal-docker container. My previous understanding is that volumes are how docker manages shared filespaces between a host machine and one or more containers. After working through issue #332 I don't think that understanding is correct.

Docker containers can write to local filesystems without specifying a volume.

For the geodatabase export, the new container doesn't need to read from the "host" (I put host in quotes because the host is a docker container too). It needs to read from the database and that setup is controlled by the --network parameter. It does need to write to the host's filesystem though, and it can do that without a volume specified. I figured this out by running

 docker run \
      --network $docker_network\
      --rm ubuntu echo "test from docker" > docker_test.txt

which creates a text file in the working directory of the "host."

So why does the gdal container need a volume specified?

I really can't tell. Will watch some youtube videos and discuss with Te

Shortcoming of the `LOCAL_WORKSPACE_FOLDER` solution

When the export is run with the -v "${LOCAL_WORKSPACE_FOLDER//\\/\/}$(pwd):/data"\ solution that Te found, it returns this error

docker: Error response from daemon: Mounts denied: 
The path /workspace/pluto_build/output/mappluto_unclipped_gdb is not shared from the host and is not known to Docker.
You can configure shared paths from Docker -> Preferences... -> Resources -> File Sharing.

My solution was to add /workspace/pluto_build/output/mappluto_unclipped_gdb and /workspace/pluto_build/output/mappluto_gdb via the docker GUI. I guess each engineer who wants to export via the devcontainer will have to do this setup. The error message is pretty straightforward.

NYCPlanning / db-pluto