[postgis-devel] ST_AsMVT

[Nicklas Avén]

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



On Mon, 2016-10-10 at 11:42 +0200, Björn Harrtell wrote:
> 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 gma
> > > > il.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
> > > 
> > > 
> > 
> > 
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel