[Talk-us] Counties Data Import

[Ted Mielczarek]

Sure, I'm not arguing that the data ought to be correct, it just seems
obvious that the state and county borders ought to coincide. If you
believe that the county borders are more correct here, then we should
adjust things to match them. In places like my second example, I may
adjust the county borders to follow geography, since that matches
reality.

-Ted

On Wed, May 14, 2008 at 11:08 AM, Ian Dees <ian.dees at gmail.com> wrote:
> Wow, that is pretty ugly. The discrepency is there because the state border
> source has a lower resolution than the counties border source. What's odd is
> that in some spots, the county borders seem to follow land features
> correctly, but in other areas they don't
> (http://openstreetmap.org/?lat=40.658&lon=-76.7046&zoom=13&layers=B0FT).
> This is a problem with the data source. We'll have to make a judgment call
> about what to do ...
>
> Personally, I think the "look" of a map is less important having correct
> data, but I can definitely see the importance of having a visually-correct
> map.
>
> On Wed, May 14, 2008 at 9:28 AM, Ted Mielczarek <ted.mielczarek at gmail.com>
> wrote:
>>
>> Just had this pointed out in #osm:
>> http://tah.openstreetmap.org/Browse/?x=1109&y=1529&z=12&layer=tile
>>
>> What data source did you use for this? Was it from TIGER? The borders
>> don't seem to line up with the state borders (from TIGER) that we
>> imported previously. It looks a bit messy. :-/ I've also noticed that
>> the borough boundary I imported (also from TIGER) for my town doesn't
>> line up with the county borders at all:
>> http://openstreetmap.org/?lat=40.69947&lon=-75.50887&zoom=16&layers=B0FT
>>  The borough border seems to match reality a little better (the river
>> is the county and borough boundary).
>>
>> -Ted
>>
>> On Mon, May 12, 2008 at 7:27 PM, Ian Dees <ian.dees at gmail.com> wrote:
>> > I uploaded the data with the lines overlapping. I figured by combining
>> > the
>> > ways into one with left and right tags, we are making it quite a bit
>> > harder
>> > to query the database to determine which county any particular point is
>> > in.
>> > Also, there would be a significant amount of work to write the import
>> > app to
>> > do that, and I didn't think it was worth it to add time on both ends of
>> > the
>> > workflow.
>> >
>> > On Mon, May 12, 2008 at 6:14 PM, Ted Mielczarek
>> > <ted.mielczarek at gmail.com>
>> > wrote:
>> >>
>> >> On Fri, May 9, 2008 at 10:41 AM, Ian Dees <ian.dees at gmail.com> wrote:
>> >> > Hi everyone,
>> >> >
>> >> > While I was trying to figure out how to divide the massive NHD
>> >> > dataset
>> >> > into
>> >> > more management pieces, I found a county boundary dataset and
>> >> > converted
>> >> > it
>> >> > to OSM.
>> >> >
>> >> > I uploaded Wisconsin and Minnesota county boundaries and submit them
>> >> > for
>> >> > your review. One minor issue:
>> >> >
>> >> > http://tah.openstreetmap.org/Browse/?x=1036&y=1489&z=12&layer=tile
>> >> > ... shows that each county is a separate, closed way in OSM. This
>> >> > means
>> >> > that
>> >> > at most boundaries, the dashed lines that are used to render
>> >> > political
>> >> > boundaries are overlapping and look odd. I can't see a way around
>> >> > this
>> >> > without losing metadata.
>> >> >
>> >> > If you have any opinion on how this data is represented, please let
>> >> > me
>> >> > know.
>> >> > Otherwise, I will upload the rest of the country later on this
>> >> > weekend.
>> >>
>> >> I looked at this data when I uploaded the state borders a while ago.
>> >> The state borders I (and Adam) split by hand into non-overlapping
>> >> sections, tagging them with left:state and right:state appropriately.
>> >> I figured it would be too much work to do the county borders manually
>> >> like that, but I didn't feel like trying to write a program to do it
>> >> in an automated fashion either. I'm not really excited for having lots
>> >> of overlapping borders like that, but I guess I can manually clean up
>> >> the ones in my area if I care enough.
>> >>
>> >> -Ted
>> >
>> >
>
>