[talk-au] Suburb boundaries

[Jack Burton]

On Thu, 2009-02-05 at 17:04 +1030, Darrin Smith wrote:
> On Thu, 05 Feb 2009 16:29:39 +1030
> Jack Burton <jack at saosce.com.au> wrote:
> 
> > >    1. What way do we want to represent the data, e.g closed ways or
> > > relations consisting of borders - something else ?
> > 
> > Closed ways (areas) - as that's how ABS define them, so it will make
> > merging updated ABS data into the OSM Australia dataset (each time ABS
> > update their dataset, which is presumably quite regularly)
> > significantly easier.
> 
> This isn't really relevant. Given the amount of data involved an
> automated process will have to be developed to bring it all in, so this
> process can just be re-utilised on any update.

Very true. But a one-to-one mapping between OSM ways and ABS boundaries
(accompanied by some means of identifying that mapping uniquely, like a
source_ref:ABS=some_unique_id_from_ABS_dataset tag or similar) would
make writing the automated update tool a significantly simpler task
(e.g.: use a diff of the old cf. new ABS datasets as your input file,
search for corresponding OSM ways by tag, then add/remove/reshape/rename
as appropriate).

Yes, you can still do that if there's a one-to-many mapping, but it's
not quite so simple. And there would be lots more stuff the update
process would need to check for (particularly if boundary segments are
shared by other, non-place-related tags) before removing/reshaping a
boundary during an update. For example: 

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).

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).

Regards,


Jack.