[talk-au] Suburb boundaries

Cameron osm-mailing-lists at justcameron.com
Thu Feb 5 10:23:01 GMT 2009

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20090205/ba87a1b3/attachment.html>

More information about the Talk-au mailing list