Erfassen / Einzeichnen von Hydranten?!

Ich hätte noch 2 Verbesserungsvorschläge:

  1. Sollen wir als optionalen Tag noch “count” für die Aznahl aufnehmen? In meinem Zuständigkeitsbereich sind die Hydranten häufig auf Straßenkreuzungen und da gibt es schon mal 2 oder 3 Hydranten auf einer Kreuzung. Ach bei Trockenen Hydranten an zB. Seen gibt es schonmal mehrere nebeneinander.

  2. Beim Hydranttyp würde ich vielleicht “pond” in “dry” ändern. Ist vielleicht verständlicher da solche Hydranten auch an Flüssen zu finden sind.

Gruß
Schlumpf

Also der amenity=fire_hydrant wurde am 15.01.2008 eingepflegt.
Es wird also schon 2,5 Jahre gelebt und ist in diversen Tools übernommen worden.

Die 3000 Einträge kannst du, wenn du dich an die Vorgaben vom Proposed features halten würdest nicht ändern sondern nur löschen. Ausser jemand begutachtet die POIs und trägt dann ein um was für Hydranten es sich handelt. Ein einfaches Vorhandensein eines Hydranten unabhängig von der Art des Hydranten ist mit dem Proposed features nicht möglich!

Was spricht dagegen das amenity=fire_hydrant zu lassen und einfach weitere Eigenschaften mit dem Proposed features einzutragen?

Warum findest du das “amenity” unsinnig?

Gruß
badger

1.) Mach euch mal unabhängig von den 3000 Einträgen… das sind noch wenige. Wenn ich dürfte wären da morgen 3200 mehr die anders getaggt wären.

2.) Weil amenity wie folgt beschrieben wird: "This is the primary tag for useful and important facilities for visitors and residents: toilets, telephones, banks, pharmacies (to buy medicines), schools … "

es gibt da einige das besser passt z.b. man_made oder evtl sogar service

  1. Gibt es meines erachtens hinreichende Gründe das Schema zu erweitern und zu Überarbeiten.
    Heute taggt ja (hoffentlich) keiner mehr Bus routen nach diesem schema: http://wiki.openstreetmap.org/wiki/Bus_stop (location / towards) …

Warum nicht dann mal ein paar alte Zöpfe abschneiden. Coexistenz ist ja auch möglich… irgendwas wird sich schon durchsetzen…

Also ich finde useful and important facilities passt schon ganz gut ob man Feuerwehrleute jetzt als Anwohner oder besser Besucher bezeichnet sei mal dahingestellt.
Wobei es für die Anwohner schon wichtig ist dass die Feuerwehr den Hydranten findet.

Warum man_mad “A tag for identifying man made (artificial) structures and buildings added to the landscape.” besser geeignet sein soll kann ich nicht verstehen. Als eine art Bauwerk würde ich ihn nicht bezeichnen.

Service wird wohl hauptsächlich für Strassen oder Schienen benutzt.

Und damit wir uns nicht falsch verstehen ich finde es gut was ihr vorhabt.
Blos würde ich zusätzlich noch amenity zulassen.

z.B.
amenity=fire_hydrant
fire_hydrant=underground

nabend,

ich habe eure diskussion über die hydranten mit sinkendem interesse verfolgt.

vor einigen tagen war meine meinung noch “ach, da werden also doch hydranten erfasst - also klopft du dein dutzend auch mal rein” :slight_smile:

dann wurde es auf einmal total technisch - anzahl, durchmesser der anschlüsse, druck, wassermenge, seriennummer des herstellers, farbe, unterboden, legierung des deckels und was es sonst noch so geben könnte.

resultat meinerseits: ich {h,l}ass es! wenn ich noch so’n rotes ding in der gegend finde, kommt es als amenity=fire_hydrant rein, damit alle hundebesitzer wissen, wohin sie mit ihrem waldi gehen sollen.
und die in den straßen versteckten sowieso nicht, da ich die nicht metergenau platzieren kann.

gruss

wambacher

p.s. zu “versöhnung” :

Liebe Feuerwehrmänner und -Frauen,

OSM ist ideal geeignet für Hydrantenpläne!

  • das Datenschema bildet die erforderlichen Eigenschaften gut ab
  • Hydranten können metergenau plaziert werden (relativ zur Strasse)
  • tausende OSMer helfen beim Erfassen
  • mit Radius=Schlauchlänge kann man den Einzugsbereich anzeigen
  • etc. etc.

Sinnvoll fände ich, wenn in jeder Wehr ein Hydrantenbeauftragter sich um die Datenkontrolle kümmert.

Und natürlich braucht Ihr eine Spezialkarte OpenFirefighterMap.org

Mit herzlichem Gruss,
Markus

PS: macht Euch keinen Kopf wegen den paar “amenity=”
hängt den alten Objekten einfach die neuen Attribute dran,
und macht alle neuen Objekte gleich ohne das veraltete “amenity”.
Und verlinkt im Wiki das alte “amenity” mit dem neuen “firehydrant”.

Ich denke auch das es wie Islanit schon schrieb, nicht das riesen Problem wäre die vorhandenen umzukennzeichnen. Zur Not könnte man mal jemanden bitten einen Bot loszuschicken. :slight_smile:
Nur so langsam sollte man mal zur Einigung kommen, was den Schlüssel angeht. Wenn amenity abgelehnt wird, dann halt etwas passenderes.
Nur lasst uns zu Potte kommen, sonst interessiert es irgendwann auch den hartgesottensten Feuerwehrmann nicht mehr.
Georg

Ich verstehe das Problem nicht.
Es gibt/gab ursprünglich amenity=fire_hydrant, und das wird auch schon ordentlich genutzt.

Und zur Verfeinerung hat man nun den fire_hydrant=pillar/wall/pond etc.
der zusätzlich gesetzt werden kann.

Grüße
Chris

Na wo die Residenten ihr Löschwasser herkriegen, wenn ihre Residenz abfackelt, ist doch primär wichtig!
→ Passt scho!

Bei der Liste, was alles amenity (“Annehmlichkeit”, “Anmut”, “Schönheit”, “Vorzüge” laut leo.org) ist, fragt man sich eh oft genug, ob da alles angenehm ist … amenity=prison?! :wink:
Ist halt ein Sammelbegriff für eine erste grobe Einordnung “hier ist IRGENDEIN Hydrant”, der mit weiteren Tags spezifiziert werden kann.
So wie bei
highway=track
highway=track + tracktype=grade3
Erspart quasi das sonst nötige fire_hydrant=yes o.ä. für unspezifizierte Einträge.

OK, lassen wir mal das gerangel mit dem “amenity”. Wie mitleiweile schon öfters vorgeschalgen bin ich nun auch dafür die alten “amenity”-tag für allgemeine Hydranten stehen zu lassen und die neuen nach dem neuen Schema zu taggen.

Bleibt noch meine Frage ob wir “pond” in “dry” ändern sollen, da sie ja auch wirklich trockene Hydranten genannt werden und es sie auch an Flüssen gibt.

Guckt euch mal bitte die Seite http://wiki.openstreetmap.org/wiki/Proposed_features/Fire_Hydrant an, wenn das so nun OK ist, werde ich die Hydranten in Proposal-Status heben und wir kommen endlich mal vorran.

So, ich werde heute meinen ersten Hydranten eintragen, und es ist so ein U-Boot Rohr, also pond.
Da es in dem Proposal so schon lange drin steht würde ich es so lassen.

Chris

Soo, es ist soweit :slight_smile:

Status: Proposed

mal gucken was nun passiert, nach der “Proposal status process”-Seite habe ich das Proposal an die tagging-Mailingliste geschickt und nun sind 2 Wochen Zeit Kommentare dazu loszuwerden und das Proposal anzupassen/verbessern. Dann wird der Vote freigeschaltet.

Die erste Antwort von der Mailinglist kam schon 4 Minunten nach dem Abschicken:

Gruß
Schlumpf

ich weiss, ich sollte im proposal antworten - mach ich eventuell später :wink:

man kann auch wasser an hydranten bekommen, wenn es NICHT brennt. da kann man sich ein rohr mit ner wasseruhr besorgen und dann z.b. den swimming-pool füllen.

gruss

wambacher

Ich versteh das Argument ‘es gibt schon so viele andere Amenities’ sowieso nicht. Warum sollte man die Anzahl Tags zu einem Key beschränken? ‘Hydrant’ ist so anders wie alle anderen Tags, dass er nun wirklich niemandem in die Quere kommt…

Mir erschließt sich aus dem proposal nicht so ganz, ob “fire_hydrant=underground/pillar/wall/pond” als Ergänzung/Verfeinerung zu “amenity=fire_hydrant” gedacht ist, oder ob dies als vollkommen selbständiges tag laufen soll und “amenity=fire_hydrant” sozusagen zum Auslaufmodell wird.

Und was ist hier mit “common” gemeint?
Irgendwie macht dies den Eindruck, dass in Zukunft doppelgleisig gefahren werden soll, sprich 2 Tags für die gleiche Sache ?!
Könnte mich bitte mal jemand aufklären. Danke.

moin,

aus dem Bauch heraus ist der “common” ein Überflurhydrant.

Habt ihr schon 'mal überlegt, wieviele schon hätten gemapt werden können, in der Zeit, die dieser Thread hier gekostet hat?

VG
Jörk

Ist vielleicht ein bisschen schlecht formuliert. Das alte Tag soll ein “Auslaufmodell” sein. Wie kann man das besser schreiben? Ich dachte der 2. Satz macht das klar: “New fire hydrants should be tagged in this more precise scheme.”

Vielen Dank für die Klarstellung, muss aber im gleichen Atemzug sagen, dass ich dann gegen dieses proposal in dieser Form bin. Wieso soll ein vollkommen neuer Schlüssel eingeführt werden, wenn bereits ein Schlüssel für den Feuerhydranten verwendet wird? Der Schlüssel “amenity=fire_hydrant” wird in Europa bereits über 3300x verwendet. Sicherlich könnte man entgegnen, dass “fire_hydrant=…” auch ca. 592x in Europa verwendet wird (in den beiden Listen jeweils nach “fire_hydrant” suchen):

Wäre es da nicht sinnvoller diese beiden tags zusammenzuführen, um noch mehr tag-Verwirrung aus dem Wege zu gehen? Man könnte z.B. so verfahren wie es bereits beim Turm gemacht wird. Erst mal wird generell ein Hydrant eingetragen, da weiß man schon mal, dass sich dort einer befindet. Eine nähere Spezifizierung ist dann mit weiteren Unterschlüsseln möglich (Typ, etc.). Außerdem ist sicherlich nicht jeder OSM’er ein Feuerwehrfreak und wird immer gleich den richtigen Hydrantentyp eintragen (wollen). Auf der anderen Seite hätte man mit “amenity=fire_hydrant” überhaupt erst mal den Standort eines Hydrants, welcher dann im Nachhinein immernoch nach Lust und Laune näher beschrieben werden könnte.
Ein weiteres Problem könnte die botmäßige Überführung von “amenity=fire_hydrant” nach “fire_hydrant=?” werden, da niemand wissen kann, welcher Hydrantentyp mit dem alleinigen tag “amenity=fire_hydrant” gemeint ist. Ohne dort nochmal hinzufahren wird das “Überführen” also nix.
Und da sich einige an dem “amenity”-tag zu stören scheinen, ist natürlich auch eine Überführung in “man_made=fire_hydrant” denkbar. Dies ist wiederum auch bot-mäßig kein Problem. Meiner Meinung nach sollte man in einem proposal versuchen möglichst alle bereits gängigen Schlüsselvarianten zu vereinigen, da dies die Chance ein proposal tatsächlich durchzubekommen mächtig erhöht.
Aus welchen Gründen soll eigentlich “amenity=fire_hydrant” abgeschafft werden (mir ist klar, dass es auch hierzu noch kein erfolgreiches proposal gab)?

Ums nochmal kurz zusammenzufassen, ich würde folgenden proposal-Formen meine Zustimmung geben:

Nichts desto trotz, ziehe ich meinen Hut vor Benutzer Schlumpf, der hier endlich mal versucht ein proposal durchzudrücken, welches schon einige Jahre in der Schwebe hängt.

bin auch dafür

+1

+1

(Variante: amenity=fire_hydrant)