[postgis-users] ST_AsMVT returns an error when calculating tile bbox from x, y, z

[Björn Harrtell]

Answers inlined below.

2016-11-28 22:38 GMT+01:00 Nikolai Bezdna <mofoyoda at gmail.com>:

> Bjorn, thanks for a quick fix!
> Now it doesn't throw this error.
> Can you please clarify some questions:
>
> 1. How do I concatenate st_asmvt output from different tables? I’ve never
> concatenated binary data in postgres (only strings) and if that really
> works, looks like some kind of magic :)
> My goal is to have multiple layers in a tile, like Mapnik MVT output. I
> guess this is the most common case.
>

There is nothing magic about binary concatenation, it's demonstrated in the
first example on this page:
https://www.postgresql.org/docs/9.6/static/functions-binarystring.html.
ST_AsMVT(...) || ST_AsMVT(...) will produce a single binary tile with two
layers. This works with the MVT protobuf format because a Tile is nothing
more than a collection of Layers at the root level.


> 2. What names are given to layers in the generated tile? Are they
> configurable? (I.e. if my input comes from a function, not a table or a
> view).
>

ST_AsMVT produces exactly one Layer. The first parameter for ST_AsMVT is
name which is the layer name. See
https://git.osgeo.org/gogs/postgis/postgis/pulls/5 for more information
about the parameters.


> 3. Does st_asmvt do any internal filtering and/or simplification of the
> input geometries?
> It’d be great if it doesn’t, because I’d like to have control on this
> process with SQL. So I send rows with filtered and simplified geometry to
> st_asmvt and it just does tile encoding.
>

Yes it does and it is inevitable. A vector tile does not encode original
coordinates. Instead the vector tile has a local integer screen coordinate
system and so coordinates must be translated in the encoding process.
Roughly the logic in the encoding throws away coordinates smaller than a
pixel (defined by the tile screen coordinate system extent) and coerces
geometries smaller than a pixel to point centroids. A more in depth
explanation is found at https://www.mapbox.com/vector-tiles/specification/.


> 4. Are there any tools to check the contents of the tile? Maybe node
> module with a decoder or smth.
>

https://github.com/mapbox/vector-tile-js


> Cheers,
> Nick
>
>
>> Date: Sun, 27 Nov 2016 17:12:22 +0100
>> From: Björn Harrtell <bjorn.harrtell at gmail.com>
>> To: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
>> Subject: Re: [postgis-users] ST_AsMVT returns an error when
>>         calculating tile bbox from x, y, z
>> Message-ID:
>>         <CANhDX=a42GQTDf6b6qo3u4w0k8=qOPOgfsBuRvEF6gxu3+Ex+w at mail.gm
>> ail.com>
>> Content-Type: text/plain; charset="utf-8"
>>
>> I've now added changes to my asmvt branch to allow for non square bounds,
>> which I hope can resolve your issues.
>>
>> /Björn
>>
>> 2016-11-26 9:59 GMT+01:00 Nikolai Bezdna <mofoyoda at gmail.com>:
>>
>> > I’m trying to use ST_AsMVT to respond to client tile requests with
>> > MVT-fromatted response.
>> >
>> > From the client side I’m getting standard web mercator tile coordinates
>> as
>> > z, x, y. To transfer these numbers to proper BBox, I’m using this Mapbox
>> > helper function for PostGIS (TileBBox):
>> > https://github.com/mapbox/postgis-vt-util/blob/master/
>> > postgis-vt-util.sql#L541
>> >
>> > When I use it's output geometry as a BBox parameter for ST_AsMVT
>> function,
>> > I get an error:
>> >
>> > [XX000] ERROR: mvt_agg_init_context: bounds must be square
>> >
>> > Both CRS of BBox and the input geometry is 3857.
>> > ST_AsMVT runs without this error only when x and y are the same, e.g:
>> > ST_AsMVT('test’, TileBBox(10, 1279, 1279), 4096, 0, false, ‘geom’, q)...
>> > In all other cases ST_AsMVT returns this error.
>> > I guess the returned BBox geometry is absolutely square only when x = y.
>> >
>> > But how can I calculate the proper bounding box for each tile request?
>> > TileBBox function looks pretty straightforward. Looks like there are no
>> > errors in it.
>> >
>> > _______________________________________________
>>
>>
> _______________________________________________
> postgis-users mailing list
> postgis-users at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20161129/09bc1b66/attachment.html>