[OSM-dev] changes in coastline are not rendered

Martin Koppenhoefer dieterdreist at gmail.com
Thu Feb 11 09:02:53 UTC 2016


2016-02-11 8:11 GMT+01:00 Stephan Knauss <osm at stephans-server.de>:

> This is the reason I suggest against using the simplify functionality.
> Just because some detail level is not to your liking you sort of "tell off"
> those mappers who invested a lot of time putting that details in the first
> place when deleting it.
>
> There are special situations where it can be useful, but in case of
> "hand-drawn" data mostly it is fine to go forward with a handful of
> additional nodes. And don't worry about the size of the data. Those few
> nodes don't do much harm (we have 4 billions already).
>


+1, for the detail I suggest to keep whatever is hand drawn and is a
noticable improvement. To expand on this: If a piece of road is straight,
you shouldn't have more than one node at each end (as long as there aren't
any junctions or other reasons like changing attributes or features on the
road that require additional nodes), but when there are curves you can
obviously add endless nodes to approximate to the shape, and it will always
be smoother. In these cases I'd go with what the mapper has decided to put
and not simplify it automatically (as long as it is an improvement,
sometimes mappers draw many nodes so close but unprecise that the road gets
zigzag curvy because of missing precision, where it actually should be
smooth). In case of overnoding I suggest to improve the geometry manually,
because the douglas peucker algorithm that simplifies only by distance will
introduce problems in sharp curves/turns and leads to a loss of detail.

FWIW, any data consumer that needs simplified geometry can automatically
apply the algorithm and reduce the nodes by himself if that is what he
needs. Reducing is always easier, but enhancing detail automatically is not
possible.

Cheers,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20160211/439cb210/attachment.html>


More information about the dev mailing list