<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">My background is big databases, XML, ISO standards and such like.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">The report has lots of long words but doesn't seem to grasp basic concepts well.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">OpenStreetMap to me has two primitives, nodes and ways. These can and are combined to create areas. They have tags attached.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">I honestly can't see any need for more primitives.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">People are inventing new tags everyday.<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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?<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">XML is bulky but can be compressed fairly easily.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Big software projects have higher failure rates by the way. The Canadian government payroll system<font size="2"><span style="font-weight:normal"> Phoenix is a prime example. OSM has done well with its approach and has done many things right.</span></font>
</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small">Cheerio John<br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif;font-size:small"> <br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 31 July 2018 at 17:49, Frederik Ramm <span dir="ltr"><<a href="mailto:frederik@remote.org" target="_blank">frederik@remote.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I don't necessarily agree with all that's been written but I found<br>
<br>
<a href="http://journals.sagepub.com/doi/10.1177/2053951718790591" rel="noreferrer" target="_blank">http://journals.sagepub.com/<wbr>doi/10.1177/2053951718790591</a><br>
<br>
an interesting read: "The social construction of technological stasis:<br>
The stagnating data structure in OpenStreetMap."<br>
<br>
Grossly simplified, the author tries to answer the question "why haven't<br>
we shipped API 0.7 yet" from a social science viewpoint.<br>
<br>
Bye<br>
<span class="HOEnZb"><font color="#888888">Frederik<br>
<br>
-- <br>
Frederik Ramm ## eMail <a href="mailto:frederik@remote.org">frederik@remote.org</a> ## N49°00'09" E008°23'33"<br>
<br>
______________________________<wbr>_________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.<wbr>org/listinfo/talk</a><br>
</font></span></blockquote></div><br></div>