[talk-au] Suburb boundaries

BlueMM bluemm1975-osm at yahoo.com
Thu Feb 5 22:40:00 GMT 2009


Darrin Smith <beldin at ...> writes:
> On Thu, 05 Feb 2009 17:18:53 +1030
> Jack Burton <jack at ...> wrote:
[SNIP]
> > 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
> boundary.
> 
> 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.

I've been following this discussion, and have changed my mind each post on
whether it should be a single way or a relation :-)

I think I now "vote" for a relation especially given the stacking issue Darren
brought up. If used for rivers/roads etc. (which probably has much accuracy than
consumer grade GPS), the way's are going to have to be divided up anyway (change
in speed, oneway, surface, roundabouts etc.). So together with the mass data
issue when viewing an area, relations seems to be the best option.

> [SNIP] 

How excessive are the extra nodes? I wonder if those nodes have significance,
like intersections of roads etc. Personally, if at all possible, I'd prefer to
keep the imported ways as close to the ABS data as possible.

Has anyone had any ideas on tagging? We have Tiger and other imports as
examples, but I imagine source_ref=ABS is a too general, there's probably lots
of organisations with ABS as initials. Would need to tag the ABS ID's on the
ways as well to allow for future updates.

BlueMM





More information about the Talk-au mailing list