Ich habe diese Saugrohre an Teichen oder Löschwasserbehälter immer als fire_hydrant:type=pond; fire_hydrant:pressure=suction - ist auch so in der JOSM-Vorlage Hydrant - gemappt. Auch http://www.osmhydrant.org/de/# verwendet das so.
→ emergency=suction_point can be intended as a place where to park the fire engine to easily take water with your pump from a river, pond, lake… But a separate refinement proposal will be needed for it.
und warum sollen Saugstellen, bei denen Wasser aus dem Grundwasser entnommen wird, bei den Hydranten verbastelt und verwurstet werden wo man doch auch hier eine Pumpe benötigt?
JOSM: stimmt schon, aber nur weil es der Patch1 noch nicht ins Release geschafft hat.
OSMHydrant: Nein, dort ist’s auch
fire_hydrant:type pipe
water_source pond
Da habe ich missverständlich ausgedrückt em=suction_point ist quasi der Parkplatz für eine Feuerlöschpumpe direkt an einem Gewässer. Da kann dann die Feuerwehr entweder ihre Saugleitung ins Wasser werfen. Oder es gibt dort auch ein Saugrohr, was mit dem Gewässer verbunden ist. Dort kann dann die Feuerwehr ihre Pumpe anschließen und Wasser direkt aus dem Gewässer fördern.
Das wäre auch
wir hatten ja schon eine Diskussion über Wasserentnahmestellen. Hier ( https://forum.openstreetmap.org/viewtopic.php?pid=658936#p658936 ) hatte ich versucht die unterschiedlichen Wasserentnahmestellen zu erläutern.
Im Moment wird leider beim Tag emergency=suction_point auf der emergency map gar kein Symbol angezeigt. Das ist schade. Damit fallen eine große Anzahl Wasserentnahmestelle aus der Ansicht heraus. Anscheinend läuft die Auswertung für das Saugstellensymbol nur über: fire_hydrant:pressure=suction.
Wäre schön wenn man emergency=suction_point auch mit auswerten und anzeigen könnte.
hier die aktuelle SQL-Query im GeoServer (*) für die Hydranten:
select 'emergency=fire_hydrant or emergency=suction_point'::text "query",
'n' || osm_id as osm_id,
wno_AsOsmLink('n',osm_id::bigint) osm_link,
tags->'fire_hydrant:type' as "type",
case tags->'fire_hydrant:type'
when 'underground' then 'svg/emergency_fire_standpipe.svg'::text
when 'pillar' then 'svg/emergency_fire_hydrant.svg'::text
when 'wall' then 'svg/question-mark-hi.svg'::text
when 'pipe' then 'svg/suction_point.svg'::text
when 'pond' then 'svg/question-mark-hi.svg'::text
when 'dry_barrel' then 'svg/emergency_fire_hydrant.svg'::text
else 'svg/question-mark-hi.svg'::text
end as icon,
regexp_replace(tags->'fire_hydrant:diameter','[^0-9]','','g') diameter,
wno_GetTagsAsJson(tags) tags,
coalesce(tags->'fire_hydrant:type','unknown') as "title",
way
from planet_osm_point
where tags->'emergency'='fire_hydrant'
--union
--select 'emergency=fire_hydrant or emergency=suction_point'::text "query",
-- 'n' || osm_id as osm_id,
-- wno_AsOsmLink('n',osm_id::bigint) osm_link,
-- coalesce(tags->'fire_hydrant:type','') as "type",
-- 'svg/suction_point.svg'::text as icon,
-- regexp_replace(tags->'fire_hydrant:diameter','[^0-9]','','g') diameter,
-- wno_GetTagsAsJson(tags) tags,
-- coalesce(tags->'fire_hydrant:type','unknown') as "title",
-- way
-- from planet_osm_point
-- where tags->'emergency'='suction_point'
wobei ich den unteren auskommentieren Teil gleich wieder aktivieren werde. Den hatte ich von ein paar Tagen deaktiviert. Ich könnte diesen “dubiosen, veralteten?” Suction Points auch ein eigenes Icon verpassen, dann würde man die leichter erkennen.
Wenn jemand Denkfehler findet, mag er mir bitte Bescheid geben, ich hab derzeit den Kopf dafür nicht frei. Für eine vorgeschlagene SQL-Änderung reicht es aber schon
ach ja: “Union” bedeutet in SQL “und”. Es werden also die Ergebnisse beider Teilabfragen zusammengefasst.
(*) eine tolle Software, die mir das OSM-Leben wirklich einfacher macht.
Das Problem ist, dass es langsam zu viele Layer werden, und dass der Layerswitcher dafür nicht geeignet ist. Bin dabei, den durch leaflet-layer-tree-plugin zu ersetzen, aber manches funzt noch nicht.
Ich sehe keinen wirklichen Sinn “service=emergency_access”
Ich plädiere eher für einen Tag aus dem emergency-Namensraum, z.B. emergency=access_way (oder so).
Begründung: Nicht nur highway=service können zugleich ausgeschilderte Feuerwehr/ Rettungsfahrzeugzufahrten sein, sondern auch z.B. highway=residential, highway=living_street
In meinen Augen ist es einfacher (und logischer), hier emergency=access_way zu verwenden, da man so unabhägig von den Hauptstraßentypen ist. (auch auswertetechnisch)