Seltsam, dass das bei der PTB nicht gut funktioniert.
In Mannheim klappt das inzwischen ganz gut:
Beispielsweise bei “mannheim q4,23” zeigt Nominatim das Gebäude und Geschäfte, über “Mehr Treffer” kann man auch den place mit “name = Q4” sehen.
Der Name der Straße “Fressgasse”, die unmittelbar davor liegt, wird nicht mehr aufgeführt, seit wir nur noch mit “place” arbeiten. Ihr Name wird auch in der Realität für keine Adresse verwendet.
Als nächsten Eintrag zeigt mir Nominatim allerdings eine Ladestation in Karlsruhe. Manche Einträge scheint Nominatim doch noch fälschlicherweise dazuzufügen.
Ein Nachteil ist, dass die Hauptkarte den Namen von “place” nicht anzeigt, wenn place als Fläche eingetragen ist. Nur die Namen von nodes werden angezeigt. Deshalb sind die meisten OSM-Karten in Mannheim wenig hilfreich und man muss doch Google nehmen, um sich zu orientieren oder um eine Adresse auf der Karte zu suchen.
OsmAnd zeigt die Namen der Quadrate aber an.
Aber auch type=site an einem einfachen way ist falsch. Das wäre nur für eine - hier nicht erforderliche - Relation zu nutzen.
Ebenfalls ist place=plot unzutreffend (siehe nachfolgend)
Bitte die Daten nicht so verbiegen, dass Nominatim oder der Renderer das gewünschte Ergebnis liefert.
Am ehesten würde nach meiner Ferndiagnose ein office=research (?) passen: https://wiki.openstreetmap.org/wiki/DE:Key:office
Tja, in office=research https://wiki.openstreetmap.org/wiki/DE:Tag:office%3Dresearch
lese ich dann aber als Abgrenzung Gebäude vers. Gelände:
“Ein Campus - Zeichne die Fläche um das Institutsgelände und füge amenity=research_institute hinzu.”
(was mir strukturell auch durchaus sinnvoll erscheint)
amenity=research_institute IST beim PTB-Gelände gesetzt, aber wohl dem Renderer carto unbekannt.
Ich habe mich mal mit overpass-Hilfe kurz (international) umgeschaut,
die meisten Nutzer reagieren darauf, dass sie einen carto-Render-Tag hinzufügen (z.B. landuse) um den IMHO verständlichen Wunsch umzusetzen den name anzeigen zu lassen.
Habe etwas suchen müssen, um ein “nacktes, ehrliches” amenity=research_institute zu finden: https://www.openstreetmap.org/way/529279681
Nominatim dagegen hat damit kein Problem, einfach mal nach
Max-Planck-Institut für Evolutionsbiologie
suchen, wird gefunden und korrekt als “Research institute” eigeordnet, sprich Nominatim braucht wohl kein place- oder sonstiges Korrektur-Tag um ein Institutsgelände zu finden.
place=plot [nutzlos, bzw, führt nur zu Falscheinordnung in Suche]
research_institution=yes [undokumentiert/nutzlos]
type=site [sinnfrei/falsch weil gar keine relation vorliegt]
loc_name=PTB [ist schon short_name - als solcher sinnvoll]
reg_name=P.T.B. [was soll das bringen?]
der
operater=Bundesministerium für Wirtschaft und Technologie
ist heute Bundesministerium für Wirtschaft und Energie
Wäre die PTB ein place:neighbourhood, würde es auftauchen, (Habe ich mal testweise so gemacht)
aber das Element auf Stufe 27, leider auch.
Für Gelände ohne Straßennamen (bzw mit Straßennamen ohne “Bedeutung”), müsste man irgendein Element finden, welches auf Stufe 26 oder 27 die Straßennamen bei Nominatim ersetzt und mit den Entwicklern von Nominatim absprechen, dass sie es nutzen.
Puh… mal der Reihe nach und Danke, dass Du meine Anregungen aufgegriffen hast…
Mein erster Tipp wäre zukünftig JOSM zu verwenden (statt ID).
Wenn ich “Fahrbereitschaft, PTB” oder “Fahrbereitschaft PTB” oder “PTB fahrbereitschaft” eingebe (#14), findet Nominatim ganz prima das Gesuchte.
In #14 beschwerst Du dich über das dortige “Parkstreifen vor Hertz-Bau” in der Ausgabe
Das ist aber (als nächstliegende Straße) nunmal bei euch so kurios gemappt: https://www.openstreetmap.org/way/477139042
als benannte access=private-Zufahrt zu einem access=yes-Parkplatz kommt mir das reichlich gaga vor.
Vielleicht (vgl. #10) erstmal auch soetwas kritisch hinterfragen und aufräumen.
“Bei research habe ich ein paar mehr Attribute gewählt…”
Mag ich dir nicht verbieten, ob das (sinnvoll) auswertbar ist, ist eine andere Frage.
“Habe place auch rausgenommen, da er sonst beim suchen nach PTB Braunschweig “Wohngegend” anzeigt”
Ebendies ist/war hier das Problem beim “place-Missbrauch”
“Nominatim würde ein landuse auch berücksichtigen…”
Das bezweifelt keiner.
Wenn Du die PTB unbedingt auch in den Nominatim-Augabetext haben willst, dann müsste vermutlich amenity=research_institute an geeigneter Stelle (z.B. 22) in deren “Country to street level” integriert werden (IMHO kein ganz abwegiger Ansatz, läuft wahrscheinlich aktuell unter Other=30)
“Was ich mich sowieso Frage, warum werden nur die Ränder eines Geländes genommen und keine “unsichtbaren” Flächen genutzt?” - Häh? wann, wo, von welchem Tool?
Ja, gefallen tut mir das auch nicht, aber z.B. die Rollbahn heißt Rollbahn, auch wenn der Name (außer bei Straßensperrungen) keinen “Zweck” hat, deswegen habe ich das erstmal so akzeptiert…
“Das hier ist ein Weg und keine Fläche:”
Nein, vgl. https://wiki.openstreetmap.org/wiki/DE:Area
Mmh, setze doch mal ein area=yes an das PTB-Gelände.
Ich glaube nicht, dass damit carto zum Rendern zu bewegen ist, aber einen Versuch ist es wert.
“Für alle Privatgelände: Hier z.B. das gleiche “Problem”:”
Dort tourism=theme_park und so ganz vergleichbar ist dies auch nicht, weil die nächstgelegene Straße, die sich Nominatim wohl greift (lt. “Nominatim/Development overview”) auch noch außerhalb der “name=Autostadt” liegt
Wenn ich mir dies anschaue: https://wiki.openstreetmap.org/w/index.php?title=Nominatim/Development_overview&action=history
(der Kerntext scheint mir vor 10 Jahren geschrieben) stellt sich mir aber auch die Frage, inwieweit das dortige überhaupt noch aktuell ist…
Nebenbei, weil ich unsicher bin, ob Dein “Sender” in #21 wirklich eine Verwechslung mit “Empfänger” ist, wie sponatan von mir vermutet …
Wie das geht:
auf OSM.org am rechten Bildschirmrand das “Teilen”-Menü (6. von oben, das mit dem Pfeil nach rechts oben) öffnen
“Kartenmarker setzen” anclicken
Marker positionieren und Link ODER Kurz-URL anwählen, die dann per cut+paste hinkopieren wohin man möchte
sehr praktisch Sache…
Schaut euch mal unter https://wiki.openstreetmap.org/wiki/DE:Tag:amenity%3Dresearch_institute
rechts die Icons unter
“Für diese Elemente” an, die sollen verdeutlichen, dass ein amenity=research institute als way immer als Fläche anzulegen und auszuwerten ist.
Solche Absprachen sind extrem wichtig, sonst klappt gar nix insb. bei geschlossenen ways.
Das “Beispiel: Ein Kreisverkehr mit einem Rasenbereich in der Mitte” in https://wiki.openstreetmap.org/wiki/DE:Area
ist da ganz hilfreich bein rein- und durchdenken - aus Renderer-Sicht (Nominatim ist dann wieder eine andere Baustelle).
Ja - **günstiger **den node (niedriger ID) in eine Umrissecke einbauen/nutzen - und dort die Daten löschen. An Hand der node-ID kann man die Historie zurück verfolgen.
Ja, Erfassung über Area ist vorzuziehen (trotz des carto-Render-Versagens) - der Node ist überflüssige/störende Dopplung.
Der Ansatz von geri-oc ist richtig, neben der Versionsgeschichte gibt es dabei noch einen weitern Vorteil
falls irgendjemand auf der weiten Welt mal darauf verlinkt hat, findet es zwar nicht mehr den Node, aber immerhin noch die Flächenecke.
(ich nehme immer die linksunten, im Südwesten, insbesondere wenn ich bisherige Node-Objekte zur Fläche (end)ausbaue)
Schreib, wenn Du nicht verstehst, was wir meinen, dann mach ich das auf die Schnelle für dich…
Der short_name sollte sich immer auf den name beziehen
schau mal hier, ob Du da(mit) ne vernüftige Struktur finden/reinbringen kannst: https://wiki.openstreetmap.org/wiki/Names
Ich würde Dir in diesem Zusammenhang raten, bei allen Liegenschaften den description-Tag zu nutzen um kurz (1-2 Sätze, max 255 Zeichen) die Standort-Bedeutung als Teil der PTB-Gesamtstruktur zu erläutern: https://wiki.openstreetmap.org/wiki/DE:Key:description
Und nebenbei:
research=[…] sollte sich auf den jeweiligen Standort beziehen, nicht auf die PTB allgemein
research_institution=yes kann bei allen Standorten raus
Und ganz nebenbei, die Zusammenfassung aller (verteilten) PTB-Standorte in einer Relation - dies wäre dann eine vom type=site (die hätte dann auch den kompletten research-Krempel)
Zur Problematik, welche Node-ID beim Vereinigen (von z.B. eines Knotens im Gebäudeumriss und Knoten mit der Adresse) der gemeinsame Knoten bekommt, habe ich einige Versuche mit JOSM gemacht:
Zum Vereinigen kann man erst einen Knoten markieren, dann mit gehaltener Strg- oder Shift-Taste den zweiten anklicken und dann ‘m’ (merge) auf der Tastatur betätigen (oder: Menü: Werkzeuke - Punkte vereinigen) (Methode 1a). Als Koordinaten für den vereinigten Knoten werden die des zuletzt rot gewordenen Knotens genommen und als Node-ID die kleinste (älteste) Nummer.
Man kann auch mit der Maus ein Rechteck oder mit der Lasso-Funktion (erhält man, wenn man nochmals ‘s’ drückt) eine geschlossene Linie um beide zu vereinigende Knoten ziehen (Methode 1b). Nach Betätigen von ‘m’ wird als Position die des jüngsten Knotens genommen, der dann die kleinste (älteste) Node-ID bekommt.
Es gibt noch eine (zweite) Methode, mit der man mit der Maus Knoten vereinigen kann:
Wenn man einen Knoten auf den anderen schiebt und beim Loslassen der Maustaste die Strg-Taste festhält, werden die Knoten wie folgt vereinigt:
Als Position und Node-ID werden die des nicht bewegten Knotens übernommen.
Auf unseren Fall bezogen (ich möchte den alten Knoten mit der Adresse, der innerhalb des Hausumrisses liegt, in den Hausumriss integrieren) bekomme ich mit Methode 1a oder 1b (zwei Knoten markieren und mit ‘m’ vereinigen) immer die älteste ID - bei Gebäuden, bei denen der Adressknoten nach dem Zeichnen des Gebäudes ergänzt wurde, geht dessen ID so verloren.
Mit der zweiten Methote kann ich mit der Maus den Adressknoten auf einen Gebäudeknoten schieben und beim Loslassen der Maustaste mittels Strg vereinigen - dann habe ich die Adresse im Hausumriss, aber die Node-ID der Adesse geht verloren. Eine andere Möglichkeit ist, einen Knoten des Gebäudes auf den Adressknoten zu schieben - dann hat der vereinigte Knoten die ID des Adressknotens, aber wir haben die Position des Gebäudeknotens verschoben.
Man muss also einen neuen Knoten in den Gebäudeumriss einfügen und den Adressknoten mit diesem vereinigen, damit die ID des Adressknotens erhalten bleibt - egal mit welcher Methode (1a, 1b oder 2). Das ist sowieso der Fall, wenn man einen neuen Umriss anlegt, um Eigenschaften eines Knotens auf eine neue Fläche zu verschieben. Aber das trifft nicht zu, wenn zuerst der Gabäudeumriss gezeichnet und später der Adressknoten hochgeladen wurde.
Was mach eigentlich iD in diesen Fällen beim Vereinigen - geht es dort verständlicher?
Mmh merge?
Wenn ich einen Node zur Fläche ausbaue schiebe ich den nach “linksunten”, erstellen von dort aus die Fläche, übertrage die Tags die ich brauchen kann und entferne sie dann am Node.
Analog würde ich hier den einen Flächen-Node “linksunten” erstmal löschen, den Node über den wir hier sprechen dorthin verschieben, die Fläche aus der Fläche heraus mit diesem Node neu verbinden und dann die Tags am Node löschen.
Irgendwelche mergereien braut es dabei nicht, aber Versionsgeschichte und ID beider Objekte bleiben erhalten.
Nutze dabei JOSM + KISS;-)
Eben mal schnell umgesetzt - Kontrolle über die Links in #29 möglich
Nur kurz getestet, ohne hochzuladen,
beim Vereinigen von Fläche und einzelnen separaten Punkt, wird die node-id vom einzelnen Punkt entfernt.
Beim Vereinigen von zwei Punkten (Punkt a wird auf Punkt b gezogen), bleibt die node-id von dem Punkt erhalten den man nicht bewegt (Punkt b).
Beim Vereinen von zwei Punkten (Punkt a und Punkt b wird selektiert, Vereinigung per Kontextmenü), bleibt die node-id von dem Punkt erhalten, den man zuerst selektiert hatte.
PS: und noch bisschen OT, interessanter wirds bei der Handhabung der Objektchronik von gesplitteten ways, siehe: https://github.com/openstreetmap/iD/issues/7795
(Man bekommt nicht wie bei JOSM eine Abfrage an welches Wegsegment die id soll, sondern man kann sich ausschliesslich über einen Workaround helfen, indem man die osm-way Richtung vorher umkehrt)
Falls jedmand aus der JOSM-Gruppe es unterstützen möchte, das iD bzg. dieses Belangs etwas “schlauer” und “flexibeler” wird, dann dort im Issue#7795 dies gerne mal mit zum Ausdruck bringen
