On Sun, Feb 22, 2009 at 6:53 PM, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org">frederik@remote.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;">
Franc,<div class="Ih2E3d"><br>
<br>
Franc Carter wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
The talk-au list has been discussing the import and the current thoughts are here:-<br>
</blockquote>
<br></div>
We did it almost the same way for a German administrative boundary import in late 2008. Your Wiki table doesn't include the obvious relation tags (type=multipolygon, boundary=administrative, admin_level=something) but I guess these were implicit and so you didn't mention them? Also, for the benefit of relation-unaware software, we usually tagged the member ways with "boundary=administrative, admin_level=x", with x being the smallest admin_level of all relations that used this way. We did not add any names or "state:left=x, state:right=y" to the ways though.</blockquote>
<div><br>This is something I was unsure about - the talk page for this had lots of conflicting opinions ;-(<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>
We did not see a need to simplify the lines in our case and I cannot imagine Aussie borders being so detailed that this should be necessary but you'll know better.</blockquote><div><br>There's a lot 'over specification' in the data - 10's of points where one for each end would be fine. <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>
Multipolygons now support multiple outer rings (see the multipolygon relation talk page in the Wiki - the "advanced multipolygons" secion really needs to be moved to the main multipolygon page, it is actually in use and not just "talk"), so that solves your problem of disjoint suburbs.</blockquote>
<div><br>Ok, I'll have a read and wrap my head around it<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>
When actually running the upload (we used the bulk_import.pl for this after creating a suitable .osc file) you should make sure that you *not* attempt to first upload all the nodes and then all the ways and then all the relation (which is what we did), because unless the process is over in an hour or so, you will have eager mappers removing your nodes for obvious lack of use! In the end I had to download the hourly diffs while I was importing, searching for "my" node IDs and checking who deleted some, then undelete them with another script running in parallel, so that my import script would find the nodes it expected to see. So the lesson learned here was, try and upload a way as soon as you have the necessary nodes for it, and not at the end.</blockquote>
<div><br>I thought of this ;-) The file has the data node/way specification just before it is first needed, so hopefully there will<br>only be a short period where the data looks inconsistent<br><br>cheers<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>
<br>
Bye<br><font color="#888888">
Frederik<br>
</font></blockquote></div><br><br clear="all"><br>-- <br>Franc<br>