Suche für Gebäude auf privaten Gelände

Das funktioniert nur wenn der Sender auch ein “digital native” ist :wink:
Die Realität sieht leider anders aus…

Mir geht es darum, die einzelnen Dinge zu verbessern, verbogen wird nur zum test.

Hab mir mal ein wenig Nominatim angeschaut.
Wie es funktioniert wird hier gut erklärt:
https://wiki.openstreetmap.org/wiki/Nominatim/Development_overview

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.

Was meint ihr?

https://github.com/gravitystorm/openstreetmap-carto/issues/4185

okay danke, place lasse ich nochmal stehen bis das mit Nomatin geklärt ist.

€dit:
Bei research habe ich ein paar mehr Attribute gewählt…

€dit:
Habe place auch rausgenommen, da er sonst beim suchen nach PTB Braunschweig “Wohngegend” anzeigt^

Nominatim würde ein landuse auch berücksichtigen…

Was ich mich sowieso Frage, warum werden nur die Ränder eines Geländes genommen und keine “unsichtbaren” Flächen genutzt?

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…

Dachte “;” ist das Trennungszeichen.

Das hier ist ein Weg und keine Fläche:
https://www.openstreetmap.org/way/31066340#map=16/52.2966/10.4642

Ich hätte gerne was Allgemeineres.

Für alle Privatgelände:
Hier z.B. das gleiche “Problem”:
https://www.openstreetmap.org/search?query=audi%20wolfsburg#map=19/52.43311/10.79258

“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…


nur kleine Änderung

Ich glaube was er meint ist:
Wenn die PTB eine Fläche wäre, wäre klar, dass die Gebäude darauf dazu gehören.

Aber ich glaube so funktioniert das nicht, oder?

Ja, seit das falsche Gelände weg ist, kann man sich über die Suche nicht mehr beschweren.

Vorher war das meiner Meinung nach Anders.

Okay, ich hab einfach mal ein Issue aufgemacht:
https://github.com/osm-search/Nominatim/issues/1897

Ja genau

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).

Wenn ich das hier habe:
https://www.openstreetmap.org/way/32359108

kann das hier doch eigentlich gelöscht werden, oder?
https://www.openstreetmap.org/node/2617460300

Wo trage ich hier den (short) Namen der PTB ein?
https://www.openstreetmap.org/way/31432934

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.

short_name=* → https://wiki.openstreetmap.org/wiki/DE:Names

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 :wink:

Dabei verliere ich aber die genauen Koordinaten des bisherigen Knotens “links inten”, die ich gerne behalten möchte.

Ne, ist ja nicht der Name des Gebäudes…

leider nicht.

Und deswegen findet man den Standort auch leider nicht, wenn man nach PTB Berlin sucht…

Hab ich gemacht, vermutlich nicht so wie du es meinst…
https://www.openstreetmap.org/changeset/88866244
https://www.openstreetmap.org/changeset/88866358
https://www.openstreetmap.org/changeset/88866568

Hab ich versucht…

Hab mich dran versucht, ID konnte scheinbar keine so weit entfernte Relation laden, deswegen mit JOSM.
https://www.openstreetmap.org/relation/11376169

Sei nicht so Nominatim-Such(t)-Fixiert :wink:
Ansonsten habe ich den Eindruck, dass Du sehr gut zurechtkommst.
In die site-relation kannst Du auch den Tag
wikipedia=de:Physikalisch-Technische Bundesanstalt
einbauen, dann kannst Du vielleicht auch beruhigt den dortigen description-Tag kürzen, der gegenwärtig etwas sinnfrei abbricht (hatte bzgl. Zeichenzahl gewarnt :wink:
Gruß
Jo


Nachtrag @ FvGordon
Der Sinn des mergens ist mir schon klar, und ich behaupte auch nicht, dass dies Teufelswerk ist, nur eben machmal (unnötig) kompliziert.

Naja, Wenn man osm.org nutzt, dann nutzt man eben auch Nominatim und im Falle des Gebäude kann man Nominatin noch nichtmal einen Vorwurf machen.
Es müsste so etwas wie name:owner und shortname:owner geben…