[postgis-devel] Developing External Functions Using PostGIS Types with postgis-devel

Mon Mar 25 14:49:27 PDT 2019

MST could be in topology.  You already have the node/edge structure in
there.  You could even do in in pure SQL but it would be slow.

On Mon, Mar 25, 2019 at 10:21 AM Paul Ramsey <pramsey at cleverelephant.ca>
wrote:

> Yes, an MST implementation is quite interesting… I even have it on my
> personal wishlist of things to Do.
> If you’re writing it anyways, let’s talk about what the SQL API would be.
> P
>
> On Mar 25, 2019, at 10:20 AM, Adam Dadvar <adam.dadvar at gmail.com> wrote:
>
> Hi All,
>
> Thanks for your responses, all of your comments make sense. Do you think
> PostGIS has scope for including of an MST function (written/partially
> written by me) or is that not within the scope of this module and more
> within pgrouting?
> I will investigate both WKB as a transport layer as well as just copying
> across some PostGIS functions. I am leaning more towards EWKB because that
> should be consistent across PostGIS versions but, as discussed above, there
> is no guarantee that the C code will be consistent especially when moving
> to v3.0.0.
>
> Thanks again all,
> Adam Dadvar
>
> On Mon, 25 Mar 2019 at 14:30, Paul Ramsey <pramsey at cleverelephant.ca>
> wrote:
>
>> Harsh but true.
>> When building “dependent” things for PostGIS I like to get the dependency
>> down to a bare minimum. So, call SQL functions, in SQL. And use EWKB as the
>> transport layer rather than assuming I know what the PostGIS serialization
>> format it. You can see an example in pointcloud_postgis. By using EWKB I
>> can integrate with PostGIS via casts through bytea. For something
>> computationally expensive like a spanning tree algorithm, you probably
>> won’t even notice the slight extra overhead of the one spare format to
>> transit through.
>> You do end up needing your own WKB reader/writer on your side, but it’s
>> not the end of the world.
>> P.
>>
>> > On Mar 25, 2019, at 4:34 AM, Raúl Marín Rodríguez <
>> rmrodriguez at carto.com> wrote:
>> >
>> > Hi,
>> >
>> > Postgis was never intented to be a building block that you could use
>> > to build C code on top; the only thing we guarantee (or try to) is
>> > that we won't break your SQL code on an upgrade*. In fact in the next
>> > release (3.0), the default will be to not install neither headers nor
>> > liblwgeom.so. The main reasoning behind this is that we don't keep
>> > internal ABI stability, so you'd depend on something that can break
>> > even within minor releases and these changes won't be documented.
>> >
>> > * This means that we also keep the exposed C API, since removing those
>> > functions would break installations.
>> >
>> > If you only need the functionality within liblwgeom, I'd recommend you
>> > to have a look at https://git.osgeo.org/gitea/rttopo/librttopo, but
>> > for the Postgres part (which both of you seem to require) there isn't
>> > an alternative to creating the functionality directly inside Postgis.
>> >
>> > On Mon, Mar 25, 2019 at 12:24 PM Esteban Zimanyi <ezimanyi at ulb.ac.be>
>> wrote:
>> >>
>> >> Dear all
>> >>
>> >> I have similar problems when building MobilityDB, a temporal extension
>> of PostGIS that takes care of the temporal aspects and fully delegates all
>> spatial functionality to PostGIS. I ended up adding a file PostGIS.h in
>> which I put all declarations of PostGIS functions that are not in
>> liblwgeom.h, e.g.,
>> >>
>> >> extern void srid_is_latlong(FunctionCallInfo fcinfo, int srid);
>> >> ....
>> >>
>> >> but also the functions from the API that I call directly
>> >>
>> >> extern Datum transform(PG_FUNCTION_ARGS);
>> >> extern Datum buffer(PG_FUNCTION_ARGS);
>> >> extern Datum centroid(PG_FUNCTION_ARGS);
>> >> ...
>> >>
>> >> Regards
>> >>
>> >> Esteban
>> >>
>> >>
>> >> On Mon, Mar 25, 2019 at 12:06 PM Adam Dadvar <adam.dadvar at gmail.com>
>> wrote:
>> >>>
>> >>> Hi All,
>> >>>
>> >>> I have been trying to develop a separate function that builds on top
>> of the PostGIS types. Effectively what I'm trying to do is use
>> MultiLineStrings as a network to compute a minimum spanning tree. The end
>> of each line is a node in this case.
>> >>> I think I have a basic understanding of how your code-base works but
>> I am having issues where functions that I think should be available in
>> postgis-devel are not.
>> >>>
>> >>> I know that liblwgeom.h is included in the postgis-devel library
>> which provides the basic types and some utility functions, but for example,
>> I want to input a MultiLineString (LWMLINE in the C code) so I use
>> PG_GETARG_GSERIALIZED_P(0), but this is not included in liblwgeom.h. For
>> that I can write my own function that does that from PG_DETOAST_DATUM, but
>> for other functions it gets much more complicated - in order to convert the
>> GSERIALIZED object I can either write my own function (which would take a
>> long time) or just use the lwgeom_from_gserialized function that has
>> already been written, however this function is not included in
>> postgis-devel and has a large number of dependencies.
>> >>>
>> >>> I could just copy all of the header files from the source code and
>> include them in my file but I'd prefer to just be able to say that the file
>> depends on postgis-devel and then it can be compiled (this file needs to be
>> rolled out to AWS in future).
>> >>>
>> >>> I understand that the recommendation might just be to produce the MST
>> function within the PostGIS code-base, which I'd be open to do. It just
>> seems strange that the postgis-devel library is basically unusable if you
>> want to use it to extend PostGIS. Does anyone have any pointers on how to
>> proceed?
>> >>>
>> >>> All advice is appreciated,
>> >>> Adam Dadvar
>> >>> _______________________________________________
>> >>> 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
>> >
>> >
>> >
>> > --
>> > Raúl Marín Rodríguez
>> > carto.com
>> > _______________________________________________
>> > 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
>
>
> _______________________________________________
> 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/20190325/976ab1e6/attachment.html>