[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