Messstation

@grossing
Hallo Florian, schön dass Du nun hier im Thread dabei bist!
Wenn Du dir die vorangegangenen Beiträge anschaust, so denke ich haben wir schon den überwiegenden Teil geklärt.
“Delta Foxtrot2”, oder “JohnSmith” wie er sich auch nannte, ist definitiv raus aus OSM, damit brauchen wir ihm und seinen Werken auch keine Träne mehr nachweinen.
Hatte man die Werke jener Leute welche OSM den Rücken gekehrt haben aus der Datenbank gebannt, so ist es im Wiki wohl genau so anzuraten.
In JOSM ist sowieso seit längerer Zeit deine Version der Messstationen vertreten, nur im Wiki gab’s eben etwas Diskrepanzen.
Wir sollten schleunigst dein Proposal zur Abstimmung bringen (gegebenenfalls mit Hinweis auf die Situation) und wer mag kann dort noch ein paar (Verbesserungs-) Vorschläge einbringen.

@Cobra
Die Frage nach “Messung” oder “Überwachung” dürfte ich doch wohl nun in #18 ausreichend erläutert haben. :wink:
Du kannst aber gerne deine Einwände in’s Proposal einfließen lassen.

Der Fehler hier ist schon früh passiert. Wenn man weiß, da wird parallel exakt das gleiche gemacht, sollte man sich schon da auf etwas einheitliches einigen, oder beides entwickeln und auf geeignetes abgrenzen. So hätte man beispielsweise das eine für reine Datenerfassung, das andere für besetzte Überwachung nehmen können. Einfach mal beides laufen lassen und irgendwann entscheiden was man nun nimmt, führt definitiv zu einem Problem und dem ungewollten Wildwuchs. Und das haben wir jetzt. Zwei Tags für das gleiche, widersprüchliche Informationen und 2000 oder aber 900 Objekte die gefunden und umgetaggt werden müssen.

Da measurement anscheinend noch gepflegt wird und wenigstens ein Proposal zu existieren scheint, sollte man da weiter machen.

Nur mal generell festgehalten, halte nichts davon, einfach die Arbeit der Leute, die aus irgendeinem Grund gegangen sind, einfach mal so kommentarlos zu tilgen oder ohne Hinweis darauf zu adoptieren. Wenn da kein Kappes getrieben wurde und es sich um sinnvolle Sachen handelt, haben die genauso ihre Existenzberechtigung. Derjenige könnte auch irgendwann wiederkommen, bin ich ja auch. Und ich hatte auch so einige Sachen einfach mal lose ins Wiki gestellt, ohne Link auf den Features etc., unter anderem z.B. das power=cable_distribution_cabinet, weil ich es erfasste, keiner weit und breit dran war, ich das aber irgendwie taggen und wenigstens dokumentieren wollte, ohne erst einmal ein Jahrelanges Proposal anzuschieben, nach dessen Ausgang alles schon wieder vergessen ist.

+1

Weil wie schon ganz früh/oben von mir geschrieben, muß man zum Monitoring ja überhaupt immer erst mal messen, sinnvoll wäre z.B. man_made=monitoring_station für reine Auswerte- und Kontrollzentren.´, dafür gibt es ja keinen geeigneten Tag bisher.

Wußte nicht, das power=cable_distribuion_cabinet von dir ist und habe gerade gesehen, das es auch schon vereinzelt für communication=* übernommen wurde. Das mit dem reinen mal eben kurz dokumentieren kann ich verstehen, irgendwann hat man bei offensichtlichen und simplen Tags keine Lust auf den langwirigen Proposalprozess.

Habe noch nicht geschaut, aber eignet sich grundsätzlich mit communication auch für KVZ für Telefon, DSLAM usw. Damals war das erst einmal nur für KVZ der Energieversorgung gedacht, da ich da ein wenig mit der Umsetzung von Ortsnetzen experimentiert habe. War noch einiges mehr wie Erdkabel, pipeline=marker, pipeline=valve, die ganzen Eisenbahntags die OpenRailMap als Grundlage übernommen hat usw. Alles Dinge die man so in der freien Wildbahn fand, wo es aber noch nichts gab, keiner dran war und die ich einfach mal genutzt und dokumentiert habe. Manches habe ich auch nicht dokumentiert und nur auf meiner Spielwiese probiert, so z.B. die Flächendarstellung von Straßen, da hat dann später jemand offiziell area:highway angeschoben. Oder historische Layer mit historic:jahr:key=value, unterirdisches wie Bergbausolen. Letztere beide habe ich aber beim Reimport raus gelassen, hab aber alles noch da.

Das hat sich einfach aus der Arbeit ergeben. Wenn du viel im Feld unterwegs bist und die Arbeit an den Daten im Vordergrund steht, ist so ein Proposal für ein popeliges Objekt schlichtweg eine riesige Arbeitsbremse. Für einfache Dinge muss das unkomplizierter gehen. Man hat etwas erfasst und will das dann direkt aus den frischen Erinnerungen umsetzen. Und so lange da nicht schon etwas parallel läuft oder das ganze komplex ist und irgendwo Diskussionsbedarf da ist, sehe ich dabei auch kein Problem, solange man es jedenfalls nicht gleich als offiziell in den Features verlinkt. Entweder wird es von anderen übernommen und wird quasi von selbst offiziell, oder jemand der nicht so sehr mit der Erfassung an sich eingebunden ist, arbeitet etwas entsprechendes aus und notfalls taggt man bereits vorhandenes um.

Klar, wenn man gerade schon mal am Erfassen ist, will man ja auch alles erfassen, was einem so über den Weg läuft. Soll heißen, ich erfasse inzwischen Kleinigkeiten wie power=cable_distribution_cabinet, Litfaßsäulen und ab und an auch mal einen Hydranten, wenn ich direkt davor stehe.

Ich habe gerade mal etwas gesucht wegen der (outdoor) DSLAM und der KVZ, die englische Fachbezeichnung SAI gibts auch schon als Proposal (https://wiki.openstreetmap.org/wiki/Proposed_features/Serving_area_interface), wobei man die noch genauer unterscheiden (die umfaßt alles vom DSLAM bis zum reinen KVZ) und das dann vielleicht gleich neu unter communication=* einsortieren sollte. Dann gibt es noch communication=cable_distribution_cabinet, was KVZ meint, im englischen aber eigentlich SAI sein müßte. Da beginnt also gerade mal wieder, neuer Taggingwildwuchs zu entstehen. Telefon-Vermittlungsstellen (Proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/Telephone_Exchange)) sind auch schon da, wobei aber die Outdoor-DSLAMs imho wichtiger sind, weil die werden ja dank VDSL schon erfaßt und sind ja auch nicht zu überhören.

Zwar entspricht das mappen der Fahrbahn als area:highway=* der Realität, aber ob das in hinblick auf Spurmapping so sinnvoll ist, bezeifele ich, da man dann in logischer Konsequenz, ja die Spurmarkiereungen als Linien auf der Fläche mappen muß. Außerdem führt das Ermitteln der logischen Begrenzungen der Spuren imho zu erhöhten Rechenaufwand. Dann setz ich doch lieber gleich die Fahrbahn aus Teilflächen zusammen, was mein Ansatz ist, auch wenn der in GLM Ver. 2 bei den Flächen leider noch kaputt ist, aber ich hab den Fehler inzwischen erkannt und auch schon eine Lösungsidee (man braucht eine Gruppierung der Übergänge, sonst sind die “Fahrspuren” auf den Flächen nicht mehr eindeutig).

Sehe ich auch so, zumal auf der “Good Practice”-Seite imho auch das einfach gleich mal dokumentieren von neuen Tags empfohlen wird.

Ein Vorschlag, wie sich die obige measurement/monitoring-Diskussion möglicherweise zu einem konstruktiven Ende führen läßt: Die Befürworter beider Tag-Varianten sowie jene, die eine Unterscheidung für nötig halten, mögen 1) jeweils mindestens ein Beispiel eines OSM-fähigen [a] Objekts nennen, das ihrer Meinung nach nur durch den jeweils favorisierten Begriff beschrieben werden kann, während der andere Begriff keinesfalls zutrifft; 2) wenn möglich, dazu ein sachlich verwandtes [aa] Objekt, auf welches nur der andere Begriff paßt. Bisher fehlen solche konkreten Beispiele in dieser Diskussion.

Sollten sich keine Beispiele finden lassen, können wir beide Begriffe innerhalb OSM als synonym ansehen (unabhängig davon, daß in den einschlägigen technischen Disziplinen die Unterscheidung gerechtfertigt oder gar zwingend sein mag). Ansonsten können beide Tags klarer voneinander abgegrenzt und beide für verschiedene Objekte verwendet werden.

[a] d.h. lokal, ortsfest, halbwegs dauerhaft und vor Ort erfaßbar; idealerweise solche, die auch schon nach mindestens einem der Schemata eingetragen wurden
[aa] Beispiele, die ausdrücklich nichts mit measurement/monitoring zu tun haben, zur Illustration, was ich mit “sachlich verwandt” meine: Bank vs. Geldautomat; Postfiliale vs. Briefkasten; Mobilfunkantenne vs. Fernsehturm; Staudamm vs. Stausee. “sachlich verwandt” darf also großzügig ausgelegt werden.

Naja, das sachliche Ende ist aus meiner Sicht, das auch bei einer man_made=monitoring_station immer erst mal irgendwo gemessen werden muß, somit ist das zu erfassende Objekt bis auf einige Ausnahmen von reinen Kontrollzentren, zumindest immer eine Messeinrichtung. Ob man beide Schlüssel erlaubt und wie man dann dort die Konflikte mit dem bisherigen Tagging lösen will, ist aus meiner Sicht eine ganz andere Frage.

Wenn man es gut verständlich für alle mit Beispielen abgrenzen kann, wäre ich dafür beide tags den Wesen nach zu erhalten. Weil in der Praxis gibt es ja auch Fernsehtürme auf denen auch Mobilfunkantennen (BTSen) stehen, wenn das also immer so eindeutig wäre… …naja, es gibt ja zum Glück Relationen!

Oder: der nächste Schritt, wäre dann zu diskutueren, was alles noch zu “messen” gehört… :wink: Aus meiner Sicht gehört da die erstmalige Anzeige/Ausgabe des Messwerts (ggf. im Kontrollzentrum) auch noch mit dazu.

Hallo,

welche der Möglichkeiten sich durchsetzt ist mir eigentlich egal.

Gefühlt würde ich zu monitoring_station tendieren, da dies für mich eher eine automatische Aufzeichnung von Messwerten umfasst, während measurement_station eher auf manuelle Messungen hindeutet. Letztlich müsste sich ein Experten-Muttersprachler dazu äußern.

Bei Google gibt es zu “monitoring station” mehr Bilder, die sowohl die Messräume als auch Klimamessstationen etc umfassen.

Grüße,
Daniel

Wenn an einer measurement_station auch Monitoring durchgeführt wird, könnte man das ganz einfach mit monitoring=yes/mögliche_Werte taggen.

Meine Rede. Lieber male ich 100 km mäandernden Fluss als im Wiki herumzudoktoren. (Schön, dass measurement/monitoring jetzt aufgeräumt wird, ohne dass ich mich dazu aufraffen muss :P)