<div dir="ltr"><div dir="ltr"><div>Hi Jean-Marc,</div><div><br></div><div>Long time no see!</div><div><br></div></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le mer. 13 mai 2020 à 17:08, Jean-Marc Liotier <<a href="mailto:jm@liotier.org">jm@liotier.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 5/12/20 3:50 PM, Colin Smale wrote:<br>
</div>
<blockquote type="cite">
<div style="margin:0px;padding:0px;font-family:monospace">The role I expect of the data consumers is to
articulate how they would like to view the data (including what
attributes they are expecting), and not to dictate how that data
is stored/represented internally. Cartography, geography,
statistics etc are very different skills to data modelling and
database design.</div>
</blockquote>
<p>Indeed, technical implementations take functional requirements
into account but have many other inputs and a different class of
actors. Consumers, tell us what you want - not how to do it ! Same
as any software project...</p></div></blockquote><div>As a data consumer, telling you what I want directly often relates to how tagging is built as I consume raw osm data without filters or transformation done by any API (and that's fortunate).</div><div><br></div>"Same as any software project"</div><div class="gmail_quote">Corporate software projects can be designed to preserve silos and inefficiency due to any so-called-valid excuse of dysfunctional middle management (rude, but... change my mind)<br></div><div class="gmail_quote">OSM is a good opportunity to change practices and show some solutions that would be really hard to provide at company scale.</div><div class="gmail_quote">So, respectably no, not like any software project please.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">All the best</div><div class="gmail_quote"><br></div><div class="gmail_quote">François<br></div></div>