How much do suburbs change anyway? Perhaps any changes could simply be introduced manually. ~Cameron
2009/2/5 Darrin Smith <bel...@beldin.org> > On Thu, 05 Feb 2009 20:23:07 +1030 > Jack Burton <j...@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@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-au >
_______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
