Ich dachte mir schon, dass es da eine Straße mit dem Namen in der Relation gibt.
addr:street gehört aber doch sicher nicht an die Relation und kann weg? Der Rest ist ja ok (Website zu dieser Alleen-Website etc.).
Gruß, Frank
Haben wir bei OSM eine Karte die Kreise um beliebige Orte darstellen kann, etwa so wie hier: https://www.freemaptools.com/radius-around-point.htm
Ich habe leider nichts entsprechendes gefunden.
Gerade wollte ich “uMap” antworten, aber wie ich feststellen musste, bietet das tatsächlich keine Buffer-Funktion an. Gefunden habe ich auch nur andere Leute mit dem selben Problem:
https://help.openstreetmap.org/questions/48034/is-the-an-equivalent-of-umap-that-can-draw-circles-as-an-overlay
http://gis.stackexchange.com/questions/134512/online-service-that-allows-drawing-a-circle-on-top-of-a-map
Hallo zusammen,
ich dachte ich könnte “mal eben” in meiner Stadt das fehlende addr:country=DE" an den nodes ergänzen, aber nach der Abfrage kam heraus, dass davon >600 nodes betroffen sind.
Ich hoffe meine Frage ist wirklich klein genug für diesen Thread und lässt sich kurz beantworten: Kann man das Ranbasteln des Tags automatisiert machen? Und wenn ja, wer könnte und würde das tun? Ich bin jetzt nicht so der Progger…
Danke!
Das sollte bequem in JOSM gehen. Stadt reinladen, Filter setzen und das Tag hinzufügen.
Ich halte addr:country=DE allerdings für redundant und benutze es nicht mehr.
Zudem wäre das ein mechanischer Edit. Und wie chris66 schon sagte: Redundant, weil es ja exakte Grenzrelationen gibt.
Lea, lass es einfach. das geht natürlich, ist aber total unnötig.
Gruss
walter
Sorry, aber Einspruch. Die Befürworter von “redundant, lass weg, unnötig” erklären mir bitte, auf welchem Wege man z.B. aus einem Geofabrik-Deutschland-Extrakt alle Adressen ausschliesst, welche nicht innerhalb der deutschen Grenzen liegen. Ich meine damit in angemessener Zeit und nicht eine Query mit Laufzeiten von mehreren Stunden. Ich lerne ja gerne dazu…
Kommt auf die Technik an:
DE-Extrakt in eine leere DB laden, spatialen Index für die Geometrien erzeugen und abfragen. Dieses ist notwendig, da die Extrakte ja größer sind als das jeweilige Land und immer etwas “Beifang” vorhanden ist.
Das mit dem addr:country=DE wird hier ja nur für Adressen diskutiert und dort könnte es sogar eine Performanceverbesserungen bedeuten.
Aber was ist mit den hunderten von anderen Objekt-Typen, die eben kein “ist in Deutschland”-Tag kennen?
Hydranten, Haltestellen, Buildings ohne Adressen, Parkplätze, Straßen, Laternen, Hundekottütenspender, …
Spätestens da sind spatiale Abfragen notwendig, weil es eben nicht anders geht.
Somit kämpft du für eine Sonderlösung bei Adressen, die mMn unnötig ist.
Gruss
walter
Da haben wir ein Problem. GIST-Indices werden bei ausnahmslos allen (!) in Frage kommenden PostGIS-Funktionen nur benutzt, wenn “is inside” gefragt ist, nicht bei “is not inside”. Die daraus resultierenden Laufzeiten so einer Query kannst du dir vorstellen, da reichen 6, 7 Stunden nicht. Alternativ kann man alle “inside” kennzeichnen und dann diejenigen entfernen, die nicht die “inside”-Kennung haben - so mach ich das im Prinzip im Moment weil selbst das Update/Delete mindestens 5x schneller ist wie das “is not in”. Aber auch das ist weit weg von optimal.
Natürlich betrifft das Problem alle anderen Objekte auch, das stimmt. Nur hier hätten wir eben den Fall, dass die Angaben schon per (Karlsruher) Schema vorgegeben sind. Ich für meinen Teil ergänze auf jeden Fall auch in Zukunft die entsprechenden Angaben in Adressen, sei es Straße, City, Postcode oder Country. Im ungünstigsten Fall sind mehrere spatiale Abfragen nötig, und auch die können irren. Siehe Nominatim, das mir meist irgendein Hamlet oder Suburb oder sonstwas zu einem Objekt packt, dass da gar nicht hingehört > https://nominatim.openstreetmap.org/search.php?q=lederstra%C3%9Fe+1%2C+calw&polygon=1&viewbox= Wimberg ist halt weit weg und hat da nichts zu suchen.
Gruß, Frank
Es gibt fast immer Probleme, die sich schneller/einfacher lösen lassen, wenn redundante Attribute vorhanden sind/wären.
Das muss man abwägen gegen die Probleme, die prinzipiell entstehen, wenn Angaben redundant (mehrfach) in einer DB existieren.
Bei den addr:country lasse ich das im Landesinnern weg, nur nahe der Grenze, vor allem bei kompliziertem Grenzverlauf überwiegen für mich die Vorteile des addr:country in der Praxis, da man bei starkem Zoom oft nicht weiß, wo man gerade ist.
Hier nochmal ein schönes Beispiel, warum vollständige Adress-Angaben m.E. schon wichtig sind: https://www.openstreetmap.org/node/420069115
Man denke sich, dass der Node ohne addr:city und addr:postalcode dastehen würde. Das Ergebnis der dann allfälligen Bestimmung von PLZ und Ort durch Distanzmessung ist “könnte eventuell unter Umständen zu Friedrichshafen gehören, aber sicher ist das nicht”. Das ist IMHO unbefriedigend.
Edit: Wortwahl
addr:city und addr:postcode sind ein anderes Thema, zumindest die PLZ ist vorläufig noch unverzichtbar, so lange die Grenzen noch ungenau sind.
Hier übrigens eher ein Beispiel dafür, dass die Grenze an die Ufer-Aufschüttung angepasst werden muss.
Anm.: Bei den “Fools” tauchte die Adresse nicht auf, da der Beach Club scheinbar im Niemandsland im Bodensee lag.
Mag sein, aber hier geht es definitiv um “welche Adressen sind innerhalb (st_contains()) der Grenze von DE?” Da zieht dein Arguiment, dass es im umgekehren Fall nicht sehr gut funzt, bei mir nicht.
Da gibt es eine ganz einfache Lösung: Die Quellen von PostGIS sind frei verfügbar - mach es besser 
Damit löst du aber nur ein sehr spezielles Problem mittels einer Sonderlösung. Für 99.9 % der restlichen Daten bring das hier nichts, aber auch garnix.
Nominatim ist eine ganz andere Baustelle, die auch ihre Schwächen hat. Bitte vergleiche hier nicht Äpfel mit Birnen.
Wenn ich das hier richtig sehe, betreibst du Tagging für die Auswerteprogramme. Kannst du gerne machen, allerdings nicht für die gesammte Database.
Ja, das sah schon eng aus:
Aber anstelle Daten notdürftig so zu taggen, dass einem die Auswertung passt, sollte man lieber die Geometrien der Grenzen anpassen.
So wie es vor einigen Stunden geschehen ist:
Sorry, aber du drehst an den falschen Schrauben.
Gruss
walter
ps: es gibt zudem immer mehr Auswerter, die auf addr:country und sogar auf addr:city verzichten. Und erst Recht auf das berüchtigte is_in-tag.
Jo, stimmt. Fools überprüft ja nur, ob eine PLZ im richtigen PLZ-Gebiet liegt. Aber wenn die Gebiete nicht sauber sind, kann ich auch nix machen.
Gruss
walter
Das ist kein Äpfel-Birnen-Vergleich. Genau das kann passieren, wenn man sich distanz-abhängig die fehlenden Daten zusammenklauben muß. Das hat erstmal mit Nominatim nichts zu tun.
Hm. Wir taggen nicht für den Renderer, nicht für Auswerteprogramme, nicht für … Ehrlich, da frage ich mich, für wen dann?
Das Karlsruher Schema existiert ja nun mal ne ganze Weile und wird auch genutzt. Mir da zu unterstellen, ich würde Daten anpassen, damit Auswertungen passen, ist nicht dein Ernst?
Überwiegend scheint die Meinung ja zu sein, dass bis auf Hausnummer und Straßenname die restlichen Angaben einer Adresse überflüssig sind, weil redundant und man die ja einfach per spatial query abfragen kann. Nun gut, dann werde ich mal in mich gehen, vielleicht bin ich ja auf dem falschen Pfad und sollte mich besser Hundekottütenspendern, Parkbänken und Stolpersteinen widmen. Das sind ja auch wichtige Themen in OSM. Oder einfach mal ne Auszeit von OSM nehmen.
Gute Nacht.
Nachtrag zur “Zuverlässigkeit” per spatialer Abfrage, weil eben gefunden: Diese PLZ-Grenze https://www.openstreetmap.org/relation/1109012#map=12/54.4079/9.6486 ist seit mehreren Tagen offensichtlich kaputt. Die Auswirkungen sind klar: mit dem aktuellen Datenstand kann man den Adressen keine PLZ zuordnen. Aber passt schon.
Nochmal ein Edit: @Walter: Die Fools müssten jetzt min. 37 “Irrläufer” (nach meiner Auswertung) im PLZ-Bereich 24811 anzeigen. In der Suche erhalte ich "Keine Daten für “where county = ‘Alle Bundesländer’ and (postcode like ‘%24811%’ or pnote ilike ‘%24811%’) " gefunden.” Was passt da nicht?
PS: Die PLZ-Boundary nebendran ist auch kaputt: https://www.openstreetmap.org/relation/1109011#map=13/54.4192/9.6928
Ich frage mich ja schon, wie die ganzen addr:postcode, addr:city etc. ohne mechanisches oder automatisches Mappen in die Datenbank kommt.
Da hab ich ja was losgetreten… Und bin dank der vielen gegensätzlichen Meinungen quasi genauso zwiegespalten wie vorher 
Sollte das vielleicht in einem extra Thread nochmal genauer unter die Lupe genommen werden? Vielleicht könnte das ja ein netter Admin verschieben.
Prinzipiell bin ich ja der Meinung, dass ich persönlich für die Datenbank mappe - je genauer, umso besser für Abfragen, Renderung, usw. Wenn ein Tagging tatsächlich mal überflüssig werden sollte, und zuviel Speicherplatz frisst, kann das doch genauso gut automatisiert gelöscht werden - oder?
Aber ich glaube so wie seichter es macht, ist es ein guter Kompromiss - in Nähe der Grenze sollte das “addr:country=DE” definitiv mit hin. Danke @all.
Repariert. Ich muss jetzt ins Büro.