On Tue, Sep 29, 2009 at 6:58 PM, Anthony <span dir="ltr"><<a href="mailto:osm@inbox.org">osm@inbox.org</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><div></div><div class="h5">On Tue, Sep 29, 2009 at 7:35 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><div class="gmail_quote">
<div><div></div><div class="h5"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div>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>
<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></div><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>
</div></div></blockquote><div><br>No. In most cases the ways do not share nodes. Almost all of the time, the overlapping ways share node locations.<br><br>e.g.: Two neighboring square country borders: one with nodes a,b,c,d and one with nodes w,x,y,z:<br>
<br style="font-family: courier new,monospace;"><span style="font-family: courier new,monospace;">a--bw--x</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--dy--z</span><br><br>Nodes b and w are exactly overlapping, but are part of two different ways.<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>
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><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>