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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 < > [EMAIL PROTECTED]> > > wrote: > >> > >> On Fri, May 9, 2008 at 10:41 AM, Ian Dees <[EMAIL PROTECTED]> 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 > > > > >
_______________________________________________ Talk-us mailing list [email protected] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-us
