[postgis-devel] geom_name

[Björn Harrtell]

I'm pro multiple agg definitions to get this as nice as possible. After all
it's just two additional variants as ST_AsMVTGeom is not an aggregate.

Do I get a deadline?

/Björn

2017-09-07 22:59 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:

>
> On Sep 7, 2017, at 1:49 PM, Björn Harrtell <bjorn.harrtell at gmail.com>
> wrote:
>
> Most annoying agitation! Because it's backed with sound reasoning and
> clear improvement to current state.
>
> So, I'm open to make these changes. It's now or never right.
>
> However, one limiting factor is that I'm fairly certain aggregate
> functions do not support the DEFAULT keyword for parameters (affecting
> ST_AsMVT).
>
>
> Damn.
>
> You seem to be right. The raster aggregates show the pattern of multiple
> agg definitions to support different parameter patterns,  and extra
> transfns for each pattern. That’s probably required so that the back-end
> can match up the parameters of the aggregate to the parameters of the
> transfn to use the correct one.
>
> So the goal of having simpler userland signatures for the aggregates runs
> into causing a much uglier situation in the set-up scripts. The C code can
> probably remain simple, but it then looks much as it does now, with checks
> for NULL parameters and use of defaults in those cases.
>
> I’m still kind of in favour of it, since a clean userland is nice. On the
> other hand, folks using these kinds of functions are probably using them in
> software (mapnik, geoserver, etc), not by hand, so they’ll write one (ugly)
> query once, then never look at it again.
>
> Arguments pro and con?
>
> P
>
>
> /Björn
>
> 2017-09-07 22:39 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:
>
>> Actually, no, I’d like to see signature changes… in particular,
>>
>> bytea ST_AsMVT(text layer_name, anyelement row,  int4 extent default
>> 4096, text geom_name default NULL);
>> geometry ST_AsMVTGeom(geometry geom, box2d bounds, int4 extent default
>> 4096, int4 buffer default 0, bool clip_geom default true);
>> bytea ST_AsGeobuf(anyelement row, text geom_name default NULL);
>>
>> Then the presence of (geom_name == NULL) implies “automagically use the
>> first geometry you find”
>> And the null checks on extent, buffer, clip_geom can be dropped since
>> PgSQL will automatically in-fill the defaults
>>
>> You don’t have to do the above, I’m just agitating for it.
>> Agitate, agitate.
>>
>> P.
>>
>>
>>
>> On Sep 7, 2017, at 1:34 PM, Björn Harrtell <bjorn.harrtell at gmail.com>
>> wrote:
>>
>> So we are agreed that there will be no signature change? Instead I will
>> work towards an implementation and documentation change for geom_name to
>> the following:
>>
>> "geom_name is the name of the geometry column in the row data. If NULL it
>> will default to use the first geometry column in the row data."
>>
>> /Björn
>>
>> 2017-09-07 21:08 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:
>>
>>>
>>> Yes, take the first one unless the geom_name is provided. So geom_name
>>> would default to NULL and NULL would mean “the first one you find"
>>> P
>>>
>>>
>>> On Sep 7, 2017, at 12:06 PM, Regina Obe <lr at pcorp.us> wrote:
>>>
>>> Just to add to this to make sure I'm following:
>>>
>>> For this question:
>>>
>>> > Also, a bit late in the day, but why the text parameter "geom_name" in
>>> these various signatures, instead of automagically finding it in the row?
>>> > ?
>>> > P
>>>
>>> Is it ever possible that an MVT row could have more than one geometry
>>> column.  I assume so.  If so I think it might be good to keep the geom_name
>>> field though perhaps make it a default option and in that case it picks the
>>> first one it finds.  Similar to how we do pgsql2shp where you can
>>> explicitly set the geometry column or have pgsql2shp do it's thing and just
>>> pick the first one it finds.
>>>
>>>
>>> Thanks,
>>> Regina
>>>
>>>
>>>
>>>
>>> *From:* Regina Obe [mailto:lr at pcorp.us <lr at pcorp.us>]
>>> *Sent:* Thursday, September 07, 2017 2:57 PM
>>> *To:* 'PostGIS Development Discussion' <postgis-devel at lists.osgeo.org>;
>>> 'Björn Harrtell' <bjorn at wololo.org>
>>> *Cc:* 'Paul Ramsey' <pramsey at cleverelephant.ca>
>>> *Subject:* RE: [postgis-devel] geom_name
>>>
>>>
>>> > We should ask about API changing, I'm sure Regina would say we're
>>> done, which effectively means done-for-all-time, since changing public
>>> function signatures is basically impossible one they are done.
>>>
>>> > P
>>>
>>> I'm fine with you changing the API now before final 2.4.0 release.  I
>>> promised no new functions, not no new API changes to new 2.4 functions.
>>>
>>> I think it would be good to drop the old signature in the
>>> postgis_drop_before.sql  since some people have already started using the
>>> MVT functions.
>>>
>>> If it impacts existing code, we should also put in BREAKING CHANGE for
>>> postgis -2.4.0  the change so people are warned and know how to change
>>> their code if they were using an earlier postgis 2.4.0dev
>>>
>>> Thanks,
>>> Regina
>>>
>>>
>>>
>>>
>>> On Thu, Sep 7, 2017 at 10:45 AM, Björn Harrtell <
>>> bjorn.harrtell at gmail.com> wrote:
>>>
>>> Hi Paul,
>>>
>>> No good reason except that I couldn't find out a deterministic way to
>>> find it and put it out of my mind after that. :(
>>>
>>> With some guidance I'll be happy to revise the API if it's not too late
>>> at this point.
>>>
>>> /Björn
>>>
>>> 2017-09-07 19:41 GMT+02:00 Paul Ramsey <pramsey at cleverelephant.ca>:
>>>
>>> Also, a bit late in the day, but why the text parameter "geom_name" in
>>> these various signatures, instead of automagically finding it in the row?
>>> ?
>>> P
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20170907/47d2ba3b/attachment.html>