Adressentags von Gebäuden

Morgen,
ich bin für die Verwendung des Karlsruher Schemas, also für die Erfassung der 5 bekannten addr=* tags an einen Node bzw. an einem Haus.

Ich bin der Meinung, Ihr dürft nicht von den bereits gut erfassten Städten und Ballungszentren auf das gesamte OSM schließen. Wenn du nämlich in ländlichen Gegenden zu mappen beginnst, dann ist das mit den PLZ-Relations, Gemeindegrenzen und administrativen Grenzen nicht mehr so eindeutig und einfach. Die fehlen dann nämlich oder sind ungenau und unvollständig.

Ich für meinen Teil mappe viel in Tirol/Österreich. Es gibt hier viele kleine Almen und Hütten, Weiler, Bauernhöfe, die alle Adressen haben. Aber ich bin mir nicht sicher, ob die für die vollständige Adresse nötigen Relations auch entsprechend genau eingezeichnet sind. Und ich will das auch nicht unbedingt überprüfen. Ich will Häuser zeichnen, Adressen dazu schreiben, vielleicht noch ein landuse um die Umgebung und gut ist. Nominatim ist damit zufrieden, findet alles.

Und ich denke, das so auch der Anfänger denkt. Der hat am Anfang gar keine Ahnung von so komplizierten Dingen wie Relations, Multipolygonen usw.

Aber er weiß, was zu einem Haus und zu dessen Adresse gehört, nämlich eben 5 addr=* tags. Und so habe ich das Erfassen von Adresse auch meiner Mutter beigebracht und die ist 66 Jahre. Da bräuchte ich anders gar nicht erst anfangen, von wegen Relations usw., da würde sie bald wieder aufhören mit dem Erfassen.

Und wenn wir dann mal über den Tellerrand hinaus schauen, in Länder, die nicht so weit und gut erfasst sind wie Deutschland, Österreich und viele andere Europäische Länder, dann ist es mit den Relations usw. noch viel schlechter. Da kann man sich die erforderlichen Infos nicht holen, weil sie nicht da sind. Ich kann auch nicht in einem solchen Land Gemeinden oder sonstiges erfassen, dazu fehlen mit die Infos. Ich kann im Urlaub besuchte Häuser, Hotels, POIs erfassen und dazu zumindest die bekannten addr-tags schreiben, ist mehr als gar nichts :wink:

Soviel zu meiner Meinung, einen schönen Tag noch

Darfst du ja auch. Zumindest ich habe da solange nichts dagegen, wie es für dich in Ordnung ist, wenn jemand die Adressen vereinfacht, wenn es möglich ist. In “grossen Städten” (dabei darf sich das “Dorf” hier schon lange nicht mehr “Stadt” nennen) sollte das allerdings nicht von möglichen Vereinfachungen abhalten – z.B. is_in=* gilt ja auch als veraltet, obwohl es teilweise noch notwendig ist.

Übrigens ist das in Deutschland auch mit kleinen Orten kaum ein Problem: Ich habe einen Ort in meinem Bearbeitungsgebiet, in dem vor nicht allzulanger Zeit nur die beiden durchgehenden Strassen und ein Place-Node vom openGeoDB-Import erfasst waren. Ich habe die Adressen so gemappt wie sonst auch und es funktionierte. Ob die Verwaltungsgrenze schon existierte weiss ich nicht, damals habe ich auf sowas noch nicht geachtet.

Vereinfachen im Grunde ja, wie es so schön heißt, keep it simple.

Aber, wenn dann sollte es doch einheitlich sein. Und da bin ich der Meinung, nicht nur innerhalb von Deutschland und Österreich, sondern wenn, dann wenn möglich in ganz OSM.
Ein einheitliches Tagging-Schema, bzw. feste Regeln, würde/n sicher vieles eben einfacher machen, aber davon träumen wir ja schon lange Zeit. :laughing:

Hauptsache es macht noch immer Spass, und das tut es, zumindest bei mir. :sunglasses:

Hi,

aufgrund der mal wieder aktuellen Address-Geschichte hab ich in meine Missing Residential-Karte eine Geo-Lokalisierung eingebaut. Einfach irgendwo hinklicken und in einem Popup kommt dazu Nominatims “Meinung”.

Wenn einen dabei die Suche nach Residentials, Places oder Ortsschildern stört: einfach im LayerSwitcher ausschalten.

Gruss
walter

p.s. an den Feinheiten feile ich noch. Vorschläge werden gerne ignoriert gesehen :wink:

Und da ziehe ich meine Frage von weiter oben noch mal raus, hier denke ich ist Nominatims Meinung falsch, die richtige Anschrift ist Starbach. Nur, wie bekommt man es hin dass Nominatim seine Meinung korrigiert?
Für Ausnahme halte ich es deshalb, da alle Ort in der Gemeinde ihren eigenen (Dorf-)Namen als Postanschrift behalten haben.

Wer kann es erklären:
Richtige Zuordnung (von Obercarsdorf und Ulberndorf auch an Grenzlinie erkennbar)
Falsche Zuordnung westlich der Weißeritz ist Obercarsdorf (Schmiedeberg) - östlich Ulberndorf (Dippoldiswalde) - auch an Grenzlinie erkennbar

Die Zuordnung scheint mir in Stufen zu verlaufen: Suche nächste Straße und dann den Ort etc. in dem sie verläuft.

Im obigen 2. Beispiel ist das für Obercarsdorf der Weißeritzweg, und der verläuft in Ulberndorf/Dippoldiswalde.
Wenn man sich mit dem Cursor nach Westen den Berg “hocharbeitet”, springt die Anzeige dann auf Ziegenrücken in Schmiedeberg um.

Das Ganze ist mir auch noch schleierhaft.
Eines ist mir inzwischen klar: Nominatim sucht das dem Click-Punkt nahe gelegenste Objekt und gibt dann dessen Daten aus. Liegt die Straße/das Haus/… dann in der anderen Grenze, kommen deren Daten raus. Und wenn die Straße nicht unterbrochen ist, ist es wohl zufällig, welchen Ort er anzeigt.
Daher geb ich jetzt mal die Id des gefundenen Objektes mit aus und demnächst zeigt ich es eventuell auch auf der Karte. (*)

Das ist natürlich unterschiedlich zur reinen Adresssuche.

Gruss
walter

*) eigentlich wollte ich heute früh nur 'nen “Quickie” machen, aber jetzt artet die Sache richtig in Arbeit aus :frowning:
Und jetzt nehme ich mir Hitzefrei.

Version 16 positioniert jetzt den Popup auf das Objekt, das Nominatim bei der Geosuche gefunden hat.
Ist wichtig, wenn man irgendwo in der “Pampa” klickt und die Suche anscheinend einen falschen Ort anzeigt.

Gruß
walter

@wambacher:
IE 7 mit Flash Player, Seiteinhalt bleibt leer (grün) Fehlermeldung:

Zeile: 285 
Zeichen: 7 
Fehler: 'console' ist undefiniert 
Code: 0

FF 21, Seiteninhalt bleibt leer (grün), da Adobe Flash Player nicht installiert werden kann. Wofür wird dieser benötigt?

Moin,

Hmm - bist Du Dir bei letzterem wirklich sicher?
Bei der Post(anschrift) gilt eigentlich der offizielle Grundsatz:

amtlicher Gemeindename = postalischer Bestimmungsort

Dies findet man regelmäßig als Aussage bei von einer Gebietsreform betroffenen Gemeinde.
Für den Ortsteil gibt es die Extra-Zeile zwischen Namen und Straße.

Aber das ist halt der Unterschied zwischer jahrzehntelanger gelebter Praxis und formaler Theorie.
Passiert mindestens tausendfach in ganz Deutschland bei der Post - und klappt in der Realität auch immer … zumindest, solange keine Briefzusteller-Aushilfe der Smartphone-Generation im vorübergehenden Einsatz ist …

Indem man die Ortsteilgrenzen und -Relation der Datenbank hinzufügt.
Dann gibt Nominatim immerhin den Ortsteil mit aus - sozusagen ganz Post-konform.

Gruß
Georg

Das JavaScript-Objekt “console” ist eine Möglichkeit in Firefox (und evtl auch anderen) selbst definierte Fehlermeldungen auszugeben. Der IE sollte aber einfach ignorieren können, dass er es nicht kennt

Bei mir funktioniert es auch ohne Flash Player. Da ich es eben auch ins Grüne geschafft habe: Wenn die Zoomleiste dargestellt wird klicke auf diese etwa mittig. Ansonsten: Was genau wird an Text angezeigt?

Mir ist das eben zwei Mal passiert (ohne Flash Player-Meldung), beim zweiten Mal war ich erst bei lat=90.000, egal wie ich mich zu bewegen versuchte, und danach irgendwo >>180 für mindesten einen der beiden Werte ohne zuvor etwas besonderes gemacht zu haben (beim ersten Mal: Öffnen der Firefox-Konsole während des Neuladens).

war nur einen Testausgabe console.log(…). ist jetzt draussen.
kann der IE das nicht? wenn ja, dann ist das Teil noch nie im IE gelaufen.
wenn er es wirklich nicht kann, müsste jetzt die selbe Meldung in Zeile 299 oder 321 kommen. Da macht er das Cookie-Handling und erzählt einiges dazu.
Teste bitte nochmal kurz. Ansonsten starte ich mal ne Windows-VM. Ich habe eigentlich versucht, alle Browserabhängigkeiten zu berücksichtigen, aber …

Ok, “Houston, wir haben ein Problem” - ich kümmere mich drum.

Links oben ist ne Uhr reingekommen, damit man nicht zulange QA macht :wink:
Entweder krieg ich ne Abfrage hin (FP nicht installiert?) oder ich schmeiss es wieder raus. (*)

gruss
walter

*) aufgrund der Hitze temporär rausgenommen. Dafür brauch ich einen “Kühlen Kopf”

Ich habe gerade beim langsamen einzoomen auf Deutschland folgende Meldungen in der Konsole erhalten, Zoomen funktionierte dann nach etwa zwei Versuchen (diese gingen nur mit der Scrollleiste) nicht mehr:

[14:22:33.250] TypeError: map.getZoom(...) is null @ http://osm.wno-edv-service.de/residentials/:412
[14:22:33.672] GET http://a.tile.openstreetmap.org/0/0/0.png [HTTP/1.1 200 OK 2782ms]
[14:22:33.770] TypeError: a is null @ http://openlayers.org/api/OpenLayers.js:129

Oh, und ich habe wieder so eine schöne Position: Heilbronn ist in der Kartenecke rechts unten noch verpixelt (ich war ja beim Reinzoomen) zu sehen, Koordinaten reichen etwa von -179 (links) bis 164 (rechts) und die Latitude ist fest bei -90.0, die Boudingbox ist als “-903.50567, -90, 885.24433, -90” angegeben. Wenn ich zum Saarland rüberscrolle komme ich auf “bbox=-918.97442, -90, 869.77558, -90”, die Koordinaten in der “latlon=”-Anzeige brechen brav bei 180° um, wobei das ja eigentlich nicht etwa an der französischen Grenze sein sollte.

Wenn ich nun die Seite neu lade komme ich auf diese Werte (ohne Auffälligkeiten in der Konsole): “bbox=-882.42188, -89.33004, 882.42188, 89.33004
zoom=0”.

Btw: Kannst du die divs #bbox_div und #zoom_div im Document vertauschen, dass das Markieren des Textes intuitiver funktioniert?

Nachtrag: Öffnen oder Schliessen der Firefox-Konsole bringt ihn in etwa 100% durcheinander.

Im IE funktioniert es nun super, danke :slight_smile:

Im FF ist das verlangen nach dem Flashplayer nicht mehr erkennbar, aber es bleibt dennoch nur grün.
Edit: habe festgestellt, wenn ich in die grüne Kartenfläche einen Doppelklick mache, wird die Karte danach aufgebaut.
Edit2: zeigt die ganze Welt an und dem Browser wird es warm :smiley:
Kann es sein, dass die Karte den letzten angezeigten Ort speichert? Wenn aber die Karte das erste mal aufgerufen wird, die ganze Welt (bzw. garnix)? Damit will ich sagen, die Sorgen hat man nur, wenn man in diesem Browser die Karte noch nie geöffnet hatte.

console.log fixed. wen es interessiert:


if (typeof console === "undefined" || typeof console.log === "undefined") {
     console = {};
     console.log = function() {};
   }

Meine Sicherheit liegt so bei 99%, obwohl gerade die Webseite der Gemeinde meint es wäre nicht so.

Das hatte ich in meinem ersten Post ja schon so vermutet, mich da aber bisher noch nicht so rangetraut …

Also bei mir gibt’s
addr:street=*
addr:housnumber=*
in der Regel für das Haus.
addr:city einzutragen ist was für Roboter.
Und um addr:postcode einzutragen müsste ich im Postleitzahlenverzeichnis oder im Telefonbuch nachschauen womit sich wieder das Problem des Urheberrechts ergibt.
Vom Thema Redundanz ganz zu schweigen.

Oder du schaust in die Grenzrelationen, aber das könnte (und sollte, weil sonst bei Korrekturen der Grenze der möglicherweise falsch übernommene Wert als richtig angenommen wird) eine Anwendung auch gleich selbst machen. Das Selbe gilt für Stadt, Staat, Bundesland und Stadtteil: Wenn sich da was ändern sollte (z.B. Korrektur einer verbreiteten falschen Schreibweise) wird vermutlich erstmal nur die Grenzrelation geändert, bis irgendjemandem auffällt, dass tausende Adressen trotzdem falsch sind, es gibt oft unterschiedliche Schreibweisen (mit/ohne Namenszusatz, mit Klammern, Komma oder Trennwort getrennt, …), Anwendungen sollten (und müssen sowieso) das aus den Grenzrelationen ermitteln können, …

Ich nutze auch nur “addr:housenumber”=* und “addr:street”=* (normalerweise ans Haus, weil es eine Hausnummer ist), wobei ich statt letzterem auch sehr oft associatedStreet-Relationen (die ursprünglich bevorzugt genutzt werden sollten) nutze um nicht bei allen hundert Hausnummern den Strassennamen angeben zu müssen (Redundanz) und um deutlicher zu haben, welche der ähnlich benannten Strassen gemeint ist.

Man kann es auch den Mappern und Anwendungen einfacher machen, indem man alle Informationen dort erfasst, wo man sie real braucht, an den Gebäuden.

Wieviele associatedStreet-Relationen habe ich gesehen, die weder addr:street, addr:postcode, addr:city noch addr:country in den Taggs der Relation enthalten. Und wieviele associatedStreet-Relationen habe ich gesehen, denen Straßen und Häusern fehlen.

Ich halte das Konzept der associatedStreet-Relationen für in der Praxis gescheitert. In der Informatik-Theorie mag das toll und einfach aussehen. In der Mapping Praxis ist der zusätzliche Schritt, eine Straße und die dazu gehörigen Gebäude in eine Relation aufzunehmen vielen zu aufwändig und daher grandios gescheitert. Gelegentlichen Mappern und Neulingen ist die Existenz einer solchen Realtion nicht einmal bewusst.

Und es ergibt sich die Frage, welche Anwendung denn überhaupt die associatedStreet-Relationen verwenden. Meines Erachtens sind diese Relationen Tagging für die Theorie. Die Aussage “associatedStreet-Relationen sollen bevorzugt genutzt werden” ist eben auch nur der Wunschtraum einiger Informatiker aus der Frühzeit des Karlsruher Adress-Schemas und hat sich in der Praxis nicht durchgesetzt.

Anders sieht es mit den addr:* Taggs des Schemas aus, die wirklich genutzt werden und einen Wildwuchs an Tagging-Varianten bei Adressen verhindert haben.

Edbert (EvanE)