Repository navigation
fix(mapscript): fall back to storage_crs when options.projection is absent - #2430
Closed
C1-BA-B1-F3 wants to merge 4 commits into
Closed
C1-BA-B1-F3 wants to merge 4 commits into
C1-BA-B1-F3 wants to merge 4 commits into
Conversation
PostgreSQL and MongoDB managers ignored the limit and offset parameters, returning all jobs regardless of the query string. Apply offset before limit in both backends, matching the existing TinyDB behaviour. Fixes geopython#2426
…ints The tilematrixsets and tilematrixset HTML handlers passed api.tpl_config as the template configuration, but that dict carries the full server config (including 'server') and lacks the 'path' key that render_j2_template expects. The lookup therefore always fell back to the default templates, ignoring any custom theme. Pass api.config['server']['templates'] instead, matching every other render_j2_template call site. Fixes geopython#2422
…DBAPI A provider configured with a bare connection string (e.g. "postgresql://user@host/db") resolved to SQLAlchemy's default DBAPI for that backend — psycopg (v3) for PostgreSQL. Deployments that only install psycopg2 then fail with 'ModuleNotFoundError: No module named psycopg' even though the provider pins 'postgresql+psycopg2'. When the caller's URL has no '+driver' suffix and the provider's driver_name does, rewrite the URL's drivername to the pinned one. Fixes geopython#2424
…bsent The MapScript provider only read options.projection, ignoring the documented storage_crs configuration. Deployments that set storage_crs (like every other provider) silently got EPSG:4326, producing empty images for data in any other projection. Use storage_crs when options.projection is not set; the legacy options.projection override still wins when present so existing workarounds keep working. Fixes geopython#2400
Contributor
Author
|
Correcting the CI evidence in my earlier comment: the Root cause The That single failure produces both red tests: Why it is environmental, not this PR
This PR only touches |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The
MapScriptProvideronly readoptions['projection'], ignoring the documentedstorage_crsconfiguration that every other provider honours. Deployments that setstorage_crs(e.g.http://www.opengis.net/def/crs/EPSG/0/2169) silently got EPSG:4326, producing empty or mis-projected images for data in any other projection.Fix
When
options.projectionis absent, fall back tostorage_crs.to_epsg(). The legacyoptions.projectionoverride still wins when present, so existing workarounds keep working.Behaviour matrix
options.projectionstorage_crsTest plan
mapscript/osgeo: all four combinations produce the expected EPSG code.Fixes #2400