[postgis-devel] ST_AsMVT

[Björn Harrtell]

Feedback on the initial ST_AsMVT implementation encouraged me to rework it
into two functions, ST_AsMVTGeom and ST_AsMVT, which I have recently
commited to svn-trunk.

The main issue with the original function was that it could produce invalid
tiles as per specification and you could only find out by inspecting the
produced end result, as the invalidity might occur in the process of
transforming geometry to tile coordinate space.

By separating the geometry transformation into tile coordinate space with
additional logic to make sure it's valid, it should not be as easy to
accidentally or unintentionally create invalid tiles.

The API of the original ST_AsMVT has changed and is now expected to be used
in concert with ST_AsMVTGeom which should be reflected in the updated
documentation at
http://postgis.net/docs/manual-dev/reference.html#Geometry_Outputs.

See https://trac.osgeo.org/postgis/ticket/3712 for background and
discussions leading up these changes.

/Björn

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/20170307/84439fcb/attachment.html>