Opened 12 hours ago

Last modified 3 seconds ago

#5836 new defect

Different result with same table and same query in various PostGIS versions

Reported by: zhangyijun Owned by: pramsey
Priority: medium Milestone:
Component: postgis Version: 3.5.x
Keywords: Cc:

Description (last modified by zhangyijun)

Hi! Have a nice day It seems we got different results with same table and same query,

The TABLE is: https://github.com/maplibre/martin/blob/935c6b624fde3a7ba48443ff66e4cf6312b6ef1e/tests/fixtures/tables/table_source.sql you could execute this sql to init the table.

The QUERY is :

SELECT
      ST_AsMVT(tile, 'table_source', 4096, 'geom')
    FROM (
      SELECT
        ST_AsMVTGeom(
            ST_Transform(ST_CurveToLine("geom"::geometry), 3857),
            ST_TileEnvelope($1::integer, $2::integer, $3::integer),
            4096, 64, true
        ) AS geom
        , "gid"
      FROM
        "public"."table_source"
      WHERE
        "geom" && ST_Transform(ST_TileEnvelope($1::integer, $2::integer, $3::integer, margin => 0.015625), 4326)
      
    ) AS tile;

The RESULT is different with postgis/postgis:14-3.3 and postgis/postgis:14-3.5 DOCKER IMAGES.

z 1 x 1 y 1 ⇒ (BLOB) 2 bytes with postgis/postgis:14-3.3

z 1 x 1 y 1 ⇒ (BLOB) 607 bytes with postgis/postgis:14-3.5

z 1 x 1 y 0 ⇒ (BLOB) 2 bytes with postgis/postgis:14-3.3

z 1 x 1 y 0 ⇒ (BLOB) 1.18 KB with postgis/postgis:14-3.5

Change History (2)

comment:1 by zhangyijun, 12 hours ago

Description: modified (diff)

comment:2 by robe, 3 seconds ago

Wrapping your example in a function:

CREATE OR REPLACE FUNCTION test_mvt(param_1 integer, param_2 integer, param_3 integer) RETURNS bytea
AS $$SELECT
      ST_AsMVT(tile, 'table_source', 4096, 'geom')
    FROM (
      SELECT
        ST_AsMVTGeom(
            ST_Transform(ST_CurveToLine("geom"::geometry), 3857),
            ST_TileEnvelope($1::integer, $2::integer, $3::integer),
            4096, 64, true
        ) AS geom
        , "gid"
      FROM
        "public"."table_source"
      WHERE
        "geom" && ST_Transform(ST_TileEnvelope($1::integer, $2::integer, $3::integer, margin => 0.015625), 4326)
      
    ) AS tile$$ language sql;

and then running these tests

SELECT length(test_mvt(1,1,1));
SELECT length(test_mvt(1,1,0));
On my: SELECT postgis_full_version()
' ' version();
POSTGIS="3.6.0dev 3.5.0-186-gff6fc3b6c" [EXTENSION] PGSQL="170" GEOS="3.13.0-CAPI-1.19.0" PROJ="8.2.1 NETWORK_ENABLED=OFF URL_ENDPOINT=https://cdn.proj.org USER_WRITABLE_DIRECTORY=C:\Users\lr\AppData\Local/proj DATABASE_PATH=C:\ming64gcc81\projects\proj\rel-proj-8.2.1w64gcc81/share/proj/proj.db" (compiled against PROJ 8.2.1) LIBXML="2.12.5" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" PostgreSQL 17.2 on x86_64-w64-mingw32, compiled by gcc.exe (x86_64-posix-seh-rev0, Built by MinGW-W64 project) 8.1.0, 64-bit

Yields the same answers as you have for your 3.5

607
1204/1024 = 1.175 kb

Still need to check the older versions. I don't remember off hand if we made changes between PostGIS 3.3 and 3.5 of MVT or curvetoline support. But I would presume that would be where changes might arise. I think the WAGYU version might impact things, but I don't think we updated the WAGYU between 3.3 and 3.5

Note: See TracTickets for help on using tickets.