Add park-api layer to geoserver #38
Conversation
docker-compose.yml
Outdated
| # to provide env variables, see https://docs.geoserver.org/stable/en/user/datadirectory/configtemplate.html | ||
| # kartoza/geoserver maps PROXY_BASE_URL_PARAMETRIZATION to ALLOW_ENV_PARAMETRIZATION, see https://github.com/kartoza/docker-geoserver/blob/844c7a26acd1687358c821ea73117a721f25f7b6/scripts/entrypoint.sh#L72 | ||
| - PROXY_BASE_URL_PARAMETRIZATION=true | ||
| # The following parameters are *not* picked up by kartoza/geoserver, but instead passed through as "regular" env vars, and then read by Geoserver whenever one of the config files references them. | ||
| - IPL_POSTGRES_PASSWORD=${IPL_POSTGRES_PASSWORD} | ||
| - IPL_GTFS_DB_POSTGRES_PASSWORD=${IPL_GTFS_DB_POSTGRES_PASSWORD} | ||
| - PARK_API_POSTGRES_PASSWORD=${PARK_API_POSTGRES_PASSWORD?'missing/empty env var $PARK_API_POSTGRES_PASSWORD} |
There was a problem hiding this comment.
The ?' syntax is not explained in the current Compose interpolation spec. It this a typo?
There was a problem hiding this comment.
You are right. It ahould read like this, shouldn't it?
| - PARK_API_POSTGRES_PASSWORD=${PARK_API_POSTGRES_PASSWORD?'missing/empty env var $PARK_API_POSTGRES_PASSWORD} | |
| - PARK_API_POSTGRES_PASSWORD=${PARK_API_POSTGRES_PASSWORD:?'missing/empty env var $PARK_API_POSTGRES_PASSWORD'} |
There was a problem hiding this comment.
The ' around the error message don't help, because it's Docker Compose interpolating $… here, and it ignores sh-like plain strings. We should at least do the following, and maybe (not sure about the implications) also add ':
| - PARK_API_POSTGRES_PASSWORD=${PARK_API_POSTGRES_PASSWORD?'missing/empty env var $PARK_API_POSTGRES_PASSWORD} | |
| - PARK_API_POSTGRES_PASSWORD=${PARK_API_POSTGRES_PASSWORD:?missing/empty env var $$PARK_API_POSTGRES_PASSWORD} |
There was a problem hiding this comment.
Hm, I copied this from the interpolations above. I suggest to create an issue to clean these up, too.
There was a problem hiding this comment.
Cannot review the SLD files because I don't know how they work and their gotchas.
There was a problem hiding this comment.
They have some gotchas, indeed. e.g. SLD-producing/consuming software like geoserver or qgis often define some custom functions (e.g. if_then_else (geoserver) or coalesce(qgis), which others don't).
Geoserver provides a validation function to check before storing, but most checks currently need to be done by visual inspection of rendering results.
There was a problem hiding this comment.
Geoserver provides a validation function to check before storing, but most checks currently need to be done by visual inspection of rendering results.
Can we integrate this in the CI run? Maybe after tomorrow's meeting?
There was a problem hiding this comment.
Let's discuss this separately
This comment was marked as off-topic.
This comment was marked as off-topic.
hbruch
force-pushed
the
park-api-geoserver
branch
2 times, most recently
from
38c9ecd
to
91caa13
Compare
hbruch
force-pushed
the
park-api-geoserver
branch
from
91caa13
to
f186008
Compare
hbruch
force-pushed
the
park-api-geoserver
branch
from
f186008
to
d71c714
Compare
This PR
mdbw_parking_sites_defaultwhich color codes parking_sites according to their remaining capacity/open stateNote: there is an upcoming pgbouncer PR. We should agree if all db connections should be handled via pgbouncer or only those which take a huge benefit.