Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create management command for importing Post shapes #249

Merged
merged 4 commits into from
Jun 27, 2019

Conversation

jeancochrane
Copy link
Contributor

@jeancochrane jeancochrane commented Jun 25, 2019

Overview

With the OCD model migration in #240, we stripped out the import_data script that imported boundaries into the app. Create an import_shapes command that will pull these boundaries from from an OCD API and associate them with their corresponding Post.

Closes #248.

Notes

When opening #248, we'd discussed trying to refactor boundaries to be served as static files instead of being stored in the Post.shape field. Ultimately we determined that would be a bigger refactor than we had scope for, so we went with the approach you see here, which simply refactors the old management command logic for the new models.

Testing instructions

Test these changes by following the instructions in chi-councilmatic: datamade/chi-councilmatic#256

@fgregg
Copy link
Member

fgregg commented Jun 26, 2019

Hi @jeancochrane, I'm sorry we should have written down what we thought the plan was after our conversation yesterday. I want the import_shapes to source the data from geojson file under version control instead of pulling that data from the API. I don't want us need to have Pittsburgh set up the API just to get their shapes in.

@jeancochrane
Copy link
Contributor Author

Shouldn't be too difficult of a change I think, thanks for clarifying @fgregg!

@jeancochrane jeancochrane changed the title Create management command for importing Post shapes [ WIP ] Create management command for importing Post shapes Jun 26, 2019
@jeancochrane jeancochrane changed the title [ WIP ] Create management command for importing Post shapes Create management command for importing Post shapes Jun 26, 2019
model_name='person',
name='headshot',
field=models.FileField(default='images/headshot_placeholder.png', storage=django.core.files.storage.FileSystemStorage(base_url='/', location='/Users/goobzie/datamade/chi-councilmatic'), upload_to='images/headshots'),
),
Copy link
Contributor Author

@jeancochrane jeancochrane Jun 26, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like this headshot migration didn't get caught earlier. It also has a path specific to my machine, since the storage param is set dynamically. If it'll pose a problem, I can remove this from the migration and we can deal with it in a separate PR.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this does not seem like what we want. Let's deal with headshots in a separate PR.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, I removed this operation from the migration.

@@ -243,6 +247,8 @@ class Meta:
on_delete=models.CASCADE,
)

shape = JSONField()
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In the 0.x line, Post.shape was stored as a TextField and data was de/serialized by hand. I'm assuming this is because 0.x was written before Django and Postgres added full support for JSONField, so I went ahead and adjusted it.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if it's better, but the database is postgis enabled if there would be any facilities we wanted to take advantage of there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think it would make any of our current application logic easier, but it does seem like a better abstraction to store it as a GeometryField, and we'd get some amount of database-level validation to boot. I'll go ahead and change the storage format.

councilmatic_core/models.py Show resolved Hide resolved
@jeancochrane jeancochrane requested a review from fgregg June 26, 2019 20:11
Copy link
Member

@fgregg fgregg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looking good. Let me know if you want to discuss the input format for the import_shapes command?

@@ -243,6 +247,8 @@ class Meta:
on_delete=models.CASCADE,
)

shape = JSONField()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if it's better, but the database is postgis enabled if there would be any facilities we wanted to take advantage of there.

model_name='person',
name='headshot',
field=models.FileField(default='images/headshot_placeholder.png', storage=django.core.files.storage.FileSystemStorage(base_url='/', location='/Users/goobzie/datamade/chi-councilmatic'), upload_to='images/headshots'),
),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this does not seem like what we want. Let's deal with headshots in a separate PR.

'shape_file',
help=(
'The location of the file containing shapes for each Division, '
'relative to the project root. The file should be formatted as JSON '
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not formatted as GeoJSON?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From an authoring perspective, I think it would be easier to get or make a geojson file and then edit the properties to add division ids, so the geojson file would look something like:

{
  "type": "FeatureCollection",
  "features": [
    {
      "type": "Feature",
      "geometry": {
        "type": "Point",
        "coordinates": [102.0, 0.5]
      },
      "properties": {
        "division_id": "/some/intersting/unique_id/division_id"
      }
    },
...

otherwise, we'll need to get some shapefile and transform it into this special format geojson file?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That seems reasonable to me. This custom JSON object was the format that minimized the amount of transformation we'd have to do above and beyond what existed in import_data already, but I agree with you that GeoJSON is probably an easier import format for end users to deal with. Changed this up so that it expects GeoJSON as input, and adjusted chi-councilmatic accordingly.

@jeancochrane jeancochrane requested a review from fgregg June 26, 2019 22:06
@fgregg
Copy link
Member

fgregg commented Jun 26, 2019 via email

@jeancochrane jeancochrane changed the base branch from ocd to 1.0 June 27, 2019 15:27
@jeancochrane jeancochrane merged commit 0fbbc5e into 1.0 Jun 27, 2019
@jeancochrane jeancochrane deleted the feature/jfc/import-geographies branch June 27, 2019 15:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants