[talk-au] Suburb boundaries

Franc Carter franc.carter at gmail.com
Thu Feb 5 11:32:46 GMT 2009

On Thu, Feb 5, 2009 at 9:23 PM, Cameron
<osm-mailing-lists at justcameron.com>wrote:

> How much do suburbs change anyway? Perhaps any changes could simply be
> introduced manually.
> ~Cameron

I suspect this is true, changing large numbers of suburbs sounds unlikely.
If we had suddenly had
a new set of this data (say at the next census) then my first thought would
be to just 'diff' the two
sets in some way.

Of course if they change the the format is supplied in or there are subtle
changes in say the signifiant
digits or node ordering then the whole thing gets harder.


> 2009/2/5 Darrin Smith <beldin at beldin.org>
> On Thu, 05 Feb 2009 20:23:07 +1030
>> Jack Burton <jack at saosce.com.au> wrote:
>> > Consider two suburbs, A & B, whose boundary is currently defined by a
>> > river. Now let's say that by the time the next ABS update occurs, that
>> > boundary has changed, and a small part of what used to be suburb A has
>> > become part of suburb B (it can happen). Since the ABS data contains
>> > only suburb boundaries (and no separate way for the river itself), and
>> > we're using multiple segments per boundary, and someone has helpfully
>> > merged that boundary segment with the way that forms the river (as I
>> > think you suggested earlier, to avoid stacking up ways on top of each
>> > other), there'd be no method for the update mechanism to know whether
>> > the course of the river itself has changed (and therefore so has the
>> > boundary segment, so it should move the way that defines both) or
>> > whether the river has stayed where it was but the boundary no longer
>> > uses that part of it (so it should split ways, create a new one, then
>> > add it to the boundary relation).
>> This is an automated process, if it can be explain logically the
>> computer can be made to do it. As I said before, as soon as any points
>> are moved things become complicated anyway.
>> If I were implementing this part of it (note Franc is only talking about
>> a one-time import at this stage anyway, so we are talking somewhat
>> theoretically):
>> I'd uniquely identify each common boundary between 2 suburbs that we
>> make a way. Use a diff mechanism to detect a change on said boundary,
>> and look at the data, updating and adjusting a way that hasn't been
>> modified at all and removing and replacing the way if it's been
>> changed beyond the ability to adjust.
>> > With a single closed way around each suburb, the problem does not
>> > arise, since the update process does not need to care about the river
>> > itself (and should be clever enough to detect that another way uses
>> > some of the existing nodes, so duplicate those nodes instead of
>> > moving them).
>> You fob it off so simply but there's a lot of work in your solution
>> also. Following your example any time a minor change happens to a
>> suburb it's likely to re-align every node on the boundary back to the
>> original place, in fact it will most likely have to remove & re-add the
>> entire way since it won't be sure which nodes are which any more,
>> someone could have added more, removed some, etc. You could tag every
>> node I guess, but seems a lot of bloat for small gain, and similar
>> gains would be made to the relation model with individual tags anyway.
>> So we have the boundary solution which when a boundary changes only has
>> to modify 1 shorter way along the common boundary between the suburbs
>> that change or the way solution which most likely requires the whole
>> way to be replaced on an update, possibly removing other adjustments
>> made on other parts of the way. From this point of view the boundary
>> solution requires less far reaching changes than the area solution.
>> Of course any unique ID is risky anyway because it can be accidentally
>> removed, but that's the risk I guess :D
>> --
>> =b
>> _______________________________________________
>> Talk-au mailing list
>> Talk-au at openstreetmap.org
>> http://lists.openstreetmap.org/listinfo/talk-au
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-au

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20090205/3d62cce9/attachment.html>

More information about the Talk-au mailing list