Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Am 10. Juni 2011 14:38 schrieb fly lowfligh...@googlemail.com: ... In der Datenbank bräuchte man den 1. Koordinatenbereich, wo der operator anzutreffen ist (kann von der ganzen Welt bishin zu einer Stadt variieren) 2. Name 3. die main-tags, mit welchen der operator zu verknüpfen ist ( zb postbox, vendingmachine, postoffice, building, ... bei der Deutschen Post AG). das ist alles ein Riesenaufwand, weil die Liste permanent nachgeführt werden muss. Das geht vermutlich gerade noch so für Unternehmen in der von Dir genannten Größe, aber universell ist das nicht verwendbar. Für building müß man noch ein bischen besser filtern, da sonst schnell eine zu große Liste entsteht ! wieso, was hat das mit building zu tun? Building ist m.E. ein Tag, um eine bauliche Anlage als solche zu deklarieren (ggf. mit genauerem Gebäudetyp). Ich weiß, dass das ein ganze Stück Arbeit erfordert, aber es würde wohl viel mehr Eindeutigkeit schaffen als Monster-Relation-Kombinationen, oder wie stellt Ihr Euch denn so eine Relation für die Post, die Deutsche Bahn bzw andere große, weltweit tätige Konzerne vor ? Ja, nicht als Relation, die alle Objekte enthält, die irgendwie dazugehören, sondern als Zeiger (URI) auf die Entität/Relation vom Einzelobjekt aus. Wenn man das mit den Relationen macht, die wir in OSM derzeit haben, dann zeigt auch die Relation wieder auf das Einzelobjekt, daher geht das so im Moment nicht. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo fly, hallo Martin! Martin: ich finde deine Idee unterstützenswert, aber ich kann leider auch Frederiks Einwände verstehen. Eine solche Datenmenge würde die Komplexität sprengen. Dann könnte OSM schnell zu einer Datenbank für alles werden, was sie vom Grunde aus nicht ist. Dennoch würde ich gerne solch ein Stammdatenkonzept in OSM sehen, denn ich überlege jedes Mal, was ich bei operator= setzen muss und schaue dann nur bei Tagwatch nach, welche Schreibweisen verbreitet sind. Am 06/10/11 14:38, schrieb fly: Ich denke ein Ansatzpunkt ist auch sich für verbreitet operator=* zu einigen und dafür eine Datenbank zu erstellen. Ob im wiki oder extern ist ersteinmal egal, jedoch sollte sie im wiki verlinkt sein und die Editor-Software sie benutzen (presets, known values, autocompletion). Deine Ausführung würde bspw. einen REST-WebService darstellen, der alle möglichen Werte für Operator beinhaltet. Wenn man nun die Pflicht, einen Operator aus dem gültigen Bereich raushält, könnte man als Datenbasis doch direkt die Tagwatch-Datenbank verwenden, oder? Sie bietet alle Werte, die bisher ausgewählt wurden als operator und gleichzeitig unterstützt sie die Wahl durch die Priorität (~= Verwendungshäufigkeit). Durch eine Anbindung (und geeignete Datenaufbereitung), würde für mich bereits ausreichen, wenn die Vorschlagswerte aus Tagwatch aufbereitet im JOSM/Potlatch 2 angezeigt würden. Dies hätte den Vorteil, dass die OSM-Datenbank nicht gesprengt wird, die Daten sich langsam durch jeden Edit verbessern und keine großartigen Umstellungen notwendig sind. Ich könnte mir solch eine Lösung gut vorstellen, als naiver Nutzer. Ich kann nicht beurteilen, ob das Datenmodell von Tagwatch solch eine Funktion überhaupt anbieten könnte und wie viel Arbeit dies darstellen würde. Auf Seiten JOSMs/Potlatchs kann ich mir eher vorstellen, dass die Arbeit nicht sehr groß ist. Nur meine zwei, drei Gedanken zu dem Thema. Gruß, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3zCAQACgkQYNYFUFLXAD1lPwCfRutrLU0/Cpr7MK96tj8qKjgI oMcAoIQB4M1/1wi0ZW86IVYaLborxkVA =bdlC -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Der Ansatz, Taginfo dazu heranzuziehen, klingt erstmal nicht schlecht. Allerdings sehe ich da immer noch ein Problem: Der häufigste operator-Wert alleine hilft ja nicht, um Fehler zu erkennen; es müsste eine Art Gruppierung her, die auch taginfo bisher eben nicht bieten kann. Also: Telekom, Deutsche Telekom, Telekom AG, Deutsche Telekom AG, Telecom. müssten alle auf einen dieser Begriffe abbilden, aber eben nicht auf irgendwas, das so ähnlich klingt, aber ein völlig anderes Unternehmen bezeichnet. Taginfo kann nur Häufigkeiten von Begriffen analysieren und den häufigsten zurückgeben; nicht aber die korrekte Gruppierung synonymer Werte. Gruß Peter Am 11.06.2011 08:15, schrieb Philip Gillißen: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo fly, hallo Martin! Martin: ich finde deine Idee unterstützenswert, aber ich kann leider auch Frederiks Einwände verstehen. Eine solche Datenmenge würde die Komplexität sprengen. Dann könnte OSM schnell zu einer Datenbank für alles werden, was sie vom Grunde aus nicht ist. Dennoch würde ich gerne solch ein Stammdatenkonzept in OSM sehen, denn ich überlege jedes Mal, was ich bei operator= setzen muss und schaue dann nur bei Tagwatch nach, welche Schreibweisen verbreitet sind. Am 06/10/11 14:38, schrieb fly: Ich denke ein Ansatzpunkt ist auch sich für verbreitet operator=* zu einigen und dafür eine Datenbank zu erstellen. Ob im wiki oder extern ist ersteinmal egal, jedoch sollte sie im wiki verlinkt sein und die Editor-Software sie benutzen (presets, known values, autocompletion). Deine Ausführung würde bspw. einen REST-WebService darstellen, der alle möglichen Werte für Operator beinhaltet. Wenn man nun die Pflicht, einen Operator aus dem gültigen Bereich raushält, könnte man als Datenbasis doch direkt die Tagwatch-Datenbank verwenden, oder? Sie bietet alle Werte, die bisher ausgewählt wurden als operator und gleichzeitig unterstützt sie die Wahl durch die Priorität (~= Verwendungshäufigkeit). Durch eine Anbindung (und geeignete Datenaufbereitung), würde für mich bereits ausreichen, wenn die Vorschlagswerte aus Tagwatch aufbereitet im JOSM/Potlatch 2 angezeigt würden. Dies hätte den Vorteil, dass die OSM-Datenbank nicht gesprengt wird, die Daten sich langsam durch jeden Edit verbessern und keine großartigen Umstellungen notwendig sind. Ich könnte mir solch eine Lösung gut vorstellen, als naiver Nutzer. Ich kann nicht beurteilen, ob das Datenmodell von Tagwatch solch eine Funktion überhaupt anbieten könnte und wie viel Arbeit dies darstellen würde. Auf Seiten JOSMs/Potlatchs kann ich mir eher vorstellen, dass die Arbeit nicht sehr groß ist. Nur meine zwei, drei Gedanken zu dem Thema. Gruß, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk3zCAQACgkQYNYFUFLXAD1lPwCfRutrLU0/Cpr7MK96tj8qKjgI oMcAoIQB4M1/1wi0ZW86IVYaLborxkVA =bdlC -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
On Thu, Jun 09, 2011 at 08:06:49PM +0200, M∡rtin Koppenhoefer wrote: Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon länger durch den Kopf geht. Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen: welche Kraftwerke werden von EON betrieben, wo ist die Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen könnten vollständig abgebildet werden (Parlament, Regierungssitz, Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur ungefähr, d.h. man verlässt sich auf gleiche Namen oder muss externe Recherchen anstellen und unsere mit anderen Daten verknüpfen. Im Prinzip ist solches Mappen derzeit schon möglich, da man auch Relationen ohne Members machen kann, die z.B. eine Firma repräsentieren könnten. Das Problem ist vor allem, wie man diese Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn es Interesse daran gibt, wäre das vielleicht lösbar. Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte: Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr drin stehen) http://www.openstreetmap.org/browse/relation/1618278 und eine Metro-Linie, die von der vg. Firma betrieben wird (die Relation taucht hier mit der Rolle operator auf): http://www.openstreetmap.org/browse/relation/207926 Kommentare? Aaargh. Das klingt auf den ersten Blick ja alles ganz toll. Alles superflexibel und so. Aber irgendjemand muss mit den Daten auch arbeiten. Das sind einerseits die Mapper, die das eintragen müssen und andererseits die Leute, die aus den Daten Karten machen oder sonstwas. Und für beide ist diese ganze Relationiererei furchtbar aufwändig. Es hat schon seinen Grund, dass OSM so erfolgreich ist und andererseits Projekte wie DBPedia und alle diese Semantik-Web-Kram-Sachen nicht in die Puschen kommen. Es ist für Menschen schwierig rekursiv verzeigerte Datenstrukturen zu verstehen. Und auch für Maschinen ist das enorm aufwändig, damit zu arbeiten. Eine Software, die die wichtigsten drei, vier Varianten von Deutsche Post aus den Operator-Tags der Briefkästen matcht ist viel viel einfacher, als eine, die Relationen nachlaufen muss. Und dass sowas mit Relationen eindeutiger wird, ist auch eine Illusion. Ich weiss nicht, ob das jetzt noch ist, aber irgendwann hatten wir mal eine Hierarchie der Stadtteile von Bremen doppelt in der Datenbank, weil halt nichts verhindert, dass man sowas macht. Nein, unsere Datenstruktur ist schon gut. Sie ist ein Kompromiss, aber ein praktikabler Kompromiss. Und sie versucht nicht, die ganze Welt in einem Datenmodell abzubilden, sondern nur die Geodaten für eine Karte zu sammeln. Wir sind keine Datenbank für Firmengeschäftsfelder oder politische Strukturen. Das soll ruhig jemand anderes machen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Hi alle, Am 10.06.2011, 09:01 Uhr, schrieb Jochen Topf joc...@remote.org: Nein, unsere Datenstruktur ist schon gut. Sie ist ein Kompromiss, aber ein praktikabler Kompromiss. Und sie versucht nicht, die ganze Welt in einem Datenmodell abzubilden, sondern nur die Geodaten für eine Karte zu sammeln. Das ist gut und genau richtig so. On Thu, Jun 09, 2011 at 08:06:49PM +0200, M∡rtin Koppenhoefer wrote: Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben Das Problem sehe ich aber durchaus auch. Es wäre toll[TM], wenn man von irgendwoher (insbesondere auch innerhalb der Map) auf ein bestimmtes Objekt in der DB verweisen könnte, und zwar * eindeutig, als auch * persistent Beispiel: ich möchte von meiner Homepage aus, weil ich gerade über das Sony-Center in Berlin schreibe, per URI darauf verweisen. Im Moment geht das z.B. über folgende Möglichkeiten: (1) http://open.mapquestapi.com/nominatim/v1/search.php?q=sony%20center (2) http://www.openstreetmap.org/browse/relation/3221 Und hat man jeweils die Probleme: (1) ist nicht eindeutig (bei der Suche könnten mehrere ähnliche gefunden werden) (2) ist nicht persistent (die Relation könnte neu erzeugt werden oder in eine andere eingebettet, oder aufgelöst, werden) Eine nahe liegende Alternativlösung sind Wiki-Links: (3) http://de.wikipedia.org/wiki/Sony_Center (rechts oben auf Karte klicken) siehe auch http://wiki.openstreetmap.org/wiki/Key:wikipedia Allerdings hat dieser eindeutige, persistente URI den Nachteil, dass er nur für wichtige Dinge existiert, nicht z.B. für meinen Bäcker nebenan oder den Grillplatz wo ich meine nächste Geburtstagsfeier abhalten will. Bleiben also noch Koordinaten: (4) http://www.openstreetmap.org/?mlat=52.510004mlon=13.373083zoom=18 mit dem Nachteil, dass der Ort zwar eindeutig, das Objekt aber damit natürlich nicht referenziert ist. Offen bleibt die (fast philos.) Frage, was denn nun das Objekt an sich ist was referenziert werden soll. Ist Bahnhof (auf dem Hinweisschild) nicht doch eher der Bahnhofsparkplatz als das Gebäude, die Plattformen, die Schienenstücke? Können wir eine solche Datenbank: * eindeutige Identifier für Real-World-Objekte (z.B. Bahnhofsparkplatz) * eindeutige Identifier für abstrakte Konzepte (z.B. Deutsche Post) auch wenn sie nicht Teil der OSM-DB ist, mit OSM konsistent halten? IMHO ja, aber nicht durch technische Einschränkungen (Du darfst Relation XY nicht löschen, weil woanders genutzt), sondern durch technische Hilfsmittel (Script das warnt, dass 'Sony Center (Gebäude)' in der OSM-DB verändert oder gelöscht wurde). Somit wäre diese (ext.) Daten- bank etwas ähnliches wie tinyurl. Viele Grüße, Kay ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Hallo, On 06/10/11 10:04, Kay Drangmeister wrote: Das Problem sehe ich aber durchaus auch. Es wäre toll[TM], wenn man von irgendwoher (insbesondere auch innerhalb der Map) auf ein bestimmtes Objekt in der DB verweisen könnte, und zwar * eindeutig, als auch * persistent Ja, das ist ein Ding, das andauernd wiederkommt. Linken von extern auf eine OSM-ID ist ganz klar eine bloede Idee (und manche Leute fordern daraufhin konstante IDs, noch bloeder). Gerade vor ein paar Tagen hier erwaehnt: http://lists.openstreetmap.org/pipermail/talk-gb/2011-June/011749.html Die wahrscheinlich beste Loesung fuer sowas - und hier wurde ja auch schon oft drueber gesprochen - ist etwas, das mit Fuzzy-Koordinaten plus weiteren Informationen arbeitet, also z.B. das amenity=restaurant mit name=*Olive* im Bereich von 500m um den Punkt X oder so. Da braucht es dann nur noch einen Server, der solche Anfragen gut aufloest (und der dann, wenn er gut gemacht ist, gleich auch Bugmeldungen erzeugt, wenn vermehrt Links auf nicht-findbare Objekte reinkommen, oder der sogar Zugriff auf eine Historie hat und der dann sagen kann das Objekt gibt es nicht, aber es gab's bis vor 10 Wochen und wurde dann mit dem Kommentar XXX vom User YYY geloescht und so). Einen ersten kleinen Schritt in die Richtung macht schon das query-to-map von Tim Alder, das schon vor einem Jahr hier diskutiert wurde: http://lists.openstreetmap.org/pipermail/talk-de/2010-May/068971.html Das hat noch nicht alles, was man braucht, und ist auch stark auf die Ausgabe von Karten fixiert (in der Praxis will man vielleicht ja eher eine Art REST-Request machen und dann eine OSM-ID zurueckbekommen). Nominatim geht auch in die Richtung; Queries wie pub near [51.538,7.217] kann es schon beantworten. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Am 09.06.2011 20:06, schrieb M∡rtin Koppenhoefer: Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon länger durch den Kopf geht. Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen: welche Kraftwerke werden von EON betrieben, wo ist die Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen könnten vollständig abgebildet werden (Parlament, Regierungssitz, Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur ungefähr, d.h. man verlässt sich auf gleiche Namen oder muss externe Recherchen anstellen und unsere mit anderen Daten verknüpfen. Im Prinzip ist solches Mappen derzeit schon möglich, da man auch Relationen ohne Members machen kann, die z.B. eine Firma repräsentieren könnten. Das Problem ist vor allem, wie man diese Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn es Interesse daran gibt, wäre das vielleicht lösbar. Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte: Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr drin stehen) http://www.openstreetmap.org/browse/relation/1618278 und eine Metro-Linie, die von der vg. Firma betrieben wird (die Relation taucht hier mit der Rolle operator auf): http://www.openstreetmap.org/browse/relation/207926 Kommentare? Ich denke ein Ansatzpunkt ist auch sich für verbreitet operator=* zu einigen und dafür eine Datenbank zu erstellen. Ob im wiki oder extern ist ersteinmal egal, jedoch sollte sie im wiki verlinkt sein und die Editor-Software sie benutzen (presets, known values, autocompletion). In der Datenbank bräuchte man den 1. Koordinatenbereich, wo der operator anzutreffen ist (kann von der ganzen Welt bishin zu einer Stadt variieren) 2. Name 3. die main-tags, mit welchen der operator zu verknüpfen ist ( zb postbox, vendingmachine, postoffice, building, ... bei der Deutschen Post AG). Für building müß man noch ein bischen besser filtern, da sonst schnell eine zu große Liste entsteht ! Es sollte zb möglich sein alle bekannten operator für Briefkästen in Deutschland im preset amenity=postbox als values zu erhalten, wenn man sich in D befindet und analog für andere Länder/Gebiete. Ich weiß, dass das ein ganze Stück Arbeit erfordert, aber es würde wohl viel mehr Eindeutigkeit schaffen als Monster-Relation-Kombinationen, oder wie stellt Ihr Euch denn so eine Relation für die Post, die Deutsche Bahn bzw andere große, weltweit tätige Konzerne vor ? Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relationen für Betreiber (und evtl. für alles?)
Ich habe gerade mal einen Versuch gemacht zu einer Idee, die mir schon länger durch den Kopf geht. Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Man könnte die DB z.B. fragen: welche Kraftwerke werden von EON betrieben, wo ist die Hauptverwaltung, wie ist die Telefonnummer, welche Firmen gehören noch dazu (Beteiligungen, Töchter, etc.). Auch politische Strukturen könnten vollständig abgebildet werden (Parlament, Regierungssitz, Hierarchie, etc.). Manches davon geht auch schon jetzt, aber nur ungefähr, d.h. man verlässt sich auf gleiche Namen oder muss externe Recherchen anstellen und unsere mit anderen Daten verknüpfen. Im Prinzip ist solches Mappen derzeit schon möglich, da man auch Relationen ohne Members machen kann, die z.B. eine Firma repräsentieren könnten. Das Problem ist vor allem, wie man diese Relationen auffinden kann ;-). Vermutlich ist unser derzeitiges db-Schema nicht besonders gut geeignet, um so was zu machen, aber wenn es Interesse daran gibt, wäre das vielleicht lösbar. Ich habe mal ein kleines Beispiel gemacht, wie man so etwas abbilden könnte: Relation für eine Firma (nur rudimentär, da könnte natürlich viel mehr drin stehen) http://www.openstreetmap.org/browse/relation/1618278 und eine Metro-Linie, die von der vg. Firma betrieben wird (die Relation taucht hier mit der Rolle operator auf): http://www.openstreetmap.org/browse/relation/207926 Kommentare? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Am 09.06.2011 20:06, M∡rtin Koppenhoefer: M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. (...) Wir sollten uns da nicht übernehmen und versuchen einen auf Universaldatenbank. Das Wissen steckt schon in den Daten selbst und kann mittels Techniken des semantischen Webs ermittelt werden. Einen vielversprechenden Ansatz liefert da schon das zwar schon fortgeschrittene, aber immer noch rudimentäre Mapping von http://linkedgeodata.org - Wenn man dort das Interlinking etwa zu DBPedia verbessert ist das schon kurz vor dem von dir beschriebenen Ziel. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationen für Betreiber (und evtl. für alles?)
Am 09.06.2011 20:06, schrieb M∡rtin Koppenhoefer: Ausgangspunkt war die Tatsache, dass wir keine eindeutigen Identifier (URI) für viele Dinge haben, so dass es z.B. von der Deutschen Post zig Varianten in der DB gibt, die man alle erst mal matchen muss. Auch wenn man das vollständig in den Griff bekommen könnte durch eindeutiges Matchen ohne jeden Zweifel, so hat man doch nur einen Namen und keine weiteren Informationen. Hier hast du generell recht. Ein Freitext-Feld funktioniert für Dinge wie operator nicht wirklich gut. Ich hätte vor kurzem wahrscheinlich noch vehement widersprochen - und für die aktuellen Werkzeuge hat die Vorsicht vor Relationen auch ihre Berechtigung. Aber das muss ja nicht so bleiben. Daher: Kann man machen, wenn man sich um die Bedienbarkeit kümmert. M.E. könnte OSM extrem dazugewinnen, wenn wir die Struktur der Welt auch im nichträumlichen Bereich in unserer Datenbank hätten. Wir könnten z.B. die Tätigkeitsfelder von Organisationen oder Geschäftsfelder von Firmen abbilden. Ein semantisches Modell der Welt ist ein sehr ambitioniertes Ziel, und geht mir persönlich im OSM-Kontext dann doch eher zu weit. Eine eindeutige Grenze ist schwer anzugeben, aber je weiter sich etwas von Geodaten entfernt, desto weniger sinnvoll finde ich eine Aufnahme in OSM. Ich kann mir vorstellen, den Architekten eines Gebäudes einzutragen. Dann aber auch noch den Stammbaum dieses Architekten einzutragen, fände ich übertrieben. Anhaltspunkt ist die Anzahl der Schritte/Mitgliedschafts-Links, die man gehen muss, bis man zu einem Objekt mit Geokoordinate kommt. Je mehr es sind, desto weniger bietet sich eine Ablage in OSM an. So schlecht finde ich deinen Vorstoß hinsichtlich semantischer Verknüpfung dennoch nicht, denn so etwas wie eine Unternehmensrelation wäre ein hervorragender Anknüpfungspunkt für externe Datenbanken. Von operator-Freitext-Tags würde ich das nicht behaupten. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
