[Imports-us] Geopolitical divisions in Ohio
cakraemer at northrivergeographic.com
Tue Feb 25 20:57:05 UTC 2014
Serge et al,
Has there been discussion yet about creating a list of base layer datasets
(imports or survey) that OSM would encourage contributors to focus on?
Also, creating a list of datasets considered inappropriate for the main map
might steer contributors and their communities into a direction that would
help reduce some of the friction, especially during the import approval
North River Geographic Systems, Inc
404.431.0125 cakraemer at northrivergeographic.com
On Tue, Feb 25, 2014 at 3:42 PM, Serge Wroclawski <emacsen at gmail.com> wrote:
> On Tue, Feb 25, 2014 at 12:50 PM, David Days <david.c.days at gmail.com>wrote:
>> Greetings, all.
>> I am a new user to OpenStreetMap, but a long-time software developer.
>> Currently, I'm working on a project that would benefit from having
>> political subdivisions in the state of Ohio represented on a map.
>> A quick run through of the import history page doesn't show any similar
>> data sets, so it appears that the results could be a worthwhile
>> To clarify, "political subdivisions" means not only the standard mapping
>> features (city, village, county), but also township, voting wards and
>> precincts, congressional districts, etc. Some of these divisions are
>> atomic (don't cross other jurisdictional lines), while others can cross
>> several larger groups.
>> Voting wards, congressional distrincts, etc. aren't really things that
> we've had in OSM. Political boundaries even for towns are somewhat
> controversial, and difficult to maintain- I certainly have a lot of
> reservations about adding new data sources.
> I understand that you need this data for your map- but since you seem to
> already have this data in another format- why can't you simply mix the data
> for your particular map?
>> The intent is to start with one county at first, then expand as the
>> project grows. That translates into roughly 100 subdivisions, of which 75+
>> are non-city/town/village in the first data set.
>> I'm planning on getting local experts within the areas described to
>> manually create the mapping features at first, but eventually I would like
>> to take other public domain data that's coming available and import it on a
>> large scale.
>> (As for licensing and reuse--the political divisions themselves are
>> public domain, and I'm the owner of the project; even though the primary
>> purpose is narrow, I thought that OSM and everyone else could benefit from
>> having this map available).
>> With all of that in mind:
>> 1. Good idea, ok, or really, really bad idea?
> I think it's not a good fit for the project, personally.
>> 1. Reuse of existing datapoints is probably important (these
>> divisions usually follow clear boundaries, so finding existing boundary or
>> markers would cut down on the import size). Pointers or gotchas?
>> Would be very complex not only to import, but to maintain.
>> 1. Import scale: Ohio has 88 counties, with probably 100 of these
>> subdivisions on average. If the entire idea is acceptable, would
>> per-county imports work better for the community, or would it be better to
>> get it all together and push it all at once?
>> This is a technical detail that would be better discussed if you decide
> to go through with the import proposal, but I don't think it would be well
> received by the general OSM community.
>> 1. Maintenance: Most of these areas are pretty stable--about 100 out
>> of the whole state get reworked every 10 years. Is this a factor, and how
>> much commitment to maintenance should I factor in?
> Yes, it's a factor.
> IMHO this is similar to the discussion we've had in the past about land
> plots, which is something that some people would like to import. Generally
> these are centralized in terms of a source, and they're not something the
> OSM community can improve upon. Clearly the data is useful to some people,
> but it's not a good match for the kind of general purpose resource that OSM
> exists to serve.
> That doesn't mean it's not good data, or not particularly useful, or that
> you couldn't mix the datasources together on your own- but that it doesn't
> belong in this dataset.
> That's MHO.
> - Serge
> Imports-us mailing list
> Imports-us at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Imports-us