Boundaries Map 4.1 released

Da gab es doch mal ein OSM-Übersetzungsteam … der Kontakt damit liegt bei mir aber etwas zurück … könnte ich versuchen wiederzufinden.

Gruß Klaus

PS: 350 € pro Monat für einen Mietserver scheint mir sehr hoch. Wie genau sind denn die Anforderungen?

wenn irgendwelche karten-tools-osm-werkzeuge eine gewisse “systemrelevants” haben, sollte man das einem nicht überlassen und unter einem “geldtopf” schlüpfen, ggf. auch mit teilabgabe der adminrechte darüber. vielleicht sollte man auch mal gespräche mit der finanzkräftigeren wikipedia stiftung führen oder der wikimedia deutschland.

ich persönlich trage kein geld bei, sondern nur meine zeit und meine daten, sowohl bei osm und wikipedia und noch andere projekte.

Ich hoffe doch dass die finanziellen Probleme ausgeräumt werden können.
Bezüglich der Übersetzung: Viele gehen erst einmal davon aus dass sich schon jemand anderes (ggf. noch besser qualifiziert) finden wird. Ein zweites mal nachfragen müssen ist nicht ungewöhnlich.

Hallo Walter,

Wie kommst du auf den Betrag? Mir kommt das gerade etwas teuer vor. mmds Vorschlag mit der Serverbörse ist eine günstige Option, aber auch “neue” Server für unter 100 Euro pro Monat sind mittlerweile echt potent.

Vielleicht ließe sich auch an der Software etwas optimieren? Für einen Förderantrag ist es von Nachteil, wenn der Quellcode unfrei ist.

Der FOSSGIS e.V. fördert aus – ich nenne es mal “Sicherheitsgründen” – nur gemietete Server, nicht den Kauf von Hardware, die dann außerhalb seines Einflussbereiches in Privatwohnungen steht. Aus ähnlichem Grund hat man vor einigen Jahren mal einen Förderantrag zum Kauf eines etwas stärkeren Rechners zum Erstellen von Garmin-Karten abgelehnt. Wenn der Server gemietet ist, aber für Zwecke außerhalb des Förderantrags bzw. der Vereinsziele des FOSSGIS e.V. verwendet wird, dann kann der FOSSGIS aufhören, dir die Ausgaben zu erstatten.

Du kommst ja auch, wie ich gesehen habe, voraussichtlich Ende Oktober nach Karlsruhe. Da kannst du ja mit Frederik mal direkt darüber reden.

Viele Grüße

Michael

jo, und deshalb versteht ich auch nicht, was die bots hier zu suchen haben.

Ja, in diese Richtung könnte/müsste sich das entwickeln.
Aber mir fallen bereits einige Wege ein, so ein Kontingent zu überlisten (Zweitaccounts usw.)

Gruss
walter

Hast du keine Maximalkontigente pro IP-Adresse und Tag? Oder ein Limit parallel laufender Abfragen pro IP-Adresse?

meinst also, meine Ansprüche wären zu hoch? Nun, ich kenne meine Kiste, weiss was die rattert und dass sie kurz vorm Ende ist. Klar, ein wenig SSD würde noch was bringen, aber bei 32 GB Mem ist Schluss mit dem Motherboard. Da hilft nicht Kleckern sondern nur Klotzen.

Jo, Frederik hab ich noch nicht direkt angesprochen.

Gruss
walter

Danke, es hat sich schon wer “erbarmt” und ist bald fertig.

Jo, ist schon heftig.

Eckdaten: 2x12 Core AMD, 64GB 4-6 TB HD Raid 1, 1 TB SSD Raid 1, wobei ich keine der noch verwendbaren Komponenten vom alten Server verwenden kann (geht ja wohl net, dass ich hetzner ein Päckchen schicke, gell?)

So gross, damit ich 2-3 Jahre Ruhe habe. Der alte Server ist von 2013.

Gruss
walter

Mit einer Neuinstallation der Softwareumgebung auf einem externen - nicht mir gehörenden - Server hätte ich wenig Probleme. Die Installation muss ich ja immer bei 'nem neuen Server machen. Und so sehr macht Admin ja auch nicht immer Spass. Nur bei FOSSGIS geht es nicht und andere Standorte hab ich noch nicht evaluiert.

Wenn ich da aber an die “never ending story” wegen dem Forenserver denke, komm ich schon ins Grübeln.

Kein Problem. Es muss ja nicht jeder was spenden - aber garkeiner? Das ist echt ätzend.

Danke und Gruss
walter

Man kann für die Boundary Map auch flattren, kommt darüber auch nichts rein?

danke, hat sich ja erübrigt :slight_smile:

Ausserden war das hier bereits schon die 2. Anfrage, da gestern 102 Kollegen das hier gelesen aber keiner reagiert hat. Daher hab ich heute wohl ein wenig nachlegen müssen und noch ein wenig Frust hinzugepackt.

Gruss
walter.

Jo, das hatte mit der Kollege von der FOSSGIS auch gesagt und ich kann das durchaus nachvollziehen. Ein Kollege von der Wochennews hat aber vorher gemeint, dass das kein Problem sein solle.

Ja, das werde ich wohl machen - und wenn mir mein Server nicht wieder vorher “abraucht”, kann das sogar was werden :slight_smile:

Gruss
walter

Hallo Walter,

Das ist leider ganz normal, dass kostenlose Dienste über Gebühr in Anspruch genommen werden (“missbrauchen” wäre das besser Wort). Dagegen hilft nur konsequentes Beschränken und Sperren der größten Nutzer. Wenn der Dienst freie Software und sein Setup dokumentiert ist, dann kann man guten Gewissens den Schuldigen mit “Schnorr’ nicht, sondern betreibe bitte deine eigene Boundaries Map” antworten. Die Betreiber bekannter, kostenloser OSM-Dienste wie den Tileservern (egal ob OSMF oder openstreetmap.de), Nominatim oder Overpass-API klagen (und haben sich damit abgefunden) über unerwünschte Crawler, schlecht programmierte Applikationen usw. Dagegen hilft nur Sperren, Sperren, Sperren. Und wenn das nicht hilft, kann man ja darüber nachdenken, mit Error 429 (too many request) im Header und einer zufällig erzeugten, auf einer Landmasse liegenden Geometrie antworten (bei Tileservern haben sich Tiles mit dem Schriftzug “Sie verletzten die Nutzungsbedingungen von …” bewährt).

So wie ich dich als Person kenne, dürfte dir das als Person vom Charakter her nicht schwer fallen, hart zu sein. :slight_smile:

Viele Grüße

Michael

Nö, pro IP noch nicht. Nur eine Erfassung pro User.

Bin gerade am Auswerten und bastel an einigen Grafiken.
siehe:

Ca 3600 aktive User (also die schon mal etwas heruntergeladen haben) und davon ca 30-50, die 50 % der Exporte gemacht haben.
Hier die Top 40:


              user               |    kb     |   mb   | gb  
---------------------------------+-----------+--------+-----
 Gian***********                 | 3515532.2 | 3433.1 | 3.4
 Step**********                  | 2438629.0 | 2381.5 | 2.3
 miss********                    | 2330763.4 | 2276.1 | 2.2
 Leo ****                        | 2244428.9 | 2191.8 | 2.1
 xixe**                          | 2153151.3 | 2102.7 | 2.1
 jung***                         | 2088401.4 | 2039.5 | 2.0
 Rica***********                 | 2049324.5 | 2001.3 | 2.0
 Bumk**                          | 1878546.1 | 1834.5 | 1.8
 etes****                        | 1836869.7 | 1793.8 | 1.8
 asbt******                      | 1753867.4 | 1712.8 | 1.7
 Phil******                      | 1662180.0 | 1623.2 | 1.6
 Davi********                    | 1641831.6 | 1603.4 | 1.6
 toms******                      | 1638104.7 | 1599.7 | 1.6
 MapM***********                 | 1627314.9 | 1589.2 | 1.6
 Pasc**********                  | 1437158.6 | 1403.5 | 1.4
 Дина*****                       | 1397904.0 | 1365.1 | 1.3
 imza***                         | 1353032.4 | 1321.3 | 1.3
 TaoX*                           | 1273960.2 | 1244.1 | 1.2
 dk_s**                          | 1268096.8 | 1238.4 | 1.2
 Laur****                        | 1218532.9 | 1190.0 | 1.2
 Fran*************************** | 1207758.0 | 1179.5 | 1.2
 DFau******                      | 1140017.4 | 1113.3 | 1.1
 Euge************************    | 1127936.8 | 1101.5 | 1.1
 bard********                    | 1100032.2 | 1074.3 | 1.0
 Nena********                    | 1031573.9 | 1007.4 | 1.0
 ybuh***                         |  968651.2 |  945.9 | 0.9
 AleW***                         |  950613.2 |  928.3 | 0.9
 Artu************                |  933669.7 |  911.8 | 0.9
 rgba****                        |  920925.5 |  899.3 | 0.9
 Marí*****************           |  855555.4 |  835.5 | 0.8
 sedi****                        |  829993.3 |  810.5 | 0.8
 Paul**************              |  786629.5 |  768.2 | 0.8
 Yann********                    |  757117.5 |  739.4 | 0.7
 Yari******                      |  700817.1 |  684.4 | 0.7
 Proj*******                     |  689861.1 |  673.7 | 0.7
 maad****                        |  670676.7 |  655.0 | 0.6
 Hsin**********                  |  652596.7 |  637.3 | 0.6
 rash******                      |  607115.3 |  592.9 | 0.6
 Stef*********                   |  599389.9 |  585.3 | 0.6
 Mafi***                         |  597799.2 |  583.8 | 0.6
(40 Zeilen)

Summe ca 130 GB, meine Tests hab ich rausgerechnet.

Zu Einschätzung: DE hat 114 MB, wenn man die komplexen Landgrenzen mit den Costlines als Shapes lädt.

klar, in diese Richtung wird der Zug wohl fahren müssen. Hab die Sache wohl etwas schludern lassen, da ich mit der Entwicklung der 4.1 sehr beschäftigt war. Aber als ich dann feststellen musste, dass ich letztendlich nur ausgenutzt werde, ist auch mir der Kragen geplatzt (obwohl ich fast nie Hemden trage ;))

Gruss
walter

Nabend,

die Übersetzung ist mittels eines netten Kolegen fertig und eigentlich könnte ich morgen die Boundaries Map 4.1 freischalten.

Ich überlege jetzt aber, ob ich noch einige Tage warte und in dieser Zeit eine vernünftige Kontingentierung einbaue. Es wäre jetzt echt die beste Gelegenheit dazu. Eine Art Accounting hab ich ja bereits.

Danke für die Hilfe und die konstruktiven Tips - aber ganz ist das Problem mit dem neuen Server nicht aus der Welt. Irgendwas muß passieren, sonst bricht mir die Kiste bald zusammen. Wer also noch konstruktive Tips hat - immer her damit.

Gruss
walter

Zero, nothing - und das von Anfang an :frowning:

Dazu eine kurze Nachfrage: ist darin ein kompletter Planet auf Postgres enthalten?
Könnte man den auch so eindampfen, dass nur noch z.B. Boundaries drin sind?

Ich habe da 2 Szenarien im Kopf:

  1. Planet-File täglich updaten, Boundaries extrahieren, Postgres damit füttern
  2. Overpass läuft die ganze Zeit mit Minutely updates (Planet benötigt etwa 200GB), je nach Bedarf Boundaries extrahieren, Postgres damit füttern

Ich kenne mich damit überhaupt nicht aus. Aber bei Wikipedia gibt es wohl so einen Hosting-Service für Werkzeuge und ähnliches: das Wikimedia Tool Labs

Wäre so etwas vielleicht auch für OSM eine sinnvolle Idee? Oder was spräche dagegen?

Nö, der Planet wird für alle möglichen - und unmöglichen - Anwendungen und Auswertungen verwendet.

manche Anwendungen sind auch “Realtime”, wenn der Update mal wieder flutscht.

Verwendet die Overpass nicht ein spezielles Datenbankschema? Zumindest war das früher so und erklärte mir auch die super Geschwindigkeit bei Abfragen.

200 GB ist natürlich winzig. Da passt bei mir gerade mal eine Tabelle rein.

Hier mal die Grössen der Basistabellen und einiger der Indixes:


 public | planet_osm_line                       | Tabelle | postgres   | 184 GB     | linestrings mit tags? - osm_id
 public | planet_osm_nodes                      | Tabelle | postgres   | 8192 bytes | rohdaten nodes (leer)
 public | planet_osm_point                      | Tabelle | postgres   | 15 GB      | Nodes mit Tags (POI) - osm_id
 public | planet_osm_polygon                    | Tabelle | postgres   | 127 GB     | Geschlossen Linestrings und Multipolygone - osm_id
 public | planet_osm_rels                       | Tabelle | postgres   | 2555 MB    | Rohdaten Relationen, id
 public | planet_osm_roads                      | Tabelle | postgres   | 16 GB      | 
 public | planet_osm_ways                       | Tabelle | postgres   | 86 GB      | Rohdaten ways, id

 public | planet_osm_line_index                 | Index | postgres   | planet_osm_line             | 23 GB      | 
 public | planet_osm_line_pkey                  | Index | postgres   | planet_osm_line             | 4274 MB    | 
 public | planet_osm_line_tags_index            | Index | postgres   | planet_osm_line             | 6785 MB    | 
 public | planet_osm_nodes_pkey                 | Index | postgres   | planet_osm_nodes            | 8192 bytes | 
 public | planet_osm_point_index                | Index | postgres   | planet_osm_point            | 5323 MB    | 
 public | planet_osm_point_pkey                 | Index | postgres   | planet_osm_point            | 2328 MB    | 
 public | planet_osm_point_place                | Index | postgres   | planet_osm_point            | 201 MB     | 
 public | planet_osm_point_tags_index           | Index | postgres   | planet_osm_point            | 2813 MB    | 
 public | planet_osm_polygon_index              | Index | postgres   | planet_osm_polygon          | 16 GB      | 
 public | planet_osm_polygon_pkey               | Index | postgres   | planet_osm_polygon          | 6341 MB    | 
 public | planet_osm_polygon_tags_index         | Index | postgres   | planet_osm_polygon          | 6999 MB    | 
 public | planet_osm_rels_idx                   | Index | postgres   | planet_osm_rels             | 10 MB      | 
 public | planet_osm_rels_parts                 | Index | postgres   | planet_osm_rels             | 2341 MB    | 
 public | planet_osm_rels_pkey                  | Index | postgres   | planet_osm_rels             | 218 MB     | 
 public | planet_osm_roads_index                | Index | postgres   | planet_osm_roads            | 2005 MB    | 
 public | planet_osm_roads_pkey                 | Index | postgres   | planet_osm_roads            | 478 MB     | 
 public | planet_osm_roads_tags_index           | Index | postgres   | planet_osm_roads            | 1106 MB    | 
 public | planet_osm_ways_idx                   | Index | postgres   | planet_osm_ways             | 332 MB     | 
 public | planet_osm_ways_nodes                 | Index | postgres   | planet_osm_ways             | 188 GB     | 
 public | planet_osm_ways_pkey                  | Index | postgres   | planet_osm_ways             | 13 GB      | 

Und da kommt noch manch anderes dazu.

Ein Full Import des Planeten ist bei mir derzeit illusorisch. Mit 24 oder auch 32 GB Memory klappt das nie. Frederik schrieb mal vor 2-3 Monaten, dass ein Import aus technischen Gründen inzwischen mindestens 64 GB braucht.

@frederik: ich kann deinen Beitrag leider nicht mehr finden, daher nur ein “Gedächtnisprotokoll”

Gruss
walter