Migration issues and questions - 0.6.2 to 0.15.0

[dansku]

I'm trying to update one project from 0.6.2 to 0.15.0

Before I had the http://server/index.json that would return something like

{
  "public.project_hexes": {
    "id": "public.project_hexes",
    "schema": "public",
    "table": "project",
    "srid": 4326,
    "geometry_column": "geom",
    "extent": 4096,
    "buffer": 64,
    "clip_geom": true,
    "geometry_type": "GEOMETRY",
    "properties": {
      "id": "text",
      "count": "int8"
    }
  }

and I could access the .pbf with https://server/public.project_hexes/9/242/196.pbf

Now on version 0.15.0 instead of the /index.json file, there is /catalog

{
  "tiles": {
    "geo_project": {
      "content_type": "application/x-protobuf",
      "description": "public.geo_project.geom"
    },
    "geo_project.1": {
      "content_type": "application/x-protobuf",
      "description": "public.geo_project.point"
    }
  },
  "sprites": {

  },
  "fonts": {

  }
}

I can'f get to download the .pbf files anymore.
What am I doing wrong, and how could I debug and fix it?

Really appreciate it 🥇

[CommanderStorm]

Hi,

Assuming you want all information (geometries+points) from the public.geo_project table, the appropriate URL would be the following

GET https://server/geo_project,geo_project.1/9/242/196

The tilejson is at

GET https://server/geo_project,geo_project.1

Relevant docs:

• https://maplibre.org/martin/using.html
• https://maplibre.org/martin/sources-composite.html

If There is a difference betwen public.project and public.geo_project, I would need further context from the log and/or configuration file.

Note

That is quite a large jump in terms of versions..
We have added quite a number of features in the mean time.
=> Please make sure to read the release notes carefully..

[dansku]

Perfect, not sure what I was doing that it wasn't working!
Thank you

[nyurik]

I really really do not want to support those weird file extensions. They increase request size (not significantly, but still), they create ambiguity, and they require the server to actually know the exact type of tile a source will support - e.g. /src/z/x/y.pbf implies that src is a vector source - but this is not guaranteed, plus it implies the ability to have multiple types for the same coordinates. I think this is a leftover from the early days of kartotherian and tileserve-gl, so best to not have this.

Note that we will might have an extension of the server-side rendered stuff from #1607 + #978 -- because there the url will be /style/<style>/z/x/y, and we may need to provide additional request parameters such as the format (png/jpg/svg/...?), and higher dpi (e.g. @2x)