search

CrunchyData / pg_tileserv

A very thin PostGIS-only tile server in Go. Takes in HTTP tile requests, executes SQL, returns MVT tiles.
Apache License 2.0
879 stars 159 forks source link

projection alignment #117

Closed wendellwt closed 2 years ago

wendellwt commented 3 years ago

Using my own definition of LCC works fine for (plain) data retrieved from a table. However, the data retrieved via FUNCTION public.<tablename> and FUNCTION ST_TileEnvelope returns data, but the data is not aligned with the directly-retrieved data.

The template ST_TileEnvelope contained 40075016.6855784 which seems to be worldMercWidth referenced within bounds.go. I had (somewhat laboriously) determined my own Xmin, Ymin, Xmax, and Ymax values, and so I changed that number in ST_TileEnvelope to my own (Xmax - Xmin). It seemed like a good idea.

Expected behavior (standard web mercator using stock ST_TileEnvelope from documentation): good_data_pic Actual behavior (my own LCC using my own modified ST_TIleEnvelope): bad_data_pic

The brown radar image of weather is the item that is mis-aligned between the two images. (Both instances of pg_tileserv use the same database. The state boundaries and urban areas are from naturalearth. This occurs in both OpenLayers and Leaflet clients)

Were my modifications to ST_TileEnvelope correct? If so, what other issue would cause mis-alignment of the retrieved data? Thank you.

POSTGIS="2.5.5" [EXTENSION] PGSQL="120" GEOS="3.9.1-CAPI-1.14.2" PROJ="Rel. 6.3.1, February 10th, 2020" GDAL="GDAL 3.2.3, released 2021/04/27" LIBXML="2.9.1" LIBJSON="0.15.99" LIBPROTOBUF="1.4.0" RASTER

pramsey commented 2 years ago

Do the hints in #122 help?

wendellwt commented 2 years ago

No, but it was interesting, and I'm trying to understand it. To compound my own issues, I'm trying to do this using MobilityDB.

I've made these substitutions from the sample ST_TileEnvelope function:

postgis geom: ST_TileEnvelope

postgis selector: ST_AsMVTGeom

mobilitydb geom: STBox

mobilitydb selector: asMVTGeom

It seems to work fine without any reprojections. The problem is when I try to reproject it to LCC using epsg:102004. Do I need to (re)project the STBox? Is that what is going on by using ST_MakeEnvelope as the 4th parameter to ST_TileEnvelope?

Thank you,

Wendell

On 2022-02-01 13:40, Paul Ramsey wrote:

Do the hints in #122 [1] help?

-- Reply to this email directly, view it on GitHub [2], or unsubscribe [3]. Triage notifications on the go with GitHub Mobile for iOS [4] or Android [5]. You are receiving this because you authored the thread.Message ID: @.***>

Links:

[1] https://github.com/CrunchyData/pg_tileserv/issues/122 [2] https://github.com/CrunchyData/pg_tileserv/issues/117#issuecomment-1027165721 [3] https://github.com/notifications/unsubscribe-auth/AHQN2LZR7RI6NSRZZMS35TLUZASIZANCNFSM5G3BD7IQ [4] https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&amp;mt=8&amp;pt=524675 [5] https://play.google.com/store/apps/details?id=com.github.android&amp;referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub

wendellwt commented 2 years ago

I figured it out. Not only do the coordinates in the [CoordinateSystem] stanza of the config file need to be square, but they have to be centered at 0,0 (duh!). Using these settings:

[CoordinateSystem]
SRID = 102004
Xmin =  -4250000
Ymin =  -4250000
Xmax =  4250000
Ymax =  4250000

made everything line up correctly.