[postgis-devel] MVT API Q?

[Javier Santana]

Just to give a different point of view about this.

As I see this the transformation to mvt coordinates stage should be outside
`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.

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 (even the spec points in that direction
<https://tools.ietf.org/html/rfc7946#section-4>)

Cheers

On Wed, Sep 27, 2017 at 7:38 AM Björn Harrtell <bjorn.harrtell at gmail.com>
wrote:

> 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
>>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel

-- 
-- CARTO CTO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170927/058b46e9/attachment.html>