[talk-au] Suburb boundaries

[Franc Carter]

One of the things I will do when building the import scripts, is to find out
how many 'excess' nodes
there are for a couple of different smoothing values and eyeball why they
might exist.

We can then make a decision as to whether we should drop nodes and if so how
many

cheers

On Fri, Feb 6, 2009 at 9:40 AM, BlueMM <bluemm1975-osm at yahoo.com> wrote:

> 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
>
>
> _______________________________________________
> Talk-au mailing list
> Talk-au at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-au
>



-- 
Franc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20090206/75c1ae5b/attachment.html>