Line up directory structure with ocd divisions

[fgregg]

For the Minneapolis city council. A shapefile of just the city area (with no subdivisions) should be placed at this path

ocd-division/country:us/state:mn/place:minneapolis

Then ward specific shapefile shoule be placed in

ocd-division/country:us/state:mn/place:minneapolis/ward:1
ocd-division/country:us/state:mn/place:minneapolis/ward:2
...
ocd-division/country:us/state:mn/place:minneapolis/ward:13

[derekeder]

Should we separate by individual shape, or collections?

Seems less useful to have a separate shapefile for each ward, hence my naming the folder 'jurisdictions' in #1

[fgregg]

individual shape

Sometimes you only want to a municipal boundary Sometimes you only want a ward boundary

Why is it less useful to have as separate shapefile for each ward?

On Fri, Aug 28, 2015 at 12:30 PM Derek Eder notifications@github.com wrote:

Should we separate by individual shape, or collections?

Seems less useful to have a separate shapefile for each ward, hence my naming the folder 'jurisdictions' in #1 https://github.com/datamade/open-divisions/issues/1

— Reply to this email directly or view it on GitHub https://github.com/datamade/open-divisions/issues/2#issuecomment-135839751 .

[derekeder]

I'm thinking of the human usability of these GeoJSON files.

A few thoughts:

• For a project in Chicago, for example, I'll always want to grab all 50 wards and store them somewhere. One at a time would mean I'd have to write some code to get them in the format I want.
• Being able to look at an entire jurisdiction is useful for checking/validating that it is the correct set of boundaries. We're taking advantage of GitHub's in-browser rendering by hosting here. The value of that is diminished quite a bit if I can only view one at a time.
• Shapefiles are typically organized as collections of polygons, not as individual ones. I think this standard is what people will expect (it's what I expect), and the practice has been established for good reasons (probably similar to what I've said above).

[fgregg]

I thought these were for programmatic access (i.e. councilmatic) and hacking around the fact that we can't easily add geometries to the OCD API. Many geographies are in OCD (state legislatures, some counties, some cities). The one geography per division is what they currently do.

I guess that's the real nub. Is the repo for humans or programmatic access?

On Fri, Aug 28, 2015 at 1:56 PM Derek Eder notifications@github.com wrote:

I'm thinking of the human usability of these GeoJSON files.

A few thoughts:

• For a project in Chicago, for example, I'll always want to grab all 50 wards and store them somewhere. One at a time would mean I'd have to write some code to get them in the format I want.
• Being able to look at an entire jurisdiction is useful for checking/validating that it is the correct set of boundaries. We're taking advantage of GitHub's in-browser rendering by hosting here. The value of that is diminished quite a bit if I can only view one at a time.
• Shapefiles are typically organized as collections of polygons, not as individual ones. I think this standard is what people will expect (it's what I expect), and the practice has been established for good reasons (probably similar to what I've said above).

— Reply to this email directly or view it on GitHub https://github.com/datamade/open-divisions/issues/2#issuecomment-135860213 .

[jpmckinney]

we can't easily add geometries to the OCD API

I figure you won't be adding geometries regularly (they change infrequently), so the ease isn't that critical. That said, an OCD/Imago API administrator can add geometries easily: https://github.com/opencivicdata/imago#getting-started

[fgregg]

Oh... is that so. What does that look like?

On Fri, Aug 28, 2015 at 3:14 PM James McKinney notifications@github.com wrote:

we can't easily add geometries to the OCD API

I figure you aren't adding geometries regularly. The OCD API admin can add geometries easily.

— Reply to this email directly or view it on GitHub https://github.com/datamade/open-divisions/issues/2#issuecomment-135877547 .

[jpmckinney]

I wrote a bit more in Slack but in short: Imago uses Represent Boundaries for the geospatial lookups, and I documented how Imago works and how it integrates with Represent Boundaries at https://github.com/opencivicdata/imago#getting-started You can load geometries into Represent and then load mappings between OCD-IDs and geometries using an Imago management command.