Postgres support

[schwanksta]

Seems simple enough to do, but right now my patch just segfaults.

https://github.com/datadesk/binify

[kevinschaul]

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?

[schwanksta]

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" notifications@github.com 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//issues/22#issuecomment-17421905
.

[kevinschaul]

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?

[schwanksta]

Sure thing.

• Ken Schwencke
  On May 3, 2013 3:49 PM, "Kevin Schaul" notifications@github.com 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 notifications@github.com
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" notifications@github.com 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//issues/22#issuecomment-17422394
.