pramsey at cleverelephant.ca
Fri Mar 29 16:27:41 PDT 2013
The main difficultly in writing something independent and then trying to integrate it is that you'll have to define data structures to solve your problem and many of them may be duplicated in the postgis code. This makes the final integration step more work than one might like.
The best interest sol'n, IMO, is to build with (and within) liblwgeom, ignoring the database piece entirely. You can get something up and running there in pure C, put your tests in CUnit, and debug there, and once everything is complete binding into the database itself is relatively trivial.
On Friday, March 29, 2013 at 4:18 PM, Stephen Mather wrote:
> Hi All,
> Assuming I spelled that right... working on wrapping my brain around adding Dijikstra to PostGIS, which is a largely pleasant way to ride Amtrak back. I had hoped to find something useful in pgRouting as a starting point, but it looks to my novice eyes like Dijikstra is dependent on Boost, so no dice there.
> Anyway, in going down this thread, I've started studying http://trac.osgeo.org/postgis/wiki/DevWikiMain
> Hopefully updated these lines correctly:
> "New functions submitted will have to go into the next minor release which is currently (PostGIS 2.0.4).
> New functions/features that require on disk structural changes will go into next major release (PostGIS 2.1)"
> Anyway, to the topic at hand: regarding function development for a noob-- as a starting place, is it more important for me to get a bit of functioning code that works on a static dataset, and then figure out how to patch that into using liblwgeom etc., or better to understand how to write the function from the ground up in the PostGIS way?
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org (mailto:postgis-devel at lists.osgeo.org)
More information about the postgis-devel