Updated configuration to support regionalization

[Andrew Jennings]

Here's a google doc with some suggested changes to the DistrictBuilder
config.xml file to support regionalization.

https://docs.google.com/document/d/1NkGsYmLzhF_oW8PxVJXM4co4hX7z8zCmf4T7Cf-CPdU/edit?hl=en_US

A legislative body will now belong to a region and we'll use a
RegionCode (a bit like the tree code syntax) to operate on data
attributes and assign geounits to a geolevel/region.

[Dr. Micah Altman]

Thanks...

This looks reasonable to me, generally... a few questions:

>. BaseGeoLevels (i.e., blocks) should be listed before the GeoLevels

Ok, as long as this is enforced by the schema definition...

> Geounits and Geolevels will have to change from having a many-to-one relationship to having a many-to-many relationship.

Ok. Just to be clear... in the google doc example, is the county
geolevel, which is not shown, essentially unchanged from previous
configs? If not -- could the change also be illustrated?

thanks,

Micah

--
________________________________________________________________________
Micah Altman, Ph.D. <http://redistricting.info>           Twitter: @drmaltman
Senior Research Scientist, Institute for Quantitative Social Science, Harvard U.
Archival Director, Henry A. Murray Archive;
"Entia non sunt multiplicanda sine necessitate" - Dr. Invincibilis
(Corollary, "Ad indicia spectate.")

[David Zwarg]

Hello,

Unfortunately, we can't enforce the ordering of GeoLevel nodes based on the existence of child BaseGeoLevel nodes in the schema. However, we can certainly make sure that our setup script detects that condition, and bails before performing any operations. I think that is a good compromise because the configuration problems would get detected at the same setup phase. To a user, they wouldn't be able to tell the difference, and we can put a nice, informative error message in the setup script, instead of the (sometimes) cryptic XML parsing errors when the schema isn't completely correct.

In our example, the other GeoLevel nodes are unchanged from previous configs, so we did not show them.

Thanks,
David

--
David Zwarg, Software Developer

Azavea  |  One Cambridge Center, 6th Floor, Cambridge, MA 02142-1601
dzw...@azavea.com  | T 617.649.2227  | F 215.925.2663
Web azavea.com  |  Blog azavea.com/blogs

[Dr. Micah Altman]

I think I see the issue. I hadn't read through the example closely
enough... Shouldn't the region be associated with the
block_philadalphia (or even not have a block_philadelphia at all)?

The benefit of putting as much in the schema as possible is that one
can leverage schema aware tools, editors etc. That's all... But the
entity-relationship issue is more important.

[David Zwarg]

We hashed out more details over chat, and the google doc reflects our changes to the config schema.

We moved all references to legislative bodies out of GeoLevel configuration items, and put them inside of the Region elements. This reduces redundancies, and hopefully the likelihood of error or misconfiguration.

Thanks,
David