On Tue, Sep 29, 2009 at 8:01 PM, Anthony <[email protected]> wrote: > On Tue, Sep 29, 2009 at 8:34 PM, Ian Dees <[email protected]> wrote: > >> On Tue, Sep 29, 2009 at 6:58 PM, Anthony <[email protected]> wrote: >> 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. >> > > Okay, I was imprecise (a terrible thing when dealing with this topic, so my > apologies). > > Before I dealt with those other problems I was going to be to go through my > data and merge any nodes with shared locations into shared nodes. I'll > probably do this while importing the data into a database, and it should be > very easy. I need the database because I want to be able to extract > sections of the data (individual neighborhoods at a time), and I've > currently got a half gig shapefile (which converts to a 1.7 gig .osm file), > which seems to have the polygons in fairly random order. > > I'm a little worried there might be situations like this, though: > > w--x > | | > a--b | > | | | > c--d | > | | > y--z > > With WY overlapping BD, but not sharing any nodes. If you think you can > attack that situation, I'd be happy to help. >
In this case, I don't consider way WY to be overlapping with BD. I would only consider them overlapping if nodes B and D are part of the way WXYZ. > > 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"). >> > > I should probably check out the java version. Does this use the old 0.4 > method, or the new multipolygon relations? > I rewrote it a while ago to use multipolygon relations when ways are >2000 nodes and when the shapefile contains a multipolygon. http://redmine.yellowbkpk.com/projects/show/geo > I guess using multipolygon relations won't be too bad. I just leave the > tags off all but one outer way (whatever one has the biggest area?), and > then reference them in a relation (calculating the area to determine > clockwise/anti-clockwise). > I currently put the tags on the multipolygon relation, but yes, the polygon's tags should end up on the outer ways according to the wiki page. > > Ugh, it sounds so easy until you get down to the nitty gritty. > Yep :)
_______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
