OpenStreetMap

Nakaner's Diary

Recent diary entries

Seit Samstag können die stimmberechtigten Mitglieder der OpenStreetMap Foundation über drei der sieben Vorstandsposten entscheiden. Informationen zu den Kandidaten findet ihr im OSM-Wiki.

Wahlverfahren

Gewählt wird nach dem Single-Transferable-Vote-Verfahren. Das heißt, die Wähler ordnen die Kandidaten nach ihrer persönlichen Präferenz. In jeder Auszählungsrunde wird geprüft, welcher Kandidat schon mehr Stimmen hat, als anhand des Quorums erforderlich wären. Falls es einen gibt, gilt er direkt als gewählt. Falls kein Kandidat genügend Stimmen hat, wird der Kandidat mit den wenigsten Stimmen gestrichen und die Stimmen seiner Wähler auf die Zweitstimmen verteilt. Es lohnt sich nicht entgegen der persönlichen Präferenz abzustimmen, weil der Vorzugskandidat geringe Chancen hat, wie es etwa beim Mehrheitswahlrecht oder einem Verhältniswahlrecht mit Fünf-Prozent-Hürde der Fall wäre. Es hat auch keinen Nutzen, die euch unliebsten Kandidaten gar nicht auf dem Stimmzettel einzutragen.

Bei der OSMF wählen die Mitglieder keine Personen in bestimmte Ämter (Vorsitzender, Stellvertreter, Finanzvorstand, Schriftführer, Beisitzer), sondern nur Personen in das “Board”. Die Zuständigkeiten werden in der ersten Sitzung festgelegt.

Der Vorstand ist kein Parlament, auch wenn mittlerweile viele Entscheidungen nur mehrheitlich, nicht einstimmig getroffen werden. Die Vorstände sind aufgrund des britischen Companies Act nicht ihrem Gewissen oder ihrem Wählerklientel verpflichtet, sondern dem Wohle des “Unternehmens”. In der Praxis müssen die Personen zusammenarbeiten können. Einzelne Vorstände, deren Interessensgebiete wenig mit den tatsächlichen Bedürfnissen und Nöten der OSMF zu tun haben, behindern die produktive Arbeit. Zudem müssen sie müssen dazu fähig sein, ehrenamtlich ein nicht geringes Zeitbudget auf die Vorstandsarbeit zu verwenden.

Meiner Meinung nach sind folgende Themen in den kommenden Jahren für die OSMF von Bedeutung (unsortierte Liste):

  • Sicherstellung der Finanzierung der laufenden Ausgaben für den Betrieb (Serverbetrieb und der fest angestellte Site Reliability Engineer)
  • Fokussierung auf das Wichtige, keine weiteren Ausgaben, die für den Betrieb des Projekts nicht essentiell sind
  • Umgang mit der Overture Foundation (Konkurrenzproblem, Lizenzfragen, Öffentlichkeitsarbeit)
  • Umzug der Foundation in die Europäische Union (erleichtet Finanzgeschäfte und Bürokratie, ermöglicht die Anspruchnahme des Datenbankschutzrechts und somit die Durchsetzung der ODbL in der EU)
  • entsprechend Bedarf: ausreichende Reaktionsfähigkeit gegen Vandalismus, der in Form und Menge relevant ist

Als “erledigt” betrachte ich:

  • Schutzmechanismen gegen feindliche Übernahmen: Neue normale und assoziierte Mitglieder müssen per OSM-Edits oder mittels Begründung ihre Berechtigung für eine Mitgliedschaft nachweisen.
  • Keine Moderation und unzureichende Regeln in Bezug auf das Verhalten auf den Diskussionskanälen (das Code-of-Conduct-Thema)

Die Kandidaten

Fünf Kandidaten können gewählt werden, drei Posten gibt es zu vergeben. Alle haben einen Manifest veröffentlicht, in dem sie auch ihren OSM-Bezug darlegen (oder diesbezüglich schmalllippig sind, weil er gering ist). Zudem konnte die Community vor ein paar Wochen Vorschläge für Fragen einreichen, die im Auftrag des Vorstands zu neun offiziellen Fragen zusammengefasst wurden. Auf die Inhalte der Manifestos und Antworten gehe ich hier nicht ein, dazu sei auf die jeweiligen Texte verwiesen. Schwerpunkt dieses Texts sind die Sachen, die nicht direkt in den Manifestos und Antworten stehen.

Guillaume Rischard (Nickname: Stereo) ist ein altbekanntes Gesicht und sitzt seit ein paar Jahren im Vorstand. Er war in der Vergangenheit für die Finanzen zuständig und musste mehrfach mit der Foundation die Bank wechseln. Derzeit ist er Vorsitzender. Wer ihn wählt, trifft keine falsche Wahl.

Roland Olbricht (Nickname: drolbr) ist seit zwei Jahren im Amt und derzeit Finanzvorstand. Wer Wert auf Kontinuität im Vorstand legt, sollte ihn auf die vorderen Plätze setzen.

Włodzimierz Bartczak (Nickname: Christoffs) kandidiert nicht zum ersten Mal, dieses Mal hat er mangels Konkurrenz Chancen, gewählt zu werden. OSM-Bezug ist klar vorhanden, da genügt ein Blick auf seine OSM-Beiträge als Mapper.

Daniela Waltersdorfer Jimenez aus den USA kandidiert auch nicht zum ersten Mal. Sie ist die Kandidatin mit dem geringsten OSM-Bezug. Ihre Mappingtage in den letzten 365 Tagen kann man an einer Hand abzählen. Während die drei vorgenannten alle in ihrem Manifest auf die aktuellen Probleme, Nöte und Aufgaben der OSMF eingehen, widmet sie sich in ihrem Manifest dem Thema Community und Diversity. Das Thema sollte mit der neuen Etiquette Guideline und dem Moderatorenteam für die großen Mailinglisten und das Forum eigentlich erledigt sein. Dessen Existenz erwähnt sie nicht. Nach Lektüre ihrer Antworten auf den Fragenkatalog bestehen für mich große Zweifel, ob sie sich in der Vergangenheit ausreichend mit der Organisation beschäftigt hat, deren Vorstand sie sein möchte. Ich befürchte, dass sie mit ihrem Steckenpferd die übrigen Vorstände ablenkt.

Ivo Reano ist langjähriger Mapper und hat die kürzesten Texte eingereicht. Das lässt mich sehr an seinem verfügbaren Zeitbudget zweifeln.

Meine persönliche Präferenz

Meine persönliche Rangfolge ist:

  • Guillaume oder Roland
  • Roland oder Guillaume
  • Daniela
  • Włodzimierz Bartczak
  • Ivo

Tatsächlich habe ich Daniela auf Platz 3 gesetzt, obwohl ich ihr oben die Eignung abgesprochen habe. Sie wäre unabhängig vom Wahlergebnis die einzige US-Amerikanerin im Vorstand. Die Gerüchteküche meint, dass das beim Fundraising (Mitteleinwerbung) nützlich sein könnte.

Włodzimierz möchte laut mir vorliegenden Informationen nächstes Jahr in Łodz (Polen) eine State of the Map Europe ausrichten, diese aber von TomTom organisieren lassen. Für mich ist das, weil es dort eigentlich ein Local Chapter gibt, ein Pakt mit dem Teufel, denn der Teufel ist auch an Overture Maps beteiligt.

Ivos magere Textbeiträge qualifizieren ihn für den letzten Platz.

As written on the OSMF-Talk mailing list, I am proposing a resolution for the upcoming Annual General Meeting of the OSM Foundation on 12 December 2020. In order to get the proposal up for voting, I need support by at least 5 % of all members, i.e. about 80 members.

You can find the text and rationale in the OSMF-Talk archives.

If you want to support this proposal, please comment this diary entry with the openstreetmap.org account which is tied to your Foundation membership. If your membership record does not contain your username (or you are not sure), please send an email to osmf-agm20-sustainable@michreichert.de with your user name. Please use the email you use for your Foundation membership.

I will email the list of all supporters to the board after 4 November 2020 (UTC).

Supporting the proposal in this step does not mean that you will or have to vote in favour of it.

I would like to ask you to use the comment section of this diary entry only for the purpose outline above. Please use the OSMF-Talk mailing list to comment on the content of proposal instead.

A new evening is a new evening to play around with SQL. This is part 2 of my series on the number of messages and the most active authors on the public mailing lists hosted a lists.openstreetmap.org. Part 1 was published on 2 December 2018.

Here are my latest queries and their results:

Numbers of messages per year

SELECT EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count
  FROM mails
  GROUP BY year
  ORDER BY year;

 year | message_count 
------+---------------
 2004 |           180
 2005 |          2343
 2006 |         10481
 2007 |         34059
 2008 |         70120
 2009 |        102357
 2010 |         96569
 2011 |         66484
 2012 |         69943
 2013 |         67428
 2014 |         55866
 2015 |         52484
 2016 |         38914
 2017 |         36815
 2018 |         34271

Numbers of messages per mailing list and year (2004–2008)

Mailing lists with less than 50 messages in all of these years are not shown in the following table. Rows are sorted by number of messages in their first year.

WITH
  postings_years AS (
    SELECT list_id, EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count                                                       
      FROM mails          
      GROUP BY list_id, year     
  ), 
  list_ids AS (
    SELECT list_id        
      FROM mails          
      GROUP BY list_id    
  )
SELECT *
  FROM (
    SELECT
        l.list_id AS list_id,
        y2004.message_count AS "2004",  
        y2005.message_count AS "2005",  
        y2006.message_count AS "2006",  
        y2007.message_count AS "2007",  
        y2008.message_count AS "2008"
      FROM list_ids AS l  
      LEFT OUTER JOIN postings_years AS y2004
        ON (l.list_id = y2004.list_id AND y2004.year = 2004)                                     
      LEFT OUTER JOIN postings_years AS y2005
        ON (l.list_id = y2005.list_id AND y2005.year = 2005)                                     
      LEFT OUTER JOIN postings_years AS y2006
        ON (l.list_id = y2006.list_id AND y2006.year = 2006)                                     
      LEFT OUTER JOIN postings_years AS y2007
        ON (l.list_id = y2007.list_id AND y2007.year = 2007)                                     
      LEFT OUTER JOIN postings_years AS y2008
        ON (l.list_id = y2008.list_id AND y2008.year = 2008)
      ORDER BY
        y2004.message_count DESC NULLS LAST,
        y2005.message_count DESC NULLS LAST,
        y2006.message_count DESC NULLS LAST,
        y2007.message_count DESC NULLS LAST,
        y2008.message_count DESC NULLS LAST,
        list_id
    ) AS stats
WHERE "2004" >= 50
  OR "2005" >= 50
  OR "2006" >= 50
  OR "2007" >= 50
  OR "2008" >= 50;

      list_id      | 2004 | 2005 | 2006 | 2007  | 2008  
-------------------+------+------+------+-------+-------
 talk              |  180 | 1771 | 7772 | 11656 | 11310
 dev               |      |  572 | 2119 |  5625 |  4979
 talk-gb           |      |      |  239 |  1952 |  1524
 talk-de           |      |      |  235 |  5953 | 26392
 legal-talk        |      |      |   47 |   452 |  1285
 talk-fr           |      |      |   42 |   763 |  4579
 talk-it           |      |      |   27 |   322 |  4381
 talk-nl           |      |      |      |  4107 |  3873
 talk-es           |      |      |      |   888 |  1473
 josm-dev          |      |      |      |   597 |  1689
 talk-cz           |      |      |      |   590 |  1727
 talk-au           |      |      |      |   487 |   771
 talk-za           |      |      |      |   184 |   104
 routing           |      |      |      |   162 |   432
 talk-tr           |      |      |      |   103 |    26
 party             |      |      |      |    69 |     7
 talk-ie           |      |      |      |    54 |   192
 talk-fi           |      |      |      |    52 |    30
 talk-se           |      |      |      |    19 |    58
 talk-us           |      |      |      |    13 |   619
 merkaartor        |      |      |      |       |  1001
 talk-ja           |      |      |      |       |   897
 talk-be           |      |      |      |       |   612
 talk-ca           |      |      |      |       |   471
 talk-at           |      |      |      |       |   441
 talk-ph           |      |      |      |       |   261
 talk-in           |      |      |      |       |   220
 talk-ar           |      |      |      |       |   181
 talk-gb-midanglia |      |      |      |       |   116
 legal-general     |      |      |      |       |   111
 talk-co           |      |      |      |       |   100
 talk-il           |      |      |      |       |    69
 talk-is           |      |      |      |       |    69
(33 rows)

Number of messages per mailing list and year (2009–2013)

Mailing lists with less than 50 messages in all of these years are not shown in the following table. Rows are sorted by number of messages in their first year.

WITH
  postings_years AS (
    SELECT list_id, EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count
      FROM mails
      GROUP BY list_id, year
  ),
  list_ids AS (
    SELECT list_id
      FROM mails
      GROUP BY list_id
  )
SELECT *
  FROM (
    SELECT
        l.list_id AS list_id,
        y2009.message_count AS "2009",
        y2010.message_count AS "2010",
        y2011.message_count AS "2011",
        y2012.message_count AS "2012",
        y2013.message_count AS "2013"
      FROM list_ids AS l
      LEFT OUTER JOIN postings_years AS y2009 ON (l.list_id = y2009.list_id AND y2009.year = 2009)
      LEFT OUTER JOIN postings_years AS y2010 ON (l.list_id = y2010.list_id AND y2010.year = 2010)
      LEFT OUTER JOIN postings_years AS y2011 ON (l.list_id = y2011.list_id AND y2011.year = 2011)
      LEFT OUTER JOIN postings_years AS y2012 ON (l.list_id = y2012.list_id AND y2012.year = 2012)
      LEFT OUTER JOIN postings_years AS y2013 ON (l.list_id = y2013.list_id AND y2013.year = 2013)
      ORDER BY
        y2009.message_count DESC NULLS LAST,
        y2010.message_count DESC NULLS LAST,
        y2011.message_count DESC NULLS LAST,
        y2012.message_count DESC NULLS LAST,
        y2013.message_count DESC NULLS LAST,
        list_id
    ) AS stats
WHERE "2009" >= 50
  OR "2010" >= 50
  OR "2011" >= 50
  OR "2012" >= 50
  OR "2013" >= 50;

        list_id        | 2009  | 2010  | 2011  | 2012  | 2013  
-----------------------+-------+-------+-------+-------+-------
 talk-de               | 28125 | 20392 | 10276 |  8758 |  6088
 talk                  | 13570 |  9296 |  5724 |  4095 |  3336
 talk-fr               | 11994 | 12072 |  9541 | 13755 | 12880
 talk-it               |  8267 |  7896 |  5182 |  6285 |  8046
 dev                   |  4720 |  3398 |  2613 |  2235 |  1236
 talk-au               |  3515 |  2617 |  1291 |  1019 |   450
 talk-gb               |  3358 |  3428 |  2027 |  1669 |  1386
 talk-nl               |  2511 |  1824 |  1236 |   721 |   328
 talk-us               |  1942 |  2436 |  2101 |  2885 |  2385
 talk-es               |  1892 |  2281 |  2121 |  2265 |  1063
 talk-cz               |  1729 |  2019 |   890 |  1064 |   888
 josm-dev              |  1587 |  1217 |   792 |   464 |   428
 talk-ca               |  1539 |  1511 |   832 |   895 |   659
 talk-ph               |  1345 |  1185 |   835 |   584 |   639
 talk-lv               |  1304 |   967 |  1724 |   985 |   543
 legal-talk            |  1291 |  2468 |  1226 |   510 |   310
 talk-at               |  1278 |   939 |   934 |  1640 |   990
 talk-ja               |  1224 |  1844 |  1667 |  1222 |   917
 tagging               |  1011 |  5118 |  2900 |  3368 |  3551
 talk-ro               |   944 |   786 |   292 |   238 |   606
 merkaartor            |   942 |  1022 |   158 |    94 |    20
 talk-br               |   901 |   971 |   480 |   671 |  1728
 talk-transit          |   858 |   391 |   290 |    50 |    83
 talk-in               |   824 |   355 |    92 |   210 |   177
 talk-hr               |   553 |   478 |   316 |   344 |   285
 imports               |   440 |   280 |   504 |   548 |   848
 osmosis-dev           |   418 |   446 |   317 |   249 |   140
 talk-be               |   416 |   674 |   733 |   921 |  2098
 talk-gb-westmidlands  |   364 |   261 |   237 |   300 |   229
 talk-co               |   363 |  1148 |   964 |   500 |   321
 talk-dk               |   357 |   708 |  1055 |  1063 |   411
 talk-is               |   269 |   207 |    65 |   145 |    92
 talk-za               |   257 |   189 |    78 |    82 |   176
 routing               |   247 |   233 |    78 |    76 |    14
 talk-ee               |   228 |   548 |   357 |   199 |   154
 talk-se               |   211 |   411 |   414 |   676 |   572
 talk-ar               |   211 |   244 |   219 |   155 |   289
 talk-lt               |   148 |   484 |   285 |   251 |   334
 talk-fr-bzh           |   117 |   114 |   290 |   279 |   194
 talk-gb-midanglia     |   114 |    48 |    62 |    16 |     8
 talk-cu               |   108 |    34 |       |    11 |     3
 talk-si               |   107 |    55 |    26 |    34 |     2
 talk-gb-oxoncotswolds |    87 |    20 |   101 |     8 |    85
 local-chapters        |    65 |   118 |    20 |       |    47
 geocoding             |    65 |    77 |    48 |   423 |   430
 talk-ie               |    61 |    50 |    64 |    26 |    44
 moderation            |    59 |    15 |       |       |      
 accessibility         |    55 |   101 |    55 |    75 |      
 talk-vi               |    54 |     1 |     1 |     7 |      
 potlatch-dev          |    51 |   326 |   984 |   540 |    79
 talk-cl               |    33 |   857 |   120 |    83 |    36
 talk-ko               |    21 |    34 |    11 |    67 |    11
 talk-pt               |    14 |    70 |   232 |   171 |   178
 talk-tr               |    12 |    18 |    21 |    38 |    64
 talk-pe               |     3 |    65 |    53 |   127 |    40
 hot                   |       |   456 |   861 |  1179 |  1787
 talk-ht               |       |   347 |    64 |   183 |   337
 talk-it-fvg           |       |   206 |    75 |    66 |   180
 strategic             |       |   185 |   398 |    14 |      
 dev-fr                |       |   140 |   480 |   821 |   449
 mapcss                |       |   134 |   116 |    61 |    65
 talk-ve               |       |    86 |   255 |   226 |    19
 talk-tw               |       |    53 |   112 |   467 |   412
 talk-rs               |       |    30 |   199 |    71 |     1
 talk-uy               |       |    12 |    17 |    24 |    68
 talk-it-piemonte      |       |       |   281 |   143 |    47
 rails-dev             |       |       |   187 |  1408 |  3458
 taginfo-dev           |       |       |    74 |    52 |    59
 talk-id               |       |       |    70 |    64 |    21
 talk-it-bici          |       |       |    54 |    47 |      
 talk-it-lazio         |       |       |    49 |    36 |   201
 talk-it-trentino      |       |       |    33 |   133 |   323
 talk-lu               |       |       |    33 |    59 |    16
 talk-np               |       |       |    14 |   163 |    31
 talk-it-liguria       |       |       |    13 |   513 |   153
 talk-pl               |       |       |     7 |   449 |   346
 rebuild               |       |       |       |   353 |      
 historic              |       |       |       |    72 |   265
 talk-sn               |       |       |       |    36 |   152
 talk-ni               |       |       |       |    15 |   310
 talk-baltics          |       |       |       |     5 |    91
 sotm-asia             |       |       |       |     4 |    86
 talk-mx               |       |       |       |     2 |    57
 tile-serving          |       |       |       |       |   778
 imports-us            |       |       |       |       |   481
 osrm-talk             |       |       |       |       |   359
 talk-cat              |       |       |       |       |   230
 diversity-talk        |       |       |       |       |   130
 talk-us-nps           |       |       |       |       |   106
 talk-it-southtyrol    |       |       |       |       |    69
 talk-it-sardinia      |       |       |       |       |    61
 talk-ke               |       |       |       |       |    61
(92 rows)

Some mailing lists changed their focus or became unnessary after some time. For example, the legal-talk mailing list became a bit more quiet after the license change in mid 2012 was over. The “rebuild” mailing list had the only purpose to discuss the decisions implemented in the Redaction Bot.

Number of messages per mailing list and year (2014 to November 2018)

Mailing lists with less than 50 messages in all of these years are not shown in the following table. Rows are sorted alphabetically by the ID of the mailing list.

WITH
  postings_years AS (
    SELECT list_id, EXTRACT(YEAR FROM "date") AS year, COUNT(1) AS message_count
      FROM mails
      GROUP BY list_id, year
  ),
  list_ids AS (
    SELECT list_id
      FROM mails
      GROUP BY list_id
  )
SELECT *
  FROM (
    SELECT
        l.list_id AS list_id,
        y2014.message_count AS "2014",
        y2015.message_count AS "2015",
        y2016.message_count AS "2016",
        y2017.message_count AS "2017",
        y2018.message_count AS "2018"
      FROM list_ids AS l
      LEFT OUTER JOIN postings_years AS y2014 ON (l.list_id = y2014.list_id AND y2014.year = 2014)
      LEFT OUTER JOIN postings_years AS y2015 ON (l.list_id = y2015.list_id AND y2015.year = 2015)
      LEFT OUTER JOIN postings_years AS y2016 ON (l.list_id = y2016.list_id AND y2016.year = 2016)
      LEFT OUTER JOIN postings_years AS y2017 ON (l.list_id = y2017.list_id AND y2017.year = 2017)
      LEFT OUTER JOIN postings_years AS y2018 ON (l.list_id = y2018.list_id AND y2018.year = 2018)
      ORDER BY
        list_id
    ) AS stats
WHERE "2014" >= 50
  OR "2015" >= 50
  OR "2016" >= 50
  OR "2017" >= 50
  OR "2018" >= 50;

        list_id        | 2014 | 2015 | 2016 | 2017 | 2018 
-----------------------+------+------+------+------+------
 dev                   |  596 |  758 |  633 |  393 |  390
 dev-fr                |  365 |  144 |   74 |   54 |   14
 dev-italia            |   90 |   16 |  165 |   11 |    5
 diversity-talk        |  118 |    4 |      |    5 |  100
 geocoding             |  318 |  300 |  104 |   57 |   29
 historic              |  205 |  380 |   55 |   83 |   59
 hot                   | 2669 | 3729 | 2088 | 1272 |  503
 hot-francophone       |  305 |  497 |  182 |  123 |  107
 imports               |  914 |  604 |  518 |  564 |  515
 imports-us            |  154 |   90 |   47 |   12 |   52
 josm-dev              |  288 |  437 |  172 |  157 |  217
 learnosm-coord        |   50 |   57 |    4 |      |     
 legal-talk            |  367 |  276 |  197 |   74 |   29
 osmf-membership       |    2 |   59 |      |      |     
 osmosis-dev           |   23 |   89 |   35 |   19 |   19
 osrm-talk             |  343 |  345 |  293 |  179 |  156
 potlatch-dev          |   14 |   22 |    2 |   71 |   12
 rails-dev             | 1309 | 1783 | 1781 | 2232 | 2494
 tagging               | 4685 | 7217 | 2803 | 3734 | 6602
 talk                  | 2814 | 3584 | 1975 | 2668 | 1778
 talk-africa           |      |    1 |   16 |  100 |  114
 talk-ar               |  228 |   77 |    4 |   11 |     
 talk-at               |  851 |  938 |  596 |  334 |  729
 talk-au               |  248 |  279 |  370 |  416 |  592
 talk-be               | 1119 | 1569 | 1234 |  837 |  260
 talk-bf               |   84 |   45 |   27 |   18 |    1
 talk-bj               |    3 |    5 |   26 |   64 |    5
 talk-blr              |    3 |   52 |      |      |     
 talk-bo               |   24 |   32 |  137 |  153 |  210
 talk-br               | 4412 | 1809 |  730 |  461 |  189
 talk-ca               |  370 |  311 |  906 |  611 |  679
 talk-cat              |  368 |  374 |   83 |   74 |   45
 talk-cl               |  106 |  110 |  165 |  159 |   83
 talk-cm               |   31 |    8 |    5 |   41 |   50
 talk-co               |  200 |  268 |  264 |  128 |   55
 talk-cu               |    1 |   13 |  131 |   42 |   35
 talk-cz               | 2290 | 1720 | 2594 | 2490 | 2140
 talk-de               | 3615 | 2306 | 1335 |  764 | 1138
 talk-dk               |  359 |  415 |  299 |  156 |  212
 talk-es               |  786 |  762 | 1121 |  814 |  856
 talk-fr               | 8479 | 5082 | 3690 | 4110 | 4008
 talk-fr-bzh           |  399 |  332 |  157 |  153 |  169
 talk-gb               | 1300 | 1136 | 1524 | 1390 | 1151
 talk-gb-westmidlands  |  262 |  161 |  123 |  180 |   65
 talk-gh               |    1 |   44 |   30 |   77 |   74
 talk-hr               |  238 |  164 |   35 |   32 |   65
 talk-ht               |  144 |   62 |  131 |   72 |   46
 talk-ie               |  352 |  481 |  297 |  298 |  159
 talk-in               |  125 |  362 |  271 |  275 |  189
 talk-it               | 5730 | 4646 | 5645 | 4843 | 3675
 talk-it-cai           |      |      |      |  336 |  173
 talk-it-fvg           |  139 |  219 |  269 |  236 |   96
 talk-it-lazio         |   64 |   23 |   47 |  231 |   98
 talk-it-liguria       |   73 |   19 |   12 |   10 |    2
 talk-it-piemonte      |  118 |   49 |   17 |   73 |  113
 talk-it-sardinia      |  110 |   12 |   28 |      |     
 talk-it-southtyrol    |   69 |   10 |      |    2 |    1
 talk-it-trentino      |  163 |  159 |  277 |   71 |   68
 talk-ja               |  635 |  543 |  356 |  378 |  370
 talk-ko               |   26 |   30 |    5 |   97 |   36
 talk-latam            |  165 |  235 |  167 |  119 |   70
 talk-lt               |   81 |  122 |  215 |  163 |   86
 talk-lv               |  153 |  132 |   57 |   63 |   28
 talk-mg               |      |   68 |   20 |   28 |   46
 talk-ml               |    9 |  101 |   33 |   29 |    4
 talk-mx               |  139 |  252 |  127 |   79 |   53
 talk-ni               |  169 |  113 |  125 |   59 |   29
 talk-nl               |  417 |  199 |  133 |   53 |   33
 talk-pe               |   71 |  187 |  137 |   40 |   12
 talk-ph               |  547 |  356 |  177 |  155 |  117
 talk-pl               |  726 |  614 |  531 |   74 |   98
 talk-pr               |  142 |   92 |   53 |   29 |    4
 talk-pt               |  372 |  190 |  110 |  113 |   71
 talk-ro               |  204 |  134 |   39 |    2 |    3
 talk-scotland         |   26 |   69 |   42 |   96 |   39
 talk-se               |  230 |  146 |  247 |  263 |  129
 talk-sn               |   64 |  114 |  113 |   75 |   57
 talk-tn               |      |      |   58 |   58 |   37
 talk-transit          |   33 |   42 |   51 |   11 |  131
 talk-tw               |   91 |   54 |   64 |   13 |   18
 talk-us               | 1552 | 1771 | 1108 | 1300 |  847
 talk-us-massachusetts |      |      |   37 |  114 |  248
 tile-serving          |  908 | 1870 |  709 | 1006 |  648
 umap                  |   17 |   49 |   79 |   63 |   36
(84 rows)

Top Authors per Year

SELECT 
    row_number() OVER (ORDER BY message_count DESC) AS rank,
    author,
    message_count
  FROM (
    SELECT
        from_short AS author,
        COUNT(1) AS message_count
      FROM mails
      WHERE
        EXTRACT(YEAR FROM "date") = 2018
        AND from_short NOT IN ('notifications@github.com', 'theweekly.osm@gmail.com')
      GROUP BY author
      ORDER BY message_count DESC
  ) AS a
  LIMIT 20;

 rank |          author           | message_count 
------+---------------------------+---------------
    1 | Martin Koppenhoefer       |          1819
    2 | Warin                     |           569
    3 | Marc Marc                 |           554
    4 | Philippe Verdy            |           506
    5 | Mateusz Konieczny         |           478
    6 | Giovanni Cascafico        |           344
    7 | Paul Allen                |           322
    8 | Graeme Fitzpatrick        |           295
    9 | François Lacombe          |           272
   10 | Simone Girardelli         |           271
   11 | Marián Kyral              |           271
   12 | Christoph Hormann         |           257
   13 | Tom Ka                    |           249
   14 | Volker Schmidt            |           248
   15 | Polyglot                  |           244
   16 | majka                     |           244
   17 | Frederik Ramm             |           236
   18 | Javier Sánchez Portero    |           230
   19 | John Whelan               |           229
   20 | Christan Quest            |           226
(20 rows)

SELECT 
    row_number() OVER (ORDER BY message_count DESC) AS rank,
    author,
    message_count
  FROM (
    SELECT
        from_short AS author,
        COUNT(1) AS message_count
      FROM mails
      WHERE
        EXTRACT(YEAR FROM "date") = 2017
        AND from_short NOT IN ('notifications@github.com', 'theweekly.osm@gmail.com')
      GROUP BY author
      ORDER BY message_count DESC
  ) AS a
  LIMIT 20;

 rank |              author              | message_count 
------+----------------------------------+---------------
    1 | Martin Koppenhoefer              |          1598
    2 | Philippe Verdy                   |           581
    3 | Marc Marc                        |           499
    4 | Marián Kyral                     |           481
    5 | Warin                            |           414
    6 | Marc Gemis                       |           372
    7 | Giovanni Cascafico               |           357
    8 | Simone Girardelli                |           352
    9 | John Whelan                      |           351
   10 | osm.sanspourriel                 |           296
   11 | Christian Quest                  |           291
   12 | Andy Townsend                    |           248
   13 | Volker Schmidt                   |           235
   14 | LogicalViolinist/James2432       |           233
   15 | Polyglot                         |           229
   16 | Frederik Ramm                    |           225
   17 | Dave F                           |           222
   18 | Alessandro Palmas                |           221
   19 | Joost Schouppe                   |           210
   20 | Paul Johnson                     |           210
(20 rows)


SELECT 
    row_number() OVER (ORDER BY message_count DESC) AS rank,
    author,
    message_count
  FROM (
    SELECT
        from_short AS author,
        COUNT(1) AS message_count
      FROM mails
      WHERE
        EXTRACT(YEAR FROM "date") = 2016
        AND from_short NOT IN ('notifications@github.com', 'theweekly.osm@gmail.com')
      GROUP BY author
      ORDER BY message_count DESC
  ) AS a
  LIMIT 20;

 rank |              author              | message_count 
------+----------------------------------+---------------
    1 | Martin Koppenhoefer              |          1781
    2 | Philippe Verdy                   |           506
    3 | Marián Kyral                     |           431
    4 | Simone Girardelli                |           394
    5 | Marc Gemis                       |           385
    6 | John Whelan                      |           347
    7 | osm.sanspourriel                 |           319
    8 | Christan Quest                   |           315
    9 | Giovanni Cascafico               |           306
   10 | Joost Schouppe                   |           302
   11 | Warin                            |           267
   12 | Polyglot                         |           245
   13 | Luca Delucchi                    |           240
   14 | Frederico Cortese                |           224
   15 | Maurizio Napolitano              |           223
   16 | Frederik Ramm                    |           223
   17 | Andrea Lattmann                  |           222
   18 | LogicalViolinist/James2432       |           220
   19 | Colin Smale                      |           215
   20 | Andy Townsend                    |           211
(20 rows)

I converted the email addresses into names manually by entering all email addresses into Google. While copying the results, I noticed that among the top 20 posters since 2016 only a few seem to have English as their native language. There are a lot of people from the French, Italian and Czech community. This is no surprise if you look for the most active mailing lists (see table above).

The OSMF-Talk mailing list was not taken into account for all these numbers (and it was not taken into account for the numbers published in part 1).

This list of the most active posters measured in messages per year will follow in the next part of this series. If you have any other suggestions what to query, don’t hesitate to comment.

I would like to ask all who intend to write a comment to stay on topic and don’t repeat themselves.

Some numbers about mailing lists

Posted by Nakaner on 2 December 2018 in English.

While reading the manifestos of the seven candidates of this year’s OSMF board elections, I though that getting some numbers about their activity could add a little bit more information to my personal decision whom to vote.

Numbers? Many readers will think of the number of changesets which is the most visible number of an OSM account. However, this number should be interpreted with care because changesets can contain between 0 and 50,000 (nowadays 10,000) changes. Users of different editors create changesets of different size. To get a better picture of the activity of an OSM user, I recommend to use Pascal Neis’s HDYC instead.

The number of data edits or the HDYC level (e.g. “super mapper (very active)”) is only one information. There are a few more contributions which can be counted:

  • Users of the OSM Forum (you have to be logged in but you don’t have to be a moderator) can search other users’ accounts by their names. It’s the menu item “members”. It will show the number of postings of a user.
  • The OSMF runs a StackOverflow-like system where people can ask questions, e.g. how to use OSM or how to map things. It’s called OSM Help. Answers can be up- or downvoted. This leads to an reputation. You can search for a user names and get their reputation. The forum and OSM Help have a a 1:1 mapping of Help/Forum and OSM API accounts but users who rename their accounts might get a new one (at least on the forum).
  • I haven’t found where to get the “editcount” using the MediaWiki front end but you can query the API (you might have to be logged in). The URL is https://wiki.openstreetmap.org/w/api.php?action=query&list=users&usprop=editcount&format=json&ususers=USERNAME where USERNAME is the display name of the user.

That was the easy part. The most difficult follows – our Mailman mailing lists.

The archives of all public mailing lists can be download as GZIP compressed plain text files. I used mailman-download by Matt Hicks, a Ruby script without a proper license, for that purpose. Afterwards I had a set of directories, each containing the archives of one mailing list. As the next step, I loaded all of them into a PostgreSQL database to run queries against them. I thought it would be easy (I am used to work with Python and the Psycopg2, its PostgreSQL library) but it was more difficult. Here are the problems I encountered:

  • Archives prior to November 2014 are not encoded in UTF-8 but in a encoding which is used in the language of the mailing list, e.g. Latin1 for Talk-de or a Japanese encoding for Talk-ja. Later archives are encoded in UTF-8. This does not affect the Subject headers and mail bodies but the From headers as well if the name of the sender contains non-ASCII characters. However, the email address is readable if your used encoding has the same character mapping for character positions 1–127.
  • An email begins with two lines matching the regular expression ^From. But it is more difficult that it sounds. If people use the TOFU quoting style, this regular expression matches for embedded, quoted emails as well. Use the regular expessions ^From +[^: ] for the first line and ^From: the next line instead to be sure not to count an email twice. The header of all emails ends with a Message-ID header.
  • The separator of the local and the domain part of email addresses is not an @ but a string which is different between languages (at or a for most mailing lists but en on Talk-ar or a @-like character on Talk-jp).

Here are some results I got:

mails=# SELECT COUNT(1) AS count FROM mails;
 count  
--------
 738498

mails=# SELECT list_id, COUNT(1) AS message_count FROM mails GROUP BY list_id ORDER BY message_count DESC;
        list_id        | message_count 
-----------------------+---------------
 talk-de               |        115377
 talk-fr               |         90995
 talk                  |         81529
 talk-it               |         64945
 tagging               |         40989
 dev                   |         30267
 talk-gb               |         22084
 talk-cz               |         20141
 talk-us               |         18959
 talk-es               |         16322
 talk-nl               |         15435
 rails-dev             |         14652
 hot                   |         14544
 talk-br               |         12375
 talk-au               |         12055
 talk-be               |         10473
 talk-ja               |         10237
 talk-at               |          9670
 talk-ca               |          8784
 legal-talk            |          8532
 josm-dev              |          8045
 talk-ph               |          6201
 talk-lv               |          5956
 tile-serving          |          5919
 imports               |          5735
 talk-dk               |          5043
 talk-co               |          4311
 talk-se               |          3376
 merkaartor            |          3302
 talk-ro               |          3248
 talk-in               |          3100
 talk-pl               |          2845
 dev-fr                |          2541
 talk-hr               |          2510
 talk-gb-westmidlands  |          2219
 talk-fr-bzh           |          2204
 talk-lt               |          2171
 potlatch-dev          |          2101
 talk-ie               |          2078
 talk-transit          |          1940
 geocoding             |          1851
 osmosis-dev           |          1755
 talk-cl               |          1752
 talk-ee               |          1679
 osrm-talk             |          1675
 talk-ar               |          1619
 talk-pt               |          1521
 talk-it-fvg           |          1486
 talk-ht               |          1386
 routing               |          1319
 talk-tw               |          1284
 talk-it-trentino      |          1227
 hot-francophone       |          1214
 talk-cat              |          1174
 talk-za               |          1141
 historic              |          1119
 talk-is               |           939
 talk-it-piemonte      |           841
 imports-us            |           836
 talk-ni               |           820
 talk-it-liguria       |           795
 talk-latam            |           756
 talk-it-lazio         |           749
 talk-pe               |           735
 talk-mx               |           709
 talk-ve               |           621
 talk-sn               |           611
 strategic             |           597
 talk-bo               |           575
 talk-it-cai           |           509
 talk-us-massachusetts |           399
 mapcss                |           397
 talk-cu               |           378
 talk-tr               |           377
 talk-gb-midanglia     |           368
 diversity-talk        |           357
 rebuild               |           353
 talk-rs               |           346
 talk-ko               |           338
 talk-gb-oxoncotswolds |           333
 dev-italia            |           333
 talk-pr               |           332
 accessibility         |           324
 talk-si               |           301
 local-chapters        |           291
 talk-np               |           276
 talk-scotland         |           272
 umap                  |           244
 taginfo-dev           |           241
 talk-africa           |           232
 talk-gh               |           226
 talk-it-sardinia      |           211
 talk-tn               |           198
 talk-bf               |           192
 legal-general         |           188
 talk-ml               |           176
 talk-uy               |           166
 talk-fi               |           165
 talk-id               |           164
 talk-mg               |           162
 talk-cm               |           153
 talk-it-southtyrol    |           151
 talk-lu               |           149
 talk-it-bici          |           134
 talk-us-nps           |           131
 learnosm-coord        |           128
 talk-il               |           121
 talk-gb-london        |           115
 talk-bj               |           106
 talk-cn               |           103
 talk-ru               |           102
 talk-bd               |           101
 maproulette           |            98
 talk-tg               |            98
 photon                |            98
 talk-ug               |            97
 talk-baltics          |            96
 talk-ci               |            91
 sotm-asia             |            90
 talk-ke               |            87
 talk-it-veneto        |            84
 talk-kosovo           |            78
 party                 |            76
 moderation            |            74
 talk-gb-thenorth      |            72
 teachosm              |            66
 talk-vi               |            65
 tagging-fr            |            63
 osmf-membership       |            61
 announce              |            61
 talk-blr              |            55
 talk-cd               |            52
 talk-py               |            47
 talk-us-pugetsound    |            36
 talk-us-newyork       |            35
 talk-ma               |            35
 talk-it-sicilia       |            34
 talk-lk               |            31
 talk-ba               |            28
 talk-al               |            26
 talk-do               |            23
 welcomewg             |            23
 talk-nc               |            19
 talk-ne               |            19
 osm-professional      |            19
 talk-mw               |            18
 talk-ng               |            17
 talk-cr               |            17
 osmcha-dev            |            15
 talk-it-marche        |            14
 talk-tz               |            12
 talk-ps               |            12
 talk-mm               |            12
 talk-et               |            10
 openhiking            |             9
 science               |             9
 lorodux-dev           |             9
 talk-gr               |             7
 talk-us-sfbay         |             7
 talk-hn               |             7
 talk-it-appulo-lucana |             7
 hot-announce          |             6
 talk-kg               |             6
 talk-my               |             5
 osm2world             |             5
 talk-sc               |             3
 talk-lb               |             3
 talk-carib            |             3
 outdoor-natural       |             3
 talk-mn               |             2
 talk-iq               |             1
 talk-bi               |             1
 talk-asia             |             1
 talk-zm               |             1
(174 Zeilen)

mails=# SELECT row_number() OVER (ORDER BY message_count DESC) AS rank, address, message_count
  FROM (
    SELECT
        from_short AS address,
        COUNT(1) AS message_count
      FROM mails WHERE from_short NOT LIKE '%@github.com'
      GROUP BY address
  ) AS a
  ORDER BY message_count DESC
  LIMIT 20;
  -- email addresses have been manually replace by names or nicknames in the following listing. People who have used multiple email addresses on the mailing lists are treated as multiple persons.
 rank |             address             | message_count
------+---------------------------------+---------------
    1 | Martin Koppenhoefer             |         25634
    2 | Frederik Ramm                   |         12274
    3 | Pieren                          |          6537
    4 | Philippe Verdy                  |          5731
    5 | Christian Quest                 |          4956
    6 | John Smith                      |          4582
    7 | Tobias Wendorff                 |          3494
    8 | Luca Delucchi                   |          3171
    9 | Sven Geggus                     |          3113
   10 | Jan Tappenbeck                  |          3025
   11 | Steve Coast                     |          3024
   12 | Maning Sambale                  |          2849
   13 | Polyglot                        |          2831
   14 | Tom Hughes                      |          2668
   15 | Paul Johnson                    |          2559
   16 | Vincent Pottier                 |          2516
   17 | Markus                          |          2506
   18 | Simone Cortesi                  |          2415
   19 | Richard Fairhurst               |          2393
   20 | Bernd Wurst                     |          2347

I will publish more results of more queries soon. If you have any suggestions what to query, write a comment to this user diary entry.

The Python script I used is quite ugly. That’s why I have not published its source code. However, if you are interested in doing similar analysis, write me an email and I will send it to you. The same applies for the dump of the database.

Im deutschen OSM-Forum hat Benutzer Jochen Kern neulich beschrieben, warum er Multipolygone für die bessere Art der Flächenerfassung hält. Da es die Diskussion dort zu arg auseinanderführen würde, lagere ich meine Erwiderung mal hierher in meinen Benutzer-Blog aus.

Flächen und Flächengrenzen der Realität sind hingegen kontinuierlich, sie fließen ineinander über, selbst dort wo der Mensch Anlagen installiert, um sie sichtbar bzw. unüberwindbar werden zu lassen. Multipolygone werden diesen Aspekt in besonderem Maße gerecht, weil sie diese Beziehungen von Flächen der Realität unmittelbar abbilden.

Dass zwei Flächen aneinander grenzen, lässt sich auch ermitteln, wenn die beiden als geschlossene Ways gemappt sind und sich die Nodes teilen. ST_Intersection der beiden ist dann ein LineString oder MultiLineString. Das OSM-Datenmodell ist für Analysen nur sehr eingeschränkt geeignet, weil es sehr viele JOINs erfordert. Um die Geometrie (Koordinatenliste) eines Ways zu erhalten, muss man in einer zweiten Tabelle die Koordinaten der Nodes nachschlagen. Um die Geometrie einer Multipolygonrelation zu erhalten, muss man zuerst die Ways in der Tabelle der Ways nachschlagen, dann deren Nodes in der Tabelle der Node nachschlagen. Das kostet Performance und aus diesem Grund hat sich für fast alle Anwendungen von OSM-Daten der Simple-Features-Ansatz durchgesetzt, bei dem Linien und Flächen keine Liste an Punkt-IDs, sondern direkt eine Liste der Koordinatenpaare haben.

Der Grund, warum unser Datenmodell praktisch nicht zur Analyse genutzt wird, ist eigentlich nicht, dass es schon in den OSM-Anfangstagen Open-Source-GIS-Software gab, die nach dem Simple-Features-Modell gearbeitet hat, sondern dass der Wechsel von einem Knoten-Kanten-Modell zu einem Simple-Feature-artigen Modell in der GIS-Welt schon vor 20 Jahren (oder etwas länger) erfolgt ist, weil es schlicht und einfach praktische Gründe gibt, eine Abstraktionsebene weniger zu haben.

Es gibt Diskussionen und mehr als nur absolut vage [1] Pläne, mittelfristig den Datentyp Node teilweise abzuschaffen, damit Ways nur noch eine Liste an Koordinatenpaaren enthalten. Im Zuge dieser Diskussion sind auch Entwickler von Software für verschiedene OSM-Anwendungsfälle gefragt worden, ob sie Nodes überhaupt brauchen. Mir ist keine Antwort bekannt, in der die teilweise Abschaffung der Nodes eine Anwendung verunmöglichen oder sehr erschweren würde. Das zeigt doch, dass unser eigenes Datenmodell nur für die OSM-API-seitige Datenhaltung taugt und praktisch alle anderen Anwendungsfälle aus guten Gründen auf die OSM-Komplexität verzichten können, oder?

Die Nichtnutzung des OSM-Datenmodells für Analysen zeigt, dass dein Argument, man könne mit Multipolygonen die Beziehungen zwischen Flächen ermitteln, keine Bedeutung hat. In den gebräuchlichen Datenhaltungen von OSM-Anwendungen, für die nachbarschaftliche Beziehungen relevant sind, hat eine Fläche keine Liste an Mitglieder-Ways. Außerdem ist eine rein koordinatenbasierte Nachbarschaftsanalyse robuster, wenn ein Mapper für zwei aneinander grenzenden Flächen keine gemeinsamen Nodes verwendet oder absichtlich für einen Verkehrsweg zwischen den beiden eine Lücke lässt.

Es ist Unsinn Flächen der Realität ohne ihre Nachbarn denken zu wollen, genau das passiert aber bei der Nutzung von “closed ways” als Flächenersatz: Sie verletzen in der überwiegenden Zahl der Fälle zwei Gebote aus den “best practices” die das Projekt sich selbst gegeben hat:

  • Bilde die Realität vor Ort ab (“ground truth”).

  • Benutze ein OSM-Objekt für ein Objekt der Realität (“one object, one feature”).

Zu “ground truth” ist der Fakt zu beachten, dass fast alle Flächen keine homogene Flächengrenze besitzen (“closed ways” aber genau das modellieren). Werden mehrere angrenzende Flächen durch “closed ways” modelliert, werden i.d.R. mehrere Flächengrenzobjekte mehrfach modelliert, wodurch eine Verletzung des zweiten Gebots stattfindet - und zwar _regel_mäßig.

Ich lege die On-the-Ground-Regel anders aus. Es geht bei dieser Regel nicht darum, ob man einen Node oder einen Way, Tags oder eine Relation verwendest, sondern darum, ob das, was in OSM erfasst ist, vor Ort so beobachtet werden kann. Sowohl wenn ein Gebüsch als geschlossener Way als auch wenn es als Multipolygon-Relation mit vier Outer-Ways und keinem Inner-Way gemappt ist, ist es vor Ort existent. Es entspricht dann innerhalb der Genauigkeit, mit der sein Rand in OSM abgebildet ist, der Realität.

Die One-Feature-one-Object-Regel verstehe ich völlig anders. Sie wäre verletzt, wenn wir Landnutzung nicht mit Flächen, sondern mit Kanten erfassen würden und nicht Tags an den Flächen, sondern an den Kanten anbringen würden (also landuse:left=meadow + landuse:right=forest statt landuse=meadow am Wiesenpolygon und landuse=forest am Waldpolygon). Die Regel ist meiner Meinung nach dafür gedacht, dass ein Objekt nicht mehrfach erfasst wird. Da wir die Landnutzung als Flächen erfassen und nicht dieselbe Wiese mehrfach erfassen, wird sie nicht verletzt.

Ein Objekt im Sinne der One-Feature-one-Object-Regel ist das Objekt, das die Tags trägt. Ein Haus in OSM, da es aus einem Way und mindestens drei Nodes besteht (also drei OSM-Objekte „zu viel“), verletzt diese Regel nach meiner Auslegung nicht. Genauso wenig verstößt man gegen sie, wenn man eine Multipolygon-Relation nimmt. Der Einsatz einer Multipolygon-Relation steht hingegen mit dem ungeschriebenen Grundsatz [2], Sachen so einfach wie angemessen zu mappen, in Konflikt. Dieser Grundsatz soll sicherzustellen, dass Neulinge die Möglichkeit haben, die Daten bearbeiten zu können, ohne umfangreiche Dokumentation lesen zu müssen.

Um es noch einmal klarzustellen: Ich will Multipolygon-Relationen nicht an sich abschaffen, ich will nur ihren Einsatz auf die Fälle beschränken, bei denen es erforderlich oder angemessen ist. Das sind Flächen mit inneren Ringen [3] sowie Flächen, mit einem sehr langen äußeren Ring und Flächen, die aus mehreren äußeren Ringen bestehen und bei denen das Mappen als zwei separate Polygone gegen die One-Feature-one-Object-Regel verstoßen würde [4].

[1] d.h. etwas konkreter als Träumereien auf einer Mailingliste oder im Forum, wie ich sie seit ich bei OSM bin, von Zeit zu Zeit sehe. https://2018.stateofthemap.org/2018/T107-Modding_the_OSM_Data_Model

[2] Bei OSM gibt es viele ungeschriebene Regeln. Wer gegen sie verstößt, wird gebeten, sie einzuhalten.

[3] Die Begriffe “innere Ringe” und “äußere Ringe” erkläre ich das gerne, wenn das gewünscht wird.

[4] z.B. ein Universitätscampus mit einer großen Straße dazwischen oder ein benannter Wald, der von einer Autobahn zerteilt wird. Diese zwei Beispiele sind aber recht kontrovers.

This is part 1b of my analysis of the candidates of 2017 OSMF board elections. Part 1a can be found here.

Please read the notes and explanations at the beginning of part 1a before reading this part!

David Dean

David Dean is Australian citizen, only understands English and is classified by HDYC as Heavy Mapper (very active). He started mapping in 2007 because he found all geocaches which were reachable during lunch break. He has been an active mapper since then although he has only very few active days between 2011 and 2016. He wants to increase the representation of the communities in AU/NZ/South Pacific Region. He works as a scientist on machine learning. His OSM edits are focused on Australia but he also contributes to HOT tasks. David wants to bring OSM to the indigenous communities around the world (he himself has no indigenous roots). They have a different look at the world than people from Europe or North America. In addition, he states that OSM data should take ownership of their OSM data.

He wants to bring the “present and future impact of automation, machine-learning and/or artificial intelligence [on mapping in OSM]” to the board, a topic has been working on for more than ten years. Although it might sound so, he thinks that machine learning is no antithesis to his opinion that local communities should hold ownership on their data. Instead, machine learning applications should support mappers and should be accessible to mappers and not be used in an import-like way.

David has not been active in the OSMF. He organized local OSM community events (see his user diary) in Brisbane between 2008 and 2011. He became inactive in 2011 because he thought that OSM was “finish” in his local area. He continued with mapping in 2016 by tracing buildings and using StreetComplete.

There is no formal OpenStreetMap association in Australia, so the question about his activity there is unnecessary.

David has some open source contributions which have related with OSM. He mentions two pull requests to StreetComplete and a machine learning project for OSM by Development Seed (Mapbox is a spin-off of Development Seed). His Github user name is dbdean.

He has not earned any money with OSM yet. There might be a commercial relation between him and OSM in future because he currently applies for a research grant “related with machine learning and HOT/OSM”.

According to several people I talked to, David is unknown in the international English speaking OSM community. He has not participated in any conference yet and there has not been any conference in Australia.

Trademark policy

He thinks that the draft published by the LWG is reasonable. He comments that we should be careful not to put in anything which is perceived as a burden by the organizers of local OSM events.

Term limits

He has not formed a final opinion yet. In principle, he is in favour of such a rule but he remarks that there should be enough candidates and we should not exclude committed board members from re-election just to limit their time on the board.

Transparency

David supports the currently practised transparent (i.e. public) board meetings. He has not listened to any board meeting yet.

Time to invest in the work at the board

He tries to dedicate one day per week for OSM-related activities.

Strategy of OSMF

He thinks that the do-ocracy culture in OSM and the independence of all those third-party applications around OSM is great. He would like to have some kind of process to integrate some useful applications into osm.org.

There are no plans by David to change the current strategy of OSMF. But the OSMF is perceived as a separate entity by many community members and this should be changed.

Imports and mechanical edits

David is critical towards imports and mechanical edits and thinks that all imports should be reviewed by local mappers.

Organised and paid editing

It seems that he did not understand this question on the Q&A page or answers evasively. The policy should treat mappers who map for money or a certificate and those who map without any reward.

Share alike

The share alike clause might discourage some potential data users to use OSM data. But another license change is not the effort worth. The active local OSM communities do compensate the disadvantage of the share alike.

OSMF supporting local chapters

He wishes that OSMF supports and encourages local communities to found their own local OSM association.

OSMF paying staff

He refers to the responses by Heather and Joost

Experience in fundraising

David has some experience with fundraising in the academic world and for start-ups but not for non-profit organisations. Membership fees of persons and companies and donation drives should be the main source of income in future.

Heather Leson

Heather is a Canadian citizen currently living in Switzerland and has an OSM account since June 2011. HDYC classifies her as a casual mapper (rarely active). She has only contributed to OSM on 11 days during these six and a half years. Her changesets are small in size. The first three changesets belong to a mapping party in Toronto in summer 2011 when she was “recruited” by Richard Weait. All other changesets are humanitarian mapping. Heather was member of the HOT US Inc. board of directors from sprint 2013 to spring 2017. She was secretary in her first year on the board, then president until spring 2016.

Heather works for International Federation of Red Cross and Red Crescent Societies in Geneva which is involved in the Missing Maps project.

Her manifesto is emphasizes “community building” and governance of open source community as her strengths. She has worked for Open Knowledge, Ushahidi and Mozilla. At HOT, she lead the group which drafted the new code of conduct.

After joining the board she wants to start a discussion how the leadership of the OSM project and the working groups of OSMF can become more diverse (regional diversity). She wants to open OSM for people with “diverse skills” who do not want to support OSM as a mapper or developer and wants to build a network of “community managers”. Her answer on the Q&A page is more precise. These community managers should be paid and she wants to hire multiple community managers.

She wants to transform the OSMF board of directors from a board of people how actually do stuff to a “strategic” board which decides and let other – probably paid – people do the work. She proudly described this change which already happened to HOT US Inc. in her blog in April.

Asked whether she has a commercial relationship with OSM, she responds that she wants to be part of OSM governance due to the “data policy”. It can be assumed that she means the Directed Editing Policy.

Heather participated in three regional OpenStreetMap conferences, the SotM 2016 in Brussels and the HOT Summit in Brussels (just before SotM 2016).

Heather would like to introduce a strong code of conduct with an enforcement.

Two emails by Nicolas Chavent, co-founder of HOT, reveal the dark side of a code of conduct. He writes that Heather filed a code of conduct complaint against him in autumn 2015 (first email). He and Severin Menard, another francophone user who has been HOT US Inc. member for a very long time, had drawn (email by Nicolas, email by Severin) attention on OSMF-Talk mailing list on possibly too high influence of HOT US Inc. on the OSMF and that HOT US Inc. voting members could gain a majority on the OSMF board of directors. He tells that he was informed by the board of HOT US Inc. that a code of conduct complaint had beenfiled against him. In May 2017 another code of conduct complaint was filed against him (second email. A board member had to resign due to a conflict of interest and Mikel Maron wanted to promote the first candidate who did not get a seat in the previous board elections. Nicolas started a discussion on HOT US Inc. voting member mailing list about conflicts of interest in general because the conflict of interest was foreseeable and dealt appropriately by the board. Mikel responded to the mailing list and warned members to participate in this discussion.

Severin casted doubt on Heather’s qualification and fundraising experience in an email on 22. November on OSMF-Talk mailing list. Severin served as a board member of HOT US Inc. from spring 2014 to February 2016. He writes that she emphasized her fundraising skills on the board but did not collect any money. Due to “confidentiality” she did not even report about her activity to the other board members. It came to the light when HOT US Inc. ran out of money. Several people, mainly from the (dominating) anglophone wing of HOT US Inc. criticized Severin for being unrespectful and offending. (He wrote that seeking for a seat on OSMF board were shameless with that low OSM activity referring to her small number of changesets)

The claims by Severin and Nicolas have not been denied substantially.

Trademark policy

Her response is meaningless. She has no suggestions for any changes.

Board term limits

She responds evading and asks counter questions which are partially beside the point.

Transparency

She does not want to commit herself to any opinion.

Workload

Heather responds that she dedicate five to ten hours per week to HOT US Inc. She thinks that the board should be a strategic board and the work should be done by the working groups.

Strategy of OSMF

She answers the questions regarding the role of OSMF in community software projects with two short sentences and refers to Joost’s response. She would like to know the opinion of the Operations Working Group before committing herself to any opinion.

Her response to the question for her opinion regarding the strategy of OSMF is confusing. She just responds with a bunch of counter questions.

Import and mechanical edits

She has no opinion and thinks that the working groups should deal with this questions.

Organised and paid editing

Her response is ambiguous. She writes that organized or even commercial edits are less valuable. The draft process of the Directed Editing Policy is the main reason why she runs for the board. She points to several articles about the contribution of companies to open source projects but forgets that OSM is no open source project but an open data project.

Note: Heather has a conflict of interest here. On the one hand she wants to influence the process leading to a guideline on directed editing, on the other hand she works for a organisation which does directed editing.

Share alike

Her response is much shorter than the responses of the other candidates. She thanks for their responses, thanks the Licensing Working Group and thinks that ODbL should be better explained.

Fundraising

Mailing lists users should not criticize ideas to make OSM(F) more attractive for funders. Here response is quite long but it misses the main point of the question – the experience in this field.

Desirable sources of income

She writes that she is unable to answer this question and has to learn how it currently works. OSMF needs people outside the board who do fundraising. It is not clear whether these people should be paid but one can assume that they are paid. She thinks that there are already skilled people in the wider network of OSM(F) who would like to help if there were no “drama” and “skilled people to collaborate”.

Part 2

Part 2 will interpret and analyse the candidates and their opinions in a non-neutral way and will provide a ballot recommendation.

The members of OpenStreetMap Foundation are called to elect board members for two seats on the OSMF Board of Directors this year. In this blog post which consists of two parts the four candidates will be presented. Part 1 summarizes their manifestos, their responses to the questions by community members, criticism and other available and relevant bits of information. Part 2 will evaluate them based on the opinion of a German craft mapper.

Links to the manifestos can be found on the OSM wiki about the election. There is also a talk page where everyone can ask questions to the candidates. In addition, a lot discussions can be read in the public archive of the OSMF-talk mailing list.

How does the election work?

All members of OSMF are eligible to vote if they have been a member of at least 30 days before the AGM which will take place on Saturday. It does not matter if you are a normal member or an associate member. Associate members are not listed by real name on the list of members which everyone has to be given access if required. But only normal members are allowed to vote on changes to the articles of association.

You can vote between 2th December 2017 16:00 UTC and 9th December 2017 16:00 UTC. The general assembly will start on 9th December 2017 16:00 UTC on a special IRC channel. The results of the election will be announced at the end of the meeting.

The election itself uses the Single Transferable Vote system (STV). It is a proportional voting system to vote persons. Every voter creates his/her personal list of desired candidates ordered by perference.

The transfer of the votes happens later during vote count. The vote count consists of several rounds. In each round, it is checked if one or multiple candidates have reached the necessary threshold to get a seat (“quota”). If a candidate gets more votes than necessary, the votes will be transfered to the remaining candidates based on the preference of the elected candidate. If no candidate reaches the quota in a round, the candidate with the lowest number of votes is eliminated and his/her votes transferred to the other candiates based on the preference of the voters. There are as many rounds as necessary until all free seats are filled.

STV is known to be a relatively fair voting system but there is some space for tactics because votes are transferred to other candidates. If there are four candidates and you want only two of them on the board, you should add only these two to your ballot. Leave the remaining fields empty.

The Wikipedia article about STV contains an example. Richard Weait has published the output of the OpenSTV programme running on the ballots of OSMF board elections 2015.

Notes for the reader

This blog entry uses the term “HOT US Inc.” if the organisation HOT US Inc. is meant. In all other cases the term HOT is used. This is not intended to be pejorative but to have a clear distinction between the organisation and the community which is larger.

There are two sections about each candidate. You can find the first section about each candidate in this first part of this two-part blog entry. It summarizes their manifestos, their repsonses to the questions asked by the voters, their activitiy and obvious opinion. Criticism which has been raised against a candidate for the last weeks will be mentioned too. The first part of this two-part blog entry tries to be neutral. The second part will not be neutral. It will describe what the opinion of a long-term contributor who wants to preserve the mappers’ freedom (freedom is limited to common decency) and that OSMF guards and accompanies but not governs the project. You will find my recommended ballot in the second part.

Paul Norman

Paul Norman is Canadian and has been contributing to OpenStreetMap since 2010. HDYC describes him as a Great Mapper (active). Paul joined the OSMF board three years ago and stands for reelection. Beyond that, Paul is member of the Data Working Group, the Engineering Working Group, the Licensing Working Group and the Membership Working Group. He is one of the two maintainers of osm2pgsql and one of the many maintainers of OpenStreetMap Carto. He has contributed a lot to the rendering stack and works as a freelancer on that topic. Carto (the company) and Mapquest were his main clients, nowadays he mainly works for Wikimedia Foundation. Paul contributed a lot to cgimap, the fast implementation of parts of the read-only OSM API. You can get an overview on his work on his blog. Paul participated in all State of the Map US conferences since 2012 and State of the Map 2016 and 2017.

His manifesto mentions three big worries. Six of the seven members of the board of directors are involved in OSM-related business. The employer/client of four members sells OSM related services. The whole Conflict of Interest topic has not got enough attention yet. Until now, it was sufficent for a board member to not speak during a discussion in which they had a conflict of interest. He thinks that such discussions should happen on a separate mailing list so that the board member with a conflict of interest is unable to read the discussion.

He is worried that more and more people want to expand governance and want to control mappers. Mappers should still have the freedom to do anything even if it is not in the interest of the board.

Paul writes that he joined the board three years ago as a personal response to the lack of volunteers. He wants the members to be interest in the work of the board.

His manifesto from 2014 when he was elected the first time can be found on the OSM wiki. He campaigned for a transparent board at that time. He thought that board meetings need a moderator to make them more efficient. The lack of volunteers had worried him already at that time. His intent to make the board more transparent was successful. A moderator has not been hired but there is Dorothea who collects items for the board meeting. The number of volunteers has been raised since then but there is still work waiting to be done.

Opinion on the trademark policy

Paul thinks that the LWG has not explained their motivation as much as necessary. He himself is member of the LWG and he will give feedback in the next steps of the process.

Term limits for board members

Paul supports term limits. He does not want that a board member sees himself as unreplaceable as it happened in the past. He doesn’t think it is important to introduce such a rule at the moment. He remarks that the right point in time has to be choosen to avoid a board member who is sticking to his/her seat percieving such a proposal as a personal attack.

Transparency

Paul is in favour of a transparent board. Because he describes the current state in his response, one can assume that it is the transparency he wants to have. Paul would like to have all working groups publishing their meeting minutes (if they have meetings at all).

Imports and mechanical edits

He responds to this questions that he himself has done imports already but he has tidied up other users’ imports, too. It is not the job of the board to set up rules. Rules should come from the community and the Data Working Group.

Organised and paid editing

He did not respond to this question.

Share-alike clause of ODbL

Paul is in favour of the share alike clause. He writes that he was a supporter of public domain. However, the fact that companies were in favour of public domain changed his mind. Because he has invested a uncountable number of hours into the license change, he does not want it to happen again.

Strategy of OSMF

Paul supports the current strategy of OSMF not to control mappers.

He did not respond to following questions:

  • extending the membership
  • role of local chapters and their support by OSMF
  • gender-limited events
  • code of conduct
  • OSMF hiring people
  • experience with fundraising
  • desirable distribution of OSMF funding

Joost Schouppe

Joost is a Belgian citizen and speaks Dutch (native), English, French and Spanish. His account was created in 2008 but he uploaded his first changeset in 2012. He became really active in 2013. HDYC classifies him as a Heavy Mapper (highly active). He came to OSM via OsmAnd. He is a sociologist working in data analysis and has no commercial relations to OSM.

He founded OSM Belgium within Open Knowledge Belgium together with Ben Abelshausen and Jorieke Vyncke and was a member of the State of the Map 2016 in Brussels.

Joost is active as a European craftmapper but also maps for HOT projects but is not a HOT US Inc. voting member.

His manifesto mentions four aims. First, he wants the OSMF to support community members better who want to build a local community. He mentions software tools to improve communication between mappers and scholarships for State of the Map. Second, he wants to improve the diversity in OSM. His main focus is on the diversity of language (skills), i.e. to include/attract more contributors who do not understand English.

Third, he aims better connections between the OSM community and researchers who want to investigate how OSM works. Their results might help the community to understand itself better. Currently, decisions are made based on assumptions.

His fourth and last point says that the board should look out for new use cases for OSM which have to potential to bring us more new contributors.

Joost does not describe himself as a software developer but he thinks that he can file useable feature requests and bug reports because he has some knowledge of script languages. His only contribution to the OSMF work was at the State of the Map 2016 in Brussels where he participated in the local team. Instead of being more involved into OSMF, he is involved into the future local chapter in Belgium which currently applies for this status.

He participated in State of the Map 2014 in Buenos Aires and 2016 in Brussels. In addition, he participated in several OSM/GIS conferences in Belgium.

Opinion on the trademark policy

He responds that the criticism expressed in the discussion on the mailing list a few months ago should be addressed.

Term limits for board members

Joost does not express a clear opinion on this issue. He thinks that it is an important issues to be solved and we should not spend to much time for theoretical problems.

Transparency

Board meetings should be open by default. Some exceptions may occur (e.g. due to privacy). Joost has participated only in one meeting yet.

Time to invest in the work at the board

Joost dedicates already four to eight hours per week to this work for OSM Belgium. He could increase this a little bit but if he gets elected he wants to reduce his activity there to have time for the OSMF.

Imports and mechanical edits

Joost admits that he though in the past that imports are great. In the meantime, he realised that it is quite difficult to get an import right. He himself is involved into two community imports in Belgium. His opinion on imports applies more or less to mechanical edits, too.

Organized and paid edits

On the one hand, Joost sees organized and paid editing as a chance but on the other hand he thinks that it is a threat to our values. He appreciates the work on the drafted policy, but neither praises it nor criticizes it. He comments that it is difficult to organize a good mapathon.

Share alike clause

Joost does not like share alike. He responds that if public administration publishes data to improve OSM, the cannot use the improved OSM data due to the share alike.

Increasing the membership of OSMF

OSMF should have ambitious goals, should support local projects and the development of community tools to be more attractive for normal mappers. In addition, OSMF members should see themselves more as a community of common values and should not argue that much.

Code of conduct

Joost thinks that OSM/OSMF needs a code of conduct but it should be short and simple: “Please try and be kind to each other”. He wishes that those who oppose a code of conduct speak out against those who behave not as firendly as expected. Otherwise they would boost the striving of the other side for a code of conduct. He does not want that the process of the creation of a code of conduct widens the gap between the different parts of the community.

OSMF paying staff

He is pride that OSMF has reached that much without paying lots of people but is in favour of paying staff in order that things get done.

Part 1b

Part 1b will focus on David Dean and Heather Leson. It will cover their manifestos, their repsonses to the questions asked by the voters, their activitiy, obvious opinion and the criticism about them. Its translation has not been finished yet.

no and yes vote icon of OSM Wiki votings

From time to time I participate in the voting of tagging proposals. Even if I lack the necessary knowledge in the field the proposal is about (e.g. I have limited knowledge about electricity or fire hydrants), I check a few things before I cast my vote. (The following is my personal opinion)

Avoid changing heavily used tags

A proposal should always avoid to change existing tags which are used a lot. There are some reasons for a change of the tagging but they are rare. Changing American English to British English just to have British English is one example if there is no other benefit. Changing from or to namespaced keys/values is another.

If the only reason is to have nicer keys/values, this will just lead to an unnecessary workload for multiple parties. Mappers who attempt to do mechanical edits, other users who revert them, the Data Working Group who has to mediate disputes (or has to revert the changes if it has not been done already), and last but not least data consumers who have to change their software. You might think “Data consumers, don’t be angry, you have just change a string (and add an AND to your code)” but you should keep in mind that more and more data users order pre-installed servers/services from companies in the OSM ecosystem. Their services get automatic data updates because they want or need data being up to date but they will miss more and more features. And all this just happens because someone thought that an l is missing in jewellry (I am not sure if that was a joke or test).

If a proposal tries to change a heavily used tag, I think that it has to address why this change is really necessary and that the “cost” of the change are lower than the benefits. Mentioning this only in one or two sentences will lead to a failure of this test (except very long sentences). If a proposal fails this check, I will say NO although other parts might be good.

Well formed keys and values

If check number 1 is passed, I will check if the new tags and values are well-formed. Keys must only contain lower-case characters, underscores and, if really necessary, numbers. Colons are namespace delimiters. You must have really good reasons that I accept upper case characters. Spaces and other characters are a no go.

The same applies for values. Only free-text values may have any content.

Boolean values must be no or yes.

This check must be passed, too. A failure results in a No vote.

Good tag design

Good tag design is more difficult. It is a good idea to put special interest tags into a namespace but on the other hand namespaced keys exclude mappers who don’t think they are qualified to edit them.

Namespaced keys have the advantage of avoiding conflicts with other keys which could be tagged on the object. On the other hand, namespaces add some kind of noise to the raw tag list.

Using keys to tag properties of the new feature B which are already in use for feature A is not a good idea if an OSM object could be both A and B but the value of the key should be different.

Example: A pole of a power line (power=minor_line) has a reference number ref=34. A proposal wants to add a tag to map transformators on poles. Both should share one node in OSM. Adding the reference number of the transformator as ref=T5 is not possible because this would overwrite the reference number of the pole. Adding a special tag for reference numbers of transformators mounted on poles is one solution. The other one is to map two nodes. Both have advantages and disadvantages.

This example shows that there is not always a clear answer what good tag design is and therefore serious problems have to persist after the discussion to make the proposal fail this test.

Observable

A tagging proposal should only suggest tags which are observable on the ground. For example, a proposal which contains a tag for the maximum amperage a electrical locomotive may consume from the catenary, might fail this test if the author could not point me to a region where it can be observed on the ground (in Germany you cannot observe it).

If a property or feature can be observed only on some objects, this will not cause a failure of this test.

Stable

Tagged values have to be stable. If values changes multiple times per year (or even every year), maintenance is difficult or impossible. If the value changes too often, the property does not fit into OSM at all.

This is a soft fail test, too. If the properties of some instances could be stable but other are not, it might not lead to a No vote.

Privacy

Tagging proposals which invite mappers to add information which infringes privacy and/or will lead the project into legal trouble in regard with data protection (in Europe) could fail this test. It depends on how much tagging without infringing privacy is possible (see “Stable” and “Observable”).

For example, a proposal with a tag for the owner of a house will clearly fail this test.

Structure

This is a soft test. Readers of a proposal should understand quickly what the proposal wants to change, what it introduces and what is just mentioned as context to understand the proposal. Guides which summarize various tagging schemes fail it easily because proposal are not guides but change requests. If a guide covers a disputed topic, it is a good idea for its author to write that it is disputed, what the parties arguments are and leave the decision to the reader.

Split up your proposal into a section of simple and advanced tagging if your proposal is very long and goes deep into a topic of a special interest. People starting adding the simple features and properties might later use the advanced tagging. But if you only offer a steep ladder, less people might climb it up.

Summary

As you have seen, I am very strict because there is no difference between a YES and a partial YES. But you, as a proposal author, could circumvent this problem partially. If you split up your proposal in two or more parts, the parts which don’t fail these test, will pass.

If you want to learn more about how to write good proposals, I suggest you to read the discussions and voting section of rejected proposals.

What do you check if you read a proposal before you cast your vote? Or does your wiki user page already include the UserAgainstTagVoting or No_Wiki_Fiddlers template?

zu Teil 1

Communitywachstumspreis

Der Communitywachstumspreis soll für Anstrengungen zur Erweiterung der Community, nicht nur in räumlich Hinsicht, sondern auch zur Verbesserung der Vielfalt sowie zur Integration des humanitären Sektors sowie der öffentlichen Verwaltung verliehen werden.

Pete Masters aka pedrito1414 wird dafür gelobt, dass er seit vier Jahren als Koordinator beim Missing-Maps-Projekt aktiv sei, “unzählige” Mitwirkende in OSM eingeführt habe, Communities in Bangladesh, der Demokratischen Republik Kongo und anderen Ländern unterstützt habe und alle ihn lieb hätten.

John Sturdy sei ein wichtiges Element für die Entwicklung der albanischen OSM-Community und pflegt Kontakte zu einem Hackerspace in Albanien.

Andrew Braye leitet die GIS-Abteilung beim Britischen Roten Kreuz und ist ein Gründungsmitglied von Missing Maps.

Tony Emery und Jean-Louis Zimmermann wurden wegen der Organisation der State of the Map France 2017 in Avignon, Kontakten zur regionalen Verwaltung, Schulen und Vereinen in Südfrankreich nominiert.

Jessica Salo wurde für das Organisieren von Mapathons in Colorado (USA) nominiert.

In dieser Kategorie haben zahlreiche Kandidaten Beschreibungen, die in meinen Augen überlange Werbetexte einer PR-Abteilung sind. An Belegen mangelt es jedoch. Nur bei Jessica Salo ist eine Überprüfung mit einem akzeptablen Rechercheaufwand (zwei Klicks) möglich.

Aufgrund mangelnder Belege und einer dadurch nicht möglichen Überprüfbarkeit der Behauptungen enthalte ich mich aus Protest in dieser Kategorie.

Preis für Engagement in Lateinamerika/Afrika/Asien

Mangels ausreichender Kenntnisse und regionaler Relevanz dieser Kategorien enthalte ich mich und kann hierzu auch keine Wahlempfehlung abgeben.

Ulf-Möller-Gedächtnispreis

Der Ulf-Möller-Gedächtnispreis ist für Einzelpersonen gedacht, die das OpenStreetMap-Projekt erheblich vorangebracht haben – sei es durch gutes Mapping, Wohltaten für die Community und andere Leistungen für OpenStreetMap. Jedes Communitymitglied, das irgendwann seit 2004 aktiv war oder ist, kann vorgeschlagen werden.

Christoph Hormann (aka imagico) wurde für seine regelmäßigen Beiträge bei den Diskussionen mechanischer Edits und Importe[ auf den einschlägigen Mailinglisten] nominiert.

Martin Raifer wurde für die Entwicklung des Overpass-Turbo nominiert.

Nama Budhathoki wurde für seine Verdienste um den Aufbau der OSM-Community in Nepal vorgeschlagen. [Er ist Leiter des Kathmandu Living Labs.]

Richard Fairhurst [(Benutzer Nr. 165)] wurde für seine lange Liste an Beiträgen zu OSM, sowohl beim Mappen als auch bei der Softwareentwicklung vorgeschlagen. Von ihm stammen die Online-Flash-Editoren Potlatch 1 und 2, welche für viele Mapper das Tor in das OpenStreetMap-Projekt waren.

Miriam Gonzalez arbeit in der Communityarbeit bei Telenav und ist bei HOT aktiv. [Ihre restliche Beschreibung gibt nicht viel mehr her und ist eine heiße Luftblase.]

Es fällt mir in dieser Kategorie sehr leicht Miriam auszusortieren. Wer in dieser Kategorie nominiert wird, sollte sich durch sowohl besonders lange als auch zahlreiche Beiträge zum Projekt auszeichnen. Miriam ist erst seit gut einem Jahr aktiv. Man kann zwar in einem Jahr viel erreichen, aber “erhebliches Voranbringen” braucht mehr Zeit.

Die anderen Kandidaten sind in meinen Augen alle ausreichend lang bei OSM dabei. Meine Stimme geht in dieser Kategorie – welch Wunder – an Richard Fairhurst.

Mangels Zeit in den letzten Wochen habe ich mich nicht so intensiv mit den Kandidaten der diesjährigen OSM Awards auseinander setzen können und veröffentliche diese Wahlempfehlung leider erst kurz vor Ende der Abstimmung.

Wie stimmt man ab?

Man ruft awards.osmz.ru auf und wird meistens erst auf die OSM-Loginseite umgeleitet. Die Abstimmungsplattform wurde vom OSMF-Vorstandsmitglied Ilya Zverv (Zverik) geschrieben und ist auf seinem Server gehostet, daher nicht unter einer “offiziellen” openstreetmap.org-Subdomain. Durch den Login wird sichergestellt, dass jedes OSM-Benutzerkonto nur einmal abstimmt.

Anders als letztes Jahr, kann man in jeder Kategorie beliebig vielen Kandidaten eine Stimme geben. Man kann bis zum Ende des Abstimmungszeitraums noch seine Stimmabgabe ändern.

Die einzelnen Kategorien

Es gibt neun Kategorien, drei mehr als letztes Jahr. Für die Definition der Kategorien sei auf meinen Eintrag im deutschen OSM-Blog hingewiesen.

Im Folgenden gehe ich durch die einzelnen Kategorien. In jeder Kategorie findet ihr zu Beginn die Beschreibung der Kategorie. Danach folgt die Liste der Kandidaten mit einer Beschreibung, die neutral zu sein versucht und an das englische Original angelehnt ist. Als letztes kommt meine persönliche Meinung, die nicht neutral, aber wertend und ehrlich-direkt ist.

Core Systems Award

Die Definition: Der Core Systems Award (Preis für zentrale Dienste) soll für herausragenden Beiträge zu wichtiger, zentraler OSM-Software, -Systemen, -Prozessen oder -Ressourcen vergeben werden. Die Software/das System muss nicht unter der Kontrolle der OSMF stehen. Der Rails Port, osm2pgsql, OSM Carto, iD, JOSM, Mapnik und all die anderen Werkzeuge, die Mapper wissentlich oder unwissentlich tagtäglich nutzen, sind qualifiziert.

  • Hartmut Holzgraefe hat den alten MapOSMatic-Dienst zum Atlantendruck, nachdem er offline gegangen war, wiederbelebt, indem er ihn geforkt hat und eine eigene Instanz aufgesetzt hat. Und das ist nicht das Ende: Jede Woche verbessert er seinen Dienst weiter. Er hat die größte Sammlung an Kartenstilen, die zum Drucken bereit sind. Sein Dienst unterstützt E-Mail-Benachrichtigungen und er hat die Benutzerobefläche verbessert. Man kann sogar zusätzliche Overlays einbinden.
  • Bryan Housel ist der Maintainer von iD, dem Online-Editor auf openstreetmap.org. Kürzlich hat er ein Einsteiger-Tutorial ergänzt, das zum Ausprobieren sogar eine virtuelle Stadt bereithält.
  • Andy Allan arbeitet seit vielen Jahren an OpenStreetMap-Projekten, am Kartenstil, der auf openstreetmap.org eingesetzt wird und seit einiger Zeit auch an der Website und API. Dort macht er gerade eine Fleißarbeit – er räumt auf.
  • Kevin Bullock ist als DigitalGlobe-Mitarbeiter auf diversen State-of-the-Map-Konferenzen schon gefragt worden, wann DigitalGlobe endlich Satellitenbilder zum Mappen bereitstelle. Jetzt war es endlich so weit.
  • Paul Norman und Matthijs Melissen haben über ein halbes Jahr den Kartenstil “OSM Carto” einem Refactoring unterzogen, eine Arbeit, von der man nicht viel sieht, aber trotzdem wichtig ist.

Ich tendiere dazu, diesen Preis demjenigen zu geben, der ehrenamtlich an einem zentralen Projekt lange arbeitet. In dieser Kategorie vergebe ich nur eine Stimme. Sie geht an Andy Allan.

Auf keinen Fall würde ich meine Stimme an Kevin Bullock geben. Zum einen sind die DigitalGlobe-Luftbilder kein “zentraler Dienst”, zum anderen sollten die OSM Awards an Freiwillige und nicht an bezahlte Kräfte vergeben werden.

Auch bei Hartmut Holzgraefe frage ich mich, was an MapOSMatic “zentral” sein soll. Es ist nur eines der vielen Tausend Projekte aus dem OSM-Universum.

Bryan Housel bekommt von mir auch keine Stimme, weil er für seine Tätigkeit von Mapbox bezahlt wird.

Da Paul und Matthijs beim Refactoring sich, soweit ich weiß, nicht so sehr um die Kompatibilität mit anderen Kartenstilen gekümmert haben und man künftig nicht mit derselben PostgreSQL-Datenbank sowohl OSM Carto als auch einen der anderen Mapnik-basierten Kartenstile rendern kann, bekommen die beiden von mir keine Stimme.

Innovationspreis

Der Innovation Award (Innovationspreis) wird für den besten neuen Dienst oder Ansatz vergeben, z.B. neue Werkzeug zum Mappen, Bilderkennung, Digitalisierung oder OSM-Datenanalyse, neue Mappingtechniken oder neue Nutzungsmöglichkeiten für bestehende Werkzeuge.

  • Stefan, Philipp und Martin, die Entwickler der OpenTopoMap, welche OSM-Daten in einem der TK50 nachempfundenen Stil rendert. Zudem stellt das Projekt OpenTopoMap wöchentlich aktualisierte Garmin-Karten bereit.
  • Sajjad Anwar (geohacker) hat die manuelle Analyse von Änderungssätzen beschleunigt. Die meisten verwenden dafür bislang Achavi, welches aber langsam ist, weil es die Daten live aus der Overpass-API bezieht. Sajjad erzeugt die für die Analyse notwendigen Daten jedoch in Echtzeit und cacht sie, was die Ladezeiten verkürzt. Zudem ist das Rendering schneller. Seine Arbeit wird schon von OSMCha verwendet.
  • Yuri Astrakhan hat die SPARQL-Schnittstelle zum Abfragen von Wikidata-Daten mit OSM verknüpft.
  • Tobias Zwick hat mit der Android-App StreetComplete neue Nutzergruppen als Mapper erschlossen. Dabei handelt es sich um einen OSM-Spezialeditor, der einem zu erledigende Aufgaben in der nahen Umgebung anzeigt.
  • Michael Straßburger hat einen ASCII-Renderer für Vektortiles geschrieben, sodass man sich OSM-Karten auch auf der Kommandozeile ansehen kann.

Ich werde in dieser Kategorie eine Stimmen vergeben.Die eine Stimme geht an Tobias Zwick. Zwar gibt es schon Manches auszusetzen, es handelt sich dabei jedoch um Fragen, die die Gestaltung der Aufgaben betreffen.

Die zweite Stimme geht an Sajjad Anwar. Zwar ist seine Arbeit Teil seiner Tätigkeit bei Mapbox, jedoch geht es in dieser Kategorie um die Innovation und nicht um das Engagement.

Da ich nicht mehr als zwei Stimmen vergeben möchte, geht Michael Straßburger leider leer aus. Ehrlich gesagt, hätte eine Implementierung des Renderers in C mehr Stil gehabt als in JavaScript.

Die OpenTopoMap ist eine Fehlnominierung und es spricht in meinen Augen nicht für das Auswahlkomittee in dieser Kategorie, dass diese Nominierung es in die Endauswahl geschafft hat. Das Projekt existiert schon seit Jahren und verstößt damit zum einen gegen die Bedingungen dieser Kategorie, zum anderen mangelt es mir an Neuheit.

Preis für einflussreiches Schreiben

Der Influential Writing Award (Preis für einflussreiches Schreiben) soll für das beste Tutorial, die beste Anleitung, den besten Blog oder Blogbeitrag vergeben werden. Ein Text oder eine Reihe an Texten, die neue Leute zu OSM bringen, einen interessanten Ausblick auf OSM bringen oder die Community dazu animieren, Sachen besser zu machen, sind gesucht.

BushmanK wird für seine nachdenklich-kritischen Benutzer-Blog-Einträge nominiert, in denen er sich Mapping-Themen widmet, z.B. der Benennung von Objekten und ob man gewisse Dinge überhaupt eintragen sollte.

Joost Schouppe wurde für die Einträge in seinen Benutzer-Blog zu den folgenden Themen nominiert: Interviews, Analyse lokaler Bearbeitungen, Statistiken, dem Effekt von Mapathons und Gedanken zur Nutzung bereitgestellter amtlicher Daten

Ramani Huria wurde für Blogeinträge zur Community und Mappingtechniken in Tansania nominiert.

Die Firma Carto’Cité wurde für ihre französischsprachigen Tutorials zur Nutzung von OSM-Daten in QGIS und uMap nominiert.

Arun Ganesh (PlaneMad) wurde für Einträge in seinem Benutzer-Blog über Statistiken, Renderingbeispiele und Kuriositäten (inkl. Vandalismus) in den OSM-Daten nominiert.

Meine Stimme geht an Joost Schouppe, weil seine Blogeinträge den Eindruck erwecken, dass sie sehr einiges an Rechereche im Vorfeld erfordert haben (Erstellung der Statistiken usw.). Meine zweite Stimme geht an BushmanK, da seine Beiträge ebenfalls einen aufrufenden Charakter haben. Gerade das ist für “einflussreich” erforderlich.

Fortsetzung in Teil 2

OSM Awards–Decision Guidance

Posted by Nakaner on 15 September 2016 in English.

This is the English of my previous posting in German.

How to cast your vote?

Open awards.osmz.ru. You will be redirected the OSM login page because the voting platform uses the authentication via OSM to ensure that every OSM account only gives one vote. The voting platform has been written by Ilya Zverv (Zverik), is hosted at his own hardware.

There are six categories I want to explain in the following paragraphs.

Core Systems Award

Following people are nominated:

  • Grant Slater and Tom Hughes who are members of OSMF Operations Working Group and operate the central servers of the OpenStreetMap project and additional services operated by OSMF, e.g. the wiki, the mailing lists, OSM Help. As you might have experienced, they do a great job. Do you remember the last downtime which was their fault?
  • Roland Olbricht has designed and developed the Overpass API and is its maintainer (relevant code contributions have been made in recent time by other contributors, too). He is responsible for the German instance of Overpass API which is sponsored by FOSSGIS e.V.
  • Bryan Housel is the main developer of iD. It is difficult for me as a JOSM fan to find nice words about him and his work. I do not like him very much because he has a mind of his own.
  • Mateusz Konieczny is a co-developer of OSM Carto map style which is used at www.openstreetmap.org and is the OpenStreetMap map for many people outside OSM community. He implemented the new road colouring scheme during Google Summer of Code 2015. Thanky you!
  • Sarah Hoffmann is the main developer of Nominatim, the only geocoder which is a community project. (There are other free geocoders but they are backed by a company). She operates the public Nominatim instance on nominatim.openstreetmap.org and therefore is member of Operations Working Group. I admire her tilting at windmills—people who abuse the public Nominatim instance to do batch geocoding (converting addresses into coordinates).

It is difficult to come to a decision. Whoever you vote, it is no bad decision. I myself prefer Grant Slater and Tom Hughes, Roland Olbricht and Sarah Hoffmann.

Innovation Award

This is the category for inventors of innovative tools.

  • Yohan Boniface founded uMap, the free and OSM based alternative to Google MyMaps
  • The MapSwipe Team has been nominated for the development of MapSwipe app. Non-mappers can look through aerial imagery and mark areas where features are located which can be mapped (e.g. buildings).
  • American Red Cross has been nominated for the development of Portable OpenStretMap. This software makes it possible to go to remote locations (without internet access) do mapping there and upload your changes after the expedition. As far as I know, the main advantage is the multi-user capability. But POSM does not solve conflicts. Therefore its use is limited.
  • Martijn van Exel has been nominated for his work on MapRoulette. This quality assurance tool selects a random map error and presents it to the human user (who will fix it). It has been used much for TIGER clean-up work.
  • Manuel Roth and Lukas Martinelli have developed OSM2Vectortiles which makes vector tiles in Mapbox’s format available for download. They have made the processes Mapbox uses to produce its vector tiles more transparent. It seems that they are that successful that Mapbox’s lawyer asked them very friendly (!) not to build exactly the same vector tiles Mapbox sells.

Ilya Zverv wrote in the announcement) of OSM Awards that people and projects can be nominated whose work has been published after August 1, 2015. (This does not apply to Ulf Möller Memorial Award) If this rule is still valid, Yohan Boniface and Martijn van Exel cannot be selected because their innovations are older.

Therefor the remaining candidates are OSM2Vectortiles and MapSwipe. MapSwipe is innovative but its use for OSM is limited. It just makes HOT even more efficient. OSM2Vectortiles is the free download service for vector tiles and takes the work of creating vector tiles out of the hands of other developers. It is a little bit like a Geofarik download service but for vector tiles instead of planet extracts.

Influential Writing Award

Three mappers have been nominated for their user diaries:

  • Zu Edil Queiroz De Araujo
  • Joost Schouppe
  • Harry Wood

In addition, Nick Allen (Tallguy) has been nominated for his work on LearnOSM and the WeeklyOSM team (this includes the folks from German Wochennotiz because they are the mother and main source of all WeeklyOSM variants).

I can say as a team member of Wochennotiz that the work which is invested into WeeklyOSM/Wochennotiz is much larger than the time to be invested into a blog. WeeklyOSM is more important and therefore has more “influence” than a simple blog. The German Wochennotiz is also read by people from outside OSM community because Wochennotiz/WeeklyOSM produce a summary of all important and less important news of OSM universe. I did not hesitate to give my vote to myself (Wochennotiz/WeeklyOSM).

Greatness in Mapping Award

This category covers great mapping efforts. You have the choice between

  • a group of HOT mappers (Ramani Huria Team)
  • Nelson A. de Oliveira (naoliv) who does monitoring and quality assurance in Brazil,
  • UK Quarterly Mapping Team who organizes the quarterly mapping tasks
  • Martin Ždila (description says that he has mapped and walked 1.4 % of all hiking routes in OSM and 38% of all in Slovakia)—I hope it is true
  • OSM Los Angeles Building Import Team

It is not difficult to say who will not get my vote—neither Ramania Huria Team nor LA Buildings Import will get my vote. I have not found any reasons why I should vote Ramania Huria Team (I hear the name for the first time). Only the official SotM Twitter account advertises them (which should not happen from my point of view, official Twitter accounts should be neutral!). Imports should not get any awards. “No complains” is the best compliment an import should get.

Because I read the name Martin Ždila for the first time, only UK Quarterly Mapping Team and Nelson A. de Oliveira remain. It is difficult for me to find a final decision.

Expanding the Community Award

You have following options:

  • Pascal Neis for his tools
  • Ahasanul Hoque and Tasauf A Baki Billah
  • Courtney Clark
  • Kathmandu Living Labs—community of mappers who had been mapping before the Great Earthquake
  • Pete Masters

The only candidates, I know, are Pascal Neis and Kathmandu Living Labs. I do not want to give to much of my votes to humanitarian mappers because OSM is more than HOT and Missing Maps and they already gain enough attention from third parties. In addition, I consider usage of the term “leadership” in the description of Ahasanul Hoque and Tasauf A Baki Billah as a bad attribute because OSM is a community of independent-minded individuals, not of people who follow their boss (my country had enough bad experience with leaders in history).

Ulf Möller Memorial Award

This award should memorize the murder of Ulf Möller in January 2012. Ulf was mapper, developer, had been OSMF board member and much more. The idea of having such an award is rather old, it was published) a few months after his death. But the idea fizzled out. The original description was:

The Ulf Möller Memorial Award will recognize an individual each year who improves OpenStreetMap through good mapping, benefit to the community and other improvements to the OpenStreetMap project.

Following persons have been nominated:

  • Kate Chapman for co-founding HOT and “bringing HOT to” the developing world
  • Harry Wood for good mapping, organizing a local OSM group and his work at HOT
  • Frederik Ramm for his engagement to make OSMF (especially the finances) transparent and his responses on mailing lists which helped other people understanding OSM
  • Nick Allen (Tallguy) – has also been nominated for Influential Writing Award
  • Richard Fairhurst as voice of reason in OSM community and his projects (Potlatch 1, Potlatch 2, Tilemaker)

Because LearnOSM is too much focussed on HOT (if a newbie reads LearnOSM, he might not be aware of the other aspects of OSM) and therefore the name LearnOSM is not appropiate, I decided not to give my vote to Nick Allen. People who want to get this award should have done good work for the whole project, not only a part of it.

“Bringing OSM to a significant portion of the developing world” might sound well but it is not the way I want to support. Someone who distributes OSM like a colonial power, should not be awarded. OSM should origin from the local people. If they don’t need maps, we should not force them.

I must admit that I am not a fan of the web editors but they attract many newbies (which is good). They lower the entry level. I assume that Potlatch was the main reason why the European OSM communities became so powerful between 2007 and 2010. Richard competes with Frederik for my vote. I admire the time he invests into OSM both as developer, entrepreneur, DWG and board member etc. It took a some time until OSMF became really transparent – Frederik joined the board in 2012. First the finances became more transparent (and published earlier), now even the board meetings are public.

OSM Awards could be better

The OSM Awards are not fair. The majority voting system is suitable for binary decisions (with optional abstention from voting). But it is not suitable for an election where opinions differ widely. I would like to give some negative votes to some candidates but I cannot. A system like STV (used for board election) is also not fair but better (and more complicated).

The best voting system is useless if your choice is limited. The candidates of these awards have been selected by “some members of CWG, SotMWG and the Board” (source). How are they legitimated to decided who will get an award? These awards will have an influence of the public image of OSM. Why do the awards not have a system with rounds? During the first round, all mappers (people with OSM account) could suggest candidates and the descriptive texts (but less than 80 words – otherwise you have to read too much) are written. Maybe you could introduce a minimum number of supporters every candidates should achieve during this round. In a second round, all mappers could vote. Four or five candidates per round progress into the third round.

OSM Awards 2016 – Entscheidungshilfe

Posted by Nakaner on 13 September 2016 in German (Deutsch). Last updated on 15 September 2016.

EDIT: Die englische Version dieses Blogeintrags ist jetzt auch online.

Wie stimmt man ab?

Man ruft awards.osmz.ru auf und wird meistens erst auf die OSM-Loginseite umgeleitet. Die Abstimmungsplattform wurde vom OSMF-Vorstandsmitglied Ilya Zverv (Zverik) geschrieben und ist auf seinem Server gehostet, daher nicht unter einer “offiziellen” openstreetmap.org-Subdomain. Durch den Login wird sichergestellt, dass jedes OSM-Benutzerkonto nur einmal abstimmt.

Die einzelnen Kategorien

Es gibt sechs Kategorien, die ich im folgenden erklären möchte.

Core Systems Award

Ungefähre deutsche Übersetzung: Preis für zentrale Dienste

Nominiert sind:

  • Grant Slater und Tom Hughes, welche Teil der Operations Working Group der OSMF sind und die zentralen Server des Projekts, die OSMF-eigenen Tileserver (tiles.openstreetmap.org) und diverse von der OSMF betriebene Dienste wie das Wiki, die Mailinglisten, OSM Help aber nicht das Forum, betreiben. Wie ihr vielleicht gemerkt habt, leisten die beiden eine hervorragende Arbeit. Wann war der letzte, nicht geplante Ausfall, den sie zu verantworten hatten? Ich weiß es nicht. Sie tun das freiwillig!
  • Roland Olbricht hat die Overpass-API entworfen, entwickelt und ist ihr Betreuer (relevante Codebeiträge sind in neuerer Zeit auch von Dritten). Er ist zuständig für die deutsche Instanz der Overpass-API (overpass-api.de), welche vom FOSSGIS e.V. gesponsert wird.
  • Bryan Housel ist der Hauptentwickler des Onlineeditors iD. Als JOSM-Liebhaber und iD-Kritiker fällte es mir schwer, gute Worte für seine Arbeit zu finden. Wenn ich ihn nicht leiden kann, dann wegen einer gewissen Schwerhörigkeit in Taggingfragen.
  • Mateusz Konieczny ist ein Hauptbeitragender des Kartenstils OSM Carto, welcher auf www.openstreetmap.org prominent eingesetzt wird und von Dritten oft mit dem OSM-Projekt gleichgesetzt wird. Mateusz hat im Rahmen des Google Summer of Code 2015 die neuen, augenfreundlicheren Straßenfarben umgesetzt. Danke!
  • Sarah Hoffman ist die Hauptentwicklerin von Nominatim, dem einzigen Community-Geocoder auf OSM-Basis. (Es gibt noch weitere freie Geocoder, aber hinter diesen stecken Unternehmen) Sie ist wegen des Betriebs von nominatim.openstreetmap.org auch Mitglied der Operations Working Group. Ich bewundere ihren Kampf gegen die Windmühlen – Leute, die Nominatim missbrauchen und große Massen an Datensätzen zu geocodieren (Adressen in Koordinaten umwandeln).

Mir persönlich fällt die Auswahl hier schwer. Jeder hätte meine Stimme verdient, ich präferiere in dieser Kategorie Grant Slater und Tom Hughes, Roland Olbricht und Sarah Hoffmann.

Innovation Award

Deutsche Übersetzung: Innovationspreis

In dieser Kategorie stehen die Entwickler/Erfinder innovativer Werkzeuge zur Auswahl.

  • Yohan Boniface hat uMap begründet, das freie, OSM-basierte Äquivalent zu Google MyMaps
  • Das MapSwipe-Team wurde für die Entwicklung der App MapSwipe nominiert. Mit dieser App können Nicht-Mapper Luftbilder sichten und markieren, ob es dort mappenswerte Objekte gibt.
  • Das US-Amerikanische Rote Kreuz wurde für die Entwicklung von Portable OpenStreetMap vorgeschlagen. Mit dieser Software kann man vor Ort (in abgelegenen Regionen) mappen und anschließend die Daten nach Ende der Expedition in OSM hochladen. Konflikte löst POSM nicht auf. Es ist also für Leute, die gemeinsam auf eine Mappingexpedition gehen wollen.
  • Martijn van Exel wurde für seine Arbeit an MapRoulette vorgeschlagen. Dieses Qualitätssicherungswerkzeug wählt für den Benutzer einen Fehler aus vielen zufällig aus und lässt ihn von seinem menschlichen Benutzer lösen. Es ist bekannt für die Aufräumarbeiten nach dem TIGER-Import.
  • Manuel Roth und Lukas Martinelli haben OSM2Vectortiles entwickelt, das Vektortiles im Mapbox-Format zum Download anbietet. Sie haben die Prozesse, mit denen Mapbox diese Vektortiles prozessiert, transparent gemacht. Sie sind wohl so erfolgreich, dass Mapbox sie als Konkurrenten sieht und ein Mapbox-Anwalt freundlich (!) auf sie zuging.

In der Ankündigung der OSM Awards schrieb Ilya Zverv, dass in allen Kategorien mit Ausnahme des Ulf-Möller-Gedächtnispreises nur Projekt/Personen vorgeschlagen werden dürfen, die nach dem 1. August 2015 veröffentlicht wurden. Wendet man diese Regel auf diese Kategorie an, fallen Yohan Boniface und Martijn van Exel heraus. Ihre Innovationen sind älter.

Es verbleiben also OSM2Vectortiles und MapSwipe. MapSwipe ist zwar innovativ, nützt aber weniger OSM, sondern macht nur HOT effizienter. Bei OSM2Vectortiles kann man gewisse Parallelen zum Download-Server der Geofabrik erkennen – beide machen OSM leichter für Entwickler zugänglich, dafür ist aber der Nutzen für die Allgemeinheit in meinen Augen größer.

Influential Writing Award

Den Titel kann man je nach Lust und Laune vielfälig übersetzen, hier mal eine Auswahl: Preis für einflussreiches Schreiben, OSM-Bloggerpreis, OSM-Propagandapreis

In dieser Kategorie sind mehrere Mapper für ihre Benutzer-Blogs vorgeschlagen worden:

  • Edil Queiroz De Araujo
  • Joost Schouppe
  • Harry Wood

Zudem finden sich in dieser Kategorie Nick Allen (Tallguy) für seine Arbeit an LearnOSM und das Team der WeeklyOSM, was die Wochennotiz inkludiert.

Als Mitglied des Wochennotizteams kann ich jedoch sagen, dass die Arbeit an der WeeklyOSM/Wochennotiz deutlich mehr Zeit verschlingt als ein Blog, eine zentralere Bedeutung und eine größere Reichweite, auch über die Grenzen der OSM-Community hinaus, hat, habe ich, ohne zu zögern, meine Stimme mir selbst gegeben.

Greatness in Mapping Award

In dieser Kategorie geht es um herausragende Mappingleistungen. Zur Wahl stehen

  • ein Gruppe HOT-Mapper (Ramani-Huria-Team)
  • Nelson A. de Oliveira (naoliv), der um Qualitätssicherung in Brasilien bemüht ist,
  • UK Quarterly Mapping Team, das die Quartalsaufgaben (britisches Äquivalent zu unseren Wochenaufgaben) organisiert
  • Martin Ždila, der laut Kurzbeschreibung 1.4% aller weltweiten Wanderrouten in OSM abgelaufen ist (und 38% aller slowakischen) – irgendwie kann ich es nicht glauben, aber es wird hoffenlich warh sein
  • OSM Los Angeles Building Import Team

In dieser Kategorie weiß ich sehr schnell, wer sicher nicht meine Stimme bekommt – weder geht sie an das Ramani-Huria-Team noch an den Gebäudeimport in Los Angeles. Für das Ramani-Huria-Team habe ich bislang keine Gründe gefunden, warum ich diesem meine Stimme geben solle. Einzig und allein der Twitter-Account der SotM macht Werbung für diesen Kandidaten (was er nicht tun sollte). Auch Importe sollten keine Preise bekommen, „keine Schelte“ ist genügend Lob für einen Import. Der Gebäudeimport ist zudem noch recht frisch; einen Import sollte man erst nach ein paar Jahren loben. Übrig bleiben Martin Ždila, dessen Namen ich hier erstmals lese (was es mir schwer macht, ihm meine Stimme zu geben), die britischen Quartalsaufgaben und Nelson A. de Oliveira. Zwischen den letzten beiden fällt mir die Entscheidung schwer.

Expanding the Community Award

Der Preis in dieser Kategorie soll an Leute gehen, die sich für das Anwerben neuer Mapper engagiert haben.

  • Pascal Neis – für seine Werkzeuge
  • Ahasanul Hoque und Tasauf A Baki Billah
  • Courtney Clark
  • Kathmandu Living Labs – Mappercommunity aus Nepal, die auch schon vor dem Erdbeben aktiv war
  • Pete Masters

Von den genannten Namen habe ich bislang nur Pascal Neis und die Kathmandu Living Labs gehört. Pascals Werkzeuge schätze ich sehr, die Kathmandu Livings Labs konkurrieren ernsthaft bei mir um meine Stimme in dieser Kategorie. Die anderen drei kommen für mich nicht in Frage. Bei Ahasanul Hoque and Tasauf A Baki Billah ist der Text viel zu lang und ich kann mangels eigener Kenntnisse nicht bewerten, ob die “Leadership” der beiden nicht wirklich eine “Community_führung_” ist, etwas was eigentlich nicht zu den Grundsätzen von OSM passt.

Ulf Möller Memorial Award

Dieser Preis soll an den im Januar 2012 ermordeten Ulf Möller erinnern, der u.a. Mapper, Entwickler und OSMF-Vorstandsmitglied war. Die Idee zum Preis kam kurz nach seinem Tod auf, seither verlief sie im Sande. Die Beschreibung lautet:

The Ulf Möller Memorial Award will recognize an individual each year who improves OpenStreetMap through good mapping, benefit to the community and other improvements to the OpenStreetMap project.

Der Ulf-Möller-Gedächtnispreis wird jedes Jahr an eine Einzelperson vergeben, welche OSM durch gutes Mapping, gute Arbeit für die Community oder andere Verbesserungen für das OpenStreetMap-Projekt verdient gemacht hat.

In dieser Kategorie stehen zur Wahl:

  • Kate Chapman für die Mitbegründung von HOT und dafür, dass sie Entwicklungsländer mit OSM/HOT bekehrt
  • Harry Wood, für gutes Mapping, die Organisation eines Stammtisches und sein Engagement bei HOT
  • Frederik Ramm für seine Bemühungen um die Transparenz der OSMF, seine aufklärenden Antworten auf Mailinglisten, die zum Verständnis des OSM-Projekts beitragen und für seine zahlreichen Skripte
  • Nick Allen (Tallguy) – steht auch in der Kategorie Influential Writing Award zur Wahl
  • Richard Fairhurst als “Stimme der Vernunft” und Entwickler von Potlatch 1 und 2

Da ich LearnOSM sehr kritisch sehe (einseitig auf humanitäres Mapping fixiert, der Name ist dem Projekt nicht angemessen), fällt Nick Allen raus. Da „bringing OSM to a significant portion of the developing world“ in meinen Augen Kolonialismus ist, bleiben nur noch Frederik und Richard übrig. Auch wenn man JOSM liebt und die Webeditoren nicht mag, sollte man sich vor Augen halten, dass iD und Potlatch für viele Neulinge der erste Kontakt mit OSM sind und gerade Potlatch der deutschsprachigen Community beim Erstarken der Community in den Jahren 2007 bis 2010 viel geholfen hat. Für Frederik spricht sein unermüdlicher Einsatz für saubere Daten – ich bewundere ihn, wie viel Zeit er in die DWG-Arbeit steckt, um den Dreck anderer Leute aufzuräumen oder unvernünftige Streithähne zur Vernunft zu bringen.

Kritik an den OSM Awards

Mir persönlich missfällt, dass bei den OSM Awards das Mehrheitswahlrecht zur Anwendung kommt. Wer viele Anhänger mobilisieren kann, kann in einer Kategorie gewinnen, auch wenn der Kandidaten von allen anderen mit aller Schärfe abgelehnt wird.

Auch die Auswahl der Kandidaten erscheint mir persönlich in manchen Kategorien arg einseitig. Wo bitteschön ist die Legitimation von “einzelnen Mitgliedern der SotM Working Group der OSMF, der Communications Working Group der OSMF und des OSMF-Vorstands” sein? Wenn man die OSM Awards wirklich transparent und neutral machen will, wäre eine System bestehend aus Vorschlagsphase und zwei Wahlgängen (zweiter Wahlgang mit maximal fünf Kandidaten pro Kategorie) deutlich besser. Auch die Kurzbeschreibungen könnten etwas länger sein (aber maximal 80 Wörter – sonst muss man zu viel lesen).

Leider können wir daran jetzt nichts mehr ändern und sollten das Beste aus der Sache machen. Das heißt, GEHT WÄHLEN! Wenn ihr abstimmt, beeinflusst ihr das Ergebnis. Es kann nicht im Sinne der deutschen Community und des Grundgedanken des OSM-Projekts sein, wenn Sesselmapping (HOT) und Importe alle Preise abräumen. Der Preis hat Außenwirkung.

Anwohner-Erlebnisse

Posted by Nakaner on 27 March 2016 in German (Deutsch).

Beim Mappen von Hausnummern passiert es mir bei jeder längeren (d.h. min. 1 1/2 Stunden draußen), dass ich von einem Anwohner angesprochen werde. Neuerdings habe ich einen Weg gefunden, der zwar die Bekanntheit von OSM nicht vergrößert, aber zu einer möglichst kurzen Gesprächsdauer und weniger Verdacht führt – die Navi-Methode.

Anwohner: Guten Tag, was machen Sie denn da?

Nakaner: Ich erfasse für einen Anbieter von Navikarten, welches Haus welche Hausnummer hat.

Anwohner: Ah, danke.

Selten wird nachgefragt, für welchen Anbieter. Eher kommt noch die Frage, warum ich das am Sonntagnachmittag mache.

Heute habe ich Fotomapping gemacht, dabei aber nicht gezielt Hausfassaden, sondern die (öffentliche) Straße selbst fotografiert (ich stand auf dem Bürgersteig). Mittendrin kommt mir ein Herr entgegen, der mir seinen Regenschirm entgegenstreckt und entrüstet meint:

Er: Wissen Sie eigentlich, dass man zum privat Fotografieren eine Erlaubnis braucht?!

Nakaner: Ihre Rechtsaufassung ist leider falsch.

Er geht ein paar Schritte weiter, schaut auf die Rückseite meiner Warnweste und meint dann: “Für welches Vermessungsbüro sind Sie denn tätig?”

Nakaner: Für gar keins. Vermessung ist in Deutschland übrigens kein geschützter Begriff.

Weiter habe ich mich nicht auf ihn eingelassen, sondern bin weitergegangen. Es hätte auf keinen grünen Zweig geführt.

Ob das mit dem geschützten Begriff wirklich ganz richtig ist, weiß ich nicht. Aber ich darf mich sogar Vermessungsingenieur nennen. ;-)

Obige Szene hat sich übrigens nicht in einem Wohngebiet mit Einfamilienhäusern, sondern einem Mischgebiet in der Nähe eines Bahnhofs ereignet.

There are some issues JOSM users experience which are not the fault of JOSM developers because Java/OpenJDK causes it.

You use Ubuntu or Debian an experience strange GUI issues at JOSM’s tag editor and at comboboxes at JOSM presets? They look like this:

screenshot tag editor 1

or this

screenshto tag editor 2

or this

screenshto tag editor 3

or this?

screenshto bug at preset combo box

There is even a video of it.

Solution

There is a workaround. Thank you, Don-vip. Remove the line

assistive_technologies=org.GNOME.Accessibility.AtkWrapper

from /etc/java-8-openjdk/accessibility.properties (the file might be located at another directory if you use OpenJDK 7)

How I discovered the bug

I have been using Arch Linux for the last 18 months and started using Ubuntu (better: Xubuntu) on my new laptop. First I thought it were a KDE-related problem because I tried Kubuntu. A switch to XFCE did not fix it. Searching JOSM’s issue tracker for open issues did not help because the issue was closed (that’s ok, it’s no JOSM problem). I tried an older version of JOSM but did not help. I tried OpenJDK 7 and 8, both behave the same. I asked at #osm-de IRC and malenki pointed me to the issue and the workaround.

Fotos Smartphone in Kfz-Halterung an Fensterscheibe

In meinem letzten Posting habe ich erklärt, wie man aus einem Video Einzelbilder extrahieren und georeferenzieren kann. Vor ziemlich genau zwei Jahren habe ich das erste Mal Videomapping zum Bahnmapping verwendet, ich blicke hier zurück und gebe meine Erfahrungen zum Besten.

Meine ersten Videomapping-Projekte

Lange Zeit habe ich bloß gefilmt. Das Smartphone mit der Kfz-Halterung an die Fensterscheibe montiert und fertig. Da ich nicht parallel einen GPS-Track aufgezeichnet habe, blieb das Verfahren elektrifizierten, mehrgleisigen Strecken vorbehalten. Nur dort stehen nämlich in ausreichend dichten Abständen Oberleitungsmasten, die man auf den Bing-Bildern gut sehen kann. Auf eingleisigen Strecken sind die Oberleitungsmasten zu nahe am Zug (oder auf der anderen Seite), sodass man gar nicht viel sieht. Alle Videos habe ich damals durch das Seitenfenster nach links hinten aufgenommen. In Deutschland fahren die Züge im rechten Gleis, sodass die Oberleitungsmasten des Gegengleises weit genug weg sind und man auch bei 120 km/h noch produktiv mappen kann. Dass ich von Anfang an nach links hinten gefilmt habe, liegt an einer Empfehlung von bigbug21, die sich gar nicht auf das Videomapping bezog, aber sich trotzdem als zutreffend erwiesen hat.

Bei der Auswertung habe ich immer ein Stückchen Video geschaut und dabei die Oberleitungsmasten gezählt. So habe ich mich von Feature zu Feature (Signale, Schilder, Hektometertafeln und andere mappenswerte Dinge) gehangelt. JOSM und der Videoplayer waren gleichzeitig geöffnet, immer ein Stückchen Video, dann wieder ein oder zwei Sachen in JOSM und dann wieder Video. Da man viel zurückspulen muss, war dieses Verfahren seeehr zeitaufwendig.

Es gab mal ein JOSM-Plugin zum Videomapping von !i!, aber das war schon Ende 2012 kaputt.

Erfahrungen

Mit der Zeit habe ich folgende Erfahrungen gesammelt:

  • Bei trübem Wetter leidet die Bildqualität. Bei Sonnenschein kann man bis 160 km/h gut mappen (bei den kleinen Signalnummern – die stehen auf weißen Tafeln am Signalmast – ist schon bei 120 km/h Schluss.
  • Bei viergleisigen Strecken kann man bei trübem Wetter die Objekte drei Gleise weiter links auch bei 200 km/h noch erkennen.
  • Vermeide dreckige Fensterscheiben. Gefühlt sehen die Fahrzeuge die letzten 18 Monate vor einem Betreiberwechsel, die zur Umbeheimatung (d.h. Verlagerung in eine andere Ecke der Republik) oder Abstellung führt, keine Waschanlage mehr von innen. Besonders auffällig war das bei DB Regio Südost und deren alten Reichsbahn-Doppelstockwagen.
  • Richte das Bild so aus, dass du das Nachbargleis nur zur Hälfte im Bild siehst (die näher bei dir gelegene Schiene des Nachbargleises nicht mehr im Video sichtbar ist). Dann kannst du trotzdem noch Weichen im Nachbargleis erkennen (unterstützen die Orientierung), hast aber Bildfläche für wichtigere Sachen.
  • Nimm nicht die Androiod-eigene Kamera-App. Sie ist für diesen Anwendungszweck unbrauchbar. Nimm stattdessen OpenCamera. Dort kannst du den Fokus fix auf Unendlich setzen. Sonst refokussiert die Kamera alle paar Sekunden.
  • Wähle in OpenCamera die SD-Karte als Speicherort (Zahnrad-Symbol → Mehr Kamera-Einstellungen → Speicherort). /storage/sdcard1 ist sowohl auf meinem Galaxy S5 als auch LG Optimus 2X die SD-Karte.
  • Leg eine schnelle und große Karte ein.
  • Schalte die maximale Helligkeit ab. Das Display braucht viel Strom. Bei meinem LG Optimus 2X brauchte das Smartphone bei maximaler Helligkeit mehr Strom beim Filmen, als das Netzteil nachliefern konnte! Stelle vor die Helligkeit so weit herunter, dass du das Display noch gut ablesen kannst. Deaktiviere in OpenCamera Zahnrad-Symbol → Benutzeroberfläche → “Maximale Helligkeit erzwingen”.
  • Die Videoaufnahme wird beendet, wenn die maximale Dateigrößere erreicht ist. Bei FAT-formatierten SD-Karten sind das 4GB. Je nach Auflösung und Kompression können das 11 oder 45 Minuten sein. Du musst dann die Aufnahme wieder neu starten. Ich muss mal ausprobieren, wie Android mit ext4-formatierten Karten zurechtkommt. (Mein Linux-Rechner dürfte sich daran nicht stören)
  • Überkopf fallen auch gute Halterungen irgendwann herunter. In Doppelstockwagen (Untergeschoss ist nicht empfehlenswert) muss man daher die Halterung festhalten.
  • Die Halterung, die durch Klebstoff halten (statt durch Saugwirkung), sind ungeeignet. Sie sind lassen sich nicht beliebig oft entfernen und an eine andere Scheibe ankleben.
  • Ein Powerbank ist eine gute Investition.
  • Zum Filmen den Flugzeugmodus aktivieren. Das spart Strom. Man will ja auch nicht beim Filmen gestört werden.

Um auch Signalnummern mappen zu können (und Signale, die ich nur von hinten im Video sehe), habe ich während des Filmens gleichzeitig Signalnummern, Weichennummern und Signalbeschreibungen diktiert.

Beispiel 1 – der ICE wurde über die Güterzugstrecke Opladen–Hilden umgeleitet, da filmte ich trotz nasser Scheibe und trübem Wetter, altes Smartphone

Beispiel 2 – gute Lichtverhältnisse, aber ohne Kfz-Halterung, da daheim liegen gelassen, altes Smartphone

Mit einem Smartphone kann man nicht vernünftig nach hinten durch den unbesetzten Führerstand hindurch filmen, da die Frontscheibe zu weit entfernt ist und man deshalb den halben Führerstand mit filmen würde. Wenn jedoch am Zugschluss ein einfacher Reisezugwagen hängt, kann man durch die abgesperrte Wagenübergangstür heraus auf die Strecke filmen. Dabei entstehen dann Videos wie dieses.

Vorverarbeitung vor dem Upload

Mittlerweile entferne ich bei allen Videos, die ich auf Youtube hochlade, immer den Ton. Das geht mit folgendem ffmpeg-Befehl:

ffmpeg -i originalvideo.mp4 -an -vcodec copy ohne-ton.mp4

Folgendes Bash-Skript verpixelt (per Weichzeichner) einen Bereich des Bildes. Das sollte man tun, wenn sich fremde Fahrgäste in der Fensterscheibe spiegeln, aber man das Video veröffentlichen will. Fahrgäste, die still sitzen, bewegen sich nicht, sodass ein statisches Rechteck genügt.

#! /usr/bin/env bash
# Usage: ./remove-sound-and-blur.sh INPUTFILE WIDTH HEIGHT LEFT_MARGIN TOP_MARGIN
ffmpeg -i $1 -filter_complex "[0:v]split=2[v0][v1];[v0]crop=$2:$3:$4:$5,boxblur=10[fg];[v1][fg]overlay=$4:$5[v]" -map "[v]" -map 0:a -c:v libx264 -c:a copy -an blurred-$1

Bilder extrahieren

Mit einer vernünftigen Kamera (rurseekatze hat die meisten Videos unserer Deutschlandpass-Tour damit aufgenommen) und einem GPS-Logger sind noch ganz andere Dinge möglich. Damit kann man einzelne Frames extrahieren und diese georeferenzieren (siehe vorheriges Posting). Die Fotos kann man direkt in JOSM laden. Der Umweg über Mapillary ist Zeitverschwendung. Mapillary komprimiert die Bilder noch ein bisschen, sodass kleine Details (Signalnummern) flöten gehen und verpixelt gerne die wichtigen Sachen (Signalnummern). Ich habe den Eindruck, dass man bei der Auswertung von georeferenzierten Fotos aus einem Video 30 bis 40 Prozent Zeit einspart.

Folgende Frameraten sind empfehlenswert:

  • Blick nach hinten oder vorne: 1 fps bis etwa 120 km/h, darüber 2 fps
  • Blick schräg zur Seite: 2 bis 4 fps bei etwa 120 km/h

Brücken, die über die Gleise hinwegführen und einen Schatten auf das Gleis werfen, eigenen sich gut, um die Georeferenzierung zu kontrollieren. Beim langsamen Anfahren im Bahnhof fällt ein Fehler von 2 Sekunden in der Zeit kaum auf. Bei schneller Fahrt merkt man das aber.

Videoaufname-Ausrüstung in einem Talent 2

Zur Erfassung von Eisenbahndaten (insbesondere Signale) haben sich in den vergangenen zwei Jahren selbst aufgenommene Videos als eine sehr gute Quelle herausgestellt. Man fährt die Strecke zwei- bis dreimal ab und kann dann daheim in aller Ruhe das Video auswerten. Somit kann man mit einer Reise kreuz und quer durch Deutschland in kurzer Zeit viele Daten erfassen. (Erfahrungsgemäß braucht man für 5 km 1 Stunde Arbeitszeit zum Auswerten, in Bahnhöfen mit vielen Gleisen und Signalen entsprechend länger)

Auf elektrifizierten Strecken erfolgt die Georeferenzierung anhand der Oberleitungsmasten. Man sieht sie markant im Video und ihren Schattenwurf auf den Bing-Bildern. Dabei zählt man die Oberleitungsmasten ab einem markanten Punkt (z.B. Bahnübergang, Brücken oder andere markante Objekte neben der Strecke). Zwischen zwei Masten wird interpoliert oder – bei Signalen mit hoher Bauhöhe – ist der Schattenwurf des Signalmastens auf dem Luftbild sichtbar.

Auf nicht elektrifizierten Strecken und Strecken, deren Oberleitungsmasten auf den Bing-Luftbildern verschattet sind, gibt es keine leichte Möglichkeit aus den Bildern Positionen abzuleiten. Hier muss man sich mit der Vegetation neben der Strecke und den Schattenwürfen der Signale behelfe. Kleine Signaltafeln neben der Strecke sieht man aber nicht auf Bing (ausgenommen Bilder mit 15 cm Auflösung).

Wenn man während des Filmens einen GPS-Track aufnimmt, kann man einzelne Frames (je nach Geschwindigkeit alle ein bis drei Sekunden) extrahieren und diese mit dem GPS-Track georeferenzieren. Zur Extraktion der Frames habe ich folgenden ffmpeg-Befehl verwendet:

ffmpeg -i km144.4--Abzw-Ribbeck--Rathenow--km228.4.mts -vf yadif,fps=1 -qscale:v 2 extracted_frames/img_%05d.jpg

Der obige Befehl extrahiert ein Frame pro Sekunde und schreibt es als img_00001.jpg in das Verzeichnis extracted_frames/ (bei den weiteren Dateien wird nur die Nummer hochgezählt). Das verwendete Video wurde interlaced aufgenommen, also im Zeilensprungverfahren. Deshalb wird noch ein Deinterlace-Filter verwendet. Wer diesen nicht braucht, kann yadif, weglassen. -qscale:v 2 legt die JPEG-Kompressionsstufe fest, wir haben uns für die zweithöchste Qualitätsstufe entschieden, damit auch kleine Signalnummern noch entziffert werden können. Die resultierenden Frames sind dann etwa 350 kB und 1920x1080 Pixel groß (das ist vom Video bzw. der Kamera abhängig).

Die extrahierten Frames können in JOSM genutzt werden und/oder auf Mapillary hochgeladen werden.

Mapillary stellt zur Vorverarbeitung einige Skripte auf Github bereit. (Es wird Python 2.x verwendet)

  1. Mit python add_fix_dates.py extracted_frames/ '2015-08-23 14:05:01' 1 setze ich den Zeitstempel. 1 steht für ein Bild pro Sekunde.
  2. Mit python geotag_from_gpx.py extracted_frames/ my_gps_track.gpx 0 setze ich dann im EXIF die Position und die Blickrichtung. Letztere wird aus der Position des Bildes und des nächsten Bildes ermittelt.

Anschließend kann man die Bilder in JOSM laden (die Blickrichtung wird dort angezeigt!) oder auf Mapillary hochladen.

Ich habe auch den Video-Upload von Mapillary gestern Abend ausprobiert. Aber bis heute Mittag ist das Video nicht online, meine Fotos haben hingegen nur wenigen Minuten gebraucht, bis sie online waren.

Beim Blick nach hinten oder vorne genügt bei einer Fahrtgeschwindigkeit zwischen 160 km/h und 200 km/h (IC-Reisegeschwindigkeit auf Aus- und Neubaustrecken) eine Framerate von 1 Bild pro Sekunde. Bei 100 km/h genügen 0,5 Bilder pro Sekunde. Beim Blick nach schräg zur Seite heraus ist eine Framerate von 1 Bild pro Sekunde bei 120 km/h gerade noch so brauchbar.

Momentan verwendet meine Toolchain noch für das gesamte Video die gleiche Framerate. Wenn das Video jedoch von einem Bahnhof zum nächsten reicht, ist das ungeschickt, weil man in Bahnhofsnähe langsamer fährt.

Screenshot Foto zur Seite raus

Screenshot JOSM Foto nach hinten

In Anspielung auf das Video-Informations-System (VIS) von DB Netz nenne ich diesen Ablauf Low-Cost-VIS. Das VIS zeigt die Strecken von DB Netz aus der Lokführerperspektive. Die Bilder werden mit Messzügen alle paar Meter aufgenommen und sind georeferenziert. [1] Sie haben jedoch eine geringe Auflösung (deutlich niedriger als HD), was aber durch den geringeren Abstand der Bilder wieder aufgefangen wird. (Messzüge fahren 80 km/h) Würde man statt Smartphones oder Garmins genauere GNSS-Empfänger einsetzen, könnte man auch genauere Koordinaten erhalten. Eine Kombination aus GNSS-Empfänger und einer Consumer-Camcorder samt Akkupack könnte man auch unabhängig von Messzügen einsetzen und dann mit normalen Zügen über das Netz schicken.

[1] Siehe dazu auch “Der neue Lichtraummesszug LIMEZ III der Deutschen Bahn AG” von Holger Wirth, erschienen in der ZfV 3/2008.

Analyse des Open-Data-Angebots der DB

Posted by Nakaner on 14 November 2015 in German (Deutsch). Last updated on 21 November 2015.

Die Deutsche Bahn hat vor einigen Tagen ihr Open-Data-Portal eröffnet und ein paar erste Datensätze eingestellt. Ich mir diese Datensätze jetzt mal angesehen und mit eigenem Wissen und OSM-Daten verglichen.

Die meisten Datensätze stehen unter der CC-BY 4.0. Da die CC-BY eine Namensnennung verlangt, dürfen diese Daten derzeit noch nicht für OSM genutzt werden. Die DB ist gewillt, uns eine Ausnahmegenehmigung zu erteilen. Ich rechne damit, dass wir diese im Laufe der kommenden Woche erhalten.

UPDATE: Die Erlaubnis liegt uns NOCH NICHT VOR. Bitte die Daten nicht in OSM nutzen!

Stuttgart 21

Die Datensätze von DB Projekt Stuttgart–Ulm GmbH sind die einzigen Datensätze, die derzeit unter der CC-0 verfügbar sind (und deshalb rechtlich keinerlei Beschränkungen unterliegen). Es stehen drei Datensätze zur Verfügung. Sie sind derzeit die einzigen echten Geodaten, alle anderen Datensätze im Portal sind reine Sachdaten.

  • “Geodaten der Tunnelachsen”
  • “Geodaten der Gleisanlagen”
  • “Geodaten der Webcam-Standorte”

Alle drei Datensätze werden als Shapefiles mit EPSG:3857 (Web Mercator) bereitgestellt. Es ist davon auszugehen, dass bei der DB selbst ein andere Bezugssystem zur Planung verwendet wird – höchstwahrscheinlich das DB-Ref, eine Gauß-Krüger-Abbildung, die jedoch von den Gauß-Krüger-Systemen der Vermessungsverwaltungen abweicht [1]. Wie die Daten in Web Mercator transformiert wurden (das ist keine einfache Umrechnung, sondern ein Datumsübergang) wird nicht offengelegt. Diese Frage muss geklärt sein, bevor die Daten in OSM übernommen werden.

In den Datensätzen sind nur die Planfeststellungsabschnitte enthalten, die auch schon planfestgestellt sind. Der Abschnitt um den Flughafen herum fehlt. Hier läuft noch immer das Planfeststellungsverfahren.

Der Datensatz “Geodaten der Gleisanlagen” enthält bei den Tunnel die Flächen der Tunnel, der Querschläge, der Rettungszufahrten, die Rettungsplätze an den Portalen, die Stollen der Zwischenangriffe sowie einige oberirdische Streckenabschnitte (viele sind es ja nicht). Auch die neuen Tunnel der Stadtbahnstrecken um den Hauptbahnhof, die verlegt werden, sind enthalten.

Der Datensatz “Geodaten der Tunnelachsen” enthält die Achsen der Tunnel. Hier sind nur die Tunnel mit Gleisen enthalten (also keine Querschläge und Zwischenangriffsstollen). Beim Fildertunnel fehlt die Oströhre, welche im Datensatz “Geodaten der Gleisanlagen” enthalten ist. Bei der Stadtbahntrasse unter der Heilbronner Straße fehlt auch ein Teil einer Röhre, der im anderen Datensatz als Fläche enthalten ist. Zwischen Bad Canstatt und Untertürkheim sind auch oberirdische Abschnitte enthalten, die im anderen Datensatz fehlen.

“Geodaten der Webcam-Standorte” enthält die Webcam-Standorte als Punkte. Dieser Datensatz ist nur bedingt brauchbar. Er enthält Links auf die Bilder der Kameras. Die Punkte befinden sich nicht am Standort der Kamera, sondern mitten im Blickfeld der Kamera. Dieser Datensatz ist ungeeignet.

Aufgrund der fehlenden Informationen zum Datumsübergang treffe ich hier keine Aussagen über die Lageunterschiede zwischen den bestehenden OSM-Daten und den Daten der DB.

Stationsdaten

Die Datensätze “Stationsdaten” und “Bahnsteigdaten” sind nach DB Station & Service AG und DB Regionetz Infrastruktur (RNI) getrennt. RNI ist eine Tochter der DB, die in einigen Netzen regionaler Bedeutung die Gleise und Bahnhöfe betreibt. Der Rest (der Großteil aller DB-Stationen) wird von DB Station & Service AG betrieben.

Diese Datensätze stehen als CSV und XSLX zur Verfügung. Die Tabelle Stationsdaten enthält folgende Spalten:

  • Bundesland
  • BM (Bahnhofsmanagement) – enthält einen der folgenden Werte: Aachen, Augsburg, Bamberg, Berlin, Berlin Hauptbahnhof, Bielefeld, Bonn, Braunschweig, Bremen Hbf, Chemnitz, Cottbus, Darmstadt, Dortmund, Dresden, Duisburg, Düsseldorf, Erfurt, Essen, Frankfurt (Oder), Frankfurt a.M., Freiburg, Friedrichshafen, Gera, Gießen, Göttingen, Hagen, Halle (Saale), Hamburg, Hannover, Kaiserslautern, Karlsruhe, Kassel, Koblenz, Köln, Leipzig, Magdeburg, Mainz, Mannheim, München, Münster (Westf), Nürnberg, Osnabrück, Potsdam, Regensburg, Rosenheim, Rostock, Saarbrücken, Schleswig-Holstein, Schwerin, Stralsund, Stuttgart, Ulm, Würzburg
  • Bf. Nr. (Bahnhofsnummer) – eine ein- bis vierstellige Nummer für jeden Bahnhof, Nr. 1 bis 7079 sind anscheinend alphabetisch vergeben, neuere Stationen haben Nummern ab 7081 erhalten. Die Nummer wird im Datensatz Bahnsteigdaten verwendet, in der Reiseauskunft kann man sie nicht verwenden.
  • Station – der Name der Station (Kommentar siehe unten)
  • “Bf DS100 Abk.” – Betriebsstellenkürzel nach DS100, ein alphabetischer Code (gelegentlich mit Leerzeichen), bei Stationen, die aus mehreren Betriebsstellen bestehen (z.B. Berlin Hbf) ist nur ein Kürzel angegeben
  • Kat. Vst – Kategorie der Verkehrsstation. Die DB hat für jede Station eine Bahnhofskategorie festgelegt (siebenteilige Skala). Danach werden die Stationsgebühren berechnet, die ein Eisenbahnverkehrsunternehmen bei einem Halt dort zu entrichten hat. Eine Liste in PDF-Form dürfen wir schon seit 2008 nutzen, getaggt wird das mit railway:station_category. Derzeit besteht jedoch der Trend bei den Bahnmappern, diese Daten durch ein selbstkreiertes internationaleres Schema zu ersetzen, welches näher an der Fahrplanrealität ist und von kaufmännischen Interessen befreit ist.
  • Straße
  • PLZ
  • Ort
  • Aufgabenträger – die Gesellschaft, die dort den Schienenpersonennahverkehr bestellt
  • Verkehrsverbund – “0”, falls keiner existent
  • Fernverkehr – “ja” oder “nein” (siehe unten)
  • Nahverkehr – dto.

In der Spalte “Station” kommen Abkürzungen vor. Regionen, die als Namenszusatz verwendet werden (z.B. “Württ”) sind abgekürzt. Ortsnamen sind ausgeschrieben. In Berlin scheint sich die Schreibweise des Stationsnamens meist an die Beschilderung vor Ort zu halten. Außerhalb Berlins stimmt das nicht. In den Daten steht “Wolfgang (Kr. Hanau)”, vor Ort steht aber nur “Wolfgang”. Selbiges gilt für “Forchheim (b Kalrsruhe)”, welche auf den Schildern auf dem Bahnsteig “Forchheim”, auf dem gelben Aushangfahrplan vor Ort “Forchheim (b Karlsruhe)” heißt. Die zum Fahrplanwechsel im Dezember 2014 erfolgte Umbenennung von “Bad Friedrichshall-Jagstfeld” in “Bad Friedrichshall Hbf” ist enthalten.

Die Daten in den Spalten Straße, PLZ und Ort sind mit denen auf bahnhof.de identisch. Diese stammen aus Geocoding. Man sieht das ganz schön an Haltepunkten, in deren Umgebung keine Gebäude (also Objekte mit Hausnummer) stehen. Für Seddin wird als Adresse “Kunersdorfer Str. 1, 14554 Seddin” geführt. Dieses Gebäude steht aber auf der anderen Seite des Güterbahnhofs und ist 380 bis 390 Meter vom Haltepunkt entfernt! Desweiteren sind diese Daten veraltet. Aufgrund einer Kommunalreform heißt die Gemeined mittlerweile “Seddiner See”, Ortsteil Neuseddin. Mit dem Haltepunkt Baitz ist es sogar noch schlimmer. Hier wird als Adresse “Bahnhofstr. 1, 14822 Brück” genannt. Das ist 5,2 km Luftlinie entfernt! Ok, wer dort landet ist nur noch 760 m Luftlinie vom Bahnhof “Brück (Mark)” entfernt, der an derselben Strecke eine Station weiter Richtung Berlin liegt. ;-)

Interessant ist, dass bei den neuen Stationen entlang der Strecke Bad Friedrichshall Hbf–Sinsheim-Steinsfurt, die erst seit Anfang Mai bedient werden, die Adresse fehlt. Auf bahnhof.de steht hingegen eine.

Ich frage mich, weshalb DB Station & Service AG die Adressdaten überhaupt unter der CC-BY 4.0 veröffentlicht hat. Hat man dort keine Kenntnis vom Datenbankschutzrecht?

Fazit: Wer sich auf die Adressen in diesen Daten und auf bahnhof.de verlässt, ist verlassen. In OSM gehören die Daten auch nicht. Sie sind erstens urheberrechtlich unsauber und zweitens verschlechtern sie die Datenqualität von OSM.

Die Spalten Aufgabenträger und Verkehrsverbund habe ich nicht geprüft. Bei der Spalte “Fernverkehr” gab es wieder Anlass zum Lachen. In weiten Teilen ist die Spalte “Fernverkehr” zwei Jahre alt, stellenweise fünfzehn.

  • Dillenburg, Haiger, Herborn (Dillkreis) (vor zwei Jahren ein EC-Zugpaar)
  • Bad Nauheim (letztes Jahr einzelne Züge in der Tagesrandlage),
  • Bullay DB, Cochem, Wittlich Hbf, Trier Hbf (seit einem Jahr fahren keine Fernzüge mehr nach Trier)
  • Bremerhaven Hbf, Bremerhaven-Lehe Pbf
  • Lehrte
  • Tarp
  • Munster (Örtze)
  • Klinge, Forst (Lausitz)
  • Kronach
  • Pegnitz
  • Schweinfurt Hbf
  • Lutherstadt Eisleben, Sangerhausen, Nordhausen, Leinefelde, Heilbad Heiligenstadt
  • Magdeburg-Buckau
  • Kehl
  • Eberbach (da ist bestimmt niemand in der Zeile verrutscht, weder Dallau noch Eicholzheim haben/hatten Fernverkehr)
  • Heilbronn Hbf (schön wär’s, den IR Rennsteig hat man uns 2001 genommen. Oder glaubt DB Station & Service AG an den Erfolg von Der Schnellzug?)

Dessau Hbf hat der Tabelle zufolge keinen Fernverkehr. Das stimmt leider nicht. Freitags hält gegen halb fünf nachmittags der IC 1933 (hat keinen Gegenzug). Er tat das auch schon zeitweise im Fahrplanjahr 2014. Auch Hünfeld fehlt. Dort hält der Mo-Fr IC 1950 Berlin–Leipzig–Bebra–Frankfurt (Di-Fr nur ab Bebra). Der Gegenzug dazu, der IC 2398 hält nicht in Schlüchtern.

Bahnsteigdaten

Auch dieser Datensatz ist nach DB Station & Service AG und RNI getrennt. Wie schon in den Kommentaren im Open-Data-Portal von anderen Usern kritisiert, werden Kommata als Dezimaltrenner verwendet. Folgende Spalten sind vorhanden:

  • bf_nr (Bahnhofsnummer, siehe dazu das Stationsverzeichnis)
  • bahnsteig – Bahnsteigbezeichnung (ein Bahnsteig hat mehere Kanten!), z.B. B01 für Gleis 1, B02 für Gleis 2+3
  • bahnsteigkante_bw_auf_bs – wie vor Ort angeschrieben, z.B. “1”, “2”, “3”
  • örtliche_bezeichnung – z.B. “Gleis 1”, “Gleis 2”
  • nettobaulängen_m – Länge der Bahnsteigkante. Die nutzbare Bahnsteiglänge ist kürzer, das merkt man an Stumpfgleisen, da hier noch ein paar Meter für den Prellbock verlorengehen
  • höhe_bahnsteigkante_cm – Höhe über Schienenoberkante

Bei all meinen Stichproben mit Bahnhöfen, die kürzlich neue Bahnsteige erhalten haben, waren die Bahnsteighöhen aktuell: Weinheim (Bergstraße), Bad Friedrichshall Hbf, Crivitz, Roßlau (Elbe) Pbf, Coswig (Anhalt). Wie es mit Höhen im Altbestand aussieht, habe ich nicht geprüft.

Ein Problem sind hingegen die Bahnsteige, die in ihrer Länge unterschiedlich hoch sind. In Osterburken ist der Bahnsteig an Gleis 1 südlich des Reisendenübergangs 76 cm über Schienenoberkante hoch (S-Bahn-Standard), nördlich davon sind es unter 40 cm. In den DB-Daten steht der Bahnsteig sei 76 cm hoch und 235 m lang. Verschwiegen wird, dass ca. 90 m davon nicht 76 cm hoch sind. An Gleis 2 ist es genauso.

An ausgewählten Stationen habe ich die Bahnsteiglängen mit denen in OSM verglichen. Die OSM-Bahnsteiglängen sind nicht immer verlässlich. Oft sind Bahnsteige von Bing abgezeichnet. Gerade bei unbefestigten Bahnsteigen, deren Oberfläche wie eine gemähte Wiese aussehen, kann man auf dem Luftbild schlecht Anfang und Ende ermitteln. Daher habe ich Bahnsteige verglichen, an denen ich schon vorbeigefahren bin und sie dabei per Videomapping erfasst habe. An allen Bahnsteigen lagen die Unterschiede im Bereich der Messgenauigkeit. Diese Daten sind ok (und aktuell).

Betriebsstellenverzeichnis

Dieser Datensatz enthält die DS100-Kürzel für Betriebsstellen. Auch nicht bundeseigene Eisenbahnen und ausländische Betriebsstellen sind enthalten. Unter Betriebsstellen versteht man Bahnhöfe, Anschluss-, Ausweichanschluss-, Abzweig-, Überleitstellen, Haltepunkte, Blockstellen, Streckenwechsel, Betreiberwechsel usw. Der Datensatz hat folgende Tabellen:

  • Abk (Abkürzung)
  • Kurzname
  • Ländercode
  • Locationcode
  • Gültig ab

Kurzname ist wirklich ein Kurzname. Für maschinelle Anwendungen ist er nur sehr eingeschränkt geeignet. Den Langnamen kann man sich leider nicht einfach aus dem Stationsverzeichnis holen (in beiden steht das DS100-Kürzel), da erstens nicht alle Betriebsstellen Bahnhöfe oder Haltepunkte des Personenverkehrs sind und zweitens eine Station (von DB Station & Service AG) aus mehreren Betriebsstellen bestehen kann.

Bei den Nicht-DB-Betriebsstellen sind die Spalten “Ländercode”, “Locationcode” und “Gültig ab” nicht ausgefüllt. Ausländische Betriebsstellen kann man aber an einem X als ersten Buchstaben im Kürzel erkennen.

Der Ländercode entspricht nicht dem politischen Land entspricht, in dem die Betriebsstelle liegt. Er ist vielmehr eine Kennzeichnung, dass die Betriebsstelle von der DB betrieben wird. DB-Bahnhöfe auf Schweizer Staatsgebiet, die aufgrund des Staatsvertrags von 1852 von der DB betrieben werden, tragen ein deutsches Kürzel (R* für Direktion Karlsruhe) und haben den Ländercode “DE”.

Netzradar

Den Netzradar-Datensatz habe ich mir nicht genauer angesehen, da er für OSM nicht interessant ist.

[1] Da Vermessung Ländersache ist, gab/gibt es in Deutschland 16 verschiedene geodätische Bezugssysteme. An den Ländergrenzen gibt es Spannungen zwischen den Systemen von bis zu 2 Meter! Aus diesem Grund pflegt die DB ihr eigenes geodätisches Bezugssystem, da ihre Trassen eben des Öfteren über Bundesländergrenzen hinweggehen.

EDIT: Typo

A Review of the Manifests of all OSM US Board Election Candidates

Posted by Nakaner on 12 October 2015 in English. Last updated on 13 October 2015.

As a part of my work for the German Wochennotiz and multilingual weeklyOSM, I have stumbled across the manifestos of the candidates of the OSM US Board elections this week. Because a summary of all nine manifestos would be too long for a posting at weeklyOSM and Wochennotiz, I decided to write it down at my user diary .

Disclaimer

This posting contains my own opinion which is not neutral. Please read the mainfestos on your own.

I am not a member of OSM US and I do not want join. My home is Germany and my main mapping is done there.

I am not a lover of HOT and remote mapping in area where you have never been before.

Martijn van Exel

Martijn van Exel is a long time (“addicted”) OSM contributor and member of the current OSM US Board. He brings up a painful subject – the community size. According to graphs at his posting, the number of active mappers in the U.S. stopped increasing about 1 1/2 years ago. These are no good news.

graph showing the zero growth of OSM in the U.S.

Figure: Zero growth of OSM in the U.S., graph by OSMStats/Martijn van Exel

He think that big conferences [like the SotM US this year in New York] will not help increasing the number of active contributors. He would like to supports smaller, local events at the places where the people live.

His manifesto looks well. I suggest you to elect him. He might change OSM US the positive way.

Elliott Plack

Elliot Plack is a very experienced (“addicted”) mapper, too. He wants to work on the cooperations between OSM and the government organizations (on local level) and make them donate their data to OSM.

I think that his way cannot address the zero-growth problem shown by Martijn. He tries to compensate the missing contributors by importing data. I think that the US community has tried this already several times and it does/did not really work (see TIGER). No imported data is perfect. Imported data has to be kept up to date, this can only be done by a large active community. And how to explain someone that there are no buildings beyond the boundary of New York City?

You might vote for Elliott but I myself would not give him my first vote.

Alyssa Wright

Alyssa is no active OSM contributor. She did (account 1, account 2) mainly HOT stuff in Harare and Kathmandu, and only added a few POIs in New York City. HDYC could not find her first account and described her second account as “casual mapper”. To summarize: Her editing experience is, compared to Martjin and Eliott, very low, and that is from my point of view a big contra-argument. She is the president of the current OSM US Board.

She mainly praises herself and her work for SotM-US 2015 in New York at her manifesto and wrote only one paragraph about the next year. She says that she wants to support the growth of OSM in the U.S. (If you read Martijn’s manifesto, you might have noticed that this is wrong. OSM does not grow in the U.S. anymore.) She wants to help hosting a second great SotM-US and make the community grow this way.

I think that she has a totally different understanding of the word “community” than Martijn. Her community are the users at Twitter, the press and other organizations but not the real community which made OSM to be so large and great (see Europe).

I have had lots of conversations with other OSM contributors over the last years. Most people started mapping because they needed a map or already used OSM and wanted to give something back. A nice blog of the OSM Foundation (or its local chapters) or a Twitter account tweeting all day long did not make them joining OSM.

I suggest not to vote for her. I think that she has not realized the bad situations OSM (US community) is in.

Eric Theise

Eric is, according to HDYC, an OSM newbie (46 changesets, 40 times iD, 6 times Potlatch¹). I doubt that a newbie is the right person for such a position.

I still summarize and evaluate his manifesto. He wants to increase the awareness of open data and open source and get OSM in peoples’ minds. He focusses on communication and not on the community. He himself says that he is a minor mapper and a minor developer. Having a look at his Github profile (two clicks away from his manifesto) I only see few OSM-related code. He contributed a little bit to the OSM website (rank #46 of 85, 4 commits, +280 lines of code!). He mentions his contributions to the programming committee of SotM US 2014 in Washington DC. In contrast to other manifestos, his manifesto has a “Qualifications and Experience” section which looks – sorry – strange. He says “[he has] been involved in a number of quarterly mapathons”. I cannot believe this looking at his osm.org profile because he has too few edits. What’s the name of his second account he has used for these mapathons?

Some parts of my writing about Alyssa apply here, too. He also has not realized the bad situation OSM US is in.

I think that he has too litte experience at OSM. I would not give him my vote.

Ian Dees

Ian (wiki user page) is a very very long time contributor to OSM, he started contributing to OSM in 2006! HDYC says that he is a “heavy mapper 2.0”, i.e. experienced. (Getting “addicted mapper” with 9 years experience might be difficult)

He is already the board’s treasurer. His manifesto agrees with the manifestos of Martijn, Drishtie and Alex. He also says that the number of contributors has to be increased. The board has made a great job organizing multiple great SotM US conferences but it failed increasing the community. The board should fund and support local events (e.g. mapping parties). He mentions that the current and past boards wanted to start sending a monthly newsletter but nothing happened. Short summary: Improve the basis all over the country and don’t focus too much on large events.

He seems to be a suitable person for OSM US board. I suggest to give him your vote.

Jonathan Witcoski

Jonathan is a “Heavy Mapper 2.0” but started editing last year and still uses an editor which I call “the newbie editor”.

His manifesto is located here. He has joined OSM at a HOT event. Scrolling through his recent changesets, I can only see remote mapping (humanitarian editing) and mapping from aerial images but less or no mapping on the ground. I doubt that this user has really experience how OSM works.

Two thirds of his manifesto are just her bio and a praise of his experience at a government project. I doubt this will really be of use for OSM. He wants to “encouragi[e] participation from colleges and universities”. Does he really knows what he is writing about? Has he ever observed edits by students of a university or school course at OSM? If he had, he would noticed the noteworthy amount of changeset by students which are either vandalism and edits which need to be corrected.

He writes that future professional geographers should know that there are not only commercial data sources. I agree but I have to note that students get teached the existence of OSM as a usable data source if OSM is a usable data source. I can observe this during my own studies², I knew OSM before my studies and I did not make much advertisement for OSM at university. OSM was mentioned at university without my advertisment.

That’s why I suggest you not to give Jonathan your vote.

Lauren Jacobson

HDYC labels Lauren as a “Hit and Run mapper” (24 changesets, only iD, but 7 times more nodes than Eric) –
That’s just a little step above “newbie”. I have had a look at her Github profile which is linked from her Wiki user page. I could not find noteworthy code contributions at all (including non-OSM repositories). I really ask myself why she candidates.

Her manifesto is long. The first and second paragraph are a bio of herself. She mentions her presence at some OSM conferences and mentions the gender diversity events and programs. She writes that she is working on an building import in Zambia and participated at some HOT events.

She wants to “promote local project creation and involve more community leaders with OSM projects”, “encourage diverse participation at State of the Map US” (i.e. gender-related scholarships and such stuff) and “enhance the benefits of joining the OSM US Foundation”. All this sounds good but she does not address the main concerns and problems OSM has in the U.S. at the moment.

I cannot suggest you to give her your vote due to her missing experience with OSM.

Drishtie Patel

Drishtie is a newbie and has edited mainly outside the U.S. Her edits are mainly HOT-related.

Her manifesto seems to be the longest of all manifestos. She write very much about her work all aroung HOT and humanitarian mapping and uses photos to attract votes. She wants to increase cooperation between humanitarian orangizations and universities to get the student map if there is a crisis.

What me really shocks are following two sentences:

I would use this opportunity to be more connected with the OSM community in the United States. There is a vast amount of talented OSM’ers in the country using open data in different ways and I am excited to learn more and expand my knowledge.

This means that she has at the moment no or only little knowledge about the active community in the U.S. and wants to get in touch with the community after getting elected! Sorry, please go to a local community meeting or organize one yourself (just an evening at a pub).

If you give your vote to her, you waste your vote. Sorry.

Alex Barth

Alex (wiki) works at Mapbox and leads Mapbox’s data team (the people getting payed for editing at OSM). He started editing in 2012, HDYC says he is a “Heavy Mapper 2.0”. He is the vice president of the current OSM US board.

His manifesto is located at his user diary. Like most candidates, he first introduces himself shortly summarizing his work and Mapbox’s editing-related tools. Afterwards he describes the work of the current and past OSM US boards and the success of SotM US.

But the succes of SotM US is no real success

While some of these numbers [of attendants at SotM US] are impressive and the seeds we have planted are developing, the people we haven’t reached yet are still in the majority.

Alex wants to connect OSM to people who either may have a benefit from using OSM or may be good OSM contributors. He wants to “tap into existing networks” and to strengthen local communities by mini grants, mapping events and bringing OpenStreetMap to other conferences.

In difference to some of his competitiors, he is no newbie and well known inside the community.

Summary

You can vote for up to five candidates. My personal rank is

  1. Martijn van Exel
  2. Ian Dees
  3. Alex Barth
  4. Elliott Plack

I would throw my fifth vote away because all other candidates are not suitable for OSM US board.

Footnotes

¹ Potlatch is not a newbie editor. I know some experienced mappers which still like and use this editor.

² I study geodesy and geoinformatics.

Symbolbild eines Fahrscheinentwerters

Abbildung: Fahrscheinentwerter (Symbolbild, reverent @ pixabay, CC-0)

Manches mappt man nur des Mappens wegen. Getreu diesem Motto, habe ich kürzlich bei einem Besuch in Berlin begonnen, gezielt die Nummern von Fahrscheinentwertern zu mappen. Man könnte sich jetzt fragen, was daran besonders sei. Einfach Nummer aufschreiben und fertig? Nein, so einfach ist es nicht. An manchen Entwertern steht außen keine Nummer angeschrieben oder es ist – wie bei der S-Bahn Berlin – nur eine örtliche Nummer angeschrieben, nur innerhalb der jeweiligen Station eindeutig und einmalig ist.

Um an die wahre Nummer des Entwerters zu gelangen, habe ich einfach einen langen Papierstreifen, der etwa so breit wie ein VBB-Fahrschein ist, in den Entwerter geschoben und abstempeln lassen. Danach habe ich den kleinen, bedruckten Teil abgeschnitten und mit den verbleibenden Papierstreifen von einem anderen Entwerter abstempeln lassen.

Foto der vier Entwerterstempelabdrücke aus Berlin-Hermsdorf Abbildung: Vier Entwerterstempelabdrücke habe ich in Berlin-Hermsdorf gesammelt

Neben Berlin-Hermsdorf habe ich auch in Berlin-Tegel die Nummern der Entwerter ermittelt. Auch dort ging bei mindestens einem Entwerter die Uhr nennenswert vor. (Für Fahrgäste ist das von Vorteil, denn Einzelfahrscheine gelten in Berlin ABC zwei Stunden lang)

Die Entwerter tagge ich wie folgt:

  • amenity = ticket_validator
  • loc_ref = (außen angeschriebene Nummer, wenn diese nicht regional einmalig zu sein scheint)
  • ref = (Nummer laut Stempelwerk, wenn die äußere Nummer in loc_ref=* landet)

Heute stellte sich mir die Frage, auf die die Overpass-API eine Antwort weiß.

Wie viele Newbies gibt es eigentlich in einem Gebiet, die Eisenbahnsignale mappen? Der Begriff “Newbie” stimmt nicht ganz, eigentlich erhält man alle Nodes, die nicht von einer vorher definierten Menge an Mappern zuletzt editiert wurden.

In den OSM-Daten sind neben den Tags nämlich auch ein paar Metadaten enthalten:

Beispiel:

<node id="3515197709" lat="48.8605008" lon="9.3274573" version="5" 
timestamp="2015-07-21T19:02:45Z" changeset="32785733" uid="2450569" 
user="regedemu">
    <tag k="railway" v="signal"/>
    <tag k="railway:signal:direction" v="forward"/>
    <tag k="railway:signal:main" v="DE-ESO:hp"/>
    <tag k="railway:signal:main:form" v="light"/>
    <tag k="railway:signal:main:height" v="normal"/>
    <tag k="railway:signal:main:states" v="DE-ESO:hp0;DE-ESO:hp1"/>
    <tag k="railway:signal:position" v="right"/>
    <tag k="ref" v="N501"/>
    <tag k="source" v="survey"/>
</node>

Wir sehen in obigen XML-Listing folgende Metadaten:

  • Version des Objekts (version)
  • Zeitstempel (timestamp)
  • Änderungssatz-ID (changeset). Dieser Änderungssatz hat das Objekt zuletzt bearbeitet.
  • User-ID (uid). Dieser User hat das Objekt zuletzt bearbeitet. Diese bleibt gleich, auch wenn der User sich umbenennt.
  • User (user). Dieser User hat das Objekt zuletzt bearbeitet.

Uns interessieren timestamp uind user. Mit dem Zeitstempel filtern wir nur die neusten Änderungen, mit User filtern wir alle Objekte weg, die von Eisenbahn-Powermappern geändert wurden.

Das ist die Overpass-Abfrage dazu:

// Datum ggf. anpassen
node
  [railway=signal](newer:"2015-05-01T07:00:00Z")
  ({{bbox}})->.newnodes;
 
// Liste aller User, die man schon kennt und nicht in den Ergebnissen haben möchte
// i.d.R. sind das Poweruser
(.newnodes; - node.newnodes(user:Nakaner);)->.newnodes;
(.newnodes; - node.newnodes(user:"Nakaner-repair");)->.newnodes;
(.newnodes; - node.newnodes(user:bigbug21);)->.newnodes;
(.newnodes; - node.newnodes(user:mapper999);)->.newnodes;
 
// Ausgabe
.newnodes out meta;

Die Abfrage muss man für jede Region anpassen. Denn Eisenbahnmapper haben meist eine Mappingregion, in der sie aktiv sind. Tut man das nicht, erhält man zu viele False Positives, d.h. unter Umständen alle Signale einer Strecke, weil diese von einem User innerhalb weniger Tage eingetragen wurden.

Diese Abfrage habe ich zur Overpass-Beispielsammlung ergänzt.