[postgis-devel] ST_AsMVT

[Björn Harrtell]

Hi Nicklas,

The specification explains extent like this:

"A layer MUST contain an extent that describes the width and height of the
tile in integer coordinates. The geometries within the Vector Tile MAY
extend past the bounds of the tile's area as defined by the extent.
Geometries that extend past the tile's area as defined by extent are often
used as a buffer for rendering features that overlap multiple adjacent
tiles."

Note that "integer coordinates" are local coordinates to the tile itself. A
nice graphical explanation can be seen here:
https://www.mapbox.com/vector-tiles/specification/#encoding-geom

The buffer parameter is also in local tile units and is only relevant if
clip_geom is true, in which case ST_AsMVT will clip input geometries at the
tile border + eventual buffer. Clipping obviously saves space and an
appropriate buffer will ensure the tile contains enough information to
avoid border rendering artifacts. For label points a reasonably large
buffer might be needed.

Note that the bounds parameter is assumed to be in geographic coordinates
and it's the callers responsibility to map these bounds to a tile in a
grid. I opted to do it this way to not assume a specific tile grid even if
vector tiles is rarely seen with anything else than mercator and the google
tile grid scheme.

I plan to expand the documentation to hopefully explain these things better
there and provide a better example than one from the regression tests.

/Björn

PS. Mail quote below might look funny because for some reason I did not
receive it, it's copy pasted from the list archive.

> Nicklas Avén nicklas.aven at jordogskog.no
> Mon Oct 17 23:26:38 PDT 2016
>
> Hi Björn
>
> I have succeeded in installing and can run the example query.
>
> But I do not understand the parameters at once. Could you give some
guidance?
>
> What is extent and buffer?
>
Sorry if I miss the obvious.
>
> Thanks
>
> Nicklas

2016-10-10 11:42 GMT+02:00 Björn Harrtell <bjorn.harrtell at gmail.com>:

> Hi list,
>
> I'm back from the deep with an initial complete implementation of ST_AsMVT
> aggregate function (1).
>
> The signature is as follows:
>
> CREATE AGGREGATE ST_AsMVT(name text, bounds box2d, extent int4, buffer
> int4, clip_geom bool, geom_name text, anyelement)
>
> Typical usage is with a subquery to create a single layer. Here is an
> example from the regression tests:
>
> SELECT ST_AsMVT('test', ST_MakeBox2D(ST_Point(0, 0), ST_Point(4096,
> 4096)), 4096, 0, false, 'geom', q)
> FROM (SELECT 1 AS c1, 'abcd'::text AS c2, ST_GeomFromText('POINT(25 17)')
> AS geom) AS q;
>
> I have been able to use it on real data to produce a set of more than 400
> 000 tiles with multiple layers and attributes without known issues. Tiles
> with multiple layers can be created by simply concatenating output from
> ST_AsMVT.
>
> Feedback on the implementation, usage and/or test results will be much
> appreciated.
>
> 1) https://git.osgeo.org/gogs/postgis/postgis/pulls/5
>
> /Björn
>
>
> 2016-09-19 0:22 GMT+02:00 Björn Harrtell <bjorn.harrtell at gmail.com>:
>
>> 2016-09-18 17:28 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:
>>
>>> I think that “pass in a SQL” string, or “table name” are the roads to
>>> hackyland. You’re building a database: take in and emit primitive
>>> values/objects or tuples or tuplesets. You build primitives and let other
>>> folks build the SQL stuff on top.
>>>
>>
>> Agreed.
>>
>> I got my hands dirty concatenating encoded protocol buffer messages and
>> fields. Finally I think the wire format have sinked in with me.
>>
>> I see now that it should be possible to not only binary concatenate
>> layers into a tile but also features into a layer message. I have a feeling
>> I'm late to the party in understanding this, but I guess better late than
>> never.
>>
>> I'll be back if I survive the trip deeper into PostgreSQL.
>>
>> /Björn
>>
>>
>>> P.
>>>
>>>
>>> On Sep 18, 2016, at 8:24 AM, Björn Harrtell <bjorn.harrtell at gmail.com>
>>> wrote:
>>>
>>> 2016-09-18 7:48 GMT+02:00 Sandro Santilli <strk at kbt.io>:
>>>
>>>> On Sat, Sep 17, 2016 at 05:47:39PM -0700, Paul Norman wrote:
>>>> > On 9/17/2016 8:09 AM, Sandro Santilli wrote:
>>>>
>>>> > >Using a row-by-row approach, makes it impossible to build such
>>>> > >dictionary, which is why my early attemps were just at producing
>>>> > >the geometric part, very much like the GML output works, delegating
>>>> > >composition of the whole final product to the caller (which could
>>>> > >eventually also be a ROW-taking wrapper).
>>>> >
>>>> > You're right. Joining different layers is fine, but each layer has
>>>> > some common information that is needed.
>>>> >
>>>> > Should it be an aggregate function then?
>>>>
>>>> Probably, which means you'd also need to define a type
>>>> to represent the state (including the dictionary, for example).
>>>> It's enough stuff that might be better to move into its own
>>>> extension.
>>>>
>>>
>>> What do you think about the alternative of simply supplying the function
>>> with a name of a table or view assuming the the proposed structure then
>>> dynamically query it internally using the supplied bounds?
>>>
>>>
>>>>
>>>> --strk;
>>>> _______________________________________________
>>>> postgis-devel mailing list
>>>> postgis-devel at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>>>>
>>>
>>> _______________________________________________
>>> postgis-devel mailing list
>>> postgis-devel at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20161020/d0290cd0/attachment.html>