[Imports-us] Geopolitical divisions in Ohio
Minh Nguyen
minh at nguyen.cincinnati.oh.us
Sun Mar 16 06:15:40 UTC 2014
(resending to imports-us)
Hi David,
On 21:54 2014-03-15, David Days wrote:
> Minh,
>
> I appreciate your response--a little more detail on my end might help
> answer some of your questions and clarify my goals.
>
> I live near Portsmouth, OH (heh...in those "hilly areas" of which you
> speak), and I'm working on an electoral support system that will be
> geared toward precinct-level workers. In effect, the primary end
> users will be those who have detailed knowledge (and need an
> information system that supports that level of knowledge) of their own
> particular voting district. There are higher-level aggregate
> functions, but the design is to have a precinct (or ward, in the case
> of a city) as the basic building block, since they don't cross larger
> political boundaries.
So far, OSM has very few administrative units below the municipality
level in the U.S. In Cincinnati, we’ve chosen to map neighborhood
districts, as defined by the city, rather than wards. The districts are
signposted and thus exist “on the ground”. You’ll probably find that
only the political boundaries that meet this “on the ground” test will
be allowed into OSM.
> (My understanding is that, in Ohio, a precinct could theoretically
> change shape, move from one congressional district to another, or be
> included/excluded from a township/city/etc election region, but it
> will be an all-or-none proposition--it is either "in" (can vote for a
> ballot question) or "out" (cannot vote for a ballot question). While
> there are exceptions to the higher-level voting districts (school
> districts, townships, cities, etc), the usage of the precinct/ward to
> build those higher-level districts would probably cover 95+% of the
> cases, with exceptions handled as I describe below.)
>
> The initial phase of the project is mostly informational, and
> maintaining the hierarchy of voting districts at all levels is
> probably enough. However, it's a short leap to including mapping
> information that is associated with those voting districts, and I want
> to plan ahead.
>
> As for specific sources of information, there are several planned so far:
>
> 1. Various official sources (county boards of election, local county
> engineer offices, and Secretary of State GIS information as it
> becomes available). These county departments have a very strong
> interest in knowing about, and having a public record of, the
> exact boundaries of the political subdivisions; it's how they
> determine who gets to vote on ballots and who pays for road
> maintenance.
>
Another Cincinnati-area mapper recently attempted to get the GIS agency
for Cincinnati and Hamilton County to open up some of their data to the
public. After initially countering that they’re not a public agency
(hah!), they told us to contact the individual agencies that contributed
the data. Some GIS agencies are reluctant to allow their data to be used
free of charge, because it undermines their fee-based business. So it
may be an uphill battle. On the other hand, it sounds like the
Cleveland-area mappers have gotten more cooperation from their local
governments.
>
> 1. Precinct workers. They have a vested interested in knowing the
> precise boundaries of their areas of responsibility, and (as a
> matter of course) keep up to date on any moves within, among, or
> around the districts.
> 2. Local government bodies as necessary to catch exceptions or fill
> details.
>
> By supplying mass data (from #1) to knowledgeable locals (#2), the
> goal is to have a good source of district map data that is
> cross-checked and adjusted accordingly. The precinct level workers
> can also pull information from #3 as necessary and help feed it into
> the primary system.
I’m of the (not at all universal) opinion that there’s room in OSM for
administrative boundaries. One of the great things about OSM is that
data sets that would otherwise remain as separate layers in most GIS
databases get to “mingle” in OSM. So, for instance, you can explicitly
say that some boundary is really intrinsically aligned with some road;
it isn’t just some coincidence.
However, this model leads to a significant amount of complexity. Once
you import boundaries into OSM, there’s no telling what could happen to
them: what started out as a simple polygon boundary (what we’d call an
“area”) could easily wind up getting sliced and diced many times as
other types of data get added or modified. As far as I know, there’s no
good way to keep track of imported data for the purposes of
synchronizing it with external data sets. That’s why the community is
spending so much time manually updating roads that were imported from
TIGER 2005 to reflect corrections made in TIGER 2012.
> Initially, I don't expect the maps to be very accurate. As you
> pointed out, there are exceptions at various levels, "official"
> information doesn't often jibe with local conditions, and the whole
> thing can leave large holes (like the townships you mentioned) that
> may be pretty important to someone actually in the area. But with a
> few iterations, I expect the map data to tighten up considerably, and
> ongoing maintenance of the data to be part of the routine operation.
>
> Once the data reaches an acceptable level of quality, I'd like to
> contribute it to the community, and even help maintain it. I'm hoping
> it will benefit the community (more and accurate data) as well as
> myself (rather than running a mapping system, I'm just using one that
> has the correct information). Making that transition to an
> OSM-supported display of the data would be much easier if the entire
> system is build from the ground up with that goal in mind. To build
> that, however, means that I have to understand both how OSM works and
> what the community requires for both data quality and etiquette.
OSM is a single, very diverse data set – a map, if you will – but not a
GIS clearinghouse. Data in OSM can’t be compartmentalized like in other
systems. We love micromapping all kinds of physical minutiae –
sidewalks, power substations, golf holes, whatever – but there’s a very
high bar for including stuff that can’t be seen on the ground. When new
aerial imagery comes out, armchair mappers like me can help to keep
things up-to-date. On the other hand, precinct data in OSM would be only
as reliable as the last data dump.
I don’t mean to dissuade you from contributing to OSM, but you may find
you need to run your own mapping system to get something best suited for
your needs. Since every part of OSM is open source, you might be able to
reuse various parts of the stack – like an editor [1] or renderer [2] –
without necessarily putting all the data directly into the OSM database.
OSM’s data can be accessed via dumps or APIs, so “mashup” can mean more
than pins on a pretty map.
> I hope that explains things a little better. The short term goal is
> to get an accurate set of relationships between voting districts; the
> medium term goal is to use OSM to display the maps within the system.
> I'm hoping to achieve a long-term goal of having good data in OSM
> that is available to everyone. Blank spots are filled, local experts
> are consulted, and everyone gets to use the data.
>
> I appreciate your time, Minh and others, and look forward to hearing
> any suggestions or advice.
>
> Sincerely,
> David Days
> Presumed Hill Jack :-)
Sorry, my message was poorly worded. I was referring to aerial imagery
having few easily discernible boundaries in hilly, heavily wooded
terrain. I’m currently mapping townships in Logan County, where you can
often "snap" boundaries to straight stretches of road or edges of farms.
I haven’t had as much success doing that in, say, Clermont County.
[1] https://github.com/openstreetmap/iD/
[2] http://switch2osm.org/serving-tiles/
--
minh at nguyen.cincinnati.oh.us
More information about the Imports-us
mailing list