<div dir="ltr">Just to give a different point of view about this.<div><br></div><div>As I see this the transformation to mvt coordinates stage should be outside `<span style="color:rgb(33,33,33)">ST_AsMVTGeom` and there should be a way to "ST_Transform" to tile mvt coordinates (a ST_Affine with the right params is enough). Obviously the clipping and geometry validation would be done outside of the function as well.</span></div><div><br></div><div>Not that I'm saying this should be like this but is what I would expect from postgis interface, in the same way ST_AsGeoJSON does not do any internal transformation (<a href="https://tools.ietf.org/html/rfc7946#section-4">even the spec points in that direction</a>)</div><div><br></div><div>Cheers</div></div><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 27, 2017 at 7:38 AM Björn Harrtell <<a href="mailto:bjorn.harrtell@gmail.com">bjorn.harrtell@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I think your observations are correct and I agree that it's an ugliness introduced by the split of ST_AsMVT and ST_AsMVTGeom but I don't agree with the proposed solution.<div><br></div><div>The reason for these boxes having to be different is that the transformation done in ST_AsMVTGeom needs to align tile coordinate 0,0 with the geometric bounds. I don't see how that could be done if the input bounds would include a buffer that is not known.</div><div><br></div><div>I guess it would be possible to change the logic to assume that bounds include the buffer but also keep the buffer parameter, the internals of ST_AsMVTGeom could then calculate the origin. I'm not certain that would be an improvement though.</div><div><div><br></div><div>Even if ST_AsMVTGeom might give some redundancy and ugliness and isn't (currently) able to be parallel (currently) I still feel it's a nice separation of concerns.</div></div></div><div dir="ltr"><div><div><br></div><div>/Björn</div></div></div><div dir="ltr"><div><div><br></div><div><div class="gmail_extra"><div class="gmail_quote">2017-09-26 14:08 GMT+02:00 Paul Ramsey <span dir="ltr"><<a href="mailto:pramsey@cleverelephant.ca" target="_blank">pramsey@cleverelephant.ca</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 dir="ltr">I'd say that, unless I'm misunderstanding, it's an ugliness, since correct usage requires the user to both have a manually buffered box for the WHERE and a original box for the MVT call. <div> The user should be responsible for buffering their own box, so that the WHERE box and the MVT box end up matching. So removing the MVT buffer parameter and documenting the best practice of using a buffer.<span class="m_6215870443879679137gmail-HOEnZb"><font color="#888888"><div><br>P</div></font></span></div></div><div class="m_6215870443879679137gmail-HOEnZb"><div class="m_6215870443879679137gmail-h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 25, 2017 at 9:57 PM, Sandro Santilli <span dir="ltr"><<a href="mailto:strk@kbt.io" target="_blank">strk@kbt.io</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>On Mon, Sep 25, 2017 at 03:06:50PM -0700, Paul Ramsey wrote:<br>
<br>
> But, the features fed into ST_AsMVTGeom will have been themselves selected<br>
> using a bbox. If that is the same bbox as fed into ST_AsMVTGeom (makes<br>
> sense) then it's possible that there are features that *should* be in the<br>
> tile (because they fall within the buffered area, but not within the bbox<br>
> itself) are *not* in the tile.<br>
><br>
> I'd expect a user to provide the same box to ST_AsMVTGeom as they use in<br>
> the WHERE clause, but that means potentially there will be features missing.<br>
<br>
</span>Are you asking why not passing an expanded box directly ?<br>
<br>
Or given your above description I'd say the expectance of using the<br>
same box for filtering and as a parameter to ST_AsMVTGeom is wrong<br>
and an HINT about that could be added to the manual...<br>
<br>
--strk;<br>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a><br></blockquote></div><br></div></div></div></div>
_______________________________________________<br>
postgis-devel mailing list<br>
<a href="mailto:postgis-devel@lists.osgeo.org" target="_blank">postgis-devel@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-devel" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-devel</a></blockquote></div><div dir="ltr">-- <br></div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><span style="font-family:"helvetica neue",helvetica,arial,sans-serif">-- CARTO CTO </span></div></div>