[postgis-devel] ST_AsMVT

Paul Ramsey pramsey at cleverelephant.ca
Fri Sep 16 15:41:09 PDT 2016


A row parameter will be tricky to code, but worth it, I think. You’ll probably have to hunt through the pgsql source to find one to work off of, but you’ll learn a lot about pgsql internals in the process.

P.

> On Sep 16, 2016, at 3:29 PM, Björn Harrtell <bjorn.harrtell at gmail.com> wrote:
> 
> 2016-09-16 23:35 GMT+02:00 Paul Norman <penorman at mac.com <mailto:penorman at mac.com>>:
> 
> On 9/16/2016 4:27 AM, Björn Harrtell wrote:
>> CREATE FUNCTION ST_AsMVT(query text, extent box2d, resolution double, buffer integer, pixelratio integer)
> 
> As an interface I propose taking in a row or similar instead of a query. Anything that takes SQL as text can be a problem.
> 
> For the other parameters I recommend name text, bounds box2d, extent integer DEFAULT 4096, buffer integer DEFAULT 0, clip_geoms bool DEFAULT true.
> 
> name is the required name of the layer.
> 
> bounds is the area which corresponds to the unbuffered area of the vector tile, and will typically be the area of an xyz tile.
> 
> Extent is the extent for the vector tile, as specified in the spec.
> 
> Buffer is how far to go out for geometries to include as well as used in clipping.
> 
> clip_geoms is if geometries should be clipped at the buffered extent or not. It's valid to include a geom that goes beyond the buffered extent, but this is not normally done for rendering.
> 
> For a return type, I'd go with bytea, being the binary data for the layer. Don't apply gzip compression, it's not part of the vector tile itself.
> 
> Thanks to the properties of mapbox vector tiles, you can then build a multi-layer tile by concatenating the results of multiple ST_AsMVT calls
> 
> Thanks Paul, I thought the first Paul was messing with me but now I see he was serious. :) To clarify, I understand that SQL as text is a problem I was just not seeing any alternative.
> 
> I think your recommendations for the other parameters make sense.
> 
> I was unaware of the possibility to concatenate layers in binary format, it seems reasonable but need to investigate further. I'm still confused about using a "row or similar" type instead of a query, if by that you mean to encode just a single geometry at a time, because I can't see how that could be possible to concatenate as binary. Perhaps my confusion can be explained by that I also have problems understanding the "40.3.4. Row Types" chapter in the PostgreSQL documentation.
>  
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/postgis-devel <http://lists.osgeo.org/mailman/listinfo/postgis-devel>
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org <mailto:postgis-devel at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/postgis-devel <http://lists.osgeo.org/mailman/listinfo/postgis-devel>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20160916/724596fc/attachment.html>


More information about the postgis-devel mailing list