[postgis-devel] ST_AsMVT

[Björn Harrtell]

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/20161010/cbff116a/attachment.html>