[Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/14513 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/14514 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/49832 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/139010 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/286579 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/287329 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/309667 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/386372 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387016 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387017 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387018 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/387019 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/537013 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/931861 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/931868 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/1083522 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1140728 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1205863 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1261837 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1371268 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1375654 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1375655 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1397371 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1663158 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1663265 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1796918 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1830532 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1936209 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1965464 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1967770 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/2086710 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2088552 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2124581 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2125551 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2125556 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2127399 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2127400 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2225347 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2248138 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2265093 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2274083 turn restriction: from member missing ways phase OSM Warning:http://www.openstreetmap.org/browse/way/26281268 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/30248605 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/33514160 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/34293887 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/52513873 Broken polygon, less than 3 points defined OSM
Re: [Talk-de] Zurueck in die Steinzeit
aighes-2 wrote ..Viel zu kompliziert...bei einer Anfahrtskizze tut es schon ein Screenshot der Karte. Klar, in diesem Falle eine gute, machbare Lösung. Ich bin in meinem netten Kommentar auch davon ausgegangen, dass es sich wirklich nur um eine kleine Anfahrtskizze handelt - da wäre ein eigener Server wohl etwa oversized. Wenn aber auf dieser kleine Skizze Sachen fehlen (bot) oder falsch sind, könnte der Hauptbenutzer seine Ecke schon ein wenig pflegen. Kriegt der Enkel auch ohne Josm hin ;) Ein Screenshot hilf *jetzt* natürlich wenig. Gruss Walter -- View this message in context: http://gis.19327.n5.nabble.com/Zurueck-in-die-Steinzeit-tp5716989p5717792.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am Sonntag, den 22.07.2012, 12:27 +0200 schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris Hi, ist doch eigentlich egal. Bei den ersten beiden wurde doch beim letzten Edit von bigboss die from - rules entfernt, weil er den Weg gelöscht hat. Oder tarnt sich so jetzt der Redaction-Bot?? ;-)) Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am Sunday 22 July 2012 schrieb Jörg Frings-Fürst: Am Sonntag, den 22.07.2012, 12:27 +0200 schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris Hi, ist doch eigentlich egal. Bei den ersten beiden wurde doch beim letzten Edit von bigboss die from - rules entfernt, weil er den Weg gelöscht hat. Oder tarnt sich so jetzt der Redaction-Bot?? ;-)) Hallo, die Daten habe ich von http://download.geofabrik.de/osm/europe/germany/baden-wuerttemberg.osm.bz2 heute morgen gezogen. Bin nicht sich, wann der Bot lief/läuft. Danke und Gruß Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM Warnungen beim Erzeugen einer Navit Karte (Bayern)
Hallo, hier die äquivalenten Warnungen für die Karte von Bayern: Turn relations: OSM Warning:http://www.openstreetmap.org/browse/relation/59134 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/59145 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/104598 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/142128 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/160853 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/160854 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/272268 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/372902 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/372903 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/419133 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/443898 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/448952 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/962893 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/324 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1210983 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1210990 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1283234 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1389766 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1413735 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1436728 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1436729 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1436730 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1659670 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1664369 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1672888 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1694364 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1838433 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1838437 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1958873 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1964615 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2008304 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/2017124 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2026076 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2026907 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2047728 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2047729 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2048371 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/2076363 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2080660 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2119351 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2173224 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/2273793 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2280169 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2282465 turn restriction: via member missing Polygone: OSM Warning:http://www.openstreetmap.org/browse/way/24897296 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/25660084 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/28149073 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/28236618 Broken
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
Am 22.07.2012 12:27, schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Eigentlich egal, so und so gehört der Fehler behoben. LG Jimmy PS: Ich halte die Daten für nützlich. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM warning in navit map generation (Baden-Wuerttemberg)
On 22/07/12 17:32, Jimmy_K wrote: Am 22.07.2012 12:27, schrieb Chris66: Am 22.07.2012 10:05, schrieb Rainer Dorsch: Hello, I got some warnings in the navit map conversion process for Baden- Wuerttemberg. In case it is not useful, please let me know, and I will not post again theses kind of data turn restrictions: Hi, nützlich wäre es noch zu wissen ob Du hier Post- oder Pre-Redaction Data verarbeitet hast... ;-) Chris Eigentlich egal, so und so gehört der Fehler behoben. +1 LG Jimmy PS: Ich halte die Daten für nützlich. Ich auch und habe begonnen die Abbiege-Relationen von unten nach oben zu reparieren. Die meisten welche ich nicht reparieren kann sind user faults Grüße fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)
Hallo, hier die Warnungen für die Österreich: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/92427 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/223509 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/241646 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278859 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278860 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278862 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/302959 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/311734 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/535236 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1318143 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1476938 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1485409 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1492801 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1506472 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1527515 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1683246 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696176 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696177 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1733647 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1779147 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1790945 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1857345 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1866773 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/2090704 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2130728 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1389144 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/1389152 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2102804 turn restriction: to member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2182619 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/34495781 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/44840922 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/51852521 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/72765511 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/101693601 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/116909398 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/123449371 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/151237729 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/162979331 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/165962199 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/169695178 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/171490446 Broken polygon, less than 3 points defined -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Österreich)
Hallo Reiner, bin in talk-cz drin, falls es Ähnliches für die Tschechei gibt, kann es einfach weiterleiten. On Sun, Jul 22, 2012 at 8:25 PM, Rainer Dorsch m...@bokomoko.de wrote: Hallo, hier die Warnungen für die Österreich: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/92427 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/223509 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/241646 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278859 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278860 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/278862 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/302959 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/311734 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/535236 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1318143 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1476938 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1485409 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1492801 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1506472 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1527515 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1683246 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696176 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1696177 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1733647 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/1779147 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1790945 turn restriction: via member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1857345 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1866773 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/2090704 turn restriction: multiple via member OSM Warning:http://www.openstreetmap.org/browse/relation/2130728 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1389144 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/1389152 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2102804 turn restriction: to member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2182619 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/34495781 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/44840922 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/51852521 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/72765511 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/101693601 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/116909398 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/123449371 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/151237729 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/162979331 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/165962199 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/169695178 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/171490446 Broken polygon, less than 3 points defined -- Rainer Dorsch http://bokomoko.de/ ___ 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] Zurueck in die Steinzeit
Bernd Wurst wrote: Kannst Du Dir vorstellen das es neben auf dem Egotrip sein für Jeden individuell verschiedene und sachlich begründete Fakten gab die ihn von der Zustimmung abhielten? Da Importe von Drittdaten normalerweise immer unter einem dafür angelegten Benutzernamen gemacht wurden und daher jeder natürliche Benutzer auch wirklich die Rechte an seinen Änderungen hält: Eigentlich nicht. Mir ging es nicht um Importe. Ich meinte mehr das sich möglicherweise Mapper ganz bewußt gegen die Lizenzänderung aussprechen und dafür individuelle Gründe haben, die wir beide nicht kennen. Das, was es hier zerhauen hat, kann ich sogar mit hoher Warscheinlichkeit einem sehr frühen Mapper zuordnen. Der hat hier studiert und die halbe Stadt ganz alleine gemacht. Danach hat ihn OSM wohl nicht mehr interessiert, die Lizenzgeschichte dürfte komplett an ihm vorbei gegangen sein. Egotrips sind das nicht. Straßen hängen komplett in der Luft. Plural? Es war eine. Und die ways waren noch da, nur ohne Tags. Ich habe die Tags wieder dran gepappt. Ja, das war mehr es sieht hier an vielen Stellen so aus. Egal, Du hast es repariert, danke. Da war wohl jemand schneller. Ich sehe da keine Probleme. Es hat an allen von mir genannten Stellen der immer gleiche User gearbeitet und wenn ich in dessen Bearbeitungshistorie schaue hoffe ich, er kennt sich in ganz Deutschland tatsächlich so gut aus wie seine Edits erkennen lassen... Die Wege bzw. ihre Nodes waren vorhanden, habe residentials draus gemacht. Könntest du mit deiner Ortskenntnis bitte noch die Straßennamen eintragen? Ja, aber nicht sofort und nicht die nächsten Wochen. Ich muß da _hin_ und das Schild ablesen. So klein sind wir hier nicht, dass ich jeden Straßennamen kenne. Die Paul-Jäkel-Straße hat der Bot verhauen, die Erzberger Straße sieht wegen einsturzgefährdeter Brücke tatsächlich so aus! Jetzt warte ich schon gespannt wann der erste Bing-Mapper kommt und repariert. Und dann auf den Nächsten, der das korrigiert. Bis wieder ein Bing-Mapper kommt und repariert, weil es doch so nach dem typischen Bot-löschen aussieht. Nun, das kann man ganz einfach beheben, indem man die Brücke (die laut deiner Aussage ja im Prinzip noch da ist) einfach einträgt als gesperrt. Durch die schon vorhandenen noexit-tags war das deutlich zu sehen wie du es beschrieben hast, ich hab die Brücke jetzt noch eingetragen. Und die Paul-Jäkel-Straße habe ich auch repariert. Ja, das war jetzt so einfach weil Du die Daten von mir hattest. Ich stieß mich an Deiner Aussage, das sei alles problemlos mit Bing zu reparieren. Dann hast du ja bestimmt deine Aufzeichnungen noch. Da kann ich am Luftbild nicht erkennen wie das sein sollte. Ähm, nein. ich weiß nicht wie andere Mapper arbeiten. Ich fahre da hin, habe dann einen GPX-Track, mache ggf. paar Bilder von Straßenschildern usw. Wenn ich das alles eingegeben habe sind Fotos von Straßenschildern jetzt nicht so von weiterem Wert für mich und ich lösche das. Die GPX-Daten liegen ganz sicher mit chronologischem Dateinamen hier rum, aber ich merke mir nicht wann ich wo war und was ich danach dort editiert habe. Auf die Idee das meine Daten derartige Löschorgien überstehen müssen bin ich damals nicht gekommen. Ist halt die Frage des Anspruchs. Klar, viele Attribute, Oberflächenbeschreibungen und so sind super. Werden aber momentan nicht wirklich irgendwo benutzt. Schau mal in die Stylefiles der MTBMap oder der Velomap... Und wer noch alles diese Daten benutzt hat wissen wir gar nicht. Natürlich hast Du Recht, rudimentäres Routing ist auch ohne surface=asphalt usw. drin. aktualisiert nutzt dann in ein paar Tagen wieder den korrigierten Bestand. Den Optimismus teile ich nicht. IMHO werden es wohl eher Monate werden. Die, die den Götz von Berlichingen machen und nie wieder aktiv werden weil sie mit diesem Umgang mit der Arbeit, die sie in ihrer Freizeit leisteten, nicht einverstanden sind, noch gar nicht mitgerechnet. LG, Jörg -- There are only 10 types of people in the world: Those who understand binary, and those who don't... signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Hallo, hier die Warnungen für die Schweiz: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/169051 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/169052 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/169053 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/410435 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/043 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300520 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300522 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300523 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300524 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300525 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1342961 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1756112 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1832623 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082534 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082535 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2266273 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2296937 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1853786 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2019001 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/38696067 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/50759439 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/50760438 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/159742530 Broken polygon, less than 3 points defined -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdor...@web.de jabber: rdor...@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Könnt ihr das bitte mal sein lassen, diese Fehler alle hier zu posten. Die allermeisten Leute auf dieser Liste interessiert das nicht die Bohne. Wenns sein muss, macht halt ne Wiki-Seite oder findet sonst einen Platz dafür. Jochen On Sun, Jul 22, 2012 at 09:03:22PM +0200, Rainer Dorsch wrote: Date: Sun, 22 Jul 2012 21:03:22 +0200 From: Rainer Dorsch m...@bokomoko.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Subject: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz) Hallo, hier die Warnungen für die Schweiz: turn restrictions: OSM Warning:http://www.openstreetmap.org/browse/relation/169051 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/169052 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/169053 turn restriction: multiple from members OSM Warning:http://www.openstreetmap.org/browse/relation/410435 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/043 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300520 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300522 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300523 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300524 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1300525 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1342961 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1756112 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/1832623 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082534 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2082535 turn restriction: to member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2266273 turn restriction: from member missing OSM Warning:http://www.openstreetmap.org/browse/relation/2296937 turn restriction: multiple to members OSM Warning:http://www.openstreetmap.org/browse/relation/1853786 turn restriction: from member not found OSM Warning:http://www.openstreetmap.org/browse/relation/2019001 turn restriction: from member not found polygon Warnungen: OSM Warning:http://www.openstreetmap.org/browse/way/38696067 Broken polygon, area is 0 OSM Warning:http://www.openstreetmap.org/browse/way/50759439 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/50760438 Broken polygon, less than 3 points defined OSM Warning:http://www.openstreetmap.org/browse/way/159742530 Broken polygon, less than 3 points defined -- Rainer Dorsch Lärchenstr. 6 D-72135 Dettenhausen 07157-734133 email: rdor...@web.de jabber: rdor...@jabber.org GPG Fingerprint: 5966 C54C 2B3C 42CC 1F4F 8F59 E3A8 C538 7519 141E Full GPG key: http://pgp.mit.edu/ -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- 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
[Talk-de] Permanente/stabile OSM IDs!
Hallo Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken. 2012/7/22 Sarah Hoffmann lon...@denofr.de schrieb in einer Diskussion auf talk-ch: On Sun, Jul 22, 2012 at 01:40:48PM +0200, Stefan Keller wrote: ... What remains to me is the following, since I'm having in mind OSM which is more and more related to external databases. First, I'm still convinced that the principle of update (versus delete and recreate) should hold also for OSM. Second, we seem to have a problem with stable id's in OSM (osm_id). Having external id's in OSM now seems to me like a necessity (in order to become related to external dbs) and a concession to the fact the OSM doesn't have stable ids. At least it's also an indication or flag to OSM users. One of the big TODOs of OSM. Closest thing we have at the moment is Rolands proposal base on the Overpass API: http://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID Problem is that it is pretty hard to define what is 'stable' in the context of OSM. How should splitting of ways be handled? What if a shop moves to the next building? What if we split the bus stops into two, one for each direction? So, we actually end up with a n-to-n relation: one OSM object might have multiple UIDs (for the shop, for the building, for the address...) and a UID might reference multiple OSM objects (split ways). Sarah 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. Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig, dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch verlängert oder ein Node eingefügt, dann hoffentlich auch nicht! Im oben erwähnten Fall wird ein - zunächst als ein bus_stop erfasste - Busstation in zwei bus_stops aufgeteilt, weil das eher der Realität entspricht. Oder es wird ein Way gesplittet wird (wenigstens bleibt dann die ID typischerweise erhalten). In diesen Fällen lässt sich auch mit nicht-technischen Argumenten debattieren, ob das nun ein Update oder ein Delete/Create ist! Daher: 2. OSM ID's sind grundsätzlich stabil! Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. 3. Projekt-ID Tag als Lösung? Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ich finde den Vorschlag gut - man muss sich aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem der offenbar unvermeidbaren menschlich- und technischen Unzulänglichkeiten nicht löst. Es kommen immer wieder Fälle vor, wo eine ID ungewollt untergeht und wo man als OSM-externe Datenbank (z.B. als Projekt wie http://wiki.openstreetmap.org/wiki/OpenMetaMap ) dann situativ darauf reagieren muss. Fälle wie der Lizenzwechsel müssen sowieso separat gelöst werden. Es kann auch vorkommen, dass am (zu einer ID kombinierten) Tag network=BAB+ref=A 516 etwas geschieht, z.B. wenn ein jemand (inkl. ein Tool) findet, ref=A 516 sei doch ref=A516 - also A516 ohne Space! Das Problem solcher eindeutigen Eigenschaften eines Objekts scheint mir, dass solch sprechende IDs nichts taugen - und es ist erst noch nicht an den Keynamen network+ref erkenntlich, dass sie überhaupt IDs bilden. Das ist genau der Unterschied zwischen Schlüssel und Identifikator! Mir scheint nichts anderes übrig zu bleiben, als entweder mit der OSM ID zu leben (und deren Stabilität laufend zu verbessern!) - oder aber folgendes: Eine OSM-externe Datenbank vergibt einen eigenen und für sie eindeutigen ID-Tag in OSM, die nicht-sprechende Identifikatorwerte erhalten, z.B. unserprojekt:id=10001 oder unserprojekt_id=10001. D.h. keine Kombination und keine normal aussehende Keys, sondern einen einzigen in OSM klar als ID erkennbaren Key. Der feine Unterschied zu network+ref
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Am Sunday 22 July 2012 schrieb Jochen Topf: Könnt ihr das bitte mal sein lassen, diese Fehler alle hier zu posten. Die allermeisten Leute auf dieser Liste interessiert das nicht die Bohne. Wenns sein muss, macht halt ne Wiki-Seite oder findet sonst einen Platz dafür. Jochen, entschuldige, aber kein Grund zur Sorge, ich habe keine weiteren Daten mehr :-) Da einige Leute Interesse an den Daten gezeigt haben, werde ich sie wenn immer ich welche habe (erwarte etwa alle 2 Monate im Schnitt) zur Verfügung stellen. Ich werde eine Summary-Mail mit Links schicken, anstelle von den Einzelmails. Viele Grüße Rainer -- Rainer Dorsch http://bokomoko.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hi Stefan, Stefan Keller schrieb: Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken. ich denke du suchst sowas in der Art, oder? Dauerhafte Links nach OSM - Overpass API http://blog.openstreetmap.de/2012/03/dauerhafte-links-nach-osm/ viele gruesse pascal ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Am 22.07.2012 21:25, schrieb Rainer Dorsch: Am Sunday 22 July 2012 schrieb Jochen Topf: Könnt ihr das bitte mal sein lassen, diese Fehler alle hier zu posten. Die allermeisten Leute auf dieser Liste interessiert das nicht die Bohne. Wenns sein muss, macht halt ne Wiki-Seite oder findet sonst einen Platz dafür. Jochen, entschuldige, aber kein Grund zur Sorge, ich habe keine weiteren Daten mehr :-) Da einige Leute Interesse an den Daten gezeigt haben, werde ich sie wenn immer ich welche habe (erwarte etwa alle 2 Monate im Schnitt) zur Verfügung stellen. Ich werde eine Summary-Mail mit Links schicken, anstelle von den Einzelmails. Deutlich besser: Mach eine Liste draus, zerhacke sie in sinnvolle Paketgrößen und pack sie auf eine Wiki-Seite. Wie bei anderen ähnlichen Aktionen üblich. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPX-Dateien wiederfinden (was: Zurueck in die Steinzeit)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 22.07.2012 20:50, Joerg Fischer wrote: Die GPX-Daten liegen ganz sicher mit chronologischem Dateinamen hier rum, aber ich merke mir nicht wann ich wo war und was ich danach dort editiert habe. Hallo Jörg, falls Du in Deinen GPX-Dateien die richtigen herausfinden möchtest, probiere mal in JOSM das Plugin openvisible. (Kann aber bei einer großen Menge an Dateien lange dauern, bis JOSM alle untersucht und die richtigen gefunden hat.) Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAlAMXDcACgkQnMz9fgzDSqd41ACfTGo0NKTg1MNKcc/h767mHKNo c3oAn2uhqHz4rXEWG4bSwHrMBX9rwwCN =d7k0 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zurueck in die Steinzeit
Am 22.07.2012 20:50, schrieb Joerg Fischer: Bernd Wurst wrote: Ist halt die Frage des Anspruchs. Klar, viele Attribute, Oberflächenbeschreibungen und so sind super. Werden aber momentan nicht wirklich irgendwo benutzt. Schau mal in die Stylefiles der MTBMap oder der Velomap... Und wer noch alles diese Daten benutzt hat wissen wir gar nicht. Natürlich hast Du Recht, rudimentäres Routing ist auch ohne surface=asphalt usw. drin. Ack aktualisiert nutzt dann in ein paar Tagen wieder den korrigierten Bestand. Den Optimismus teile ich nicht. IMHO werden es wohl eher Monate werden. Die, die den Götz von Berlichingen machen und nie wieder aktiv werden weil sie mit diesem Umgang mit der Arbeit, die sie in ihrer Freizeit leisteten, nicht einverstanden sind, noch gar nicht mitgerechnet. Den Götz mache ich gar nicht. Aber in der Zeit, als hier in der Gegend OSM im wesentlichen aus ein paar (oft fehlerhaften) Durchgangsstraßen und Autobahnen bestand, habe ich etliche Tankfüllungen vergurkt, mich in Schneewehen festgefahren und manches mal geschwitzt, daß mich keiner anmoppert, weil ich auch mal diverse Zufahrtsbeschränkungen ignoriert habe. Hatte ja ein Anliegen :-) Das tue ich mir nicht nochmal von vorne an. -- Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Am 22.07.2012 21:38, schrieb Jo: Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche spezifischen Tags an Objekte hängt? Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und ein neues ohne all die ref-Tags erstellt? Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
schau dir mal die sache mit den uuids an. ich glaube, dass das ein interessanter Ansatz ist. https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID von diesem thread find ich gerade nicht den anfang: http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html uuid für osm geistert schon lange bei uns rum, ist aber irgendwie eingeschlafen. Gruss walter p.s. sorry, bin gerade knapp dran mit zeit. -- View this message in context: http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Stefan. Ich glaube, du hast dir da direkt ein schwierigeres Thema rausgesucht - und ich hab dazu sicher auch keine perfekte Lösung. Den Ansatz der Overpass-API hast du ja schon mit aufgelistet, und ich halte ihn für momentan den am ehesten praxistauglichen. Deine anderen Ideen kritisiere (bitte nicht übelnehmen) ich mal zwischen deinem Text: Am 22.07.2012 21:22, schrieb Stefan Keller: 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs ungewollt/unfreiwillig? Nehmen wir an, ich trage einen Supermarkt als Node ein - ein gängiger Weg, wenn ich keine Luftbilder zur Verfügung habe. Beim Hochladen bekommt dieser Supermarkt die Id node 42 - denn osm hat ja für nodes, ways und relations getrennte id-räume. Jetzt kommst du und hast 'n Luftbild, willst den supermarkt also besser eintragen als Polygon: Wenn/da du weißt, dass ids zum verlinken genutzt werden könnten, benutzt du den alten node als startknoten des gebäudepolygons und kopierst die daten auf das polygon. Der way hat jetzt eine ID way23 - und die id node42 kann er auch gar nicht kriegen, das hat mit dem editor nichts zu tun. Wenn eine Software aber zur ID node42 verlinkt, wird er z.B. die Öffnungszeiten nicht mehr finden können, denn die hängen jetzt korrekterweise am way23. Eine Korrektur hin zu stabilen ObjektIDs ist also mit der aktuellen API nicht machbar - und vermutlich auch so ohne weiteres dauerhaft nicht zu lösen, denn: - Ich trage das Gebäude Mozartstraße 3 als Polygon way323 ein mit building=yes, amenity=doctors. - Eine Datenbank D verlinkt das Gebäude (way323), um die Arztpraxis von Dr. OSM zu markieren. - Du verbesserst OSM und trägst die drei Arztpraxen von Dr. OSM, Dr. Etsch und Dr. doofe-IDee als einzelne nodes ein. Auf einmal ist zwar das ursprüngliche polygon noch da, aber das ist gar nicht das, was die externe datenbank meinte - die verlinkt immer noch zum damals am besten passenden Objekt. Das war zwar vorher schon eine Arztpraxis, aber eben noch ungenau, die drei arztpraxen wurden als eine abgebildet. 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 stimmt nicht, wenn du den node nur verschiebst. Dafür musst du ihn kopieren und einfügen. Das ist aber kein logisch zwingender Grund, sondern technischer Mangel. Nein. Nur eine andere Interpretation dessen, was richtig ist, als du sie annimmst. Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig, dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch verlängert oder ein Node eingefügt, dann hoffentlich auch nicht! Im Sinne stabiler IDs: Wenn ein way das Tag highway=residential verliert und jetzt auf einmal stattdessen building=yes bekommt, dann ist das ein neues Objekt. Wenn dagegen highway=residential durch highway=pedestrian ausgetauscht wird, ist die Straße im Grunde die gleiche geblieben. 2. OSM ID's sind grundsätzlich stabil! Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. Guck dir alle Städte an, die bisher noch Hausnummern in Form von Nodes enthalten, verschaff denen aktive Mapper mit etwas Langeweile und gute Luftbilder - und schon sind deine alten Nodes weg und unter neuen IDs die gleichen Hausnummern in Form von Gebäudepolygonen drin - tausendfach. 3. Projekt-ID Tag als Lösung? Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ich finde den Vorschlag gut - man muss sich aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem der offenbar unvermeidbaren menschlich- und technischen Unzulänglichkeiten nicht löst. Es kommen immer wieder Fälle vor, wo eine ID ungewollt untergeht und wo man als OSM-externe Datenbank (z.B. als Projekt wie http://wiki.openstreetmap.org/wiki/OpenMetaMap ) dann situativ darauf reagieren muss. Fälle wie der Lizenzwechsel müssen sowieso separat gelöst werden. Es kann auch vorkommen, dass am (zu einer ID kombinierten) Tag network=BAB+ref=A 516 etwas geschieht, z.B. wenn ein jemand (inkl. ein Tool) findet, ref=A 516 sei doch ref=A516 - also A516 ohne Space! Das Problem solcher eindeutigen Eigenschaften eines Objekts scheint mir, dass solch sprechende IDs nichts taugen - und es ist erst noch nicht an den Keynamen network+ref erkenntlich, dass sie überhaupt IDs bilden. Das ist genau der Unterschied zwischen Schlüssel und Identifikator! Die stabile ID, die die overpass-ID einführt, ist eben keine ID im eigentlichen Sinne, sondern eine
Re: [Talk-de] Warnungen beim Erzeugen einer Navit Karte (Schweiz)
Am 22.07.2012 21:34, schrieb aighes: Deutlich besser: Mach eine Liste draus, zerhacke sie in sinnvolle Paketgrößen und pack sie auf eine Wiki-Seite. Wie bei anderen ähnlichen Aktionen üblich. Würde ich auch besser finden. Ich halte solche Listen zwar grundsätzlich schon für hilfreich, aber habe jetzt natürlich keine Ahnung, ob schon jemand Einträge darauf abgearbeitet hat, und wenn ja welche. Sollte nächstes Mal besser wie eine der älteren Aktionen im Wiki aufgezogen werden: http://wiki.openstreetmap.org/wiki/Aktionen Und dann _eine_ Mail mit Link auf die entsprechende Wikiseite schicken. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Pascal Am 22. Juli 2012 21:30 schrieb Pascal Neis pascal.n...@gmail.com: Hi Stefan, Stefan Keller schrieb: Mich beschäftigt seit einiger Zeit die Frage von permanenten/stabilen OSM IDs und der Verknüpfung von OSM mit anderen Datenbanken. ich denke du suchst sowas in der Art, oder? Dauerhafte Links nach OSM - Overpass API http://blog.openstreetmap.de/2012/03/dauerhafte-links-nach-osm/ Jein; das Problem dieses Vorschlags ist, dass er zusammengesetzte, z.T. sprechende Schlüssel vorschlägt. Vgl. meine Ausführungen unten. LG, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID Am 22.07.2012 22:19, schrieb Walter Nordmann: schau dir mal die sache mit den uuids an. ich glaube, dass das ein interessanter Ansatz ist. https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID von diesem thread find ich gerade nicht den anfang: http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html uuid für osm geistert schon lange bei uns rum, ist aber irgendwie eingeschlafen. Gruss walter p.s. sorry, bin gerade knapp dran mit zeit. -- View this message in context: http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.html Sent from the Germany mailing list archive at Nabble.com. ___ 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] Permanente/stabile OSM IDs!
Hallo Jo/aighes und Henning Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Am 22.07.2012 21:38, schrieb Jo: Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Fast genau: Ich aber statt ref:myproject=(foreign key) lieber schreiben ref:myproject=(unser_projekt_OSM_ID). Der Unterschied ist minim, denn ich will der OSM nicht meine Objekt unterjubeln, sondern das OSM Objekt in unserer externen DB verwenden und den Mappern gleichzeitig signalisieren, dass es dieses externe Projekt gibt. Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche spezifischen Tags an Objekte hängt? Also nochmals um das klarzustellen: Anwendungen, die mit der OSM ID wie sie jetzt ist klarkommen, brauchen nichts zu tun. Anwendungen hingegen, die OSM nicht mit eigenen Daten belasten und z.B. selber weitere Attribute verwalten wollen, sind auf (für sie) permanente/stabile/dauerhafte OSM IDs angewiesen. Dazu dient dieser Vorschlag. Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und ein neues ohne all die ref-Tags erstellt? Das würde in meinem Fall ein Achtung da hat jemand unser Objekt gelöscht signalisieren und er müsste dem nachgehen, was Sache ist. Jedenfalls hoffe ich nicht, dass es unlautere Absichten sind, denn bestehende Tags sollten ja erhalten bleiben, wenn das Objekt z.B. nur verschoben wird (vgl. das DIDOK-Beispiel oben). Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Verstehe ich nicht. Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine Datenbank für alle sein kann und einfach vollgestopft werden soll mit Tags, die von externen Projekten kommen. Der einzige Tag den ich vorschlage ist diese eine Projekt_ID. LG, S. Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Am 22.07.2012 21:38, schrieb Jo: Ich würde auch ein Tag wie ref:myproject=(foreign key) benutzen. Ich habe vor einige Tage aber irgendwo gelesen dass das auch nicht gewunscht sei. Das ist ja nun auch großer Käse...wie viel Anwendungen gibt es, die mit OSM-Daten arbeiten...Wo soll das enden, wenn jede Anwendung irgendwelche spezifischen Tags an Objekte hängt? Und was bringt es, wenn jemand das Objekt mit samt dem raf-Tag löscht und ein neues ohne all die ref-Tags erstellt? Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Henning ___ 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] Permanente/stabile OSM IDs!
Am 22.07.2012 21:22, schrieb Stefan Keller: Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. Viele Bearbeitungsoperationen kann man in der Tat so durchführen, dass eine ID erhalten bleibt, aber das ist keine Garantie, dass ein Mapper auch diesen Weg wählen wird - und es gibt auch keine Pflicht, das zu tun. Zudem gibt es Änderungen der Darstellungsform (Umbau von Node auf Fläche, oder von geschlossenem Way auf Relation), bei denen der Erhalt einer ID schon vom Prinzip her nicht möglich ist. Ebensowenig kann etwa beim Auftrennen eines der Ways einer Straße die Liste der IDs für die Straße erhalten bleiben. Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ich finde den Vorschlag gut - man muss sich aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem der offenbar unvermeidbaren menschlich- und technischen Unzulänglichkeiten nicht löst. Es ändert schon etwas: IDs sind versteckte Eigenschaften, die der Mapper bedenkenlos ändern darf und oft wird. Tags sind hingegen Eigenschaften, bei denen beim Bearbeiten klar sein sollte, dass das nach außen, also für Datennutzer, Folgen haben wird und man sich daher beim Ändern Gedanken machen muss. Mein Minimalvorschlag ist, dass nur eine klar am Tagnamen erkennbare projektspezifische ID eingeführt wird, die niemals mehr verändert wird (ausser sie geht mit dem OSM Objekt unter). Die externe Datenbank verwaltet die Beziehung zwischen ihren Objekten und dem so bezeichneten OSM-Objekt selber. Bei OpenMetaMap steht zurzeit OSM ID (für keyA bzw. Object ID); da wäre nun nur noch eine openmetamap_osm_id nötig. Diese Option scheitert schon daran, dass es auf lange Sicht zu viele Datenbanken geben dürfte, die mit OSM interagieren wollen. Das geht gut, solange es sich um einige wenige, bekannte Projekte handelt - z.B. bei den existierenden Wikipedia-Links -, aber wenn jetzt außer Flickr noch dutzende weitere kommerzielle Fotoportale OSM-Verlinkungen einführen wollen, würden diese Tags ausufern. Es ist außerdem auch nicht klar, welche Eigenschaft dem Verlinker nun wichtig ist. Wenn ein Restaurant umzieht, ist es dann noch dasselbe Restaurant? Die Definition von dasselbe ist vermutlich für jedes der verlinkten Projekte anders, und man kann nicht erwarten, dass der Mapper die Kriterien jedes der Projekte kennt. Bei einer Query hingegen ist das ganz automatisch definiert - da müssen in der Query eben genau die Eigenschaften eingebaut sein, die für den Verlinker das Objekt ausmachen. Von daher denke ich weiterhin, dass die Identifikation über Eigenschaften aus der realen Welt (was auf geeignete Queries in z.B. Overpass hinausläuft) die richtige Lösung ist. Solche Probleme wie dein Beispiel mit Leerzeichen sind vorhersehbar, so dass man sich in vielen Fällen darauf vorab einstellen kann. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche OSM-ID schon ändert. Was am meisten bestand hat, sind IDs aus offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich: Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt wurden. Es gibt auch für jede Straße eine offizielle ID (die man z.B. bei der Fahrrad-Kodierung verwendet) oder halt auch für jede Ortschaft. Das bedeutet aber, dass man da erstmal einen externen Katalog finden muss. Natürlich ginge es auch eine ID aus einem eigenen Katalog zu verpassen, um es mit dem eigenen Projekt zu verknüpfen, jedoch bevorzuge ich schon offizielle Identifikationsmerkmale, und nicht zig ref:*=* zu ein und dem selben Objekt Der Übersichtlichkeit wegen ;). MfG Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Simon 2012/7/22 Simon Poole si...@poole.ch: Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID Das wäre genau so eine Projekt ID, die ich meinte! Stefan 2012/7/22 Simon Poole si...@poole.ch: Nur mal zum über den Hag schauen: http://en.wikipedia.org/wiki/TOID Am 22.07.2012 22:19, schrieb Walter Nordmann: schau dir mal die sache mit den uuids an. ich glaube, dass das ein interessanter Ansatz ist. https://wiki.openstreetmap.org/wiki/Proposed_Features/UUID von diesem thread find ich gerade nicht den anfang: http://www.mail-archive.com/talk@openstreetmap.org/msg30181.html uuid für osm geistert schon lange bei uns rum, ist aber irgendwie eingeschlafen. Gruss walter p.s. sorry, bin gerade knapp dran mit zeit. -- View this message in context: http://gis.19327.n5.nabble.com/Permanente-stabile-OSM-IDs-tp5717856p5717870.html Sent from the Germany mailing list archive at Nabble.com. ___ 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo Peter Am 22. Juli 2012 22:30 schrieb Peter Wendorff wendo...@uni-paderborn.de: ... Nehmen wir an, ich trage einen Supermarkt als Node ein - ein gängiger Weg, wenn ich keine Luftbilder zur Verfügung habe. Beim Hochladen bekommt dieser Supermarkt die Id node 42 - denn osm hat ja für nodes, ways und relations getrennte id-räume. Jetzt kommst du und hast 'n Luftbild, willst den supermarkt also besser eintragen als Polygon: Das ist ein interessanter Fall, der mir auch von (Einzel-)Parkplätzen und (Einzel-)Bäumen etc. bekannt ist. Meine/unsere externe DB sollte sich da vorher schon klar gemacht haben, bevor sie die Projekt-IDs in OSM einträgt, ob sie Supermärkte (oder was auch immer) nun als Punkte oder Flächen (oder beides) modelliert. Je nachdem wird dann darauf reagiert. LG, Stefan Am 22. Juli 2012 22:30 schrieb Peter Wendorff wendo...@uni-paderborn.de: Hallo Stefan. Ich glaube, du hast dir da direkt ein schwierigeres Thema rausgesucht - und ich hab dazu sicher auch keine perfekte Lösung. Den Ansatz der Overpass-API hast du ja schon mit aufgelistet, und ich halte ihn für momentan den am ehesten praxistauglichen. Deine anderen Ideen kritisiere (bitte nicht übelnehmen) ich mal zwischen deinem Text: Am 22.07.2012 21:22, schrieb Stefan Keller: 1. Sind OSM ID's wirklich instabil? bzw. Wann ändern IDs ungewollt/unfreiwillig? Nehmen wir an, ich trage einen Supermarkt als Node ein - ein gängiger Weg, wenn ich keine Luftbilder zur Verfügung habe. Beim Hochladen bekommt dieser Supermarkt die Id node 42 - denn osm hat ja für nodes, ways und relations getrennte id-räume. Jetzt kommst du und hast 'n Luftbild, willst den supermarkt also besser eintragen als Polygon: Wenn/da du weißt, dass ids zum verlinken genutzt werden könnten, benutzt du den alten node als startknoten des gebäudepolygons und kopierst die daten auf das polygon. Der way hat jetzt eine ID way23 - und die id node42 kann er auch gar nicht kriegen, das hat mit dem editor nichts zu tun. Wenn eine Software aber zur ID node42 verlinkt, wird er z.B. die Öffnungszeiten nicht mehr finden können, denn die hängen jetzt korrekterweise am way23. Eine Korrektur hin zu stabilen ObjektIDs ist also mit der aktuellen API nicht machbar - und vermutlich auch so ohne weiteres dauerhaft nicht zu lösen, denn: - Ich trage das Gebäude Mozartstraße 3 als Polygon way323 ein mit building=yes, amenity=doctors. - Eine Datenbank D verlinkt das Gebäude (way323), um die Arztpraxis von Dr. OSM zu markieren. - Du verbesserst OSM und trägst die drei Arztpraxen von Dr. OSM, Dr. Etsch und Dr. doofe-IDee als einzelne nodes ein. Auf einmal ist zwar das ursprüngliche polygon noch da, aber das ist gar nicht das, was die externe datenbank meinte - die verlinkt immer noch zum damals am besten passenden Objekt. Das war zwar vorher schon eine Arztpraxis, aber eben noch ungenau, die drei arztpraxen wurden als eine abgebildet. 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 stimmt nicht, wenn du den node nur verschiebst. Dafür musst du ihn kopieren und einfügen. Das ist aber kein logisch zwingender Grund, sondern technischer Mangel. Nein. Nur eine andere Interpretation dessen, was richtig ist, als du sie annimmst. Wenn nur die Way Tags ändern, dann sind sich hoffentlich alle einig, dass deswegen keine neue Way ID erzeugt wird. Wird ein Way geometrisch verlängert oder ein Node eingefügt, dann hoffentlich auch nicht! Im Sinne stabiler IDs: Wenn ein way das Tag highway=residential verliert und jetzt auf einmal stattdessen building=yes bekommt, dann ist das ein neues Objekt. Wenn dagegen highway=residential durch highway=pedestrian ausgetauscht wird, ist die Straße im Grunde die gleiche geblieben. 2. OSM ID's sind grundsätzlich stabil! Wenn ich mir diese Beispiele anschaue - und annehme, dass Tools (wie JOSM) korrekt arbeiten und richtig angewendet werden -, dann sehe ich keinen Anlass, die OSM ID's grundsätzlich als instabil zu bezeichnen. Ich lasse mich aber gern - bzw. weils's sein muss :- vom Gegenteil überzeugen. Guck dir alle Städte an, die bisher noch Hausnummern in Form von Nodes enthalten, verschaff denen aktive Mapper mit etwas Langeweile und gute Luftbilder - und schon sind deine alten Nodes weg und unter neuen IDs die gleichen Hausnummern in Form von Gebäudepolygonen drin - tausendfach. 3. Projekt-ID Tag als Lösung? Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ich finde den Vorschlag gut - man muss sich aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem der offenbar unvermeidbaren
Re: [Talk-de] Permanente/stabile OSM IDs!
Hallo, ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf die sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten bei OSM einschraenkt. Im rein hypothetischen Fall, dass OSM irgendwann einmal beschliessen sollte, seine Daten auf mehrere Server auf verschiedenen Kontinenten aufzuteilen und daher alle Objekte auf neue Server mit neuen Nummernraeumen verteilt, sollte das niemanden stoeren. Im rein hypothetischen Fall, dass OSM irgendwann alle existierenden Objekte umnumeriert, um nicht mehr genutzte Luecken wiederzuverwenden, sollte das keine Probleme verursachen. Im rein hypothetischen Fall, dass jemand einen Ort komplett loescht und neu einfuegt, sollte niemand davon etwas merken. Darauf hinzuarbeiten, dass OSM-IDs moeglichst stabil sein sollen, wuerde zugleich heissen, die Flexibilitaet der Mapper zu reduzieren, ihnen das Leben schwerer zu machen - m.E. keine gute Idee. UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der Link-Stabilitaet unseren Mappern aufbuerden. Ich finde, unser Mapper soll sich damit beschaeftigen, dass da ein Restaurant mit dem Namen X ist, und wenn das Restaurant umzieht auf die andere Strassenseite, dann loescht er das und legt es neu an, oder er schiebt es rueber, ganz wie es gerade am geeignetsten erscheint. Die UUID-Diskussion wurde schon oft gefuehrt, und es konnte meines Erachtens nie schluessig dargelegt werden, was die UUID genau sein soll. Eine UUID fuer die ganze Bachstrasse, oder eine fuer jeden Teil-Way? Wenn ich ein denkmalgeschuetztes Haus mappe und drin ist ein Restaurant, und ich gebe dem Way eine UUID, und spaeter zieht das Restaurant um auf die andere Strassenseite - woher weiss ich dann, ob ich die UUID mit umziehen muss (weil sie in einem Restaurantfuehrer verwendet wird) oder nicht (weil sie in einem Architekturfuehrer verwendet wird)? Aha, wir brauchen mehrere UUIDs pro Objekt, eine fuer jeden Aspekt... Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ich finde den Vorschlag gut - man muss sich aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem der offenbar unvermeidbaren menschlich- und technischen Unzulänglichkeiten nicht löst. Ich halte das fuer die beste Loesung, die wir haben, weil hier derjenige, der den Link setzt, entscheiden muss, was ihm wichtig ist, und die Mapper sich nicht damit herumschlagen muessen. Das Problem der unvermeidbaren Unzulaenglichkeiten wird dadurch nicht geloest, aber reduziert - wenn ich ein Restaurant loesche und auf der anderen Strassenseite neu zeichne, wird das immer noch gefunden. Eine OSM-externe Datenbank vergibt einen eigenen und für sie eindeutigen ID-Tag in OSM, die nicht-sprechende Identifikatorwerte erhalten, z.B. unserprojekt:id=10001 oder unserprojekt_id=10001. Nein, das halte ich nicht fuer akzeptabel, es hat die gleichen Probleme wie das UUID-Konzept. Was aber eine gute Idee waere: Man baut eine externe Datenbank als Interface zwischen der Oeffentlichkeit und OSM auf. Zur Oeffentlichkeit hin unterstuetzt diese Datenbank permanente Schluessel - seien das UUIDs oder Nummern oder sonstwas. Zu OSM hin benutzt diese Datenbank das Overpass-Permanent-ID-Konzept (das nicht von Roland erfunden wurde, sondern ursrpuenglich mal von Tim Alder mit seinem query to map angedacht worden war). Jeder kann bei Bedarf einen Link in dieser Datenbank anlegen lassen und den dann ueberall benutzen. Im Gegensatz zur reinen Verwendung von Overpass-IDs rund um die Welt hat dieses Vorgehen den Vorteil, dass alle Links in der Datenbank regelmaessig automatisiert ueberprueft werden koennen: Sind sie noch gueltig? Zeigen sie noch auf genau 1 Objekt, oder mittlerweile auf 0 oder 2? Es waere trivial, in dieser Datenbank eine Liste zu generieren mit allen kaputten Links; es waere sogar moeglich, diese nach Nutzungsintensitaet zu sortieren, so dass viel genutzte Links von Freiwilligen sofort repariert werden koennen, wenn sie kaputt gehen. Es waere sogar denkbar, in dieser Datenbank das letzte bekannte gute Ergebnis aus OSM zu cachen fuer jeden Link, so dass man, selbst wenn bei OSM was kaputt geht, dem Anfrager immer noch wenigstens eine alte Version ausliefern kann. Und das beste: Man muss OSM nicht mit seinen Privatkeys ueberfluten, um das machen zu koennen. 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] Permanente/stabile OSM IDs!
Am 22.07.2012 22:45, schrieb Stefan Keller: Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Verstehe ich nicht. Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine Datenbank für alle sein kann und einfach vollgestopft werden soll mit Tags, die von externen Projekten kommen. Der einzige Tag den ich vorschlage ist diese eine Projekt_ID. Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil gegenüber der normalen Objekt-ID. Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört, oder zu dem Objekt Restaurant. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge haben). In beiden Fällen kommt bei dem Projekt Unsinn an, der evtl. nicht bemerkt wird und wenn er bemerkt werden würde, dann würde er auch bemerkt, wenn man nach der OSM-ID gegangen wäre. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Permanente/stabile OSM IDs!
Hoi Andreas Am 22. Juli 2012 22:52 schrieb Andreas Neumann andr-neum...@gmx.net: Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche OSM-ID schon ändert. Genau. Siehe auch meine Antwort an Peter oben. Was am meisten bestand hat, sind IDs aus offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich: Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt wurden. Solch ein offizieller Katalog wären genau solch ein Projekt einer externen Datenbank. Meine Idee ist es nun aber, dass dieser Katalog weiterhin bestehen bleibt und nicht meint, er könne OSM mit einem Import beglücken und durch OSM ersetzt zu werden. Mein Vorschlag zielt darauf ab, dass diese Schulhäuser in OSM getaggt und wenn nötig/möglich eingetragen werden (sagen wir als Gebäudepolygone), OSM dann aber auch genutzt werden kann, um den Katalog aktuell zu halten. LG, Stefan Am 22. Juli 2012 22:52 schrieb Andreas Neumann andr-neum...@gmx.net: Schwierig, zumal bei Übetragungen von Node auf Way sich die eigentliche OSM-ID schon ändert. Was am meisten bestand hat, sind IDs aus offiziellen Katalogen. Diese sind dann aber Attributabhängig. Sprich: Es gibt m.W.n. IDs für Schulen in Hessen, die jetzt kräftig eingepflegt wurden. Es gibt auch für jede Straße eine offizielle ID (die man z.B. bei der Fahrrad-Kodierung verwendet) oder halt auch für jede Ortschaft. Das bedeutet aber, dass man da erstmal einen externen Katalog finden muss. Natürlich ginge es auch eine ID aus einem eigenen Katalog zu verpassen, um es mit dem eigenen Projekt zu verknüpfen, jedoch bevorzuge ich schon offizielle Identifikationsmerkmale, und nicht zig ref:*=* zu ein und dem selben Objekt Der Übersichtlichkeit wegen ;). MfG Andreas ___ 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] Permanente/stabile OSM IDs!
Hallo Henning (aighes) Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de: Am 22.07.2012 22:45, schrieb Stefan Keller: Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Verstehe ich nicht. Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine Datenbank für alle sein kann und einfach vollgestopft werden soll mit Tags, die von externen Projekten kommen. Der einzige Tag den ich vorschlage ist diese eine Projekt_ID. Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil gegenüber der normalen Objekt-ID. Doch: Es ist permanent/stabil/eindeutig (falls einem die OSM ID nicht genügt). Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört, oder zu dem Objekt Restaurant. Das mit dem Verschieben von Node zu Fläche habe ich oben beantwortet. Wenn ein Mapper aus einen Restaurant als Node eine Parkbank macht, dann stimmte entweder tatsächlich vorher etwas nicht mit der Realität überein (und die externe Datenank registriert das) oder mit dem Mapper :- Will anständigerweise sagen, er war sich seiner unbedarften Handlung nicht bewusst, und das Projekt ist so nett (zu OSM), erzeugt das Restaurant wieder (mit seiner Projekt-ID) und löscht die Projekt-ID beim Parkbank. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. Ok: Restaurants haben Namen (wenn auch kaum eindeutige), Parkbänke leider kaum. Daher ist die Idee der kombinierten Tags unzureichend. Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge haben). Der Mapper hat hier die freie Wahl! Er soll einfach den Tag irgendwohin tun - nur in (wie üblich) nicht löschen. Das Projekt kümmert sich (hoffentlich) drum. LG, Stefan Am 22. Juli 2012 23:05 schrieb aighes o...@aighes.de: Am 22.07.2012 22:45, schrieb Stefan Keller: Am 22. Juli 2012 22:14 schrieb aighes o...@aighes.de: Oder wenn jemand das Objekt nun anderweitig nutzt. Bspw. Straße - Gebäude. Dann hat auf einmal das Gebäude die ref der Straße. Verstehe ich nicht. Jedenfalls bin ich mit dir gleicher Meinung, dass OSM nicht eine Datenbank für alle sein kann und einfach vollgestopft werden soll mit Tags, die von externen Projekten kommen. Der einzige Tag den ich vorschlage ist diese eine Projekt_ID. Nein. Die ID hilft keinem bei der sicheren Zuordnung. Es hat keinen Vorteil gegenüber der normalen Objekt-ID. Bsp: Restaurant als Node eingetragen mit Projekt-ID. Nun wird aus dem Restaurant eine Fläche und der Node wird bspw. eine Parkbank und behält die Projekt-ID. Der normale Mapper wird sich darum nicht kümmern, weil es ihm nichts sagt und er auch nicht weiß, ob die ID nun zum Node an sich gehört, oder zu dem Objekt Restaurant. Sinnvoller wäre es, bspw. über die OverpassAPI nach einem Restaurant mit dem Namen xyz in der BBox... zu fragen. Noch etwas deutlicher eine Bundesstraße verlief durch den Ort und hat eine Projekt-ID bekommen. Nun wird eine Umgehung gebaut und das was vorher Bundesstraße war, ist nur noch Ortsstraße. Der Mapper weiß wieder nicht, ob die ID nun zur Bundestraße gehört oder zu der Straße an diesem Ort (können ja auch mehrere ID's an dem Way sein, die jeweils unterschiedliche Bezüge haben). In beiden Fällen kommt bei dem Projekt Unsinn an, der evtl. nicht bemerkt wird und wenn er bemerkt werden würde, dann würde er auch bemerkt, wenn man nach der OSM-ID gegangen wäre. Henning ___ 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] Permanente/stabile OSM IDs!
Hallo, Am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org: ich bin der Ansicht, das OSM-IDs eine 100% OSM-interne Sache sind, auf die sich niemand sonst verlassen darf, weil dies die Handlungsmoeglichkeiten bei OSM einschraenkt. Kann ich mit Leben ink. allen erwähnten hypothetischen Fällen. Daher ja mein Vorschlag von Projekt/privaten IDs :- Darauf hinzuarbeiten, dass OSM-IDs moeglichst stabil sein sollen, wuerde zugleich heissen, die Flexibilitaet der Mapper zu reduzieren, ihnen das Leben schwerer zu machen - m.E. keine gute Idee. Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten, dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und allen Tags) erhalten bleibt und bitte ein neuer Node in den Way eingefügt wird und nicht - wie offenbar aktuell - der Node im Way erhalten wird und die Haltestelle eine neue Node-ID erhält. UUIDs stehe ich ebenfalls sehr kritisch gegenueber, weil sie das Fuehren der Link-Stabilitaet unseren Mappern aufbuerden. Ich finde, unser Mapper soll sich damit beschaeftigen, dass da ein Restaurant mit dem Namen X ist, und wenn das Restaurant umzieht auf die andere Strassenseite, dann loescht er das und legt es neu an, oder er schiebt es rueber, ganz wie es gerade am geeignetsten erscheint. Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke geht, die keinen Namen haben! UUID ist ein Spezialfall von meinem Vorschlag einer Projekt-ID. Im Gegensatz zu UUIDs verlangen meine Projekt-IDs aber nicht, dass sich alle an eine gemeinsame UUID-Spezifikation halten, sondern lediglich, dass der Mapper den Tag in Ruhe lässt. Wenn dann noch die Editoren den Mapper beim Verschieben besser unterstützen (und wirklich updaten und nicht löschen und neu erzeugen), dann umso besser für OSM - und die Projekt-Datenbank. ... Laut Overpass's Permanent ID könnte die Lösung eine eindeutige Eigenschaft des Objekts sein, typischerweise eine Kombination von Tags. Als Beispiel wird eine Relation mit den Tags network=BAB und ref=A 516 herangezogen. Ich finde den Vorschlag gut - man muss sich aber bewusst sein, dass er m.E. nichts Neues bringt, bzw. das Problem der offenbar unvermeidbaren menschlich- und technischen Unzulänglichkeiten nicht löst. Ich halte das fuer die beste Loesung, die wir haben, weil hier derjenige, der den Link setzt, entscheiden muss, was ihm wichtig ist, und die Mapper sich nicht damit herumschlagen muessen. Das Problem der unvermeidbaren Unzulaenglichkeiten wird dadurch nicht geloest, aber reduziert - wenn ich ein Restaurant loesche und auf der anderen Strassenseite neu zeichne, wird das immer noch gefunden. Wie gesagt, ist damit der (häufige) Fall nicht abgedeckt, für alle diese Objekte, für die die Mapper keine ref-Links (o.ä.) ausdenken. Eine OSM-externe Datenbank vergibt einen eigenen und für sie eindeutigen ID-Tag in OSM, die nicht-sprechende Identifikatorwerte erhalten, z.B. unserprojekt:id=10001 oder unserprojekt_id=10001. Nein, das halte ich nicht fuer akzeptabel, es hat die gleichen Probleme wie das UUID-Konzept. Sehe keinen Unterschied zu meinem Vorschlag, denn auch hier werden Links als Tags ins OSM Objekt gesetzt. Ich könnte mir höchstens vorstellen, dass mein Vorschlag nur dort zum Zuge kommt, wo Mapper keine Links setzen. Was aber eine gute Idee waere: Vorab: Genau diese Idee steckt hinter meinem Vorschlag. Der Vorteil meines Vorschlags ist, dass es das Overpass-Permanent-ID-Konzept ergänzt (und ursprünglich auf ein Tag einschränken wollte), da das Overpass-Permanent-ID-Konzept nur für OSM Objekte funktioniert, die für Mapper einen sprechenden Schlüssel haben. Man baut eine externe Datenbank als Interface zwischen der Oeffentlichkeit und OSM auf. Zur Oeffentlichkeit hin unterstuetzt diese Datenbank permanente Schluessel - seien das UUIDs oder Nummern oder sonstwas. Soweit wie gesagt einverstanden. Zu OSM hin benutzt diese Datenbank das Overpass-Permanent-ID-Konzept (das nicht von Roland erfunden wurde, sondern ursrpuenglich mal von Tim Alder mit seinem query to map angedacht worden war). Deine Hinweise oben drängen für mich eine Kombination des Overpass-Permanent-ID-Konzept mit meinem Vorschlag auf: Projekt-IDs würden dann nur vergeben, wenn in der OSM DB keine zusammengesetzte Schlüssel vergeben werden können, wie das wohl z.B. bei Sitzbänken, Briefkästen, etc. der Fall ist. Jeder kann bei Bedarf einen Link in dieser Datenbank anlegen lassen und den dann ueberall benutzen. Im Gegensatz zur reinen Verwendung von Overpass-IDs rund um die Welt hat dieses Vorgehen den Vorteil, dass alle Links in der Datenbank regelmaessig automatisiert ueberprueft werden koennen: Sind sie noch gueltig? Zeigen sie noch auf genau 1 Objekt, oder mittlerweile auf 0 oder 2? Es
Re: [Talk-de] Permanente/stabile OSM IDs!
Moin, Am 23.07.2012 00:09, schrieb Stefan Keller: Am 22. Juli 2012 22:58 schrieb Frederik Ramm frede...@remote.org: Grundsätzlich einverstanden. Deine Aussage sollte aber doch nicht solche Fälle sanktionieren, die ich oben erwähnt habe, bei denen der Mapper einen Node (wie z.B. eine Bushaltestelle, die vorher Teil eines Ways war) nur verschieben will! Da sollte JOSM unbedingt Hand bieten, dass bitte der Haltestellen-Node (mit ID und Haltestellen-Namen und allen Tags) erhalten bleibt und bitte ein neuer Node in den Way eingefügt wird und nicht - wie offenbar aktuell - der Node im Way erhalten wird und die Haltestelle eine neue Node-ID erhält. Warum soll JOSM insgesamt drei Objekte (H-node, way-node, way) verändern, nur um eine OSM-interne ID an den für irgendeinen Auswerter vermeintlich richtigen Ort zu plazieren, wenn es doch reicht, nur zwei Objekte (H-node, way-node-Tags) zu verändern? Wer sagt, dass die Haltestelle wichtiger ist als der node in der Straße - der (rein hypothetisch) ein Vermessungspunkt sein könnte? Das Verschieben soll aber auch funktionieren, wenn es um Parkbänke geht, die keinen Namen haben! Bei solchen Argumenten fällt mir irgendwie immer ein, das auch Koordinaten eindeutige IDs sind ... Diese IDs sind dann immer eindeutig ... und passende Objekte können auch in einem gewissen Suchradius gefunden werden. Die dann extern auf andere IDs gemappt werden können, so man unbedingt will. Und wenn das OSM-Objekt dann verschoben wird, - stimmte entweder die vorherige Projekt-ID erst gar nicht (die Parkbank mit der Projekt-ID 123 musste sich an der Koordinate xyz befinden!) - oder das Projekt-Objekt wurde tatsächlich verschoben (neue Koordinate = externe Zuordnung anpassen!) - oder es ist der ganz typische OSM-Fall: Der Mapper hat das OSM-Objekt komplett verändert (Projekt muss eh sein Objekt auch als OSM-Objekt wiederherstellen!) Aber wir erwarten doch auch nicht, das Mapper sich für Sitzbänke und Briefkästen irgendwelche ref-Attribute ausdenken müssen - dazu braucht's m.E. Projekt-IDs, oder? Und was unterscheidet eine Projekt-ID von irgenwelchem ausgedachten ref-Attribut? Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
