On Thu, Feb 5, 2009 at 9:23 PM, Cameron <span dir="ltr"><<a href="mailto:osm-mailing-lists@justcameron.com">osm-mailing-lists@justcameron.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;">
How much do suburbs change anyway? Perhaps any changes could simply be introduced manually.<br>~Cameron</blockquote><div><br>I suspect this is true, changing large numbers of suburbs sounds unlikely. If we had suddenly had<br>
a new set of this data (say at the next census) then my first thought would be to just 'diff' the two<br>sets in some way.<br><br>Of course if they change the the format is supplied in or there are subtle changes in say the signifiant<br>
digits or node ordering then the whole thing gets harder.<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><div class="gmail_quote">
2009/2/5 Darrin Smith <span dir="ltr"><<a href="mailto:beldin@beldin.org" target="_blank">beldin@beldin.org</a>></span><div><div></div><div class="Wj3C7c"><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">On Thu, 05 Feb 2009 20:23:07 +1030<br>
<div>Jack Burton <<a href="mailto:jack@saosce.com.au" target="_blank">jack@saosce.com.au</a>> wrote:<br>
<br>
</div><div>> Consider two suburbs, A & B, whose boundary is currently defined by a<br>
> river. Now let's say that by the time the next ABS update occurs, that<br>
> boundary has changed, and a small part of what used to be suburb A has<br>
> become part of suburb B (it can happen). Since the ABS data contains<br>
> only suburb boundaries (and no separate way for the river itself), and<br>
> we're using multiple segments per boundary, and someone has helpfully<br>
> merged that boundary segment with the way that forms the river (as I<br>
> think you suggested earlier, to avoid stacking up ways on top of each<br>
> other), there'd be no method for the update mechanism to know whether<br>
> the course of the river itself has changed (and therefore so has the<br>
> boundary segment, so it should move the way that defines both) or<br>
> whether the river has stayed where it was but the boundary no longer<br>
> uses that part of it (so it should split ways, create a new one, then<br>
> add it to the boundary relation).<br>
<br>
</div>This is an automated process, if it can be explain logically the<br>
computer can be made to do it. As I said before, as soon as any points<br>
are moved things become complicated anyway.<br>
<br>
If I were implementing this part of it (note Franc is only talking about<br>
a one-time import at this stage anyway, so we are talking somewhat<br>
theoretically):<br>
I'd uniquely identify each common boundary between 2 suburbs that we<br>
make a way. Use a diff mechanism to detect a change on said boundary,<br>
and look at the data, updating and adjusting a way that hasn't been<br>
modified at all and removing and replacing the way if it's been<br>
changed beyond the ability to adjust.<br>
<div><br>
> With a single closed way around each suburb, the problem does not<br>
> arise, since the update process does not need to care about the river<br>
> itself (and should be clever enough to detect that another way uses<br>
> some of the existing nodes, so duplicate those nodes instead of<br>
> moving them).<br>
<br>
</div>You fob it off so simply but there's a lot of work in your solution<br>
also. Following your example any time a minor change happens to a<br>
suburb it's likely to re-align every node on the boundary back to the<br>
original place, in fact it will most likely have to remove & re-add the<br>
entire way since it won't be sure which nodes are which any more,<br>
someone could have added more, removed some, etc. You could tag every<br>
node I guess, but seems a lot of bloat for small gain, and similar<br>
gains would be made to the relation model with individual tags anyway.<br>
<br>
So we have the boundary solution which when a boundary changes only has<br>
to modify 1 shorter way along the common boundary between the suburbs<br>
that change or the way solution which most likely requires the whole<br>
way to be replaced on an update, possibly removing other adjustments<br>
made on other parts of the way. From this point of view the boundary<br>
solution requires less far reaching changes than the area solution.<br>
<br>
Of course any unique ID is risky anyway because it can be accidentally<br>
removed, but that's the risk I guess :D<br>
<font color="#888888"><br>
--<br>
<br>
=b<br>
</font><div><div></div><div><br>
_______________________________________________<br>
Talk-au mailing list<br>
<a href="mailto:Talk-au@openstreetmap.org" target="_blank">Talk-au@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-au" target="_blank">http://lists.openstreetmap.org/listinfo/talk-au</a><br>
</div></div></blockquote></div></div></div><br>
<br>_______________________________________________<br>
Talk-au mailing list<br>
<a href="mailto:Talk-au@openstreetmap.org">Talk-au@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-au" target="_blank">http://lists.openstreetmap.org/listinfo/talk-au</a><br>
<br></blockquote></div><br><br clear="all"><br>-- <br>Franc<br>