In looking at some of those ways I'd say your simplification is completely warranted. The curves still look very smooth after you've removed 73% of the nodes.
I agree with others that storage is cheap and saving space in the DB may not be that important. More nodes make for smoother, more detailed ways but after a certain density is reached more nodes offer diminishing returns. Also when nodes are very dense on a way it becomes hard to select said way with out zooming very far in. Clearly there's no need to systematically remove excess nodes on already imported data, but if simplifying a way makes your editing easier and doesn't reduce the detail/smoothness (clearly this is a judgement call) I say go for it. Zeke On Tue, Aug 24, 2010 at 4:14 AM, Alan Mintz <alan_mintz+...@earthlink.net<alan_mintz%2b...@earthlink.net> > wrote: > At 2010-08-19 20:24, Alan Mintz wrote: > >> I'm mapping in this area: >> http://www.openstreetmap.org/?lat=34.08242&lon=-118.639&zoom=17 >> >> Along the north side of the tertiary road (whose name is not rendered, but >> is Saddle Peak Road) is a state park polygon (Topanga State Park) imported >> from CASIL. In this small segment, the road is approximated with less than >> 70 nodes, while the park polygon segment alongside uses over 1200. I've >> noticed similar "beauty" in other data from this source and others (like the >> Bakersfield data mentioned recently on the list). >> >> Should imports make an effort to "un-smooth" such data to some extent, for >> the benefit of editing and rendering performance, storage, etc? >> > > As a test case, I used JOSM's "Simplify Way" on the ways that make up > Topanga State Park. After playing around a bit, in advanced preferences, I > set simplify-way.max-error to 0.2, which still modeled curves to maybe > single-digit meter errors, yet removed 73% of the nodes (from 9103 to 2466). > > The ways are: > 38458997 > 38459009 > 38459010 > 38459013 > 45753168 > 45753173 > 45753175 > > I'm not embarking on a mission to simplify all ways - just taking the > (short time) to do this when I'm mapping an area anyway and see it could be > of benefit. > > -- > Alan Mintz <alan_mintz+...@earthlink.net> > > > > _______________________________________________ > Talk-us mailing list > Talk-us@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-us >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
