[OSM-dev] dev Digest, Vol 158, Issue 3

Tomas Straupis tomasstraupis at gmail.com
Wed May 16 21:22:42 UTC 2018


2018-05-16 10:01 GMT+03:00 SandorS wrote:
> The statement was not quite wise and in some aspects it is wrong. Blindly
> trusting open source solutions is not the best thing for a newcomer
> especially not for a developer. By experience I know that sometimes a hint,
> a simple warning may help a developer to change his way of thinking.
> Besides, reading someone’s complex and complicated source (like the
> generalisation related source) is not just a simple exercise. If you ever
> wrote a complex basic sw and tried to read it after several months of brake
> then you understand what is my point.

  I think there was some misunderstanding here. I only stated that
using commercial (or to be more precise - closed) software in my
opinion is not the way to go for an open project like OSM. Results of
generalisation using commercial software can be used to refine the
approach (by looking, comparing), but final software will probably be
open (and open gis software is gaining fast anyway). For example
Netherlands example of using commercial software shows that
generalisation is successfully(?) done on PARTS of data, so now we
know that we do not have to think of ways to generalise whole world at

  Open data entered by volunteers does have a higher probability of
errors, but generalisation could be just one of many ways of detecting
such errors (and so fixing them).

  Regarding other points. There are a lot of different operations done
on a lot of different types of objects in different sequences. But in
my opinion it is not "all or nothing". You can start with some
generalisation and progress with time.
  For example doing simple polygon aggregation/amalgamation is doable
now with good results but should of course be improved with proper
polygon conflict resolution methods (already described in numerous
scientific papers, f.e. "Detecting and resolving size and proximity
conflicts in the generalization of polygonal maps", Bader and Weibel
  Transport network collapsing (multi-lines to one line) can already
be done with standard PostGIS functions (buffer,
  Building simplification is already in testing stage.
  GRASS provides functionality for transport network displacement and
  And these already give good and noticeable results. Of course a lot
of other things must be done, but we have a greatest luxury - time -
there are no deadlines. This is why some operations could be
implemented with even better results than closed implementations.


More information about the dev mailing list