Datenquellen von Nominatim auf openstreetmap.org

Hallo zusammen. Ich stehe gerade voll auf dem Schlauch.

Ich habe auf openstreetmap.org nach der Adresse 35516 galen place, fremont gesucht. Die Suche spuckt unter der Nominatim-Rubrik dann das Ergebnis “Haus 35516, Galen Place, Centerville District, Fremont, Alameda County, Kalifornien, 94536, Vereinigte Staaten von Amerika” aus, von GeoNames kommt nichts zurück. So weit so gut, das Haus wird beim Hovern über dem Ergebnistext an der richtigen Stelle angezeigt.

Jetzt wird beim Anklicken des Ergebnistexts aber der way der Straße und nicht diese Adresse angezeigt. Ein Blick in die Daten zeigt, dass dort nur die Straße gemappt ist und keine Adressen, auch keine Interpolation, so weit JOSM mir hier keinen Streich spielt.

Wie verortet Nominatim hier also die Adresse? Woher kommt das “Haus 35516”?

woher weist DU das?

Wenn man Nominatim nach Details fragt (https://nominatim.openstreetmap.org/details.php?place_id=184715412), wird der “Schwerpunkt” der Strasse angezeigt. So ist es ja bei fehlenden Hausnummern ok.

Gruss
walter

Was mich jetzt aber auch stutzig macht:

wenn man auf deinen Link https://www.openstreetmap.org/search?query=35516%20galen%20place%2C%20fremont#map=19/37.57132/-122.02315 klickt, kommt diese Seite:

Man achte auf das “wo ist das?”.

Ein Klick darauf und dann kommt

wobei “Suchergebnisse von Internal” auf openstreetmap.org zeigt, also keine Info bringt.

Grübelnde Grüße
walter

Wenn man mal nach anderen Hausnummern (z. B. 35459 oder 35528) in dieser Straße sucht, sieht man dass der Marker (der beim Hovern kommt) an eine andere Stelle/Straßenseite springt. Und wenn man mal bei Google Maps spinkst, sieht man, dass die Position stimmt. Bei in dieser Straße nicht vorhanden Hausnummern (z. B. 35527) wird allerdings trotzdem ein Treffer im Galen Place angezeigt, wohl interpoliert.

Die Hausnummern sind in dieser Siedlung (Stadtteil?) scheinbar straßenunabhängig grob von Süd nach Nord und dann von West nach Ost vergeben.

Ok, das bestätigt die korrekte Lage.

Nun schliess ich mich deiner Frage an: Woher weiss Nominatim das? Und was bedeutet “Suchergebnisse von Internal”?

Magst du mal beim Nominatim-Team nachfragen?

Gruss
walter

Kann ich machen. Als github-Issue oder gibt es einen anderen Weg für solche Fragen?

Hier gibt’s den Nominatim DEBUG-Output inkl. sämtlicher SQL-Statements:

https://nominatim.openstreetmap.org/search.php?q=35516+galen+place%2C+fremont&polygon_geojson=1&viewbox=&debug=1

Ich würd es mal hier versuchen: https://lists.openstreetmap.org/listinfo/geocoding

ist ja kein Bug, sondern ne Frage.

ein Kontakt wäre auch noch Sarah Hoffmann, nur hab ich die mail net.

Gruss
walter

jo, das hier sieht “verdächtig” aus:


SELECT place_id 
  FROM location_property_tiger                   <------------------------ !!
 WHERE parent_place_id in (64135866) 
   and (interpolationtype='even' or interpolationtype='all') 
   and 35516>=startnumber 
   and 35516<=endnumber 
 limit 20;

Greifen anscheinend auf externe Daten zu (Tiger).

Toll. Wie soll man dann die Amis motivieren, fehlende Adressen in OSM einzugeben, wenn Nominatim und somit openstreetmap.org dort eh alles findet. :frowning:

Gruss
walter

Nominating importiert ‘schon immer’ TIGER Adress(interpolations)daten.

Habe auf der Mailingliste jetzt eine Antwort von lonvia bekommen.

(https://lists.openstreetmap.org/pipermail/geocoding/2018-March/001937.html)

Aufgrund Punkt c) hätte ich eigentlich den kompletten Verzicht auf externe Daten erwartet. Andererseits ist das ja genau die Diskussion, die hier vor ein paar Tagen noch lief, was auf der Startseite eigentlich gezeigt werden sollte und für wen.

Ja, das hatte mich ja auch negativ überrascht. Da Simon davon sprach, dass das “schon immer” so gewesen sei, macht es wohl keinen Sinn um Abstellung dieses Punktes zu bitten.

Gruss
walter