Re: [Talk-de] Navigationsprogramme fuer Android
On Sat, 3 Jan 2009 08:11:22 +0100, Bernd Wurst wrote: Oder bist du Heise-Mitarbeiter und dir geht im Herzen die Sonne auf wenn alle die c't kaufen gehen um zu sehen was du meinst? Das wird nicht passieren, denn die Artikel zu GPS sind s schlecht gewesen daß deswegen dieses Blatt nicht mehr gekauft wird. Ich hab aus dem Grund mein Abo gekündigt. -- Ciao, Holger (GUS-KOTAL, GUS#1100, GRR#51) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - News II
Wie kann man diese Karte abrufen? dgdg -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Jutta Weisel Gesendet: Freitag, 2. Januar 2009 22:30 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapping Quality - News II Hallo, man sieht an der Karte sehr schön die Problematik der zu Großgemeinden zusammengefassten Dörfer. Der Mittelpunkt der Großgemeinde liegt in der Regel da, wo sonst nix ist. Die Dörfer der Großgemeinde sind zudem mal als village, mal als suburb gemappt. - Jutta Zitat von Gary68 g...@gary68.de: hi, so, nun ist ganz deutschland mit der version 1.2 BETA gerechnet. bayern musste ich wieder mal teilen, das wird zu groß... es gibt nun auch mehr statistik werte als zuvor. wie ganz früher. wer die rohdaten brauchen kann, bitte in den csv-dateien nachsehen! ciao gerhard gary68 Am Donnerstag, den 01.01.2009, 21:22 +0100 schrieb Gary68: hi, wer möchte, kann sich mal http://www.gary68.de/osm/qa/unmapped/hessen.png ansehen. neues: - radius daten können aus osm daten (tags) gewonnen werden - kann man hier noch nicht sehen. siehe auch http://wiki.openstreetmap.org/wiki/Mapping_Quality - ich habe eine automatische erkennung der ausdehnung gebaut. sie funktioniert bei etwa 20% der places. das ist aber relativ, da sie unmapped places nicht berücksichtigt. die kreise beschreiben die (angenommene) ausdehnung - blau = osm (hier noch nicht zu sehen) - orange = auto - dunkel grau = default (wie gehabt) unter den kreisen stehen die radien. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- http://www.weisel.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] Mapping Quality - News II
hi, der link ins wiki ist doch unten angegeben. und dann die png dateien ansehen. http://wiki.openstreetmap.org/wiki/Mapping_Quality gerhard Am Samstag, den 03.01.2009, 09:34 +0100 schrieb dgdg: Wie kann man diese Karte abrufen? dgdg -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Jutta Weisel Gesendet: Freitag, 2. Januar 2009 22:30 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapping Quality - News II Hallo, man sieht an der Karte sehr schön die Problematik der zu Großgemeinden zusammengefassten Dörfer. Der Mittelpunkt der Großgemeinde liegt in der Regel da, wo sonst nix ist. Die Dörfer der Großgemeinde sind zudem mal als village, mal als suburb gemappt. - Jutta Zitat von Gary68 g...@gary68.de: hi, so, nun ist ganz deutschland mit der version 1.2 BETA gerechnet. bayern musste ich wieder mal teilen, das wird zu groß... es gibt nun auch mehr statistik werte als zuvor. wie ganz früher. wer die rohdaten brauchen kann, bitte in den csv-dateien nachsehen! ciao gerhard gary68 Am Donnerstag, den 01.01.2009, 21:22 +0100 schrieb Gary68: hi, wer möchte, kann sich mal http://www.gary68.de/osm/qa/unmapped/hessen.png ansehen. neues: - radius daten können aus osm daten (tags) gewonnen werden - kann man hier noch nicht sehen. siehe auch http://wiki.openstreetmap.org/wiki/Mapping_Quality - ich habe eine automatische erkennung der ausdehnung gebaut. sie funktioniert bei etwa 20% der places. das ist aber relativ, da sie unmapped places nicht berücksichtigt. die kreise beschreiben die (angenommene) ausdehnung - blau = osm (hier noch nicht zu sehen) - orange = auto - dunkel grau = default (wie gehabt) unter den kreisen stehen die radien. ___ 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] Mapping Quality - News II
Den Link hatte ich gesehen. Auch den direkten Link auf das PNG-Image von Hessen. Aber wenn ich versuche, das PNG-Image von Hessen abzurufen (Firefox 3 unter Windows XP) bekomme ich lediglich die Meldung: Die Grafik http://www.gary68.de/osm/qa/unmapped/hessen.png kann nicht angezeigt werden, weil sie Fehler enthält. Manche Bunderlänger bekomme ich angezeigt (z.B. BW und Berlin). Andere funktionieren ebenfalls nicht. Detlef -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Gary68 Gesendet: Samstag, 3. Januar 2009 09:52 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Mapping Quality - News II hi, der link ins wiki ist doch unten angegeben. und dann die png dateien ansehen. http://wiki.openstreetmap.org/wiki/Mapping_Quality gerhard Am Samstag, den 03.01.2009, 09:34 +0100 schrieb dgdg: Wie kann man diese Karte abrufen? dgdg -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Jutta Weisel Gesendet: Freitag, 2. Januar 2009 22:30 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapping Quality - News II Hallo, man sieht an der Karte sehr schön die Problematik der zu Großgemeinden zusammengefassten Dörfer. Der Mittelpunkt der Großgemeinde liegt in der Regel da, wo sonst nix ist. Die Dörfer der Großgemeinde sind zudem mal als village, mal als suburb gemappt. - Jutta Zitat von Gary68 g...@gary68.de: hi, so, nun ist ganz deutschland mit der version 1.2 BETA gerechnet. bayern musste ich wieder mal teilen, das wird zu groß... es gibt nun auch mehr statistik werte als zuvor. wie ganz früher. wer die rohdaten brauchen kann, bitte in den csv-dateien nachsehen! ciao gerhard gary68 Am Donnerstag, den 01.01.2009, 21:22 +0100 schrieb Gary68: hi, wer möchte, kann sich mal http://www.gary68.de/osm/qa/unmapped/hessen.png ansehen. neues: - radius daten können aus osm daten (tags) gewonnen werden - kann man hier noch nicht sehen. siehe auch http://wiki.openstreetmap.org/wiki/Mapping_Quality - ich habe eine automatische erkennung der ausdehnung gebaut. sie funktioniert bei etwa 20% der places. das ist aber relativ, da sie unmapped places nicht berücksichtigt. die kreise beschreiben die (angenommene) ausdehnung - blau = osm (hier noch nicht zu sehen) - orange = auto - dunkel grau = default (wie gehabt) unter den kreisen stehen die radien. ___ 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] Mapping Quality - News II
Den Link hatte ich gesehen. Auch den direkten Link auf das PNG-Image von Hessen. Aber wenn ich versuche, das PNG-Image von Hessen abzurufen (Firefox 3 unter Windows XP) bekomme ich lediglich die Meldung: Die Grafik http://www.gary68.de/osm/qa/unmapped/hessen.png kann nicht angezeigt werden, weil sie Fehler enthält. Manche Bunderlänger bekomme ich angezeigt (z.B. BW und Berlin). Andere funktionieren ebenfalls nicht. Ich habe jetzt den Link auf die Slippy-Map gefunden. ;-) Alles klar! Detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - News II
Zu dem Thema Gemeinden und Ortsteile hatte ich im OSM-Forum eine Diskussion angestossen, weil ich mir unsicher war, wie man das am sinnvollsten taggt. Inzwischen habe ich einige Gemeinden (Fronhausen, Ebsdorfergrund und Weimar) mal probeweise mit village und suburb getaggt - mit eine virtuellen Place-Node für die Flächengemeinde. Vorher hatte ich alles mit village getaggt (auch die Ortsteile) und die Verbindung nur über is_in hergestellt. Aber was macht man mit Gemeinden wie Ebsdorfergrund, Weimar (Lahn) oder Lahntal. Da gibt es keinen geografischen Ort an dem man die politische Gemeinde festmachen kann. Also kommt man nicht drum herum für die Gemeinde einen virtuellen Place-Node in die Landschaft zu setzen. Und dann sollte man das meiner Meinung nach immer so machen. Detlef -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Jutta Weisel Gesendet: Freitag, 2. Januar 2009 22:30 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapping Quality - News II Hallo, man sieht an der Karte sehr schön die Problematik der zu Großgemeinden zusammengefassten Dörfer. Der Mittelpunkt der Großgemeinde liegt in der Regel da, wo sonst nix ist. Die Dörfer der Großgemeinde sind zudem mal als village, mal als suburb gemappt. - Jutta Zitat von Gary68 g...@gary68.de: hi, so, nun ist ganz deutschland mit der version 1.2 BETA gerechnet. bayern musste ich wieder mal teilen, das wird zu groß... es gibt nun auch mehr statistik werte als zuvor. wie ganz früher. wer die rohdaten brauchen kann, bitte in den csv-dateien nachsehen! ciao gerhard gary68 Am Donnerstag, den 01.01.2009, 21:22 +0100 schrieb Gary68: hi, wer möchte, kann sich mal http://www.gary68.de/osm/qa/unmapped/hessen.png ansehen. neues: - radius daten können aus osm daten (tags) gewonnen werden - kann man hier noch nicht sehen. siehe auch http://wiki.openstreetmap.org/wiki/Mapping_Quality - ich habe eine automatische erkennung der ausdehnung gebaut. sie funktioniert bei etwa 20% der places. das ist aber relativ, da sie unmapped places nicht berücksichtigt. die kreise beschreiben die (angenommene) ausdehnung - blau = osm (hier noch nicht zu sehen) - orange = auto - dunkel grau = default (wie gehabt) unter den kreisen stehen die radien. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- http://www.weisel.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] Mapping Quality - News II
das ist nicht das, was du gesucht hast! lade die pngs herunter und lasse sie dir mit einem grafikprogramm anzeigen! firefox 3.0.5 unter linux kein probelm... ciao gerhard Am Samstag, den 03.01.2009, 10:10 +0100 schrieb dgdg: Den Link hatte ich gesehen. Auch den direkten Link auf das PNG-Image von Hessen. Aber wenn ich versuche, das PNG-Image von Hessen abzurufen (Firefox 3 unter Windows XP) bekomme ich lediglich die Meldung: Die Grafik http://www.gary68.de/osm/qa/unmapped/hessen.png kann nicht angezeigt werden, weil sie Fehler enthält. Manche Bunderlänger bekomme ich angezeigt (z.B. BW und Berlin). Andere funktionieren ebenfalls nicht. Ich habe jetzt den Link auf die Slippy-Map gefunden. ;-) Alles klar! Detlef ___ 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] Mapping Quality - News II
Am Samstag, den 03.01.2009, 10:41 +0100 schrieb Gary68: lade die pngs herunter und lasse sie dir mit einem grafikprogramm anzeigen! firefox 3.0.5 unter linux kein probelm... Hallo, vielleicht solltest Du einen Hinweis anbringen, das man entweder ein gutes Grafikprogramm verwenden muß (eins mit intelligenter Speicherverwaltung) oder über ausreichend Speicher verfügen sollte. Mein Versuch BaWü zu öffnen habe ich mit firefox abgebrochen, nachdem er auch noch nach ein paar Minuten damit beschäftigt war alles andere was läuft in den Swap auszulagern. Das ist mit einem GB RAM und einer handvoll geöffneter Programme passiert. Grüßle, detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - News II
Ich sehe es gerade: 8192 x 12107 Pixel. Das muss der Browser nicht anzeigen können. Nur die Fehlermeldung könnte etwas aussagekräftiger sein. Ja, und ein Hinweis im Wiki wäre auf jeden Fall sinnvoll. Detlef -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Detlef Reichl Gesendet: Samstag, 3. Januar 2009 10:50 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Mapping Quality - News II Am Samstag, den 03.01.2009, 10:41 +0100 schrieb Gary68: lade die pngs herunter und lasse sie dir mit einem grafikprogramm anzeigen! firefox 3.0.5 unter linux kein probelm... Hallo, vielleicht solltest Du einen Hinweis anbringen, das man entweder ein gutes Grafikprogramm verwenden muß (eins mit intelligenter Speicherverwaltung) oder über ausreichend Speicher verfügen sollte. Mein Versuch BaWü zu öffnen habe ich mit firefox abgebrochen, nachdem er auch noch nach ein paar Minuten damit beschäftigt war alles andere was läuft in den Swap auszulagern. Das ist mit einem GB RAM und einer handvoll geöffneter Programme passiert. Grüßle, detlef ___ 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] Mapping Quality - News II
lade die pngs herunter und lasse sie dir mit einem grafikprogramm anzeigen! Ja, das funktioniert. das ist nicht das, was du gesucht hast! Doch schon. Die Slippy-Map mit den eingezeichneten ungemappten Orten war eigentlich schon das, was ich gesucht hatte. Detlef -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Gary68 Gesendet: Samstag, 3. Januar 2009 10:41 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Mapping Quality - News II das ist nicht das, was du gesucht hast! lade die pngs herunter und lasse sie dir mit einem grafikprogramm anzeigen! firefox 3.0.5 unter linux kein probelm... ciao gerhard Am Samstag, den 03.01.2009, 10:10 +0100 schrieb dgdg: Den Link hatte ich gesehen. Auch den direkten Link auf das PNG-Image von Hessen. Aber wenn ich versuche, das PNG-Image von Hessen abzurufen (Firefox 3 unter Windows XP) bekomme ich lediglich die Meldung: Die Grafik http://www.gary68.de/osm/qa/unmapped/hessen.png kann nicht angezeigt werden, weil sie Fehler enthält. Manche Bunderlänger bekomme ich angezeigt (z.B. BW und Berlin). Andere funktionieren ebenfalls nicht. Ich habe jetzt den Link auf die Slippy-Map gefunden. ;-) Alles klar! Detlef ___ 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] Navigationsprogramme fuer Android
Danke Bernd für die konstruktive Kritik;-) also, in dem Artikel geht es um ein Navigationsprogramm das auf Googles Android läuft. Dieses Progamm nennt sich ANDNav2 und benutzt die Karten von OSM als Basis. Bei YOUTUBE kann man sogar Videos sehen aus denen ersichtlich ist, das die Sache funktioniert. Einfach mal in einer Suchmaschine nachschauen. Übrigens: bin kein Mitarbeiter von c't Gruß Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapping Quality - News II
jeder kann das wiki bearbeiten!!! aber ich mache es eben. habe übrigens bisher auch im browser nie ein problem gehabt. auch 1gb speicher. ubuntu 8.04. und ff3.0.5 aber ich gebe zu, es hat etwas gedauert :-) Am Samstag, den 03.01.2009, 10:55 +0100 schrieb dgdg: Ich sehe es gerade: 8192 x 12107 Pixel. Das muss der Browser nicht anzeigen können. Nur die Fehlermeldung könnte etwas aussagekräftiger sein. Ja, und ein Hinweis im Wiki wäre auf jeden Fall sinnvoll. Detlef ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Modifikation der surveyor.xml des surveyor plugin
Hallo, ich möchte die surveyor.xml meinen Bedürfnissen anpassen. 1. Kann die Wartezeit von 4 sec nach Eingabe verkürzt werden?. 2. Wie kann ich eigene icons einbinden? 3. Habe die Funktion toggle noch nicht richtig einbinden können. 4. Mein Notebook hat ein zuätzliches Keypad. Diese Taste haben bei Benutzung der der Beispiels-surveyor-Datei keine Funktion. Was ist zu tun, um diese fasten bzw. ein seoparates Keypad (Ziffern) nutzen zu können? Benutze JOSM mit Vista MfG Dieter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] right/left
Bjørn Bürger schrieb: Auch Fuß- und Radwege haben baulich definierte Übergangspunkte. Und die willst Du definitiv haben, da sonst ein vernünftiges Fußgänger- und Radrouting immer nur Makulatur bleiben wird. Ich sehe aktuell das Hauptproblem darin, dass wir nicht definieren können, ob die Wege baulich getrennt sind oder ob man einfach rüberlaufen kann. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigationsprogramme fuer Android
Das ist übrigens kein Artikel sondern eine Pressemeldung, die von der c't abgedruckt wurde. Außer dass AndNav Routing auf Basis von OSM-Karten unterstützen soll, steht da nichts drin. Nicht dass jetzt alle loslaufen und deswegen die c't kaufen. ;-) Detlef -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org]im Auftrag von Michael Gerst Gesendet: Samstag, 3. Januar 2009 11:15 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Navigationsprogramme fuer Android Danke Bernd für die konstruktive Kritik;-) also, in dem Artikel geht es um ein Navigationsprogramm das auf Googles Android läuft. Dieses Progamm nennt sich ANDNav2 und benutzt die Karten von OSM als Basis. Bei YOUTUBE kann man sogar Videos sehen aus denen ersichtlich ist, das die Sache funktioniert. Einfach mal in einer Suchmaschine nachschauen. Übrigens: bin kein Mitarbeiter von c't Gruß Michael ___ 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] right/left
Hallo, Also JOSM fragt dann, ob er den einen Weg in der Relation jetzt durch die zwei neuen Wege ersetezen soll Wenn ich so für right/left arumentiere kommt regelmäßig ein es gibt auch noch andere Editoren Sind wir us einig, daß wenn man einen ganzen Weg zur Einbahnstraße machen will beide Lösungen: 1)den gleichen Informationsgehalt haben, beide mit entsprechender Untersttzung des Editors kein Problem mit Drehen haben. 2)die Relation aufwändiger ist Wenn man nur einen Teil eines Weges zur Einbahnstraße machen will könnte man mit der Relation das Zerteilen des Weges umgehen. Dies sollte aber nicht auf Einbahnstraßen beschränkt sein. Ich habe ja schonmal vorgeschlagen eine Relation zu definieren, die Weg, Anfangs und Endpunkt enthält und zusätzlich alle Tags akzeptiert die man auch für einen ganzen Weg vergeben könnte. So könnte man auch z.B. unterschiedliche Geschwindigkeitsbeschränkungen auf einem Teil der Straße, usw eintragen. Aber auch da wäre es sinnvoll angeben zu können ob es für beide Seiten/Fahrtrichtungen gilt oder nur für eine. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] right/left
Hallo, Auch Fuß- und Radwege haben baulich definierte Übergangspunkte. Ich weiß ja nicht wo Du wohnst, aber in der realen Welt gibt es große Straßen mit Ampeln wo man die Straße nur dort überqueren soll, aber kleine Straßen haben keine Übergänge, da kann man die Straße also überall überquern. Und wenn mir ein Router sagt ich soll an der T-Kreuzung rechts abbiegen, bis zur nächsten Kreuzung gehen, dann zurück gehen und stelle dann fest, daß das gesuchte Haus fast genau gegenüber der T-Kreuzung war, das ist das Müll. Es müßte also auch bei getrennten Wegen entweder jede mögliche/erlaubte Wechselmöglichkeit als Querweg eingezeichnet werden, oder per Relation gesagt werden, man kann zwischen Spur A und Spur B: -immer -etwa alle 10m -nur an Kreuzungen -nie wechseln Ja, das sind eine Menge Daten. Aber wo ist das Problem? Vom jetzigen OSM Stand haben die Experten vor Jahren ja auch behauptet, daß man sowas niemals als freies Projekt umsetzen könne, weil es zu viele Daten seien. Wir haben jetzt in vielen Gebieten einen Stand erreicht wo die Karte schon brauchbar ist. Wir sollten also Mappingregeln finden mit denen man einfach und schnell die fehlenden Infos hinzufügen können, wenn dann jemand später dies nach detailierter machen will soll er es machen, vorausgesetzt die Daten werden dadurch nicht unbrauchbar, wir brauchen meiner Meinung nach also beides. Wenn ein Autofahrer sieht, daß neben der langen Straße die er fährt ein Fahrradweg verläuft, ist es mir lieber er trägt ihn per cycleway=track ein, als er zuckt mit den Schultern und man wartet bis mal jemand wirklich per Fahrrad diesen abfährt. Die Info ob da ein Fahrradweg ist ist viel wichtiger als die Info ob er 10cm oder 1m neben der Straße verläuft oder auch ob er an der Kreuzung einen Schlenker macht. Ohne eine einfache Möglichkeit z.B. Fahrradwege zu mappen schrecken wir viele Mapper ab die sich eigentlich nicht für Fahrradwege interessieren. Ich mappe hauptsächlich zu Fuß, trage dann aber natürlich Auto, Fahrrad und Fußgängerinfos ein. Ich werde aber nicht auf der Straße laufen um diese zu vermessen, und wenn ich mal per Auto eine Autobahn aufnehme werde ich nicht dauernd auf der linken Fahrbahn fahren um diese als getrennten Weg mappen zu können. Wenn wir jemals in die Lage versetzt werden sollen, dafür ein vernünftiges Routing zu entwerfen, brauchen wir diese Details. Nochmal. Natürlich gibt es Fälle wo Zusatztags nicht ausreichen, oft reichen sie aber oder sind als Zwischenlösung besser als nichts. Nehmen wir hier die Triererstraße, dort verläuft ein Fahrradweg auf dem Bürgersteig absolut parallel zur Fahrbahn, teils durch einen 1m Grünstreifen getrennt. Aber etwa alle 10m ist der Grünstreifen unterbrachen, wegen Garageneinfahrten o.ä. Ein cycleway=track würde ein Router so interpretieren, daß man jederzeit wechseln kann, was fast stimmt, der jetzt dort vorhandene abgesetzte Weg ohne Querverbindungen zwischen den Kreuzungen würde dagegen so interpretiert, daß man immer zu nächsten Kreuzung muß um zu wechseln. Das ist deutlich ungeauer. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Navigationsprogramme fuer Android
Hallo, Das ist übrigens kein Artikel sondern eine Pressemeldung, die von der c't abgedruckt wurde. Außer dass AndNav Routing auf Basis von OSM-Karten unterstützen soll, steht da nichts drin. Nicht dass jetzt alle loslaufen und deswegen die c't kaufen. ;-) AndNav ist von Nicolas Gramlich (Frontend) und Pascal Neis (Backend). Anders als Pyroute, Navit Co. routet es nicht selber (im Client), sondern ueber einen OpenRouteService-Server im Netz (bin kein Hardware-Experte, aber vermutlich sind diese Androidgeraete auch nicht schnell genug, um im Client zu routen). Nico hatte das schon vor einigen Wochen auf der Liste angekuendigt, womoeglich nur auf talk und nicht auf talk-de. Ein Teil von AndNav, naemlich die eigentliche Viewer-Komponente fuer die Karten, so wie ich das verstanden hab, ist Open Source, die restliche Applikation nicht. Man kann auch Tracks damit aufzeichnen und hochladen. Hier die Ankuendigung vom Dezember: http://lists.openstreetmap.org/pipermail/talk/2008-December/032300.html Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] right/left
Hallo, Dimitri Junker wrote: Ich weiß ja nicht wo Du wohnst, aber in der realen Welt gibt es große Straßen mit Ampeln wo man die Straße nur dort überqueren soll, aber kleine Straßen haben keine Übergänge, da kann man die Straße also überall überquern. Und wenn mir ein Router sagt ich soll an der T-Kreuzung rechts abbiegen, bis zur nächsten Kreuzung gehen, dann zurück gehen und stelle dann fest, daß das gesuchte Haus fast genau gegenüber der T-Kreuzung war, das ist das Müll. Es müßte also auch bei getrennten Wegen entweder jede mögliche/erlaubte Wechselmöglichkeit als Querweg eingezeichnet werden, oder per Relation gesagt werden, man kann zwischen Spur A und Spur B: Prinzipiell laesst sich jede Strasse zu Fuss ueberqueren, nur das Gesundheitsrisiko dabei ist unterschiedlich. (Wie ist das rechtlich - ab welcher Strassenklasse/Bauart darf man die Fahrban nicht mehr betreten? Oder gibts da eine Gummiregel a la Verkehr nicht gefaehrden oder so?) Allerdings waere es gut, wenn wir sowohl ein pragmatisches Routing fuer gesunde Buerger im besten Alter anbieten koennen (folgen Sie der Xy-Strasse... gehen Sie links in die Zz-Strasse, und wenn Sie gerade dafuer auf der falschen Strassenseite sind, dann gehen sie halt rueber) als auch eines, das beispielsweise einen sicheren Schulweg berechnet und daher bei allem oberhalb von residential die Strasse nur an Ampeln und Zebrastreifen quert. (Und bei residential ebenso, falls in der Naehe eine Ampel ist, diese nutzt...) Oder sollte man die Querbarkeit durch Fussgaenger explizit an eine Strasse drantaggen? In einem Wohngebiet, in dem jede Strasse beliebig gequert werden kann, ist es m.E. zudem voellig irrelevant, auf welcher Seite der Strasse sich Fusswege befinden. Graphentechnisch gesprochen, wuerde in einem solchen Wohngebiet der Fussgaenger-Routing-Graph eine Kante pro Strasse haben; sobald es aber zu groesseren Strassen geht, waeren es zwei Kanten pro Strasse, eine links, eine rechts. Aeh... eine suedlich, eine noerdlich wollte ich sagen ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] mapping quality, kleiner renderer und perl modul veröffentlicht
hi, habe ein weiteres perl modul geschrieben, diesmal für die grafikausgabe von osm daten. mit dem modul osm.pm ist es dann ganz einfach, simple, aber benutzerspezifische karten zu zeichnen. beispiel siehe hier: http://wiki.openstreetmap.org/wiki/Osmrender.pl code: http://wiki.openstreetmap.org/wiki/User:Gary68 das programm mappingqualiy.pl bedient sich dieser funktionen. http://wiki.openstreetmap.org/wiki/Mapping_Quality (für Bsp. die pngs downloaden und in grafikprogramm ansehen). ciao gerhard gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Slippymap mit Position von Mappern?
Hallo zusammen, es nervt kollosal, dass man die Position von Mappern ab einem bestimmten Zoomlevel nicht einfach als Layer in der Slippymap aktivieren kann. Nun kenne ich mich leider nicht mit der Api aus. Deshalb meine Frage, gibt es einen API Call mit dem ich eine Liste von Mapperpositionen innerhalb einer Bounding Box abrufen kann? Im Worldfile sind diese Daten ja nicht drin. Wenn ja würde ich nämlich einfach selber mal eine solche Slippymap bauen. Gruss Sven -- If you don't make lower-resolution mapping data publicly available, there will be people with their cars and GPS devices, driving around with their laptops (Tim Berners-Lee) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Sven Geggus schrieb: Hallo zusammen, es nervt kollosal, dass man die Position von Mappern ab einem bestimmten Zoomlevel nicht einfach als Layer in der Slippymap aktivieren kann. Stimmt, die aktuelle Lösung ist extrem Community feindlich. Wenn man dann noch viele Karteileichen drin hat sind sofort die 10 User voll und man sieht überhaupt nicht, wen es noch so in der Gegend gibt. Und eigene Koordinaten verschieben ist auch keine tolle Lösung. Am besten wäre einfach alle User im Umkreis von 15km (auf die Zahl müsste man sich einigen) zu zeigen, egal wieviele es da gibt. Nun kenne ich mich leider nicht mit der Api aus. Deshalb meine Frage, gibt es einen API Call mit dem ich eine Liste von Mapperpositionen innerhalb einer Bounding Box abrufen kann? Wäre mir neu. Habe nur vor langer Zeit mal gesucht, wie das mit den nearby usern umgesetzt ist und bin hier fündig geworden: http://trac.openstreetmap.org/browser/sites/rails_port/app/models/user.rb?rev=3296 Vllt. hilft das irgendwie. Im Worldfile sind diese Daten ja nicht drin. Wenn ja würde ich nämlich einfach selber mal eine solche Slippymap bauen. Das wäre super. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
John07 o...@jonas-krueckel.de wrote: Wäre mir neu. Habe nur vor langer Zeit mal gesucht, wie das mit den nearby usern umgesetzt ist und bin hier fündig geworden: http://trac.openstreetmap.org/browser/sites/rails_port/app/models/user.rb?rev=3296 Vllt. hilft das irgendwie. Hm, wenn ich das richtig interpretiere müsste man auf Basis dieses Scriptes ein zusätzliches script bauen, das alle User innerhalb einer angegebenen Bounding Box rausfischt, denn mit obigen script kann man nur nach Benutzern im Umkreis eines anderen Benutzers suchen :( Ich kann aber leider kein Ruby. Gruss Sven -- Those who do not understand Unix are condemned to reinvent it, poorly (Henry Spencer) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] mapping quality, kleiner renderer und perl modul veröffentlicht
Hallo, Gary68 wrote: habe ein weiteres perl modul geschrieben, diesmal für die grafikausgabe von osm daten. mit dem modul osm.pm ist es dann ganz einfach, simple, aber benutzerspezifische karten zu zeichnen. Ist ja ganz beachtlich, was Du da inzwischen fuer ein Perl-Arsenal zusammengebastelt hast ;-) Eventuell lohnt es sich, Deine Perl-Module mit den existierenden unter svn.openstreetmap.org:/applications/utils/perl_lib/Geo/OSM zusammenzubringen? Vieles von deinem osm.pm überschneidet sich vermutlich mit dem, was schon da ist, aber eine Rendering-Engine wie das osmgraph.pm gibt es da noch nicht. Wenn Du osmgraph.pm mal ins SVN tust, baue ich Support fuer richtige Projektion ein ;-) 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] Slippymap mit Position von Mappern?
Hallo. Am Samstag, 3. Januar 2009 schrieb Sven Geggus: Hm, wenn ich das richtig interpretiere müsste man auf Basis dieses Scriptes ein zusätzliches script bauen, das alle User innerhalb einer angegebenen Bounding Box rausfischt, denn mit obigen script kann man nur nach Benutzern im Umkreis eines anderen Benutzers suchen :( Ich versteh das eher so, dass das Script direkt auf die Datenbank zugreift (ActiveRecord). Daher bringt dir das Script im ersten Moment mal gar nichts, da du von außen gar nicht auf die Datenbank zugreifen kannst. Davon ab: Ich glaube, dass viele User ihren Standort unter der Prämisse eingetragen haben dass nur andere Mapper in ihrer Umgebung dies sehen können. Du könntest einen datenschutztechnischen aufschrei der Community provozieren wenn du so ne Karte mit allen Mappern machst. Unabhängig davon, dass das jetzt auch schon geht, wenn auch umständlicher. Gruß, Bernd -- Erfahrung heisst garnichts. Man kann eine Sache auch 35 Jahre lang schlecht machen. - Kurt Tucholsky (dt. Schriftsteller) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Bernd Wurst schrieb: Davon ab: Ich glaube, dass viele User ihren Standort unter der Prämisse eingetragen haben dass nur andere Mapper in ihrer Umgebung dies sehen können. Du könntest einen datenschutztechnischen aufschrei der Community provozieren wenn du so ne Karte mit allen Mappern machst. Unabhängig davon, dass das jetzt auch schon geht, wenn auch umständlicher. Also wer sich hier anmeldet und aktiv Tracks hochlädt, hat seine Ansprüche an den Datenschutz schon gesenkt. Ich brauch doch nur anschauen, von wo die Tracks von einem User sind, und schon kann ich abschätzen, in welcher Region er lebt. Und ich sag mal so, wer hier die exakten Koordinaten von seiner Wohnung angibt... Wenn es eine solche Karte gibt, und alle User darüber informiert sind, dann können diejenigen die bedenken haben, ihre Koordinaten immer noch um ein paar (Kilo-)Meter verschieben. So findet man immer noch, wie die Mapper in einer Region verteilt sind und der Datenschutz passt auch. Und wer (zumindest in D) eine Homepage betreibt, dessen Adresse ist sowieso jedem zugänglich. Frohes Neues! signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Hallo, Bernd Wurst wrote: Davon ab: Ich glaube, dass viele User ihren Standort unter der Prämisse eingetragen haben dass nur andere Mapper in ihrer Umgebung dies sehen können. Ich würd's drauf ankommen lassen. Sven, das mit dem ich kann kein Ruby ist ne Ausrede, du weisst ebensogut wie ich, dass Du mit ein bisschen copy+paste+gutem Willen problemlos einen API-Call einbauen koenntest, der das Gewuenschte liefert, auch ohne Ruby zu koennen ;-) Allerdings: Die Daten, die uns wirklich interessieren, bekommen wir doch im Planet File bzw. den diffs: Da steht drin, welche User in welcher Intensität an welchen Orten mappen. Wenn jemand jetzt als Heimat-Location Berlin eingetragen hat, aber massiv in Muenchen mappt, dann ist es doch fuer alle denkbaren Anwendungen voellig schnurz, dass seine Heimat-Location in Berlin ist. Man muesste also nur die Diffs regelmaessig auswerten und haette die Information, die einen interessiert. Da gab es mal dieses OSM Aware, das so etwas ähnliches machte: http://code.google.com/p/osmlab/ - oder in gewisser Weise auch der OSM Mapper von ITO. Oder halt selber basteln. 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] Slippymap mit Position von Mappern?
Hallo, Frederik Ramm wrote: Da gab es mal dieses OSM Aware, das so etwas ähnliches machte: http://code.google.com/p/osmlab/ - oder in gewisser Weise auch der OSM Mapper von ITO. Oder halt selber basteln. Bitte keine Witze über die Häufigkeit, in der ich mir in der letzten Zeit selbst antworte ;-) Aber hier hab ich gerade auf der Userpage von Gary68 gesehen, dass er so ein Programm gebastelt hat, das aus den User-Id-Daten im Planet-File eine Karte mit Kosmos erzeugt (Screenshot ganz am Ende der Seite): http://wiki.openstreetmap.org/wiki/User:Gary68 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] Slippymap mit Position von Mappern?
Hallo. Am Samstag, 3. Januar 2009 schrieb Tobias Hägele: Also wer [...] aktiv Tracks hochlädt [...]. [... wenn ...] alle User darüber informiert sind Ich finde deine Annahmen etwas willkürlich und falsch. nicht jeder USer läd GPX-Tracks hoch und wie du alle User über sowas informieren willst, ist mir unklar. Meine Profilseite ruf ich z.B. nicht wirklich oft auf. Ich selbst hab kein Problem mit dem Vorhaben. Aber als das letzte mal irgend was in dieser Richtung vorgeschlagen wurde, gab es da böses Blut. Gruß, Bernd -- [Homer Simpson ist Kandidat für den Posten des Müllbeseitigungsreferenten] Carl: Homer ist ein großartiger Sicherheitsinspektor, aber meinen Müll würde ich ihm nicht anvertrauen! signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Modifikation der surveyor.xml des surveyor plugin
Hallo, ich möchte die surveyor.xml meinen Bedürfnissen anpassen. 1. Kann die Wartezeit von 4 sec nach Eingabe verkürzt werden? 2. Wie kann ich eigene Icons bzw. die aus JOSM einbinden? 3. Habe die Funktion toggle noch nicht richtig einbinden können. 4. Die Tastatur meines Notebook hat ein zuätzlichen Ziffernblock. Diese Tasten haben bei der Benutzung der der Beispiels-surveyor-Datei keine Funktion. Was ist zu tun, um diese Tasten bzw. ein separates Keypad (Ziffern) nutzen zu können? Benutze JOSM mit Vista MfG Dieter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Kreisgrenzen im OSM Inspector
Der Kreisgrenzen-View im OSM Inspector zeigt jetzt auch die alten Grenzen an, die vor dem Import drin waren. Sie werden als violette Linie mit X-en drin angezeigt. http://tools.geofabrik.de/osmi/?view=kreisgrenzen Nach dem Schluckauf zum Jahreswechsel, weil der Server ausgefallen war, der die Datenbankauszüge bereit stellt, sind die Daten im Inspector jetzt wieder einmal täglich da. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
John07 schrieb: Und eigene Koordinaten verschieben ist auch keine tolle Lösung. Das ließe sich aber mit einem dafür dedizierten User gut scripten, der dann wöchentlich einmal über 357.000 Quadratkilometer huscht und hofft, dass nirgends die Mapperdichte so hoch ist, dass jemand durch's Raster fällt. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Frederik Ramm schrieb: Aber hier hab ich gerade auf der Userpage von Gary68 gesehen, dass er so ein Programm gebastelt hat, das aus den User-Id-Daten im Planet-File eine Karte mit Kosmos erzeugt (Screenshot ganz am Ende der Seite): http://wiki.openstreetmap.org/wiki/User:Gary68 Sehr schön. Dieses CenterUserActivity.pl wird nur dann sinnvolle Ergebnisse liefern wenn der User im geschlossenen Polygon mappt. Wenn ich z.B. zu gleichen Teilen in Frankfurt (Main) und Düsseldorf mappe, dann wird meine CenterActivity vermutlich irgendwo bei Waldbröl im Oberbergischen liegen. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Hallo Ingrid, Wenn ich z.B. zu gleichen Teilen in Frankfurt (Main) und Düsseldorf mappe, dann wird meine CenterActivity vermutlich irgendwo bei Waldbröl im Oberbergischen liegen. Nur zur Klarstellung: Ohne die Leistung der dort aktiven Mapper schmälern zu wollen, aber dort war ich bislang noch nie. http://www.openstreetmap.org/?lat=50.87448lon=7.62386zoom=15layers=0B00FTF Aber wenn mir jemand jemand aus dem planetfile ein Aktivitätszentrum ausrechnen mag, dann werde ich da gerne mal einen Mapping-Ausflug unternehmen ;-) -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Track-Anonymisierer gesucht (was: Slippymap mit Position von Mappern?)
Bernd Wurst schrieb: Also wer [...] aktiv Tracks hochlädt [...]. Ich finde deine Annahmen etwas willkürlich und falsch. Ich wünsche mir ein Desktop-Programm zum Anonymisieren von von GPX-Dateien. Das ganze sollte a) Datum und Uhrzeit des Tracks anonymisieren b) Geschwindigkeiten anonymisieren (random offset, Jitter/Skew), also massiv an den Timestamps der Punkte drehen c) Tracks ggf. neu teilen und umordnen, auch über Dateigrenzen hinweg. d) so schonend wie möglich vorgehen, um z.B. bei der SpeedVisualisierung im Josm keinen völlig Humbug zu verzapfen. (Werte sollten also in +/-30%-Bereich bleiben) e) Auf Windows-PCs laufen f) mit wenig Installation auskommen (bitte kein Active Perl ... ) g) Laienkompatibel sein (Alle Tracks in einem Verzeichnis, Beim zweiten Aufruf im gleichen Verzeichnis, bereits behandelte Tracks verschonen h) dem Anwender einen vertrauenserweckenden Eindruck vermitteln. Bevor jetzt jemand fragt: Wozu, Du lädst doch auch so jede Menge Tracks hoch ( http://www.openstreetmap.org/user/-jha-/traces ) Es könnten noch wesentlich mehr sein! Wenn ich guten gewissens Kollegen überzeugen könnte, auf ihren Dienstfahrten und Dienstreisen ins Ausland einen Tracklogger mitzunehmen oder einfach in ihrem Tomtom bzw GoPal das Tracklogging zu aktivieren und mir die Tracks zu geben. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Nasse Grenzen
Hallo, wenn ich mir dieses Bild ansehe http://tools.geofabrik.de/osmi/?view=boundarieslon=5.14122lat=54.78662zoom=6opacity=1.00overlays=boundary_relations_3,boundary_relations_4,boundary_relations_5,boundary_ways_2 (der OSM-Inspector ist ein wahrhaft gutes Tool!) und dann das lese http://de.wikipedia.org/wiki/Hoheitsgew%C3%A4sser#12-Meilen-Zone und auch noch diesen Link auf der Seite verfolge http://www.bfn.de/marinehabitate/de/downloads/erlaeuterungstexte/Karte1_Schutzgebiete_mit_Koordinaten.pdf , dann bin ich überzeugt, dass wir was falsch machen. Bundesgrenze und Ländergrenze gehören weg von der Küstenlinie und raus auf die (zu schätzende) Grenze der 12-Meilen-Zone. Also auch das im Augenblick nicht gerenderte Außen-Grenz-Geraffel in der Nordsee sollte entsorgt werden. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreisgrenzen im OSM Inspector
Lars Francke schrieb: Der Kreisgrenzen-View im OSM Inspector zeigt jetzt auch die alten Grenzen an, die vor dem Import drin waren. Sie werden als violette Linie mit X-en drin angezeigt. Großartig! Vielen Dank! Mal gucken was man so an alten Grenzen aufräumen kann. Jo, aber bitte nicht gerade die Grenzen in Nord- und Ostsee. Die könnte man noch mal brauchen! Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Bernd Wurst be...@bwurst.org wrote: Davon ab: Ich glaube, dass viele User ihren Standort unter der Prämisse eingetragen haben dass nur andere Mapper in ihrer Umgebung dies sehen können. Was außer ihrem Standort unterscheidet die Mapper in meiner Umgebung von denen auf der anderen Seite des Globus? Wer seine Position nicht preisgeben möchte kann dies tun, alles andere ist security by obscurity. Sven -- In my opinion MS is a lot better at making money than it is at making good operating systems (Linus Torvalds, August 1997) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Moin, wenn ich mir dieses Bild ansehe http://tools.geofabrik.de/osmi/?view=boundarieslon=5.14122lat=54.78662zoom=6opacity=1.00overlays=boundary_relations_3,boundary_relations_4,boundary_relations_5,boundary_ways_2 (der OSM-Inspector ist ein wahrhaft gutes Tool!) und dann das lese http://de.wikipedia.org/wiki/Hoheitsgew%C3%A4sser#12-Meilen-Zone und auch noch diesen Link auf der Seite verfolge http://www.bfn.de/marinehabitate/de/downloads/erlaeuterungstexte/Karte1_Schutzgebiete_mit_Koordinaten.pdf , dann bin ich überzeugt, dass wir was falsch machen. Bundesgrenze und Ländergrenze gehören weg von der Küstenlinie und raus auf die (zu schätzende) Grenze der 12-Meilen-Zone. da stimme ich vollkommen zuaberdas ist sie doch schon?! Also auch das im Augenblick nicht gerenderte Außen-Grenz-Geraffel in der Nordsee sollte entsorgt werden. Magst Du das genauer erklären? Ich verstehe nicht ganz was Du meinst (Außen-Grenz-Geraffel). Seit dem INFAS-Import gibt es mindestens zwei Grenzrelationen für Deutschland. Die alte hat Ihre Grenze auf dem Wasser und schließt alle Inseln ein. Es sind sicher keine 12sm von den Inseln entfernt, eher vom Festland, aber besser als die neue Grenze allemal, die schoen entlang der Küstenlinie geht (zumindest zum Teil). Und diese seeseitige Grenze sieht auch ganz grob ähnlich aus wie die 12sm Grenze aus Deinem verlinkten PDF. Frederik hat im INFAS-Kreisgrenzen-Thread folgende Meinung vertreten: 'fuer, gelinde gesagt, Bloedsinn. Wenn jemand mir sagt exportiere mir doch mal den Umriss von Schleswig-Holstein, dann wird der mir einen Vogel zeigen, wenn ich ihm irgendwas liefere, was 12 Meilen auf der See liegt oder so.' Daher habe ich die neuen Relationen und Grenzen nicht angefasst sondern die alten Relationen und Grenzen reaktiviert. Solange es also diese zwei Meinungen gibt wird es für Deutschland, Schleswig-Holstein, MV, Niedersachsen und die Kreise in den Ländern jeweils zwei Relationen geben. Einmal mit Seegrenzen und einmal mit Küstenlinie als Grenze. Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Frederik Ramm frede...@remote.org wrote: Sven, das mit dem ich kann kein Ruby ist ne Ausrede, du weisst ebensogut wie ich, dass Du mit ein bisschen copy+paste+gutem Willen problemlos einen API-Call einbauen koenntest, der das Gewuenschte liefert, auch ohne Ruby zu koennen ;-) Das kann ich schon deshalb nicht weil ich keinerlei Zugang zu einem Server habe auf dem man sowas testen könnte. Ist es aufwendig nen API-Server auf der eigenen Kiste aufzusetzen? Sven -- In my opinion MS is a lot better at making money than it is at making good operating systems (Linus Torvalds, August 1997) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Johann H. Addicks wrote: Bernd Wurst schrieb: Also wer [...] aktiv Tracks hochlädt [...]. Ich finde deine Annahmen etwas willkürlich und falsch. Ich wünsche mir ein Desktop-Programm zum Anonymisieren von von GPX-Dateien. Das ganze sollte a) Datum und Uhrzeit des Tracks anonymisieren [...] Hi, warum dann einen Teil der Anonymisierung nicht gleich beim Hochladen in der API machen? Interessieren im zentralen Repo noch z.B. Timestamps (wer war _wann_ dort)? PS: So ganz überzeugt bin ich aber noch nicht das die Tracks zentral hochladen überhaupt sinnvoll ist - lade also entsprechend keine hoch, wie sicher einige andere Leute ebenfalls. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht (was: Slippymap mit Position von Mappern?)
GPSBabel kann einiges davon. Es gibt Filter (http://www.gpsbabel.org/htmldoc-1.3.6/filter_track.html) a) Datum und Uhrzeit des Tracks anonymisieren die Daten und Uhrzeiten koennen um beliebige Offsets verschoben werden. Damit würde die Geschwindigkeit und alles allerdings vollkommen erhalten bleiben. c) Tracks ggf. neu teilen und umordnen, auch über Dateigrenzen hinweg. d) so schonend wie möglich vorgehen, um z.B. bei der SpeedVisualisierung im Josm keinen völlig Humbug zu verzapfen. (Werte sollten also in +/-30%-Bereich bleiben) e) Auf Windows-PCs laufen f) mit wenig Installation auskommen (bitte kein Active Perl ... ) g) Laienkompatibel sein (Alle Tracks in einem Verzeichnis, Beim zweiten Aufruf im gleichen Verzeichnis, bereits behandelte Tracks verschonen c) geht glaube ich auch aber ich habe nicht nachgeguckt. d) auf jeden Fall - s.o. e) und f) treffen auch zu g) ich weiß aus dem kopf nicht ob es ganze verzeichnisse bearbeiten kann... Viellleicht hilft es Dir ja schon. Online geht das ganze, glaube ich(!), auch über http://www.gpsvisualizer.com/ - aber das habe ich noch nie genutzt. Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Hallo, Lars Francke wrote: GPSBabel kann einiges davon. Es gibt Filter (http://www.gpsbabel.org/htmldoc-1.3.6/filter_track.html) a) Datum und Uhrzeit des Tracks anonymisieren die Daten und Uhrzeiten koennen um beliebige Offsets verschoben werden. Damit würde die Geschwindigkeit und alles allerdings vollkommen erhalten bleiben. Es ist nicht unwahrscheinlich, dass irgendwann irgendwer mit irgendeinem Verfahren aus den hochgeladenen Tracks automatische Verkehrsflussinformationen destillieren wird. Wenn ein Track, der freitags im Sommer zwischen 14 und 16 Uhr aufgezeichnet wurde, dann per Skript an einen Sonntag im Winter, 7.00 bis 9:00 gelegt wird, duerfte das den Wert der Analysen deutlich reduzieren. Wer solche Verfaelschungen vornimmt, sollte also zumindest den Track eindeutig kennzeichnen (Caution, falsified timestamps oder sowas), damit ein automatischer Auswerter diese Tracks ignorieren kann. Eine Moeglichkeit dafuer ist auch, die Timestamps auf einen Zeitpunkt zu legen, an dem es noch kein GPS gab. 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] Track-Anonymisierer gesucht
Stefan Neufeind schrieb: warum dann einen Teil der Anonymisierung nicht gleich beim Hochladen in der API machen? Interessieren im zentralen Repo noch z.B. Timestamps (wer war _wann_ dort)? Weil die Leute dann den Krempel selbst hochladen und bei der Anonymisierung Dritten mehr vertrauen müssten. Ich hätte gerne, dass die Kollegen ihre Tracks anonymisieren könnten bevor sie mir die GPX-Dateien geben. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Lars Francke schrieb: Viellleicht hilft es Dir ja schon. Nein, es hilft mir nicht. GPS-Babel kenne ich. Und so sehr ich die Leistung der Programmierer dort schätze, allein die Tatsache, dass dermaßen Posix-rigide auftritt (selbst die Gui), disqualifiziert es für Laien. Selbst wenn es die notwendigen Funktionen hätte, es braucht eben ein komplettes Environment (Shell/Scriptsprache drumherum), um komplexere Aufgaben zu erledigen. Und dann ist der Krampf mit dem Polygonfilter nur auf Wegepunkte, weshalb man die Tracks x-mal zwischen Track, Wegepunktmenge mit Timestamp und zurück in Tracks konvertieren muss. Und wenn dann irgendwo (sei es wg. Bug im Receiver) einen falschen Timestamp im Track gibt, dann zerreisst das GPS-Babel und Handarbeit am GPX-Track ist angesagt. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Hallo, Lars Francke schrieb: Bundesgrenze und Ländergrenze gehören weg von der Küstenlinie und raus auf die (zu schätzende) Grenze der 12-Meilen-Zone. da stimme ich vollkommen zuaberdas ist sie doch schon?! Nein, sind sie nicht, wie du selber auch feststellst. Also auch das im Augenblick nicht gerenderte Außen-Grenz-Geraffel in der Nordsee sollte entsorgt werden. Magst Du das genauer erklären? Ich verstehe nicht ganz was Du meinst (Außen-Grenz-Geraffel). Ich meine die Außengrenzen im Wasser, die mit keiner geltenden Hoheitsgrenze etwas zu tun haben, nämlich siehe unten *) Seit dem INFAS-Import gibt es mindestens zwei Grenzrelationen für Deutschland. Die alte hat Ihre Grenze auf dem Wasser und schließt alle Inseln ein. *) Genau die meine ich. Es sind sicher keine 12sm von den Inseln entfernt, eher vom Festland, aber besser als die neue Grenze allemal, die schoen entlang der Küstenlinie geht (zumindest zum Teil). Und diese seeseitige Grenze sieht auch ganz grob ähnlich aus wie die 12sm Grenze aus Deinem verlinkten PDF. Das ist eine Frage des Maßstabs. Zoome mal in die Karte rein und vergleiche Im OSM-Inspector, sie die Deutsche bucht aussieht im Vergleich zur dänischen oder britischen Küste. Frederik hat im INFAS-Kreisgrenzen-Thread folgende Meinung vertreten: 'fuer, gelinde gesagt, Bloedsinn. Wenn jemand mir sagt exportiere mir doch mal den Umriss von Schleswig-Holstein, dann wird der mir einen Vogel zeigen, wenn ich ihm irgendwas liefere, was 12 Meilen auf der See liegt oder so.' Das kann ja seine Meinung ruhig sein, aber es gibt auch andere Meinungen. Es wurde ihm ja auch mit einem Hinweis auf den möglichen Unterschied zwischen Umriss und Hoheitsgrenzen geantwortet. Topo-, Geo- und andere Graphen haben die Aufgabe, die Wirklichkeit zu beschreiben - erfinden sollen sie sie nicht. Und die Wirklichkeit ist hier: Das Hoheitsgebiet der Bundesrepublik Deutschland umfasst die 12-Meilen-Zone. Daher habe ich die neuen Relationen und Grenzen nicht angefasst sondern die alten Relationen und Grenzen reaktiviert. Solange es also diese zwei Meinungen gibt wird es für Deutschland, Schleswig-Holstein, MV, Niedersachsen und die Kreise in den Ländern jeweils zwei Relationen geben. Einmal mit Seegrenzen und einmal mit Küstenlinie als Grenze. Prima, dann haben wir mit Sicherheit ein falsches Ergebnis. Ich war auch zunächst auf diesem leicht resignativen Dampfer - aber unzufrieden genug, um weiter nach dem richtigen Weg zu suchen. Mir wäre es lieber, wenn wir die RICHTIGE Grenze zeichnen - nicht das Ergebnis einer Diskussion (vielleicht sogar mit Komprmiss), sondern auf der Basis von Wissen. Was wäre wenn nun jemand (über den Verein?) die Bundesregierung oder das Bundesverwaltungsamt fragen würde, wo die Grenzen liegen? Ich wäre auch bereit, im OSM mit einer 12 Seemeilen breiten Rolle an der Basislinie entlang zu rollen, um mal eine Linie dort zu sehen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
Frederik Granna schrieb: Mal eine Frage: In Hannover laufen die Straßenbahnen auch als U-Bahnen (in der Kernstadt 90% unterirdisch) Wie leg ich sowas an? Oder ist das nicht relevant weil die Ways ja unterirdisch angelegt sind?! Die Verkehrsbetriebe von Hannover bezeichnen das ganze (zumindest auf ihrer Website) als Stadtbahn. Das Wiki empfiehlt in diesem Fall light_rail http://wiki.openstreetmap.org/wiki/DE:Howto_Map_A#Gleise Siehe auch http://de.wikipedia.org/wiki/Stra%C3%9Fenbahn Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] INFAS Kreisgrenzen
Am 02.01.09 schrieb kannix: (potentieller) Umfang und (hoffentlich) Uebersichtlichkeit. Was von beiden moechtest Du denn? Ich glaube, es gibt ziemlich viele Stadtteile, Gemeinden und Staedte in Deutschland. Ich haette gerne eine Liste mit allen Relationen (und deren Status). Findet man die nicht relativ gut über den Datalayer oder den Editor Deiner Wahl? Viele Gruesse, Fabian.___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Frederik Ramm schrieb: damit ein automatischer Auswerter diese Tracks ignorieren kann. Eine Moeglichkeit dafuer ist auch, die Timestamps auf einen Zeitpunkt zu legen, an dem es noch kein GPS gab. Zumindest das Quartal sollte meiner Ansicht noch erhalten bleiben, schließlich werden wir in 10 Jahren durchaus gerne alte Tracks ausblenden wollen. Sei es, dass die Empfänger bis dahin besser geworden sind, sei es, dass irgendwelche Kreisverkehrsfanatiker (Gegener wie Befürworter) Ortseinfallstraßen bis dahin das 4. Mal umgebaut haben. Ein Tagging auf Timestamps modified within limits date of year and speed range sollte irgendwie mit hinein. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
On Sat, Jan 03, 2009 at 06:34:26PM +0100, Norbert Kück wrote: wenn ich mir dieses Bild ansehe http://tools.geofabrik.de/osmi/?view=boundarieslon=5.14122lat=54.78662zoom=6opacity=1.00overlays=boundary_relations_3,boundary_relations_4,boundary_relations_5,boundary_ways_2 (der OSM-Inspector ist ein wahrhaft gutes Tool!) und dann das lese http://de.wikipedia.org/wiki/Hoheitsgew%C3%A4sser#12-Meilen-Zone und auch noch diesen Link auf der Seite verfolge http://www.bfn.de/marinehabitate/de/downloads/erlaeuterungstexte/Karte1_Schutzgebiete_mit_Koordinaten.pdf , dann bin ich überzeugt, dass wir was falsch machen. Bundesgrenze und Ländergrenze gehören weg von der Küstenlinie und raus auf die (zu schätzende) Grenze der 12-Meilen-Zone. Also auch das im Augenblick nicht gerenderte Außen-Grenz-Geraffel in der Nordsee sollte entsorgt werden. Also diese Diskussion hatten wir hier jetzt schon ein paarmal und auf talk gabs die auch schon ein paar mal. Und es wird immer viel geredet, aber Klarheit gibts keine. Es ist wohl klar, dass sowohl die Grenzführung an der Küstenlinie entlang als auch die, die aufs Wasser raus geht, beide sinnvoll sind und für verschiedene Anwendungen nützlich. D.h. es sollte auch beide Möglichkeiten geben, das zu erfassen bzw. die entsprechenden Daten rauszuziehen. Dafür sehe ich nur die Möglichkeit eine weitere Relation einzuführen. Dann haben wir eine, die die Küstenlinien benutzt und eine, die die Grenzen auf dem Wasser benutzt. Die Grenzen auf dem Land werden von beiden benutzt. Bliebe die Frage, wie man sie nennt, bzw. tagged. Vorschläge? Andere Ideen? Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Moin, Dafür sehe ich nur die Möglichkeit eine weitere Relation einzuführen. Dann haben wir eine, die die Küstenlinien benutzt und eine, die die Grenzen auf dem Wasser benutzt. Die Grenzen auf dem Land werden von beiden benutzt. da wir irgendwie aneinander vorbeireden warte ich einfach ab was Norbert tut. Ich glaube wir wollen das gleich erreichen aber Deine Ausführungen verstehe ich nicht. Und es gibt schon zwei Relationen: Mit Seegrenzen (sicher nicht korrekt aber die kann man ja verschieben, werden auch gerendert, warum Du die loeschen willst weiß ich nicht): http://www.openstreetmap.org/browse/relation/51477 Mit Grenze an der Küstenlinie: http://www.openstreetmap.org/browse/relation/62781 Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
Dimitri Junker schrieb: Und wo steht das? Nirgendwo, aber es gibt Indizien. 1. Ist alles in OSM symetrisch es sei denn es ist speziell markiert. Jedem Mapper war bisher klar, daß wenn er cycleway=track setzt ein Router diese Info für beide oder für keine Richtung nutzen kann, es also besser ist bei nur einseitigem Fahrradweg dies anders zu mappen (Extraweg) da es sonst wertlos ist. Da es für Einbahnstraßen extra die opposite-Tags gibt folgt, daß ohne dort von einem Fahrradweg ausgegangen werden kann der in gleicher Fahrtrichtung benutzbar ist wie die Straße. Das bedeutet zwar alles nicht, daß irgendwer das so definiert hat, aber da sich viele Mapper wohl ähnliche Gedanken gemacht haben werden es viele wohl so genutzt haben als ob es so definiert wäre. Ja.. ;) So wie häufig bei OSM (gerade bei 'älteren' Tags) ist es hauptsächlich Interpretationssache. Jemand anders kann das vielleicht wieder komplett anders sehen. Jedes Schema hat seine Vor- und Nachteile. Hauptsache wir entscheiden uns mal für eins das funktioniert. Ich würde bei Deinem Proposal zuerst einmal das right/left/both zurückstellen. Wie soll ich das machen? Das Ganze basiert doch darauf. Wenn bei meinem Proposal was rauskommt kannst Du es dann daran anpassen. Das würde die Diskussion zu Deinem Proposal auf die wesentlicheren Teile beschränken, ob das right/left vorne oder hinten steht ist Dir wahrscheinlich relativ egal wenn es denn funktioniert. Ich hätte es schon gerne so wie es im Moment in meinem Proposal steht (deshalb stehts ja auch so da), wenn es aber gute Argumente für ein anderes Schema gibt (also das tatsächlich BESSER nicht nur anders ist), dann kann man es natürlich ändern. Allerdings wäre die Methode mit right/left als value nicht mit meiner Alternative 1 vereinbar die Du eigentlich favorisierst. Vereinbar wäre cycleway:right=yes usw. Wenn Du wirklich das Vorhandensein und den Typ trennen willst. Hmm, um das Trennen von Vorhandensein- und Typ-Definition geht es mir weniger, eher darum dass es einfacher ist, wenn man nicht so viele mögliche und lange Hauptschlüssel hat. Zudem eine Definition (also auch Vorhandensein) mit.. cycleway:left=track ..ein bisschen ähnlich wäre wie: parking=multi-storey Statt: amenity=parking parking=multi-storey Der Vergleich hinkt ein bisschen, da 'amenity' eher eine größere Kategorie ist. Aber wenn man 'cycleway' als Kategorie ansieht und 'cycleway:left' als ein möglicher Wert davon, ist es doch wieder ähnlich. Wobei man das amenity=parking vermutlich dafür angibt, um zunächst mal die Informationen 'amenity' und 'parking' zu haben, ohne sich um die Details kümmern zu müssen. Und man kann eben alle 'amenity' auslesen, ohne die einzelnen Werte kennen zu müssen. Genau das mache ich auch, bloss eben auf einem viel kleineren Level. Insofern wäre es wohl eher möglich es anders zu machen, auch wenn es mir irgendwie nicht gefällt. Alternativ könnte ich auch folgendes vorschlagen: Will man verschiedene Eigenschaften (values) für beide Seiten setzen kommt das right/left/both in den Key, will man die Existens eines Keys, der also sonst mit yes gesetzt würde auf eine Seite beschränken wird statt yes right oder left benutzt. Sag mir Bescheid ob ich dies zusätzlich aufnehmen soll. Schließlich soll mein Proposal kein Widerspruch zu Deinem sein, sondern den right/left Anteil nur verallgemeinern. Du meinst also genauso wie in meinem Proposal? Bei Features die als Wert definiert werden, könnte es aber problematisch werden: highway=bus_stop Müsste dann entweder heißen: bus_stop=right Oder: highway:right=bus_stop Vielleicht ist es garnicht so gut möglich eine allgemeine Methode zu definieren, da es allgemein bei den Tags keine festgelegte Systematik gibt, sondern eben alles so gemacht wird wie es gerade passt. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relation:Traffic enforcement Feature Proposal - Voting - Enforcement
Hello there, the voting is now open: http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:enforcement Regards Lulu-Ann -- Sensationsangebot verlängert: GMX FreeDSL - Telefonanschluss + DSL für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K1308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Ein .gpx-File enthält üblicherweise die Koordinaten (+Höhe) und die Zeit. Meine Idee wäre es, den ersten Trackpoint zufällig auszuwählen und die restlichen dann geordnet anhängen, wahlweise wird auch die Richtung des Tracks gedreht. Dann wird jede Zeit auf den Ersten des Quartals gesetzt, also bspw. 01.03.2009 00:00 UTC, bei jedem Trackpoint erhöht sich die Zeit um eine Sekunde. Damit sollten keine persönlichen Daten zurückbleiben. Das ganze könnte als Skript oder zusätzlich als Webinterface angeboten werden (wobei dann wieder die Frage aufkommt: Wie weit vertraue ich der Website/Verbindung) Gruß Patrick -- E-Mail: patrick.kol...@web.de Jabber: patrick.kol...@jabbermx.org GnuPG: 0xB8C38BA3 signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
On Sat, Jan 03, 2009 at 09:09:52PM +0100, Norbert Kück wrote: Dafür sehe ich nur die Möglichkeit eine weitere Relation einzuführen. Dann haben wir eine, die die Küstenlinien benutzt und eine, die die Grenzen auf dem Wasser benutzt. Die Grenzen auf dem Land werden von beiden benutzt. So isses! Relation Hoheitsgebiet enthält die realen Grenzen. Relation Landfläche enthält die nicht die See berührenden Grenzen und die diese Grenzen verbindenden Küstenlinien (bzw. Hilfslinien, die Flüsse mit Tideeinfluss abtrennen). Diese Küstenlinien könnten mit einem boundary=yes oder boundary=auxiliary (oder sonst was Klügeres) zusätzlich gekennzeichnet werden. Die ways müssen ja nicht irgendwie zusätzlich getagged werden. Es reicht, wenn die passende Relation da ist. Ich schlage also vor: Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. Relation B: boundary=land_area type=multipolygon Enthält auf dem Lande die ways, die auch in Relation A drin, wo die aufs Wasser gehen dann aber die ways der Küstenlinien (also natural=coastline). Inseln erscheinen also als Exklaven. Das ganze gibt es jeweils für alle admin_level. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
On Sat, Jan 03, 2009 at 08:22:06PM +0100, Lars Francke wrote: Dafür sehe ich nur die Möglichkeit eine weitere Relation einzuführen. Dann haben wir eine, die die Küstenlinien benutzt und eine, die die Grenzen auf dem Wasser benutzt. Die Grenzen auf dem Land werden von beiden benutzt. da wir irgendwie aneinander vorbeireden warte ich einfach ab was Norbert tut. Ich glaube wir wollen das gleich erreichen aber Deine Ausführungen verstehe ich nicht. Und es gibt schon zwei Relationen: Mit Seegrenzen (sicher nicht korrekt aber die kann man ja verschieben, werden auch gerendert, warum Du die loeschen willst weiß ich nicht): Wer redet denn davon, dass ich die löschen will. http://www.openstreetmap.org/browse/relation/51477 Mit Grenze an der Küstenlinie: http://www.openstreetmap.org/browse/relation/62781 Ja, es gibt derzeit zwei. Aber die haben beide die gleichen Tags (boundary = administrative) und sind daher nicht unterscheidbar. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Hi, Patrick Kolesa wrote: Dann wird jede Zeit auf den Ersten des Quartals gesetzt, also bspw. 01.03.2009 00:00 UTC, bei jedem Trackpoint erhöht sich die Zeit um eine Sekunde. Eine automatische Ermittlung der Geschwindigkeiten auf verschiedenen Strassen oder eine Heuristik, die bestimmt, ob jemand zu Fuss, mit dem Rad oder mit dem Auto unterwegs war, sind damit nicht mehr möglich. Wie schon gesagt, solche Tracks sollten auf jeden Fall als verfälscht gekennzeichnet werden, wenn man sie hochlädt. Persönlich bin ich der Ansicht, dass man, wenn man derartige Bedenken hat, lieber ganz auf ein Hochladen der Tracks verzichten sollte. Zwar sind GPS-Daten in unserer Datenbank manchmal hilfreich, aber wenn ich annehmen muss, dass alles, was ich da rausziehe, mit sehr viel Vorsicht zu geniessen ist, weil es u.U. durch zig verschiedene Skripts verfremdet und verwurstet wurde (ja ich weiss, ihr wollt die Koordinaten nicht anpassen, aber wer sagt mir denn, ob irgendjemand nicht beim gpsbabel doch mal irgendwelche witzigen Switches angibt...), dann sinkt der Wert so weit, dass man es auch ganz bleiben lassen kann. Ich will den Schutz der Persoenlichkeitssphaere gar nicht kleinreden, das ist ein legitimes Ansinnen, und es ist gut, sich darueber Gedanken zu machen, aber ich finde, man sollte sich am Ende entweder fuer das Hochladen der unverfaelschten Tracks oder fuer das Nicht-Hochladen entscheiden und dazu stehen. 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] Nasse Grenzen
Hallo, Jochen Topf wrote: Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. [...] Das ganze gibt es jeweils für alle admin_level. Bis auf welchen Adminlevel sind denn diese 12 Meilen runtergebrochen? Jemand sagte, alles gehoert mindestens zu einem Bundesland. Was ist mit Kreisen - wenn ein Kreis an der Küste liegt, sind die 12 Meilen vor der Küste dann auch Kreisgebiet (und wo verläuft auf der See die Grenze zwischen benachbarten Küstenkreisen?), oder handelt es sich um kreisloses See-Hoheitsgebiet des Bundeslandes X? Und ebenso für Städte... 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] Slippymap mit Position von Mappern?
Bernd Wurst schrieb: Tobias Hägele: Also wer [...] aktiv Tracks hochlädt [...]. [... wenn ...] alle User darüber informiert sind Ich finde deine Annahmen etwas willkürlich und falsch. Aber genauso willkürlich wie meine Annahmen sind, genauso willkürlich können unsere Daten hier auch verwendet werden. Von daher nicht unbedingt falsch. Fakt ist auf jeden Fall: Wer die Daten will, hat genug Mittel und Wege, um sie zu erhalten. nicht jeder User läd GPX-Tracks hoch und wie du alle User über sowas informieren willst, ist mir unklar. Zu den Tracks brauch ich nichts mehr sagen, da wurden bisher genug Möglichkeiten genannt. Ich geh davon aus, dass es für einen bestimmten Nutzerkreis möglich ist, Mails an alle Accounts zu senden. Das wär dann die einfachste Möglichkeit. Meine Profilseite ruf ich z.B. nicht wirklich oft auf. Ich auch nicht. Aber das ist kein Argument. Ich selbst hab kein Problem mit dem Vorhaben. Ich auch nicht, ansonsten dürft ich nicht hier sein. Aber als das letzte mal irgend was in dieser Richtung vorgeschlagen wurde, gab es da böses Blut. Das kann ich im Zusammenhang so diesem Projekt nicht verstehen. Bis dann, Tobias signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Hallo, Lars Francke schrieb: da wir irgendwie aneinander vorbeireden warte ich einfach ab was Norbert tut. Ich glaube wir wollen das gleich erreichen aber Deine Ausführungen verstehe ich nicht. OK, dann schätze ich mal eine 12-Meilen-Zone da rein. Und es gibt schon zwei Relationen: Mit Seegrenzen (sicher nicht korrekt aber die kann man ja verschieben, werden auch gerendert, warum Du die loeschen willst weiß ich nicht): http://www.openstreetmap.org/browse/relation/51477 Kann ich mir jetzt nicht ansehen, OSM-API sendet Internal Server Error 500. Aber die Osmarender-Bilder werden ja geliefert. Nun, ich hätte vieleicht mehr in die Totale gehen sollen. In der Ostsee glaube ich wirklich nicht, dass man da andere Linien ziehen muss. Allerdings werden die Grenzen auch da lückenhaft gezeigt. Die Relation sollte ein geschlossenes Polygon zeigen. Ich hatte sie Situation der Nordseeküste im Blick. Und wenn ich die Grenzlinien von Borkum bis Helgoland sehe, beiß ich fast in die Tischkante. Und mit verschieben ist dort auch nichts geholfen, weil die Form eine andere ist. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Hallo, Jochen Topf schrieb: Die ways müssen ja nicht irgendwie zusätzlich getagged werden. Es reicht, wenn die passende Relation da ist. Ich schlage also vor: Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. Relation B: boundary=land_area type=multipolygon Enthält auf dem Lande die ways, die auch in Relation A drin, wo die aufs Wasser gehen dann aber die ways der Küstenlinien (also natural=coastline). Inseln erscheinen also als Exklaven. Das ganze gibt es jeweils für alle admin_level. Ja gerne - schon gekauft. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Lars Francke schrieb: GPSBabel kann einiges davon. Es gibt Filter (http://www.gpsbabel.org/htmldoc-1.3.6/filter_track.html) a) Datum und Uhrzeit des Tracks anonymisieren die Daten und Uhrzeiten koennen um beliebige Offsets verschoben werden. Damit würde die Geschwindigkeit und alles allerdings vollkommen erhalten bleiben. Also wenn es nur darum geht, um vor eventuellen Strafzetteln sicher zu sein, reicht dies vollkommen. Denn dazu muss Vater Staat nicht nur nachweisen, DASS jemand zu schnell war, sondern auch WO und WANN. Man muss natürlich nur aufpassen, dass man zum gefälschten Zeitpunkt nicht genau das selbe Vergehen am selben Ort begangen hat. Und nur, weil Person A etwas hochgeladen hat, ist noch lange nicht gesagt, dass er dort selbst war. Und dann ist da noch die Tatsache, dass die Passwörter hier in Klartext übertragen werden. Bis dann, Tobias signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Hallo, Das ganze gibt es jeweils für alle admin_level. Bis auf welchen Adminlevel sind denn diese 12 Meilen runtergebrochen? Jemand sagte, alles gehoert mindestens zu einem Bundesland. Was ist mit Kreisen - wenn ein Kreis an der Küste liegt, sind die 12 Meilen vor der Küste dann auch Kreisgebiet (und wo verläuft auf der See die Grenze zwischen benachbarten Küstenkreisen?), oder handelt es sich um kreisloses See-Hoheitsgebiet des Bundeslandes X? Und ebenso für Städte... Ja, alles gehört hoheitsrechtlich zu einem Bundesland. Das ist sicher. Wie die Länder das mit ihren eigenen Gebietskörperschaften machen, ist eine andere Frage. Das muss man klären. Deshalb äußere ich mich dazu ja viel zurückhaltender. Kommunale Aufgaben sind zudem viel eingeschränkter. Wir sollten uns an Tatsachen orientieren. Wenn die Grenzen aufs Wasser gehen, denn ist das eben so. Zumindest die abgeschafften Regierungsbezirke in Niedersachsen haben die Küstengewässer mit umfasst. Und es gibt offizielle Darstellungen http://cdl.niedersachsen.de/blob/images/C1440433_L20.gif , die zumindest die Kreisgrenzen NICHT auf der Küstenlinie laufen lassen, sondern nicht mehr darstellen, wenn sie aufs Wasser stoßen. Hier http://cdl.niedersachsen.de/blob/images/C21649088_L20.gif wird sogar gezeigt, wie die Grenzen zwischen den ostfriesischen Kreisen im Wasser verlaufen. Ich will nicht verschweigen, dass es auch Darstellungen gibt, die das Küstengewässer aussparen. Wie das einzuordnen ist?? Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
Hallo, Wie soll ich das machen? Das Ganze basiert doch darauf. ich meine daß Du Dich erstmal nicht darauf festlegst wo das right/left/both stehen soll, also einfach irgendeine Form wählen mit dem Hinweis daß Du es ggf noch anpaßt. Du meinst also genauso wie in meinem Proposal? Klar, deshalb habe ich es ja vorgeschlagen Vielleicht ist es garnicht so gut möglich eine allgemeine Methode zu definieren, da es allgemein bei den Tags keine festgelegte Systematik gibt, sondern eben alles so gemacht wird wie es gerade passt. Wenn man einerseits key:left=value und andererseits key=left als 2 Standardmethoden definiert sollte dies für die meisten Fälle reichen. Es geht bei der Standardmethode ja nur darum, daß man diese allen Editoren einmal beibringt, sie also Wege drehen können und dabei rechts/links vertauschen können, ohne das bei jedem neuen key der ein right/left nutzen soll wieder alle Editoren anpassen muß. Ist dies einmal in den Editoren eingebaut nimmt es den Gegnern von rechts/links den Wind aus den Segeln. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einigkeit bei Linienbündeldiskussion (Re: Kreuzung Radweg)
Dimitri Junker schrieb: Vielleicht ist es garnicht so gut möglich eine allgemeine Methode zu definieren, da es allgemein bei den Tags keine festgelegte Systematik gibt, sondern eben alles so gemacht wird wie es gerade passt. Wenn man einerseits key:left=value und andererseits key=left als 2 Standardmethoden definiert sollte dies für die meisten Fälle reichen. Es geht bei der Standardmethode ja nur darum, daß man diese allen Editoren einmal beibringt, sie also Wege drehen können und dabei rechts/links vertauschen können, ohne das bei jedem neuen key der ein right/left nutzen soll wieder alle Editoren anpassen muß. Ist dies einmal in den Editoren eingebaut nimmt es den Gegnern von rechts/links den Wind aus den Segeln. Wenn es dir hauptsächlich darum geht, bin ich damit einverstanden. Darauf kann man dann aufbauen. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht (was: Slippymap mit Position von Mappern?)
Hallo. Am Samstag, 3. Januar 2009 schrieb Johann H. Addicks: Ich wünsche mir ein Desktop-Programm zum Anonymisieren von von GPX-Dateien. Ich habe mir das auch schon überlegt, aber es klingt einfacher als es ist. Das ganze sollte a) Datum und Uhrzeit des Tracks anonymisieren trivial. b) Geschwindigkeiten anonymisieren (random offset, Jitter/Skew), also massiv an den Timestamps der Punkte drehen Quasi unmöglich. Die meisten logger loggen in festen Intervallen. Wenn du also noch so sehr Kopfstände mit den Timestamps machst, sieht man nachher die Punkte-Linie und wer irgendwas über dich weiß, kann recht schnell dein Logger-Intervall herausfinden. Wenn dieses auf 1 Sekunde steht (was vermutlich die meisten aktiven OSM'ler haben), ist der Abstand zweier Punkte das was du in einer Sekunde gefahren bist. Egal was die Timestamps sagen. Um das also zu anonymisieren müsste man entweder zusätzliche Punkte interpolieren lassen (schlecht für die Qualität) oder zufällig Punkte weglassen (ebenfalls schlecht für die Qualität). Interessant wird es bei loggern, die von sich behaupten, sie könnten in festen Abständen loggen. Ich hab selbst kein solches Gerät, würde aber stark vermuten, dass das auch nicht 100% funktioniert und man bei Kenntnis der Eigenheiten des Geräts auch recht gut auf die Geschwindigkeit schließen kann. c) Tracks ggf. neu teilen und umordnen, auch über Dateigrenzen hinweg. Das ist quasi trivial. d) so schonend wie möglich vorgehen, um z.B. bei der SpeedVisualisierung im Josm keinen völlig Humbug zu verzapfen. (Werte sollten also in +/-30%-Bereich bleiben) Hm. Das finde ich jetzt keine besonders gute Idee. Du willst ja aus der Speed- Visualisierung ggf. ablesen können wie schnell man auf der Straße fahren kann. Wenn ich da jetzt laut anonymisiertem Track 100 gefahren wäre, könnte das also in Wahrheit 75 oder 140 gewesen sein... Das ist ein ziemlicher Unterschied. Und wenn bei einer Straße der Mittelwert aller Tracks nachher auf 80 fällt, heißt das ebenfalls nichts. :) Ich wäre eher dafür, dass man beim upload angeben kann dass der Track anonymisiert ist und man bei der Daten-Auswertung für so etwas dann nur nicht- anonymisierte Tracks nutzen kann. e) Auf Windows-PCs laufen Oh, jetzt wird's knifflig. Immer dieser Spezialanforderungen. ;-)) Die trivialen Veränderungen kann prinzipiell alle gpsbabel. Unter http://www.gpsbabel.org/screenshots.html gibt es Screenshots der GUI für Windows. Zugegeben, es kann so wie es ist nicht auf Verzeichnissen operieren und nicht mehrere Dateien gleichzeitig bearbeiten. Aber da gpsbabel an sich mit den richtigen Parametern das kann, sollte es möglich sein, so etwas einzubauen. Als Basis wäre gpsbabelgui vermutlich gut geeignet. Gruß, Bernd -- Auto: Eine Vorrichtung, mit der man die Werkstatt schneller erreicht, als es zu Fuß je möglich wäre. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Slippymap mit Position von Mappern?
Hallo. Am Samstag, 3. Januar 2009 schrieb Sven Geggus: Was außer ihrem Standort unterscheidet die Mapper in meiner Umgebung von denen auf der anderen Seite des Globus? Wer seine Position nicht preisgeben möchte kann dies tun, alles andere ist security by obscurity. Richtig, aber viele Menschen verlassen sich darauf weil sie sich keine weiteren Gedanken dazu machen. :) Gruß, Bernd -- Fettflecke werden wie neu, wenn man sie regelmäßig mit Butter einreibt. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Track-Anonymisierer gesucht
Bernd Wurst schrieb: b) Geschwindigkeiten anonymisieren (random offset, Jitter/Skew), also massiv an den Timestamps der Punkte drehen Quasi unmöglich. Die meisten logger loggen in festen Intervallen. Wenn du also noch so sehr Kopfstände mit den Timestamps machst, sieht man nachher die Punkte-Linie und wer irgendwas über dich weiß, kann recht schnell dein Logger-Intervall herausfinden. Wenn dieses auf 1 Sekunde steht (was vermutlich die meisten aktiven OSM'ler haben), ist der Abstand zweier Punkte das was du in einer Sekunde gefahren bist. Egal was die Timestamps sagen. Garmin und Co arbeiten so, dass aus dem Empfänger jede Sekunde eine Koordinate kommt. Wenn man das Logintervall höher dreht, dann mittelt er jeweils die Anzahl der Werte, wenn man auf Abstand stellt, dann verwirft er so lang Punkte bis der Mindestabstand zum letzten noch gelogten Punkt erreicht ist. Will sagen: Wenn man Tracks glättet (GPS-Babel kann das ja auch), hat man hinterher ziemlich freie Hand zum Schieben. d) so schonend wie möglich vorgehen, um z.B. bei der SpeedVisualisierung im Josm keinen völlig Humbug zu verzapfen. (Werte sollten also in +/-30%-Bereich bleiben) Hm. Das finde ich jetzt keine besonders gute Idee. Du willst ja aus der Speed- Visualisierung ggf. ablesen können wie schnell man auf der Straße fahren kann. Wenn ich da jetzt laut anonymisiertem Track 100 gefahren wäre, könnte das also in Wahrheit 75 oder 140 gewesen sein... Dann eben +/-15%... Soll ja durchaus Leute geben, die auch Real ständig 20km/h schneller fahren als zulässig, darauf aufbauend wird hoffentlich auch niemand Speedlimits mappen. Ich wäre eher dafür, dass man beim upload angeben kann dass der Track anonymisiert ist und man bei der Daten-Auswertung für so etwas dann nur nicht- anonymisierte Tracks nutzen kann. Auch dafür. Vielleicht ein Upload mit komplett komplett gefälschten Timestamps (gestauchten) mit Geschwindigkeiten in einem Bereich, dass niemand ernsthaft daran glaubt? Wenn man sich mit Josm und Potlach verständigen könnte, solchermaßen anonymisierten und geänderten Tracks nur noch als Punktewolke darzustellen und ohne jede Speed-Visualisierung, dann hätte man GPS-Tracks zweiter Klasse eingeführt. Wäre vielleicht eine Möglichkeit. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Nasse Grenzen
Am Samstag, 3. Januar 2009 21:34 schrieb Jochen Topf: Die ways müssen ja nicht irgendwie zusätzlich getagged werden. Es reicht, wenn die passende Relation da ist. Ich schlage also vor: Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. Relation B: boundary=land_area type=multipolygon Enthält auf dem Lande die ways, die auch in Relation A drin, wo die aufs Wasser gehen dann aber die ways der Küstenlinien (also natural=coastline). Inseln erscheinen also als Exklaven. Dann müssten wir für alle Hamburger Stadtteile zwei Relationen anlegen, die Deckungsgleich sind? Finde ich Unschön. Was hälst du von einem Zusatztag Relation A: boundary=administrative type=multipolygon Enthält alle ways, die die Grenzen ausmachen, geht aufs Wasser hinaus. boundary_wettnes=water Relation B: boundary=administrative type=multipolygon Enthält auf dem Lande die ways, die auch in Relation A drin, wo die aufs Wasser gehen dann aber die ways der Küstenlinien (also natural=coastline). Inseln erscheinen also als Exklaven. boundary_wettnes=land Bei einem Stadteil von Hamburg der keine Nassen Grenzen hat: Einfach: Relation C: boundary=administrative type=multipolygon boundary_wettness=nowater oder sowas. Den Tag und die Values habe ich mir eben aus den Fingern gesogen. Es gibt bestimmt besserer Vorschläge. Eigentlich könnte man das auch an den Way drannhängen, also z.B. outer_water=42 outer_land=43 würde aber das Mutlitpolygon noch komplizierter machen Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de