Add GeoJSON MultiPolygon support for city boundaries

[mapmeld]

Developed this to support change detection in all parts of Boston in https://github.com/cityofboston/changewithin

Created a 'multipolygon' branch to separate from our other changes to the code.

[tmcw]

Going to wait a tick to see if @migurski has reason to PR a Shapely/OGR/whatnot patch.

[migurski]

Not for the moment, though brainless MultiPoly support is a great reason to introduce Shapely. @mapmeld I’ve been making the code somewhat more modular to support user-configurable areas, interested in collaborating since we’re chasing some of the same things?

[mapmeld]

Sure! I've been using Shapely on another project where it worked pretty well. Do you picture a user adding any GeoJSON boundary, using a web tool, or something else?

[migurski]

I see three possible uses:

1. User supplies their own GeoJSON or WKT boundary in a file.
2. User specifies US Census GEOID for a county or place, e.g. 06075 for SF County.
3. User specifies a simple bbox.

[migurski]

…Shapely would help in cases like Oakland which has a hole in it, or Boston which sounds like it has multiple parts.

[tmcw]

For each of those cases, at the end of the day you can get a GeoJSON snippet, right? So changewithin should ideally be pretty limited in what it accepts, as far as I can see.

[migurski]

BTW I did it in a somewhat baroque way in Changepipe to account for relative speed of bboxes, nodes vs. ways, etc.: https://github.com/migurski/Changepipe/blob/master/Changepipe/osm.py#L156

@tmcw You can get a GeoJSON snippet, but it would be totally sweet if you didn’t have to!

[migurski]

Sample invocations:

1. changewithin --within newyork.geojson
2. changewithin --within http://example.com/newyork.geojson
3. changewithin --within http://example.com/newyork.wkt
4. changewithin --within census:06075
5. changewithin --within bbox:-180,-90,180,90

Or like this?

1. changewithin --geojson newyork.geojson
2. changewithin --geojson http://example.com/newyork.geojson
3. changewithin --wkt http://example.com/newyork.wkt
4. changewithin --census 06075
5. changewithin --bbox -180 -90 180 90
6. changewithin --wkt "POLYGON(…)"

[tmcw]

Eh, seems like the kind of thing unix pipes are for, not this tool. Why would we want to expand 'osm change detection' to 'swiss-army knife geodata ingestion and conversion' when better tools for the latter already exist, and the potential userbase of changewithin knows how to use them?

echo "WKTWHATEVER" | wellknown | changewithin

Though changewithin is more a server process than a binary application anyway, so you would want your data in a config file rather than a cli arg.

[migurski]

I think this would be useful for people who don’t know how to do any of those things, but could be convinced to follow a short set of steps to set up a scheduled task on a server someplace. Think county-level GIS specialists who’ve never used a unix pipe.

[tmcw]

Hm, but who do know how to use a CLI, install a python app from scratch, and edit a JSON file? Like - I think, yes, this kind of tool should be accessible to lots more people and will be in the future, but right now we're still in the 'working out the kinks for bleeding-edge users' stage, not the 'creating affordances for new people' stage, since it very recently came into existence and the technique that it uses is not fully baked or congealed.

[migurski]

More likely, they can follow directions on setting up a Heroku account and a Sendgrid account. There's a gulf between knowing enough CLI to copy/paste instructions to get around and grokking pipes. I'll put a bit of time into this, see if I can clarify where this can be coaxed off the bleeding edge through code. The idea of OSM change tracking is pretty established (OWL, Changepipe) but it's not been sufficiently well adapted to a more general audience. The use of email and once-daily updates here in Changewithin is what makes it truly good.