Was ist ein Import?

Aus gegebenem Anlass möchte ich hier eine Grundsatzdiskussion “vom Zaune brechen” mit dem Ziel, die Definition eines Imports zu präzisieren.

Im Wiki steht: “Ein Import ist der Vorgang der Hochladens externer Daten in die OSM-Datenbank.” (gestern frisch übersetzt, vom Englischen “Importing is the process of uploading external data to OSM”.)

Dort folgen dann zur Illustration Beispiele großer Importe nach OSM, und der Hinweis auf die Importrichtlinien. Es fehlen aber Hinweise, bei welcher Datenmenge ein Import anfängt, und ob ein Import einen bestimmten Automatisierungsgrad, verbunden mit einer bestimmten Geschwindigkeit voraussetzt.

Voraussetzung, von einem Import zu sprechen, ist natürlich die Lizenz-Kompatibilität der externen Daten, ansonsten wäre es ja ein Urheberrechtsverstoß.

Ich postuliere daher mal wie folgt:

**1. Ein Import beginnt mit dem ersten Datum, das aus einer externen Quelle nach OSM übernommen wird. **

2. Ein Import ist unabhängig davon, mit welchem Editor, Skript oder anderem Werkzeug er ausgeführt wird.

**3. Ein Import ist unabhängig von der Menge der Daten pro Changeset. Es kann ein einziges Datum pro Changeset sein, das Upload-Limit der API, oder jeder Wert dazwischen. **

4. Ein Import ist unabhängig davon, ob die Daten unwesentlich verändert oder in einer anderen Formatierung übernommen werden.

Wir sollten hier also zunächst Klarheit schaffen, was ein Import überhaupt ist. Ob wir verschiedene Ausprägungen eines Imports dann unterschiedlich betrachten, wäre der nächste Schritt.

Vielleicht hilft es ja, sich auch von der anderen Seite der Definition zu nähern, also zu fragen, was ist kein Import? Die Liste ist natürlich offen, hier ein Anfang:

5. Kein Import ist eine Beobachtung vor Ort.

**6. Kein Import ist die Verifizierung und Präzisierung einer Beobachtung vor Ort mittels der externen Daten. **

7. u.s.w.

Erläuterungen

zu 1.: Jede andere Zahl als 1 wäre willkürlich gewählt und unterläge subjektiver Betrachtungsweise. Bei einem Urheberrechtsverstoß ist auch bereits die erste Verwendung ein solcher, das kann eigentlich beim Import nicht anders sein.

zu 2.: Jede andere Formulierung würde dazu führen, dass die Import-Richtlinien in OSM durch Wechsel des Werkzeugs umgangen werden könnten.

zu 3.: Jede andere Festlegung würde dazu führen, dass die Import-Richtlinien in OSM durch das Aufteilen in mehr Changesets umgangen werden könnten.

zu 4.: Ob ich die Daten aus einer anderen Datenbank in maschinenlesbarem Format beziehe, durch ein Konverter-Skript jage und im OSM-Format hochlade, oder ob ich eine Visualisierung der anderen Datenbank, z.B. als WMS-Tile, im Editor hinterlege und die Daten abmale - das Ergebnis ist das selbe - potentielle Fehler der externen Daten werden übernommen, im zweiten Beispiel wird noch die Zeichen-Ungenauigkeit hinzugefügt. Solches Abzeichnen wird gern “händische” Übernahme genannt. “Andere Formatierung” meint z.b. das Vereinheitlichen von Telefonnummern im +49 30 00000-Stil.

genau, ein Import ist wenn man Daten von jemand anderem hochlädt. Es könnten auch eigene Daten sein die man über Jahre gesammelt hat und jetzt (mit großem zeitlichem Versatz) „en bloc“ hochlädt, zumindest wäre bei beidem das Importprozedere sinnvoll

Ich probier’s mal:

Das Schlüsselwort ist hier strukturiert.

Beispiele für strukturierte Quellen:

• Datenbanken wie https://www.emobility-partner.de/rest/public/poi
• “Die Gelben Seiten” in gedruckter Form
• Adresskarteien

Beispiele für unstrukturierte Quellen:

• Luftbilder
• streetview/mapillary
• Besichtigung vor Ort mit Photos, Augen, GPS, usw.

Grenzfälle:

• Digitale Karten, z. B. Häuserumrisse vom ALKIS abpinseln, eher strukturiert.
• Kontaktdaten vor Ort erfassen (Visitenkarte/Speisekarte, Öffnungszeiten im Fenster, etc.), eher unstrukturiert.
• Kontaktdaten von Homepages kopieren, auch eher unstrukturiert (weil jede Homepage anders)
• Mapping with AI, wo Luftbilder automatisiert ausgewertet werden. Eher unstrukturiert, weil die Quelle Luftbilder sind.

Hallo zusammen.

Hm…

Dann würde eine Nutzung eines Luftbildes (z.B. um Gebäudegeometrien zu verbessern) auch stets unter Import fallen?

Luftbilder sind externe Daten, sind genauso Geodaten. Es könnten z.B. systematisch erfasste Gebäudegeometrien aus hinreichend gut georeferenzierten Luftbilder (hier in Brandenburg die nutzbaren LGB-Luftbilder) letztendlich auch als Import (im weiteren Sinne) interpretiert werden.

…Es sind auch Geodaten…

?? oder ??

Sven

Nein, siehe #3 unter “Grenzfälle”.

Ja. Und im allerweitesten Sinne können auch die Erinnerungen in meinem Gehirn als externe Quelle interpretiert werden.

Spaß beiseite, worum geht es denn bei der Import-Richtlinie? Es geht darum, keine externen Datensätze automatisiert in die OSM-Datenbank zu kippen, ohne vorher genauestens abgesprochen zu haben, wie das geschehen soll, damit dabei keine Unfälle passieren. Einfacher ausgedrückt: Es geht darum, dass jede Änderung an der OSM-Datenbank eine Aktion eines gesunden Menschenverstandes sein sollte. Also führst du bestimmt keinen Import durch, wenn du Gebäudeumrisse selbst abmalst. Wenn du allerdings eine KI auf das Abmalen von Gebäudeumrissen ansetzt, die dabei ungeahnte Fehler machen kann, ohne dass du es merkst, dann kann man das durchaus als Import betrachten.

nein, weil wir nicht die pixel importieren sondern das Bild interpretieren und daraus Daten ableiten, das ist was anderes, die Daten schafft wer auf dem Luftbild was erkennt und zeichnet

… und ich dann parallel aus dem ALKIS-Gebäudelayer oder dem (auch nutzbaren) Datensatz der georeferenzierten Adressen die Adresse übernehmen… komme ich in den Graubereich…
Grenzen… nutze ich wms und pinsele Geometriesegmente ab… oder kann einzelne Geometriesegmente als findiger Kopf aus WFS extrahieren und nachnutzen. Im Ergebnis das selbe… in der Import/nichtImport- Disskussion… ???

Allgemein…

Für mich persönlich ist Möglichkeit, die Daten des LGB größer, als es das OSM-Wiki benennt.

Aber das ist durchaus eine Fragestellung, die ich nach der Datenfreigabe erwartet habe…

Sven

Das ist für mich der springende Punkt.
Karten mit z.B. Adressdaten, die als Hintergrund verwendet werden dürfen, enthalten die Daten in einer maschinell - für den Durchschnittsmapper - nicht verarbeitbaren Form. Ich sehe hier also demgemäß keinen Import.

Auch nach mehrmaligem Durchlesen der Änderungskommentare und des Threads hier kann ich noch nicht erkennen, was das Problem ist.

Geofreund1 hat händisch mit JOSM aus einem Layer, den wir offensichtlich offiziell verwenden dürfen, Adressdaten als Knoten in die Datenbank eingetragen. Alle Achtung vor der Fleißarbeit. Ich kann darin keinen Import erkennen.

Als Import sehe ich persönlich eher das automatisierte Hochladen externer Quellen in die Datenbank.

Insofern würde ich sagen, dass das WIKI in dieser Definition fehlerhaft ist. Das kann aber durch die Einfügung eines einzelnen Wortes und das Ersetzen eines Buchstabens wie folgt geheilt werden

…de**s automatisierten **Hochladens externer Daten…

Damit würde auch die Grammatik wieder stimmen.

Ein Problem würde ich darin sehen, wenn der verwendete Datenlayer massiv unkorrekte Daten enthält, die durch solch eine Fleißarbeit in die Datenbank kämen und durch lokale Mapper wieder aufwendig korrigiert werden müssten. Das ist aber schon wieder eine ganz andere Geschichte.

offtopicAbgesehen davon missfällt es mir sehr, wie ausufernd die CS-Kommentarfunktion genutzt wird. Ich denke, es ist nicht im Sinne des Erfinders, diese Funktion so zu nutzen und macht das Ganze ziemlich unübersichtlich. Dafür gibt es das Forum und die Mailingliste

Im Sinne der Disskussion würde ich da durchaus Ermessensspielraum sehen.

Aber Nein… Ich sehe Luftbildnutzung als solches natürlich nicht als Import an… sondern die Art und Weise der Nutzung der Daten…

…und nein, trotzdem ich weiß immer noch nicht, was und wie…

Sven

Das Problem ist, das alle Daten Fehler haben.

OSM hat Fehler, amtliche Daten haben Fehler, und amtliche Daten sind zuweilen zwar amtlich/formal richtig, aber die Realität vor Ort ist anders. Wenn ich nun im Glauben an die Amtlichkeit der Daten diese in OSM übernehme, und dabei noch vermeintliche Fehler - die aber durchaus die Realität vor Ort widerspiegeln können - wegbügele, schaffe ich zwar ein Abbild der amtlichen Daten, aber keine Verbesserung von OSM, und Frust bei dem Mapper vor Ort.

Und da macht es keinen Unterschied, ob ich einen ALKIS-Layer von Hand abzeichne, oder Vektorobjekte per WFS beschaffe und das Hochladen stärker automatisiere.

Beispiele:

• im Ort haben wir Gräben, die als Gemeindeland Grundstücke durchschneiden. Diese Gemeinde-Flurstücke entsprechen vielleicht dem Grabenverlauf bei der Erstellung vor 100 Jahren, bzw. dem damaligen Stand der Vermessungstechnik. Wenn jemand ein Haus bauen will, gibt es ggf. einen Flurstücktausch von Einzelschnipseln, ansonsten stört sich keiner daran. Wenn nun ein Mapper diesen Flurstücksverlauf als Wasserlauf abzeichnet, entspricht es aber nicht der Realität.

• Bei mir im Ort weiss ich z.B. von einem Häuserblock, der vor Ort genau umgekehrt nummeriert ist als es in ALKIS steht. Was nützt die tolle Fleissarbeit, die das nur aufgrund der amtlichen Adressknoten wieder ändert?

• Die Qualität von Hausumringen ist sehr unterschiedlich. Ein neues Haus muss laut Gesetz eingemessen werden, wenn der Bauherr das veranlasst, ist es (genauer, die Bodenplatte) auf 2cm genau in ALKIS. Wenn er es unterlässt, zeichnet das ein Praktikant im Amt irgendwann aus dem Luftbild ein. Das gleiche passiert mit Schuppen, Garagen, Carports, für die keine Vermessungspflicht besteht, sowie mit Altbestand. Hier finde ich viel Zeug, bei dem die Anzahl der aneinandergrenzenden Umringe nicht plausibel zur Struktur der Bauten passt. Welcher Umring nun genau vermessen und welcher nur abgescannt ist, dazu habe ich noch keine Daten gefunden.

Ja, da sind wir ja jetzt auch gelandet. Aber in der CS-Diskussion (Link siehe OP) hat sich herauskristallisiert, dass es ein grundsätzliches Problem ist, dass separater Diskussion bedarf.

Das alle Daten Fehler haben, ist klar. Ich, aus meiner persönlichen Betrachtungsweise heraus würde zum Beispiel äußerst vorsichtig mit Gewässernamen sein… Das steht jetzt aber nicht im Vordergund…

Ich möchte Wissen, ab welcher Stelle ich einen ungewünschten Import begehe, wenn ich in meiner Umgegend mir einen schlecht erfassten Ort mir heraussuche, Wege, Häuser, Landschaft ect. nach Luftbild ergänze/lageverbessere, Fehlende Hausnummern aus den Adressdaten ergänze, Grenzen nach WMS verbessere und eine Ortsteilgrenze (weil z.B. komplizierte Grenzsituation wegen Gewässer) in Teilsegmenten aus WFS nachnutzen würde, und das alles in einem CS hochlade?

Seitens der nun möglichen Datennutzung wäre/ist das für mich ein üblicher Verarbeitungsweg, wobei ich bewust direkte Nachnutzung von Vektorgeometrien bisher stets vermieden habe.

Sven

Was haben jetzt Fehler in den ALKIS Daten mit einem Import zu tun? Dein erster Satz in diesem Thread war doch

Ein Import von Daten und das händische Abmalen aus irgend einem vielleicht auch fehlerhaften Layer sind zwei verschiedene Paar Schuhe. Wenn Du ein Problem damit hast, das Daten, die uns zur Verfügung stehen, Fehler haben, und das hat jede Datenquelle mit Sicherheit, dann können wir aufhören zu mappen. Wenn ALKIS so gravierende Fehler hat, dann kann es zum Mappen nicht mehr verwendet werden.

Ich bin in der Hinsicht, das wir beim Mappen die Nutzung fehlerhafter Quellen bzw. die Anwendung fehlerhafter Mappingpraktiken, nur um Masse statt Klasse zu produzieren, vermeiden /unterbinden sollten, voll auf Deiner Seite.

Du solltest dann aber auch den Thread anders benennen.

Zu Deinen Beispielen kann ich auch noch eine Sache hinzufügen. In Großbritannien greift jetzt eine Unsitte um sich, dass man Reihenhäuser nicht mehr mit ihren tatsächlichen auf den Luftbild ersichtlichen Umringen zeichnet, sondern nur noch als Rechteck, um dann mit dem Teracer drüberzugehen. Der “Erfinder” dieser Praktik hat auch noch im Blog eine ausführliche Anleitung dazu geschrieben. Ich habe dazu einen sehr drastischen Kommentar geschrieben, weil ich finde dieses Masse statt Klasse Denken versaut unsere Daten, vergeudet Speicherplatz auf den Servern (weil auch OSM vergisst nix) und bürdet den lokalen Mappern auf, es dann wieder zu richten.

Aber weder Deine Beispiele noch mein Beispiel haben etwas mit einem Import zu tun, sondern eher mit der Qualitätssicherung beim Abzeichnen / Sesselmappen( Das habe ich bewusst jetzt mal so allgemein geschrieben). Weil Sesselmappen nichts mehr mit dem zu tun hat, mit dem ich mal angefangen habe. Nämlich GPS Spuren aufzuzeichnen, diese abzuzeichnen und aus Aufzeichnungen auf Papier z.B. Hausnummern einzutragen.

kommt auf den Layer an. Beim Luftbild ist es kein Abmalen im Sinne des Abmalens eines ALKIS-Renderings/Grundkarte.

Was hier ein bisschen vermischt wird ist das händisch (meint unter Betrachtung jedes einzelnen Teils) vs. automatisiert (und im einzelnen Fall „unkontrolliert“), weil die Importrichtlinie sich glaube ich nur auf den zweiten Fall bezieht.
Im Hinblick auf die Lizenzsituation ist es aber immer dann ein Import wenn man Daten die ein anderer gemacht hat, einstellt.

Mann muss sich schon manchmal wundern wie aktive Mapper aktiv aus OSM vergrault werden sollen.
Die Auslegung von Import und Automatisierung war schon immer grauenhaft. Je älter die Beiträgenden, umso grauenhafter.

Am besten 90% der Adressdaten wieder reviertieren…

Der Schaden den man so mit “bester” Absicht OSM zu fügt ist weit größer als mutwillige Zerstörung.

solche Forderungen hat doch überhaupt niemand gestellt. Wenn die Lizenz kompatibel ist, die Daten gut und die lokale Community sie will, dann spricht ja nichts gegen einen Import…

Dieser Thread hat seinen Ursprung in der CS-Diskussion (siehe #1) , wo es sinngemäß darum ging, wie im Land Brandenburg frei gegebene Adressdaten genutzt werden dürfen, und ob das massenhafte händisch Einpflegen dieser frei gegebenen Adressdaten, bei gleichzeitiger Prüfung jedes einzelnen Objekts nun zulässig ist oder nicht.
Ich bin es ehrlich gesagt auch leid, wenn immer wieder Leute, die anhand des frei gegebenen Datenmaterials vergleichsweise sehr viel zur Datenbank beitragen (wir haben hier in Brandenburg hoch auflösende Luftbilder und Adressdaten zur Verfügung), herab lassend als “Sesselmapper” bezeichnet werden.
Ich persönlich tracke auch viel und schaue mir die Gegenden, wo ich “Sessel-mappe” nach Möglichkeit auch
vor Ort an. Gleichzeitig denke ich immer auch an die Nutzer der OSM-Daten. Ich nutze selbst auch intensiv OsmAnd, und bin immer froh, wenn ich viele Daten vorfinde und möchte natürlich selbst auch mit möglichst vielen Daten beitragen.
Solches Klein-Klein der Mapping-Methoden der OSM-Anfangszeit (“Ich gehe jetzt mal raus und laufe mit dem GPS Tracker um 2 Häuser und schreibe mir die Hausnummern auf und wo die Parkbank steht werde ich auch auf der Karte vermerken…”) ist okay, kann man machen.
In meiner Heimatregion gibt es kaum aktive Mapper und die Karte hat nach wie vor teils extreme Defizite.
Da ist" Klotzen statt Kleckern" angesagt.
Ich brauche eine klare Auskunft, welche im Land Brandenburg frei gegebenen Daten man legal nutzen darf, und ob es Limitierungen gibt, wenn ja, welche.
Die Grunsatzdiskussion hier, was ist ein Import und was nicht, verwirrt mich eher.
Deshalb verzichte ich bis auf weiteres auf die Übernahme von amtlichen Adressdaten.

Herrlich – pünktlich zum Advent-Endspurt eine gaaanz grundsätzliche Grundsatzdiskussion, mit der wir uns über die Feiertage bestens streiten können. Super! Und nachher sind wieder einige aktive und sorgfältige Mapper vergrault und zig weitere sind beleidigt …

Also, im Ernst: man kann es mit dem craftmapping-Ideal auch übertreiben. Manche Kollegen möchten offenbar nur in der Datenbank haben, was sie selbst ausgemessen haben. Wie wäre es, wenn wir uns darauf konzentrieren würden, die bedenklichen Importe und echten Schlampermapper zu finden, und ansonsten weitermappen würden, statt wirklich hoch verdienstvolle Kollegen wie Geofreund1 zu ärgern?

das ist immer ein Problem, wenn es wenig Mapper gibt, weil dann das feedback vor Ort fehlt und niemand sich um die Pflege der vorhandenen Daten kümmert. Ein Import hilft da höchstens kurzfristig führt aber mittel- und langfristig dazu, dass man auf einem Haufen veralteter Daten sitzt und sich erst recht keine neuen mapper finden, die sich diesen Klotz ans Bein binden wollen. An der Schaffung einer Community führt kein Weg vorbei, es gibt da keine Abkürzung