Multipolygone updaten / ausbessern (21-25.Nov)

Rogehm · 2018-11-21T18:28:10.000Z

emga:

Hallo,

angeregt durch die Multipolygon Diskussion im DE Forum, habe ich mich ein bisschen in AT umgeschaut und stelle fest es gibt auch bei uns die ein oder anderen Multipolygone die man überarbeiten kann bzw ausbessern kann und die zum Teil auch gar keine Multipolygone sein müssen.

Zum Beispiel einfache Wiesenflächen die aus mehreren einzelnen Ways bestehen, obwohl man sie genauso gut auch als ein einzelner geschlossener Way zeichnen kann. Würde die weitere Bearbeitung evt erleichtern. Wenn ich so kleinere Dinge finde besser ich sie gleich aus. Oft benötigt man gar kein Multipolygon der komplexen Sorte mit 2 oder mehr Member und in iD ist es sowieso nur umständlich und Fehler passieren schnell.

Zum anderen haben wir sehr große Multipolygone die etliche Mitglieder haben (Flüsse, Straßen, Grenzen) und Gebirge/Regionen abgrenzen.
Jene werden immer auch geändert wenn man zB etwas an einem Fluss, der Mitglied in der Relation ist ändert.
Ist oder wäre es hier nicht von Vorteil wenn man für diese Gebiet"grenzen"/Regionen eine eigenen Linie verwendet?
Klar, es ist ein Way mehr am Bildschirm, aber wesentlich leichter zu bearbeiten als wenn ein Relation über X Bäche und Y Straßen, Z Gebirge geht inkl Grenzen und Co.

Um potentiell “unnötige” Multipolygone zu finden verwende ich dieses rudimentäre overpass Turbo Script, erfahrenen Nutzern von Overpass wird wsl schlecht dabei ;-))

[out:json][timeout:25]

(
  relation["type"="multipolygon"](if: count_by_role("outer") >= 2 && count_by_role("inner") == 0 )
({{bbox}});
);
// print results
out body;
>;
out skel qt;

Was sagt ihr dazu? Macht sowas Sinn?

Sorry, ich weiß nicht, warum Nakaner diesen Thread einfach abschneidet.

@Nakaner, du solltest das vielleicht besser absprechen mit deinem Moderator-Kollegen.

addresshistory_org · 2018-11-22T05:54:29.000Z

Zumindest ein Kunde der Firma Geofabrik nutzt zur Weiterverarbeitung, von der Firma Geofabrik bereitgestellter Daten, ein Tool - er bezeichnet selbst dieses Tool als einzigartig-. Dieses Tool wird aber nicht mehr weiterentwickelt. Hinweis: Dieses Tool stammt nicht von der Geofabrik.
Meiner Wahrnehmung nach, ist das der Grund warum die Firma Geofabrik (Micheal Nakaner) eine Initiative gestartet hat, die Datenerfassung in OpenStreetMap gemäß den eigenen Erfordernissen zu ändern. Im speziellen betrifft das künftig bei Multipolygonen jeweils solche verpflichtend mit einem geschlossenen äußeren Ring zu versehen. Ich habe daher hier darum gebeten dass Michael seinen Moderator Hut abnimmt, und aufgrund von Befangenheit von einer weiterer Beeinflussung der Diskussion in Funktion als Forums Moderator Abstand nimmt.

edit: Text, aufgrund einer Aufforderung hier https://forum.openstreetmap.org/viewtopic.php?pid=727209#p727209 geändert.

Richtigstellung: Es handelt sich nicht -wie von mir behauptet- um ein Tool der Firma geofabrik, sondern um eine Drittanwendung welche dazu benutzt wird, Geofabrik Daten weiterzuverarbeiten. Ich bitte um Entschuldigung.

Edit: Zur aktuellen Diskussion unnötiges Zitat entfernt: https://forum.openstreetmap.org/viewtopic.php?pid=727212#p727212

Gppes · 2018-11-22T06:43:30.000Z

Ich spreche mich auch gegen die exzessive Nutzung von Multipolygonen aus.

addresshistory*org:

Andere Länder sehen nun diese von Deutschland ausgehende Initiative eher skeptisch.

Der Satz passt von hinten bis vorne nicht: Was ist das fuer eine undefinierte Pauschalaussage? Was geht da von Deutschland aus? Ein deutscher User stellt im deutschen Forum einen kontroversen OSM Dauerbrenner zur Diskussion; So what?

In OSM muss das laenderuebergreifende Gemeinsame vor den (teils konstruierten) Eigenheiten stehen!

Dass Du auch noch den provokantesten, am schlechtesten fuer eine sachliche Diskussion geeigneten Post hier rueber kopierst, was sagt das ueber Dich aus?

kopfschuettel

JM82 · 2018-11-22T06:44:10.000Z

@adresshistory*org:
Vorneweg, ich habe keinerlei Geschäftsbeziehungen zu irgendeiner Firma, die mit Daten von OSM Umsätze generiert.
Dennoch sehe ich nach wie vor übergroße MPs als Problem in der Wartung/Bearbeitung an, da sie schlichtweg unhandlich sind. Im Besonderen, wenn diese über mehrere Quadratkilometer ohne ersichtlichen Grund sich erstrecken. Wenn du meine Region in der ich seit längerem nur mehr Landschaftmapping betreibt, anschaust, wirst du sehen, dann das detaillierte Mappen unterschiedlichster Landschaftsarten (Felder, Wälder usw.) viele Vorteile besitzt im Vgl. zu Großen MPs, wo dann diese Inhalte ausgespart werden. Zugegebenermaßen, ist meine Herangehensweise die wesentlich aufwendigere. Aber für nachträgliche Korrekturen und Veränderungen die deutlich einfachere.
Zudem kommt noch hinzu, dass die Gefahr von Fehlern bei MPs größer ist, als ohne MPs. Siehe z.b. das - ja - Geofabrik Tool OSM-Inspector. Fehler irgendwelcher Art (Touching Rings, relation inner statt outer oder vice versa usw.) tauchen praktisch nur bei MPs auf.
Hier ist auch ein großes MP mit zig Mitgliedern und haufenweise Fehlern zu sehen im Link.
Ich meine, klar kann man MPs nicht gänzlich vermeiden, jedoch ist auch meine Meinung, diese spärlich/sparsam einzusetzen und nach Möglichkeit zu vermeiden.

addresshistory_org · 2018-11-22T06:54:47.000Z

JM82:

@adresshistory*org:
Vorneweg, ich habe keinerlei Geschäftsbeziehungen zu irgendeiner Firma, die mit Daten von OSM Umsätze generiert.
Dennoch sehe ich nach wie vor übergroße MPs als Problem in der Wartung/Bearbeitung an, da sie schlichtweg unhandlich sind. Im Besonderen, wenn diese über mehrere Quadratkilometer ohne ersichtlichen Grund sich erstrecken. Wenn du meine Region in der ich seit längerem nur mehr Landschaftmapping betreibt, anschaust, wirst du sehen, dann das detaillierte Mappen unterschiedlichster Landschaftsarten (Felder, Wälder usw.) viele Vorteile besitzt im Vgl. zu Großen MPs, wo dann diese Inhalte ausgespart werden. Zugegebenermaßen, ist meine Herangehensweise die wesentlich aufwendigere. Aber für nachträgliche Korrekturen und Veränderungen die deutlich einfachere.
Zudem kommt noch hinzu, dass die Gefahr von Fehlern bei MPs größer ist, als ohne MPs. Siehe z.b. das - ja - Geofabrik Tool OSM-Inspector. Fehler irgendwelcher Art (Touching Rings, relation inner statt outer oder vice versa usw.) tauchen praktisch nur bei MPs auf.
Hier ist auch ein großes MP mit zig Mitgliedern und haufenweise Fehlern zu sehen im Link.
Ich meine, klar kann man MPs nicht gänzlich vermeiden, jedoch ist auch meine Meinung, diese spärlich/sparsam einzusetzen und nach Möglichkeit zu vermeiden.

Hallo JM82, übergroße MP´s sind ein Relikt, und benötigen daher, da es praktisch keine Neuzugänge von solchen mehr gibt, keine neue Regel.
Übrigens das Auflösen dieser ist mein spezielles Hobby, wenn Du mir eines nennst, helfe ich Dir sehr gerne im aufzulösen. Ich löse solche aber in kleinere segmentierte MP Strukturen auf, wer möchte kann anschließend ja auch noch daraus Ringe erzeugen, das geht mit dem Tool reltoolbox sehr einfach. Solche Ring Strukturen finde ich aber nur bei sehr kleinen Flächen sinnvoll, da solche Ringe das Verkleinern von MP´s brutal erschweren, denn zum auftrennen von Ringen musst du dieses zuerst splitten. Was zum Schutz solcher Strukturen vor Laien dient, ist in der täglichen Arbeit von erfahrenen Usern eine massive Erschwernis. Daher finde ich diese Initiative von Michael vollkommen überzogen.

Negreheb · 2018-11-22T10:52:56.000Z

addresshistory*org:

spiderman:

…
Ich nutze die OSM-Daten von Geofabrik, um diese mit einem speziellen Tool für einen speziellen Einsatzzweck weiter zu verwenden. … Das verwendete Tool ist einzigartig und wird auch nicht mehr weiterentwickelt werden, weshalb ich anderweitig eine Lösung benötige.

Als Lösungsansatz habe ich mir überlegt, die Relationen automatisch in eine eine einfache Fläche umzuwandeln. Dass dabei Daten verloren gehen ist mir bewusst und absolut zweitrangig. Die Frage ist nur wie ich das anstellen könnte. Ich habe mir Osmfilter angesehen, mir ist jedoch keine Möglichkeit aufgefallen. Hat jemand eine Idee? Wichtig ist, dass alles automatisiert ablaufen muss, manuelles bearbeiten ist aufgrund der Masse an Daten unmöglich.

Es geht als darum dass Multipolygone in Dritt Anwendungen Probleme bereiten.
Also von Nakaner eine Initative in Angelegenheit seiner Firma. Nun wird von Michael nicht sein spezielles Problem thematisiert, sondern er versucht strengere Regeln als OSM Community Entscheidung zu kommunizieren.
Andere Länder sehen nun diese von Deutschland ausgehende Initiative eher skeptisch. …

Du solltest wirklich an deiner Lesekompetenz arbeiten. spiderman verwendet die Daten von Geofabrik. So, wie er es geschrieben hat, lokal. Er verwendet ein nicht näher genanntes Tool, d.h. nicht, dass es ein Tool von Geofabrik ist.

Und, welche andere Länder? Wo steht das? Wie hast du das mitbekommen? Oder behauptest du das einfach nur um wichtiger zu klingen?

spiderman:

Das verwendete Tool ist einzigartig und wird auch nicht mehr weiterentwickelt werden, weshalb ich anderweitig eine Lösung benötige.

Noch einmal. Die Firma geofabrik hat ein Tool, welches diese nicht mehr weiterentwickelt. Daher versucht die Firma Geofabrik nun auf das OpenStreetMap Projekt Einfluss zu nehmen. Zufälligerweise ist ein Mitarbeiter der Firma Geofabrik Moderator hier im Forum, und entfernt daher für dieses Anliegen unliebsame Diskussionsbeiträge. Es wäre also daher fair, wenn Michael dazu hier seinen Moderator Hut abnimmt, und mit Sachargumenten argumentieren würde. …

Nein, das Tool ist nicht von Geofabrik. Das hast du dir gerade einfach zusammengereimt.

Bzgl. der Anschuldigung von löschen, hast du da auch Beweise? Ich hab nämlich eine gewisse (naja, recht konkrete) Ahnung, was passiert ist.

Und, was es mit Michael und dem Mod in diesem Forum auf sich hat, wurde dir eigentlich schon zu genüge erläutert. Das ist anstrengend…

@JM82
Bitte, lass solche vorab “ich habe keine Beziehungen”, ich verstehe aber, dass du das geschrieben hast.

Es ist traurig, wenn Leute sich wegen einem (!) User genütigt fühlen, solche Hinweise schreiben zu müssen, weil der mit Vorwürfen und Verschwörungstheorien um sich wirft, sobald ihm was nicht in den Kram passt.
Wenn er so etwas behauptet, muss er das auch erklären.

EDIT: Rechtschreibfehler

EDIT2: Auf nachfrage von mir hat spiderman meine Vermutungen bestätigt. Er macht das ganze A, lokal bei sich und will online bei osm.org oder osm.de nichts ändern und B, mit einem Tool welches nicht von der Geofabrik stammt. Damit das klargestellt ist.

addresshistory_org · 2018-11-23T05:46:09.000Z

Ich nutze für meine Outdoor Aktivitäten ein ultra mobiles Hand GPS Gerät Marke Edmundson mit LCD Display.
Dieses Tool ist einzigartig und wird auch nicht mehr weiterentwickelt werden. Interner Speicher 640 Kilobyte.

Ich habe nun im Editor JOSM die Funktion Umschalt+Y, Linie vereinfachen entdeckt, schlage daher vor, dass wir künftig dessen Skalierung auf sämtliche Linien in OpenStreetMap anwenden.
Ich bitte hierzu um Diskussion.

Für eine nachhaltige Datenreduktion hätte ich das gerne als verbindliche Regel festgelegt.

Ref: https://josm.openstreetmap.de/wiki/De%3AHelp/Action/SimplifyWay
Ref: Ramer–Douglas–Peucker algorithm https://de.wikipedia.org/wiki/Douglas-Peucker-Algorithmus
Beispiel einer praktischen Anwendung: https://www.openstreetmap.org/changeset/42276122
edit: +Ref

Luzandro · 2018-11-23T06:56:57.000Z

addresshistory*org:

Ich nutze für meine Outdoor Aktivitäten ein ultra mobiles Hand GPS Gerät Marke Edmundson mit LCD Display.
Dieses Tool ist einzigartig und wird auch nicht mehr weiterentwickelt werden. Interner Speicher 640 Kilobyte.

Ich habe nun im Editor JOSM die Funktion Umschalt+Y, Linie vereinfachen entdeckt, schlage daher vor, dass wir künftig dessen Skalierung auf sämtliche Linien in OpenStreetMap anwenden.
Ich bitte hierzu um Diskussion.

Für eine nachhaltige Datenreduktion hätte ich das gerne als verbindliche Regel festgelegt.

Du bist schon witzig. Auf der einen Seite ist dir das Schätzen des Dachvorsprungs ganz wichtig und auf der anderen möchtest du sämtliche Abweichungen über default 3 Metern wegwerfen. So wie oft kann diese Funktion in einigen Fällen sinnvoll sein, im Allgemeinen ist sie aber auch zu grob und du bekommst lauter Ungenauigkeiten und Überschneidungen wie diese hier:

7MzVVuq.png1482×698 143 KB

addresshistory_org · 2018-11-23T08:37:45.000Z

Luzandro:

addresshistory*org:

Ich nutze für meine Outdoor Aktivitäten ein ultra mobiles Hand GPS Gerät Marke Edmundson mit LCD Display.
Dieses Tool ist einzigartig und wird auch nicht mehr weiterentwickelt werden. Interner Speicher 640 Kilobyte.

Ich habe nun im Editor JOSM die Funktion Umschalt+Y, Linie vereinfachen entdeckt, schlage daher vor, dass wir künftig dessen Skalierung auf sämtliche Linien in OpenStreetMap anwenden.
Ich bitte hierzu um Diskussion.

Für eine nachhaltige Datenreduktion hätte ich das gerne als verbindliche Regel festgelegt.

Du bist schon witzig. Auf der einen Seite ist dir das Schätzen des Dachvorsprungs ganz wichtig und auf der anderen möchtest du sämtliche Abweichungen über default 3 Metern wegwerfen. So wie oft kann diese Funktion in einigen Fällen sinnvoll sein, im Allgemeinen ist sie aber auch zu grob und du bekommst lauter Ungenauigkeiten und Überschneidungen wie diese hier:
https://i.imgur.com/7MzVVuq.png

Wieso, in beiden Fällen geht es darum alte Werkzeuge am Laufen zu halten.
Wer mehr möchte für den gibt es ja kommerzielle Projekte https://www.swisstopo.admin.ch/de/home.detail.news.html/swisstopo-internet/news2018/news_release/20180927.html

edit: typo

Negreheb · 2018-11-23T08:54:08.000Z

Was laberst du? spiderman will lokal heruntergeladene daten so anpassen, dass er sein bevorzugtes tool benutzen kann. Weder will er das Tool weiterentwickeln, noch will er Regeln in OSM einführen, oder was auch immer. Er hat nach tipps gefragt, wie er das am besten anstellen kann.
Du konstruierst hier wiedermal zusammenhänge, wo keine sind.

Nakaner will Regeln für Multipolygone einführen, nicht diese abschaffen.

Und was spiderman vorhat, hat nichts mit den Sachen von Nakaner zu tun. Da einen Zusammehang zu konstruieren, dafür muss man schon sehr kreativ sein…

addresshistory_org · 2018-11-23T11:23:52.000Z

Negreheb:

spiderman will lokal heruntergeladene daten so anpassen, dass er sein bevorzugtes tool benutzen kann.

und Nakaner möchte in seiner aktuellen Initiative die Regeln in OpenStreetMap derart verändern, dass spiderman künftig ohne Nachbearbeitung mit den von seiner Firma aus unserem Projekt gezogenen Daten glücklich ist.

Rogehm · 2018-11-23T20:24:24.000Z

adresshistory*org:

…und Nakaner möchte in seiner aktuellen Initiative die Regeln in OpenStreetMap derart verändern, dass spiderman künftig ohne Nachbearbeitung mit den von seiner Firma aus unserem Projekt gezogenen Daten glücklich ist.

Ich habe in der Hoffnung, das dieser Thread, den Nakaner wegen teils berechtigten Einwänden geschlossen hat, nochmal neu eröffnet, weil ich den Eindruck hatte, das Thema ist nicht ausdiskutiert und es bedarf noch einer Restdiskussion.
@adresshistory*org Off Topic: Allerdings möchte ich dich unbedingt bitten, nicht wieder unsachlich zu werden und dem Ansinnen von Nakaner nicht falsch auszulegen. Wenn du überall mitliest, was ich erwarte ob deiner Eigenschaft, alles zu kommentieren (was grundsätzlich ok wäre, wenn es die Nerven der OSM-Mitstreiter nicht übermäßig belastet), geht es nicht mehr um das Thema an sich, sondern um deine Ansichten ggü. bestimmten Leuten und Firmen. Nakaner macht sich gute Gedanken und die sollten im Konsenz zu einem Wiki-Vorschlag reichen, wie mit M-Polygonen im allgemeinen umzugehen ist.
Da ich deine Ansichten manchmal auch nicht übermäßig gut finde, dürfte dir nicht entgangen sein. Allerdings halte ich nichts von einer vorübergehenden Sperre, wie von Nakaner, ob seinen Möglichkeiten, angedroht wurde. Ich hoffe, du bleibst sachlich, ohne falsche Vorwürfe, gerne mit eigener Meinung in der weiteren Folge der Diskussion. Diese darf dann gerne im Sinne einer guten Versachlichung fortgesetzt werden. Danke an alle Beteiligten.

P.S. Erster Entwurf: https://forum.openstreetmap.org/viewtopic.php?pid=727019#p727019

addresshistory_org · 2018-11-23T20:35:16.000Z

Bislang kein Protest,
also kennen wir nun das Problem, Probleme kann man lösen.

Wie können wir also Michel glücklich machen.

Bitte um Vorschläge:

Phase I Fragen:

Wie sinnvoll ist ein geschlossener Äußerer Ring.
Wie rekonstruiert man aus Segmenten wieder einen geschlossenen Ring, Hilfsmittel Tools.
Wie gehen wir mit segmentierten Groß Polygonen um, ist es zulässig bei deren Verkleinerung im Äußeren Ring temporär bei Segmenten zu bleiben.
Verkleben mit Straßen oder anderen Objekten, wie gehen wir hiermit um.
Grenzlinie Wald/Wiese getrennte oder gemeinsame Nodes.
Grenzlinie Wald/Wiese mit Straße am Waldrand.
Bachläufe, Sandbett, sind Grenzflächen Wasser oder Wald.
Bei Änderungen, Ring löschen und jeweils neu zeichnen, oder Historie erhalten.
Methode in der Bearbeitung per ID oder GoMap!!, sollen Anfänger, statt einen Ring zu verändern, diesen besser löschen und anschließend jeweils neu zeichnen?
Was ist Nichts, welche Funktion haben leer Flächen.
Gewerbegebiet oder Golfplatz aus Teilflächen, wie fassen wir solche in namentlicher Zuordnung zusammen.

Bitte um Ergänzung von weiteren Fragen…

edit: text

Gppes · 2018-11-24T08:08:08.000Z

Im deutschen Forum scheinen sich jetzt Regeln herauszukristallisieren, mit denen eine breite? Mehrheit leben kann.

https://forum.openstreetmap.org/viewtopic.php?pid=726993#p726993

Wollen wir uns dem anschliessen? Mir gefaellt es gut!

Lg, Gppes

PS: Ich verstehe auch nicht, warum der eigentliche Thread dazu geschlossen wurde.

Gppes · 2018-11-24T08:32:36.000Z

addresshistory*org:

Bislang kein Protest,
also kennen wir nun das Problem, Probleme kann man lösen.

Wie können wir also Michel glücklich machen.

Bitte um Vorschläge:

Phase I Fragen:

Wie sinnvoll ist ein geschlossener Äußerer Ring.

Ein notwendiges MP bleibt kompatibel zu Polygon Nachbarn, ein MP ohne Nachbarn ist einfacher zu editieren (keine Langen outer-Listen).

Wie rekonstruiert man aus Segmenten wieder einen geschlossenen Ring, Hilfsmittel Tools.

Z.B. mit dem von Dir oft empfohlenen reltoolbox Plugin? Josm selbst hat sich aber im Umgang mit MPs in den letzten Jahren auch deutlich verbessert.

Wie gehen wir mit segmentierten Groß Polygonen um, ist es zulässig bei deren Verkleinerung im Äußeren Ring temporär bei Segmenten zu bleiben.

Denke ich schon, es ist ohnehin nicht empfohlen vorhandene Daten nur der Daten Willen umzuarbeiten.

Verkleben mit Straßen oder anderen Objekten, wie gehen wir hiermit um.

Ich spreche mich gegen das Verkleben mit Strassen aus, auch wenn es im Ausnahmefall OK sein kann.

Grenzlinie Wald/Wiese getrennte oder gemeinsame Nodes.

Aus meiner Sicht gemeinsame Nodes (ueberlappende Ways).

Grenzlinie Wald/Wiese mit Straße am Waldrand.

Ich trenne, oder setze die Strasse in die Wiese. Eine einzelne Baumzeile zwischen Strasse und Wiese also: Wald->Strasse->Baumzeile->Wiese mache ich als natural=tree_row, das erscheint mir am realistischsten.

Bachläufe, Sandbett, sind Grenzflächen Wasser oder Wald.

Sind fuer mich Grenzflaechen, also keine gemeinsame Ways. Also im Allgemeinen kein gemeinsamer Way des Bachlaufs selbst, gerne aber bei einem Flussbett oder Sandbett.

Bei Änderungen, Ring löschen und jeweils neu zeichnen, oder Historie erhalten.
Methode in der Bearbeitung per ID oder GoMap!!, sollen Anfänger, statt einen Ring zu verändern, diesen besser löschen und anschließend jeweils neu zeichnen?

Aus meiner Sicht immer die History erhalten. Aber wenn es einem neuen User mal passiert, was solls?

Was ist Nichts, welche Funktion haben leer Flächen.

Nichts kann bedeuten, dass man nicht weiss was es ist, dass man nicht weiss wie man das Feature mappt, oder dass es derzeit in OSM nicht erfassbar ist. (Z.B.: Strassen als areas oder ways). Aus meiner Sicht braucht man Mut zum Nichts! Man muss nicht immer auf Biegen und Brechen alles erfassen.

Gewerbegebiet oder Golfplatz aus Teilflächen, wie fassen wir solche in namentlicher Zuordnung zusammen.

Weiss ich nicht. Ich bin kein Freund davon hierfuer MPs zu verwenden.

Bitte um Ergänzung von weiteren Fragen…

edit: text

addresshistory_org · 2018-11-24T16:07:35.000Z

Gppes:

Dass Du auch noch den provokantesten, am schlechtesten fuer eine sachliche Diskussion geeigneten Post hier rueber kopierst,

Ich habe das von Dir kritisierte Zitat entfernt. Danke für den Hinweis.

addresshistory_org · 2018-11-25T13:59:46.000Z

Gppes:

Im deutschen Forum scheinen sich jetzt Regeln herauszukristallisieren, mit denen eine breite? Mehrheit leben kann.

https://forum.openstreetmap.org/viewtopic.php?pid=726993#p726993

Wollen wir uns dem anschliessen? Mir gefaellt es gut!

Lg, Gppes

PS: Ich verstehe auch nicht, warum der eigentliche Thread dazu geschlossen wurde.

Bevor so wichtige Entscheidungen angegangen werden, müssen möglichst alle Karten offen auf den Tisch. Das bedeutet aber nicht -zumindest von mir- eine sofortige Ablehnung.

Ich würde hier gerne noch auf weiteren lokalen Input zuwarten. Deine Antworten finde ich bereits plausibel und jedenfalls für mich nachvollziehbar.
Wir haben wie JM82 angemerkt hat, bereits Fragestellungen bei unserer Grenze zu Ungarn, und auch noch mehrere weitere Kulturräume welche an unser Land angrenzen. Wir sollten daher sorgsam abwägen, und Inkompatibilitäten finde ich eher versuchen zu vermeiden.
Schön wäre es, wenn sich bereits weitere Länder, der Deutschen Initiative anschließen würden, dann hätten wir mehr Klarheit.

Servus Johann

edit: text

Rogehm · 2018-11-25T20:29:18.000Z

Ein erster Wiki Entwurf ist erstellt worden.
Gerne könnt ihr hier weiterdiskutieren, aber auch auf der Diskussionsseite (meine Empfehlung) und natürlich hier und hier.

Nakaner · 2018-11-25T22:06:22.000Z

Moderatorhut auf

Hallo addresshistory*org,

du bist in den vergangene Wochen wiederholt durch Verschwörungstheorien, die Behauptung grob falscher Tatsachen und das Entlaufenlassen von Diskussionen im österreichischen Forum aufgefallen. Mehrere Benutzer haben sich beschwert oder gar das OpenStreetMap-Projekt verlassen. Deine Beiträge haben größtenteils nicht positiv dem Diskurs beigetragen. Ich habe dich bis zum 2. Deuember 2018 im OpenStreetMap-Forum gesperrt.

Diese Sperre ist keine Strafe. In der Zwischenzeit soll hier eine Willkommenskultur geschaffen werden.

Viele Grüße

Michael

Moderatorhut ab

guest11 · 2018-11-25T22:57:28.000Z

Nakaner:

…

Da du offenbar dieser Michael bist, um den es hier u.a. geht, würde ich dich auch in deinem eigenen Interesse bitten, diesen Beitrag der Realität entsprechend anzupassen oder zu ergänzen:
https://forum.openstreetmap.org/viewtopic.php?pid=726768#p726768

Hier findest du mehr Hintergründe zu diesem wirren Beitrag von oben:
https://forum.openstreetmap.org/viewtopic.php?pid=726755#p726755
https://forum.openstreetmap.org/viewtopic.php?pid=727275#p727275