Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Moin! Klasse tool! Vielen Dank! Nun habe ich noch ein weiteres Problem: Ich bin mir ziemlich sicher, dass es für die Autobahnen A39 und A7 (andere habe ich nun nicht geprüft) eine route-Relation gab. Die scheinen jedoch jetzt verschwunden. Kann ich irgendwie noch feststellen, ob die im Rahmen des Redaction-Prozesses gelöscht wurde oder schon vorher nicht (mehr) da war? Gruß Andre Am 23.07.2012 12:23, schrieb Frederik Ramm: Hi, auf http://tools.geofabrik.de/osmi/?view=redactionbotlon=7.84268lat=48.78466zoom=5 gibt es einen neuen OSMI-Layer, der zeigt, was beim Lizenzwechsel-Bot passiert ist: ROT - Sachen, die der Bot geloescht hat. Der OSMI zeigt noch die alten Tags an, aber bitte nur angucken, nicht nach OSM hinein uebernehmen! ORANGE - Sachen, die der Bot geaendert hat. GELB - Sachen, die der Bot geanedert hat und die seitdem von jemand anders nochmal angefasst wurden. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Werner Interessant, was du da in deinem Mail vom 24. Juli 2012 00:38 schreibst. Letztlich sagst du damit, dass jedes OSM Objekt identifiziert oder zumindest verfolgt werden kann, wenn man vom ihm 1. die OSM ID(?), 2. die Version und 3. das Change-Datum (aus der Historie) verwaltet, oder? D.h. dass eine externe Datenbank jedem OSM Objekt eine eigene (permanente/stabile) ID zuordnen könnte, was meine Frage eingangs löst. Ich bin ein wenig verunsichert, weil du schreibst ... habe ich mal einen Prototypen geschrieben, der ... aus der OSM-DB ein Objekt zu jedem Zeitpunkt ermitteln kann.. Was ich - bzw. Linked Open Data und Projekte wie query-to-map oder OpenMetadata ja möchten, ist eine eindeutige, permanente ID - solange es das Objekt gibt. Weiter hast du geschrieben: Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr aufwändig. Ja; das habe ich auch gemerkt, als ich ein Extrakt (z.B. ein Land) mit aktuell halten wollte. Ist es nun mit deine Prototyp möglich oder nicht? Anmerkungen: * Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden. Du meinst es braucht eine zeitliche Toleranz, eine Zeitspanne (von z.B. einigen Minuten)? * Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction Bot verändert wurden. Ok. Aber was kann der Bot anders machen als das was unbedarfte Mapper und Editoren tun (löschen+neu einfügen sollte ja erkannt werden mit deinem Ansatz)? Grüsse, Stefan Am 24. Juli 2012 00:38 schrieb Werner Hoch werner...@gmx.de: Hallo, Am Sonntag, den 22.07.2012, 21:22 +0200 schrieb Stefan Keller: 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs ungewollt/unfreiwillig? Oben wird die Overpass Permanent ID erwähnt (http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID ) und dort steht: ...you shouldn't use an object ID, because the OSM IDs may change at any time. Das würde ich gerne mal näher analysieren: Ein klarer Fall für ein Löschen und Neu-Einfügen (mit neuer ID) scheint mir zu sein, wenn das auch in der realen Welt der Fall ist: Wenn z.B. ein Gebäude abgerissen und neu erstellt wird, oder ein wichtiger Einzelbaum gefällt und neu gepflanzt wird. Soeben realisiere ich, dass wenn Nodes (mit Tags) lagemässig verschoben werden, ein neuer Node mit neuer ID und neuen Koordinaten und den geretteten Tags erzeugt wird (zumindest in JOSM), während dessen alte Koordinaten als normaler Way-Node zurückbleiben. Das ist aber kein logisch zwingender Grund, sondern technischer Mangel. Dieses Problem lässt sich umgehen, wenn man nicht mit der Version des Weges arbeitet, sondern zusätzlich mit einem Datum. Ein way X lässt sich zu jedem Zeitpunkt und immer gleich aus OSM (und der OSM-Historie) extrahieren. Dieses Objekt(mit Datum) ist stabil. Diese Information ließen sich cachen und bei Bedarf gegen die Objekte mit aktuellerem Datum abgleichen. Wie kommt man an das Objekt mit ObjektID+Datum? -- alle referenzierten Objekte mit dem entsprechenden Datum ermitteln. Die Ermittlung ist ohne komplette Datenbank mit OSM-Historie sehr aufwändig. Vor einigen Jahren habe ich mal einen Prototypen geschrieben, der über die API aus der OSM-DB ein Objekt zu jedem Zeitpunkt ermitteln kann: Beschreibung: http://www.h-renrew.de/h/osm/tools/osmhistory.html Quelltext: https://github.com/werner2101/python-osm Anmerkungen: * Bei der Eindeutigkeit gibt es eine gewisse Unschärfe, weil die Changesets AFAIK nicht atomar in die OSM-Datenbank eingetragen werden. * Ich weiß nicht ob der Code mit Objekten noch geht, die vom Redaction Bot verändert wurden. Grüße Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Moin, Am 23.07.2012 23:41, schrieb Stefan Keller: Hallo Henning Am 23. Juli 2012 18:45 schrieb aighes o...@aighes.de: Am 23.07.2012 17:41, schrieb Stefan Keller: Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist? Siehe oben den Link zur Bushaltestelle in meiner Antwort vom 23. Juli 2012 13:34 an Georg. Scheint übrigens in JOSM zurzeit auch für Eingeweihte eine Herausforderung zu sein, so einen Node zu verschieben und die ID beizubehalten. JOSM - utilsplugin2 - Punkt extrahieren Wenn man sich denn überhaupt der Problemstellung bewusst ist, dass die ID unbedingt mitverschoben werden muss. Das ist der Knackpunkt. Verstehe ich nicht. Wenn es in der BBox nicht mehr ist, wird es wohl nicht mehr das gleiche Objekt sein, dass man gemeint hat. In jedem Fall sollte dann das Projekt überprüfen, ob ihre Daten noch zu dem neuen Objekt passen. Es gibt etliche Gebiete, die ab Orthofotos abdigitalisiert wurden und die um mehrere Meter (bis zu 30!) falsch sind, weil die Orthofotos falsch waren. Da steht man mit BBox sprichwörtlich im Schilf. Also als konkretes Beispiel halte ich eine Suche nach einer Bushaltestelle innerhalb von 50 m jetzt nicht unbedingt für problematisch, ganz abgesehen davon, dass diese einen konkreten Namen haben (sollten). Bei ganz genau einer bestimmten von 4 Sitzbänken nebeneinander fehlt mir persönlich so ein bisschen die Notwendigkeit der Objektunterscheidung - aber nun gut, dass mag jemand anders sehen. Bist Du wirklich sicher, dass sich der Aufwand, ggf. hundert(e) von Projekt-IDs einzupflegen und auch zu warten, lohnt, um ggf. ein(zelne) Objekt(e) auch außerhalb ihrer Positions-Box (möglicherweise in Timbuktu statt in Deutschland) wiederzufinden? Um bei Deinem Beispiel zu bleiben: Ein Projekt verweist (meinetwegen per Projekt-ID) auf diese Bushaltestelle, die als einzelnes Objekt auf dem Straßen-way in OSM vorhanden ist. Jetzt wird diese Bushaltestelle in OSM als zwei Objekte abseits der Straße verändert. Welches Objekt soll jetzt die Projekt-ID bekommen, beide Haltestellen oder nur eine ganz bestimmte? Oder die stop-area-Relation? Oder gehört diese ID womöglich zum Node der Straße? Das bist dann nicht Du, der das dann entscheiden muss! Derjenige, der das externe Projekt kennt und entsprechende Schlüsse ziehen kann. Sondern das ist Mapper Joe, der von Deinem Projekt keine Ahnung hat und nur so eine komische Projekt-ID als Tag vorfindet. Du must in jedem Fall hinterherarbeiten, ganz egal ob a) die ID dann mehrfach vorhanden ist b) die ID jetzt gar nicht mehr vorhanden ist, aber das Objekt sich noch in der Box befindet c) oder das Objekt mit oder ohne ID nicht mehr in der Positions-Box gefunden wird Denn ich gehe stark davon aus, dass es Dir nicht egal ist, ob sich _Dein_ Objekt mit der ID plötzlich in Timbuktu befindet. D. h. Du prüfst doch sowieso gegen, ob sich das Objekt noch in einer gewissen Box befindet. Warum dann nicht gleich so? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hallo Frederik, neuen OSMI-Layer Super! Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Moin, Am 23.07.2012 22:32, schrieb Frederik Ramm: Euer Ja/Nein-Gemisch finde ich nicht gut ueberlegt: Eine Autobahn kostet Maut, wenn sie in Deutschland ist und nicht explizit als mautfrei getaggt ist, oder wenn sie in einem anderen Land ist und explizit als mautpflichtig getaggt ist. Eine Bundesstrasse kostet immer dann Maut, wenn sie explizit als mautpflichtig getaggt ist. Eine niederrangige Strasse kostet nie Maut, wenn sie in Deutschland ist, egal wie sie getaggt ist... [Den Punkt lasse ich mal außen vor] Da blickt doch keiner mehr durch. Loriot würde jetzt sagen (lassen): Ach! Das ist doch eigentlich nur genau das, was die entsprechenden Gesetze vom Nutzer (mautpflichtigen Autofahrer) auch verlangen ... In einem Land mit genereller Mautpflicht für einen bestimmten Straßentyp würde ich auch explizit die Ausnahmen taggen. In einem Land mit expliziter Mautpflicht für bestimmte Abschnitte eines Straßentyps würde ich auch explizit die Abschnitte taggen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Moin, auch von mir vielen Dank! Am 24.07.2012 08:11, schrieb Andre Hinrichs: Ich bin mir ziemlich sicher, dass es für die Autobahnen A39 und A7 eine route-Relation gab. Kann ich irgendwie noch feststellen, ob die im Rahmen des Redaction-Prozesses gelöscht wurde oder schon vorher nicht (mehr) da war? vielleicht irgendwie über http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Autobahn? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag Supersedes
Hallo, Manuel Reimer wrote: Stefan Tiran wrote: Ein neuer Vorschlag: Wie wäre es damit, es so wie im Usenet zu machen? Wenn ein Objekt durch ein anderes ersetzt wird, auf das neue einen supersedes-Tag setzen, der als Wert die alte Objekt-ID hält. Das löst nicht das Problem Node wird durch Way ersetzt. Man kann durchaus Typ und Objekt-ID in einen String kodieren. Das zeigt JOSM mit seinem Feature Download Object seit einiger Weile. Einfach ein n, w, oder r der ID voranstellen und schon ist klar, was gemeint ist. Liebe Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 24.07.2012 09:56, schrieb Stefan Keller: Letztlich sagst du damit, dass jedes OSM Objekt identifiziert oder zumindest verfolgt werden kann, wenn man vom ihm 1. die OSM ID(?), 2. die Version und 3. das Change-Datum (aus der Historie) verwaltet, oder? Nein...du kannst mit ID und Datum immer das Objekt bekommen, dass du in deine DB eingetragen hast. Bsp.: Du verknüpfst gestern eine Bushaltestelle mit deiner DB. Heute lösche ich die Bushaltestelle und trage eine neue ein. Dann kannst du aus der History DB das Objekt so bekommen, wie es gestern war. Was ich dann mit dem Objekt gemacht habe, kannst du auch in Erfahrung bringen, aber das muss dann nicht mehr das Objekt sein, auf das sich deine DB bezieht. Da diese weiterverfolgung nicht geht, kannst du dir aber auch gleich die Daten aus OSM kopieren und in deine DB einfügen. Da ist der Aufwand geringer. Denn so eine History-DB ist mit Sicherheit nicht ohne ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Stefan Keller wrote: Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Eben. Die Tendenz geht dahin, dass ein Mapper ggf. alle Tags übernimmt. Erst recht auch die, die er nicht kennt. Aber es ist doch immer ein Objekt an nahezu einer Koordinate, oder? Dann frag' halt die Overpass-API nach allen Bildstöcken in einer gewissen BBox. Eine BBox taugt nicht als Identifikator. Wenn das Objekt verschoben wurde, dann ist es weg, ausserhalb der BBOX. Nicht nur das. Ich müsste für alle Bildstöcke (ca. 30 Stück) eine BBox ermitteln und speichern. Zudem gibt es Stellen, an denen Bildstöcke relativ nah beieinander stehen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
aighes wrote: Folgendes fehlt in deiner Zusammenfassung: Mit der OSM-IDs ist die Gefahr grösser als mit der UUID, dass das Projekt das Objekt verliert (da es einer gelöscht und mit denselben Tags neu erstellt hat). Wenn jemand das Objekt ändert, dann muss das Projekt so oder so überprüfen. Daher die UUID, bzw. die Projekt-ID Kannst du mal ein konkretes Beispielszenario nennen, wo das so ist? $GEBAEUDE ist aktuell noch als Node eingezeichnet und jemand zeichnet den Gebäudeumriss ein und überträgt alle Tags vom Node auf den neu geschaffenen Way. Beispiele gibt es viele. Problem ist und bleibt, dass man, wenn man direkt Daten von der OSM-Datenbank in einem Projekt verwenden will, irgendwie eine Referenz auf bestimmte Objekte benötigt. Prinzipiell ist es nämlich in zweierlei Hinsicht praktisch, Geodaten direkt in der OSM-DB zu pflegen. Zum einen gibt es hier gute Tools um die via GPS ermittelten Daten in der Karte einzutragen und auch zu benennen und/oder mit weiteren Infos zu versehen. Zum anderen profitiert auch die OSM gleich mit, wenn solche Daten direkt in deren DB gepflegt und verwaltet werden. Auch andere Projekte könnten so die Daten (z.B. alle Bildstöcke) anzeigen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Roland Olbricht wrote: Wenn doch jede Sehenswürdigkeit genug Material für eine Webseite hat (Foto und/oder Text reicht), dann mache am besten diese als Webseiten zugänglich (z.B. mit Basisurl + UUID als URL aus der Datenbank) und trage die URL als url=... oder website=... ein. Dann sieht jeder Mapper sofort, dass die Objekte wichtig genug sind, eine Website zu haben und kann damit umgehen, da im Gegensatz zur UUID ja der Zweck des Tags ohne Recherche erkennbar ist. ... aber es kann keiner einem anderen Mapper verbieten eine andere Webseite oder einen anderen Link auf ein Bild zu hinterlegen. Ich hatte ursprünglich tatsächlich vor, die Verknüpfung zwischen Object-ID und Bild auch in der OSM zu pflegen, habe mich aber bewusst dagegen entschieden, weil ich auf unserer Vereinskarte auch nur unsere Bilder sehen will. Ich will vermeiden, dass jemand ein vermeintlich schöneres Bild an einen Bildstock hängt und dieses dann auf dem Weg auf unsere Karte kommt. Aus dem Grund kommen auch nur Position und Name (ggf. noch start_date, wenn bekannt) aus der OSM-DB. Die Verbindung zwischen Bild und OSM-ID mache ich dann auf unserem Server. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Stefan Keller wrote: * Bisher haben wir von externen Datenbanken gesprochen - also Mehrzahl: Gehört so eine externe Datenbank nicht eigentlich zur OSM Infrastruktur? Nicht, wenn der Betreiber der externen DB ganz bewusst verhindern will, dass jemand seine Daten ändert. In meinem Fall eben Verknüpfung zwischen OSM-ID (da ich aktuell noch diese nutze, da kein anderes Merkmal brauchbar) und einem Foto. Die Summe der Daten visualisiere ich dann auf einer Karte für unseren Heimat- und Geschichtsverein. Ich will ganz bewusst verhindern, dass jemand ein anderes Bild für das für mich interessante Objekt hinterlegt. Auf unserer Karte will ich auch nur unsere Bilder sehen. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LKW Mautinformationen
Am 24.07.2012 00:00, schrieb aighes: Hallo Frederik, meiner Meinung nach ist die Maut eine Eigenschaft der Straße und sollte daher auch an der Straße getaggt werden und nicht an einer Routenrelation. Für eine Auswertung wäre es auch deutlich einfacher, wenn die Wege (in irgendeiner Form) entsprechend getaggt sind. Bei anderen Eigenschaften eines Weges erfassen wir ja auch nicht Start- und Endpunkt der Eigenschaft, sondern geben dem Weg diese Eigenschaft. Ich sehe jetzt erstmal keinen Grund hiervon abzuweichen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de +1 falls gewünscht, kann man ja zusätzlich den Start und Endpunkt taggen. Jimmy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kartenauswertung erweitert
HI ! aufgrund der Hinweise habe ich die Auswertung verbessert Großkraftwerk Mannheim (Kohle): http://www.openstreetmap.org/browse/way/152506744 = http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019lat=49.44126lon=8.49607zoom=14layers=BTTTlang=de Wasserkraftwerk Mannheim-Feudenheim: http://www.openstreetmap.org/browse/way/59701027 = http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019lat=49.47604lon=8.52911zoom=14layers=BTTTlang=de Danke für die Hinweise. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kartenauswertung verbessert
HI ! aufgrund der Hinweise habe ich die Auswertung verbessert Großkraftwerk Mannheim (Kohle): http://www.openstreetmap.org/browse/way/152506744 = http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019lat=49.44126lon=8.49607zoom=14layers=BTTTlang=de Wasserkraftwerk Mannheim-Feudenheim: http://www.openstreetmap.org/browse/way/59701027 = http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019lat=49.47604lon=8.52911zoom=14layers=BTTTlang=de Danke für die Hinweise. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kartenauswertung erweitert
HI ! aufgrund der Hinweise habe ich die Auswertung verbessert Großkraftwerk Mannheim (Kohle): http://www.openstreetmap.org/browse/way/152506744 = http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019lat=49.44126lon=8.49607zoom=14layers=BTTTlang=de Wasserkraftwerk Mannheim-Feudenheim: http://www.openstreetmap.org/browse/way/59701027 = http://www.tappenbeck.net/osm/maps/deu/index.php?id=1019lat=49.47604lon=8.52911zoom=14layers=BTTTlang=de Danke für die Hinweise. Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] 3-fach hällt besser ...
Hi ! bevor ich wieder Rückmeldungen zu dem 3-fach-Posting bekomme. Ich wollte die eMail parallel an eine Dritte Person verschicken und mein Thunderbird hat angemerkt das dieses mit dem Konto nicht geht. Wenn man eine solche Meldung bekommt, dann entsteht der Eindruck da ist auch wirklich nichts rausgegangen. Das dem aber nicht so war sehen wir an dem 3-fach-Posting. Sorry Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kartenauswertung erweitert
Moin Jan, Biomassekraftwerke sind unterschiedlich mit generator:source=biomass/biofuel/biogas gekennzeichnet. Du fragst im Overlay Biomasse offenbar nur biofuel ab. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Ich möchte den Diskussionsfaden von Permanente/stabile OSM IDs! zusammenfassen wie folgt: Den Anwendungsfall, den ich einem Lösungskonzept zuführen möchte, sind Nachnutzer und (OSM-)externe Datenbanken (nennen wir es Fachinformationssystem X, das z.B. Schlafbänke als Objekte der Realität verwaltet). Das Fachinformationssystem X verwaltet eigene, zusätzliche Eigenschaften eines Objekts der Realität jemand hat Schlafbänke vorgeschlagen :-) und möchte sich mit der OSM DB verknüpfen. Dazu kann sie sich - wie von Frederik skizziert - auf eine externe Datenbank verlassen, nennen wir sie LinkedOSMDB (siehe auch z.B. OpenMetaMap, die sich noch auf OSM IDs stützt). Die LinkedOSMDB bietet in Richtung Fachinformationssystem X hin eine eindeutige und stabile ID (z.B. ein URI à la Linked Open Data, oder ein TOID à la UK's MasterMap oder die Swiss OID à la Interlis: http://www.interlis.ch/oid/oid_d.php). Dazu gehört natürlich auch eine schnelle API. Und Richtung OSM Datenbank hin zeigt sie auf OSM-Objekte. In OSM geht es nun darum, einen Ansatz zu finden, um eine ID eines OSM-Objekts zu gewährleisten, die zusammen mit dem Objekt der Realität eindeutig ist und stabil bleibt. Genau genommen, ist mit eindeutig im Rahmen eines bestimmten Kontextes gemeint. Und ich spreche bewusst von stabil und nicht von permanent, denn es ist nicht das oberste Ziel, IDs auf gelöschte Objekte - die auch in der Realität gelöscht wurden - zu erhalten - das wäre eine zusätzliche Historisierungs-Dienstleistung. Die Meldung Objekt bzw. ID nicht (mehr) vorhanden genügt. Die OSM ID ist es nicht und soll es auch nicht werden, wie Frederik das beschrieben hat. Ein Vorschlag geht offenbar in Richtung fuzzy links bzw. semantische ID. Dabei spielt ein Mapper den Identifizierer und definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte (vgl. dazu http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist schon mal ein guter Ansatz (z.B. ist name=Matterhorn weltweit wohl eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und genügt ev. für query-to-map-Anwendungen. Er ist aber für die oben erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen. Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM Objekt einsetzbar ist und als ID erkennbar sein soll. Vorschlag: linkedosmdb_id=...! Man beachte, dass damit nicht automatisch sämtliche OSM-Objekte damit aufgebläht werden und dass es keine UUID sein muss, die universumweit eindeutig ist (das geht auch kürzer als mit 64 Zeichen, wie TOID und Swiss OID zeigen). Diese ID ist nicht zusammengesetzt (bei network+ref sieht man dem Key network alleine keine ID-Eigenschaft an und man sieht auch nicht, dass sie zusammengehören!). Und Koordinaten inkl. BoundaryBox kommen auch nicht in Frage, denn das Objekt ist ja immer noch dasselbe, wenn deren Lage ein paar Koordinatenstellen weniger hat oder wenn es verschoben wird, weil jemand die Bushaltestelle an den richtigeren Ort schiebt, die Orthophotos falsch georeferenziert waren oder Koordinaten sich ändern, weil Kontinente herumdriften!!! Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist: Sollen nebst linkedosmdb_id=... weitere Keys zugelassen sein (gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte Objekt mit name=...) ? LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hallo, On 24.07.2012 23:12, Stefan Keller wrote: Ein Vorschlag geht offenbar in Richtung fuzzy links bzw. semantische ID. Dabei spielt ein Mapper den Identifizierer und definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte (vgl. dazu http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist schon mal ein guter Ansatz (z.B. ist name=Matterhorn weltweit wohl eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und genügt ev. für query-to-map-Anwendungen. Er ist aber für die oben erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen. Ich denke, dann muss man an diesem Konzept noch verfeinern. Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM Objekt einsetzbar ist und als ID erkennbar sein soll. Das finde ich nicht gut. Ich denke, die Link-Datenbank kann auch Parkbaenke identifizieren mit einer Anfrage wie: Diejenige amenity=bench, die dem Punkt lat=y,lon=x am naechsten ist. - in dem Fall ist eine Punktposition Teil des hinterlegten Links, was ich aber gar nicht schlecht finde, selbst bei sowas wie Matterhorn, einfach um eine groessere Stabilitaet auch gegenueber Spaesschen (jemand erfindet eine Insel in der Suedsee und taggt dort ein natural=peak name=Matterhorn) gewappnet zu sein. Natuerlich sind solche Links dann unter Umstaenden nicht mehr garantiert eindeutig, aber: Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die Parkbank mit der Plakette gestiftet von Dr. Mueller, dann sollte man *das* in OSM taggen (inscription=gestiftet...) und dann kann man darauf auch einen Link setzen (eine Parkbank im Umkreis von 50m um den Punkt X, mit Inschrift...). Oder es gibt kein identifizierendes Merkmal, weil da eben drei Parkbanke stehen und alle gleich sind - aber *dann* gibt es auch keinen Anlass, auf speziell eine der drei verlinken zu wollen. Da waeren uebrigens noch allerhand interessante Sperenzchen denkbar - man koennte z.B. auch einen Link setzen auf eine Gruppe von 3-5 Parkbaenken in der unmittelbaren Naehe der Position X oder so etwas. Und wie gesagt, man koennte ja staendig automatische Analysen machen und diese Links aufloesen, und in einer Datenbank das Aufloese-Ergebnis festhalten und Aenderungen visualisieren - die Permanent-ID X, der folgende Abfrage hinterlegt ist und die 17mal pro Woche nachgefragt wird, ergab gestern noch die OSM-ID A als Resultat, heute ergab sie B. Solche IDs koennten sogar geflaggt werden als muesste mal ein Mensch kontrollieren. Das ist doch ein viel maechtigeres Konzept, als OSM seine eigenen IDs aufzubuerden. Vorallem laesst es auf besere Weise Raum fuer Wettbewerb - wenn der Betreiber der Link-Datenbank schlurt, dann kann jemand anders die Datenbank komplett kopieren und eine eigene Version davon betreiben, ohne dass man jetzt in OSM alle linkedosmdb-Tags noch kopieren muss auf freelinkdb oder was auch immer ;) Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist: Sollen nebst linkedosmdb_id=... weitere Keys zugelassen sein (gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte Objekt mit name=...) ? Wie gesagt, fuer mich ist die Gesamtheit aller Eigenschaften der potentielle Key eines Objekts, und wenn diese Gesamtheit nicht ausreicht, um das Objekt zu identifizieren, dann ist dieses Objekt auch nicht des Identifizierens wuerdig. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LinkedOSMDB (War: Permanente/stabile OSM IDs!)
Hallo, Am 24. Juli 2012 23:55 schrieb Frederik Ramm frede...@remote.org: Hallo, On 24.07.2012 23:12, Stefan Keller wrote: Ein Vorschlag geht offenbar in Richtung fuzzy links bzw. semantische ID. Dabei spielt ein Mapper den Identifizierer und definiert und speichert eine Query (z.B. ref+network) auf OSM Objekte (vgl. dazu http://wiki.openstreetmap.org/wiki/Query-to-map). Das ist schon mal ein guter Ansatz (z.B. ist name=Matterhorn weltweit wohl eindeutig für ein bestimmtes Objekt der Realität). Er ist gut und genügt ev. für query-to-map-Anwendungen. Er ist aber für die oben erwähnten Anwendungsfälle nicht hinreichend, denn er deckt nur einen Teil von OSM Objekten ab: Was ist mit Parkbänken und Briefkästen. Ich denke, dann muss man an diesem Konzept noch verfeinern. Als Verbesserung schlage ich vor, dass die ID potentiell für jedes OSM Objekt einsetzbar ist und als ID erkennbar sein soll. Das finde ich nicht gut. Ich denke, die Link-Datenbank kann auch Parkbaenke identifizieren mit einer Anfrage wie: Diejenige amenity=bench, die dem Punkt lat=y,lon=x am naechsten ist. - in dem Fall ist eine Punktposition Teil des hinterlegten Links, was ich aber gar nicht schlecht finde, selbst bei sowas wie Matterhorn, einfach um eine groessere Stabilitaet auch gegenueber Spaesschen (jemand erfindet eine Insel in der Suedsee und taggt dort ein natural=peak name=Matterhorn) gewappnet zu sein. Gute Idee, sich gegen solche Spaesschen zu wappnen. Ich habe einfach Bedenken mit Koordinaten arbeiten. Die machen fast noch grösseren Kummer als die OSM-ID. Dann kann die LinkedOSMDB ja gleich bei der OSM-ID bleiben und versuchen, diese bzw. das dazugehörige Objekt zu tracken (das meine ich nicht abwertend). Natuerlich sind solche Links dann unter Umstaenden nicht mehr garantiert eindeutig, aber: Entweder gibt es kein identifizierendes Merkmal, z.B. man meint konkret die Parkbank mit der Plakette gestiftet von Dr. Mueller, dann sollte man *das* in OSM taggen (inscription=gestiftet...) und dann kann man darauf auch einen Link setzen (eine Parkbank im Umkreis von 50m um den Punkt X, mit Inschrift...). Oder es gibt kein identifizierendes Merkmal, weil da eben drei Parkbanke stehen und alle gleich sind - aber *dann* gibt es auch keinen Anlass, auf speziell eine der drei verlinken zu wollen. Diese Relevanz-These scheint mir etwas gewagt: Wieso sollte ich als für die Erhaltung der Parkbänke verantwortliche Parkverwaltung zwei nebeneinander stehende knallrote Parkbänke (ohne Plakette) nicht verlinken wollen? Da waeren uebrigens noch allerhand interessante Sperenzchen denkbar - man koennte z.B. auch einen Link setzen auf eine Gruppe von 3-5 Parkbaenken in der unmittelbaren Naehe der Position X oder so etwas. Und wie gesagt, man koennte ja staendig automatische Analysen machen und diese Links aufloesen, und in einer Datenbank das Aufloese-Ergebnis festhalten und Aenderungen visualisieren - die Permanent-ID X, der folgende Abfrage hinterlegt ist und die 17mal pro Woche nachgefragt wird, ergab gestern noch die OSM-ID A als Resultat, heute ergab sie B. Solche IDs koennten sogar geflaggt werden als muesste mal ein Mensch kontrollieren. Stimmt. Gute Ideen. Das ist doch ein viel maechtigeres Konzept, als OSM seine eigenen IDs aufzubuerden. Vorallem laesst es auf besere Weise Raum fuer Wettbewerb - wenn der Betreiber der Link-Datenbank schlurt, dann kann jemand anders die Datenbank komplett kopieren und eine eigene Version davon betreiben, ohne dass man jetzt in OSM alle linkedosmdb-Tags noch kopieren muss auf freelinkdb oder was auch immer ;) Guter Punkt. Um dem vorzubeugen würde ich als LinkedOSMDB-Betreiber die ID-Werte analog dem TOID und Swiss-OID-Prinzip definieren. Das verhindert, dass zwei DBs dieselbe ID-Werte zweimal vergeben. Andererseits lässt sich das Umkopieren und Ergänzen nur verhindern wenn die neue freelinkdb genau denselben geografischen Bereich umfasst. Deckt die freelinkdb einen grösseren Bereich ab, ist etwas was vorher eindeutig war, plötzlich nicht mehr unbedingt so (z.B. ist name=Stuttgart für Deutschland wohl eindeutig, weltweit aber nicht mehr). Eine offene Frage bleibt für mich: Was als Projekt-ID sinnvoller ist: Sollen nebst linkedosmdb_id=... weitere Keys zugelassen sein (gegeben sie sind ebenfalls nicht-zusammengesetzt und als ID erkennbar und erheben ebenfalls den Anspruch, stabil zu sein, wie eben bestimmte Objekt mit name=...) ? Wie gesagt, fuer mich ist die Gesamtheit aller Eigenschaften der potentielle Key eines Objekts, und wenn diese Gesamtheit nicht ausreicht, um das Objekt zu identifizieren, dann ist dieses Objekt auch nicht des Identifizierens wuerdig. Wie oben gesagt, finde ich die Relevanz-These (identifizierwürdige-Parkbänke-müssen-ein-besonderes-Merkmal-haben) etwas gewagt. Die Gesamtheit aller Eigenschaften, sprich Tags, kann doch im selben Objekt über die Zeit variieren, ohne dass sich das Objekt der Realität auch nur im
