Für die Telekommunikation-Verteiler z.B. hier beanstandet OSMI “no_feature_tag_nodes”. Auf Basis der Fehlerbechreibung vermute ich, dass die Änderung von man_made=MDF zu telecom=exchange die eigentliche Ursache ist; “name” ist vorhanden, “man_made” nicht mehr.
Das Problem kommt recht häufig vor. Was tun:
Du hast dir die Antwort selbst gegeben durch deinen 3. Link :
“Dieses Feature wurde als veraltet markiert. Der empfohlene Ersatz ist: telecom=exchange .”
Der “Fehler” liegt somit bei OSMI.
PS:
Der name=Deutsche Telekom AG ist dort wohl nicht korrekt.
Danke @Map-Peter ,
aber einen OSMI-Fehler sehe ich nicht! Deren Fehlerbeschreibung sagt:
... Der Fehler bezeichnet OSM-Objekte ohne richtigen
Tag aber mit einen Namen, einer Beschreibung und/oder einer Website.
OSMI unterscheidet zwischen Nicht-Feature-Schlüsseln und Feature-Schlüsseln.
Ein Schlüssel gilt als Nicht-Feature-Schlüssel,
wenn er mit einer der folgenden Zeichenketten beginnt:
* name
* description
* comment
* website
* contact:website
Die folgenden Schlüssel werden als Feature-Schlüssel betrachtet,
d. h. sie beschreiben, was das Objekt darstellt
(für telecom=exchange sind relevant):
building, .., man_made
Ich denke auch, dass der name-Tag falsch ist und würde die Objekte gemäß Wiki wie hier beschrieben ändern …
Hat jemand Einsprüche?
Sehe ich genauso. Auf einschlägigen Straßenbildern sieht das allerdings nicht wie ein Gebäude aus, deswegen wohl eindeutig man_made=street_cabinet und dann sollte man auch gleich mal die addr:-Tags entweder entfernen, oder durch object:-Tags ersetzen. Aber auf jeden Fall vor Ort prüfen.
Der blanke node verursacht halt Fehler, dem ist aber doch recht simpel mit den geänderten Vorgaben abzuhelfen. Zwischenzeitlich wurde der beispielhafte node ja angepaßt und ist nun nicht mehr im OSMI als Fehler. In Fürstenfeld gibt’s aber noch eine 2. solche Anlage mit entsprechender Fehlermeldung, die ist noch ohne “Beiwerk”.
Im angeführten Beispiel geht es mMn um dieses Gebäude, welches noch zu erfassen wäre. Etwas anderes kann ich nicht erkennen (auch kein street_cabinet - ist mir zudem in diesem Zusammenhang noch nie begegnet), was hier für eine Vermittlung geeignet wäre. Der o.g. node ist also mindestens an der falschen Stelle. Es bietet sich an, das Gebäude als Einrichtung zu erfassen (Beispiel). Wenn man aber nur einen node erfaßt, weil die Anlage innerhalb eines größeren Gebäudes (Beispiel) ist (oder man selbst es so möchte), sollte man einfach ein location=indoor (halte ich für besser als indoor=yes, das zähle ich eher zu 3D-Mapping) dazu packen. Bisher habe ich in keiner QA (auch OSMI) irgendeine (neue) Fehlermeldung zu den von mir bearbeiteten Einrichtungen im LDK erhalten.
Die letzte unbearbeitete Schaltzentrale ist auch die im LDK einzige verbliebene Fehlermeldung dazu im OSMI, denn es gibt eine Adressunstimmigkeit mit der offiziellen Liste (unter der Adresse in der Liste ist vor Ort ein Wohnhaus), bevor ich da drangehe muss ich das otg prüfen (wenn da überhaupt eine Nummer dransteht).
Danke, der vollständige Datensatz für telecom_exchange sieht dann gemäß Wiki und den hier empfohlenen Änderungen so aus:
Zusätze:
telecom=exchange auf einem way building eingetragen ist,building die Tags addr*.building UND node telecom=exchangeoperator=Deutsche Telekom AG wird hinzugefügt:operator:wikidata=Q9396operator:wikipedia=de:Deutsche Telekom