search

kevinschaul / binify

A command-line tool to better visualize crowded dot density maps.
MIT License
158 stars 11 forks source link

Postgres support #22

Open schwanksta opened 11 years ago

schwanksta commented 11 years ago

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

https://github.com/datadesk/binify

kevinschaul commented 11 years ago

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 commented 11 years ago

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.

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 .

kevinschaul commented 11 years ago

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 commented 11 years ago

Sure thing.

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/kevinschaul/binify/issues/22#issuecomment-17422394 .