Using martin-cp to generate custom function tiles can only generate zoom 1

[ljh2057]

This is my custom function to achieve the conversion of 4490 coordinate system

 CREATE OR REPLACE
    FUNCTION f_lrdl_4490(z integer, x integer, y integer)
    RETURNS bytea AS $$
DECLARE
  mvt bytea;m numeric;minx numeric;maxy numeric;maxx numeric;miny numeric;
BEGIN
	m:=POWER(2,z);   
	minx := (x / m) * 360.0 - 180;
	maxx := ((x + 1) / m) * 360.0 - 180;
	miny := 90 - ((y + 1.0) / m) * 360.0;
	maxy := 90 - (y / m) * 360.0;
  SELECT INTO mvt ST_AsMVT(tile, 'f_lrdl_4490', 4096, 'geom') FROM (
    SELECT
      ST_AsMVTGeom(
          ST_CurveToLine(smgeometry),
          ST_MakeEnvelope(minx,miny,maxx,maxy,4490),
          4096, 64, true) AS geom,rn,rteg,name,null as elementId,null as elementType
    FROM pdc_lrdl
    WHERE smgeometry && ST_MakeEnvelope(minx,miny,maxx,maxy,4490) 
  ) as tile WHERE geom IS NOT NULL;
  RETURN mvt;
END
$$ LANGUAGE plpgsql IMMUTABLE STRICT PARALLEL SAFE;

It can be accessed and loaded normally, the following is a screenshot of the loading

This is the configuration file config.yaml of martin-cp

postgres:
  - connection_string: postgresql://user:password@192.168.1.1:5432/postgis
    functions:
      f_lrdl_4490:
        schema: public
        function: f_lrdl_4490

This is the command I used to generate tiles using martin-cp

martin-cp   --config mb_config.yaml  --encoding brotli --output-file f_lrdl_4490.mbtiles --min-zoom 1 --max-zoom 10 --bbox 72.004,0.829,137.834,55.827 --source f_lrdl_4490

The generated f_lrdl_4490.mbtiles file is only 12MB. After publishing it to the service, I found that there is data only when z=1, x=1, y=0. Through database query, I found that the data returned by f_lrdl_4490(1, 1, 0) is indeed 12MB. Can martin-cp only generate the first level for custom functions?

[ljh2057]

I am using Martin 0.17.0.

[CommanderStorm]

I am having a bit of trouble to reproduce this.

Could you give me

• the underlying table definition
• an (extract of) the data in said table

If thait is not possible:

• the underlying table definition
• the full log of martin-cp
• what our mbtiles utilitiy says abotu said file

Tip

The file-size is not a good indicator of data being present as using the normalized mbtiles schema is the default.

[ljh2057]

This is my table definition

CREATE TABLE "public"."pdc_lrdl" (
	"smid" int4  NOT NULL,
	"smgeometry" geometry  NULL,
	"objectid" int4  NULL,
	"gb" int4  NULL,
	"rn" varchar(7)  NULL,
	"name" varchar(60)  NULL,
	"rteg" varchar(4)  NULL,
	"type" varchar(20)  NULL,
	CONSTRAINT "pdc_lrdl_pkey" PRIMARY KEY ("smid")
);

CREATE INDEX index_gist_lrdl ON public.pdc_lrdl USING gist (smgeometry);

This is a sample data by query
SELECT st_astext(smgeometry) FROM pdc_lrdl where smid=26

MULTILINESTRING((108.90419113200005 19.008747893000077,108.90429564500005 19.00825730500003,108.90464774300006 19.006795830000044,108.90483008300004 19.00604087100004,108.90501051700005 19.005293825000024,108.90522480700008 19.004189891000067,108.90521768900004 19.00386458400004,108.90518237800006 19.003677367000023,108.90505945500007 19.003417538000065,108.90450008700009 19.002661044000035,108.90351418900008 19.001430261000053,108.90239898200008 19.000040230000025))

[ljh2057]

This is the full log of martin-cp

[2025-08-01T11:42:50Z INFO  martin_cp] martin-cp tile copier v0.17.0
[2025-08-01T11:42:50Z INFO  martin_cp] Using mb_config.yaml
[2025-08-01T11:42:51Z INFO  martin_cp] Use --save-config to save or print configuration.
[2025-08-01T11:42:51Z INFO  martin_cp] Copying 48439 application/x-protobuf tiles from f_lrdl_4490 to f_lrdl_4490.mbtiles
[2025-08-01T11:42:53Z INFO  martin_cp] [2.0s] 4% @ 1199.1/s | ✓ 1 □ 2400 | 38s left
[2025-08-01T11:42:55Z INFO  martin_cp] [4.0s] 22% @ 2747.2/s | ✓ 1 □ 11000 | 14s left
[2025-08-01T11:42:57Z INFO  martin_cp] [6.0s] 41% @ 3309.4/s | ✓ 1 □ 19900 | 9s left
[2025-08-01T11:42:59Z INFO  martin_cp] [8.0s] 58% @ 3526.6/s | ✓ 1 □ 28300 | 6s left
[2025-08-01T11:43:01Z INFO  martin_cp] [10.0s] 76% @ 3706.3/s | ✓ 1 □ 37200 | 3s left
[2025-08-01T11:43:03Z INFO  martin_cp] [12.1s] 95% @ 3824.3/s | ✓ 1 □ 46100 | 611ms left
[2025-08-01T11:43:04Z INFO  martin_cp] [12.7s] 100% @ 3813.8/s | ✓ 1 □ 48438 | done
[2025-08-01T11:43:04Z INFO  martin_cp] Computing agg_tiles_hash value...

[CommanderStorm]

It seems to be related to how the bbox is handled. If I ommit it, it is emmitted as it should

Here is the bbox that you have selected. It does not include the linestring.

http://bboxfinder.com/#72.004000,0.829000,137.834000,55.827000

I think you have a bug either in your coordiante conversion or lat/lon issue?

[CommanderStorm]

maybe also something is different in how you store the coordiantes.
A proper reproducible example with the exact insert sql-insert statement would be when I can continue helping you.

But check first that the bbox actually contains what you want to select

[ljh2057]

I think it is related to the coordinate system of z,x,y calculated by martin-cp. I checked the source code of martin-cp and it is based on the epsg:3857 coordinate system to generate z,x,y, but my custom function is based on epsg:4490

[ljh2057]

This is a sample data

MULTILINESTRING((108.90419113200005 19.008747893000077,108.90429564500005 19.00825730500003,108.90464774300006 19.006795830000044,108.90483008300004 19.00604087100004,108.90501051700005 19.005293825000024,108.90522480700008 19.004189891000067,108.90521768900004 19.00386458400004,108.90518237800006 19.003677367000023,108.90505945500007 19.003417538000065,108.90450008700009 19.002661044000035,108.90351418900008 19.001430261000053,108.90239898200008 19.000040230000025))

[CommanderStorm]

As I said, proper insert statement with which projection both insereted data and table geometry collumn is.

Otherwise, we are talking past each other

[ljh2057]

This is an insert statement,thanks

INSERT INTO "public"."pdc_lrdl"("smid", "smgeometry", "objectid", "gb", "rn", "name", "rteg", "type") VALUES (26,  '01050000208A1100000100000001020000000C00000080517B44DE395B4020584A4D3D023340304CD7FADF395B40A0ED96261D02334078A5A5BFE5395B4070991B5FBD01334004BB6FBCE8395B407062FFE48B01334048433BB1EB395B40F03EA5EF5A013340F8650734EF395B40B0D1B4961201334004812C16EF395B4090E4F544FD003340409B1182EE395B402000FBFFF00033404C0A7E7EEC395B4070F1C5F8DF00334040395554E3395B4010F4E864AE0033408C4E2D2DD3395B405038CCBB5D00334094E8A8E7C0395B40D088F2A202003340', 26, 420301, 'X755', 'dong', '4', NULL);

[CommanderStorm]

Could you please check your bbox as I asked?

[ljh2057]

SELECT ST_Extent(smgeometry) FROM pdc_lrdl;

query result

BOX(73.25000077600004 4.246417482000027,135.4159619080001 53.790714310000055)

[CommanderStorm]

so actually, the bbox you have is this http://bboxfinder.com/#0.829000,72.004000,55.827000,137.834000 not the bbox that I accidentally thought you had.

we look into these tile ranges:

 TileRect {
        zoom: 1,
        min_x: 1,
        min_y: 0,
        max_x: 1,
        max_y: 0,
    },
    TileRect {
        zoom: 2,
        min_x: 2,
        min_y: 1,
        max_x: 3,
        max_y: 1,
    },
    TileRect {
        zoom: 3,
        min_x: 5,
        min_y: 2,
        max_x: 7,
        max_y: 3,
    },
    TileRect {
        zoom: 4,
        min_x: 11,
        min_y: 5,
        max_x: 14,
        max_y: 7,
    },
    TileRect {
        zoom: 5,
        min_x: 22,
        min_y: 10,
        max_x: 28,
        max_y: 15,
    },
    TileRect {
        zoom: 6,
        min_x: 45,
        min_y: 20,
        max_x: 56,
        max_y: 31,
    },
    TileRect {
        zoom: 7,
        min_x: 90,
        min_y: 41,
        max_x: 112,
        max_y: 62,
    },
    TileRect {
        zoom: 8,
        min_x: 180,
        min_y: 82,
        max_x: 224,
        max_y: 124,
    },
    TileRect {
        zoom: 9,
        min_x: 360,
        min_y: 164,
        max_x: 448,
        max_y: 249,
    },
    TileRect {
        zoom: 10,
        min_x: 720,
        min_y: 329,
        max_x: 897,
        max_y: 499,
    },
]

example range, not containing any values

Select x,y,10 as z FROM generate_series(720, 897) as x, generate_series(329, 499) as y where length(f_lrdl_4490(x,y,10)) != 0

Could you select if your function returns values for these ranges?

If none of these match, either your custom projection logic is wrong or we generate the rectangles.

[ljh2057]

I executed this sql and returned 0 records.

[CommanderStorm]

Also, what I asked before but never got an aswer:

What is the SRD of the table?

I somewhat assume

SELECT UpdateGeometrySRID('pdc_lrdl','smgeometry',4490);

[CommanderStorm]

Have you tried writing your function as we recomend here:

https://maplibre.org/martin/sources-pg-functions.html#simple-function

Your projection logic seems.. sus.

[ljh2057]

Also, what I asked before but never got an aswer:

What is the SRD of the table?

I somewhat assume

SELECT UpdateGeometrySRID('pdc_lrdl','smgeometry',4490);

yes,the srid of table is 4490.

[ljh2057]

Have you tried writing your function as we recomend here:

https://maplibre.org/martin/sources-pg-functions.html#simple-function

Your projection logic seems.. sus.

I've tried this way of writing, but the released service has a big offset under EPSG:4490.

[CommanderStorm]

I know about 4490, but how does this offset affect us as a tileserver?

You should not tamper with that offset as you likely know.
If you want to do things in china, you must serve things in that weird projection.

[CommanderStorm]

I convered it to an discussion as I currently don't see clear evidence of a feauture, doc improvement or bug.
I created a few related issues during the investigation, but those are not actually the core issue I think.