On Tue, Sep 29, 2009 at 6:58 PM, Anthony <[email protected]> wrote: > On Tue, Sep 29, 2009 at 7:35 PM, Ian Dees <[email protected]> wrote: > >> On Tue, Sep 29, 2009 at 6:09 PM, Peter Körner <[email protected]>wrote: >> >>> > And I believe it has >>> > been suggested to use boundary relations rather than polygons in cases >>> > where there are a lot of overlapping boundaries. >>> >>> Yes, I'ts not good to have overlapping ways - they are a mess to edit >>> and they can be constructed by relations, as well. >>> >> >> I've been hoping someone would strike up a conversation with me on a good >> algorithm to find and relation-ize overlapping boundary ways. I would love >> to implement this... >> > > Can we assume the shared ways use shared nodes? I was planning on making > that assumption, because I believe it's true for the particular data I'm > trying to import. Without that assumption, it's probably too much work for > the time I have. >
No. In most cases the ways do not share nodes. Almost all of the time, the overlapping ways share node locations. e.g.: Two neighboring square country borders: one with nodes a,b,c,d and one with nodes w,x,y,z: a--bw--x | | | c--dy--z Nodes b and w are exactly overlapping, but are part of two different ways. > In any case, I have to worry about converting the multipolygons from the > shapefile I have first. I'm pretty sure there are some, in the standard > "holes go clockwise" format, and shp2osm doesn't handle that as far as I can > tell. > My Java version of shp-to-osm handled this automatically. It appears to me that the shapefile format follows the same model we do: clockwise for outer rings and anti-clockwise for inner rings (e.g. "holes").
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
