[Imports-us] Geopolitical divisions in Ohio

Carol Kraemer 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
process.

Thanks,
Carol


-------------------------------------
Carol Kraemer
North River Geographic Systems, Inc
http://www.northrivergeographic.com
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
>> contribution.
>>
>> 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
> https://lists.openstreetmap.org/listinfo/imports-us
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports-us/attachments/20140225/312bd4d1/attachment-0001.html>


More information about the Imports-us mailing list