OK, aber ich will ja die Kombination mit water_source=pond ja sehen… und da wird mir nix angezeigt. Das bringt mir so nix.
water_source=pond
gibt es insgesamt nur 1.455 in der gesamten Datenbank. Soweit ich weiß, werden manche Funktionen in taginfo, wie wohl auch die Kombinationen, nur für häufig verwendete Tags generiert. Mit dem häufigeren Wert main
funktioniert es: water_source=main | Tags | OpenStreetMap Taginfo
Teils teils… Es gibt bei taginfo… auch Seiten da wird alles generiert… obwohl keine hundert Objekte davon gibt… bzw. je gab
Zumindest empfindet Taginfo nur drei der water_source
-Values als “häufig”:
Du kannst alternativ versuchen die Daten per OverpassTurbo zu bekommen.
Link: overpass turbo
Nach dem Ausführen in dem gewünschten Berech rechts oben auf “Daten” klicken und dann die Werte in “tags” betrachten.
Auf die schnelle würde ich sagen, dass emergency=fire_hydrant
auf Platz 1 als Kombination kommt. Auch sehr häufig ist emergency=fire_water_pond
. Danach kommt emergency=suction_point
und emergency=water_tank
.
Nö…
Diese Ansicht:
https://taginfo.openstreetmap.org/tags/water_source=main#combinations
Nur für water_source=pond
Mein Skript das ich mir gebastelt hab… und nicht so optimal ist… Macht genau das… Holt von Oberpass für die ganz Welt… Und zählt die Dinge zusammen.
Aber ich sehe schon es gibt keine Alternative… muss ich das Skript aufpolieren. Das ich ursprünglich für was anderes geschrieben habe.
Gruß Miche
Das Problem in Taginfo ist einfach die notwendige Rechenzeit für diese ganzen Statistiken. Das funktioniert anscheinend noch ganz gut für die 100k Keys und die relativ wenigen Tags die häufig auftauchen. Für alle 150 Millionen unterschiedliche Tags diese Tabellen zu generieren dürfte jedes System sprengen.
Hier ist eine Overpass-Abfrage, die direkt Statistiken ausspuckt: overpass turbo
Allerdings sieht man schon, dass diese Abfragen sehr viel Zeit brauchen und für Tags die häufiger als wenige tausend Mal vorkommen nicht zu gebrauchen sind.
wow… super
ich hab es noch a bisserl angepasst
https://overpass-turbo.eu/s/1C93
bzw.
https://overpass-turbo.eu/s/1C92
dann kann ich auf der console das schnell mit cat * | grep “^1” | sort | sed -e … usw. sortieren
Gruß Miche
Meinem Verständnis nach bezieht sich “Kombination” auf das gleichzeitige Auftreten von Tags an Objekten:
z.B. kommt addr:housenumber häufig mit folgenden Tags zusammen vor:
https://taginfo.openstreetmap.org/keys/addr:housenumber#combinations
water_source=pond ist eine Kombination von tag und value, die entsprechend auch angezeigt wird.
Es ist klar, dass von dem Key water_source
insgesamt 1.455 Objekte den Value pond
haben.
Es geht Miche nicht darum wie häufig die Kombination des Keys water_source
mit dem Value pond
ist, sondern wie häufig der Tag water_source=pond
gleichzeitig mit (beispielsweise) dem Tag emergency=fire_hydrant
vorkommt. (In der Kombination etwa 995 Objekte).
In einem anderen Beispiel verhält es sich mit der Kombination aus dem Tag amenity=parking
und informal=yes
: Diese Kombination gibt es laut taginfo 2.195 Mal: amenity=parking | Tags | OpenStreetMap Taginfo (Seite 6).
Irgendwie bin ich darüber erstaunt, dass obwohl @miche101 in seinem Eingangspost sehr deutlich (und für mich unmissverständlich) geschrieben hat, was er möchte und um was es ihm geht, dass es hier dann in den ganzen Kommentaren nur 2 Leute gibt, die ihn dann auch wirklich verstanden haben
Ja manchmal denk ich mir…ob ich so komisch schreibe bzw. unverständlich schreibe… das dass keiner Versteht. Aber gut wenn es noch Leute gibt die das verstehen was ich schreibe.
Ja an was bastele ich… ich spiele mich mit php + mysql … an einer “Feuerwehr-Map” … daher versuch ich das tagging möglichst kompakt und nur relevantes in die Datenbank rein zu bekommen. Darum auch das interesse daran was mit was getaggt ist und wie oft. Mal schauen wie gut das ganz funktioniert
Sorry, dass ich nicht sorgfältig genug gelesen habe.
Ich hatte ein python Skript auf Lager, das aus einer OVP Querry z.B. water_source=pond alle an den
Elementen vorhandene Tags auswertet.
Hier das Ergebnis für Deutschland:
{‘addr:city’: 1, ‘addr:housenumber’: 1, ‘addr:postcode’: 1, ‘addr:street’: 1, ‘bonnet:colour’: 2, ‘building’: 1, ‘check_date’: 1, ‘colour’: 12, ‘content’: 3, ‘couplings’: 80, ‘couplings:diameters’: 64, ‘couplings:type’: 59, ‘description’: 197, ‘description:de’: 1, ‘drinking_water’: 11, ‘emergency’: 944, ‘fire_hydrant:awwa_class’: 4, ‘fire_hydrant:count’: 8, ‘fire_hydrant:coupling_type’: 13, ‘fire_hydrant:couplings’: 13, ‘fire_hydrant:diameter’: 86, ‘fire_hydrant:diameter:signed’: 2, ‘fire_hydrant:location’: 21, ‘fire_hydrant:position’: 362, ‘fire_hydrant:pressure’: 381, ‘fire_hydrant:style’: 1, ‘fire_hydrant:type’: 483, ‘fixme’: 12, ‘flow_rate’: 11, ‘height’: 1, ‘inscription’: 1, ‘intermittent’: 1, ‘man_made’: 6, ‘name’: 95, ‘natural’: 13, ‘note’: 21, ‘operator’: 88, ‘pillar:type’: 39, ‘ref’: 57, ‘source’: 14, ‘survey:date’: 129, ‘survey_date’: 1, ‘verified’: 2, ‘water’: 12, ‘water_source’: 946, ‘water_tank:volume’: 33, ‘water_volume’: 21}
Die Details pro ::id gibt es als CSV Datei.
Wo hast du die Daten her? Auch von Overpass? Python bin ich nicht so gut… mein bash Skript holt von Overpass… Und gibt dann zwei HTML Daten aus… Ein key und einmal Key=value
Ich kann für die Overpass API
diese Abfrage anbieten:
[out:csv(cnt,key,val)];
nwr[water_source=pond];
for ->.per_key(keys())
{
( make info cnt=per_key.count(nwr),key=per_key.val,val="*";
.result;)->.result;
for .per_key(t[per_key.val])
{
( make info cnt=count(nwr),key=per_key.val,val=_.val;
.result;)->.result;
}
}
for .result(1000000 - t["cnt"])
{
out;
}
Zeile 2 selektiert die Objekte, die betrachtet werden sollen. In der
geschachtelten Schleife werden dann die Keys und Tags ausgezählt. Die
Schleife am Ende ist ein Hack, um zu erzwingen, dass absteigend geordnet
ausgegeben wird.
Hallo,
ich bin noch aktiv dran da auszuwerten und was in eine Datenbank einzuspielen … damit ich da eine Karte daraus schnitzen kann:
Test-Seite…
https://greymiche.lima-city.de/osm_page/index.html?lat=48.1962&lon=11.80605&zoom=18&layers=D&emergency=db
Hab jetzt alle Key=* genommen was an ca. >5% der Objekte (in Bayern) dran ist… unwichtige hab ich noch herausgefiltert… z.B.: (roof:shape, survey:date, FIXME usw.)
Das ist jetzt so meine Liste… kann man bestimmt noch verbessern
listen/Aufzug
level
indoor
door:width
width
length
ref
maxweight
description
operator
access
levelpart
entrance
bicycle
listen/Ausgang
access
door
barrier
level
listen/BMA
facp:initiating
facp:call
facp:operator
facp:name
listen/Defibrillator
indoor
defibrillator:location
opening_hours
access
operator
level
name
defibrillator:location:de
listen/Eingang Notaufnahme
name
level
opening_hours
operator
access
description
addr:street
addr:housenumber
website
barrier
addr:postcode
addr:city
listen/Eingang
access
level
name
step_count
door
listen/Erste Hilfe Kit
indoor
description
operator
opening_hours
name
listen/Feuerlöscher
level
operator
indoor
layer
listen/Feuerwehrhaus
name
addr:housenumber
addr:postcode
addr:street
addr:city
website
addr:suburb
operator
listen/Feuerwehrschlauch
name
listen/Haupteingang
access
door
level
name
listen/Hubschrauber Ladeplatz
name
surface
ref
operator
lit
listen/Krankenhaus
name
healthcare
addr:street
addr:housenumber
addr:city
addr:postcode
website
phone
emergency
operator
email
healthcare:speciality
fax
contact:website
contact:phone
wikipedia
listen/Landestelle Hubschrauber
surface
name
aeroway
description
operator
listen/Löschwassereinspeisung
couplings
description:emergency
name:de
description
couplings:type
listen/Nebeneingang
access
door
level
ref
listen/Notausgang
level
access
door
description
name
listen/Notruf-Telefon
operator
level
ref
listen/Oberflurhydrant
fire_hydrant:position
fire_hydrant:diameter
pillar:type
couplings
ref
couplings:diameters
colour
operator
couplings:type
fire_hydrant:pressure
name
fire_hydrant:couplings
description
fire_hydrant:coupling_type
listen/Rettungspunkt
ref
emergency_telephone_code
operator
description
website
sign
name
description:de
reflecting
listen/Rettungsring
listen/Rettungswache
name
addr:street
addr:housenumber
operator
addr:postcode
addr:city
building
brand
addr:country
website
phone
listen/Sammelplatz
name
ref
landuse
listen/Saugstelle
fire_hydrant:type
water_source
fire_hydrant:position
couplings
couplings:diameters
description
couplings:type
operator
name
ref
fire_hydrant:diameter
water_tank:volume
pillar:type
water_volume
colour
listen/Sirene
siren:type
siren:purpose
siren:model
operator
location
support
listen/Technisches Hilfswerk
name
operator
emergency_service
addr:postcode
addr:city
addr:street
addr:housenumber
contact:website
contact:email
thw:lv
contact:phone
ref:thw
contact:fax
thw:rb
addr:country
old_name
listen/Unbekanntes Objekt
ref
operator
name
description
addr:street
addr:housenumber
addr:city
addr:postcode
website
phone
emergency
email
fax
wikipedia
listen/Unterflurhydrant
fire_hydrant:diameter
fire_hydrant:position
ref
operator
name
fire_hydrant:pressure
description
couplings
flow_rate
listen/Wasserbecken
natural
water
description
name
ref
water_tank:volume
fire_hydrant:pressure
fire_hydrant:type
fire_hydrant:position
listen/Wassertank
water_tank:volume
name
description
ref
operator
drinking_water
listen/Wasserwacht
name
operator
addr:street
addr:postcode
addr:housenumber
addr:city
website
phone
opening_hours
emergency_telephone_code
seamark:type
description
contact:website
listen/Zusatzeingang
access
door
level
Hab mir die Daten Landkreis weise von Overpass geholt und in die DB-Importiert und dabei gefiltert.
Es sind jetzt Landkreis Ebersberg, Erding, Freising, Mühldorf, München, Rosenheim + Stadt Rosenheim und München drin… 64277 Objekte haben den Weg in die Datenbank gefunden Ein Dump der DB ergibt eine Größe von 5,4MB nicht komprimiert sql-Datei.
Die Karte stellt 3 Bereiche da… einmal Dinge die im näheren Bereich interessant sind… z.B. Eingänge. Einen Mittleren Bereich z.B. Hydranten… und einen weiten Bereich mit Feuerwehrhäuser, Krankenhäuser usw. Vielleicht mach in noch einen kleineren für Feuerwehren… weil so viele braucht man nicht
Ich finde es schon ganz cool aber verbessern kann man immer noch…
Gruß Miche