POI nicht als Polygon eintragen!

moenk wrote:

Darum erfasse ich POI nur als Punkte. Und nun seid Ihr dran ;-)

Das darfst Du. Jeder so wie er mag.

Es gibt sicher auch Argumente für Flächen-POIs.

Ein Aldi ist nunmal kein Punkt sondern ein flächenhaftes Etwas. ;-)

Wenn die Eigenschaften das komplette Gebäude betreffen, zum Beispiel beim oben genannten Aldi, Schulen, Hotels usw., setze ich die Eigenschaften immer auf die Fläche. Wenn ich doppelt gemappte Pois entdecke (keepright meckert), einmal als POI und einmal auf der Fläche, habe ich bisher den POI immer gelöscht.

Ich sehe es eigentlich genauso wie meine beiden Vorposter. Ein POI kann eine Fläche sein. Ein Restaurant ist immerhin kein Punkt, sondern vermutlich ein ganzes Haus, oder ein Teil dessen. Zumindest hat es eine Ausdehnung. Wir würden viel Informationen verlieren, wenn wir das alles nur als einen Punkt mappen (Name "Point of Interest" ist dabei irrelevant. Nenne es in Zukunft doch "Polygon of Interest" 😉). Dabei meine ich, dass vielleicht mal jemand kommt und fragt, wie viel m² Verkaufsfläche ALDI wohl hat (OK, ausm Hut gezogen, aber mit Fantasie lässt sich da was machen). Ich denke eher, Punkte mappen ist falsch, weil das gibt die Realität einfach weniger wieder. Und OSM will die Realität darstellen. Willst du den Eingang von ALDI, dann mappe ihn doch mit entrance = yes. Und fertig 🙂

In puncto Einfachheit gebe ich dir allerdings Recht. Irgendwie. Letztlich ist das aber eher eine Frage der API (vielleicht sollte es eine einfache Möglichkeit der Abfrage geben: "Gib mir alle POIs eines Typs" liefert vielleicht auch die Zentroide der Polygone mit... Als erster naiver Ansatz. Und dann hast du wieder deine Punktsammlungen). Ich bleibe dabei: Sicherlich ist durch den Ansatz "Realität mappen" nicht immer allen in optimaler Weise geholfen, aber daran sollten wir uns doch eher halten als an "möglichst einfach auszuwerten".

moenk wrote:

Aber ich finde es nicht richtig und wird der Natur eines POI (der "Punkt" ist hier schon Teil des Namens) auch nicht gerecht. Der POI wird impliziert als Zentroid eines Polygons gemappt. Das ist unnötig kompliziert.

Dann redefiniere ich jetzt kurzerhand die Abkürzung POI als "Point/Polygon Of Interest". Problem gelöst.

Ich finde auch, dass die Eigenschaften immer an eine Fläche gehören, es sei denn eine Fläche wäre durch unzureichende Genauigkeit der Quelle unsinnig.
Wir erstellen hier Daten, die die Geographie der Welt widerspiegeln sollen. Dazu gehört auch, dass z.B. ein Restaurant tatsächlich auch eine Fläche ist, denn es erstreckt sich über einen Bereich.
Ein Restaurant als Punkt ist lediglich eine Abstraktion davon, für wessen Erzeugung wiederum auswertende Programme zuständig sein sollen.

chris66 wrote:

Ein Aldi ist nunmal kein Punkt sondern ein flächenhaftes Etwas. ;-)

Ist eine deutschlandweite Ausbreitung. Ich setze die Info ans DE-Polygon 😄

Petja wrote:

Wenn die Eigenschaften das komplette Gebäude betreffen, zum Beispiel beim oben genannten Aldi, Schulen, Hotels usw., setze ich die Eigenschaften immer auf die Fläche. Wenn ich doppelt gemappte Pois entdecke (keepright meckert), einmal als POI und einmal auf der Fläche, habe ich bisher den POI immer gelöscht.

+1 Mach ich ganz genau so wie du 🙂

Oli-Wan wrote:

Dann redefiniere ich jetzt kurzerhand die Abkürzung POI als "Point/Polygon Of Interest". Problem gelöst.

+1 Gute Idee, wäre ja nicht die erste Definition die mit der Zeit gehen muss 😄

Moin,

bleiben wir mal bei dem Restaurant. Das ist zunächst mal nur ein Gebäude, das kann man auch so mappen. Damit bilden wir die Realität doch gut ab? Was darin nun passiert, also die Nutzung muss doch nicht an das Gebäude gebunden werden. Ja, man kann das, das sieht man auch oft, ich stelle aber genau das zur Diskussion. Es gibt praktische Gründe, das nicht zu tun. Es ist nicht schlechter, den POI als Punkt zu setzen, macht aber einiges einfacher. Warum die Attribute zum Gebäude, wo ist der Vorteil?

LG,

-moenk

Das Gebäude ist ein Hotel -> in diesem ist eine öffentliche Gaststätte. building=hotel mit name, phone, website, addr:... und Gaststätte ist ein node mit phone, website, ... (falls abweichend) - In dem Hotel gibt es noch einen Frisör ... ( noch ein POI)

Moin Geri,

Du zeigst mit Deinem Beispiel genau auf, warum die gängige Praxis Käse ist. Das Gebäude ist ein Gebäude und das hat ganz andere Attribute, die nicht vermischt werden sollten. Darin sind die POI, die sich sogar verorten lassen. Über den Stuss mit building oder area gleich yes oder sonstwas werde ich mich an dieser Stelle nicht weiter aufregen, das hat sich mit einer neuen API hoffentlich auch erledigt.

LG,

-moenk

moenk wrote:

Es ist nicht schlechter, den POI als Punkt zu setzen, macht aber einiges einfacher.

Für unausgereifte Anwendungen, die nur mit Punkten umgehen können, besteht ja die Möglichkeit, die Umwandlung Weg/Relation -> Knoten nach dem Herunterzuladen durchzuführen. osmconvert ermöglicht das schon out-of-the-box mit der Option --all-to-nodes; und ich würde mich nicht wundern, wenn mittelfristig auch die eierlegende Wollmilchsau genannt Overpass API ähnliches anbieten würde. Ich sehe nicht, warum OSM seine Abbildung der Realität kastrieren sollte, um einigen unbedarften Nutzern zwei Zeilen Code zu ersparen.

Oli-Wan wrote:

Ich sehe nicht, warum OSM seine Abbildung der Realität kastrieren sollte, um einigen unbedarften Nutzern zwei Zeilen Code zu ersparen.

Oli-Wan,

es geht doch erstmal nicht um Anwendungen, sondern um ein sauberes Datenmodell. Mir kommts auch gleich wieder hoch wenn ich die Arroganz in Deinem Zeilen da herauslese. Sollen die anderen doch sehen wie sie mit unserem Murks klar kommen, wir machen das so wie wir das praktisch finden, gibt doch hier ein Tool und da eine Funktion, alles ganz einfach, sind doch nur zwei Zeilen Code, Pipifax, wir sind genial und ihr seid alle Pfuscher - so einfach geht das nicht!

Das ist aber auch nicht die Frage. Ich finde dass die wirtschaftliche Nutzung des Gebäudes nichts in seinen Attributen zu suchen haben muss. Vermehrt wird das aber bevorzugt so gemappt und auch als korrekt propagiert.

LG,

-moenk

moenk wrote:

es geht doch erstmal nicht um Anwendungen

moenk wrote:

Es macht den Umgang mit den Geodaten für jemand der sich für POI interessiert komplizierter als erforderlich. Wir sollten ein Interesse daran haben, dass der Umgang mit den Geodaten einfach ist. Das wird dann auch zu mehr schönen Apps und Webseiten führen, die unsere Daten nutzen, weil es einfacher ist.

Geht es nun um Anwendungen oder nicht?

moenk wrote:

Sollen die anderen doch sehen wie sie mit unserem Murks klar kommen

Wer unsere Daten nutzen will, kommt nicht umhin, sich mit dem verwendeten Datenmodell zu beschäftigen. Und auch mit der Tatsache, daß die Erfassungsarten ebenso wie die Datenqualität nun einmal sehr inhomogen sind. In der Regel wird er auch nicht daran vorbeikommen, die Daten für seine Zwecke aufzubereiten.

moenk wrote:

Das ist aber auch nicht die Frage. Ich finde dass die wirtschaftliche Nutzung des Gebäudes nichts in seinen Attributen zu suchen haben muss.

Bei einem Gebäude, das ausschließlich ein Restaurant, eine Bank, einen Supermarkt, ein Hotel, eine Hochschuleinrichtung, eine Autowerkstatt, ... beherbergt, ist das Gebäude für mich synonym mit dem jeweiligen Objekt. Wollte man Nutzung und Gebäude trennen, dürfte man konsequenterweise auch keine - postalischen! - Adressen an Gebäude taggen (siehe aktuelle Inkarnation des ewigen Themas im Nachbarfaden) - schließlich schreibt man ja den Bewohnern bzw. dem dort ansässigen Unternehmen einen Brief, nicht dem Gebäude selbst.

Oli-Wan wrote:

... osmconvert ermöglicht das schon out-of-the-box mit der Option --all-to-nodes ...

Hier ist zu beachten, das gleichzeitig alle Wege und Relationen entfernt werden.
Möglicherweise ist dies nicht das, was man möchte ...

Ansonsten halte ich es für essentiell wichtig, daß Objekte nicht doppelt erfaßt werden / sind.
Also sowohl an einem Way (Polygon) als auch an einem Node.

Gruß Klaus

Oli-Wan wrote:

Wollte man Nutzung und Gebäude trennen, dürfte man konsequenterweise auch keine - postalischen! - Adressen an Gebäude taggen (siehe aktuelle Inkarnation des ewigen Themas im Nachbarfaden) - schließlich schreibt man ja den Bewohnern bzw. dem dort ansässigen Unternehmen einen Brief, nicht dem Gebäude selbst.

Oli-wan,

genau so isses. Das Gebäude hat andere Attribute, wie Höhe, Anzahl der Stockwerke, Dach, vieles mehr. Mit der Hausnummer bin ich auch als Punkt einverstanden, ein Gebäude kann auch mehrere haben. Hier sollte vielleicht auch eine klare Vorgabe her. Das bringt uns aber etwas vom Thema ab.

Ich halte immer noch die Zuweisung der POI-Attribute an das Gebäude für falsch. Das ändert nichts daran, dass ich die Vorgehensweise anderer akzeptiere, aber das OSM-Datenmodell für dringend reformbedürftig halte. Es geht um saubere Datenstrukturen, der durch die Crowd entstandene Wildwuchs wird für mich immer unerträglicher. Aber sonst scheint sich um sowas im Forum kaum jemand Gedanken zu machen. Alle Argumente gehen für mich in die Richtung "weil man das so machen kann".

LG,

-moenk

toc-rox wrote:

Ansonsten halte ich es für essentiell wichtig, da? Objekte nicht doppelt erfaßt werden / sind. Also einmal am Polygon und zusätzlich noch einmal als POI.

Moin Klaus,

am besten nur als POI ;-)

Doppelt passiert, wir wissen alle warum, und das wird immer wieder passieren.

Danke an dieser Stelle für das Paket zum Jahresende!

LG,

-moenk

Auch, wenn ich schon in wenigen Fällen POIs an Flächen gepappt habe, stimme ich moenk voll zu. POIs gehören in einen einzelnen Node. Mir ist gerade kein Beispiel eingefallen, wo es Vorteile bringt, das nicht zu tun. Es ist einfacher auswertbar und würde sich auch einfacher pflegen lassen. Es geht zwar auch mit Flächen, die Auswertung wird aber verkompliziert - auch wenn es nur eine Zeile Code oder nur ein einzelner Buchstabe im Code ist. Wenn es einfacher geht, weshalb dann nicht einfacher machen?
Ich werde in Zukunft POIs als einzelne nodes taggen.

dancingman wrote:

die Auswertung wird aber verkompliziert - auch wenn es nur eine Zeile Code oder nur ein einzelner Buchstabe im Code ist. Wenn es einfacher geht, weshalb dann nicht einfacher machen?

Dancingman,

danke für Deine Unterstützung - "ganz einfach" isses übrigens gar nicht, nur in bestimmten Szenarien lässt sich die Auswertung mit relativ wenig Aufwand machen. Frag mal einer die Wheelmapper was die für ein Rad drehen mussten.

LG,

-moenk

@moenk: Machen wir das mal anders herum. Mit Polygonen hast du die Möglichkeit, dem Restaurant eine Fläche zu geben. Wenn wir jetzt komplett auf Punkte umsteigen würden, wie würdest du dann irgendwann (man weiß ja nie, vielleicht bekommen wir ja irgendwann Pläne von Gebäuden auf einem Level 20 oder so) die Fläche angeben?

Generell verstehe ich dein Anliegen vom Trennen von Objekt und Nutzung. Kann ich komplett nachvollziehen. Aber wenn das ganze Gebäude ein ALDI ist, die auch die Fläche ein ALDI, also gebe ich der Fläche aktuell den Namen ALDI. Auch wenn es sicherlich nicht so 100% sauber ist. Ich finde es aktuell immernoch besser, die Nutzungsfläche zu taggen, als nur vage da einen Punkt reinzusetzen. Man kann das Tagging auch anders interpretieren: Nicht das building = yes bekommt ein Attribut amenity = supermarket, sondern der Supermarkt ist eben überdacht, also der amenity bekommt als Attribut das building-Tag. Ähnlich wie bei Haltestellen und shelter. Oder man interpretiert es als nebeneinander: Da gibt es ein building und ein amenity auf der Fläche. In beiden Interpretationen ist nichts, was falsch ist... Da ist eher die Landnutzung spezifiziert: Ein überdachter Supermarkt... Finde ich nix schlimmes dran.

Wie gesagt, ich verstehe deinen Einwand, aber er ist meiner Meinung doch sehr engstirnig und einseitig betrachtet. Mir ist es lieb, die Fläche zu erhalten. Und dafür interpretiere ich die Daten, dass es passt - oder besser: Nicht so, dass es nicht passt. Ist irgendwie klar, was ich versuche zu sagen? 😄

Hallo,

Oli-Wan wrote:

Bei einem Gebäude, das ausschließlich ein Restaurant, eine Bank, einen Supermarkt, ein Hotel, eine Hochschuleinrichtung, eine Autowerkstatt, ... beherbergt, ist das Gebäude für mich synonym mit dem jeweiligen Objekt. Wollte man Nutzung und Gebäude trennen, dürfte man konsequenterweise auch keine - postalischen! - Adressen an Gebäude taggen (siehe aktuelle Inkarnation des ewigen Themas im Nachbarfaden) - schließlich schreibt man ja den Bewohnern bzw. dem dort ansässigen Unternehmen einen Brief, nicht dem Gebäude selbst.

Ich wäre auch für eine Trennung, denn dieses Erfassungssystem ist nicht konsequent
Befindet sich nur ein POI im Gebäude, dann ans Gebäude, sind es mehrere dann an einen Node, nicht gut 😠

Warum nicht auch bei einem POI extra an einen Node? Einfach immer, wenn ein POI vorhanden ist, dann an einen extra Node, das würde ich konsequente Umsetzung nennen.

Das gleich sehe ich bei Adressen. Befindet sich in einem Gebäude nur eine Adresse, ans Gebäude, sind es mehrere dann wird an Nodes getaggt. Das ist das gleiche Tagging wie bei den POIs, nicht gut.

Auch hier würde das generelle Erfassen an Nodes eine klare Struktur schaffen und eine einheitliche Erfassung leichter machen. Nicht einmal so und dass wieder so....

Ich finde es einfach logischer und klarer und auch für Neulinge leichter umzusetzen.

Hmm, bei Adressen gibt es die Möglichkeit, die Gebäude zu splitten. Das wurde oft diskutiert (erst vor kurzem hier http://forum.openstreetmap.org/viewtopic.php?id=19376). Ich hab früher komplett Nodes an die Stelle des Eingangs gehangen. Dann wurde das von jemandem umgemappt und hier wurde das Vorgehen diskutiert und für sinnvoll befunden. Nun mappe ich unterteilte Gebäude. Auch wenn ich damit nach wie vor nicht konform gehe, weil ein Gebäude eben nicht 3 Gebäude sind, sondern 3 Eingänge mit 3 Adressen, mache ich es so. Bei POIs ist es doch auch so möglich. Und vermutlich sogar sinnvoller, da Geschäfte wirklich räumlich voneinander getrennt sind. Insofern kann man durchaus immer auf POIs verzichten. Man muss also nicht in die eine, sondern kann auch in die andere Richtung gehen.

Die meisten POI (Points/Polygons Of Interest) haben nun mal eine räumliche Ausdehnung, und die kann und wird gemappt werden. Das Eintragen dieser Objekte als Punkt ist dann eine - vollkommen zulässige - Abstraktion. Wenn jemand aber anfinge, gezielt flächige Objekte in Punkte zu überführen, wäre ich davon wenig angetan, weil dabei Informationen verloren gingen, man also Arbeit früherer Mapper zerstört.

Im Übrigen fallen mir auch Konstrukte oder Mapping-Praktiken ein, die trotz ihrer Verbreitung für mich ganz offensichtlich und 100 % eindeutig unsinnig, inkonsistent o.ä. sind. Ergibt sich dann aber in einer Diskussion, dass andere genau gegenteiliger Meinung sind, legt das den Schluss nahe, dass es eben doch weniger eindeutig ist als angenommen.

Oli-Wan wrote:

Bei einem Gebäude, das ausschließlich ein Restaurant, eine Bank, einen Supermarkt, ein Hotel, eine Hochschuleinrichtung, eine Autowerkstatt, ... beherbergt, ist das Gebäude für mich synonym mit dem jeweiligen Objekt.

So mache ich das auch. Aber folgendes reales Szenario finde ich dann doch etwas komisch.
In einem Supermarkt gibt es einen Bäcker -> zwei POIs -> 2 Nodes
Der Bäcker macht zu -> ein POI -> POI-Infos auf Gebäude setzen
Ein neuer Bäcker eröffnet nach einigen Monaten wieder -> zwei POIs -> Infos wieder vom Gebäude weg, zwei Nodes

Oder man pappt den Supermarkt an die Fläche und den kleinen Bäcker mappt man als Node.

Was ist überhaupt ein POI? Ist ein Krankenhaus EIN POI, was ist ein Freizeitpark oder eine Hotelanlage? Sind das alles nur Punkte? Wie soll man denn die Ausdehnung der Hotelanlage darstellen? Manche dieser Sachen fassen ja viele sogar zu einer site-Relation zusammen.

Klar ist es von der Auswertung einfacher sich nur auf Nodes zu beschränken, aber ich denke wir brauchen einfach nur gute Tools. Und osmconvert ist das schon sehr gut.

Christian

Realistisch betrachtet kann man POIs nur als Relationen sauber mappen. Es sind nun mal keine physischen Objekte, sondern nur abstrakte Eigenschaften, die einen Bezug zu Geodaten haben. Das wäre ein sauberes und konsistentes Datenmodell und löst alle oben angesprochenen Probleme (außer der einfachen Auswertung). Das Krankenhaus wäre dann eine POI-Relation mit mehreren Gebäuden usw., der Supermarkt mit Bäcker wären zwei POI-Relationen, die potentiell das gleiche Gebäude als Geometrie beinhalten. Und der Supermarkt ohne Bäcker ist eben nur eine POI-Relation, die das Gebäude enthält.

Leider aber ist das relativ komplex, die Unterstützung unserer Editoren für Relationen nur begrenzt gut und die Auswertung von sowas schwer. Daher gibt es verschiedene Abstraktionen davon, die alle ihre Daseinsberechtigung haben. Eine davon ist, die Eigenschaften des POIs an den Weg selbst zu packen. Das ist sehr ähnlich dazu, einen geschlossenen Weg als Fläche zu verwenden, obwohl man dafür eigentlich besser in jedem Fall eine echte Fläche (in unserem aktuellen Schema also ein Multipolygon) hernehmen würde. Diese Abstraktion ist besonders gut geeignet, denn solange die Geometrie mit einem Weg dargestellt werden kann, geht so nicht die geringste Information verloren. Die Unterstützung dafür, sowohl von Editoren als auch Auswertern, ist außerdem ziemlich gut. Das Krankenhaus (mit den mehreren Gebäuden) ist so natürlich nicht richtig darstellbar - der Supermarkt allein aber sehr gut. Außerdem entspricht diese Darstellung der menschlichen Wahrnehmung - das Gebäude, das von ALDI gebaut wurde und dessen Fläche zu 90% von ALDI benutzt wird und an dem vorne groß ALDI drauf steht IST der ALDI - zumindest für geschätzte 99,9% der Menschen 😉 Die andere gängige Abstraktion ist der Punkt mit allen Informationen. Diese Variante hat natürlich auch ihre Vorteile - sie ist noch etwas leichter einzutragen und auszuwerten (allerdings ist die Unterstützung für erstere Variante wirklich nicht schlecht, so dass der Unterschied nicht sehr groß ist), aber auch ihre Nachteile. Die Verknüpfung zur Geometrie fällt vollständig weg, der menschlichen Wahrnehmung entspricht diese Darstellung eher weniger. Wenn ich aber nicht die bessere Variante mit den Relationen verwenden will, ist das die Abstraktion, die es ermöglicht, mehrere POIs zumindest innerhalb (wenn auch ohne logische Verbindung zu) einer Geometrie unterzubringen. Sie kann dann auch manchmal besser der Wahrnehmung entsprechen: Wenn sich mehrere Geschäfte ein Gebäude teilen, wird das Gebäude eher nicht stellvertretend für eines der Geschäfte wahrgenommen. Es hat dann ja auch nicht nur die Gestaltung eines Geschäftes und wurde meist nicht von einem der Unternehmen allein erbaut. Für den Fall des Supermarkts mit Bäcker würde ich allerdings zu einer Kombination der beiden Abstraktionen greifen, da das Gebäude meist als zum Supermarkt gehörig wahrgenommen wird (und meistens von diesem ja auch erbaut und unterhalten wird), weshalb die Auszeichnung der Fläche damit gerechtfertigt ist. Der Bäcker kommt dann einfach als untergeordneter Punkt dazu.

(Und falls das nicht klargeworden sein sollte: Ich widerspreche dem Threadersteller und lehne Punkte für POIs mit Ausdehnung ab, wenn nicht unbedingt nötig)

moenk wrote:

Moin Geri,

Du zeigst mit Deinem Beispiel genau auf, warum die gängige Praxis Käse ist. Das Gebäude ist ein Gebäude und das hat ganz andere Attribute, die nicht vermischt werden sollten. Darin sind die POI, die sich sogar verorten lassen. Über den Stuss mit building oder area gleich yes oder sonstwas werde ich mich an dieser Stelle nicht weiter aufregen, das hat sich mit einer neuen API hoffentlich auch erledigt.

LG,

-moenk

Ich hatte am Anfang in meinem Ort - weil ich wusste, wo der Eingang ist - die Häuser als building=* mit node entrance=* (jetzt *=main) und der kompletten Adresse eingezeichnet. Da (damals) die Adresse zum Gebäude gehörte, sollte sie auch an diese . (Umtaggen war mir aber damals zu aufwendig).

Das Gebäude hat einen (Haupt-)Eingang: danach geht es gerade zur "Hotelrezeption" - rechts durch eine Tür in die Gaststätte und durch eine gegenüberliegnde Tür zum Friseur. Alle haben die gleiche Adresse, aber unterschiedliche website, phone, name. Also auch so als POI eingetragen. Das Hotel erstreckt sich über zwei Etagen - in der ersten wohnt noch Herr Mustermann - der Hotelbetreiber und Eigentümer. Deshalb hatte ich das Gebäude zum Hotel "erklärt".

Nun, es lässt sich ändern -> Hotel vom Gebäude als zusätzlichen POI ins Gebäude. Und ist das dann einfach building=yes oder building Aber kommt dann nicht wieder jemand, der sagt: Die Hauptnutzung sollte an das Gebäude. (Wohnhäuser in Innenstädten mit Geschäften im Erdgeschoß und Büros in den unteren Etagen sind doch Wohngebäude - oder nur Gebäude?)

moenk wrote:

Frag mal einer die Wheelmapper was die für ein Rad drehen mussten.

Frag mal einer die Mapper, die den Murks der Wheelmapper regelmäßig aufgeräumt haben, weil letztere einen unfertigen Editor auf ein Massenpublikum losgelassen haben. Damit wären wir wieder bei den unausgereiften Anwendungen - ich bedaure, falls meine Äußerung bei Dir nun zu erneuter Emesis führt.

Die Grundfrage des Problems ist eigentlich eine andere: Sind die Eigenschaften des "POIs" am richtigen Element angehängt.
Die meisten "POIs", die als Polygon gemappt sind, sind doch nur Tags an buildings. Und das ist meistens falsch. Warum? Weil das Gebäude eben nicht so wie der POI heißt oder wie bei Aldi meistens gar keinen Namen hat. Wenn man den Aldi schon als Polygon mappen will, dann schon gleich als Ring um Gebäude UND Parkplatz. Dann erübrigen sich auch häufige Fantasiename wie "Aldi-Parkplatz", "Besucherparkplatz" und dergleichen.

Seit einiger Zeit sehe ich, dass dieses letztgenannte Taggingprinzip zumindest bei Schulen schon Schule macht ;-) Das Schulgelände bekommt den Schulnamen und die Einzelgebäude können "richtige" Namen -so vorhanden- oder auch lokale Namen (wie "Südflügel") bekommen.

Leider gibt es genügend Mapper, die nach dem Prinzip "eine Fläche ist besser als ein Punkt" die Arbeit von Vor-Ort-Erfassern einfach abändern (der POI wird einfach an das darunterliegende Gebäude gehängt - auch wenn sich noch weitere (nicht gemappte) POIs und Wohnungen darin befinden). Das eigentlich sehr schöne buildings_tools-Plugin ist sogar standardmäßig so eingestellt, einen innerhalb des neuen Gebäudes liegenden POI zu verwursten (glücklicherweise habe ich die Einstellungsmöglichkeit gefunden - und sofort ausgeschaltet) :-(

Zu einem Zeitpunkt, wo wir beim Detailmapping so weit sind, dass wir beginnnen in öffentlich zugänglichen Gebäude Räume einzuzeichnen, gleichzeitig darüber zu diskutieren, ob wir einen weit über 100m² großen Supermärkte wieder auf einen Punkt reduzieren finde ich ein wenig widersprüchlich.
Wenn sich nur ein POI am Gebäude befindet, auch wenn es nur ein kleines ist, es gleich an das gesamte Gebäudepolygon zu hängen, ist auch ein wenig übertrieben. Wenn die Fläche bekannt ist, würde ich ein eigenes Polygon anstreben (mit Stockwerksangabe).

LG Jimmy

PS: Bitte nicht daran aufhängen, dass im POI "Point" steht, das muss nicht gezwungener maßen heißen, dass es ein Punkt ohne Flächenausbreitung ist.

Oli-Wan wrote:

Damit wären wir wieder bei den unausgereiften Anwendungen - ich bedaure, falls meine Äußerung bei Dir nun zu erneuter Emesis führt.

Oli-wan,

ich bin da recht unemotional. Ändert aber nichts dran, dass ich POI als Polygon für falsch halte und das Problem mit den Wheelmapper mit POI-Punkten hätte auch vermieden werden können. Für mich heißt es auch sich der Realität der Anwendungen zu stellen, wenn man sich Gedanken über ein Datenmodell macht. Das ist ein Problem von OSM: Das Datenmodell ist historisch gewachsen und erfüllt nicht was man an allgemeinen Qualitätsmaßstäben an Geodaten anlegt - daran gemessen ist völliger Murks. Das kann man nun verteidigen oder schrittweise beheben.

LG,

-moenk

erwin6330 wrote:

Ich wäre auch für eine Trennung, denn dieses Erfassungssystem ist nicht konsequent
Befindet sich nur ein POI im Gebäude, dann ans Gebäude, sind es mehrere dann an einen Node, nicht gut 😠

Erwin,

danke für Deinen Hinweis. Das erschien mir schon so trivial, dass ich vergessen habe darauf hinzuweisen. Allein das ist schon Grund genug POI nur als Punkt zu mappen.

LG,

-moenk

Jimmy_K wrote:

...
PS: Bitte nicht daran aufhängen, dass im POI "Point" steht, das muss nicht gezwungener maßen heißen, dass es ein Punkt ohne Flächenausbreitung ist.

+1
point kann auch einfach "Ort" heißen ( http://www.dict.cc/?s=point ) und interest kann mit "Wichtigkeit" oder "Bedeutung" übersett werden ( http://www.dict.cc/?s=interest&failed_kw=interest ), woraus sich für "point of interest" "Ort von Bedeutung" ergibt.

S-Man42 wrote:

@moenk: Machen wir das mal anders herum. Mit Polygonen hast du die Möglichkeit, dem Restaurant eine Fläche zu geben. Wenn wir jetzt komplett auf Punkte umsteigen würden, wie würdest du dann irgendwann (man weiß ja nie, vielleicht bekommen wir ja irgendwann Pläne von Gebäuden auf einem Level 20 oder so) die Fläche angeben?

S-Man,

danke auch für Deinen Hinweis, über den ich erst mal nachdenken musste. Es ändert sich aber nichts für mich. Selbst wenn wir in einer Shopping-Mall jeden Laden indoor kartiert haben, über mehrere Geschosse meinetwegen, dann möchte ich den Laden als solchen und dann den POI als Punkt mit Hinweis was da gibt kartieren. Der Punkt liegt drin, vielleicht denken wir über einen Tag nach der Sorte von "is_in" als eine Art Relation nach, dass man zu einem Polygon immer den passenden POI und umgekehrt finden kann.

LG,

-moenk

Jimmy.

Jimmy_K wrote:

Zu einem Zeitpunkt, wo wir beim Detailmapping so weit sind, dass wir beginnnen in öffentlich zugänglichen Gebäude Räume einzuzeichnen, gleichzeitig darüber zu diskutieren, ob wir einen weit über 100m² großen Supermärkte wieder auf einen Punkt reduzieren finde ich ein wenig widersprüchlich.

so ist das nicht. Das Gebäude des Supermarkts ist doch da mit seiner Fläche. Der Punkt zeigt dann sogar auf den Eingang und nicht nur auf die Mitte. Und der Bäcker-Laden vorweg kann auch indoor kartiert werden, dazu ein POI auf den Eingang.

LG,

-moenk

moenk wrote:

Der Punkt zeigt dann sogar auf den Eingang und nicht nur auf die Mitte.

Dann ist jeder "POI" also auch als "building:entrance" zu taggen... (oder sollten wir dann nicht gleich auch noch shop/amenity/...:entrance einführen?)

tunnelbauer wrote:

Dann ist jeder "POI" also auch als "building:entrance" zu taggen...

Thomas,

das hängt dann davon ab, wie der POI liegt - wenn er denn auf dem Eingang liegt, eine gute Idee. Ich würd das nicht mal vorschreiben wollen, vielleicht gibts auch Fälle wo man den POI nicht auf den Eingang legen will. Vielleicht gibt sogar Fälle, wo man den POI auf einen Zuweg mit einem Schild legen will, weil man sonst gar nicht hinfindet.

LG,

-moenk

Dann wiedersprichst du dir jetzt gerade selber: Geradeeben sagst du der POI darf nicht irgendwo liegen sondern genau am eingang und jetzt liegt er aufeinmal am "Zuweg" - oder sollen wir POIs setzen? Ähnlich einer Krümelspur? Dann bräuchten wir auch keine routing-Software mehr - einfach der POIs-Kette folgen...

Also für mich ist und bleibt ein POI ein "Ort" und kein "Punkt" - ein Schloss/Burg kann ja zB ein "POI" sein - da will ich dann aber nicht nur einen Punkt im Innenhof sehen, sondern das Bauwerk in seiner Gesamtheit - somit bleibe ich bei Tagging-Schema alt: "Ein POI" > way/polygon - "mehrere POIs" > nodes

Hallo,

POI? was ist ein POI?

hurdygurdyman wrote:

point kann auch einfach "Ort" heißen ( http://www.dict.cc/?s=point ) und interest kann mit "Wichtigkeit" oder "Bedeutung" übersett werden ( http://www.dict.cc/?s=interest&failed_kw=interest ), woraus sich für "point of interest" "Ort von Bedeutung" ergibt.

Aber was ist es genau? Es ist immer das, was der jeweilige Betrachter darin sieht. Für den einen sind es geschichtliche Orte, den anderen ehemalige Bahnstrecken, wieder andere Einkaufsläden, oder Taxistände. Dasraus ergibt sich für mich, daß ein POI sowohl Fläche, Linie oder Punkt sein kann (auch in Relationen). Diese POI's immer als Punkte zu sehen, halte für unlogisch.

POI ist wie ein Gummituch. Jeder zieht es dahin, wo er es haben will.

Sven

moenk wrote:

Selbst wenn wir in einer Shopping-Mall jeden Laden indoor kartiert haben, über mehrere Geschosse meinetwegen, dann möchte ich den Laden als solchen und dann den POI als Punkt mit Hinweis was da gibt kartieren. Der Punkt liegt drin, vielleicht denken wir über einen Tag nach der Sorte von "is_in" als eine Art Relation nach, dass man zu einem Polygon immer den passenden POI und umgekehrt finden kann.

Die is_in-Relation macht die Sachen aber für alle Seiten komplexer und ohne die geht die Beziehung zwischen Fläche und POI verloren. Den automatisch darin zu verorten ist noch wesentlich blöder für die Auswerter. Und es gibt ja durchaus verschiedene Auswerter. Für Rederer ist es Mist, wenn der POI auf dem Gebäuderand liegt wie ein Eingang, denn dann landet der Schriftzug völlig falsch oder man muss deutlich mehr Aufwand betreiben. Letzlich bleiben insgesamt fast nur Nachteile.

Errt,

ich will die Relation oder "is_in"-Geschichte auch nicht haben. Mir reicht wenn der Punkt in der Fläche liegt. Und die Attribute für den POI an dem Punkt und nicht am Gebäude hängen. Wo der Renderer den Schriftzug hinsetzt ist mir eigentlich recht egal, mir ist wichtiger, dass man alle POI bekommt wenn man die z.B. über die Overpass-API abfragt.

LG,

-moenk

Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem. Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden. Schlag es denen halt mal vor. Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.

errt wrote:

Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem. Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden. Schlag es denen halt mal vor. Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.

+1

errt wrote:

Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden.

Errt,

hast dazu mal ein Beispiel? Punkte lassen sich einfach abfragem Zentroide wäre mir neu.

LG,

-moenk

errt wrote:

Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem.

Ich glaube, du irrst. Ein guter Renderer setzt Symbole und Beschriftungen so, dass der Zusammenhang zum dazugehoerigen Objekt nicht verloren geht und wird ansonsten das Gesamtbild optimieren. Da kommt's auf ein paar Pixel lechts oder rinks nicht an.

errt wrote:

Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.

Du hast: "Das haben wir schon immer so gemacht! Das haben wir noch nie so gemacht! Da koennte ja jeder kommen!" vergessen.

Warum reagieren hier eigentlich viele so, als ob moenk ihnen ihr Lieblings-Sandfoermchen wegnehmen will? Er schlaegt eine Vereinfachung vor. Die ist mit Beschraenkungen verbunden. Was geht denn nun wirklich verloren, wenn wir seinen Vorschlag umsetzen wuerden?

Gruss Christian

moenk wrote:

errt wrote:

Und die Umwandlung von Fläche in Punkt ist unkritisch und kann leicht von der (Overpass-)API gemacht werden.

hast dazu mal ein Beispiel? Punkte lassen sich einfach abfragem Zentroide wäre mir neu.

Das Zitat lese sich als 'technisch kein Problem, leider noch nicht umgesetzt' 😉

chkr wrote:

errt wrote:

Eben. DIR reicht es, wenn der Punkt in der Fläche liegt. DIR ist es egal, wo der Renderer den Schriftzug hinsetzt. Aber eben nicht jedem.

Ich glaube, du irrst. Ein guter Renderer setzt Symbole und Beschriftungen so, dass der Zusammenhang zum dazugehoerigen Objekt nicht verloren geht und wird ansonsten das Gesamtbild optimieren. Da kommt's auf ein paar Pixel lechts oder rinks nicht an.

Natürlich tut das ein guter Renderer. Aber das kann er nur solange er den Zusammenhang kennt. Und wenn ich nunmal irgendwohin (weiter oben hieß es schon, auf den Parkplatz) einen Punkt setze, kann er den nicht mit der Fläche in Verbindung bringen. Man sollte es ihm doch nicht unnötig schwer machen, wenn doch eine der Hauptbegründungen für die Punktvariante war, dass sei für die Auswerter leichter - ist es eben nicht für alle, nur für bestimmte.

chkr wrote:

errt wrote:

Aber lass die Daten ganz, in dem Schema, dass allgemein als gut anerkannt ist.

Du hast: "Das haben wir schon immer so gemacht! Das haben wir noch nie so gemacht! Da koennte ja jeder kommen!" vergessen.

Warum reagieren hier eigentlich viele so, als ob moenk ihnen ihr Lieblings-Sandfoermchen wegnehmen will? Er schlaegt eine Vereinfachung vor. Die ist mit Beschraenkungen verbunden. Was geht denn nun wirklich verloren, wenn wir seinen Vorschlag umsetzen wuerden?

Ich habe nichts gegen eine Verbesserung. Aber hier sehe ich eben einen Rückschritt. Und es ist ja nun so, dass das Ganze seit längerem so praktiziert wird und die meisten damit keine Probleme haben und die Tool-Unterstützung schon recht gut ist.
Was uns verloren geht, wenn wir das umsetzen? Der Bezug von Fläche und Nutzung geht uns verloren. Das kann man natürlich unproblematisch finden, mich würde es stören. Viele Renderer stellen beispielsweise Gebäude mit POI anders da, als solche ohne, das verbessert die Orientierung auf der Karte doch gewaltig. OSM wirbt doch gerade auch damit, dass wir semantisch wertvolle Daten mit Beziehungen der geographischen Objekte untereinander und mit weiterführenden Informationen haben, und nicht nur, wie kommerzielle Datensätze, Punktwolken mit gerade so viel Information, wie für wenige Hauptanwendungsfälle gerade so notwendig.
Natürlich müssen wir darauf achten, dass unsere Daten leicht zu erfassen und leicht zu verwerten sind. Aber mal ehrlich: Zumindest mit JOSM (andere Editoren nutze ich zu wenig, um das beurteilen zu können) ist es kein bisschen komplexer, das mit Flächen zu erfassen. Die Auswertung ist natürlich etwas komplexer, ganz klar, schließlich muss man ja zwei Fälle abdecken. Aber mit Unterstützung der einschlägigen Werkzeuge (osmconvert wurde schon angesprochen) und der Tatsache, dass das als häufig benötigte und technisch nicht so komplexe Funktion ist und deshalb sicher auch von anderen Werkzeugen unterstützt werden wird (wie schon gesagt, schlagt es doch für die Overpass-API mal vor - wenn sie's nicht doch schon kann), sehe ich auch keine allzu großen Hürden für Auswerter. Da haben wir wirklich wesentlich komplexere Daten, wenn es z.B. um Relationen, Multipolygone, ÖPNV-Linien geht.

Ok, ich habe ein großen Aldi (um beim Beispiel zu bleiben). Dieser hat zwei Eingänge. Einer ist nicht rollstuhltauglich, der andere schon. (nicht realitätsnah, aber egal :-)
Aktuelles mapping:
Gebäude+Aldi polygon. Auf diesem sind zwei entrance=yes nodes, wheelchair=yes/no jeweils. Meine (fiktive?) wheelchair-Routingsoftware kann also mich zum Aldi führen und weiss, dass sie direkt den entrance node mit wheelchair=yes ansteuern muss. Einfach, weil sie sieht, dass der Such-Treffer ein polygon ist und der zwei entrances nodes hat.

Vorgeschlagenes Mapping:
Gebäudepolygon und in der Mitte ein Aldi-Node. Das Gebäude hat auch jeweils die Entrance Nodes.
Meine routing-software hat jetzt einen Berg arbeit vor sich, rauszufinden, ob der Such-Treffer-Node jetzt innerhalb eines Gebäudes liegt. Dazu muss sie zusätzlich raten, dass beide entrance-nodes hoffentlich auch wirklich in den Supermarkt führen.

Alternativ:
Gebäudepolygon mit Aldinode am Haupteingang. Damit weiss erst recht keiner, dass der 20 meter danebenliegende wheelchair entrance auch in den supermarkt führt...

Alternativ 2:
Gebäudepolygon mit Aldinode in der Mitte. Dazu zwei Eingänge auf dem Gebäude und zwei footways von den Eingängen zum Aldi-Node. wird dann aber erstens hässlich und zweitens aufwändiger zu mappen.

Da gefällt mir das aktuelle Datenmodell irgendwie besser.

... nur kurz wegen der vorgerueckten Stunde:

errt wrote:

... und die meisten damit keine Probleme haben ...

Die "meisten" Mapper lesen dieses Forum nicht. Und die "meisten" von den hier Mitlesenden/-schreibenden arbeiten nicht in Projekten mit, die irgendwas zur Verfuegung stellen, dass dann von 'Nicht-Mappern' verwendet wird.

Leute wie moenk kriegen durch Fragen von Benutzern (anders als die "meisten") mit, wie unlogisch und kompliziert unser Tagging-Modell an manchen Stellen ist und wie viele Probleme in der Praxis dadurch entstehen.

Wenn wir die Erfahrungen der "Verwerter" unserer Daten nicht Ernst nehmen, anstelle sie mit "Problem der Anwendung - mir doch egal, ich kippe in die DB was ich diese Woche gerade glaube, was en vogue ist!" abzubuegeln, dann werden wir dem Gedanken der "Foerderung freier Geodaten" wohl nicht wirklich gerecht.

Gruss Christian

Das wird aber auch nicht besser, wenn wir in die DB kippen, was gerade bei den "Verwertern" en vogue ist, wie du so schön sagst. Alles was wir für die tun können, ist vernünftige Schnittstellen zu schaffen, welches Datenmodell denen auch immer zu Grunde liegt. Und grundsätzlich kommt man nun mal nicht drumherum, sich mit dem Datenmodell auseinanderzusetzen, wenn man die Daten vernünftig verwerten will, so viele sollten da also nicht von Außen kommen und dann erwarten, dass alles irgendwie gebrauchsfertig vorliegt. Jedenfalls kritisiere ich, dass ihr behauptet, die vorgeschlagene Variante wäre für "die Auswerter" besser - das stimmt eben nicht. Sie ist für manche Nischen etwas einfacher, korrekt, aber Wege das zu ermöglichen wurden aufgezeigt, aber für andere Nischen wesentlich komplizierter, das wurde ebenfalls schon angesprochen, siehe auch HolgerJeromin über dir, Lösungsansätze dafür wurden aber nicht genannt. Warum also einen Weg forcieren, der zwar manche Auswertungen vereinfacht, andere aber fast unmöglich macht, wenn der aktuell eingeschlagene, natürlich sicher auch nicht perfekte, Weg für praktisch alles, was mir bisher an Auswertungen unserer Daten bekannt geworden ist, zumindest keine besonders großen Hürden aufwirft. Insbesondere ist das Beispiel mit der Wheelmap ungeeignet, denn das Problem war von Anfang an bekannt und obwohl grundsätzlich Lösungen existierten wurde eine halbfertige Anwendung auf die Öffentlichkeit losgelassen.

errt und HolgerJeromin:
+1

moenk wrote:

"ganz einfach" isses übrigens gar nicht, nur in bestimmten Szenarien lässt sich die Auswertung mit relativ wenig Aufwand machen. Frag mal einer die Wheelmapper was die für ein Rad drehen mussten.

Das Beispiel mit Wheelmap ist auch deshalb ungeeignet, weil Wheelmap nicht nur ein Auswerter ist, sondern auch einen POI-Editor über die Internetseite bietet.
Erst die Möglichkeit der Bearbeitung und Rückgabe (Synchronisierung) von Daten in die OSM-Datenbank macht die Sache so aufwändig.

Gruß,
Mondschein

Mondschein wrote:

Erst die Möglichkeit der Bearbeitung und Rückgabe (Synchronisierung) von Daten in die OSM-Datenbank macht die Sache so aufwändig.

Komisch, ich muß da gerade an ein anderes Programm denken, dass sich wohl mit den gleichen Problemen rumschlagen muß.

Lösungsansatz A: Programm erweitern
Lösungsansatz B: Rohdaten vereinfachen

Ein Schelm, wer da Böses denkt 😉

Gruss
walter

errt wrote:

Die Auswertung ist natürlich etwas komplexer, ganz klar, schließlich muss man ja zwei Fälle abdecken.

Errt,

zwei nur? Zähl mal nach.

LG,

-moenk

Mondschein wrote:

Das Beispiel mit Wheelmap ist auch deshalb ungeeignet, weil Wheelmap nicht nur ein Auswerter ist, sondern auch einen POI-Editor über die Internetseite bietet.

Mondschein,

das Beispiel ist deswegen gut, weil es zeigt was für ein Rad die für das eine, und erst recht für das andere drehen mussten. Und nur weil POI in Ways und Relationen festgehalten wird.

LG,

-moenk

chkr wrote:

Wenn wir die Erfahrungen der "Verwerter" unserer Daten nicht Ernst nehmen, anstelle sie mit "Problem der Anwendung - mir doch egal, ich kippe in die DB was ich diese Woche gerade glaube, was en vogue ist!" abzubuegeln, dann werden wir dem Gedanken der "Foerderung freier Geodaten" wohl nicht wirklich gerecht.

Christian,

danke auch für Deine Unterstützung. OSM würde an vielen Stellen geholfen, wenn man nicht den genialsten, sondern den einfachsten Weg wählen würde. Sonst fehlt Akzeptanz! Warum wohl die Radarfallen in OSM nicht brauchbar sind? Weil es eine aufgeblasesen Relationskacke rundherum gibt die kaum einer kapiert, statt einfach Punkte zu setzen. Noch mehr Beispiele auf Nachfrage.

LG,

-moenk

Moin,

wo das ja alles ganz einfach ist: Ich habe hier einen einfachen Weg, um POI aus der OSM fürs Garmin aufzubereiten. Allerdings nur für Punkte. Vielleicht krieg ich noch einen sachdienlichen Hinweis, was ich ergänzen muss um auch Polygone (oder Ways, jaja) mit drin zu haben.
http://www.moenk.de/archives/75-Punkte- … ieren.html
Ist sicher nur eine Zeile, aber ich kann ja kein RTFM und möchte nicht noch ein Kilo Software zu den Standardstools dazuinstallieren die ich eh schon habe. Denn legt mal los!

LG,

-moenk

moenk wrote:

Warum wohl die Radarfallen in OSM nicht brauchbar sind? Weil es eine aufgeblasesen Relationskacke rundherum gibt die kaum einer kapiert, statt einfach Punkte zu setzen.

Weil genau dieses Beispiel zeigt, dass zum Beispiel nicht nur schwarz/weiß vorhanden ist. es gibt Blitzer die blitzen von vorne - da willst du nicht gewarnt sein, wenn du auf Höhe des Blitzers bist. Es gibt Blitzer die blitzen von hinten - da reicht es wenn du gewarnt wirst, wenn du auf deren Höhe bist. Und dann gibt es Blitzer die können gedreht werden.

Und dann gibt es Blitzer die blitzen bei Rotlicht... usw.

Und deine way-to-nodes - da gibt es was von osmconvert... 😉

tunnelbauer wrote:

Und deine way-to-nodes - da gibt es was von osmconvert... 😉

Thomas,

schön dass es das was gibt - darum hab ich die Lösung immer noch nicht hier auf dem Tisch. Komm, mach schon, ist doch nur eine Zeile ;-)

LG,

-moenk

Du erinnerst mich gerade stark an jemanden, der auch hier im Forum aktiv ist...

Aber ich bediene auch für dich gerne google: http://wiki.openstreetmap.org/wiki/Osmc … m_to_Nodes

tunnelbauer wrote:

Weil genau dieses Beispiel zeigt, dass zum Beispiel nicht nur schwarz/weiß vorhanden ist. es gibt Blitzer die blitzen von vorne - da willst du nicht gewarnt sein, wenn du auf Höhe des Blitzers bist. Es gibt Blitzer die blitzen von

Thomas,

mir würde reichen wenn der Blitzer überhaupt erst mal eingetragen ist - das Thema fasst aber kaum noch einer an, weil per verkopfter Definition so verkompliziert dass es schon abschreckend ist, seinen Beitrag dazu zu leisten. Verstehst Du nicht dass es Leute gibt, die nicht so schlau sind wie wir und die nur einen Blitzer eintragen würden wenn es einfach ist?

LG,

-moenk

moenk wrote:

Thomas,

mir würde reichen wenn der Blitzer überhaupt erst mal eingetragen ist - das Thema fasst aber kaum noch einer an, weil per verkopfter Definition so verkompliziert dass es schon abschreckend ist, seinen Beitrag dazu zu leisten. Verstehst Du nicht dass es Leute gibt, die nicht so schlau sind wie wir und die nur einen Blitzer eintragen würden wenn es einfach ist?

LG,

-moenk

JOSM > Punkt setzen > Vorlage > Straße > Wegpunkt > Radar

(weil ich grad JOSM nur in englisch da hab: JOSM > add point > Presets > highways > Waypoints > Speed camera)

Fertig.

moenk wrote:

... Verstehst Du nicht dass es Leute gibt, die nicht so schlau sind wie wir und die nur einen Blitzer eintragen würden wenn es einfach ist?

LG,

-moenk

Was ist mit YAPIS (Blitzer eintragen) oder über OSB (hier ist ein "Schwarzblitzer")?

Richtig ist - die Leute müssen es wissen -> also Werbung (in der Gemeinde -> die wimmelt ab. Habe mit Mühe eine OSB_Karte auf der Gemeindeseite verlinken können.).

Geri,

YAPIS kenn ich, find ich auch gut, arbeitet auch nur mit Punkten. Was meiste was ich mir zu dem Thema alles anhören muss und wie oft einer um die Ecke kommt, der mich auf diesen "Bug" hinweisen will.

Dieses "POI als Polygon"-Problem ist nur ein sichtbares Symptom der OSM-Community, die alles möglichst universell und perfekt machen will, dabei aber leicht an den Bedürfnissen der Zielgruppe vorbeischießt.

LG,

-moenk

moenk wrote:

wo das ja alles ganz einfach ist: Ich habe hier einen einfachen Weg, um POI aus der OSM fürs Garmin aufzubereiten. Allerdings nur für Punkte. Vielleicht krieg ich noch einen sachdienlichen Hinweis, was ich ergänzen muss um auch Polygone (oder Ways, jaja) mit drin zu haben.
http://www.moenk.de/archives/75-Punkte- … ieren.html
Ist sicher nur eine Zeile, aber ich kann ja kein RTFM und möchte nicht noch ein Kilo Software zu den Standardstools dazuinstallieren die ich eh schon habe. Denn legt mal los!

Vorbemerkung: Ich habe die Overpass API noch nie benutzt. Nach ein paar Minuten mit deren Dokumentation komme ich auf folgende Lösung, wie die erste Codezeile zu ersetzen ist:

wget␣"http://overpass-api.de/api/interpreter?data=node[tourism=hotel](-18,-61,2,-46);out␣meta;way[tourism=hotel](-18,-61,2,-46);out␣meta;>;out␣meta;"␣-O␣-␣|␣osmosis␣--read-xml␣file=-␣--sort␣--write-xml␣file=-␣|␣osmconvert32␣--all-to-nodes␣-␣>␣hotel.osm

Wer sich mit der Overpass API auskennt, kriegt es zweifellos noch einfacher und eleganter hin. Wie gesagt, dies war meine erste Berührung damit.

Du wirst nun vermutlich darlegen, daß dies den unzumutbar großen Aufwand der Weg-zu-Knoten-Konversion beweist.

moenk wrote:

Warum wohl die Radarfallen in OSM nicht brauchbar sind? Weil es eine aufgeblasesen Relationskacke rundherum gibt die kaum einer kapiert, statt einfach Punkte zu setzen.

Die Radarfallen können ganz simple als Node gesetzt werden. Die Relation ist (optional) on top um die Blickrichtung des Blitzers anzugeben.

Blitzer die als Fläche gemappt sind habe ich noch nicht gesehen. (Hoffe dass ich die Atommapper jetzt nicht angespitzt habe).

chris66 wrote:

Die Radarfallen können ganz simple als Node gesetzt werden. Die Relation ist (optional) on top um die Blickrichtung des Blitzers anzugeben.

Chris,

mittlerweile weiß ich das auch. Vor einiger Zeit wollte ich mich mit dem Thema befassen und hab im Wiki nur entnehmen können dass man solche Relationen dafür braucht.

Nun könnte man mit einem Skript überall wo beim Device das Tag fehlt das automatisch ergänzen. Hab davon aber die Finger gelassen weil solche automatisierten Edits auch wieder schwierig sind (also nicht in der Umsetzung, sondern in der Community).

Wir können daraus lernen: Wir sollten immer einen einfachen Weg anbieten und dann eine kompliziertere Option. Erst die einfache Lösung im Wiki, dann die Variante für Bessermapper.

LG,

-moenk

Oli-Wan wrote:

Du wirst nun vermutlich darlegen, daß dies den unzumutbar großen Aufwand der Weg-zu-Knoten-Konversion beweist.

Oli,

ich lege nun erstmal dar, dass Du da eine geniale Commandline hingezaubert hast. Wo der Tunnelbauer noch auf Wiki-Seiten verlinkt, hast Du schon eine gute Umsetzung dazu gemacht - Respekt!

Man braucht zwar dann noch ein paar Tools, das ist etwas schade, aber so gehts erst mal. Das könnte man als Lösung für diese oft gefragte Aufgabe so stehen lassen. Damit ist der Welt erst mal weiter geholfen. Wenn es mich überkommt mache ich noch einen Nachtrag zu dem Artikel, das ist ja toll dass man nun endlich aus der Overpass-API auch POI-Dateien fürs Garmin machen kann.

Natürlich ändert das nichts an meiner Haltung zur Sache ;-)

LG,

-moenk

chris66 wrote:

moenk wrote:

Warum wohl die Radarfallen in OSM nicht brauchbar sind? Weil es eine aufgeblasesen Relationskacke rundherum gibt die kaum einer kapiert, statt einfach Punkte zu setzen.

Die Radarfallen können ganz simple als Node gesetzt werden. Die Relation ist (optional) on top um die Blickrichtung des Blitzers anzugeben.

Blitzer die als Fläche gemappt sind habe ich noch nicht gesehen. (Hoffe dass ich die Atommapper jetzt nicht angespitzt habe).

Auch wenn die Blitzer hier OT sind 🤔
Eine Idee, um die "Relationskacke" zu vermeiden:
Wie Ampeln werden Blitzer grundsätzlich als node auf den überwachten way gesetzt (und nicht daneben, wo das Gerät steht)
Zusätzliche keys könnten sein:
speed_camera:forward misst in Richtung des ways, speed_camera:backward die Gegenrichtung; speed_camera=both misst beide Richtungen.
Mögliche values für diese keys:
frontside misst den in Richtung auf den Blitzer zufahrenden Verkehr, backside misst den von ihm wegfahrenden Missetäter, both misst beides.

Ein "speed_camera:forward=frontside" würde somit den in Richtung des ways fahrenden Verkehr blitzen, wenn er auf den Blitzer zufährt.

speed_camera:type=* könnte dann noch die Art der Messung erfassen

no relation=no problem
Erste Meinungen? Oder soll ich einen neuen thread aufmachen?

moenk wrote:

ich lege nun erstmal dar, dass Du da eine geniale Commandline hingezaubert hast. Wo der Tunnelbauer noch auf Wiki-Seiten verlinkt, ...

So gerne ich mich nun geschmeichelt fühlen würde: Genial ist daran überhaupt nichts (zum Glück, denn sonst wäre solch eine Lösung tatsächlich einigen wenigen Experten vorbehalten). Es handelt sich um den kombinierten Einsatz dreier Werkzeuge, die genau dafür gemacht sind. Der Weg zu --all-to-nodes hätte mich übrigens genau über die von Dir verschmähte Wiki-Seite geführt, wenn ich die Option nicht zufällig bereits gekannt hätte. Am längsten hat bei mir die Recherche in der Dokumentation zur Overpass API gedauert; da Du diese aber bereits kennst, sollte Dir das noch leichter fallen. Bleibt noch die Sache mit osmosis --sort: Daß dieser Einschub nötig ist, merkt man an der Fehlermeldung von osmconvert.

Gerade bin ich zufällig über diesen Edit von "FriendofMaps" mit dem Kommentar "+PoIs as Points" gestolpert (Tags werden am Gebäude gelöscht und in ggf neu erzeugte Nodes gesteckt) und musste an diesen Thread denken.
Vielleicht mag sich jemand weitere Edits dieses Nutzers anschauen?
Ich will erst einmal meine derzeitige Arbeit zu Ende bringen.

Ich sehe hier keine Probleme durch FriendOfMaps. An dem Gebäude gibt es einen Node am Eingang, der die Adresse beinhaltet (entrance=main/yes fehlt halt noch) und das Gebäude sollte keinen Namen haben, sondern das Restaurant heißt halt so.
Kann man so oder so sehen, ist aber nichts kaputt.

Ansonsten malt er gerne Flüsse vom Luftbild ab.

Zum Topic: Ich kann dem Threadersteller ganz und gar nicht zustimmen, die Punkte sind bereits genannt, aber ganz besonders finde ich pyrams Aussage:

pyram wrote:

Wenn man den Aldi schon als Polygon mappen will, dann schon gleich als Ring um Gebäude UND Parkplatz. Dann erübrigen sich auch häufige Fantasiename wie "Aldi-Parkplatz", "Besucherparkplatz" und dergleichen.

Genau das sehe ich nämlich auch, wenn ich ein Gebäude sehe, dass POI-Tags hat, dann sehe ich das eher als Gebäude (building=*) UND getrennt davon die Ausdehnung des POIs. Wenn nun der Mapper der Meinung ist, dass der ALDI so groß ist, wie das ganze Gebäude, dann ist das sein gutes Recht (dass viele Menschen - auch nicht-Mapper - das so sehen, hatten wir ja schon).

pyram wrote:

Seit einiger Zeit sehe ich, dass dieses letztgenannte Taggingprinzip zumindest bei Schulen schon Schule macht

Das sehe ich auch oft und das ist gut, denn das Schulgelände ist das POI, die Gebäude sind building=school. Auch bei Krankenhäusern seh ich diese Methode öfter mal. Anwendbar auch auf andere Dinge z.B. Hotels: z.B. das hier http://osm.org/go/0DaQ0bcTx--

Ich mappe wenn möglich (und es mir sinnvoll erscheint) immer als Polygon.

1. Wenn ich bestimmte interessante Orte als Polygon auf der Karte darstellen möchte, dann brauche ich den Zusammenhang zwischen dem sogenannten POI und dem Polygon. Ansonten kann ich das nicht so darstellen wie ich das haben will.
2. Falls man sich tatsächlich irgendwann mal darauf einigen würde, dass man für bestimmte Objekte nur Punkte benutzt, dann könnte man ein Skript schreiben der alle Polygone weltweit zu Punkten umwandelt. Andersrum ist das schlicht nicht möglich!
3. Was ist überhaupt ein POI? Leute interessieren sich für die verschiedensten Dinge. Ist ein Campingplatz ein POI? Der wäre mit einem Punkt auf jeden Fall sehr ungenau gemappt.

Ich kann die Bedenken durchaus verstehen, und wir hatten auch schon damals solche Diskussionen. Mit Punkten lässt sich halt am einfachsten Arbeiten, wenn man nur ein simple Anwendung baut, die nicht mehr benötigt.

Es fehlt einfach ein Tool mit dem man POIs als Punkt aus der Datenbank ziehen kann, egal als was sie eingetragen sind. Ich kann ich kaum glauben, dass es sowas bis heute nicht gibt.

Es fehlt einfach ein Tool mit dem man POIs als Punkt aus der Datenbank ziehen kann, egal als was sie eingetragen sind. Ich kann ich kaum glauben, dass es sowas bis heute nicht gibt.

Yepp, ein POI Befehl fuer die Overpass Api waer was feines.
Ansonsten gibt es schon was : mkgmap kann es standardmaeßig und osmfilter hat eine all-to-nodes Option.

chris66 wrote:

Yepp, ein POI Befehl fuer die Overpass Api waer was feines.
Ansonsten gibt es schon was : mkgmap kann es standardmaeßig und osmfilter hat eine all-to-nodes Option.

Aber ich muss dem Threadersteller schon recht geben. Das ist einfach zu kompliziert. Man muss erstmal Software installieren, und die noch mit Kommandozeilenbefehlen ausführen. Viele geben da wohl schon auf.
Was ich meinte wär eher ein Onlinetool. So, dass man die Daten direkt als POI bekommt und nicht erst umwandeln muss. POI-Befehl für die Overpass API wär super, wenn dann auch jemand ein Tool mit Eingabemaske baut.

Aus meiner Erfahrung heraus sind viele punkthafte POIs falsch gesetzt, da noch keine Flächen also Häuser gezeichnet und durchnumeriert wurden. Daher habe ich meist die vorhanden in meine neu gezeichneten Flächen übernommen. Bei der zweiten Überarbeitung habe ich dann aber viele wieder als Punkte neu erstellt, weil, wenn man richtig kartiert, ein Haus meist mehrere PoIs hat, zumindet in den Innenstädten. Dort werde ich nur noch dann flächenhaft, wenn es wirklich nur eine Nutzung der Fläche gibt, beispielsweise ein Kaufhaus.
Ich halte es daher für falsch, das eine oder andere zu verbieten, solange sich da keine zwei Mapper kloppen, ist doch jede Information erst mal gut.