Moin,
Hier stehen die Ergebnisse der letzten globalen Auswertung. Datenstand war von heute Nacht.
Gruss
walter
ps: In Serbien nix neues.
Moin,
Hier stehen die Ergebnisse der letzten globalen Auswertung. Datenstand war von heute Nacht 1:00 Uhr.
DEU: +3
BOL_ +2
BRA: -1, +2
CAN: -2, +1
ECU: +4
GBR: +20
IRL: +29
JPN: +19
PHL: +1
POL: -2, +12
PRT: -1, +16
RUS: +14
TUR: +1
UKR: -2, +8
USA: -2, +3
Gruss
walter
ps: In Serbien nix neues.
Fixed, jetzt gibt es nur noch die Hälfte zu tun 
Es gab da ein Problem an der Grenze DE,AT (Sorgschrofen, Jungholz). An Verzweigungspunkten wurden Grenzsegmente nicht getrennt (also neu zusammengefügt). Eventuell hat auch jemand versucht, eine MP-Warnung zu fixen, da OSM ja nicht alle OGC-konformen MPs unterstützt.
Ich hab den Kollegen gestern bereits angeschrieben und heute eine ziemlich ausführliche Antwort erhalten, mit deren Inhalt ich - natürlich - nicht einverstanden bin.
Tenor: “Ich weiss was ich mache”.
Hier der Schlußsatz:
Hab ihn mal auf diesen Thread hingewiesen und bin mal gespannt.
Mein Senf dazu: Wir wissen, dass das eine topologisch kritische Ecke ist und haben akzeptiert, dass manche QA-Tools damit nicht klar kommen. Irgendwelche Konstrukte aufzubauen, die nur den Sinn haben, OSMI zufrieden zu stellen, ist absolut untragbar (Mappen für den QA-Tool. ooooommmm…)
Gruss
walter
so, hab auch noch ein wenig rungflickt. jetzt sollte die ecke zumindest einigermaßen ok sein.
Die Änderungen hatten ja eine Vorgeschichte mit folgendem Änderungssatz:
Nach mühsamer Reparatur aller betroffenen Relationen war gleich der nächste Mapper zur Stelle, um die Genzlinien aufzutrennen.
Die Gründe für deine Einschätzung bleibst Du allderdings schuldig.
Tatsächlich habe ich das, was ich gemacht habe, überlegt und bewußt gemacht. Ob es nun als richtig oder falsch war, wird sich nun nicht mehr herausstellen, da so wie aussieht, alles in deinem Sinne wieder geändert wurde
Ich mappe für Anwender und Anwendungen. Und OSMI ist auch nur eine Anwendung und das aus einer Quelle, die eigentlich mit OSM umgehen können müssten, aber offensichlich nicht damit zurechtkommt.
Unzulässiges “mappen für” bedeutet für mich, falsche Daten zu erfassen, um eine Anwendung zu einem mir genehmen Verhalten zu veranlassen. Inwiefern meine Änderungen falsch waren hätte ich doch gerne begründet. Gefühlsäußerungen (so interpretier ich ooooommmm…) werte ich nicht als Gründe.
ist ein wenig schwierig, das noch zu rekonstruieren.
Gestern:
Fakt war - und auch Auslöser dieser Aktion - dass die Grenze des Landkreises Oberallgäu defekt war. Als ich das “mal eben” fixen wollte, fiel mir einiges Komisches auf. U.a gab es einen Grenzway im südlichen Teil der Gegend, der aus einem einzigen Stück bestand und zudem die dort bereits vorhandenen Grenzways überlagert hat.
Als ich dann bemerkte, dass du das aus ganz bestimmten Gründen -wohl um OSMI zu “überlisten” - so gemacht hast, habe ich erstmal garnichts geändert, sondern dich angesprochen.
Heute:
Jan (User Gehrke) hat unabhängig von mir den gleichen Fehler gefunden, seine Unzufriedenheit mit der “Lösung” geäußert und das Gröbste repariert. Und da jetzt sowieso schon jemand dran war, hab ich halt den Rest gemacht.
Grenzen bestehen bei OSM aus einfachen Ways zwischen den Gebieten, die dann in Multipointrelationen zusammengefasst werden. Eine Überlappung dieser Ways ist mMn nicht korrekt.
ach ja: Ooooooooooooommmmmmm ist ein alter Mantra von mir, den manche von uns durchaus als Kommentar zum Thema “Taggen für den Renderer” verstehen. Und diese Aktion fällt mMn in diesen Bereich.
Gruss
walter
Ein Weg ist immer noch doppelt: https://www.openstreetmap.org/way/325724073 Ich hab mich nicht getraut, den anzufassen.
Gruß
Done:
Gruss
walter
Mitmachen nicht strafbar 
Ich habe ihn aus den zwei Jungholz-Relationen entfernt und dort durch die in den AL2-Grenzen verwendeten Teile ersetzt.
Zur Dokumentation habe ich ihn nicht gelöscht, sondern ein obsolete verpasst. Er wird aber natürlich vom JOSM-Inspektor als überlappende Linie moniert.
Hier in der Gegend gibt es auch so eine Exklave, die in einem Punkt berührt. Da hat OSMI auch lange gemeckert, ich habe das aber ignoriert. Seit einiger Zeit kommt aber keine Warnung mehr. Da stießen aber vier ways zusammen, da an diesem Quadrupel-Punkt drei Gemeinden zusammentreffen.
Bei Jungholz kam die Fehlermeldung mMn daher, weil einer der ways (s.o.) über den Vierer-Punkt hinweglief. Sollte zwar auch kein Fehler sein, aber in der momentanen (aufgeteilten) Variante sollte die Meldung auch verschwinden.
Ich bin auf jeden Fall zufrieden:
Die Landkreise sind wieder komplett und Jungholz liegt auch in Österreich.
Gruss und Dank
walter
Moin,
Hier stehen die Ergebnisse der letzten globalen Auswertung. Datenstand war von heute Nacht 2:00 Uhr.
DEU: -1, +16
BRA: -9, +2
CAN: +2
CMR: -4
FRA: -1
GBR: -1, +28
IND: +4
IRL: +48
ITA: -2
JPN: +2
POL: -2, +27
RUS: -1, + >100 AL10
UKR: +13
USA: -1, +1
Gruss
walter
ps: In Serbien nix neues.
Moin,
Hier stehen - noch - die Ergebnisse der letzten globalen Auswertung. Datenstand war von heute Nacht 2:00 Uhr.
DEU: -1, +7
ARG: -1
BRA: -9, +2
POL: -4
FRA: +1
GBR: +52
IRL: +116
Korrekturen Gestern (*): 0
Gruss
walter
*) ausser meinen
Hi,
ich habe meine Boundary-Map “ein wenig” getuned. Der Seitenaufbau grösserer oder auch vieler Grenzen zugleich (z.B. alle AL4 von USA) ist jetzt um den geschätzten Faktor von 10 schneller geworden. Da werden schon mal aus nervenden 30 Sekunden flotte 3 - hoffe ich zumindest
Die neue Version 2.1 ist online.
Gruss
walter
Wow, ist das fix geworden! Wie kommts? Programmierung oder Datenbank, oder ein Zusammenspiel?
ja
nee, im Ernst. Ich hab in den letzten Tagen zwar auch an der DB rumgeschraubt, aber heute hab ich ein ST_SimplifyPreservingTopology(way,tolerance) eingebaut.
Das läuft auf dem DB-Server, der die Daten liefert, die dann bei dir mit Openlayers gerendert werden. Und damit lass ich die Polygone vereinfachen; die werden dann kleiner, sind schneller übertragen und erzeugen weniger Last auf deiner Kiste. Es ist schon halt ein Unterschied ob 133000 oder 4832 Nodes für die #51477 AL2 GER verarbeitet werden müssen.
Dann die Toleranz noch vom Zoom abhängig und das war es auch schon.
Gruss
walter
tl;dr: Serverseitige Datenreduzierung vor dem Upload
Ja - macht Sinn für mich. Es gibt eine OSM Gemeinschaft im Kosovo, aber es ist gerade erst gegründet, und die Menschen sind immer noch lernen, wie man die Dinge zu bearbeiten, das ist wahrscheinlich das, was verursacht die Grenze durchbrochen werden.
Die Erfahrungen der Menschen hier sein würde, wirklich sinnvoll, sie in die Hilfe bei Grenzlinien und Grenzrelationen richtig.
(English)
Yes - makes sense to me. There is an OSM community in Kosovo, but it’s just getting established, and people are still learning how to edit things, which is probably what caused the boundary to be broken.
The experience of people here would be be really useful to them in helping to set up boundary ways and relations correctly.
- Andy Townsend, OSM DWG
Great !
you will know that this is not a technical problem (for us) to fix that stuff. But it will lead to an edit-war with the serbian community, i think.
we, you, someone else has to discuss that to get a permanent solution.
Any ideas?
walter
If you have a look at some of the placename changes you’ll see that an edit war has already happened 
As was said further up the thread, there have been moves to normalise relations between Serbia and Kosovo recently (see https://en.wikipedia.org/wiki/Brussels_Agreement_%282013%29 et al ). I think that having admin_level=2 boundaries between Serbian and Kosovo best fits the situation on the ground (as far as I can tell from various Western, Serbian and Kosovan media sources). Obviously not everyone’s going to be happy with any change (Serbia still technically claims Kosovo).
As I understand it, there are also sizable non-Albanian-speaking minorities within the boundaries of Kosovo, including majority-Serb communities in North Kosovo. I’m not sure if any special status is needed there. There were parallel political structures in place there which in theory were removed by the Brussels Agreement, but that normalisation process seems not complete (see e.g. http://www.b92.net/info/vesti/index.php?yyyy=2015&mm=02&dd=05&nav_category=640&nav_id=954883 ).
(via Google Translate)
Wenn Sie einen Blick auf einige der Ortsname Veränderungen haben Sie sehen, dass ein Bearbeitungs Krieg bereits geschehen ist
Wie bereits weiter oben im Thread sagte, gab es bewegt sich auf die Beziehungen zwischen Serbien und dem Kosovo kürzlich normalisieren (siehe https://en.wikipedia.org/wiki/Brussels_Agreement_%282013%29 et al). Ich denke, dass mit admin_level = 2 Grenzen zwischen Serben und Kosovo am besten für die Situation auf dem Boden (so weit ich kann aus verschiedenen westlichen, serbischen und kosovarischen Medienquellen sagen). Offensichtlich geht nicht jeder mit einer Änderung (Serbien noch technisch behauptet, Kosovo), glücklich zu sein.
Wie ich es verstehe, gibt es auch beträchtliche nicht-albanischsprachigen Minderheiten in den Grenzen des Kosovo, einschließlich der Mehrheits serbischen Gemeinden im Norden des Kosovo. Ich bin nicht sicher, wenn eine Spezialstatus wird dort gebraucht. Es gab parallel politischen Strukturen anstelle es, die in der Theorie wurden von der Brüsseler Vereinbarung entfernt, aber das Normalisierungsprozess scheint nicht abgeschlossen (siehe zB http://www.b92.net/info/vesti/index.php?yyyy=2015&mm=02&dd=05&nav_category=640&nav_id=954883 ).
@arch what should we do now?
- “shrink” serbia?
- fix serbia containing kosovo?
- concact both communities?
- ask DWG or someone else?
- something else?
- nothing?
regards
walter
Moin,
Hier stehen die Ergebnisse der letzten globalen Auswertung. Datenstand war von heute Nacht 2:30 Uhr.
DEU: +23 fast alle AL9
ARG: -2, +3
BLZ: -1, +2, stark geschrumpft
BOL: +2
BRA: -13, + ~100
ECU: +5
FRA: -3
GBR: +35
GRC: -4 auf 1% geschrumpft - passt irgendwie
GTM: -1 AL2! +24
HTI: -2
IRL: -2, + ~50
JPN: -2, +7
MKD: -5 al2 put
POL: +13
PRT: +9
RUS: +2
SVK: -5
TWN: +23
UKR: +3
USA: +4
eventuell hat ja jemand “Erbarmen” mit seinem geplanten Urlaubsland?
Sieht ein wenig mau aus:
Gruss
walter