[OSM-talk] Paper/Article about stagnation in OSM
jwhelan0112 at gmail.com
Tue Jul 31 23:08:21 UTC 2018
My background is big databases, XML, ISO standards and such like.
The report has lots of long words but doesn't seem to grasp basic concepts
OpenStreetMap to me has two primitives, nodes and ways. These can and are
combined to create areas. They have tags attached.
I honestly can't see any need for more primitives.
To me OSM is the database. It's a very big database but its just a
collection of data. Everything else just accesses it either to put data in
or take data out. It's not stagnant by any means. iD for example has been
updated quite recently.
People are inventing new tags everyday.
Web 2.0 is nice but the processing demands and therefore costs are very
high. Instant tile refresh if someone makes a change to the underlining
data? It's not practical on a very large database on a shoe string.
XML has one very nice thing going for it. Stability, make a change and the
rest of the system carries on working. The changes are ignored until the
software is modified to accept the new data. Changing the data format of a
file without XML is horrendous, every program that uses the data must be
updated at the same time and in a decentralised environment like OSM with
many different applications feeding it and extracting data from it the
system would crash without it and to be honest do we really know all the
software that processes OSM data?
XML is bulky but can be compressed fairly easily.
Big software projects have higher failure rates by the way. The Canadian
government payroll system Phoenix is a prime example. OSM has done well
with its approach and has done many things right.
One final point mappers aren't involved in software development. True but
there again I'm happy to catch a bus when I haven't been involved in the
construction of it. Software is best done by small teams, the larger the
team the more time you spend in communicating to other members. I think
once you get above 100 programmers the projects tend to be slower because
of the communication problems.
On 31 July 2018 at 17:49, Frederik Ramm <frederik at remote.org> wrote:
> I don't necessarily agree with all that's been written but I found
> an interesting read: "The social construction of technological stasis:
> The stagnating data structure in OpenStreetMap."
> Grossly simplified, the author tries to answer the question "why haven't
> we shipped API 0.7 yet" from a social science viewpoint.
> Frederik Ramm ## eMail frederik at remote.org ## N49°00'09" E008°23'33"
> talk mailing list
> talk at openstreetmap.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the talk