<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2016-09-16 23:35 GMT+02:00 Paul Norman <span dir="ltr"><<a href="mailto:penorman@mac.com" target="_blank">penorman@mac.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span class="gmail-">
    <br>
    <div>On 9/16/2016 4:27 AM, Björn Harrtell
      wrote:<br>
    </div>
    <blockquote type="cite">CREATE FUNCTION ST_AsMVT(query text, extent <span>box2d,
        resolution double, buffer integer, pixelratio integer</span>)</blockquote>
    <br></span>
    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.</div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
    <br>
    For the other parameters I recommend name text, bounds box2d, extent
    integer DEFAULT 4096, buffer integer DEFAULT 0, clip_geoms bool
    DEFAULT true.<br>
    <br>
    name is the required name of the layer.<br>
    <br>
    bounds is the area which corresponds to the unbuffered area of the
    vector tile, and will typically be the area of an xyz tile.<br>
    <br>
    Extent is the extent for the vector tile, as specified in the spec.<br>
    <br>
    Buffer is how far to go out for geometries to include as well as
    used in clipping.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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<br></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div>I think your recommendations for the other parameters make sense.</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF">
  </div>

<br>______________________________<wbr>_________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org">postgis-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">http://lists.osgeo.org/<wbr>mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div></div>