[postgis-devel] ST_AsMVT

[Björn Harrtell]

2016-09-17 0:45 GMT+02:00 Björn Harrtell <bjorn.harrtell at gmail.com>:

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

Found https://github.com/mapbox/vector-tile-spec/issues/11 supporting the
claim that a multi-layered vector tile is indeed a set of independent layer
messages. Still not sure about the possibility of aggregating the contents
of a layer as separate calls.



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