On Thu, 05 Feb 2009 20:23:07 +1030 Jack Burton <[email protected]> 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 [email protected] http://lists.openstreetmap.org/listinfo/talk-au
