<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Rob,<br>
    <br>
    excellent, now we are getting into technical discussion.<br>
    <br>
    I did not say that rasdaman is the best in the universe under all
    possible constellations, but we do have both theoretical
    considerations and practical results that suggest that rasdaman
    performs outstandingly well on n-D arrays.<br>
    <br>
    Your offer to participate is very welcome, and timely. We have
    established the RDA Array Database Assessment WG, and here we need
    as many volunteers as possible to undertake this huge endeavour of
    getting reproducible knowledge about the state of the art, best
    practices, etc. Here is the page:<br>
    <a class="moz-txt-link-freetext" href="https://www.rd-alliance.org/groups/array-database-working-group.html">https://www.rd-alliance.org/groups/array-database-working-group.html</a><br>
    <br>
    Participation is at no cost and open, same the results. Just
    register yourself with RDA and let me know so that we canplan
    contributions.<br>
    <br>
    Looking forward to welcoming you on board,<br>
    Peter<br>
    <br>
    <br>
    <br>
    <div class="moz-cite-prefix">On 05/15/2016 06:10 PM, Rob Emanuele
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAFPWJ6d8+W3G-8J=wq6EwRgi-E1CzzLg=jg90NLRSEouJG3UWA@mail.gmail.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
      <div dir="ltr">
        <div>Apologies for veering off topic.</div>
        <div><br>
        </div>
        Hi Peter,
        <div><br>
        </div>
        <div>Thanks for citing your resources. Unfortunately I can't
          access the one paper, since the only version I could find is
          behind a paywall, and the bar chart you attached gives very
          little information; from these I cannot understand the
          methodology or results. If you have more details I would be
          happy to look further into this.</div>
        <div><br>
        </div>
        <div>My concern is with your wide sweeping statements, and the
          implication that rasdaman has been scientifically verified to
          be more performant than any other system in all cases. This to
          me feels hyperbolically similar to measuring that a bowling
          ball falls faster than a piece of paper when dropped from the
          roof of a building and concluding that trees are the objects
          which fall most slowly towards the earth.</div>
        <div><br>
        </div>
        <div>For instance, I have doubts that those who had conducted
          the quoted performance benchmarks set up the Apache Spark
          system in a way that represents all potential configurations.
          I work on the GeoTrellis project [1], which adds raster
          processing capabilities to Spark. I could for instance imagine
          a system where raster data was stored in Accumulo, indexed by
          GeoTrellis, and processed through Spark, which is very fast
          under many query types. I won't make any assumptions on how
          fast as compared to other systems, and it's very possible that
          rasdaman will beat out such a system in a set of query types,
          or perhaps all queries. However, it is my opinion that until
          the two systems were compared in such a way that everyone
          agreed on on the methodology and the results, casually using
          the "fact" that one system is "way faster" than the other
          system, and that one beats the other "in all benchmarks" as an
          argument for some treatment from OSGeo (or for any other
          purpose) deserves to be called into question, which I am doing
          here.</div>
        <div><br>
        </div>
        <div>I'd be happy to collaborate to develop, out in the open and
          in front of any paywalls, an objective system of measuring
          performance between systems. At which point in time we could
          make proclamations like, "[whichever framework], under [these
          specific query types], running on [however many nodes,
          whatever type of hardware], storing [this amount] of [this
          type of data], performs better than [some other framework]
          under the same conditions". Until then, I object to your very
          broad statements of superiority.</div>
        <div><br>
        </div>
        <div>Regards,</div>
        <div>Rob</div>
        <div><br>
        </div>
        <div>[1] <a moz-do-not-send="true"
            href="https://github.com/geotrellis/geotrellis">https://github.com/geotrellis/geotrellis</a></div>
      </div>
      <div class="gmail_extra"><br>
        <div class="gmail_quote">On Sun, May 15, 2016 at 9:30 AM, Moritz
          Lennert <span dir="ltr"><<a moz-do-not-send="true"
              href="mailto:mlennert@club.worldonline.be" target="_blank">mlennert@club.worldonline.be</a>></span>
          wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex"><span
              class="">On 15/05/16 14:40, Marco Afonso wrote:<br>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                Hi Anita,<br>
                <br>
                Aha! So there is a ponderation weight on software
                quality evaluation AND<br>
                project organization evaluation.<br>
                <br>
                So you can exclude an open source software with high
                quality if their<br>
                organization evaluation is low.<br>
                <br>
                For me that seems wrong. A software on a public
                repository is only<br>
                limited by it's licence terms, or unlimited at all. :)<br>
              </blockquote>
              <br>
            </span>
            But the discussion is not about whether the software should
            be in a public repository or not, or what the licence term
            should be. The discussion is about what the meaning of the
            "OSGeo project" label is.<br>
            <br>
            I don't think anyone has questioned the quality of the
            software, here. However, one of the aims of labeling a
            project an OSGeo project is to give a certain level of
            guarantee to potential users that this software _project_
            respects a series of criteria that are considered important
            to ensure a long-term sustainability of that project.
            Putting one person's name in the statutes of a project and
            designating that person as the one who has ultimate decision
            rights (even if these decisions are always based on quality
            criteria), leaves the question of what would happen if that
            person lands under the proverbial bus.<br>
            <br>
            A more collective governance structure is seen by many as
            more sustainable in the long run. Similar debates have gone
            on for ages in Debian, for example, about team-based
            maintaining of packages vs individual maintainers.<br>
            <br>
            What I personally haven't really understood, yet, is what
            the rasdaman community is really afraid of. If the community
            works as well as described, why would the creation of a
            PSC-like structure create such problems ?<span
              class="HOEnZb"><font color="#888888"><br>
                <br>
                Moritz</font></span>
            <div class="HOEnZb">
              <div class="h5"><br>
                _______________________________________________<br>
                Discuss mailing list<br>
                <a moz-do-not-send="true"
                  href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
                <a moz-do-not-send="true"
                  href="http://lists.osgeo.org/mailman/listinfo/discuss"
                  rel="noreferrer" target="_blank">http://lists.osgeo.org/mailman/listinfo/discuss</a></div>
            </div>
          </blockquote>
        </div>
        <br>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
Discuss mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Discuss@lists.osgeo.org">Discuss@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/discuss">http://lists.osgeo.org/mailman/listinfo/discuss</a></pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="80">-- 
Dr. Peter Baumann
 - Professor of Computer Science, Jacobs University Bremen
   <a class="moz-txt-link-abbreviated" href="http://www.faculty.jacobs-university.de/pbaumann">www.faculty.jacobs-university.de/pbaumann</a>
   mail: <a class="moz-txt-link-abbreviated" href="mailto:p.baumann@jacobs-university.de">p.baumann@jacobs-university.de</a>
   tel: +49-421-200-3178, fax: +49-421-200-493178
 - Executive Director, rasdaman GmbH Bremen (HRB 26793)
   <a class="moz-txt-link-abbreviated" href="http://www.rasdaman.com">www.rasdaman.com</a>, mail: <a class="moz-txt-link-abbreviated" href="mailto:baumann@rasdaman.com">baumann@rasdaman.com</a>
   tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)


</pre>
  </body>
</html>