binify
binify copied to clipboard
Postgres support
Seems simple enough to do, but right now my patch just segfaults.
https://github.com/datadesk/binify
I've thought about this (as well as supporting other formats that GDAL/OGR support), and I've come to the following question: Would there ever be a time where converting to an ESRI shapefile would be a problem? Since Binify requires these tools to be installed, couldn't a simple run of ogr2ogr
drop anything into a shapefile? Is there enough of a benefit to outweigh the cost of more code branches?
Of course, there very well might be. Speed might be one benefit. I just want to make sure the objective of Binify stays lightweight.
Are you hoping everything (including the output) stays in postgres?
Its a solid question. Branching the execution is ugly especially because of a weird GDAL quirk that segfaults if your driver variable isn't declared locally.
I like like to keep all of my work in Postgres as a matter of course, so in the end I would have it output to a new table. Using shape files as a temporary stop is annoying, but nothing that can't be stuck between two ogr2ogr calls and scripted.
I might still flesh out the postgres support just to finish it, but no hard feelings about merging it in.
- Ken Schwencke On May 3, 2013 3:36 PM, "Kevin Schaul" [email protected] wrote:
I've thought about this (as well as supporting other formats that GDAL/OGR support), and I've come to the following question: Would there ever be a time where converting to an ESRI shapefile would be a problem? Since Binify requires these tools to be installed, couldn't a simple run of ogr2ogrdrop anything into a shapefile? Is there enough of a benefit to outweigh the cost of more code branches?
Of course, there very well might be. Speed might be one benefit. I just want to make sure the objective of Binify stays lightweight.
Are you hoping everything (including the output) stays in postgres?
— Reply to this email directly or view it on GitHubhttps://github.com/kevinschaul/binify/issues/22#issuecomment-17421905 .
I definitely see how it could be useful, though. Postgres would definitely be the next format to support, if we do take that route.
Why don't you send a pull request when you have it working, and we'll go from there?
Sure thing.
- Ken Schwencke On May 3, 2013 3:49 PM, "Kevin Schaul" [email protected] wrote:
I definitely see how it could be useful, though. Postgres would definitely be the next format to support, if we do take that route.
Why don't you send a pull request when you have it working, and we'll go from there?
On May 3, 2013, at 5:46 PM, Ken Schwencke [email protected] wrote:
Its a solid question. Branching the execution is ugly especially because of a weird GDAL quirk that segfaults if your driver variable isn't declared locally.
I like like to keep all of my work in Postgres as a matter of course, so in the end I would have it output to a new table. Using shape files as a temporary stop is annoying, but nothing that can't be stuck between two ogr2ogr calls and scripted.
I might still flesh out the postgres support just to finish it, but no hard feelings about merging it in.
- Ken Schwencke On May 3, 2013 3:36 PM, "Kevin Schaul" [email protected] wrote:
I've thought about this (as well as supporting other formats that GDAL/OGR support), and I've come to the following question: Would there ever be a time where converting to an ESRI shapefile would be a problem? Since Binify requires these tools to be installed, couldn't a simple run of ogr2ogrdrop anything into a shapefile? Is there enough of a benefit to outweigh the cost of more code branches?
Of course, there very well might be. Speed might be one benefit. I just want to make sure the objective of Binify stays lightweight.
Are you hoping everything (including the output) stays in postgres?
— Reply to this email directly or view it on GitHub< https://github.com/kevinschaul/binify/issues/22#issuecomment-17421905> .
— Reply to this email directly or view it on GitHub< https://github.com/kevinschaul/binify/issues/22#issuecomment-17422268> .
— Reply to this email directly or view it on GitHubhttps://github.com/kevinschaul/binify/issues/22#issuecomment-17422394 .