Re: [Talk-de] An die thread-Piraten
Am 09.10.10 12:15, schrieb Tom Müller: Mmmh. Wenn ich http://news.gmane.org/gmane.comp.gis.openstreetmap.region.de als Newsgroup hinzufügen will kann ich nicht auf weiter klicken. Brauche ich da noch nen Addon oder so? Nö, so geht das ja auch nicht. Du legst in Thunderbird über Extras Konten-Einstellungen und Konten-Aktionen ein neues anderes Konto an, und gibst news.gmane.org als Server ein. Dann hast du links unterhalb der Lokalen Ordner einen neuen Ordner für gmane. Den wählst du an, und gehst rechts auf Newsgruppen abbonieren, und wählst dort in dem Baum die Gruppe gmane.comp.gis.openstreetmap.region.de aus; und klickst auf abbonieren. Wenn du erstmalig über gmane schreiben willst, bekommst du eine email-Aufforderung, die du beantworten musst, bevor der Beitrag in die Liste eingestellt wird. Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 00:07, schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Es ist immer einfach zu sagen das das technisch ginge, wenn man es nicht selber tun muß. Wieviele Renderer/Karten hast du selber schon geschrieben, die sowas generell (und nicht nur ein Paar Spezialfälle) auswerten können? Das sowas bislang kaum einer (keiner?) der Renderer auswertet deutet darauf hin, das es doch nicht ganz so trivial ist ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 00:07:38 schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Ich hatte schon vor einiger Zeit mal angemerkt, daß die Sache mit dem Semikolon so eine Sache ist ;-) das liegt aber meist nicht am Semikolon selbst, sondern an den Anwendungen, die das nicht verstehen (wollen)... +1 Wenn du ein amenity=pub;cafe einträgst, ist die Wahrscheinlichkeit sehr hoch, das keiner der Renderer so ein Haupttag findet. Ich erwarte nicht, das sich das in Zukunft großartig ändern wird. Hier taggt jemand aber nur noch für bloed nur, dass sich sowas nicht anders darstellen laesst. [...] Es ist gut eine Regel zu haben, wie man mit mehreren Werten in einem Tag umgeht (sowas bei jedem Tag anders zu lösen macht ja keinen Sinn). +1 +1 Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Das ist auch ganz unabhaengig davon, um welches Tag oder welche Kombinationen es sich handelt. Es stellt sich nur die Frage, tut man's oder tut man's nicht. +1 Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) -/- amenity=cafe;restaurant cuisine=greek;italian Als diese Unsitte mir area=yes eingeführt wurde, verpassten wir die Gelegenheit, die Bodennutzung mit area zu definieren. area=residential, building=wohnhaus... . Der Zug ist abgefahren. Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 08:34:10 schrieb Ulf Lamping: Am 11.10.2010 00:07, schrieb Guenther Meyer: Am Sonntag 10 Oktober 2010, 23:09:41 schrieb Ulf Lamping: Es ist aber nicht so gut zu glauben das die Renderer alle möglichen Kombinationen schon irgendwie/irgendwo/irgendwann schlucken werden. Irgendwann sagt der Renderer (Regel) Schreiber halt: Die Arbeit mache ich mir nicht auch noch, dann geht das halt nicht. Technisch sehe ich da keine Probleme bei der Verarbeitung. Es ist immer einfach zu sagen das das technisch ginge, wenn man es nicht selber tun muß. Wieviele Renderer/Karten hast du selber schon geschrieben, die sowas generell (und nicht nur ein Paar Spezialfälle) auswerten können? Das sowas bislang kaum einer (keiner?) der Renderer auswertet deutet darauf hin, das es doch nicht ganz so trivial ist ... Mit den richtigen Werkzeugen ist das parsen trivial. Mit mehreren Eigenschaften umzugehen, ist unabhängig von der Einlesetechnik nicht trivial, weil man sich überlegen muss, wie man es darstellt. Das aber ist und muss dem Renderer freigestellt sein. Eben das ist ja der Vorteil bei OSM, dass erfasst wird, was vorliegt. Wer das wie auswertet, ist für die Erfassung _absolut_ egal. Ich habe selbst schon einiges erfasst, was nirgends gerendert wird, so what! Wenn ich es brauche sollte, schreibe ich halt irgend etwas, oder lasse es schreiben. Wir können doch nicht bei der Erfassung Rücksicht auf vermeintlich unzureichende Auswertesoftware nehmen! Wenn wir immer nur das erfasst hätten, was im Moment gerendert wird, würde die Karte bis heute nur aus einem Strickmuster von unklassifizierten Straßen und Wegen bestehen. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Sonntag 10 Oktober 2010 21:48:30 schrieb Jan Tappenbeck: ... nämlich das semikolon ist dem tag sein tod ! -1 Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 08:59, schrieb Wolfgang: amenity=cafe;restaurant cuisine=greek;italian Ich denke mal, dass man als Programmierer einfach nicht entscheiden kann (oder will), was in so einem Fall gerendert (ausgewertet) werden soll: Soll das Symbol für Cafe oder für Restaurant dargestellt werden? Gibt es dort griechischen Kaffee und italienisches Essen oder italienischen Kaffee und griechisches Essen oder griechisch-italienisches Essen und auch Kaffee? Wenn ich soetwas auswerten wollte, würde ich bestenfalls das jeweils erste Element nehmen, also hier ein griechisches Cafe darstellen. Stell Dir mal vor, man will eine Liste mit griechischen Restaurants machen. Soll das dann aufgenommen werden oder nicht? Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Etwas Anderes ist es bei den opening_hours, dort ist klar definiert, wie das Semikolon zu interpretieren ist. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Stefan Dettenhofer (StefanDausR) wrote: Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? wie soll ich im JOSM schnell alle Geldautomaten loeschen, ohne eine Bank mitzuloeschen? Wie sollen Statistikseiten wie taginfo das zaehlen? Gibt es einen Unterschied zwischen bank;atm und atm;bank? ...) Ich halte es da pragmatisch wie Ulf - wenn das Tag eins ist, das ohnehin kaum automatisch ausgewertet wird (oder bei dem ein automatischer Auswerter ohnehin erstmal gruendlich recherchieren muss), dann kann man sich ein Semikolon erlauben; wenn man aber bei sowas wie amenity ein Semikolon benutzt, dann nimmt man damit (egal ob im Recht oder nicht) in Kauf, dass das so getaggte Objekt auf Jahre hinaus in den meisten Karten unsichtbar bleibt. Bei sowas wie amenity=bank;atm ist die Sache klar, da setze ich zwei Nodes. Bei sowas wie amenity=cafe;restaurant ist es etwas bloeder, da entscheide ich mich in der Regel fuer eins. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 09:42:43 schrieb Frederik Ramm: Hallo, Stefan Dettenhofer (StefanDausR) wrote: Ich könnte mir bei cuisine alleine noch Mehrfachnennungen vorstellen, aber bei amenity gar nicht. Das Beispiel cafe/restaurant ist zugegeben in vielen Fällen eine Werbeaussage. Trotzdem gibt es den Unterschied: Viele Restaurants haben Mittags und Abends auf, viele Cafés haben vom Vormittag bis späten Nachmittag geöffnet. In Restaurants liegt das Schwergewicht auf festen Mahlzeiten, während Cafés nahezu ausschließlich Kaffee, Kuchen und ggf. Eis anbieten. Wer beides hat, ist halt Café;Restaurant. Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. wie soll ich im JOSM schnell alle Geldautomaten loeschen, ohne eine Bank mitzuloeschen? Gar nicht. Bitte beim Löschen von Objekten jeden Einzelfall prüfen (scnr). Wie sollen Statistikseiten wie taginfo das zaehlen? Gibt es einen Unterschied zwischen bank;atm und atm;bank? ...) Das ist jetzt nicht dein Ernst? Ich halte es da pragmatisch wie Ulf - wenn das Tag eins ist, das ohnehin kaum automatisch ausgewertet wird (oder bei dem ein automatischer Auswerter ohnehin erstmal gruendlich recherchieren muss), dann kann man sich ein Semikolon erlauben; wenn man aber bei sowas wie amenity ein Semikolon benutzt, dann nimmt man damit (egal ob im Recht oder nicht) in Kauf, dass das so getaggte Objekt auf Jahre hinaus in den meisten Karten unsichtbar bleibt. Genau das ist mir egal. Ich tagge nicht für den Renderer. Wenn jemand das Semikolon auswertet, ist es der Software egal, für wieviel tags er das auswertet. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Für andere Anwendungen kann es aber durchaus sinnvoll sein zu wissen, es gibt hier in einer Entfernung von weniger als 3 km nicht nur warmes Essen, sondern auch Kuchen. Die Öffnungszeiten werden auch nicht gerendert, aber trotzdem eingetragen. Es gibt auch andere Software als Renderer. Gerade Anwendungen wie der openstreetbrowser sind prinzipiell in der Lage, gezielt Mehrfacheigenschaften auszuwerten. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Ich (als Programmierer) setze eher darauf, dass die Semikolons irgendwann wieder verschwinden. Ich fand die noch nie gut. Wenn jemand anders das in Mapnik und osm2pgsql und so einbauen will - ich werd's bestimmt nicht tun. Genau das ist mir egal. Ich tagge nicht für den Renderer. Wenn jemand das Semikolon auswertet, ist es der Software egal, für wieviel tags er das auswertet. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Oder keine ;) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag, 11. Oktober 2010 08:59:18 schrieb Wolfgang: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Da möchte ich jetzt doch mal widersprechen. Ich tagge sehr wohl für Renderer, Router und Auswertesoftware, und eher nicht für die Datenbank. Nicht für den Renderer taggen bedeutet für mich, dass ich keine verfälschten Daten eintrage, um damit ein bestimmtes Render-Ergebnis zu erreichen. Es ist auch klar, dass ich keine Daten entferne, bloß weil sie nicht gerendert werden. Und ich gestehe auch gerne zu, dass zum Zwecke einer besseren Datenerfassung hin und wieder Änderungen eingeführt werden, an die bestehende Auswertesoftware erst angepasst werden muss. Aber dass man die Möglichkeiten der bestehenden Auswertesoftware und gegebenenfalls nötigen Änderungsaufwand völlig ignoriert, kann ich nicht verstehen. Wie gesagt, _ich_ mappe nicht für die Datenbank. Gruß, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Ulf Lamping wrote: Am 11.10.2010 09:09, schrieb Wolfgang: Mit den richtigen Werkzeugen ist das parsen trivial. Mit mehreren Eigenschaften umzugehen, ist unabhängig von der Einlesetechnik nicht trivial, weil man sich überlegen muss, wie man es darstellt. Nein, wie Stephan an anderer Stelle am Beispiel gezeigt hat, geht der Aufwand schon damit los, daß man sich überhaupt erstmal überlegen muß, was denn der Mapper mit dieser Kombination gemeint haben könnte. Die Darstellung ist dann einer der weiteren nicht trivialen Schritte. Und das muß man dann für jedes Tag einzeln bewerten. +1 -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5622338.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] Darstellung von geotagged Bildern in OSM
Hallo zusammen, vielen Dank für Eure Tipps. Ich werde mich in den nächsten Tagen mit diesen auseinander setzen. Ausschliessen kann ich allerdings sofort die Lösungen, bei denen man Bilder auf irgendeinen externen Server hochladen muss. hike 39 Am 08.10.2010 11:35, schrieb hike39: Hallo, ich bin auf der Suche nach einer Möglichkeit Photos, die ich über das JOSM-Addon Photo Geotagging mit Positionsinfos versehen habe, auch in OSM anzeigen zu lassen. Gibt es hierzu schon eine Lösung? Ich habe gerade überall im Wiki und in den dt. Diskussionsgruppen gesucht, aber leider nichts gefunden. hike39 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 10:30 schrieb Frederik Ramm frede...@remote.org: Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. Ein pragmatischer Ansatz wäre evtl. auch schonmal, die Reihenfolge vorzugeben (alphabetisch), mit der doppelte Werte eingetragen werden. Dann könnte man cafe;restaurant, atm;bank und was einem sonst noch so am Herzen liegt, mit endlichem Aufwand als einen Wert definieren. Skaliert natürlich nicht, aber könnte ein paar Spezialfälle abfangen, ohne dass man auch noch jeweils bank;atm und restaurant;cafe prüfen müsste. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 08:59 schrieb Wolfgang wolfg...@ivkasogis.de: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. das kann er eben nicht so einfach, daher gibt's ja die Probleme. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) warum schauderts Dich da? Das ist besser auszuwerten und wird daher in der Regel dargestellt. Was Du dagegen forderst vernichtet im Prinzip die Daten auf der Auswertungsseite. Früher konnte man ja mehrmals denselben Key auf demselben Objekt verwenden (zumindest erlaubten Editoren und DB das), was war da genau der Grund, dass man es abgeschafft hat? (Sorry für die Frage, bin weder Mathematiker noch Informatiker wie man sicher leicht erkennen kann). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 10:30:57 schrieb Frederik Ramm: Hallo, Wolfgang wrote: Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Ich (als Programmierer) setze eher darauf, dass die Semikolons irgendwann wieder verschwinden. Ich fand die noch nie gut. Wenn jemand anders das in Mapnik und osm2pgsql und so einbauen will - ich werd's bestimmt nicht tun. Vielleicht verschwindet das Semikolon und wird durch etwas anderes ersetzt. Ich glaube aber nicht, dass Mehrfacheigenschaften verschwinden werden. Es bleibt dem Renderer ja freigestellt, im Falle von Mehrfacheigenschaften generell nur die erste zu rendern. Oder keine ;) Ist auch OK. Dann rendert es halt ein anderer. Später. :) Ich kann es aber jetzt auswerten. Z.B. Summe der italienischen Restaurants in x-Stadt. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 10:15, schrieb Wolfgang: Hallo, Am Montag 11 Oktober 2010 09:42:43 schrieb Frederik Ramm: Der Klassiker ist eine Bank mit Geldautomat: amenity=bank;atm Ich benutze das selber aber auch nicht, weil ich im Herzen eben doch Programmierer bin und weiss, dass einem das ueberall nur Stress macht (Wie soll osm2pgsql damit umgehen, wenn es nur eine amenity-Spalte befuellen kann? wie soll ein SQL-Query aussehen, der alle Banken aus einer semikolon-getrennten Spalte sucht - etwa mit amenity like '%;bank;%' or amenity like 'bank;%' or amenity like '%;bank' or amenity='bank'? Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Die Mehrfacheigenschaften sind lange genug in Gebrauch, es hätte hier längst etwas passieren können. Hier argumentiert Frederik mit konkreten Problemen auf die ein Entwickler stößt, wenn er es denn einbauen wollte. Du argumentierst hingegen mit: es hätte, muß es, ... Für andere Anwendungen kann es aber durchaus sinnvoll sein zu wissen, es gibt hier in einer Entfernung von weniger als 3 km nicht nur warmes Essen, sondern auch Kuchen. Es geht hier nicht darum, ob man sowas eintragen kann (oder sollte), sondern wie es sinnvoll gemacht wird. Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Platzierung stop_position-Knoten im Oxomoa-Schema
Am 8. Oktober 2010 18:45 schrieb Benjamin John o...@bejotel.de: Am 08.10.2010 16:37, schrieb Claudius: Szenario ist eine Buslinie mit Haltestelle an einer Kreuzung, wobei der Bus in jeder Richtung jeweils *vor* der Kreuzung hält. die stop_position jeweils dort projeziert auf die Straße (=Teil des highway, Mitte der Straße), wo der Bus hält (m.E. Vorderkante Bus bzw. projezierte Position des Haltestellenmastes). In diesem Fall also mind. 2 davon. Ein Mapper meinte, dass der eine dafür nötige stop_position-Knoten dann auf den Kreuzungsknoten gehöre (und verwies dabei unter anderem auf die Verwendung in Aachen, die ich mir aber noch nicht angeschaut habe). das können sich die Aachener ja nochmal überlegen, m.E. ist es jedenfalls so falsch. Meinem Verständnis nach mappt man zwei stop_positions jeweils auf dem Weg vor (==lotgefällt) auf dem Weg der Buslinie. Ich bin auf jeden Fall dafür für jeden Stop einen Knoten zu erfassen. Also in diesm Fall zwei, und wenn sich an der Kreuzung zwei Linien kreuzen dann auch vier oder wie viel auch immer nötig sind. +1 Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TüV Reinland Breitbandatlas basiert auf OSM-Daten
Am 8. Oktober 2010 10:21 schrieb Oliver Tonnhofer o...@omniscale.de: Wir stellen die Daten bereit und haben mit der Kartenanwendung selber nichts zu tun. Wir haben das allerdings weitergeleitet und denken, dass da heute noch nachgebessert wird. ja, danke, jetzt steht da klar Hintergrundkarte Openstreetmap, CC-BY-SA 2.0, wie es auch im OSM-Wiki vorgeschlagen wird. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 10:54:28 schrieb M∡rtin Koppenhoefer: Am 11. Oktober 2010 10:30 schrieb Frederik Ramm frede...@remote.org: Hallo, Wolfgang wrote: Hier argumentierst du mit den Unzulänglichkeiten des Datenbankschemas und von osm2pgsql. Wenn das in das bestehende Schema nicht passt, muss es eben angepasst werden. Darunter leidet halt auch die Effizienz. Das verstehe ich schon, dass die Programmierer dazu keine Lust haben. Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Wird vermutlich allerdings ne Weile dauern, wenn man den Planet damit durchackern will. 0/-1 In deinem speziellen Beispiel ginge das, aber für das Beispiel Amenity oder Cuisine geht es nicht, weil damit die Statistik in die Tonne getreten würde. Wer das für seine Auswertung so machen will, dem steht das frei. Ein pragmatischer Ansatz wäre evtl. auch schonmal, die Reihenfolge vorzugeben (alphabetisch), mit der doppelte Werte eingetragen werden. Dann könnte man cafe;restaurant, atm;bank und was einem sonst noch so am Herzen liegt, mit endlichem Aufwand als einen Wert definieren. Skaliert natürlich nicht, aber könnte ein paar Spezialfälle abfangen, ohne dass man auch noch jeweils bank;atm und restaurant;cafe prüfen müsste. Hier habe ich ein grundlegendes Verständnisproblem - ich finde das Problem einfach nicht. Wenn ich das Datenschema nicht anpasse, bekomme ich für den key amenity den Value cafe;restaurant. Jetzt mit einer klitzekleinen Programmzeile eben prüfen, ob ein Semikolon vorliegt, und im Falle, dass dieses zutrifft, einen Value-Array mit den einzelnen durch Semikolon(s) getrennten Werten erzeugen. Hier den ersten Wert dem Value wieder zuweisen und den übrigen Programmablauf so lassen, wie bisher. Damit wird ausschließlich der erste Wert benutzt. Nicht optimal, aber für den 08-15-Renderer eine brauchbare Möglichkeit. Geht viel schneller als die ganzen Diskussionen über das Semikolon in nicht nur diesem Thread. Die Idee mit der Sortierung ist auch nicht schlecht. Wenn ich den erzeugten Value-Array noch sortieren lasse, kann ich auf bestimmte Kombinationen abprüfen. Das geht allerdings auch ohne Sortierung. Wer den Programmablauf beschleunigen will, könnte für die Keys und Values in der DB eine zusätzliche Spalte für Integers einführen. Dann bekäme jeder Key und Value eindeutige int, die nur einmal erzeugt werden muss (und einmal für den Inhalt jedes Updates). Die Queries könnten dann integers zurückgeben, die viel schneller (automatisch) auszuwerten sind. Nur so als Idee. Zugegeben einmalig viel Aufwand. Beschleunigt aber erheblich mehr, als die Auswertung von ein paar Semikolons sonst kosten könnte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrrad-Access-Karte überarbeitet
Hallo zusammen, Auf dem Toolserver werkelt inzwischen Tirex, daher sollten veraltete Kacheln der Vergangenheit angehören. Grund genug, meine Fahrrad-Karte zu überarbeiten: http://access.t-i.ch/extended-bicycle.html Neu ist insbesondere die dünne Mittellinie, welche die Oberfläche visualisiert: Schwarz für gescholssene/geteerte Oberflächen Weiss für verfestigte/bearbeitete Oberflächen Rot für naturbelassene Oberflächen schönes Beispiel: http://access.t-i.ch/extended-bicycle.html?zoom=17lat=47.39758lon=8.54614layers=B000T Wünsche, Anregungen und Fehlermeldungen bitte hier oder auf der Wiki- Seite: http://wiki.openstreetmap.org/wiki/User:T-i/Access-Map Gruss, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 11:31, Friedhelm Schmidt wrote: Am 11.10.2010 10:54, schrieb M∡rtin Koppenhoefer: Eine pauschale Möglichkeit wäre, vor dem Verarbeiten alle values zu parsen und aus amenity=bank;atm einen automatisch 2 duplicate nodes zu generieren, die jeweils bank und atm als value haben. Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. Für die grafische Darstellung ist das egal - nur wird meist einer der Knoten dann immer noch rausfallen, weil zwei POIs auf dem gleichen Punkt zufällig oder aus anderen Gründen auf einen reduziert werden. Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Wolfgang-4 wrote: Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) hi wolfgang, ich fühle mich in keiner hinsicht entmündigt ;) a) das neue binärformat ist nicht bindend, du kannst auch einfach das alte nehmen. b) osmosis kann alles lesen und alles schreiben. omosis --read-pbf . --write-xml und dein altes osm-file ist da. gruss walter - Wanderer, kommst Du nach Liechtenstein, tritt nicht daneben, tritt voll hinein. - Ingo Insterburg -- View this message in context: http://gis.638310.n2.nabble.com/api-download-bei-semikon-getrennten-values-tp5620526p5622707.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] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 10:59:30 schrieb M∡rtin Koppenhoefer: Am 11. Oktober 2010 08:59 schrieb Wolfgang wolfg...@ivkasogis.de: Wir taggen weder für Renderer, noch für Router, noch für sonstige Auswertungssoftware. Wir mappen und taggen das, was da ist, und wie es da ist. Ein Tag kann halt mehrere Werte haben. das kann er eben nicht so einfach, daher gibt's ja die Probleme. Lieber ein eindeutiger Tag mit eindeutig mehreren Eigenschaften, als diese yes-Krankheiten, die Tag und Value im einem auszudrücken versuchen. cafe=yes restaurant=yes cusine_greek=yes cuisine:italian=yes (schauder) warum schauderts Dich da? Das ist besser auszuwerten und wird daher in der Regel dargestellt. Was Du dagegen forderst vernichtet im Prinzip die Daten auf der Auswertungsseite. Du übersiehst, dass der Programmierer hier ein im Grunde größeres Problem hat. Die Eigenschaften sind nach wie vor mehrfach vorhanden. An dieser grauenvollen Wirklichkeit führt auch dieses Schema nicht vorbei. Aber die Auswertung muss erkennen, dass cuisine_greek und italian sich auf die gleiche Eigenschaftsgruppe beziehen. Zusätzlich zum Vorhandensein der Mehrfacheigenschaft muss diese Mehrfacheigenschaft erkannt werden, sonst malt der Renderer das eine Icon über das andere. Oder er nimmt immer das zuerst gefundene. Damit wären wir auch nicht weiter. Eine Software, die ein Icon für eine relativ häufige Kombi wie diese hier darstellen könnte, hätte einen erheblichen Mehraufwand, weil sie die Kombi erst suchen müsste. Aber die Eigenschaftenliste wird in jedem Editor länger und auch hier muss die humane Schnittstelle die Mehrfacheigenschaft erst mühsam erkennen, während das Semikolon diese brutal vor das entsetzte Auge zerrt. Man muss sich immer überlegen, dass es sich letztlich um ein grundsätzliches Problem handelt. Wenn nur ein yes-Tag dabei ist, fällt das Problem nicht auf. Wenn aber alles so getaggt würde, weil es scheinbar einfacher ist, würde die Übersicht schnell sparsamer werden: automatic_entrance_door=yes bar=yes blinking_leuchtreklame=no cafe=yes cuisine_greek=yes cuisine_italian=yes decoration_greek=yes decoration_italian=yes english_money_accepted=no english_spoken=yes euro_accepted=yes fish_dishes=yes german_spoken=yes good_speed_of_service=yes greek_music_sound=yes greek_spoken=yes high_qality_of_food=no interior_color_read=yes italian_music_sound=yes italian_spoken=yes japanese_spoken=no kitchen_visible=yes kitchen_visible_by_window=yes leuchtreklame=yes leuchtreklame_color_blue=yes leuchtreklame_color_red=yes maestro_card_accepted=yes master_card_accepted=yes music_box=yes music_box_accepts_credit_cards=no music_box_accepts_coins=yes number_of_seats=100 oven_in_guest_room=no outside_color_blue=yes pizza_oven=yes prices_high=yes restaurant=yes tables=25 traveller_cheques_accepted=yes visa_card_accepted=yes weelchair_geeignet=yes Da habe ich natürlich maßlos übertrieben. Aber ein Problem zeigt sich immer am Extremfall, und so eine Liste möchte ich weder im josm noch im merkaartor editieren müssen. Mehrfacheigenschaften sind trotzdem drin. Wenn man das Schema noch etwas ausbaut, kann das yes/no weggelassen werden, und wir sind beim valuelosen tagging. Früher konnte man ja mehrmals denselben Key auf demselben Objekt verwenden (zumindest erlaubten Editoren und DB das), was war da genau der Grund, dass man es abgeschafft hat? (Sorry für die Frage, bin weder Mathematiker noch Informatiker wie man sicher leicht erkennen kann). Da würde ich auf die DB-Struktur zu dem Zeitpunkt tippen. Ist aber nur Spekulation. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Farmland
Am 10. Oktober 2010 23:23 schrieb minze my-email-confirmat...@online.de: natural wären dann Naturschutzgebiete, wo die Nutzung verboten ist, oder wie grenzst Du das ab? Wie bei natural=wood vsv Landuse=forest, steht in der wiki. funktioniert da ja auch schon nicht. Bei Heiden ist es noch schwieriger als bei Wäldern, versuchen könnte mans trotzdem mal, die meisten Mapper haben halt kaum ein Auge / Vorbildung / Acht auf solche feinen Details. NSGs sind handlungsleitende Widmungen und haben mit der vorgefundenen Struktur weniger zu tun. Nicht jeder Naturwald ist ein Schutzgebiet - insbesondere international gesehen. da bin ich allerdings voll bei Dir. ... Den Wert von crop könnte man auch lateinisch eintragen, so dass es eindeutiger wird (vgl. natural=tree). ja. wie? So: # name=tomatoes # genus=Solanum # species:en=tomato ? nein, so nicht. Ich nehme an, das hast Du absichtlich so geschrieben? Warum sollte der Name im Plural sein? Name von was? Willst Du einzelne Tomaten taggen? Genus braucht man prinzipiell nicht, weil er in der Spezies schon enthalten ist und für sich betrachtet noch wenig aussagekräftig, zumindest bei Tomaten. species=solanum lycopersicum hatte ich gedacht, bin aber kein Biologe und evtl. gibt es da auch unterschiedliche Spezies (k.Ahnung, ob Fleischtomaten, Kirschtomaten, Flaschentomaten, San Marzano, etc. alle dieselbe Species sind). Prinzipiell läuft das halt auf eine komplette Neuregelung hinaus, da für Wiesen bisher landuse=meadow dokumentiert und im Einsatz ist. Im Prinzip ist das aber eine Untergruppe von farmland, da stimme ich auch zu. eigentlich haben wir nur landuse und farmland getauscht, damit - landuse=grass nicht weiter belastet wird - Unterschied Wiese und Weide möglich wird ist er schon jetzt: meadow und pasture - eine Oberkategorie farmland entsteht. das meinte ich mit alles umkrempeln Ein kleiner Fehler in meinem vorherigen Tagg-Vorschlag ist allerdings, dass Schlüsselnamen farmland zweimal, also redundant vorkommen. Das finde ich nicht schön. einmal als key, einmal als value, das finde ich nicht so schlecht, da es einer einfach nachvollziehbaren Systematik folgt und eine Hierarchie bildet. zum Begriff Wiese: es ist nicht auszuschließen, dass Wiesen vor nicht zu langer Zeit beweidet wurden. das ist allerdings egal. Wenn Du geschichtliche Informationen taggen willst, dann mit einem klaren Schema. Siehe auch die Meisten der in der wiki und in google zu findenen Wiesenbilder: sie wären heute ohne viel Aufwand zu beweiden. klar, das liegt in der Natur der Sache. Eine Unterscheidung in Weide und Wiese würde landuse m.E. unnötig verkomplizieren. manche wollen das offenbar trotzdem tun. Hattest Du nicht oben selbst geschrieben, diese Unterscheidung würde mit Deinem Vorschlag möglich ? Ich würde einen neuen Hauptkey landcover einführen, um erstmal Klarheit zu haben, was in landuse gehört, und was nicht. sieht schick aus, aber ich wäre vorsichtig. Einen neuen Hauptschlüssel sehe ich noch nicht. Das wäre auf jeden Fall komplizierter, ein Tagg mehr. es wäre ein Start um nach und nach zu migrieren. surface=grass würde bei uns auch gut passen, da Gras auf dem Banquette oder Mittelstreifen tatsächlich nur eine Oberfläche ist und u.A. nichts mit Wiesen- oder Grünlandboden zu tun hat. +1 Gruß Martin PS: Es würde die Diskussion sicher erleichtern, wenn man mal eine Zusammenfassung im Wiki hätte, am besten als Proposal (Status Draft) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Hallo, Am Montag 11 Oktober 2010 12:45:36 schrieb Walter Nordmann: Wolfgang-4 wrote: Und wenn man bei xml/osm bleibt, kann man das im File auch noch lesen. Im Gegensatz zu diesem allenfalls für den zügigeren Download sinnvollen Binärformat, dass als Datenfile IMO einen Rückschritt in das Mittelalter des PC darstellt, als man für jede Datei eine spezielle SW brauchte, um den Inhalt zu verstehen. Eine Art Entmündigung der Mapper. (scnr) hi wolfgang, ich fühle mich in keiner hinsicht entmündigt ;) a) das neue binärformat ist nicht bindend, du kannst auch einfach das alte nehmen. b) osmosis kann alles lesen und alles schreiben. omosis --read-pbf . --write-xml und dein altes osm-file ist da. Stimmt, ich habe es auch etwas drastisch ausgedrückt. Im Grunde will ich nur darauf hinweisen, dass das Binärformat zwar Platz spart und damit eine gewisse Berechtigung hat (für ISDN-User z.B.), aber sonst das xml-Format nicht ersetzen sollte. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: - was ist mit den nicht erreichten....
Am 10. Oktober 2010 13:47 schrieb Frederik Ramm frede...@remote.org: Jan Tappenbeck wrote: immer noch positiv gegenüberstehen und nur weil diese nicht mehr erreichbar sind, vielleicht inzwischen ein anderes Hobby haben, sollen deren Daten gelöscht werden ?!?!? ja Ob man allerdings den von Dir vorgeschlagenen weiteren Schritt gehen wird, dass man Daten der nicht-erreichten bis auf Widerspruch erstmal behaelt, das weiss ich nicht; ich koennte mir vorstellen, dass das eine Einzelfallentscheidung sein koennte. Wie sollte man den Einzelfall entscheiden? Auf welcher Grundlage? Das einzige was ich mit rechtlich vorstellen kann, ist zu sagen, cc-by-sa schützt die Daten sowieso nicht (was aber auch nicht ganz klar ist). OK, eine andere Möglichkeit wäre evtl. ein Verblassen des Schutzes: wenn man eine grob dahingerotzte Straße (oder anderes Feature) nach und nach so dermaßen überarbeitet hat, dass vom ursprünglichen Edit nichts mehr übrig ist. Andererseits hat das Urheberrecht in manchen Laendern tatsaechlich eine Regel, die sinngemaess besagt, dass wenn man mehrmals sorgfaeltig versucht hat, den Rechteinhaber zu erreichen, und das fehlschlug, man bis zu anderslautender Nachricht von einer Zustimmung ausgehen darf. das kann allerdings erst dann mögliche Handlungen vorgeben, wenn wir entweder mehrere OSMs für verschiedene Länder machen (m.E. komplett unvorstellbar) oder diese Rechtsauffassung in allen Ländern gilt (auch das unwahrscheinlich). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Element-Historie.....
Am 10. Oktober 2010 16:30 schrieb Matthias Versen ma...@mversen.de: Jan Tappenbeck wrote: gibt es eine Möglichkeit irgendwie festzustellen wer das Element XYZ einmal erstellt hat ?? Bedingt denn beim splitten eines ways entsteht ein neuer und ein alter Teil. Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 13:01, Wolfgang wrote: Stimmt, ich habe es auch etwas drastisch ausgedrückt. Im Grunde will ich nur darauf hinweisen, dass das Binärformat zwar Platz spart und damit eine gewisse Berechtigung hat (für ISDN-User z.B.), aber sonst das xml-Format nicht ersetzen sollte. Ich denke, das hat niemand vor. Die Vorteile liegen aber absolut auf der Hand. Ohne das geprüft zu haben: - Ein Bottleneck an der API ist der Datentransfer - komprimierung spart hier. - Bottleneck in vielen Anwendungen ist die Festplatte - Komprimierung hilft. Komprimierte Daten sind selten gut, wenn es um kleine Ausschnitte geht: Zwei Häuserblocks runterladen, um in JOSM einen Briefkasten einzutragen ist unspannend im komprimierten Format. Aber es gibt ja andere Anwendungen, und insofern finde ich auch da ein offenes, wenn auch nicht unbedingt gut menschenlesbares Format eine gute Sache. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gültige XSD für API 0.6
Hallo zusammen! Ich bastel gerade an einem Tool, das OSM-Daten aufbereiten soll und suche daher nach einer gültigen XSD für die API 0.6. Im Wiki habe ich zwar eine XSD gefunden[1], diese lässt sich aber nicht gegen aktuelle Serverfiles validieren (unter anderem fehlt das bounds Tag. Daher meine Frage an die Liste: Gibt es eine aktuelle XSD für die API 0.6? Das würde mir die Arbeit sehr erleichtern :) Gruß, Philip [1]: http://wiki.openstreetmap.org/wiki/API_v0.6/XSD Exklusiv: Neue E-Mail-Adresse @iPhone.de jetzt verfügbar! Sichern Sie sich jetzt ihre persönliche http://www.iphone.de/iphonemail/index.html?pid=10111947021 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 12:33, schrieb Peter Wendorff: Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Natürlich gelten die Eigenschaften hier oft nicht für beide Teile, das fängt schon beim Namen an - der Geldautomat hat in der Regel gar keinen. Aber amenity=bank;atm ist sowieso ein schlechtes Beispiel. Denn das ist kein Objekt, das gleichzeitig ein Geldautomat und eine Bank ist. Das ist ein Geldautomat *in* einer Bank. Also sollte man m.E. einen node mit amenity=atm in der Fläche der Bank platzieren. Dann kann man auch noch zusätzliche Tags für den Geldautomaten und die Bank unabhängig vergeben. An sich könnte eine Software so eine liegt im Polygon-Geschichte sogar auswerten und auf die is in-Beziehung kommen. Praktischerweise funktionieren die üblichen Anwendungen aber auch ohne diesen Zusatzaufwand ganz gut. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
Am 11.10.2010 13:37, schrieb Philip Gillißen: Daher meine Frage an die Liste: Gibt es eine aktuelle XSD für die API 0.6? Es gibt nicht das API 0.6 Schema sondern nur eine Erklärung, was die einzelnen Tags in den XML-Files genau bedeuten. Daher benutzt jedes Tool (Planet-Dumper, API, Osmosis, JOSM) seinen eigenen Dialekt. Es sollte jedoch Möglich sein, ein Schema zu definieren, das alle Dialekte abdeckt -- nur ob das ist was man(tm) will... Dies ist, hoffe ich, etwas das mit API 0.7 vereinheitlicht wird. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 12:33 schrieb Peter Wendorff wendo...@uni-paderborn.de: Das geht wahrscheinlich oft auch nicht so einfach, weil an dem Knoten noch andere Eigenschaften, zum Beispiel die Adresse, dranhängen können. Dann hättest du diese Information auch dupliziert, was du wahrscheinlich nicht willst. Für die grafische Darstellung ist das egal - nur wird meist einer der Knoten dann immer noch rausfallen, weil zwei POIs auf dem gleichen Punkt zufällig oder aus anderen Gründen auf einen reduziert werden. +1 Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
Hallo, Peter Körner wrote: Dies ist, hoffe ich, etwas das mit API 0.7 vereinheitlicht wird. Oder wir kommen komplett von diesem ueberkandidelten XML weg, dann braucht man auch keine Schemata mehr ;) 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] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 12:48 schrieb Wolfgang wolfg...@ivkasogis.de: Übersicht schnell sparsamer werden: automatic_entrance_door=yes bar=yes blinking_leuchtreklame=no cafe=yes cuisine_greek=yes cuisine_italian=yes decoration_greek=yes decoration_italian=yes english_money_accepted=no english_spoken=yes euro_accepted=yes fish_dishes=yes german_spoken=yes good_speed_of_service=yes greek_music_sound=yes greek_spoken=yes high_qality_of_food=no interior_color_read=yes italian_music_sound=yes italian_spoken=yes japanese_spoken=no kitchen_visible=yes kitchen_visible_by_window=yes leuchtreklame=yes leuchtreklame_color_blue=yes leuchtreklame_color_red=yes maestro_card_accepted=yes master_card_accepted=yes music_box=yes music_box_accepts_credit_cards=no music_box_accepts_coins=yes number_of_seats=100 oven_in_guest_room=no outside_color_blue=yes pizza_oven=yes prices_high=yes restaurant=yes tables=25 traveller_cheques_accepted=yes visa_card_accepted=yes weelchair_geeignet=yes Da habe ich natürlich maßlos übertrieben. +1 und die Hierarchien, die wir durch Doppelpunkte zur Strukturierung erzeugen, mal eben ignoriert. Diese Liste würde auch durch Mehrfachwerte kaum übersichtlicher: im Gegenteil (zugegebermaßen sowohl von den konkreten Editoren als auch von den persönlichen Präferenzen und auch von der Maus/Steuerung abhängig): Während lange (Mehrfach-)Werte in der meist schmalen (in Potlatch 1 definitiv zu schmalen) Valuespalte oft horizontales Scrollen erfordern, ist eine lange Liste in der Regel durch bessere Unterstützung von vertikalem Scrolling (Mausrad) einfacher handlebar. Wenn wir uns einem Punkt annähern, dass viele Objekte so lange Attributslisten haben, wird sich sicherlich auch auf Editorseite eine Lösung finden, diese gruppiert / strukturiert zu präsentieren. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
Am 11.10.2010 15:50, schrieb Frederik Ramm: Hallo, Peter Körner wrote: Dies ist, hoffe ich, etwas das mit API 0.7 vereinheitlicht wird. Oder wir kommen komplett von diesem ueberkandidelten XML weg, dann braucht man auch keine Schemata mehr ;) Egal welches Format wir zum Serialisieren der Daten in einen Byte-Strom benutzen (XML, JSON oder PBF) - es sind immer Schemata nötig, die möglichst einheitlich sein sollten. Ich fürchte mich ja ein wenig vor den PBFs da es eben noch nicht für jede Sprache eine Bindung gibt (PHP? Python?), ich jedoch gerne PHP als Glue-Sprache für alle möglichen Auswertungen (z.B. [1]) verwende. Es gibt derzeit nach meinem Wissensstand nicht einmal eine allgemeine C oder C++ Lib, die man mit PHP verbinden könnte, obwohl sowas aus pbf2osm [2] hervor gehen könnte. XML Support ist dagegen Allgegenwärtig. Lg, Peter [1] http://svn.toolserver.org/svnroot/mazder/experimental_osmdoc_import/ [2] http://git.openstreetmap.nl/index.cgi/pbf2osm.git/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 00:07, schrieb Guenther Meyer: bloed nur, dass sich sowas nicht anders darstellen laesst. http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags :) Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
On 10/11/2010 04:44 PM, Peter Körner wrote: Ich fürchte mich ja ein wenig vor den PBFs da es eben noch nicht für jede Sprache eine Bindung gibt (PHP? Python?), ich jedoch gerne PHP als Glue-Sprache für alle möglichen Auswertungen (z.B. [1]) verwende. für PHP siehts tatsächlich noch finster aus, aber ich werde mich vermutlich in kürze darauf stürzen ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11.10.2010 17:10, schrieb Peter Körner: http://wiki.openstreetmap.org/wiki/API_v0.7#Multiple_Tags :) Oh, eine API V0.7 Wunschliste. Gut gefällt mir: No trolls We need to ruthlessly hunt down and exterminate trolls wherever they may be found. :-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 15:46, M∡rtin Koppenhoefer wrote: Am 11. Oktober 2010 12:33 schrieb Peter Wendorffwendo...@uni-paderborn.de: Die zusätzlichen Eigenschaften sind aus anderer Hinsicht ein Problem: Gehören die wirklich zu beiden Teilen des doppel-Tags? Was ist bei amenity=bank;atm mit opening_hours? Gelten die wirklich nur für die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. An vielen Stellen wird es aber trotzdem so gemacht, weil verschiedene Entitäten eben nicht sauber getrennt werden. Das Beispiel von Bank und Geldautomat ist eins, Bei Tankstellen ist die Zahlungsmodalität während der Öffnungszeiten und am Automaten zu unterscheiden. Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. Beispiel Tankstelle: Gleiche Zapfsäule(n), aber unterschiedliche Daten; mehrere Nodes machen? blöde Redundanz von Sprit-Sorten, operator, brand etc. Beispiel Post: operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) Ich merke immer wieder, dass Leute Nodes mergen, die unterschiedliche; auch widersprüchliche Attribute haben. Das wird hier erst recht der Fall sein. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... Pizzerien sind nunmal lange nicht immer italienische Restaurants, italienische Restaurants haben aber tatsächlich nicht immer Pizza auf der Karte (Ausnahme z.B. Raffaello in Kassel - wobei das italienische Küche ohne Pizza mit ägyptischem Koch ist; lecker (und leider teuer) isses trotzdem). Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. Vielleicht ist dies wieder ein Beispiel für eine blöde Vermischung von Tags. Als ich wegen dem Raffaello grade meine Freundin fragte, meinte sie andererseits: Pizza ist für mich italienisch. wenn da Pizza und Türkisch steht, würde ich Lahmacun erwarten. Das ist sicherlich geprägt von der Anwenderseite - die Tags sind IMHO nicht so gemeint und zu interpretieren. Als Beispiel zeigt es aber, denke ich, dass mehrfache Werte durchaus sinnvoll sein könnten, ohne dass das ein Fehler in den Daten wäre (wenn man es nicht grundsätzlich verbietet). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO geht nicht auf 60Csx
Hallo *, die neue Bayernkarte vom 2010.10.09 funktioniert wieder wie erhofft. Gruß Kai ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Offline Tile Server?
André Joost schrieb am 10.10.2010 18:14:
Eigentlich brauchst du gar keinen Server dafür. Es reicht, wenn du den
Aufruf in Openlayers in der openStreetMap.js umbiegst:
OpenLayers.Layer.OSM.Mapnik = OpenLayers.Class(OpenLayers.Layer.OSM, {
/**
* Constructor: OpenLayers.Layer.OSM.Mapnik
*
* Parameters:
* name - {String}
* options - {Object} Hashtable of extra options to tag onto the
layer
*/
initialize: function(name, options) {
var url = [
file:///D:/Tiles/Mapnik/${z}/${x}/${y}.png
];
options = OpenLayers.Util.extend({ numZoomLevels: 19 }, options);
var newArguments = [name, url, options];
OpenLayers.Layer.OSM.prototype.initialize.apply(this,
newArguments);
},
CLASS_NAME: OpenLayers.Layer.OSM.Mapnik
Danke fuer den Tipp. Das sieht doch so aus, als ob es mein Problem loesen
muesste, und neben bei lerne ich dann auch gleich noch mal OpenLayers kennen :-)
Gruss
Torsten
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 17:58 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 11.10.2010 15:46, M∡rtin Koppenhoefer wrote: die Bank? oder ist der Automat bei geschlossener Bank auch nicht zugänglich? das ist dann ein Problem (Fehler) in den Daten. Die anderen tags müssen für alles gelten, sonst ist ein doppelter Wert sowieso nicht möglich. An vielen Stellen wird es aber trotzdem so gemacht, weil verschiedene Entitäten eben nicht sauber getrennt werden. ja, aber es bleibt falsch. Es gibt sehr viele Fehler in den Daten, manche sind offenkundig, andere eher versteckt oder im Detail. Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) wobei ich da (sorry kenne mich nicht 100% aus, weil kaum je damit in Berührung gekommen) doch der Ladenbetreiber im Auftrag der Post handelt, oder? Von daher wäre er doch der operator und die Post was für den brand-tag. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. Pizzerien sind nunmal lange nicht immer italienische Restaurants, italienische Restaurants haben aber tatsächlich nicht immer Pizza auf der Karte ja klar Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. na komm, das Schnitzel lassen wir den Österreichern. ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gültige XSD für API 0.6
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo! Am 11.10.2010 15:33, schrieb Peter Körner: Es gibt nicht das API 0.6 Schema sondern nur eine Erklärung, was die einzelnen Tags in den XML-Files genau bedeuten. Daher benutzt jedes Tool (Planet-Dumper, API, Osmosis, JOSM) seinen eigenen Dialekt. Aber warum ist das so? Das OSM-Format ist doch nicht so kompliziert, um eine Basis-Abdeckung zu bekommen. Es sollte jedoch Möglich sein, ein Schema zu definieren, das alle Dialekte abdeckt -- nur ob das ist was man(tm) will... Die Dialekte braucht es ja nicht abdecken, nur das generelle OSM-XML-Format, das der Server liefert. Wer ist denn zuständig für die Server-Komponente, die die .osm-Dateien erstellt? Gruß, Philip -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyzSFgACgkQYNYFUFLXAD1IQgCfTZY8sKZ6lkcEgC7a+o3UnJxr LWYAmQFiHM3Z90fuHquxlnEyXp52aCrA =kG63 -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
On 11.10.2010 19:06, M∡rtin Koppenhoefer wrote: Am 11. Oktober 2010 17:58 schrieb Peter Wendorffwendo...@uni-paderborn.de: Poststellen innerhalb von Geschäften sind mehrfach diskutiert worden - hier kann der operator unterschiedlich sein. operator gilt einmal für das Postunternehmen (Deutsche Post/Hermes/), aber auch für den Laden (Tante Emma/...) wobei ich da (sorry kenne mich nicht 100% aus, weil kaum je damit in Berührung gekommen) doch der Ladenbetreiber im Auftrag der Post handelt, oder? Von daher wäre er doch der operator und die Post was für den brand-tag. brand ist die Marke... Ich hab zwar kein praktisches Beispiel, wo diese Kombination tatsächlich vorkommt, aber auch ein Laden an sich kann ein brand haben. Bei Kleidungsgeschäften ist das häufig, bei Schreibwarenläden und Kiosken, die meist als Post-Annahmestellen handeln, kenne ich es tatsächlich nicht. Trotzdem finde ich diese Lösung aus dem Grund nicht gut. Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. ja? wie lokal ist das denn dann? gutbürgerlich Deutsch oder gutbürgerlich Bayrisch? oder die ganz besonderen Dorfspezialitäten? Ähnliches ließe sich in Deutschland mit Schnitzel und german finden, denke ich. na komm, das Schnitzel lassen wir den Österreichern. ;-) Als Wiener Schnitzel sicherlich, aber ob das Schweineschnitzel Wiener Art wirklich auf Österreich zu beschränken wäre, weiß ich nicht - nichtmal, ob die Österreicher (oder zumindest die Wiener) damit wirklich glücklich sind Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
Am 11. Oktober 2010 20:53 schrieb Peter Wendorff wendo...@uni-paderborn.de: On 11.10.2010 19:06, M∡rtin Koppenhoefer wrote: Bei Restaurants ist cuisine nochmal so eine Sache: cuisine=pizza vs. cuisine=italian... ja, wobei das auch so eine Sache ist. Italienische Küche gibt es vielleicht im Ausland, in Italien ist man da aber doch deutlich genauer (jede Region hat ihre eigene Küche, z.T. auch noch feingranularer --- in OSM allerdings bisher noch nicht so richtig durchdacht). Ich nutze meistens cuisine=local, weil es das noch am genauesten beschreibt. ja? wie lokal ist das denn dann? gutbürgerlich Deutsch oder gutbürgerlich Bayrisch? oder die ganz besonderen Dorfspezialitäten? es gibt ja auch noch regional, was für Dein Bayern-beispiel wohl am besten passt. Das ist übrigens weltweit auch der häufigste Wert überhaupt im cuisine-tag http://taginfo.openstreetmap.de/keys/cuisine wobei die deutsche Küche international auch einen guten Stand zu haben scheint (gleich nach burgern, italienisch und chinesisch) ;-) Sowas wie cuisine=german macht eigentlich sowieso keinen Sinn, wie Du selbst auch schon erkannt hast, es gibt nicht die deutsche Küche, sondern jeweils regionale Varianten davon. Wäre was für einen Subtag. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] api-download bei semikon-getrennten-values
nochmal kurz zum Thema: cuisine=pizza;kebab 111x cuisine=kebab;pizza 158x eine Definition, dass die Reihenfolge durch den Mapper alphabetisch erfolgen sollte, würde hier schonmal für sowas wie cuisine=pizza;kebab 3x cuisine=kebab;pizza 266x sorgen ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Element-Historie.....
Hallo, Am Montag 11 Oktober 2010 schrieb M∡rtin Koppenhoefer: Am 10. Oktober 2010 16:30 schrieb Matthias Versen ma...@mversen.de: Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Über die Changesets sind die zwei Teile doch noch verbunden, darüber liese sich doch bestimmt die Historie zurückverfolgen, oder? Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel: - was ist mit den nicht erreichten....
Am 10.10.2010 13:20, schrieb Jan Tappenbeck: Aus eigenen Gesprächen habe ich erfahren das Mapper gesagt haben - ich mache kein Kreuz - sollen andere über irgendwelche Lizenzen entscheiden... Denkt bitte auch über dieses nochmal nach Das blöde ist, dass die bereits ein Kreuz gemacht haben, nämlich in dem Moment, in dem sie sich registriert haben. Dieses Kreuz verbietet den von dir vorgeschlagenen Weg denn es kann nicht einfach ignoriert werden. Lg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Element-Historie.....
Hallo, Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Über die Changesets sind die zwei Teile doch noch verbunden, darüber liese sich doch bestimmt die Historie zurückverfolgen, oder? Hier sind jetzt ein paar Sachen durcheinander gekommen. 1. Wir haben keine History aus der Zeit vor API 0.5, also vor Oktober 2007. Damals hatte OSM rund 30 Millionen Nodes und 3 Millionen Ways, heute haben wir 750 Millionen Nodes und 60 Millionen Ways, d.h. zu etwa 5% unserer heutigen Daten fehlt die History (in der Praxis duerfte die Zahl kleiner sein, weil viele von diesen Altdaten vermutlich auch im Lauf der Zeit geloescht wurden). Im Zuge des Lizenzwechsels werden wir vermutlich ein altes Backup raussuchen muessen, um auf die alte History zuzugreifen. 2. Changesets wurden erst mit API 0.6, also seit April 2009, aufgezeichnet. Allerdings wurden beim Wechsel von 0.5 zu 0.6 Changesets fuer die damals bestehende History synthetisiert, indem Aenderungen des gleichen Users im gleichen Zeitraum zusammengefasst wurden, so dass man weitgehend so tun kan, als ob es schon immer welche gegeben haette. 3. In der Tat kann das Aufspalten eines Ways, oder auch das Loeschen und Neuanlegen eines Ways, aus einer Analyse der Changesets erkannt werden. 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] Element-Historie.....
Am 11.10.2010 23:12, schrieb Frederik Ramm: Hallo, Nach mehrmaligen splitten und löschen kann man nicht mehr nachvollziehen wer die Daten ursprünglich erstellt hat. Ist das eigentlich immer noch der Fall, oder gilt das nur für Altdaten, die unter einer anderen API-Version als der aktuellen bearbeitet wurden? Über die Changesets sind die zwei Teile doch noch verbunden, darüber liese sich doch bestimmt die Historie zurückverfolgen, oder? Hier sind jetzt ein paar Sachen durcheinander gekommen. 1. Wir haben keine History aus der Zeit vor API 0.5, also vor Oktober 2007. Damals hatte OSM rund 30 Millionen Nodes und 3 Millionen Ways, heute haben wir 750 Millionen Nodes und 60 Millionen Ways, d.h. zu etwa 5% unserer heutigen Daten fehlt die History (in der Praxis duerfte die Zahl kleiner sein, weil viele von diesen Altdaten vermutlich auch im Lauf der Zeit geloescht wurden). Im Zuge des Lizenzwechsels werden wir vermutlich ein altes Backup raussuchen muessen, um auf die alte History zuzugreifen. 2. Changesets wurden erst mit API 0.6, also seit April 2009, aufgezeichnet. Allerdings wurden beim Wechsel von 0.5 zu 0.6 Changesets fuer die damals bestehende History synthetisiert, indem Aenderungen des gleichen Users im gleichen Zeitraum zusammengefasst wurden, so dass man weitgehend so tun kan, als ob es schon immer welche gegeben haette. 3. In der Tat kann das Aufspalten eines Ways, oder auch das Loeschen und Neuanlegen eines Ways, aus einer Analyse der Changesets erkannt werden. Bye Frederik also wenn ich das richtig sehe ist das eine menge aufwand die alten daten zu löschen und wenn es einer darauf anlegt ist eine verschleierung möglich ?!?! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
