Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Chrysopras · 2018-12-30 21:37:44

Den Vorschlag von Frederik (#398) finde ich sehr gut. Gratulation an Frederik für diese Idee!

Nur ein kleines „Bedenken“ dazu: Bei Punkt 4 (

woodpeck wrote:

4. Hat die Fläche mehrere disjunkte Teile, aber eine gemeinsame identifizierende Eigenschaft (z.B. ein gemeinsamer Name), weswegen die disjunkten Teile nicht separiert werden können --> Multipolygon ist erforderlich

) muss möglicherweise erklärt werden (vielleicht in einer Anmerkung?), dass es noch nicht als „gemeinsame identifizierende Eigenschaft“ zählt, wenn die Teile einfach irgendwelche Eigenschaften bzw. Tags teilen (wie es z.B. bei mehreren Wiesenflächen der Fall wäre – auch so etwas wird ja manchmal als MP zusammengefasst). Es geht wirklich um identifizierende Eigenschaften, insbesondere Eigennamen.

Last edited by Chrysopras (2018-12-30 21:38:29)

Nop · 2018-12-30 23:29:12

Mir gefällt der Ansatz als Checkliste.

Allerdings würde ich die Reihenfolge umdrehen. Also mit den einfachen Fällen anfangen, in denen keinesfalls ein MP erforderlich ist, und dann zu den komplizierteren kommen.

aeonesa · 2018-12-31 00:37:29

Mit Checklisten habe ich immer gern gearbeitet. Weil man das Rad da nicht jedes Mal neu erfinden muss und die Gefahr, dass man was nicht beachtet, minimiert wird.

Mann könnte das evtl. auch wie einen Entscheidungsbaum (Programmablaufplan) aufbauen, an dessen Endzweig jeweils der entsprechende Link zu dem zutreffenden WIKI hängt.

Mann muss es noch nicht mal mit den Symbolen eines Programmablaufplanes erstellen. In Zeiten, wo Computer noch nicht so richtig grafikfähig waren, ging das auch ganz gut mit ASCII Zeichen.

rainerU · 2018-12-31 07:22:25

Hallo Frederik,

bei den meisten in diesem Faden erwähnten Negativ-Beispielen, z.B. diesem, endet der Check schon bei Punkt 2, weil die Fläche ein Loch hat, oder läuft durch bis Punkt 7, weil der Umriss mehr als 50 Punkte oder mehr als 10 qkm hat. Ich würde daher "Multipolygon ist erforderlich", außer bei Punkt 4, ersetzen durch "Prüfe, ob die Fläche so aufgeteilt werden kann dass diese Bedingung nicht mehr erfüllt ist", also z.B.

2. Ist es eine Fläche mit Loch --> Prüfe, ob die Fläche so aufgeteilt werden kann, dass die Teilflächen keine Löcher mehr aufweisen.

Es braucht dann natürlich eine Anleitung zum Aufteilen. Über die sollte vielleicht separat diskutiert werden.

Grüße
Rainer

Edit: Satzzeichen

Last edited by rainerU (2018-12-31 10:15:01)

rab · 2018-12-31 13:39:35

Eine Fläche mit Loch sollte als eine Fläche mit Loch gezeichnet werden und nicht als ein zusammengestückeltes Flickwerk.

addresshistory*org · 2018-12-31 15:52:04

rab wrote:

Eine Fläche mit Loch sollte als eine Fläche mit Loch gezeichnet werden und nicht als ein zusammengestückeltes Flickwerk.

:-)
Es geht hier auch gar nicht um Multipolygone, sondern darum dass das Verkaufs Produkt, der Polygon Vermarkter, auf die Wiedergabe von uns gezeichneter "Löcher" weitgehend verzichtet.
Wir arbeiten für die Branche der Tilevermarkter bereits viel zu sehr in der Tiefe, und für Berufs Geografen -welche selbst an amtlichen Karten arbeiten- bereits viel zu detailliert.
Daher nun deren aktuelle Initiaitive, uns im Einsatz von Multipolygonen durch beschönigend genannten Empfehlungen, welche in Realität natürlich verbindliche Regeln sind, einzuschränken.

Dazu ein passendes Zitat: Nur die dümmsten Kälber wählen ihre Schlächter selber.
Bertolt Brecht

edit: typo

Last edited by addresshistory*org (2018-12-31 16:14:24)

PT-53 · 2018-12-31 16:46:41

addresshistory*org wrote:

Es geht hier auch gar nicht um Multipolygone, sondern darum dass das Verkaufs Produkt, der Polygon Vermarkter, auf die Wiedergabe von uns gezeichneter "Löcher" weitgehend verzichtet.
Wir arbeiten für die Branche der Tilevermarkter bereits viel zu sehr in der Tiefe, und für Berufs Geografen -welche selbst an amtlichen Karten arbeiten- bereits viel zu detailliert.
Daher nun deren aktuelle Initiaitive, uns im Einsatz von Multipolygonen durch beschönigend genannten Empfehlungen, welche in Realität natürlich verbindliche Regeln sind, einzuschränken.

Was ist den das für eine Verschwörungsthorie ?

Fragende Grüße

addresshistory*org · 2018-12-31 17:04:26

PT-53 wrote:

addresshistory*org wrote:
Es geht hier auch gar nicht um Multipolygone, sondern darum dass das Verkaufs Produkt, der Polygon Vermarkter, auf die Wiedergabe von uns gezeichneter "Löcher" weitgehend verzichtet.
Wir arbeiten für die Branche der Tilevermarkter bereits viel zu sehr in der Tiefe, und für Berufs Geografen -welche selbst an amtlichen Karten arbeiten- bereits viel zu detailliert.
Daher nun deren aktuelle Initiaitive, uns im Einsatz von Multipolygonen durch beschönigend genannten Empfehlungen, welche in Realität natürlich verbindliche Regeln sind, einzuschränken.
Was ist den das für eine Verschwörungsthorie ?
Fragende Grüße

Die Frage ist doch, wem nützt die hier vorligende Initiative von Michael.
Michael befindet sich schon sehr lange auf einem Kreuzzug gegen die Verwendung von Multipolygonen https://www.openstreetmap.org/changeset/56911458 ,was hat ein Deutscher User, mit solchen Wünschen in Österreich verloren. Es geht hier um eine Agenda der Firma für die Michael arbeitet. Uns wird hier hingegen vermittelt, es gehe um eine Agenda für eine leichtere Bearbeitbarkeit für OpenStreetMap Anfänger.
Fehlen die Argumente kommt der Hamme Verschwärungstheorie zum Einsatz.

Ich Mappe in meinen primären Regionen https://www.openstreetmap.org/#map=19/47.52595/12.39868 in großer Detailtiefe. ICh erkläre klar, dass die Verwendung von Multipolygonen vorteile bringt. Auch die Anwendung sogenannter Polygonteppiche liefert klare Vorteile. Aus Technischer Sicht spricht nichts gegen die gemeinsame Nutzung einer Flächenbegrenzung. Klar ablehnend sehe ich das zerstückel von Straßen. Aber das ist hier auch nicht die Frage.

aeonesa · 2018-12-31 17:26:59

Warum arbeitest Du hier mit Andeutungen. Die Arbeitsverhältnisse sind hier kein Geheimnis.

Und wenn Frederik ein berufliches Interesse daran hätte, die Multipoligonitis einzuschränken, schätze ich ihn so ein, dass er genug E... .. .. . Hose hat, um so etwas selbst anzuschieben.

Es ist einfach so, dass es mittlerweile in OSM Konstrukte gibt und damit meine ich nicht nur Multipoligone, die die spätere Bearbeitung dieser Elemente auf Grund ihre Komplexität fast unmöglich machen bzw. man die Lust verliert sich soviel Arbeit zu machen. Um dieses Thema umfassend zu behandeln, müsste man aber einen eigenen Faden aufmachen.

Ich kann Dich nur bitten, Deine Provokationen und unterschwelligen Verdächtigungen gegen andere Mapper zu unterlassen.
Und wenn Dir was nicht passt, dann nenne die Dinge oder die Personen beim Namen.

Ich wünsch Dir trotzdem einen guten Rutsch

addresshistory*org · 2018-12-31 19:02:41

aeonesa wrote:

Ich wünsch Dir trotzdem einen guten Rutsch

Dem schließe ich mich an,
Euch allen einen guten Rutsch ins neue Jahr 2019

PT-53 · 2018-12-31 19:24:27

addresshistory*org wrote:

was hat ein Deutscher User, mit solchen Wünschen in Österreich verloren

Wow !

whb · 2018-12-31 19:36:33

addresshistory*org wrote:

Es geht hier auch gar nicht um Multipolygone, sondern darum dass das Verkaufs Produkt, der Polygon Vermarkter, auf die Wiedergabe von uns gezeichneter "Löcher" weitgehend verzichtet.
Wir arbeiten für die Branche der Tilevermarkter bereits viel zu sehr in der Tiefe, und für Berufs Geografen -welche selbst an amtlichen Karten arbeiten- bereits viel zu detailliert.
Daher nun deren aktuelle Initiaitive, uns im Einsatz von Multipolygonen durch beschönigend genannten Empfehlungen, welche in Realität natürlich verbindliche Regeln sind, einzuschränken.

Bei der Empfehlung geht es doch gar nicht darum, auf Details zu verzichten.
Ziel ist es auf MP zu verzichten, wenn dies ohne Informationsverlust möglich ist, um Mappern die Bearbeitung etwas einfacher zu machen.
Welche Vorteile hier irgendwelche Vermarkter haben sollten, ist mir nicht klar.

addresshistory*org wrote:

Die Frage ist doch, wem nützt die hier vorligende Initiative von Michael.

Hauptsächlich den Mappern, welche sich nicht mit unnötig komplizierten MP herumschlagen wollen.
Ich bin vor einigen Wochen, das war glaube ich irgendwo in der Nähe von Neckargerach oder Zwingenberg (https://www.openstreetmap.org/#map=15/49.3977/9.0744) beim Mappen über MPs gestolpert und habe dann irgendwann das Bearbeiten abgebrochen, da es einfach sehr zeitaufwendig ist, solche MPs zu bearbeiten und trotz aller Bemühungen habe ich den Wald bei Zwingenberg kaputt gemacht (obwohl ich diesen gar nicht bearbeiten wollte, sondern nur die angrenzende Wiese, welche eine gemeinsame Linie mit dem Wald teilte) und JOSM hat mich nicht gewarnt, da das entsprechende MP nicht vollständig geladen war.
Deswegen bin ich sehr dankbar, dass hier versucht wird, eine entsprechende Empfehlung zu beschließen.
Ich bin der Meinung, dass man alles einfach halten sollte, solange dies möglich ist, ohne die Realität falsch darzustellen oder an Details zu verlieren.

Last edited by whb (2018-12-31 19:39:51)

addresshistory*org · 2018-12-31 21:32:35

whb wrote:

ltrotz aller Bemühungen habe ich den Wald bei Zwingenberg kaputt gemacht (obwohl ich diesen gar nicht bearbeiten wollte, sondern nur die angrenzende Wiese, welche eine gemeinsame Linie mit dem Wald teilte) und JOSM hat mich nicht gewarnt, da das entsprechende MP nicht vollständig geladen war.

Ich arbeite nun sehr viel und gerne mit Multipolygonen, und habe persönlich in meiner Laufbahn auch sämtliche hierzu genannten Fehler selbst begangen, und anschließend wieder mühsam selbst ausgebessert. Letztlich sind MP´s kein Problem sofern man sich an wenige Regeln hält.

Eine Straße besteht aus drei Details,
* dem Straßen Way, dieser dient als Träger der Straßen Eigenschaften, dieser zeigt auch den Straßenverlauf an.
* dem Leer Raum (Vorbereitung für spätere Straßen Flächen Elemente)
* dem Straßenrand Way, Träger der angrenzenden Flächen- Eigenschaft.

Die meisten Multipolygone sind durch diese Trennung bereits unnötig
mein Beispiel: https://www.openstreetmap.org/#map=19/47.52595/12.39868

Multipolygon Teppiche verwende ich gerne und ausgiebig, achte bei solchen aber sehr darauf, dass hierbei nur kleine Strukturen entstehen. Groß- MP Strukturen löst man hierbei unbedingt auf. Diese Relikte sind wirklich problematisch, und werden sehr gerne als Ausrede der MP Gegner genannt, dabei ist das auflösen solcher Strukturen heute absolut keine Hexerei.

Ich möchte also abgesehen von Grenz Relationen nie die Ausrede hören, mein MP wurde nicht vollständig geladen, daher habe ich ein MP zerstört, das ist doch nur eine faule Ausrede.

Grenz- Relationen gehören von allen anderen Details getrennt, sauber in einem eigenen Polygon geführt. Diese Vorsichtsmaßnahme senkt auch das Risiko einer versehentlichen Zerstörung solcher Strukturen beträchtlich.

Grüße

edit typo

Last edited by addresshistory*org (2018-12-31 21:42:23)

streckenkundler · 2018-12-31 23:04:41

addresshistory*org wrote:

Multipolygon Teppiche verwende ich gerne und ausgiebig, achte bei solchen aber sehr darauf, dass hierbei nur kleine Strukturen entstehen. Groß- MP Strukturen löst man hierbei unbedingt auf.

Ahja...
https://www.openstreetmap.org/relation/1906210
https://www.openstreetmap.org/relation/4472122
https://www.openstreetmap.org/relation/2090677

... soll ich noch mehr liefern, z.B. ein paar Forst-MP's noch?

In meinen Augen sind MP-Teppiche, die aus Liniensegmenten zusammengesetzt sind und solche o.g. Beispiele ein Verstoß gegen https://wiki.openstreetmap.org/wiki/DE: … SM-Element. Sie stellen eine unnötige Verkomplizierung des Datenbestandes dar und behindern im extremsten die Anpassung/ Änderung der Daten durch Dritte... Ich habe öfters Kontakt zu Mappern, die nicht JOSM nutzen und die beschweren sich regelmäßig über MP's und bitten mich mal drüberzuschauen, daß kein Fehler entstanden ist...

Sven

aeonesa · 2019-01-01 01:53:38

@streckenkundler: Eigentlich wollte ich Dir schreiben: "Do not feedt the troll"

Zu diesem WIKI rege ich mich auf, wenn ich ausgeschlafen habe

Galbinus · 2019-01-01 02:40:48

addresshistory*org wrote:

Ich arbeite nun sehr viel und gerne mit Multipolygonen, und habe persönlich in meiner Laufbahn auch sämtliche hierzu genannten Fehler selbst begangen, und anschließend wieder mühsam selbst ausgebessert. Letztlich sind MP´s kein Problem sofern man sich an wenige Regeln hält.
Eine Straße besteht aus drei Details,
* dem Straßen Way, dieser dient als Träger der Straßen Eigenschaften, dieser zeigt auch den Straßenverlauf an.
* dem Leer Raum (Vorbereitung für spätere Straßen Flächen Elemente)
* dem Straßenrand Way, Träger der angrenzenden Flächen- Eigenschaft.
Die meisten Multipolygone sind durch diese Trennung bereits unnötig
mein Beispiel: https://www.openstreetmap.org/#map=19/47.52595/12.39868

Ich habe mir das Beispiel angeschaut. Ich finde es - sagen wir mal - suboptimal. Wieso werden von Dir die gepflasterten Flächen der privaten Grundstückseinfahrten aus landuse=residential ausgelassen? Das entspricht keiner der in https://wiki.openstreetmap.org/wiki/DE: … esidential aufgeführten Verwendungen (bei der einen werden die gesamten Siedlungsflächen inkl. der dazu gehörigen Straßen als landuse=residential eingezeichnet, bei der anderen die tatsächlichen Siedlungsgrundstücke unter Auslassung der Straßen). Grundstückseinfahrten sind aber Teil des Siedlungsgrundstücks und somit gehören sie eindeutig in die landuse=residential-Fläche.
Die von Dir genutzten Aussparungen für Zufahrten gaukeln auch eine Detailtreue vor, die aber tatsächlich nicht vorhanden ist. Was ist Zufahrt, was ist Fußweg zur Haustür, was ist Terrasse? Das gibt kein Luftbild so eindeutig her und ein exaktes Einzeichnen nach Besichtung vor Ort ist weder möglich (Betreten von Privatgrundstücken) noch ist es erwünscht, dass diese Details auf Wohngrundstücken ohne Einverständnis des Besitzer so detailliert eingezeichnet werden. Also: Wenn man Deinen Ansatz umsetzen wollte, müsste sich das Aussparen von Straßen auf tatsächliche Straßen beschränken. Die privaten Zufahrten auf den angrenzenden Grundstücken sind dagegen eindeutig landuse=residential.

Last edited by Galbinus (2019-01-01 02:43:38)

addresshistory*org · 2019-01-01 02:45:11

streckenkundler wrote:

addresshistory*org wrote:
Multipolygon Teppiche verwende ich gerne und ausgiebig, achte bei solchen aber sehr darauf, dass hierbei nur kleine Strukturen entstehen. Groß- MP Strukturen löst man hierbei unbedingt auf.
Ahja...
https://www.openstreetmap.org/relation/1906210
https://www.openstreetmap.org/relation/4472122
https://www.openstreetmap.org/relation/2090677
... soll ich noch mehr liefern, z.B. ein paar Forst-MP's noch?
In meinen Augen sind MP-Teppiche, die aus Liniensegmenten zusammengesetzt sind und solche o.g. Beispiele ein Verstoß gegen https://wiki.openstreetmap.org/wiki/DE: … SM-Element. Sie stellen eine unnötige Verkomplizierung des Datenbestandes dar und behindern im extremsten die Anpassung/ Änderung der Daten durch Dritte... Ich habe öfters Kontakt zu Mappern, die nicht JOSM nutzen und die beschweren sich regelmäßig über MP's und bitten mich mal drüberzuschauen, daß kein Fehler entstanden ist...
Sven

Ein_Objekt,_ein_OSM-Element. Ein Beispiel hierfür: Ein ausgedehntes Waldgebiet genannt Finsterwald, ist durch mehrere Wiesen durchbrochen. Den Regeln entsprechend Ein_Objekt,_ein_OSM-Element, sind demnach die verteilten Waldflächen in einem gemeinsamen Multipolygon mit name=Finsterwald zusammenzufassen. Du beschreibst hier aber das genaue Gegenteil. Ich finde Ein_Objekt,_ein_OSM-Element, ist sogar ein hervorragendes Beispiel für den sinnvollen Einsatz von Multipolygonen. Beispiel: Wald/ Unterberghorn https://www.openstreetmap.org/relation/1914793

Deine Angriffe sind nun ein excellentes Beispiel, was den kleinen Mappern blüht, sobald die aktuelle Proposal "Empfehlung" in Abstimmung abgeschlossen ist.
Inquisition

Mich beschäftigt aktuell anders, wie unerledigte Arbeiten wie diese: https://osmcha.mapbox.com/changesets/65 … 2%7D%5D%7D

Anstatt über kleine Mapper herzuziehen, sollten wir diese dazu motivieren, seit Jahren unerledigte Baustellen aufzuräumen.

Zu Deiner Behauptung, Kontakt zu Usern welche per ID Probleme mit Multipolygonen haben, habe ich bereits ausgeführt, dass der Editor ID Defekt ist. Das kümmert Dich und andere aber nicht, ID User regelmäßig als Kronzeugen zu instrumentalisieren.
Nun gut, nenne uns einen solchen. Dieser bekommt hier Gehör. Einstweilen würde ich dich Bitten, Deine Energie auf die Reparatur des Editos ID zu lenken.

edit:typo

Last edited by addresshistory*org (2019-01-01 11:15:58)

addresshistory*org · 2019-01-01 03:46:17

Galbinus wrote:

addresshistory*org wrote:
Ich arbeite nun sehr viel und gerne mit Multipolygonen, und habe persönlich in meiner Laufbahn auch sämtliche hierzu genannten Fehler selbst begangen, und anschließend wieder mühsam selbst ausgebessert. Letztlich sind MP´s kein Problem sofern man sich an wenige Regeln hält.
Eine Straße besteht aus drei Details,
* dem Straßen Way, dieser dient als Träger der Straßen Eigenschaften, dieser zeigt auch den Straßenverlauf an.
* dem Leer Raum (Vorbereitung für spätere Straßen Flächen Elemente)
* dem Straßenrand Way, Träger der angrenzenden Flächen- Eigenschaft.
Die meisten Multipolygone sind durch diese Trennung bereits unnötig
mein Beispiel: https://www.openstreetmap.org/#map=19/47.52595/12.39868
Ich habe mir das Beispiel angeschaut. Ich finde es - sagen wir mal - suboptimal. Wieso werden von Dir die gepflasterten Flächen der privaten Grundstückseinfahrten aus landuse=residential ausgelassen? Das entspricht keiner der in https://wiki.openstreetmap.org/wiki/DE: … esidential aufgeführten Verwendungen (bei der einen werden die gesamten Siedlungsflächen inkl. der dazu gehörigen Straßen als landuse=residential eingezeichnet, bei der anderen die tatsächlichen Siedlungsgrundstücke unter Auslassung der Straßen). Grundstückseinfahrten sind aber Teil des Siedlungsgrundstücks und somit gehören sie eindeutig in die landuse=residential-Fläche.
Die von Dir genutzten Aussparungen für Zufahrten gaukeln auch eine Detailtreue vor, die aber tatsächlich nicht vorhanden ist. Was ist Zufahrt, was ist Fußweg zur Haustür, was ist Terrasse? Das gibt kein Luftbild so eindeutig her und ein exaktes Einzeichnen nach Besichtung vor Ort ist weder möglich (Betreten von Privatgrundstücken) noch ist es erwünscht, dass diese Details auf Wohngrundstücken ohne Einverständnis des Besitzer so detailliert eingezeichnet werden. Also: Wenn man Deinen Ansatz umsetzen wollte, müsste sich das Aussparen von Straßen auf tatsächliche Straßen beschränken. Die privaten Zufahrten auf den angrenzenden Grundstücken sind dagegen eindeutig landuse=residential.

Uns stehen in dieser Region sehr hochwertige Luftbilder von geoimage.at zur Verfügung, und ich wohne und lebe in dieser Gemeinde. In Österreich gibt es Panoramafreiheit. Zu den frei gehaltenen Straßenflächen. Diese halte ich in Vorbereitung für Flächenmerkmalen von Straßenflächen frei. Ich hoffe ich habe Deine Frage zur Detailtreue hiermit bentworten können.

Noch eine Anmerkung. Auch in der sogenennten Basemap, also unserem amtlichen Mitbewerber Produkt, werden Straßenflächen von anderen Flächenmerkmalen freigehalten. Warum ausgerechnet soll OSM das nicht dürfen, gibt es hierzu ein stilles Abkommen?. Nachdem das von Dir genannte Argument OSM Residential fließt über die Straßenfläche, geradezu gebetsmühelartig immer wieder kommt, bin ich geneigt in Verbindung mit der in Karto unterirdischen Rendering Breite von highway=residential genau solches anzunehmen.

edit:typo + text

Last edited by addresshistory*org (2019-01-01 10:57:40)

Mammi71 · 2019-01-01 09:53:50

addresshistory*org wrote:

Zu den frei gehaltenen Straßenflächen. Diese halte ich in Vorbereitung für Flächenmerkmalen von Straßenflächen frei.

In der weiteren Konsequenz bitte nicht nur die Flächen für Grundstückszufahrten, sondern auch die Flächen für Terrassen, Rasenfläche, Gemüsebeete, Swimmingpool etc. frei halten. Eigentlich gehört ein landuse=residential ausschließlich an die Flächen, wo das Wohngebäude drauf steht. Das ist zwar identisch mit building=*, aber egal. Alles andere ist dann nicht mehr residential. Auch nicht der Gartengeräte-Schuppen und auch nicht die Garage.
Das ist doch absurd!

addresshistory*org · 2019-01-01 10:25:23

Mammi71 wrote:

addresshistory*org wrote:
Zu den frei gehaltenen Straßenflächen. Diese halte ich in Vorbereitung für Flächenmerkmalen von Straßenflächen frei.
In der weiteren Konsequenz bitte nicht nur die Flächen für Grundstückszufahrten, sondern auch die Flächen für Terrassen, Rasenfläche, Gemüsebeete, Swimmingpool etc. frei halten. Eigentlich gehört ein landuse=residential ausschließlich an die Flächen, wo das Wohngebäude drauf steht. Das ist zwar identisch mit building=*, aber egal. Alles andere ist dann nicht mehr residential. Auch nicht der Gartengeräte-Schuppen und auch nicht die Garage.
Das ist doch absurd!

Allen Guten Morgen 2019! https://wiki.openstreetmap.org/wiki/DE: … ipolygonen

Wir weichen jetzt vom Thema ab, wenn Dir danach ist, bitte um einen eigenen Gesprächsfaden.

Last edited by addresshistory*org (2019-01-01 11:39:42)

kartler175 · 2019-01-01 12:09:05

Mammi71 wrote:

In der weiteren Konsequenz bitte nicht nur die Flächen für Grundstückszufahrten, sondern auch die Flächen für Terrassen, Rasenfläche, Gemüsebeete, Swimmingpool etc. frei halten.

Das brauchst Du iim nicht zweimal sagen: Beispiel

streckenkundler · 2019-01-01 12:40:49

addresshistory*org wrote:

Deine Angriffe sind nun ein excellentes Beispiel, was den kleinen Mappern blüht, sobald die aktuelle Proposal "Empfehlung" in Abstimmung abgeschlossen ist.
Inquisition

Komm mal bitte auf den Boden der Tatsachen zurück und unterlasse die Verwendung von Begriffen, die hier nichts zu suchen haben. Damit disqualifizierst du dich nur selbst...

aeonesa wrote:

@streckenkundler: Eigentlich wollte ich Dir schreiben: "Do not feedt the troll"

Danke für die Erinnerung...

Sven

Chrysopras · 2019-01-01 12:42:28

whb wrote:

addresshistory*org wrote:
Die Frage ist doch, wem nützt die hier vorligende Initiative von Michael.
Hauptsächlich den Mappern, welche sich nicht mit unnötig komplizierten MP herumschlagen wollen.

+1. Kein Bedarf für Verschwörungstheorien. Und letztlich sind diese „Mappe[r], welche sich nicht mit unnötig komplizierten MP herumschlagen wollen“, fast alle Mapper – denn wie whb gut schildert, schreckt so ein richtiger MP-Verhau keineswegs nur Anfänger, sondern auch erfahrene Mapper vom Warten und Verbessern der Daten ab.

Last edited by Chrysopras (2019-01-01 12:44:03)

addresshistory*org · 2019-01-01 12:55:17

Chrysopras wrote:

Und letztlich sind diese „Mappe[r], welche sich nicht mit unnötig komplizierten MP herumschlagen wollen“, fast alle Mapper – denn wie whb gut schildert, schreckt so ein richtiger MP-Verhau keineswegs nur Anfänger, sondern auch erfahrene Mapper vom Warten und Verbessern der Daten ab.

Die Verschwörung:
Was macht Michael hier: https://www.openstreetmap.org/changeset/56911458
Ein Mitarbeiter eines Tile Vermarkters, in Angelegenheit kleiner Mapper unterwegs, oder doch nur in Agenda seiner Firma?

Nicht zu vergessen wer diesen Gesprächsfaden hier "» users: Germany» Wir brauchen feste Regeln für die Verwendung von Multipolygonen!"
gestartet hat. Wobei ich mich nach wie vor frage, wem Nakaner mit "Wir" wirklich mein.

Mein Trauma ist aber der User 4rch, mich würde interessieren wem dieser Account, fürs Grobe zuzuordnen ist.

miche101 · 2019-01-01 13:22:58

Chrysopras wrote:

Und letztlich sind diese „Mappe[r], welche sich nicht mit unnötig komplizierten MP herumschlagen wollen“, fast alle Mapper – denn wie whb gut schildert, schreckt so ein richtiger MP-Verhau keineswegs nur Anfänger, sondern auch erfahrene Mapper vom Warten und Verbessern der Daten ab.

+1

Ja manchmal ist neu mappen (=altes löschen) einfacher als ändern

Announcement

#401 2018-12-30 21:37:44

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#402 2018-12-30 23:29:12

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#403 2018-12-31 00:37:29

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#404 2018-12-31 07:22:25

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#405 2018-12-31 13:39:35

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#406 2018-12-31 15:52:04

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#407 2018-12-31 16:46:41

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#408 2018-12-31 17:04:26

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#409 2018-12-31 17:26:59

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#410 2018-12-31 19:02:41

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#411 2018-12-31 19:24:27

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#412 2018-12-31 19:36:33

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#413 2018-12-31 21:32:35

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#414 2018-12-31 23:04:41

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#415 2019-01-01 01:53:38

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#416 2019-01-01 02:40:48

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#417 2019-01-01 02:45:11

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#418 2019-01-01 03:46:17

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#419 2019-01-01 09:53:50

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#420 2019-01-01 10:25:23

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#421 2019-01-01 12:09:05

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#422 2019-01-01 12:40:49

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#423 2019-01-01 12:42:28

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#424 2019-01-01 12:55:17

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

#425 2019-01-01 13:22:58

Re: Wir brauchen feste Regeln für die Verwendung von Multipolygonen!

Board footer