Ich nehm mal an, ihr haltet die Daten lokal in Josm.
siehe Ungewollte Uploads verhindern
Gruss
walter
Das wirft bei mir einen 404er-Fehler.
Komisch - bei mir nicht.
eventuell mit https? Ungewollte Uploads verhindern
EDIT: hab was gefunden: sollte jetzt gehen.
operator=ast_tracker wurde in OSM hochgeladen
Gefällt mir nicht, weil ein undokumentierter Schlüssel wieder die Frage nach dem “Was soll das” aufwirft.
Warum nicht für die TU das cn_tud=* (Gebäude) ein ast_tud=* dokumentieren. Ihr braucht ja nicht die Werte veröffentlichen, die euch zum idendifizieren dienen.
Vielleicht kann es auf der TU Dresden Seite mit eingefügt/dokumentiert werden - Siehe meinen Beitrag weiter oben.
Kannst ja auch einmal ein Beispiel verlinken. Man kann ja mehrere Flächen mit dem tatsächlichen Operator belegen, wenn eine öffentlche Nennung möglich ist (Agrargenossenschaft “Land und Wiese”, …)
Anscheinend war das wohl doch möglich, und das nicht nur einmal. Siehe den ersten Post hier ganz oben von geri-oc, dort hat er ja einige Changesets verlinkt. Dort könnt ihr dann den OSM-Account und auch die Zeit, wann es hochgeladen wurde nachschauen.
Und nochmal: eure Daten sind bereits öffentlich in der Datenbank einsehbar! Wenn ihr das nicht wollt, müssten die Changesets reverviert werden.
Ihr habt unserer Vereinbarung für Mitwirkende zugestimmt, damit ist das Kind schon in den Brunnen gefallen.
Es wurde übrigens nicht JOSM verwendet, sondern iD und einmal Potlatch 2. Die waren sich entweder nicht bewusst, was sie tun, oder wollten sich das Geld und den Aufwand des Betriebs einer eigenen Geodatenhaltung sparen. Sorry, aber OSM ist dafür nicht da!
Soll der Overpass-Turbo-Link vom ersten Post des Nakaner ein Beispiel für unsere Daten sein?
Wenn ja, dann muss ich mal entschieden widersprechen. Wir haben mit diesen Flächen und den darin eingezeichneten Spuren absolut nichts zu tun (sollte man auch am Bearbeiter erkennen). Und nochmal: Wir laden keine Fahrspuren oder sonstwas hoch, was sollen wir bitteschön öffentlich gemacht haben - “… Kind in Brunnen gefallen…”. Natürlich wissen wir, dass wir die Rechte abtreten, aber da wir keine Daten hochladen, tangiert es uns nicht. Im Übrigen: wenn der Operator der Eigentümer/Nutzer der Fläche ist und wir genau diesen Flächen mit Zustimmung der wahren Eigentümer/Nutzer nutzen, dann finde ich die Aufregung hier ein bisschen übertrieben. Der kommerzielle Zweck ist nicht da, wir haben es bisher nicht besser gewusst und wenn wir jetzt schon frei verfügbare Felder nutzen möchten (wie es vorgeschlagen wurde), dann sollte das auch mal respektiert werden.
Bitte jetzt nicht als Vorwurf oder Angriff sehen, aber letztendlich hast du selbst vor 30 Tagen operator=ast_tracker hinzugefügt und dabei handelt es sich eben definitiv NICHT um einen Eigentümer!
Auch wenn ich das Gefühl habe, dass hier teilweise aneinander vorbei diskutiert wird bleibt doch festzuhalten:
Operator ist nicht ein frei verfügbares Feld, nur weil es bei Ackerflächen in der Regel nicht genutzt wird.
Ein Operator ist ganz klar ins Deutsche übertragen der Betreiber von etwas. Laut OSM-Wiki z. B. Unternehmen, Privatperson, öffentliche Körperschaft. ast_tracker ist offensichtlich nicht der Betreiber der Ackerflächen. Damit ist Operator=ast_tracker schlichtweg ein Falscheintrag.
Setzt man einen Acker mit einer Produktionsstätte gleich, ist Betreiber der Ackerfläche derjenige, der auf dem Acker Ackerbau betreibt. Das kann der Besitzer des Ackers sein oder der Pächter eines Ackers.
Es sollte auch darauf geachtet werden, Begriffe nicht zu vermischen:
Der Begriff Operator (=Betreiber) ist nicht identisch mit User (Nutzer)
Der Begriff Operator (=Betreiber) ist auch nicht identisch mit Eigentümer (Owner)
Auch sollte
Erst einmal ist der overpass eine “Funktion” die man “ausführen” sollte um ein Ergebniss zu erhalten. Jetzt sind dort keine Daten mehr zu finden, da ich diese ja “entfernt” habe.
Hier habe ich eines übersehen:
http://www.openstreetmap.org/way/261073936
Dort kannst du noch deine Eintragung sehen (operator=ast_tracker) und nur diesen. Fahrspuren habt ihr nicht hochgeladen.
Noch einmal operator ist der Betreiber. Wenn dort steht “Landwirt A. Mustermann, Musterdorf” oder “AGRA “Sonne”, Regendorf”
bezeichnet das den operator.
Ihr wollt aber mit “asttracker” eure Felder wiederfinden - warum nicht mit ast_tud:token=ast_tracker (ast_tracker_1) oder numerisch (als Beispiel) ast_tud:token=S10010 (Sachsen, 100=Traktoren, 10=Bauer Mustermann - B=Brandenburg, 200=Mähdrescher, 12=Bauer Musterfrau)
Dokumentieren solltet ihr:
“ast_tud:token=* ist ein Schlüssel der Agrarsystemtechnik an der TU Dresden. Er dient der Erfassung landwirtschaftliche Prozesse wie Feldbestellungen, Pflege und Ernte” - Die Bedeutung Werte (*) sind uninteressant und intern.
In Absprache (als Koordinator sollte vielleicht die Professur für Geoinformatik dienen - oder Fakultät Bauingenieurwesen der TU setzt sich den Hut auf) kann es vielleicht hier sein: http://wiki.openstreetmap.org/wiki/User:TEAM_CN_TUD
Vielleicht helfen die Kollegen, die bereits cn_tud:token=* nutzen: http://navigator.tu-dresden.de/mitarbeiter weiter.
Nun habe ich hier genug gesagt.
- ja, bestimmt
- wollen sie auch nicht - eigene Daten (Spuren und Daten) sind separat
- es wird ein Schlüssel zur Identfikation benötigt, um Daten in OSM wiederzufinden und zu verknüpfen
Änderungsatz revertet und geändert - um die Möglichkeit einer Abfrage und Schlüssel/Wert-Änderung für die Studienarbeit zu ermöglichen. Schlüssel operator=* → ast_tud:token=ast_tracker (ast_tracker ist nur vorübergehnder Wert)
http://overpass-turbo.eu/s/jwq
Dokumentierung der Schlüssel soll erfolgen. TU möchte auch die Dokumentation der Schlüssel (z.B. des CampusNavigator cn_tud:token, cn_ukd:token, …) verbessern.
Dem kann ich nur zustimmen. Die Geometrien der Felder werden für ein uni-internes Projekt benötigt und mit der Kennzeichnung kann ansonsten niemand etwas anfangen.
@Laseko: Erweitert bitte eure Datenbank, in der schon die Fahrspuren und sonstigen Daten der Bauern und Felder enthalten sind, um eine Tabelle mit den Feldgeometrien und verwendet OSM nur als Hintergrundkarte.
Welche Datenbank wird verwendet?
Wie wird festgestellt, auf welchen Feld sich die Fahrspur befindet?
Werden sonstige Komponenten der OSM-Infrastruktur benutzt (Nominatim, Overpass, …)?
Wenn ja, wie?
Grüße
Joachim
Danke für alle Tipps und Hilfen,
wir arbeiten an einer Möglichkeit, um zukünftig wirklich ALLES lokal zu halten.
Zu den Fragen von DD1GJ: Wir nutzen als DB mysql auf einem sogenannten LAMP-Server. Zur Identifikation der Felder, wo sich unsere Fahrspuren befinden legen wir zuerst lokal die Fahrspur auf eine Karte. Dann wird manuell in OSM gesucht, wo das Feld ist. Wenn es schon eingetragen ist, dann haben wir diesen Variableneintrag ast_tracker gemacht. Unser lokales Auswerteprogramm schaut dann auch mit einer Overpass-Abfrage nach, wo es unsere Einträge gibt. Die Treffer werden dann wiederum lokal angezeigt und ausgewertet.
Nominatim kennen wir, hilft uns aber nicht wirklich, weil keine nutzbaren Infos für uns vorhanden sind.
Hallo, auch ich gehöre zum Projekt an der TU Dresden.
Ich habe soeben versucht, eine lokale Kopie der OpenStreetMap Daten so zu modifizieren, dass dort unsere Felder wie gehabt mit operator=ast_tracker gekennzeichnet werden. Damit könnten dann unsere öffentlichen Einträge in der OSM weg und würden keinen mehr stören!
Allerdings hab ich das Ganze nicht hinbekommen und bräuchte etwas Hilfe…
Wir greifen bisher folgendermaßen auf die OSM Daten zu:
-Felder, die wir in unserem Programm (was als Webseite realisiert ist) anzeigen lassen möchten, werden in OSM mit operator=ast_tracker gekennzeichnet
-Wir ziehen uns regelmäßig den relevanten Ausschnitt der OSM-Daten von geofabrik (http://download.geofabrik.de/europe/germany/sachsen-latest.osm.bz2)
-Diese .osm.bz2 Datei laden wir in einen von uns selbst betriebenen Overpass-Server
-Dieser Overpass Server wird von unserem Programm abgefragt: “Gib mir alle Felder, die das Attribut operator=ast_tracker haben”
Meine Idee wäre jetzt: Wenn ich die sachsen-latest.osm.bz2 Datei lokal editieren könnte, kann ich einfach lokal unsere Felder markieren ohne das ganze zu OSM hochzuladen und niemand bekommt etwas davon mit. Am besten wäre es sogar, die lokal modifizierten Felder irgendwie in eine eigene .osm Datei auslagen zu können, damit die “Basis-Daten”, also die öffentlichen Daten, regelmäßig von geofabrik aktualisiert werden könnten.
Zum lokalen Editieren hätte ich jetzt JOSM verwendet. Dort gibt es ja verschiedene Layers, ich könnte mir vorstellen, dass damit die Trennung von “Basis-Daten” und modifizierten Feldern möglich wäre.
Das Problem ist nun, dass ich nicht weiß, wie ich das mit JOSM umsetzen kann. Ich habe einfach mal versucht die sachsen-latest.osm.bz2 zu laden, da diese aber zu groß ist, stürzt mir JOSM dabei ab.
Könnte mir daher jemand weiterhelfen und beurteilen ob die Idee so überhaupt Sinn macht und wie ich sie umsetzen kann?
Hallo Laseko und philipp3121,
danke für die ausführliche Erklärung. Ich habe eine Overpass-Abfrage erstellt, die eure Felder selektiert und die Daten im OSM-Format bereitstellt. Diese Daten können dann abgespeichert und direkt in JOSM geladen werden.
http://overpass-turbo.eu/s/jEy
Ich habe den Eindruck, dass ihr mit einem erheblichen Overhead arbeitet, um die Fahrspuren den Ackerflächen zuordnen zu können. Ich habe folgende Ideen:
- lokale JOSM-Lösung
Nehmt die oben generierte OSM-Datei als Grundlage und ladet sie lokal in JOSM. Wenn ein neues Feld hinzukommt, malt es in der Ebene der geladenen OSM-Datei nach und speichert wieder lokal ab ohne die Datei hochzuladen. So habt ihr zum Nachschauen eine eigene Umgebung, völlig abgekoppelt von der OSM-Datenbank.
- Geodatenbank
Verwendet eine richtige Geodatenbank wie z.B. PostgreSQL mit PostGIS Erweiterung. Macht aus allen Ackerflächen eine Shape-Datei, die dann in eine Tabelle geladen wird. Dafür und für die weitere Pflege ist. z.B. QGIS geeignet. Mittels ST_Within könnt ihr automatisch feststellen, auf welchem Acker der Track oder jeder einzelne Punkt liegt und habt sofort die restlichen (nicht öffentlichen) Daten im Zugriff.
Nachtrag:
Die Dateien der Geofabrik lassen sich mit folgenden Tools bearbeiten:
https://wiki.openstreetmap.org/wiki/DE:Osmconvert
https://wiki.openstreetmap.org/wiki/DE:Osmfilter
Viel Erfolg
Joachim
Hallo,
mal ein kleines Update zum aktuellen Stand: geri-oc war so nett seine Änderungen zu reverten und die Schlüssel für jedes Feld von operator zu ast_tud:token zu ändern (Danke!). Dazu gibt es mittlerweile auch einen Wiki-Eintrag: https://wiki.openstreetmap.org/wiki/User:Ast_tud
Wie bereits oben beschrieben, arbeiten wir an einer Lösung um alle relevanten Informationen lokal speichern zu können. Bis dies fertig ist, würden wir die ast_tud:token Tags gesetzt lassen, wenn das so für alle in Ordnung ist?
@DD1GJ: Danke für die Hilfe! Die lokale JOSM-Lösung finde ich schonmal gut (man könnte noch ein Skript schreiben, das als Input die OSM-ID eines Feldes nimmt, dessen Daten von Overpass-Turbe lädt und automatisch der lokalen OSM-Datei hinzufügt - dann spart man sich immer JOSM zu verwenden, wenn es das Feld in OSM schon gibt). Weißt du zufällig noch, ob man beim Initialisieren eines eigenen Overpass-Servers (beschrieben hier) Daten aus mehreren .osm Dateien “einspeisen” kann?
Von der zweiten Idee versteh ich nicht viel, werd mir das aber mal anschauen. Vorallem die Möglichkeit zu prüfen, auf welchem Feld ein aufgezeichneter Punkt liegt, klingt vielversprechend!
Hallo philipp3121,
Mit Osmconvert könntest Du mehrere OSM-Dateien zusammenfügen und diese Datei dann in Overpass laden.
Allerdings ist mir immer noch nicht klar, welche Aufgaben außer “Gib mir alle Felder, die das Attribut operator=ast_tracker haben” der Overpass-Server sonst noch hat. Würde er nur für diese Aufgabe gebraucht, dann wäre das wie eine Kiste Bier mit einem 40 Tonnen Sattelzug auszuliefern.
Grüße
Joachim
Perfekt, genau so etwas habe ich gesucht! Beim googlen wie man mehrere Dateien in Overpass bekommt, hatte ich nichts gefunden… Eventuell kann man auch einfach den Initialisierungs-Prozess mehrmals mit verschiedenen Dateien ausführen und die DB wird erweitert statt überschrieben, das hab ich aber noch nicht getestet.
Dass ein Overpass-Server nur für diese Sache etwas übertrieben ist, ist mir bewusst… Allerdings ist das, wie das System derzeit implementiert ist und das so weiter zu verwenden ist erstmal der Weg des geringsten Widerstandes… Es würde sogar alles weiterhin funktionieren ohne überhaupt etwas am Code des Programmes zu ändern 
Trotzdem werd ich mir die Geodatenbank mal anschauen, hab gerade eben aber nicht die Zeit dazu!
Ich denke damit ist das Thema besprochen, ich werde mich noch einmal melden, sobald unsere Attribute komplett aus der öffentlichen OSM raus sind.
Danke an alle die geholfen haben und danke an Joachim für die Tipps zur lokalen Speicherung!
Entschuldigt, dass ich mich zu dem Thema erst so spät melde. Habe die Mail wohl etwas übersehen…
Grundsätzlich habe ich die Einträge in die OSM Datenbank zu dem Thema im Rahmen einer Studienarbeit begonnen. Damals noch etwas grün hinter den Ohren bestand der Bedarf eine Liste intern gemappter Felder für die Auswertung von Analysedaten heranzuziehen, also eine Verknüpfung zwischen Messdaten und Ortsbezug herzustellen.
Natürlich wäre es kein Problem gewesen, intern - soll heißen nicht sichtbar für OSM - ein Mapping zwischen OSM ID und Bauer X,Y,Z herzustellen. Dafür sind aber meiner Meinung nach OSM Ids nicht geeignet, da sie keine Persistenz garantieren. Was passiert also z.B. wenn jemand ein Feld löscht und dafür zwei neue anlegt? Ähnliche Problematiken finden sich zuhauf.
Aus diesem Grund befürworte ich auch den Vorschlag von geri-oc. Internalisierung dieser keys wird in der Zukunft zu Inkonsistenzen führen. Vielleicht könnte man den Tag ja auch so sinnvoll gestalten, dass er für den Rest der OSM Welt Sinn ergibt?
Weiterhin dürfte die Erfassung/Verbesserung von (realen) Feldgrenzen, bzw. die Unterteilung von Feldern, ja auch im Interesse der OSM Community sein. So genaue Messwerte im sächsischen Land dürften sonst selten vorliegen.