-
-
Notifications
You must be signed in to change notification settings - Fork 288
Bug-Fix : Fix tile fetch code for MVT Postgres for WorldCRS84Quad TMS #2042
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
ThorodanBrom
wants to merge
2
commits into
geopython:master
from
ThorodanBrom:fix-worldcrs84quad-tiles-mvt-postgres
Closed
Bug-Fix : Fix tile fetch code for MVT Postgres for WorldCRS84Quad TMS #2042
ThorodanBrom
wants to merge
2
commits into
geopython:master
from
ThorodanBrom:fix-worldcrs84quad-tiles-mvt-postgres
Conversation
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
- `ST_TileEnvelope` PostGIS method did not work for WorldCRS84Quad TMS, the MVTs generated with it were not valid tiles for the TMS. This is probably because `ST_TileEnvelope` works properly with WebMercatorQuad, and WebMercatorQuad and WorldCRS84Quad have different tile matrix sizes at the same zoom levels. - Hence instead we manually find the coordinates of the tile envelope based on the zoom level, x and y and use this in `ST_MakeEnvelope` to create the tile envelope for the `ST_AsMVT` query.
5 tasks
webb-ben
added a commit
to webb-ben/pygeoapi
that referenced
this pull request
Jun 17, 2025
Align with WorldCRS84Quad spec using geopython#2042
… for the different TMSs have different parameters
@ThorodanBrom Can you confirm this behavior is correctly implemented in #2022? Would prefer to subsume this PR with that if it looks good. |
Sure, will do.On 24 Jun 2025 4:17 pm, Benjamin Webb ***@***.***> wrote:webb-ben left a comment (geopython/pygeoapi#2042)
@ThorodanBrom Can you confirm this behavior is correctly implemented in #2022? Would prefer to subsume this PR with that if it looks good.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>
|
tomkralidis
pushed a commit
that referenced
this pull request
Jun 28, 2025
* Implement SQLAlchemy native MVT query Fix typo Rename base tile provider Fix Tile HTML highlighting Fix missing tile rename Update CRS conversion Change fallback for vector tile id Undo rename tile provider Reduce diff Cleanup mvt-postgres provider Re-add ST_CurveToLine 97ba024 * Add ST_CurveToLine for output geom * Set id field for vector files * Add MVT Postgres Provider test Fix Flake8 * Fix indentation in MVT-Postgres docs * Fix get_metadata() - Fix get_metadata function - Add unit test for get_metadata * Fix MVT feature properties - Fix MVT field selection - Add test for vector tile properties * Fix flake8 * Add storage_crs information to docs * Add test_postgresql_mvt_provider to GitHub CI * Bump GitHub Action Postgis version Bump GitHub Postgis engine to >3 * Filter SQL connection options Prevent passing dict to SQL connection which throws an error because it cannot be cached * Use geoalchemy2 functions * Amend WorldCRS84Quad Tile bbox Align with WorldCRS84Quad spec using #2042 * Support WorldCRS84Quad in default tile html Add minimal support stretching EPSG3857 TileLayer to EPSG4326. Really should be a CRS84 based layer like: L.tileLayer.wms("https://gibs.earthdata.nasa.gov/wms/epsg4326/best/wms.cgi", { layers: "BlueMarble_ShadedRelief_Bathymetry", attribution: "NASA GIBS", }) .addTo(map);
@ThorodanBrom FYI now that #2022 has been merged, can you rebase this PR? Thanks. |
@tomkralidis This can be closed because #2022 included this fix. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Overview
As part of PR #1979, support was added to generate MVTs from PostgreSQL feature tables in the WorldCRS84Quad TMS. Unfortunately, the use of the
ST_TileEnvelope
method did not work as intended for this TMS. The tiles generated were incorrect andST_TileEnvelope
was throwing 'Invalid x/y' errors for valid tiles indices for WorldCRS84Quad.Hence instead of using
ST_TileEnvelope
, this PR calculates the tile coordinates manually using the WorldCRS84Quad TMS properties and then generates the tile envelope for the query by usingST_MakeEnvelope
Related Issue / discussion
None, I can make an issue if required.
Additional information
Unfortunately the pygeoapi UI does not visualise tiles in the WorldCRS84Quad TMS. Using OpenLayers, I was able to test it out:
Invalid tiles generated using
ST_TileEnvelope
for WorldCRS84Quad onmaster
branch.Correct tiles generated from this PR for WorldCRS84Quad.
I'd be grateful if anyone could test out the current implementation to reproduce the error, and to check the current logic for obtaining the correct tile envelope.
Dependency policy (RFC2)
Updates to public demo
Contributions and licensing
(as per https://github.com/geopython/pygeoapi/blob/master/CONTRIBUTING.md#contributions-and-licensing)