(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/
--
[email protected]
_______________________________________________
Imports-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/imports-us
