<br>One of the things I will do when building the import scripts, is to find out how many 'excess' nodes<br>there are for a couple of different smoothing values and eyeball why they might exist.<br><br>We can then make a decision as to whether we should drop nodes and if so how many<br>
<br>cheers<br><br>On Fri, Feb 6, 2009 at 9:40 AM, BlueMM <span dir="ltr"><<a href="mailto:bluemm1975-osm@yahoo.com">bluemm1975-osm@yahoo.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">Darrin Smith <beldin@...> writes:<br>
> On Thu, 05 Feb 2009 17:18:53 +1030<br>
</div>> Jack Burton <jack@...> wrote:<br>
[SNIP]<br>
<div><div></div><div class="Wj3C7c">> > Also, consider the case of a user downloading a rectangular section<br>
> > from OSM (since I'd imagine most of us do that, rather than deal with<br>
> > enormous planet or country files), where a suburb boundary intersects<br>
> > the boundary of the rectangle downloaded:<br>
> ><br>
> > If we use the single way method, the OSM API will give the user the<br>
> > entire suburb boundary, even the bits that are outside the rectangle -<br>
> > so every suburb that has any part of itself within the rectangle will<br>
> > have its boundary fully defined within the user's osm file.<br>
> ><br>
> > If we use the relation method, only those segments of the boundary<br>
> > which have nodes within the rectangle will be supplied - leaving some<br>
> > suburbs with incomplete boundaries in the user's osm file.<br>
><br>
> If the user doing the download is not prepared to handle the relation<br>
> issue with respect to boundaries they will probably encounter far<br>
> greater problems that just suburb boundaries. Multi-polygon relations<br>
> for example will suffer from exactly the same problem. The issue is<br>
> that the down-loader needs to be aware of the data structure and not<br>
> make the data structure adjust to handle his in-competencies. For<br>
> example in JOSM it's a matter of a 3 clicks to request all the ways of<br>
> boundary.<br>
><br>
> There are already issues of ways with too many nodes causing<br>
> downloading problems for the OSM servers, a single area for a whole<br>
> rural suburb (or one of the bigger boundaries like a council) is easily<br>
> going to exceed reasonable limits of way length, and unlike a way where<br>
> you have to download the entire way every time it's viewed, with<br>
> relations you can choose to download only the relevant parts, and the<br>
> whole lot if you need it.<br>
><br>
> Should you happen to not have your download's bounding box cross any<br>
> of the suburb boundaries with either method you may just end up with<br>
> no suburb data at all anyway. Assuming you can rely on suburb data<br>
> from a small are download is a little naive.<br>
<br>
</div></div>I've been following this discussion, and have changed my mind each post on<br>
whether it should be a single way or a relation :-)<br>
<br>
I think I now "vote" for a relation especially given the stacking issue Darren<br>
brought up. If used for rivers/roads etc. (which probably has much accuracy than<br>
consumer grade GPS), the way's are going to have to be divided up anyway (change<br>
in speed, oneway, surface, roundabouts etc.). So together with the mass data<br>
issue when viewing an area, relations seems to be the best option.<br>
<br>
> [SNIP]<br>
<br>
How excessive are the extra nodes? I wonder if those nodes have significance,<br>
like intersections of roads etc. Personally, if at all possible, I'd prefer to<br>
keep the imported ways as close to the ABS data as possible.<br>
<br>
Has anyone had any ideas on tagging? We have Tiger and other imports as<br>
examples, but I imagine source_ref=ABS is a too general, there's probably lots<br>
of organisations with ABS as initials. Would need to tag the ABS ID's on the<br>
ways as well to allow for future updates.<br>
<font color="#888888"><br>
BlueMM<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
_______________________________________________<br>
Talk-au mailing list<br>
<a href="mailto:Talk-au@openstreetmap.org">Talk-au@openstreetmap.org</a><br>
<a href="http://lists.openstreetmap.org/listinfo/talk-au" target="_blank">http://lists.openstreetmap.org/listinfo/talk-au</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Franc<br>