[postgis-devel] MVT API Q?

[Paul Ramsey]

Thank you Bjorn that was the last piece I was missing... what a difficult
problem!
Javier, I'm not what you're describing that is not just ST_AsMVTGeom again;
I suppose we could remove it out of a sense of cleanliness, but then anyone
who wanted to use MVT in practice would just have to re-invent it by
cobbling together all the necessary parts (transform, clip, repair) which
seems hardly any better. There's some (small) precedent for output
functions that alter geometries, in ST_AsKML, which applies a transform
into EPSG:4326 before writing out the result.

P


On Tue, Sep 26, 2017 at 11:41 PM, Javier Santana <jsantana at carto.com> wrote:

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