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 <[email protected]> wrote: > Darrin Smith <bel...@...> writes: > > On Thu, 05 Feb 2009 17:18:53 +1030 > > Jack Burton <j...@...> 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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk-au > -- Franc
_______________________________________________ Talk-au mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-au
