[talk-au] Suburb boundaries

Darrin Smith beldin at beldin.org
Thu Feb 5 07:37:33 GMT 2009

On Thu, 05 Feb 2009 17:18:53 +1030
Jack Burton <jack at saosce.com.au> wrote:

> But I'm still not a fan of relations for suburb boundaries - even more
> so, now that we know that the authoritative set for Australia (the ABS
> data) is organised as a set of polygons (one for each suburb), since
> we'll presumably want to continue using this dataset for updates (e.g.
> when new suburbs appear, or old ones are split
> up/consolidated/renamed/etc.). This could be accomplished really
> easily if each item of ABS data was tagged with a source_ref:ABS (or
> whatever) set to corresponding object id from the ABS dataset (I'm
> assuming it uses such things - most large datasets do).

And as soon as we edit that data in any way, such as you yourself
suggest doing lower down in your reply, then updates from ABS are only
ever going to be able to be imported as diffs - a straight 'update to
these values' will break any adjusted edges and move other ways around.
This will require extensive processing and either option can be handled
at that time. You also assume the ABS is actually going to be (a)
recently up to date (b) accurate, I'm not holding my breath on either,
blindly syncing with any changes they make is not necessarily wise.

> It still seems to me that the simplest possible set of data to define
> a suburb is the location of its town centre (a single node) and the
> outline of its boundary (a single way). [And we already have most of
> the nodes for NSW towns/suburbs in the OSM dataset, from another bulk
> import of government data - adding suburb areas from the ABS data
> would give us complete definitions for NSW, and the hard part done
> already for other states]

I isolation this makes sense, when included with other features such as
roads etc it makes more sense that if a suburb boundary runs down a
road that road is some how flagged as part of the boundary. Stand alone
areas make extra work correlating that kind of data.

> Also, consider the case of a user downloading a rectangular section
> from OSM (since I'd imagine most of us do that, rather than deal with
> enormous planet or country files), where a suburb boundary intersects
> the boundary of the rectangle downloaded:
> If we use the single way method, the OSM API will give the user the
> entire suburb boundary, even the bits that are outside the rectangle -
> so every suburb that has any part of itself within the rectangle will
> have its boundary fully defined within the user's osm file.
> If we use the relation method, only those segments of the boundary
> which have nodes within the rectangle will be supplied - leaving some
> suburbs with incomplete boundaries in the user's osm file.

If the user doing the download is not prepared to handle the relation
issue with respect to boundaries they will probably encounter far
greater problems that just suburb boundaries. Multi-polygon relations
for example will suffer from exactly the same problem. The issue is
that the down-loader needs to be aware of the data structure and not
make the data structure adjust to handle his in-competencies. For
example in JOSM it's a matter of a 3 clicks to request all the ways of

There are already issues of ways with too many nodes causing
downloading problems for the OSM servers, a single area for a whole
rural suburb (or one of the bigger boundaries like a council) is easily
going to exceed reasonable limits of way length, and unlike a way where
you have to download the entire way every time it's viewed, with
relations you can choose to download only the relevant parts, and the
whole lot if you need it.

Should you happen to not have your download's bounding box cross any
of the suburb boundaries with either method you may just end up with
no suburb data at all anyway. Assuming you can rely on suburb data
from a small are download is a little naive.
> The only situation I can think of where a relation would be necessary
> for a suburb boundary would be when one suburb exists wholly within
> the boundaries of another suburb - but we already have the
> multipolygon relation for that (and I can't think of a single Aussie
> example of this off the top of my head - in fact, the only one I can
> think of globally is Vatican City being wholly within Rome - although
> we do have a similar situation for state borders with NSW/ACT).

It's also able to be handled by the boundary relation with enclaves and
exclaves which are designed for exactly this reason. ACT/NSW being a
prime example of exactly that. Interestingly there is now support in
multi-polygon relations for outer and inner ways to be broken into
multiple ways (mapnik and josm already handle them properly) rather
than being single areas, further indicating that stacked ways is not
considered the ideal solution to these problems. 

> This can be done either way - since with the one closed way per suburb
> method, the nodes along shared portions of boundaries should be common
> anyway: a mapper fixing an incorrect boundary would still only need to
> move the erroneous nodes. For aligning a boundary with a physical
> feature like a river, it'd be a simple matter of merging each node on
> the boundary with the corresponding node on the river (or riverbank
> for wider rivers).

And adding and removing numerous nodes to make it actually line up,
rather than just adding that section of the river to the boundary
sounds like a lot more work to me.

More information about the Talk-au mailing list