[postgis-devel] ST_AsMVT

[Björn Harrtell]

2016-09-17 0:41 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:

> 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.
>

Yay. :)

But you still have to convince me it's at all possible to produce a vector
tile by binary concatenation, for layers and/or geometries. When diving
into this subject I related to the ongoing work (unfortunately it seem to
have stalled) to make Geobuf streamable. As it is Geobuf is not streamable
which is discussed at https://github.com/mapbox/geobuf/issues/37 and as far
as I can understand it the same applies to the vector tile format?


>
> 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>:
>
>>
>> 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
>> 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/20160917/9950cb6e/attachment.html>