<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <div class="moz-cite-prefix"><br>
      On 21/11/2017 13:47, Darafei "Komяpa" Praliaskouski wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAC8Q8tLvK_ZO4nGbicpCjF+UQpVaFNr3RBZmFPysA82Kb_yrGQ@mail.gmail.com">
      <div dir="ltr"><br>
        <div class="gmail_quote">I've posted a -dev mail about reusing
          nighttime of tile rendering servers. Some likes on GitHub,
          some reviews from passer-by's, no merge, nothing about "what
          to fix to get it merged". For a year. Patience you say?
          <div><a
              href="https://github.com/openstreetmap/mod_tile/pull/152"
              moz-do-not-send="true">https://github.com/openstreetmap/mod_tile/pull/152</a>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Whilst I'm not a contributor to the repository there, I do have some
    familiarity with the code.  What you seem to be doing is
    interpreting the mod_tile repository as "part of the infrastructure
    of OpenStreetMap.org", and you seem to be viewing OpenStreetMap.org
    as an end-user Google Maps competitor, not as a "creating map data
    enabler".  I regularly use mod_tile on memory-limited machines and
    would be concerned if I was suddenly not able to process as large
    data extracts that I could previously.  I don't see any thought
    given in what you're proposing to what the knock-on effects of your
    change would be.<br>
    <br>
    <blockquote type="cite"
cite="mid:CAC8Q8tLvK_ZO4nGbicpCjF+UQpVaFNr3RBZmFPysA82Kb_yrGQ@mail.gmail.com">
      <div dir="ltr">
        <div class="gmail_quote">
          <div><br>
            /map call is technically 40x slower than it should be, but
            issue is being closed with "we are not complete idiots"
            comments. No action taken wherever.<br>
            <a
              href="https://github.com/openstreetmap/operations/issues/135"
              moz-do-not-send="true">https://github.com/openstreetmap/operations/issues/135</a>
            <br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    The second line of your issue starts "This causes hatred when
    editing something", which is not exactly helpful if you want an
    in-depth investigation of a perceived performance problem.  Despite
    this, the conversation that follows covers in detail the status of
    the problem, and a suggestion to you where you can help.  Your
    contributions there (at
    <a class="moz-txt-link-freetext" href="https://github.com/zerebubuth/openstreetmap-cgimap/issues/122">https://github.com/zerebubuth/openstreetmap-cgimap/issues/122</a> )
    stopped after a day.<br>
    <br>
    I've said elsewhere the developing things _around_ OpenStreetMap and
    with OpenStreetMap data has a surprisingly low barrier to entry -
    you just download the data and off you go; there's no API with Ts
    and Cs to negotiate.  However, _changing_ the way that the the
    project or the existing osm.org infrastructure does something will
    necessarily require a series of arguments to be made and people to
    be persuaded, and it seems to me that you haven't successfully done
    that yet, just as Yuri didn't with his approach to mechanical
    editing, which led indirectly to the WeeklyOSM article and the
    thread that this one developed from.<br>
    <br>
    Where there are competing requirements (and there are always
    competing requirements) you can't always expect everyone to agree
    the your view of the requirements is the "most valid" one - see for
    example
    <a class="moz-txt-link-freetext" href="https://github.com/gravitystorm/openstreetmap-carto/issues/765">https://github.com/gravitystorm/openstreetmap-carto/issues/765</a> .  I
    took the hint from that to create something else with OSM data that
    was (for my purposes) better; perhaps you could do the same?<br>
    <br>
    Best Regards,<br>
    <br>
    Andy<br>
    <br>
  </body>
</html>