<br><br><div class="gmail_quote">On Tue, Sep 29, 2009 at 8:01 PM, Anthony <span dir="ltr"><<a href="mailto:osm@inbox.org">osm@inbox.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Tue, Sep 29, 2009 at 8:34 PM, Ian Dees <span dir="ltr"><<a href="mailto:ian.dees@gmail.com" target="_blank">ian.dees@gmail.com</a>></span> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div class="im">On Tue, Sep 29, 2009 at 6:58 PM, Anthony <span dir="ltr"><<a href="mailto:osm@inbox.org" target="_blank">osm@inbox.org</a>></span> wrote:<br></div><div class="im">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.<br>
</div></div><div class="im"><div class="gmail_quote"><div><br>No. In most cases the ways do not share nodes. Almost all of the time, the overlapping ways share node locations.<br></div></div></div></blockquote><div><br>Okay, I was imprecise (a terrible thing when dealing with this topic, so my apologies).<br>
<br>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.<br>
<br>I'm a little worried there might be situations like this, though:<br><br><span style="font-family: courier new,monospace;"> w--x</span><br><span style="font-family: courier new,monospace;"> | |</span><br><span style="font-family: courier new,monospace;">a--b |</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">| | |</span><br style="font-family: courier new,monospace;">
<span style="font-family: courier new,monospace;">c--d |</span><br><span style="font-family: courier new,monospace;"> | |<br></span><span style="font-family: courier new,monospace;"> y--z</span><br><br>With WY overlapping BD, but not sharing any nodes. If you think you can attack that situation, I'd be happy to help.<br>
</div></div></blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>
<br></div><div class="im"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote"><div>
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.<br>
</div></div>
</blockquote></div></div><br>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").<br>
</blockquote></div></div><br>I should probably check out the java version. Does this use the old 0.4 method, or the new multipolygon relations?<br></blockquote><div><br>I rewrote it a while ago to use multipolygon relations when ways are >2000 nodes and when the shapefile contains a multipolygon.<br>
<br><a href="http://redmine.yellowbkpk.com/projects/show/geo">http://redmine.yellowbkpk.com/projects/show/geo</a><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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).<br>
</blockquote><div><br>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.<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>Ugh, it sounds so easy until you get down to the nitty gritty.<br></blockquote><div><br>Yep :) <br></div></div><br>