Überarbeitung der place-Nodes Deutschland

Das postal_code=-Tag brauchen wir in Deutschland m. E. gar nicht mehr, seit wir flächendeckende postal_code-Relationen haben, die ganz Deutschland abdecken. Das kann nicht nur aus place-nodes raus, sondern auch aus allen Straßen (gibt hier und da ein paar die noch ein postal_code-Tag haben).

Die Entfernung der openGeoDB-Tags wurde bereits zuvor im Forum beschlossen. Die Dinger werden weder genutzt noch gewartet.

Prince Kassad wrote:

Die Entfernung der openGeoDB-Tags wurde bereits zuvor im Forum beschlossen. Die Dinger werden weder genutzt noch gewartet.

Sollte man dann nicht das Wiki updaten?
http://wiki.openstreetmap.org/wiki/OpenGeoDB

Gilt das nur fuer Deutschland?

Also meine Wenigkeit würde eine solche Überarbeitung sehr begrüßen. Allerdings bin ich nur ein einfacher Mapper ohne besondere Erfahrung mit der Verarbeitung dieser Daten; dazu müssen sich also die kompetenten Experten äußern. 😉

Prince Kassad wrote:

Die Entfernung der openGeoDB-Tags wurde bereits zuvor im Forum beschlossen. Die Dinger werden weder genutzt noch gewartet.

Nur "im Forum" reicht nicht. Gabs da auf den Mailinglisten auch was?

Versteht mich nicht falsch, ich brauch die Tags auch nicht und sie stören mich. Aber wenn wir sie rausnehmen wollen, dann richtig.

Die Thematik wurde ebenso im AT Forum, aber bereits als Feststelltung!: "im deutschen Forum gibt es den Standpunkt, dass OpenGeoDB obsolet ist" gepostet: https://forum.openstreetmap.org/viewtop … 73#p645973

Hier im DE Forum finde ich kleine Feststellung dieser Art.

Sofern wir aus allen Place Nodes wirklich den Tag Postleitzahl entfernen, so könnten wir ebenso auch den Gemeindenamen entfernen, denn dieser ergibt sich sogar besser als die Postleitzahl aus der Admin Relation.

Der Editor ID wäre dann überflüssig denn wenn der kleine Mapper anschließend auf www.osm.org eine Objektabfrage startet, -Beispiel einer einfachen Objekabfrage: http://www.openstreetmap.org/way/288266 … 4/12.39909-, dann bekommt er künftig keine vollständige Adresse mehr geliefert. Das macht die Bürgerbeteiligung kaputt.

Mein Fazit:
Nachdem wie oben beschrieben eine einfache Datenbankabfrage ein brauchbares Fehlerbild liefert, so kann man eine solche Abfrage auch als Korrekturgrundlage nutzen. PLZ Fehler kann man relativ einfach mittels Datenbankabfrage identifizieren und mit sehr geringem Aufwand bereinigen. Ein globales Entfernen von PLZ Zahlen verhindert übrigens nicht dass der kleiner OSM User, später solche Elemente nicht doch wieder hinzufügt.

Daher Nodes sollten möglichst vollständig alle Elemente eines Objektes beinhalten, das Entfernen von Postleitzahlen schadet dem OSM als kollaboratives Projekt, und ist daher strikt abzulehnen.

geocodec wrote:

Die Thematik wurde ebenso im AT Forum, aber bereits als Feststelltung!: "im deutschen Forum gibt es den Standpunkt, dass OpenGeoDB obsolet ist" gepostet: https://forum.openstreetmap.org/viewtop … 73#p645973

Sollte ich das missverstaendlich geschrieben haben, so tut mir das sehr leid. Ich meinte damit einfach nur, dass es den Standpunkt gibt und wollte nicht als Fuersprecher fuer das deutsche Forum auftreten, oder verkaufen wollen, dass alle im deutschen Forum so denken. Ich hatte ja sogar auf diesen Thread hier verlinkt.

Auch wenn ich geocodecs Thread "Wozu OSM" gerne gelesen habe, moechte ich diese (derzeit im AT Forum kaum vorhandene Diskussion) gerne in (m)einem eigenstaendigen Thread belassen.

Gppes wrote:

geocodec wrote:

Die Thematik wurde ebenso im AT Forum, aber bereits als Feststelltung!: "im deutschen Forum gibt es den Standpunkt, dass OpenGeoDB obsolet ist" gepostet: https://forum.openstreetmap.org/viewtop … 73#p645973

Sollte ich das missverstaendlich geschrieben haben, so tut mir das sehr leid. Ich meinte damit einfach nur, dass es den Standpunkt gibt und wollte nicht als Fuersprecher fuer das deutsche Forum auftreten, oder verkaufen wollen, dass alle im deutschen Forum so denken. Ich hatte ja sogar auf diesen Thread hier verlinkt.

Auch wenn ich geocodecs Thread "Wozu OSM" gerne gelesen habe, moechte ich diese (derzeit im AT Forum kaum vorhandene Diskussion) gerne in (m)einem eigenstaendigen Thread belassen.

Sofern jemand eine geoDatenbank ohne Redundanzen möchte, so kann er gerne einen Abzug von OSM nehmen und daraus mit Verweis auf "Datenteile entnommen aus OSM" sein eigenes propreitäre Geo-Projekt weiterentwickeln.

Jetzt aber OSM zu biegen und für den kleinen Mapper dadurch kaputt zu machen, und sich dann später wenn es keinen einzigen kleinen Mapper mehr gibt, in eine Abspaltung zu vertschüssen, halte ich für unfair.

geocodec wrote:

Die Thematik wurde ebenso im AT Forum, aber bereits als Feststelltung!: "im deutschen Forum gibt es den Standpunkt, dass OpenGeoDB obsolet ist" gepostet: https://forum.openstreetmap.org/viewtop … 73#p645973

Hier im DE Forum finde ich kleine Feststellung dieser Art.

In https://forum.openstreetmap.org/viewtopic.php?id=17293 hat mindestens keiner groß widersprochen.

+1 für das Löschen der openGeoDB:*-Einträge (wenn man drüberstolpert) an den place-Nodes, genauso wie das IMHO überflüssige is_in.

dooley wrote:

+1 für das Löschen der openGeoDB:*-Einträge (wenn man drüberstolpert) an den place-Nodes, genauso wie das IMHO überflüssige is_in.

is_in finde ich alsbald überflüssig wenn in einer Region sämtliche Straßen an den Grenz Relationen sauber abgeschlossen sind.
Genau das habe ich in meinem Bezirk in den letzten Monaten erledigt. http://www.openstreetmap.org/way/150170 … 1/12.31580

Einfach so "is_in" zu löschen, finde ich hingegen unverantwortlich.

geocodec wrote:

Einfach so "is_in" zu löschen, finde ich hingegen unverantwortlich.

Redundanz führt früher oder später zu Inkonsistenz der Daten. OSM ist in erster Linie eine Datenbank. Daraus folgere ich, dass die Grundsätze von Datenbanken eingehalten werden sollten. So ziemlich das erste, was man als Datenbankler lernt, ist die Normalisierung der anfallenden Daten in die ersten Normalform, um eben Redundanz zu vermeiden.

Die Redundanz hier entsteht durch das Vorhandensein übergeordneter Ebenen (landuse, administrative Areas etc.). Für so ziemlich jeden place-Node kann durch spatiale Abfragen die übergeordnete Ebene festgestellt werden. Und genau diese werden auch gepflegt (Namensänderungen etc.) - wer denkt daran, die place-Nodes innerhalb entsprechend zu durchsuchen und ggf. die is_in zu ändern? Und schon haben wir unnötigerweise inkonsistene Daten.

Daher finde ich es in keiner Weise unverantwortlich, is_in zu entfernen.

dooley wrote:

geocodec wrote:

Einfach so "is_in" zu löschen, finde ich hingegen unverantwortlich.

Redundanz führt früher oder später zu Inkonsistenz der Daten. OSM ist in erster Linie eine Datenbank. Daraus folgere ich, dass die Grundsätze von Datenbanken eingehalten werden sollten. So ziemlich das erste, was man als Datenbankler lernt, ist die Normalisierung der anfallenden Daten in die ersten Normalform, um eben Redundanz zu vermeiden.

Allein Datenbank? Dem muss ich wiedersprechen. OpenStreetMap ist in erstere Linie ein Kollaboratives Projekt. Datentechnik dient der Unterstützung und ist keinesfalls Selbstzweck.
Wie unterstützende Werkzeuge -nur ein kleiner Auszug:- https://tools.geofabrik.de/, oder http://regio-osm.de/, https://thomaskonrad.at/ eindrucksvoll belegen, liegt die Hauptarbeit Tausender Mapper immer noch im Erfassen von Daten, hingegen bereits wenige Kontrollwerkzeuge genügen um Redundanzen im Zaum zu halten.

Du möchtest also die "Schafherde" der Mapper wegrationalisieren, weil Du eine schöne Datenbank möchtest.

Datenbanken füllen sich nicht von selbst.

geocodec wrote:

Du möchtest also die "Schafherde" der Mapper wegrationalisieren

Wer hat das wann gesagt? Kennst du einen einzigen Mapper, der sagt: „Och, wenn ich kein is_in mehr setzen darf, dann mache ich nicht mehr mit“?
Bitte keine Strohmänner aufbauen.

--ks

geocodec wrote:

Du möchtest also die "Schafherde" der Mapper wegrationalisieren, weil Du eine schöne Datenbank möchtest.

Mit Verlaub, das ist Bullshit. Ich möchte konsistente Daten und keinen Datenmüll. Und das wars dann auch mit der Diskutiererei mit dir, diese Unterstellungen brauche ich mir nicht anzutun.

geocodec wrote:

is_in finde ich alsbald überflüssig wenn in einer Region sämtliche Straßen an den Grenz Relationen sauber abgeschlossen sind.

+1

Einfach so "is_in" zu löschen, finde ich hingegen unverantwortlich.

Würde ich mal so drastisch nicht ausdrücken. Man sollte nur nicht vergessen, das das deutsche OSM sicher zu den bestgepflegtesten gehört, was boundary angeht. Die Ortsnodes stammen natürlich aus vergangenen Jahren und sind immer noch vielerorts nicht günstig platziert, unvollständig und nicht eindeutig z.B. als Ortsteil einer Gemeinde spezifiziert. Da viele Mapper (auch im Ausland) evtl. unser deutsches Tagging als Vorgabe betrachten könnten (Vermutung), wäre es bestimmt nicht gut, die Ortsnodes "abzuspecken", die noch vor wenigen Jahren Standard waren. Wir in Deutschland sollten nicht so "hochnäsig" sein, und einleuchtendes Standard-Tagging einfach umbauen. Viele Mapper sind froh um solche Strohhalme.

dooley wrote:

Mit Verlaub, das ist Bullshit. Ich möchte konsistente Daten und keinen Datenmüll. Und das wars dann auch mit der Diskutiererei mit dir, diese Unterstellungen brauche ich mir nicht anzutun.

Österreicher belehrt Deutsche im Deutschen Forum. Die Emotionen gehen hoch.
Ich denke wir sprechen in unseren Sprachfarben aneinander vorbei, haben aber als OSM Mitwirkende sicher mehr Gemeinsamkeiten als trennendes.

Rogehm wrote:

geocodec wrote:

is_in finde ich alsbald überflüssig wenn in einer Region sämtliche Straßen an den Grenz Relationen sauber abgeschlossen sind.

+1

@Rogehm: Was genau haben an den Grenzrelationen sauber abgeschlossene Straßen mit dem Vorhandensein oder Nichtvorhandensein von is_in an place-Nodes zu tun? Da hätte ich gerne eine einleuchtende Erklärung - wie man da einen Zusammenhang herstellen kann, ist mir nicht klar.

Dass man die is_in dort nicht entfernt, wo man auf andere Weise nicht an die Daten kommt (also keine Redundanz gegeben ist), ist ja klar.

"auf andere Weise nicht drankommt": Das ist etwas, was mich etwas stört, das man nicht auf "Mausklick" in den Editoren dran kommt. Da wünsche ich mir in JOSM (und ID, Potlach, ...) einen Button, der mir dann anzeigt was "unter" dem mich interessierenden Punkt liegt. Ähnlich dem "?" auf openstreetmap mit den "umschließende Objekte". Aber das ist ein anderes Thema.

dooley wrote:

Da wünsche ich mir in JOSM (und ID, Potlach, ...) einen Button, der mir dann anzeigt was "unter" dem mich interessierenden Punkt liegt.

Das kann der Editor allerdings erst dann ermitteln, wenn er die betreffende umgebende Grenzrelation auch vollständig im Speicher hat. Wenn er keine Onlinequellen anzapfen will.

--ks

dooley wrote:

geocodec wrote:

Einfach so "is_in" zu löschen, finde ich hingegen unverantwortlich.

Redundanz führt früher oder später zu Inkonsistenz der Daten. OSM ist in erster Linie eine Datenbank. Daraus folgere ich, dass die Grundsätze von Datenbanken eingehalten werden sollten. So ziemlich das erste, was man als Datenbankler lernt, ist die Normalisierung der anfallenden Daten in die ersten Normalform, um eben Redundanz zu vermeiden.

Die Redundanz hier entsteht durch das Vorhandensein übergeordneter Ebenen (landuse, administrative Areas etc.). Für so ziemlich jeden place-Node kann durch spatiale Abfragen die übergeordnete Ebene festgestellt werden. Und genau diese werden auch gepflegt (Namensänderungen etc.) - wer denkt daran, die place-Nodes innerhalb entsprechend zu durchsuchen und ggf. die is_in zu ändern? Und schon haben wir unnötigerweise inkonsistene Daten.

Daher finde ich es in keiner Weise unverantwortlich, is_in zu entfernen.

Der Kern von OSM ist eine DB, aber OSM ist mehr. Dazu gehören auch die vielen Auswerte- und Renderprogramme (Karten).
Erst sie machen aus einem Datenhaufen ein für viele attraktives System.

Redundanz ist für eine DB eine potentielle Quelle von Inkonsistenz und daher zu vermeiden, bei einem kooperativem Projekt ohne zentrale Steuerung ist Normalisierung aber Illusion.

Redundanz hat auch eine zweite Seite: Der einfachere Zugriff auf Information, wenn nur Teile der DB (sprich: kleiner Ausschnitt) geladen sind. Ein Beispiel dafür ist die vollständige Postadresse an einem POI, die die Regel ist.
Hausnummer ist unumstritten, aber schon bei der Straße gehen die Redundanzprobleme los. Eckhäuser können meist nicht automatisch einer Straße zugeordnet werden, aber Straßenname am way und am POI können auseinanderlaufen.

Ich halte das is_in-Tagging auch für überholt und verwende es nie. Löschen würde ich es aber nur, wenn es dafür einen allgemeinen Konsens (siehe landuse=farm) gibt und gewährleistet ist, dass keine Information vernichtet wird.

seichter wrote:

Ein Beispiel dafür ist die vollständige Postadresse an einem POI, die die Regel ist.
Hausnummer ist unumstritten, aber schon bei der Straße gehen die Redundanzprobleme los. Eckhäuser können meist nicht automatisch einer Straße zugeordnet werden, aber Straßenname am way und am POI können auseinanderlaufen.

Adressen...

Die Zugehörigkeit des Straßennames (wie auch der Postleitzahlen) kann man nicht immer eindeutig durch spatiale Abfragen feststellen.

A␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣B
A␣-------------------␣B
A␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣|␣␣␣Grundstück␣␣␣␣|␣B
A␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣|␣Haus␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣|␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣|␣B
A␣-------------------␣B
A␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣␣B

Gehört das Haus zur Straße A oder zur Straße B? Eine Bestimmung durch spatiale Abfragen ergibt Straße A, es gehört aber zu Straße B. Daher ist der Straßenname zwar redundant, dieser ist aber nicht entbehrlich, weil keine eindeutige Zuordnung gegeben ist. Die Redundanz hier ließe sich nur vermeiden, indem man die Adressen per Relation an die Straße hängt. Bei Straßen mag das noch praktikabel sein, bei Postleitzahlen nicht mehr (im Sinne vom Handling in den Editoren). Von daher gibt es nicht immer den Königsweg.

Es ist wie immer im Leben, man muß abwägen. Stumpf "überflüssiges" zu löschen, halte auch ich für falsch.

Ich kenne übrigens keinen Renderer oder ein Auswerteprogramm, welches "is_in" auswertet, das dürfte ohne größere Verrenkungen auch ziemlich schwierig sein. Eine Verifizierung ist AFAIK im Moment nur durch manuelle Sichtung möglich.

Moin,

ihr könne ja mal folgende Query probieren, die alle Knoten mit is_in Tags anzeigt. Zusätzliches wird auch ein is_in_boundary-Tag mit ausgegeben, das die is_in auf Basis der existierenden administrativen Grenzen direkt ermittelt. Einfach um mal eine Idee dafür zu bekommen, wie redundant is_in wirklich ist.

http://overpass-turbo.eu/s/p6D

Beispiel

␣<node␣id="260440481">
<tag␣k="is_in"␣v="Großostheim"/>
<tag␣k="name"␣v="Pflaumheim"/>
<tag␣k="place"␣v="village"/>
<tag␣k="postal_code"␣v="63762"/>
<tag␣k="is_in_boundary"␣v="{2:Deutschland};{4:Bayern};{5:Unterfranken};{6:Landkreis␣Aschaffenburg};{8:Großostheim}"/>
</node>

geocodec wrote:

Österreicher belehrt Deutsche im Deutschen Forum. Die Emotionen gehen hoch.

Was hat das jetzt mit Österreicher und Deutschen zu tun? Haben wir jetzt etwa rassistische Vorurteile schon zwischen D und AT? Oder will jemand umgekehrt „den Deutschen“ generell solche Vorurteile unterstellen? Das ist doch alles Unsinn. Ich (als Deutscher) lasse mich sehr gerne von einem Österreicher, Syrer, Nigerianer, Inuit, … belehren, wenn derjenige es eben besser weiß als ich; ich würde mich aber nicht gerne von Personen belehren lassen, die es nicht besser wissen (auch nicht, wenn diese Personen Deutsche sind).

Rogehm wrote:

geocodec wrote:

is_in finde ich alsbald überflüssig wenn in einer Region sämtliche Straßen an den Grenz Relationen sauber abgeschlossen sind.

+1

Einfach so "is_in" zu löschen, finde ich hingegen unverantwortlich.

Würde ich mal so drastisch nicht ausdrücken. Man sollte nur nicht vergessen, das das deutsche OSM sicher zu den bestgepflegtesten gehört, was boundary angeht. Die Ortsnodes stammen natürlich aus vergangenen Jahren und sind immer noch vielerorts nicht günstig platziert, unvollständig und nicht eindeutig z.B. als Ortsteil einer Gemeinde spezifiziert. Da viele Mapper (auch im Ausland) evtl. unser deutsches Tagging als Vorgabe betrachten könnten (Vermutung), wäre es bestimmt nicht gut, die Ortsnodes "abzuspecken", die noch vor wenigen Jahren Standard waren. Wir in Deutschland sollten nicht so "hochnäsig" sein, und einleuchtendes Standard-Tagging einfach umbauen. Viele Mapper sind froh um solche Strohhalme.

Ich verstehe Ortsnodes als Notnagel in Gegenden wo es keine Bounderies gibt. Falls das deutsche OSM Vorbild ist, dann sollte es die Ortsnodes "abspecken" und nur da belassen, wo es keine Bounderies gibt. Den Bounderies + Ortsnodes ist nicht vorbildlich.

Außerdem sollte im Wiki dargestellt warden, dass es eine Priorisierung zwischen Ortsnodes und Boundaries gibt.

hfst wrote:

Ich verstehe Ortsnodes als Notnagel in Gegenden wo es keine Bounderies gibt. Falls das deutsche OSM Vorbild ist, dann sollte es die Ortsnodes "abspecken" und nur da belassen, wo es keine Bounderies gibt. Den Bounderies + Ortsnodes ist nicht vorbildlich.

Ich habe da ein Verstaendnis Problem: Aus meiner Sicht kann ich unmoeglich jede "Ortschaft" als 2D-Objekt mit Hilfe von Boundaries abbilden!?

Meiner Vermutung nach ist in AT die kleinste in OSM [EDIT: als 2D-Objekt] umgesetzte (und meiner Meinung nach sinnvolle) Einheit die Gemeinde, welche aber durchaus aus mehreren Ortschaften (teilweise Kaffs, die aus drei Haeuserln bestehen) bestehen. Diese Ortschaften haben alle Place-Nodes und ich haette keine Ahnung, wie ich daraus ein sinnvolles Flaechenobjekt machen koennte - wo verlaufen die Grenzen genau? Das waere kompliziert.

War hier auf Besuch:
http://www.openstreetmap.org/search?que … 45/12.4026

Das ist in Deutschland, einfach zufaellig ein Kaff raus gepickt, dort werden auch Place Nodes verwendet.

Lg, Gppes

PS.: Mir sind Posting-Ursprungs-Nationen auch Wurscht! :-)

mmd wrote:

http://overpass-turbo.eu/s/p6D

Das ist eine ganz hervorragende overpass-Abfrage, vielen Dank dafür!

Gppes wrote:

… ich haette keine Ahnung, wie ich daraus ein sinnvolles Flaechenobjekt machen koennte - wo verlaufen die Grenzen genau? Das waere kompliziert.

Manche sind der Auffassung, dass sämtliche Ortschaften auch eine Grenze haben müssen, egal wie klein sie sind. Das führt dann zu fiktiven Grenzziehungen wie hier: https://www.openstreetmap.org/#map=13/51.8690/11.8647.
Wer hier Aufräum-Versuche unternimmt hat nicht nur enorm viel Arbeit, sondern muß sich hinterher auch noch für das von ihm verursachte Ortsteilgrenzen-Massensterben verantworten.

CKorsmeier wrote:

Gppes wrote:

… ich haette keine Ahnung, wie ich daraus ein sinnvolles Flaechenobjekt machen koennte - wo verlaufen die Grenzen genau? Das waere kompliziert.

Manche sind der Auffassung, dass sämtliche Ortschaften auch eine Grenze haben müssen, egal wie klein sie sind. Das führt dann zu fiktiven Grenzziehungen wie hier: https://www.openstreetmap.org/#map=13/51.8690/11.8647.
Wer hier Aufräum-Versuche unternimmt hat nicht nur enorm viel Arbeit, sondern muß sich hinterher auch noch für das von ihm verursachte Ortsteilgrenzen-Massensterben verantworten.

+1

Das ist ein sehr deutliches Beispiel fuer mein Empfinden zu diesem Thema! Hatte ich ja gar nicht geschrieben. Areas sind natuerlich immer wesentlich komplexer!

Lg, Gppes

PS.: Sorry mein Beispiel mit den Place-nodes:
http://www.openstreetmap.org/#map=16/48.8249/12.4054
sollte das hier sein, habe nur gleich eine Nominatim-Suche auf eine angrenzende Adresse getestet.

PPS.: Off topic (Areas, Ways, Nodes): Auch wegen der Komplexitaet predige ich fuer den Einsatz von "natural=tree_row" anstatt ein "natural=wood" oder "landuse=forest" um eine einzelne Baumreihe zu "wickeln". Im Area-Fall kommen dann auch oft sehr interessante oder komplexe Gebilde raus!

Gppes wrote:

hfst wrote:

Ich verstehe Ortsnodes als Notnagel in Gegenden wo es keine Bounderies gibt. Falls das deutsche OSM Vorbild ist, dann sollte es die Ortsnodes "abspecken" und nur da belassen, wo es keine Bounderies gibt. Den Bounderies + Ortsnodes ist nicht vorbildlich.

Ich habe da ein Verstaendnis Problem: Aus meiner Sicht kann ich unmoeglich jede "Ortschaft" als 2D-Objekt mit Hilfe von Boundaries abbilden!?

Ja und? Wenn's keine Bounderies gibt (weil nicht sinnvoll erstellbar) nimmt man halt place. Aber ich halte es für nicht sinnvoll place und boundaries gleichzeitig zu verwenden.

hfst wrote:

Ja und? Wenn's keine Bounderies gibt (weil nicht sinnvoll erstellbar) nimmt man halt place. Aber ich halte es für nicht sinnvoll place und boundaries gleichzeitig zu verwenden.

Ach so war das gemeint. Alles klar.

Ich habe auf nominatim einen Bugreport erstellt, weil manche Adressen mit address:place nicht gefunden werden. Als Loesung wurde mir unter anderem vorgeschlagen, eine 2D boundary zu machen. Deshalb die Detailfrage. Genau dort macht es aus meiner Sicht naemlich auch keinen Sinn.

Gppes wrote:

Meiner Vermutung nach ist in AT die kleinste in OSM [EDIT: als 2D-Objekt] umgesetzte (und meiner Meinung nach sinnvolle) Einheit die Gemeinde, welche aber durchaus aus mehreren Ortschaften (teilweise Kaffs, die aus drei Haeuserln bestehen) bestehen. Diese Ortschaften haben alle Place-Nodes und ich haette keine Ahnung, wie ich daraus ein sinnvolles Flaechenobjekt machen koennte - wo verlaufen die Grenzen genau? Das waere kompliziert.

Darum geht es ja jetzt eben nicht, aus place-Nodes place-Boundaries zu machen. Es geht darum, dass die place-Nodes einen key "is_in" haben, der durch geeignete Abfragen der umgebenden Grenzen praktisch überflüssig ist, sofern diese vorhanden sind. @mmd hat eine Overpass-Abfrage zur Verfügung gestellt, mit der man sehr schön nachschauen kann, ob is_in überflüssig ist oder nicht.

is_in hat keinerlei Aussagewert (zumindest für Ortsfremde), weil man nicht ohne weiteres feststellen kann, um was es sich bei den Buchstabenfolgen handelt. Beispiel Saladorf in Niederösterreich:

<tag␣k="is_in"␣v="Würmla,Tulln,Niederösterreich,Österreich,Europe"/>
<tag␣k="name"␣v="Saladorf"/>

Was sagt der Inhalt von is_in aus? Saladorf gehört anscheinend u.a. zu Würmla. Was aber ist Wümla? Ein Regierungsbezirk, eine Stadt, ein Stadtteil, ein Bundesland? Ich kann das nicht sagen, weil ich mich in Österreich nicht auskenne.

Mit einer spatialen Abfrage, z.B. https://overpass-turbo.eu/s/p6U (1) bekommt man Auskunft (aufgedröseltes is_in_boundaries):

administrativer␣Level␣8:␣Gemeinde␣Würmla
administrativer␣Level␣6:␣Bezirk␣Tulln
administrativer␣Level␣4:␣Niederösterreich
administrativer␣Level␣2:␣Österreich

Wenn ich jetzt noch weiß, was die einzelnen administrativen Level in dem jeweiligen Staat/Bundesland bedeuten, kann ich damit wirklich etwas anfangen. Mit der reinen Aufzählung von Namen in is_in nicht.

(1) overpass-Query von mmd erweitert, so das nur places mit is_in berüchsichtigt werden.

dooley wrote:

[...]
Mit einer spatialen Abfrage, z.B. https://overpass-turbo.eu/s/p6U (1) bekommt man Auskunft (aufgedröseltes is_in_boundaries):

[...]

Danke fuer die Erklaerungen, der Link funktioniert bei mir nicht, ich kriege nur ein Beispiel mit Trinkwasserspendern in Rom!?

Gppes wrote:

dooley wrote:

[...]
Mit einer spatialen Abfrage, z.B. https://overpass-turbo.eu/s/p6U (1) bekommt man Auskunft (aufgedröseltes is_in_boundaries):

[...]

Danke fuer die Erklaerungen, der Link funktioniert bei mir nicht, ich kriege nur ein Beispiel mit Trinkwasserspendern in Rom!?

Puh... ist dachte schon bei mir ist was...

irgendwas ist bei overpass Turbo... die zuletzt eingegebene Abfrage wird ausgeführt... hhab es gerade manuell getestet... über wizard landuse=forest ausgeführt, Tab mit Overpass-Abfrage geschlossen, Link angeklickt, diese eben durchgeführte Abfrage kam wieder...

Sven

streckenkundler wrote:

irgendwas ist bei overpass Turbo... die zuletzt eingegebene Abfrage wird ausgeführt... hhab es gerade manuell getestet... über wizard landuse=forest ausgeführt, Tab mit Overpass-Abfrage geschlossen, Link angeklickt, diese eben durchgeführte Abfrage kam wieder...

Sven

Hm, hab den Link eben nochmal aufgerufen, bei mir gehts... Sollte irgendwo westlich Wien rauskommen, das spielt aber auch keine Rolle. Die Karte an den gewünschten Ort schieben und die Abfrage ausführen, das sollte gehen?

node({{bbox}})[is_in][place];
foreach(
is_in->.a;
area.a[name][boundary=administrative][admin_level~"^[2-8]$"]␣->␣.a;
convert␣node␣::=::,
::id␣=␣id(),
is_in_boundary␣=a.set("{"␣+␣t[admin_level]␣+␣":"␣+␣t[name]␣+␣"}");

out;
);

Habt ihr zufällig NoScript installiert?

mmd wrote:

Habt ihr zufällig NoScript installiert?

ja... hatte damit eigentlich nie Probleme...

Gibt es eine spezielle Regel? Die Seiten overpass.turbo.eu und overpass-api.de sind jedenfalls auf der Positiv-Liste.

Sven

Also seit ein paar Tagen habe ich auch massiv Probleme damit, ich weiß allerdings noch nicht genau was da los ist. Evtl schlägt die xss Protection da zu. Mit Chrome klappts aber.

mmd wrote:

Evtl schlägt die xss Protection da zu.

anscheinend ja... habe den Haken bei "Anfragen bei Verdacht auf Cross-Site Scripting bereinigen" rausgenommen, nun kommt der Link in Niederösterreich raus...

Sven

place ist doch ganz sinnvoll um manuell das siedlungsortszentrum für den renderer festzulegen. stell dir vor, eine gemeinde besteht aus 3/4 wald und 1/4 siedlung, das aber nur ganz im östlichen gemeindegebiet angesiedelt ist. wo würde auf der karte der gemeindename auftauchen, mitten im wald natürlich.

hier ein anderes beispiel wo im nördlichen bereich nur landwirtschaft ist und ganz im süden die eigentliche siedlung worum es geht:
https://www.openstreetmap.org/relation/ … 887/8.4509

in dem fall wo gemeinde gleich ort ist, muss das place node mit der rolle=admin_centre in die admin-relation. wäre hier auch name=* überflüssig und kommt aus der relation? wo das place-node nur eine ortsbeschreibende funktion hat steht es selbstständig.

ich glaub ich weiche gerade ein bisschen aus dem redestrang ab und mehr zusammenfassend zu dem thema

Für mich bedeutet
wenn künftig eine einfache Objektabfrage auf OSM.org nicht mehr sämtliche Elemente

einer normalen vollständigen Postadresse

liefert, dass das zugleich das Ende von OSM als Kollaboratives Projekt mit sich bringt.

Wer unbedingt und mit aller Gewalt OpenStreetMap zerstören möchte, der kann dieser Initiaitive folgen.

Chenshi wrote:

place ist doch ganz sinnvoll um manuell das siedlungsortszentrum für den renderer festzulegen.

Dafür gibt es ja auch die Rolle label in der boundary-Relation. Prinzipiell kann man das place-Node als eben dieses label in die Relation mit reinnehmen.

geocodec wrote:

Für mich bedeutet
wenn künftig eine einfache Objektabfrage auf OSM.org nicht mehr sämtliche Elemente

einer normalen vollständigen Postadresse

liefert, dass das zugleich das Ende von OSM als Kollaboratives Projekt mit sich bringt.

Wer unbedingt und mit aller Gewalt OpenStreetMap zerstören möchte, der kann dieser Initiaitive folgen.
Wer unbedingt und mit aller Gewalt OpenStreetMap zerstören möchte, der kann dieser Initiaitive folgen.
Wer unbedingt und mit aller Gewalt OpenStreetMap zerstören möchte, der kann dieser Initiaitive folgen.

Was willst Du uns damit sagen ?

geocodec wrote:

wenn künftig eine einfache Objektabfrage auf OSM.org nicht mehr sämtliche Elemente einer normalen vollständigen Postadresse liefert, dass das zugleich das Ende von OSM als Kollaboratives Projekt mit sich bringt

Was meinst du damit? In DE findet man mit Nominatim (sämtliche eingetragene) Adressen mit vollständiger Postadresse.
Bin der Meinung, die "is_in"-tags sollte man nicht anrühren. Im mindesten Fall dient der Tag immer noch dazu, auf einfache Weise Geoinformationen zu erhalten, wenn man sich ( in DE!) für einen kleinen Ort oder einen Weiler interessiert und diesen in OSM direkt lokalisiert. Natürlich sind dies bessere Informationen, wenn die Boundaries unkorrekt sind (Sicher oft auf der Welt!). Aber die beiden Abfragen sollten deckungsgleich sein im optimalen Fall. Ich sehe dies als Gegenkontrolle. Man muss sich also nur kümmern bei Abweichungen.
Mit der Bitte, die "is_in" tags nicht zu löschen, sondern vielmehr zu korrigieren. Danke euch.

geocodec wrote:

wenn künftig eine einfache Objektabfrage auf OSM.org nicht mehr sämtliche Elemente einer normalen vollständigen Postadresse liefert, dass das zugleich das Ende von OSM als Kollaboratives Projekt mit sich bringt.

Das wäre nur dann logisch, wenn OSM dadurch für jeden Anwender komplett unbrauchbar würde – denn „Ende als kollaboratives Projekt“ kann doch nur bedeuten, dass es keine interessierte Community mehr gibt. Aber warum sollte es? OSM ist doch keine Adressdatenbank. Freilich ist es „nett“, gleich aus OSM alle Kontakt- und Adressdaten zu bekommen, wenn man sie mal haben möchte. Aber als Geodatenbank ist OSM für mich auch dann schon wertvoll, wenn ich „nur“ die Information, was da ist, sowie die Geoposition bekomme. Für vollständige Postadressen gibt es im Zeitalter ständig verfügbarer Datenanbindung andere Quellen, das ist in OSM für mich eher ein „nice to have“.

Für mich ist OSM deshalb wertvoll, weil ich überall, wo ich bin, sehen kann, wie meine Umgebung aussieht, wo die Straßen und Wege hinführen, und was da so angeboten wird. Für mich ist OSM wertvoll, weil ich in einer fremden Stadt, wenn sich mein Hund eine Pfote an einer Glasscherbe aufreißt (Idioten, die es sinnvoll finden, Bierflaschen auf Gehwegen zu zertrümmern und den Müll liegenzulassen, gibt es ja überall), in OsmAnd nach „Tierarzt“ suchen und mir dann auch gleich den Weg dahin anzeigen lassen kann. Dessen ladungsfähige Postadresse brauche ich dazu nicht, Länge und Breite reicht. Für mich ist OSM wertvoll, weil ich damit eine aktuelle Abbildung der baulichen und verkehrsmäßigen Strukturen in der Tasche habe, die es mir unschätzbar erleichtert, mich zurechtzufinden. Das ist für mich der Sinn einer Geodatenbank.

geocodec wrote:

Wer unbedingt und mit aller Gewalt OpenStreetMap zerstören möchte, der kann dieser Initiaitive folgen.

Das läuft auf „Wer anderer Meinung ist als ich, ist bösartig“ hinaus und darf wohl als radikale Ansicht bezeichnet werden. So was hätte ich eher von Pegida-Kundgebungen erwartet als hier im Forum.

--ks

Umkreissuche ist doch nett.

Auf meinem PC läuft ebenso eine hochwertige Esri Umgebung. Leider gibt es bei dieser einen lizenbedingtes Timeout, in OSM gelangt man daher jeweils um entscheidende Sekunden schneller in die geografische Übersicht. Ich habe übrigens noch nicht verstanden warum ich eine restriktive Lizenzbarriere für Trivial Abfragen hinnehmen soll.

Geschwindigkeit bedeutet, dass ich für Trivial-Abfragen nicht ganze Regionen in den Speicher laden möchte.
Auf lokaler Ebene hat sich gezeigt dass is_in gelegentlich das einzige Mittel ist, wie man gleichlautende Straßen zweier Ortschaften auseinanderhalten kann.