On Tue, Sep 29, 2009 at 7:35 PM, Ian Dees <span dir="ltr"><<a href="mailto:ian.dees@gmail.com">ian.dees@gmail.com</a>></span> wrote:<br><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 class="im">On Tue, Sep 29, 2009 at 6:09 PM, Peter Körner <span dir="ltr"><<a href="mailto:osm-lists@mazdermind.de" target="_blank">osm-lists@mazdermind.de</a>></span> wrote:<br></div><div class="gmail_quote"><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> > And I believe it has<br>
> been suggested to use boundary relations rather than polygons in cases<br>
> where there are a lot of overlapping boundaries.<br>
<br>
</div>Yes, I'ts not good to have overlapping ways - they are a mess to edit<br>
and they can be constructed by relations, as well.<br></blockquote></div><div><br>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...</div>
</div></blockquote><div><br>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>
<br>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>