[postgis-devel] MVT API Q?

[Björn Harrtell]

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.

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.

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.

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.

/Björn

2017-09-26 14:08 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:

> 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.
>   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.
>
> P
>
> On Mon, Sep 25, 2017 at 9:57 PM, Sandro Santilli <strk at kbt.io> wrote:
>
>> On Mon, Sep 25, 2017 at 03:06:50PM -0700, Paul Ramsey wrote:
>>
>> > But, the features fed into ST_AsMVTGeom will have been themselves
>> selected
>> > using a bbox. If that is the same bbox as fed into ST_AsMVTGeom (makes
>> > sense) then it's possible that there are features that *should* be in
>> the
>> > tile (because they fall within the buffered area, but not within the
>> bbox
>> > itself) are *not* in the tile.
>> >
>> > I'd expect a user to provide the same box to ST_AsMVTGeom as they use in
>> > the WHERE clause, but that means potentially there will be features
>> missing.
>>
>> Are you asking why not passing an expanded box directly ?
>>
>> Or given your above description I'd say the expectance of using the
>> same box for filtering and as a parameter to ST_AsMVTGeom is wrong
>> and an HINT about that could be added to the manual...
>>
>> --strk;
>> _______________________________________________
>> postgis-devel mailing list
>> postgis-devel at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170927/84f9281e/attachment.html>