Re: [talk-au] Suburb boundaries
On Thu, 2009-02-05 at 21:16 +1030, Darrin Smith wrote: Futher to this I was looking back through this thread (thinking maybe about having a look at the data myself) and I James said: It's described as These boundaries have been based upon localities gazetted by the Geographic Place name authority current at the time of the Census. So it's always going to be out-of-date anyway and updated every 4 years, it's not going to change often. But it's a much better start than what we have now :) Very good point. I agree now that there's not much point trying to automate updates as the ABS dataset changes - that could be accomplished faster by just manually updating changes as when gazzetted (so long as someone keeps an eye on each Gazette, but that shouldn't be a problem spread across all the Aussie mappers) [Anyone know what the status is of the copyright (if any) on the Gazette itself?]. I still prefer the idea of areas rather than relations for suburb boundaries in general, for a whole bunch of reasons states earlier (which I won't bore the list with again), but I guess that's just something we'll probably always have differing opinions on... Regards, Jack. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
On Thu, Feb 5, 2009 at 9:23 PM, Cameron osm-mailing-li...@justcameron.comwrote: 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. cheers 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 -- Franc ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Suburb boundaries
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
Re: [talk-au] Suburb boundaries
On Thu, 5 Feb 2009 20:53:01 +1030 Cameron osm-mailing-li...@justcameron.com wrote: How much do suburbs change anyway? Perhaps any changes could simply be introduced manually. ~Cameron Yeah I did think that might be an easier solution, I was addressing automatic updates because jackb brought them up :) And as soon as we modify them in any way (align with road for example) I think it probably comes out the more appealing however we put it in initially. I know for example the SA Gazette tends to provide information about suburb boundary changes, probably before they make into the ABS structures. I imagine the other states have similar channels. -- =b ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
