Das widerspricht sich jetzt…
Auf der Grunlage kann ich nicht disskutieren.
Sven
OSM ist ein Community-Projekt und lebt von einigen wenigen Community-Regeln, die du als Mapper der ersten Stunde ganz genau kennst. Deine Quick-and-dirty-Vorgehensweise widerspricht dem Community-Gedanken von OSM in mehrfacher Hinsicht. Ich zitiere mal ein wenig aus dem OSM-Wiki:
- Wenn du eine automatische Bearbeitung planst, solltest du deine Pläne im Voraus besprechen und dokumentieren.
- Wenn es einen breiteren Widerstand gibt, solltest du möglicherweise deine Pläne überdenken.
- Normalerweise solltest du deine vorgeschlagene Bearbeitung auf einer englischsprachigen Wiki-Seite dokumentieren
Wenn du statt deines unabgestimmten Taggings an den 2200 Denkmalen das subject:wikidata angefügt hättest (und einiges anderes mehr, siehe hier), dann wäre dies ein wesentlich größerer Mehrwehrt für OSM gewesen, denn dieses Tagging wird von zahlreichen Webseiten/Apps - die hier bzw. im Nachbarthread mehrfach erwähnt wurden - ausgewertet.
Du hast jetzt hinlänglich deine Argumente und Beweggründe vorgetragen, dann mach doch bitte ein offizielles Proposal und dann kann die OSM-Community - auch die Internationale - deinen Vorschlag diskutieren und darüber abstimmen.
1 Like
Das widerspricht sich doch nicht. Du schickst den Link einer Overpass-Abfrage ohne eine Erklärung zu geben was du aus den zurückgelieferten Daten liest, was damit in dieser Diskussion angefangen werden kann.
Meine Daten stammen auch einer overpass-Abfrage, aber ich habe sie aufbereitet, gefiltert und danach den Daten mit einer Erklärung einen Bezug zu dieser Diskussion gegeben.
Blockzitat Für mich sehr wichtig: Die Leute, die z.B. hinter https://gk.historic.place/ stehen müssen mitgenommen werden, sonst ist das alles eh für die Katz und Datenmüll
Nur weil wir erwähnt wurden, es braucht nicht viel Schulbildung, zu erkennen, das black_bike recht hat.
Es wäre schade, würde eine gute Idee wiedermal dem “Prinzip” geopfert.
Mir ist das weiterhin deutlich zu viel Text. Zuerst gibt es drei Beiträge mit Zahlen. Hier hätten entprechende Links zu Taginfo gereicht, wo die Zahlen tagesaktuell sind.
Dazu meinst du:
Mein Argument dagegen: Was interessieren mich die Zahlen von gestern?
Nach den drei Beiträgen wird es endlich konkret - dachte ich. Zuerst folgt aber noch ein Exkurs, was Denkmäler sind und wie diese in OSM erfasst werden. Das ist hier im Forum sicherlich hinlänglich bekannt.
Aber dann:
Ja, das ist wahrscheinlich tatsächlich ein Problem. Leider bietest du dafür aber keine Lösung, sondern lediglich die Einführung eines weiteren redundanten Tags, dass das bereits als Kriegsdenkmal klassifizierte Objekt als ebendas markiert.
Danach folgt wieder ein Exkurs zu Stolpersteinen und Geisterräder bevor du zum ersten Mal deine Beweggründe für ein neues Tag nennst (wohlgemerkt nach 3,5 Beiträgen):
Und du lieferst die Lösung:
Das Problem ist nur: Du hast dir die “Lösung” nicht nur überlegt, sondern auch direkt umgesetzt.
Dann folgt Beitrag Nr. 5 in dem du subject:category vorschlägst und erläuterst, warum subject:wikidata nicht in Frage kommt. Als Grund wird hauptsächlich die Abhängigkeit zu und die Komplexität von Wikidata genannt und dass Overpass einfacher in der Nutzung ist. Und bei letzterem sehe ich auch den Hauptgrund, warum du ein neues Tag einführen willst: Weil es für dich einfacher ist.
Bisher überzeugen mich deine Argumente nicht, was aber auch daran liegen mag, dass du schonmal Tatsachen schaffst, bevor es überhaupt zu einer Diskussion kommt.
1 Like
Danke lutz, tut gut auch mal etwas Unterstützung zu bekommen.
Ich gehe naturlich selbst auch davon aus dass ich recht habe.
Aber das muss ja nicht in allen Punkten so sein. Und für Hinweis wo das nicht der Fall ist und wo ich irre, etwas falsch gemacht habe bin ich sehr dankbar.
Nur so kann es besser werden.
1 Like
In Kurzform (speziell für aixbrick)
memorial=war_memorial ist ein Problem
Lösungsweg 0:
memorial=war_memorial
Wir lassen alles wie es ist.
Lösungsweg 1:
memorial=stone
Wir verlieren zwar die Info, dass es ein Kriegsdenkmal war, aber jetzt kennen wir die Form, konsistent mit den anderen 70000 Denkmalen in DE.
Lösungsweg 2:
memorial=war_memorial
memorial:form=stone
Wir kennen jetzt Form und Widmung, aber inkonsistent zu den anderen 70000 Denkmalen in DE
Lösungsweg 3:
memorial=stone
subject:category=war
Beide Infos zu Form und Widmung können auf diese Weise konsistent für alle 77000 Denkmale in DE angelegt werden.
Ich habe mich für Lösungsweg 3 entschieden.
In einem ersten Schritt die Info über Kriegsdenkmal in neuem Tag gespeichert. In einem zweiten Schritt kann dann unter memorial= die Form des Denkmals eingetragen werden.
Welchen Lösungsweg hättet ihr gewählt?
Es ist aber 62.000 mal in Verwendung und dokumentiert.
Ich habe das Problem noch net verstanden. Geht es darum, dass Du war_memorial + stone setzen möchtest? Dann wäre material=stone eine Lösung.
Genauso schade ist es, dass hier das Potenzial von Linked Open Data ignoriert und eine OSM-only Lösung geschaffen wurde, die nur exakt dieses eine Problem löst.
Wenn ich mir die Größe des Wikidata-Projektes anschaue, halte ich diese Risiken einer Abhängigkeit für vernachlässigbar.
Unvollständigkeit ist bei Wikidata genauso verbreitet wie bei OSM. Wir gehen ja auch nicht hin und raten Menschen von der Nutzung von OSM ab, weil dort noch Dinge fehlen. Wir laden sie stattdessen ein, sie zu ergänzen. Wenn dir in Wikidata also Informationen zu einem Denkmal fehlen, kannst und solltest du sie dort ergänzen.
Das Schreiben einer SPARQL-Query ist auch nicht komplexer als das Schreiben einer Overpass-Query. Ich wette, es gibt mehr Menschen, die SPARQL beherrschen als Overpass. Zum Thema zeitnah habe ich oben ja schon eine Beispiel-Query verlinkt, die auf Live-Daten arbeitet. Abgesehen davon ändern sich in deinem spezifischen Anwendungsfall die Daten nun auch nicht so schnell, dass eine wöchentliche Aktualisierung nicht reichen würde.
Wenn es eine Lösung gibt (oder sie zumindest vorstellbar ist), die selbst für komplexe Informationen funktioniert, warum sollte man dann für marginal einfachere Informationen eine andere Lösung wählen? Wir reden hier ja nicht von Dingen, die primäre Geodaten sind, für die OSM erfunden wurde, sondern von Meta-Daten über Denkmäler. Was ist an der Kategorie des Subjekts des Denkmals so viel weniger komplex als an den Preisen der durch das Denkmal gewürdigten Person, dass das eine in OSM gehört und das andere nicht?
In OSM passiert das nicht oft, das stimmt. Gute Gründe dafür habe ich bisher nicht gehört.
Schon komisch: Wir füllen als Community eine detaillierte Datenbank und stellen sie öffentlich frei zur Verfügung, weil wir das für eine gute Sache halten, aber wenn eine andere Community dasselbe tut, gibt es angeblich “gute Gründe”, das nicht zu nutzen. Sprächen dann nicht dieselben Gründe auch dagegen, OSM zu nutzen?
2 Likes
Lösungsweg 4: (inspiriert aus dem OSM-Wiki):
historic=memorial
memorial=stone // bzw. entsprechend dem Objekt
war_memorial=yes
memorial:conflict=WW2 // bzw. entsprechend dem Objekt
subject=* (Wird empfohlen, bisher aber kaum verwendet)
material=stone // bzw. entsprechend dem Objekt
height=*
inscription=*
...
Siehe auch:
2 Likes
Und bei letzterem sehe ich auch den Hauptgrund, warum du ein neues Tag einführen willst: Weil es für dich einfacher ist.
Nein, es ist auch für die meisten anderen Anwender einfacher!
Es ist legitim, das jemand der jahrelang zu OSM beigetragen hat eine einfache Lösung für sein Problem sucht.
Also der Widerspruch in den Changesets und im Forum zeigt, das @black_bike eben gerade nicht unbedingt Recht hat. Allen Diskutierenden jetzt die Schulbildung abzusprechen, finde ich nicht gerade die feine Art von dir @lutz - insbesondere da @black_bike zunächst pauschal jede Diskussion abgelehnt hat und den vorgetragenen Bedenken keinerlei Aufmerksamkeit schenken wollte. Ein paar Tage später meint er dann, mittels einer Overpass-Karte die Nützlichkeit seines Taggings im Kontext eines Gedenktages Gewicht verschaffen zu können.
Das ändert aber nichts daran, dass hier Community-Regeln nicht eingehalten wurden. Die wenigen Regeln, die wir haben, sollten von Allen respektiert werden, denn sie gelten für alle Beitragende - egal wie lange man dabei ist und welche wie auch immer gut gemeinten Absichten damit verfolgt werden sollen.
Ich kann mich den Ausführungen von @mstriewe nur anschließen und das Potential von Linked Open Data sollte viel mehr genutzt werden. Wikidata und OSM können sich gegenseitig ergänzen und bieten gemeinsam noch sehr viel mehr Potential. Die Verknüpfung von OSM-Objekten mit den Meta-Daten in Wikidata hat enormes Potential, weswegen dies auch zunehmend getaggt wird. Das Equal-Street-Names-Projekt und die OpenEtymologyMap zeigen, was hier möglich ist.
Das Erfinden und massenhafte Setzen neuer Tags, damit man SEIN gewünschtes Ergebnis in Overpass abfragen kann (weil man “sehr tief drin in der Nutzung von Overpass” ist), widerspricht eindeutig den OSM-Prinzipien. Die Community-Regeln sind von @black_bike, wie schon dargestellt, in mehrfacher Hinsicht missachtet worden. Somit ist ein vollständiger Revert angezeigt (@woodpeck).
Die zahlreichen Verlinkungen zu verschiedensten (internationalen) Diskussionen mit Bezug zum Memorial-Tagging und der bisherige Diskussionsverlauf zeigen ja gerade, dass ein ordentlicher Proposal-Prozess erforderlich ist.
4 Likes
Ich habe mich nicht gegen die Nutzung von Wikidata, bzw, dem Tag subject:wikidata ausgesprochen. Ich begrüße die Verknüpfung dieser beiden Projekte sehr und mache dafür an anderer Stelle auch fleißig Werbung.
Ich möchte nur, dass es für die drei Kerninformation eines Denkmals, also
- Position
- Form
- Widmung
in OpenStreetMap eigene Möglichkeiten gibt diese konsitent abzulegen.
Da dies mit den bisher genutzten Tags nicht möglich war habe ich in einer stillen Stunde nach einer Lösung gesucht und dann das neue Tag subject;category erdacht.
Genauso schade ist es, dass hier das Potenzial von Linked Open Data ignoriert und eine OSM-only Lösung geschaffen wurde, die nur exakt dieses eine Problem löst.
Linked Open Data steckt noch in den Kinderschuhen, ich finde es immer merkwürdig, wenn EDV Fachleute bzw. Programmierer für normale Anwender Lösungsvorschläge machen die extreme Fachkenntnisse voraussetzen.
Hier wird der normale Mapper zum reinen Datenlieferanten degradiert.
Wenn dem Harald hier empfohlen wird sich in mehreren großen Projekten gleichzeitig zu beteiligen, kann ich nur sagen, geh zu Wikidata und lass das hier sein.
Genau darum fängt man an
“Hey leute,
ich habe das Problem AB erkannt.
Das ist ein Problem weil: CD
Ich habe eine Idee, wie ich das lösen könnte, und zwar: EF
Was verspreche ich mir davon? GH”
Da hätte man sich viel Diskussion gespart. Und das fehlt mir immer noch, kurz und knapp, nicht über 7 Postings verteilt mit Infos, die danach kamen.
Da dies mit den bisher genutzten Tags nicht möglich war habe ich in einer stillen Stunde nach einer Lösung gesucht und dann das neue Tag subject;category erdacht.
Ja, aber warum nicht vorher im Forum drüber geredet, bevor man sich so viel arbeit antut, was am ende vielleicht sogar revertiert wird?
3 Likes
Ich bin ein wenig überrascht, dass in dieser Diskussion überwiegend die Meinung vertreten wird, dass Memorial-Auswertungen unter Hinzuziehen von Infomationen aus Wikidata überhaupt kein Problem darstellen, mit Ausnahme vom Topicverfasser selber und @lutz.
In dem von mir bereits zuvor verlinkten Thema hat man mir ganz im Gegensatz dazu nachdrücklich klar gemacht, dass es überhaupt keine gute Idee ist, auf eigene Tags zu Gunsten von Wikidata-Links zu verzichten. Ich zitiere eine Zusammenfassung:
Memorials sind nicht meine Baustelle, aber ich finde den Ansatz von @black_bike unter diesem Aspekt durchaus bedenkenswert.
Im Gegensatz dazu finde ich genau wie alle anderen die Art und Weise des Vorgehens in keiner Weise korrekt, aber das sollten wir jetzt eigentlich zu Genüge abgehandelt haben.
Mein Vorschlag: Wir haken das Vorgehen jetzt erst mal ab und versuchen, einen Konsens zu der Frage zu finden, ob eine generelle Erweiterung der MemorialTags wünschenswert ist oder nicht.
Falls nicht, ist das Thema durch.
Falls ja, käme als nächstes, ob die von @black_bike vorgeschlagenen Tags dafür in Frage kommen oder nicht.
So könnte man sich langsam konstruktiv einer Lösung nähern.
7 Likes
Liebe Leute, tretet doch mal alle einen Schritt zurück und betrachtet das Ding aus einer anderen Perspektive:
Was kann denn das neue hier vorgestellte Tag subject:category dafür, das ein durchgeknallter, egoistischer, unkommuniktiver, hypersensibler Typ es schon “einige Male” Probe gefahren hat bevor die TÜV-Plakette des Diskussionsforums drauf geklebt wurde?
Also hier bitte nur Prüfung des Transportmediums subject:category.
Und ob der durchgeknallte Typ seinen OSM-Schein behalten darf wird an anderer Stelle entschieden.
1 Like
Dann habe ich den folgenden Satz von dir wohl missverstanden:
Egal, Schwamm drüber. Schön, dass du andersnorts sogar Werbung für die Verknüpfung mit Wikidata machst!
Jetzt stehe ich auf dem Schlauch. Die Widmung ist für mich das “subject” (egal mit welchem Tag gekennzeichnet), während “subject:category” nach meinem Verständnis und deiner Doku bereits eine Meta-Information über die Widmung ist. Genau diese Information ist nach meinem Empfinden in Wikidata besser aufgehoben, da die echt gut darin sind, Sachen zu kategorisieren.
Hier geht es nicht nur um eine Erweiterung, sondern manche Tags wie z.B. memorial=war_memorial sollen zugunsten neuer Tags (subject:category etc.) deprecated werden.
Das ist global gültig und betrifft nicht nur Deutschland und muss aufgrund der Verbreitung der etablierten Tags durch ein Proposal geschehen.
@black_bike Wäre das OK für Dich? Du hast Dich intensiv damit beschäftigt, hast einen guten Vorschlag auf dem Tisch, also warum nicht den “offiziellen” Weg gehen. Ich wäre dafür.
1 Like
Zu einem Proposal mit memorial=war_memorial auf deprecated zu stellen und auch subject:category in ein Proposal zu stellen möchte ich zwei Anmerkungen machen.
Ich sehe zwar memorial=war_memorial als problematisch an, und subject:category als etwas das eventuell bei der Lösung helfen kann.
Aber dieses weltweit zahlreich genutzte Tagging auf depreceted zu stellen ist eine ganz andere große Baustelle und sollte unabhängig von der Existenz von subject:category angegangen werden.
Es gibt genug andere gute Gründe subject:category einzusetzen und daher sollte eine Entscheidung ob das genutzt wird unabhängig davon sein ob ein anderes Tagging sich als deprecated herausstellt.
Der zweite Grund warum ich mich dagegen ausspreche etwas durch ein OSM-Proposal zu schicken ist meine persönliche Sichtweise auf das was OSM-Community ist. Ich bin OSM-Urgestein und auch OSM-Anarcho.
Ich spreche ganz einfach den wenigen Abstimmern bei einem Proposal das Recht ab, eine wie du es nennst “offizielle” Entscheidung zu treffen.
Jedes einzelne Mitglied der OSM Community kann jederzeit eine valide Meinung zu einem Thema, zu einem Tagging-Schema innerhalb von Treffen, Foren oder auch Proposals abgeben.
Aber ein Stimmrecht, das einem Einzelnen oder auch einer Menge von Communitymitgliedern bei einem Proposal, die Möglichkeit gibt, ein Taggingschema als"offiziell" zu erklären gibt es meiner Meinung nach nicht. Ergebnisse von Proposals werden überbewertet. Die Zahl der Abstimmenden ist immer verschwindend klein gegenüber der Anzahl der Nutzer die ein Tag anwenden und noch kleiner gegenüber der Anzahl der gesamten OSM-Community. Und diese Abstimmer dort sind in keiner Weise mit einem Mandat ausgestattet, das ihnen Recht und Möglichkeit gibt eine “offizielle” Entscheidung zu treffen.
Auch das OSM-Wiki gibt den Weg des Proposals nur als einen der möglichen Wege an ein neues Tagging einzuführen. Und das Proposal ist nicht der Weg, den ich gehen werde um ein neues Tagging in die OSM-Community zu tragen.
Ich habe nichts dagegen wenn ein neues Tagging wie hier subject:category innerhalb der Community kritisch betrachtet wird, auch kräftig durch die Mangel gedreht wird und dadurch Änderungen, Verbesserungen oder auch Ablehnung erfährt.
Ich stimme dir zu, das dieses neue Tagging auch international diskutiert werden sollte.