Re: [Talk-de] Editieren bei laengeren Strecken
Wie mache ich das sinnvoll in JOSM? Split way kenne ich. Aber ein Stück löschen funktioniert ja nicht so richtig, da wird der Way gelöscht, nicht aber die Segmente und Nodes?! Erst splitten, markierung aufheben, dann löschen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Standseilbahn
Gestern war ich etwas Standseilbahn [1] Fahren. Hat jemand eine Ahnung wie man das richtig Taggen soll? Hab dann bei der Polybahn [2] nachgeschaut, die ist als railway=cable_railway getaggt. Sowas hab ich aber nicht in den Map_Features gefunden. [1] http://de.wikipedia.org/wiki/Braunwaldbahn [2] http://de.wikipedia.org/wiki/Polybahn Da gibts noch ein 2tes Proposal: http://wiki.openstreetmap.org/index.php/Proposed_features/Piste_Maps#Railways Grüsse ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osnabrück ist in einem Tag weit gekomm en - Frida Daten sind in OSM importiert!
Guten Morgen, http://www.informationfreeway.org/?lat=52.268677003321734lon=8.046990082365921zoom=12layers=B000F000 (bis die Daten im Mapnik Layer auftauchen wird's wie gewohnt noch ein paar Tage dauern) Unglaublich wie schnell etwas auf einmal gehen kann :) Mir ist aufgefallen, dass die Stadt recht gelb wirkt. Sind das alles secondary Strassen und nicht teilweise auch residential? Grüsse ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
Hi, Am Montag, 24. September 2007 schrieb Holger Issle: Ich fahre und tracke mit. Dann reduziere ich die Tracks in TTQV (und schneide Pausen etc raus) und speichere die als GPX, das ich in JOSM lade und dort dank convert to data layer als Daten habe. So weit so gut. Die Verwendung von dieser Funktion ist sehr umstritten und du solltest darauf achten, dass nicht zu viele Nodes eingefügt werden. - Wenn ich das mit meinen Tracks machen würde würden etwa die 20 fache Menge an Nodes und Segmenten erzeugt werden wie nötig. Ich persönlich halte es für das bessere Vorgehen in JOSM die Tracks anzuzeigen und dann die Nodes/Ways mittels HBI (= Human Brain Interpolation) selbst zu machen. Jetzt ergibt sich die Situation, daß es neue Wege gibt, und Bereiche die schon vor mir eingetragen wurden. Ergo will ich meine Wege dort anschließen wo schon welche bestehen, und von den Duplikaten meine Teile löschen (also das bestehende belassen). Wenn man die Wege selbst anlegt besteht dieses Problem nicht. Und es ist einfacher, Wege an bestehende Nodes anzuknüpfen. Wie mache ich das sinnvoll in JOSM? Split way kenne ich. Aber ein Stück löschen funktioniert ja nicht so richtig, da wird der Way gelöscht, nicht aber die Segmente und Nodes?! Du kannst Segmente und Nodes nur dann löschen, wenn die nicht verwendet werden. Also am besten den Weg splitten, dann einen davon löschen. Dann kannst du die Segmente die von dem gelöschten Teil verwendet wurden löschen. Happy mapping. Rapha ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] GPS Tracks zur Verfügung stellen
Hallo, wir sind ein kleines - mittleres Entsorgungs / Transportunternehmen und übernehmen bei ca. 3000 Stellen / Jahr in Bayern Fotochemikalien und andere Reststoffe, bei weiteren 8000 / Jahr Trockenbatterien. Kurz gesagt wir decken innerhalb eines Jahres ganz Bayern ab, eine große Menge der Daten ist aber redundant. Dazu setzen wir 4-5 Transporter (Iveco Daily - Mercedes Vario) zum Sammeln ein. Da diese Fahrzeuge derzeit mit Telematikgeräten ausgerüstet werden bestünde für uns die Möglichkeit die Tracks zur Verfügung zu stellen. Eine Nachbearbeitung der Tracks können wir nicht leisten. Besteht dennoch Interesse ? cu Ha-Jö ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tübingen
Hi Frank, btw. warum ist im mapnik renderer eigentlich immer wieder das waldgebiet des schönbuchs kaputt wie jetzt zum beispiel? Das könnte an der Anordnung der Linien liegen. Christoph Eckert hatte da so was erwähnt. Ich schau heut abend mal rein. -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
Hallo Karl, On Mon, 24 Sep 2007 09:16:58 +0200 (CEST), Karl Eichwalder wrote: Wie mache ich das sinnvoll in JOSM? Split way kenne ich. Aber ein Stück löschen funktioniert ja nicht so richtig, da wird der Way gelöscht, nicht aber die Segmente und Nodes?! Erst splitten, markierung aufheben, dann löschen. Ich habe nochmals getestet: Einen Weg markiert, dann Markierung aufgehoben. Das Löschtool angeklickt, den Weg angeklickt, und der Weg ist weg. Seine Nodes und Segmente sind aber noch da. Kann ich denn nicht alles auf einmal loswerden? Eigentlich will ich USER-Objekte bearbeiten (Straßen etc), nicht low-level-Objekte in einer Datenbank. Wenn ich eine Datei speichere muß ich ja auch nicht die Einträge in der FAT selber anlegen... Wenn das wichtig ist, ich verwende Repository UUID: 0c6e7542-c601-0410-84e7-c038aed88b3b Revision: 305 Node Kind: directory Last Changed Author: imi Last Changed Rev: 305 Last Changed Date: 2007-08-13 13:09:04 +0200 (Mon, 13 Aug 2007) mit Java 1.6.0_01 -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Eigene Luftbilder als Vorlage
Hallo Hermann, Am Mon, 24 Sep 2007 09:50:57 +0200 schrieb Hermann Schwaerzler: leider komme ich erst jetzt dazu, die zu antworten, aber am wochenende war nix mit mails lesen geschweige denn antworten. :-) Kein Grund zur Eile, die Bilder laufen ja nicht weg und ich stehe eh immer noch am Anfang. ;-) wenn du also zusätzlich zu meiner ultrakurzanleitung im mail von ein paar wochen noch fragen hast, helfe ich dir gerne weiter. Danke, auf das Angebot werde ich zurückkommen. und dann habe ich auch noch ein paar fragen: hast du die luftbilder selbst gemacht? Die Bilder, die ich im Moment habe sind Faksimiles von freigegebenen Militäraufnahmen. Auf den ersten Blick scheinen sie bereits orthorektifiziert zu sein, georeferenziert sind sie nicht. Grundsätzlich könnte ich aber auch Bilder machen (lassen), um die Ecke ist ein Sportflugplatz und jede Menge Flieger in der Nachbarschaft, die froh sind einen Grund zum Fliegen zu bekommen ;-) ich habe gesehen, dass man mit GRASS bilder orthorektifizieren kann. machst du es damit? GRASS und Quantum GIS waren die Anwendungen über die ich gestolpert bin und mit deren Hilfe ich mich wohl auch durchbeissen werde. Aus grauer Vorzeit meine ich mich zu erinnern, dass ich zur Bergtourenplanung mit einem Programm gearbeitet habe, das die Möglichkeit hatte gescannte Karten einzubinden und dabei die Projektion mit Hilfe von Referenzpunkten anzupassen. Keine Ahnung was das war, ich erinnere mich nur noch schwach an die Motif Oberfläche und, dass es auf einer SUN lief. Fugawi, bzw. TTQV dürften das heutzutage ja aber auch können (oder?), laufen nur leider unter Windows. Grüße, micha ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
Hi Frederick, Du musst den Way natuerlich doppelt splitten, wenn du mittendrin was rausloeschen willst. Soweit war mir das klar. Dann kannst du ein Selektionsrechteck um den zu loeschenden Bereich ziehen, so dass es das Stueck Way und die Segmente und Nodes umschliesst, dann ein Klick auf delete und weg ist alles. Das funktioniert ja aber grad dann nicht, wenn mein Track eine bestehende Straße überlagert (weil die dann auch selektiert wird). Oder übersehe ich da was? Im allgemeinen bin ich allerdings kein Freund von convert to data layer. Mittlerweile kannst Du mit dem add line and connect ziemlich komfortabel Tracks nachzeichnen und dabei an bestehende Nodes anknuepfen und/oder Kreuzungsnodes in bestehende Segmente einfuegen. Ist natuerlich nix fuer einen 200km-Track durch die Pampa, aber in den meisten Faellen doch gar nicht schlecht. Ich tracke grad auf der Alb, da ist bislang nur sehr wenig, und ich habe reichlich Tracks von Motorradtouren auf der Landstraße. Und die will ich nun wirklich nicht nachzeichnen, denn das sind bevorzugt kurvige Straßen. -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
On Mon, 24 Sep 2007 09:17:11 +0200, Raphael Mack wrote: Hi, Die Verwendung von dieser Funktion ist sehr umstritten und du solltest darauf achten, dass nicht zu viele Nodes eingefügt werden. - Wenn ich das mit meinen Tracks machen würde würden etwa die 20 fache Menge an Nodes und Segmenten erzeugt werden wie nötig. Ich reduziere das mit dem Filter in TTQV (und gpsbabel kann ähnliches wohl auch). Damit bleibt der Weg im wesentlichen erhalten, und überflüssige Punkte werden automatisch entsorgt. Es ist einfacher, einige wenige unzulänglichkeiten zu verbessern als alles von hand zu machen. Ich persönlich halte es für das bessere Vorgehen in JOSM die Tracks anzuzeigen und dann die Nodes/Ways mittels HBI (= Human Brain Interpolation) selbst zu machen. Ich hab letzte Woche 200km kurvige Landstraßen auf der Alb eingetragen. Bevor ich das komplett nachmale lass ichs ganz bleiben. -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
Holger Issle schrieb: Ich reduziere das mit dem Filter in TTQV (und gpsbabel kann ähnliches wohl auch). Damit bleibt der Weg im wesentlichen erhalten, und überflüssige Punkte werden automatisch entsorgt. Es ist einfacher, einige wenige unzulänglichkeiten zu verbessern als alles von hand zu machen. Ich habe gestern bei osmtrackfilter eine Funktion gesehen die aus einem Trackfile automatisch den Teil des Weges rausnehmen kann, der bereits in OSM ist. Getestet hab ich das allerdings noch nicht. Geplant ist das ich mal ein großes GPX File mit allen meinen Tracks mache und das dann durch diesen Filter laufen lasse, so bekomm ich ne schöne Übersicht was ich alles noch nicht eingetragen habe und kann mich dann immer noch entscheiden ob ich die Daten direkt übernehme oder eben manuell einpflege. MfG ah signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osnabrück ist in einem Tag weit gekomm en - Frida Daten sind in OSM importiert!
Raphael Studer schrieb: Guten Morgen, http://www.informationfreeway.org/?lat=52.268677003321734lon=8.046990082365921zoom=12layers=B000F000 (bis die Daten im Mapnik Layer auftauchen wird's wie gewohnt noch ein paar Tage dauern) Unglaublich wie schnell etwas auf einmal gehen kann :) Mir ist aufgefallen, dass die Stadt recht gelb wirkt. Sind das alles secondary Strassen und nicht teilweise auch residential? ich tippe bei dem leichten gelb mal auf teritary (oder wie man das auch immer schreibt) MfG ah signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Benennen von Tunnel, Brücken, R outen
Hallo, gibt es eigentlich eine elegante Möglichkeit, Tunnel-, Brücken- und Routen (also z.B. Deutsche Spargelstraße, Badische Weinstraße etc.) zu taggen. Der name-Tag fällt ja häufig flach, da z.B. eine Straße über eine Brücke ja einen eigenen Namen hat. Nehme ich also am besten loc_name? Was, wenn ich eine Straße mit einem loc_name habe und dort auch ein Tunnel vorhanden ist? Das ist nicht konstruiert, ich habe den Fall hier wirklich: Ich habe hier einen Straßenzug aus mehreren (Teil-)Straßen, der hier in der Stadt eigentlich nur als Schlossbergtangente bekannt ist. Dort gibt es auch einen Schlossbergtunnel. Ich glaube bei den Londoner Daten gesehen zu haben, dass dort einfach parallel zur Straße über eine Brücke einfach ein weiterer Way angelegt wird und der dann mit dem name-Tag versehen wird. Halte ich aber für eine unsaubere Lösung. Gruß, Wabba ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
Hallo, Dann kannst du ein Selektionsrechteck um den zu loeschenden Bereich ziehen, so dass es das Stueck Way und die Segmente und Nodes umschliesst, dann ein Klick auf delete und weg ist alles. Das funktioniert ja aber grad dann nicht, wenn mein Track eine bestehende Straße überlagert (weil die dann auch selektiert wird). Oder übersehe ich da was? Jein. Wenn Du bloss ein paar Segmente einer ueberlagerten Strasse mitmarkierst, dann passiert genau das, was man eigentlich haben will - die ueberlagerte Strasse bleibt bestehen, weil sie aus Deinem Rechteck herausragt und dadurch die Segmente und Nodes benutzt sind, waehrend Deine zu loeschende Strasse genau im Rechteck drin liegt und daher samt Nodes und Segmenten geloescht werden kann. Zugegeben, etwas frickelig manchmal, aber in vielen Faellen kann man damit ganz gut arbeiten. Ein anderer Trick, der aber auch schon sehr in die Eingeweide geht, ist der folgende: Wenn Du mit dem Selektionsrechteck Zeugs markiert hast, git es ja einen von diesen Andock-Dialogen, der die Liste mit allen selektierten Objekten anzeigt - oben Nodes, dann Segmente, dann Ways. Alles, was noch keine ID hat (bzw. eine negative), also von Dir neu angelegt wurde, kommt immer vor allem, was schon eine ID hat, also vom Server geladen wurde. Will ich nun alle Segmente loeschen, die sich im markierten Bereich befinden und die nicht vom Server kamen, kann ich di eobere Haelfte der Segmente in diesem Dialog, also die ohne Nummer, markieren (Click aufs erste, Shift-Click aufs letzte), dann den Select-Button druecken, und dann die Loeschfunktion anwenden. Ebenso mit Nodes oder Ways. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Daten Korrigieren
Hallo, willkommen! OSM Daten erstellt. Jetzt muss ich unseren Ort an die nächstgrößere Bundesstraße anschließen. Wie geht man hier am besten vor? So wie Du es schon beschreibst: Daten vom Server holen, eigene an- und einfügen, hochladen Habe auch bemerkt, dass die GPS-Daten der Bundesstraße nicht ganz genau sind. Meine Idee wäre ja: Mit JOSM den betreffenden Ausschnitt der Bundesstraße vom Server holen, unseren Ort anbinden und die etwas falschen Daten korrigieren, und alles zusammen wieder hoch laden. Nur habe ich ja lediglich einen Teil der Bundesstraße auf meinem System, kommt der Server mit so was dann zurecht? Ja, denn alle Bundesstraßen sind ja viel zu lang, um sie als einen Way zu machen. JOSM ist so schlau, daß es Dir einen Way holt (also da abschneidet, wo der nächste Way beginnt.) Mach so, wie Du es vorgeschlagen hast. Grüße Cor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tübingen
On Mon, Sep 24, 2007 at 07:44:41AM +0200, Frank Sautter wrote: die eine oder andere straße in tübingen habe ich auch schon bearbeitet. aber mehr den raum schönbuchlichtung und gäu sowie böblingen, sindelfingen, magstadt. OK. Werden dieses WE wahrscheinlich nach Leonberg fahren und auf dem Weg ein paar Daten ergänzen. In Leonberg sind dann wahrscheinlich auch ein paar Straßen fällig, das sieht noch recht kahl aus. CU Sascha -- http://sascha.silbe.org/ pgp8o4C1r5vVd.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Daten Korrigieren
Super, danke für die schnelle Antwort. Eine Frage hätte ich aber doch noch. JOSM zeigt mir bei den Properties nur Created by=JOSM. Muss ich die Properties wieder neu setzten oder werden die beim hochladen wieder richtig übernommen? Nicht das ich die Bundesstraße zerlege, oder das System die als neue unabhängige Straße ansieht. Grüße Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von [EMAIL PROTECTED] Gesendet: Montag, 24. September 2007 12:03 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Anfängerfrage: Daten Korrigieren Hallo, willkommen! OSM Daten erstellt. Jetzt muss ich unseren Ort an die nächstgrößere Bundesstraße anschließen. Wie geht man hier am besten vor? So wie Du es schon beschreibst: Daten vom Server holen, eigene an- und einfügen, hochladen Habe auch bemerkt, dass die GPS-Daten der Bundesstraße nicht ganz genau sind. Meine Idee wäre ja: Mit JOSM den betreffenden Ausschnitt der Bundesstraße vom Server holen, unseren Ort anbinden und die etwas falschen Daten korrigieren, und alles zusammen wieder hoch laden. Nur habe ich ja lediglich einen Teil der Bundesstraße auf meinem System, kommt der Server mit so was dann zurecht? Ja, denn alle Bundesstraßen sind ja viel zu lang, um sie als einen Way zu machen. JOSM ist so schlau, daß es Dir einen Way holt (also da abschneidet, wo der nächste Way beginnt.) Mach so, wie Du es vorgeschlagen hast. Grüße Cor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Anfängerfrage: Daten Korrigieren
On 9/24/07, PartySound [EMAIL PROTECTED] wrote: Super, danke für die schnelle Antwort. Eine Frage hätte ich aber doch noch. JOSM zeigt mir bei den Properties nur „Created by=JOSM. Muss ich die Properties wieder neu setzten oder werden die beim hochladen wieder richtig übernommen? Nicht das ich die Bundesstraße zerlege, oder das System die als neue unabhängige Straße ansieht. Nein, die properties kannst Du so lassen. Die werden automatisch eingefügt, wenn es JOSM erstellt, modifiziert wird Cor ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osnabrück ist in einem Tag weit gekomm en - Frida Daten sind in OSM importiert!
On 9/24/07, Andreas Hubel [EMAIL PROTECTED] wrote: Raphael Studer schrieb: Guten Morgen, http://www.informationfreeway.org/?lat=52.268677003321734lon=8.046990082365921zoom=12layers=B000F000 (bis die Daten im Mapnik Layer auftauchen wird's wie gewohnt noch ein paar Tage dauern) Unglaublich wie schnell etwas auf einmal gehen kann :) Mir ist aufgefallen, dass die Stadt recht gelb wirkt. Sind das alles secondary Strassen und nicht teilweise auch residential? ich tippe bei dem leichten gelb mal auf teritary (oder wie man das auch immer schreibt) Jetzt wo dus sagst :) Find trotzdem, dass es etwas gar viele von diesem Typ Strasse hat. Sind solche Strassen doch Residential. Ich tagg die jeweils so. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
Holger Issle schrieb: Ich hab letzte Woche 200km kurvige Landstraßen auf der Alb eingetragen. Bevor ich das komplett nachmale lass ichs ganz bleiben. Das ist nachzuvollziehen. Man kann aber mit dem Löschwerkzeug auch nachträglich sehr schnell überflüssige Nodes entfernen. In meinem Revier sind viele Tracks, die nur nach Track generiert wurden. Wenn ich da mal nebenbei drüber gehe sterben in der Minute über 50 Nodes ;-) So kann man fix die Datenbank um etliche KBs erleichtern (die auch den Renderer entlasten). Und in Wohngebieten sind die Straßen halt meist gerade weshalb dieses Zickzack (das durch mäßigen Empfang entsteht) nicht nur falsch ist sondern auch die Lesbarkeit enorm verschlechtert. Musst aber du selber wissen. Die sterben spätestens wenn in fünf Jahren der Globus kartiert ist und die erste Qualitätsoffensive gestartet wird ;-) Mfg, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tübingen
On Mon, 24 Sep 2007 12:06:16 +0200, Sascha Silbe wrote: Bist Du Bulldozer-Holger? Gut kombiniert :-) Der Dozer ist hier online: http://shop.lego.com/Product/?p=8275 -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Editieren bei laengeren Strecken
Hi Frederick, Ein anderer Trick Die Idee ist cool, das probier ich mal aus. Vor allem weil es viel einfacher zu sehen ist als die Elemente in der Grafik. -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tübingen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tag, Sascha Silbe schrieb: Wer (ausser mir) bearbeitet denn Tübingen? Bitte mal melden zwecks Koordination. *meld* Mein Kollege (Nickname: nochmaltobi) und ich (derm00m) sind recht aktiv in Tü. Im Wiki haben wir die Stadtteile schonmal grob zusammengeschrieben (http://wiki.openstreetmap.org/index.php/T%C3%BCbingen), sind aber bisher eher nach Lust und Laune durch die Stadt marschiert oder haben Wege gemapt, die wir ohnehin fahren. Können das gerne koordinieren (auch bei ner gemütlichen Wiener Melange im Fachschaftszimmer aufm Sand ;)) Gruß - -- Juergen Mayer - -- pgp key id 0x2766D0F2 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG96U0pCkI1Sdm0PIRAvbbAJsFsi3yU1Dm8yK8nzxtYkLPP5qD2wCfV+MT RcBzsEedH+p59sSFLaq1/eI= =LUEk -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tübingen
On Mon, Sep 24, 2007 at 01:53:01PM +0200, J. Mayer wrote: Mein Kollege (Nickname: nochmaltobi) und ich (derm00m) sind recht aktiv in Tü. Wusste ich doch, daß ein Info'tiker dabei ist. :) Im Wiki haben wir die Stadtteile schonmal grob zusammengeschrieben (http://wiki.openstreetmap.org/index.php/T%C3%BCbingen), sind aber bisher eher nach Lust und Laune durch die Stadt marschiert oder haben Wege gemapt, die wir ohnehin fahren. So mach ichs bisher auch. Und plötzlich gabs den Berliner Ring doppelt. :) Können das gerne koordinieren (auch bei ner gemütlichen Wiener Melange im Fachschaftszimmer aufm Sand ;)) Gern. Ich selbst werde allerdings vom dem Gebräu Abstand halten und lieber was vom bösen Monopolisten vernichten. :) pgp key id 0x2766D0F2 PGP Keysigning können wir bei der Gelegenheit auch gleich machen. :) Wann seid ihr beide denn die nächsten Tage auf dem Sand? CU Sascha -- http://sascha.silbe.org/ pgp8JNrxj3JLr.pgp Description: PGP signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS Tracks zur Verfügung stellen
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo Herr Vashold, da sich bisher niemand gemeldet hat, hebe ich mal die Hand: Ja, Interesse besteht. In welchem Format liegen die Tracks vor? Mit freundlichen Grüßen, Andreas Winckler Hans-Jörg Vasold schrieb: Hallo, wir sind ein kleines - mittleres Entsorgungs / Transportunternehmen und übernehmen bei ca. 3000 Stellen / Jahr in Bayern Fotochemikalien und andere Reststoffe, bei weiteren 8000 / Jahr Trockenbatterien. Kurz gesagt wir decken innerhalb eines Jahres ganz Bayern ab, eine große Menge der Daten ist aber redundant. Dazu setzen wir 4-5 Transporter (Iveco Daily - Mercedes Vario) zum Sammeln ein. Da diese Fahrzeuge derzeit mit Telematikgeräten ausgerüstet werden bestünde für uns die Möglichkeit die Tracks zur Verfügung zu stellen. Eine Nachbearbeitung der Tracks können wir nicht leisten. Besteht dennoch Interesse ? cu Ha-Jö ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de - -- - - Andreas Winckler http://www.andreas-winckler.de A good plan today is better than a perfect plan tomorrow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFG99BmtjGQfQhK43URAszDAKC0IedBQeb7UEPfsL6kugy9sLuxeACeN1Of x0L92pXqxQMWnP+X/j2L6zw= =oH2K -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Worldfile vom 19.9.07
Hi, ich hab grad die Version vom 19.9. in MapSource eingebunden, und da gibt es gravierende Probleme. MS stürzt beim Durchzoomen einfach ab einem bestimmten Anzeigegrad kommentarlos ab. Und zwar eine ältere die bei mir noch auf dem System war, als auch die allerneueste. Kann das bitte mal noch jemand anders testen? Karte anzeigen, zoom 700km, dann die Plus-Lupe klicken. Bei Anzeigen von der Stufe 50km mit Medium Detaillierung schepperts: Opening map at (lat,lon): 48.2087, 9.69683 Resolution: 16 Rückwärts von 20m rauszoomen geht bis Stufe 7km, dann schepperts mit Resolution 18. Danke! -- Ciao, Holger (GUS-KOTAL, GUS#1100) 90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm 95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 50 Mm (Die Renndrecksau!) cu @ http://www.issle.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS Tracks zur Verfügung stellen
Ich bin zu mindest persönlich der Meinung, dass wir so dann innerhalb des nächsten Jahres die Hauptverkehrsstraßen von Bayern abgedeckt bekommen müssten. Die anfallenden GPX Daten könnten wir ja zwecks Arbeitserleichterung mit dem OSM Filter erstmal weiter verarbeiten. Ich bin strikt dagegen, die daten (halb-)automatisch drüberzubügeln. Das wären allenfalls in völlig jüngfräulichem gebiet akzeptabel. Das genaue Tagging der einzelnen Straßen sollte dann aber von Ortskundigen auch nachträglich gut machbar sein. Das ist von gegend zu gegend bestimmt sehr unterschiedlich... Aber auf jeden Fall würden wir uns sehr über diese Daten für unser Projekt freuen! Ja, zu vergleichzwecken wären die track wohl brauchbar, aber bitte nicht blind einspielen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS Tracks zur Verfügung stellen
Karl Eichwalder schrieb: Ich bin strikt dagegen, die daten (halb-)automatisch drüberzubügeln. Das wären allenfalls in völlig jüngfräulichem gebiet akzeptabel. Sehe ich auch so, diese automatischen Ways sind zwar gut für den Anfang, damit man mal ein wenig auf der Karte zu sehen bekommt. Aber die Arbeit der Ortskundigen, die die Straße dann qualitativ aufarbeiten wird dadurch nicht so wirklich erleichert. Ja, zu vergleichzwecken wären die track wohl brauchbar, aber bitte nicht blind einspielen. Ganz genau, die bloßen Pünktchen des Tracks sind nämlich super um damit zu arbeiten. Wen man selber schlechten Empfang oder eh ein schlechtes Gerät hatte lassen sich damit Kurven und exakte Straßenverläufe viel besser aufnehmen. Freue mich immer wenn eine zu mappende Straße schon befahren wurde, dann liegt die Verantwortung nicht allein auf meinen Daten. Also einfach GPX-Files übers Webinterface hochladen und gut is. MfG, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS Tracks zur Verfügung stellen
Am Montag, 24. September 2007 schrieb Karl Eichwalder: Aber auf jeden Fall würden wir uns sehr über diese Daten für unser Projekt freuen! Ja, zu vergleichzwecken wären die track wohl brauchbar, aber bitte nicht blind einspielen. Also ich finde, die Tracks als GPS-Punkte raufzuladen ist wunderbar. - Von automatisch Wege draus generieren halte ich jedoch nicht viel. (Wer hätt's gedacht ;-?) Rapha ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS Tracks zur Verfügung stellen
Am Montag, 24. September 2007 22:24 schrieb Sven Grüner: Also einfach GPX-Files übers Webinterface hochladen und gut is. Ich hätte auch nichts dagegen, wenn jemand von der Liste (ich würde dies auch tun) die Tracks per Email entgegen nimmt, mit josm eine Qualitätskontrolle durchführt und sie dann per Webinterface hochlädt. Um Missverständnissen vorzubeugen, würde ich dafür natürlich einen extra-account anlegen. Es kommt natürlich auch etwas auf die Menge an, denn der edle Spender soll ja nicht allzu viel kostbare Zeit verlieren, und fürs Sichten würde ich nicht mehr als 3 Stunden pro Woche veranschlagen. Mit freundlichen Grüßen Thomas Schäfer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Osnabrück ist in einem Tag weit gekomm en - Frida Daten sind in OSM importiert!
Raphael Studer schrieb: On 9/24/07, Andreas Hubel [EMAIL PROTECTED] wrote: Raphael Studer schrieb: Guten Morgen, http://www.informationfreeway.org/?lat=52.268677003321734lon=8.046990082365921zoom=12layers=B000F000 (bis die Daten im Mapnik Layer auftauchen wird's wie gewohnt noch ein paar Tage dauern) Unglaublich wie schnell etwas auf einmal gehen kann :) Mir ist aufgefallen, dass die Stadt recht gelb wirkt. Sind das alles secondary Strassen und nicht teilweise auch residential? ich tippe bei dem leichten gelb mal auf teritary (oder wie man das auch immer schreibt) Jetzt wo dus sagst :) Find trotzdem, dass es etwas gar viele von diesem Typ Strasse hat. Sind solche Strassen doch Residential. Ich tagg die jeweils so. Wenn Ihr denn mal auf die ToDo Liste unter Genaueres zum Stand der Dinge ist unter: http://wiki.openstreetmap.org/index.php/Frida zu finden. angeschaut hättet, wäre euch bestimmt mein Kommentar dazu aufgefallen ;-))) Die meisten Straßen sind tertiary, obwohl bestimmt sehr viele davon nur residential sind. Wie gesagt, es gibt durchaus noch einiges, was man verbessern muß damit die Daten wirklich OSM konform sind, das meiste kann man aber jetzt auch aus der Ferne machen (was für nasse Herbsttage). Ich wollte aber zuerst mal die Daten *vor* der API 0.5 drin haben. Sonst wären wir Gefahr gelaufen, die Daten *nie* nach OSM importiert zu bekommen. Da ich aber denke, daß die Daten momentan zwar nicht schön, aber wesentlich besser als garnichts sind, habe ich sie einfach mal importitert ... Gruß ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS Tracks zur Verfügung stellen
Am Montag, 24. September 2007 21:02 schrieb Andreas Winckler: - gpg control packet Sven Grüner schrieb: Also einfach GPX-Files übers Webinterface hochladen und gut is. Wenn die Daten als GPX vorliegen. Wenn nicht, muss sie jemand konvertieren. So wie ich das Posting von Herrn Vasold verstanden habe, hat er genau dafür aber keine Zeit. Also braucht's vermutlich Freiwillige, die mit gpsbabel und mit Shell-Skripten umgehen können. gpsbabel nutze ich auch, und etwas Shell-Programmierung kann ich auch. Melde mich hiermit als Freiwilliger. MfG TS ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS Tracks zur Verfügung stellen
Am Montag, 24. September 2007 21:23 schrieb Frederik Ramm: Hi, Wenn die Daten als GPX vorliegen. Wenn nicht, muss sie jemand konvertieren. So wie ich das Posting von Herrn Vasold verstanden habe, hat er genau dafür aber keine Zeit. Also braucht's vermutlich Freiwillige, die mit gpsbabel und mit Shell-Skripten umgehen können. Das ist sicherlich das kleinere Problem. Etwas komplizierter ist, das diese Fahrzeuge ja staendig die gleichen Wege fahren (der OP sagte ja auch viele Daten redundant). Die ersten paar Mal wuerden wir schon hochladen, aber nach 10 Tracks auf der gleichen Strasse verliert sich fuer uns etwas der Nutzen; wir sollten dann nur noch das hochladen, was es noch nicht gibt - und das koennte diffizil werden. Ich würde mir die Dinger ja mit josm vorher anschauen und ggf. zum Vergleich die GPX-Daten aus der Datenbank drüber/drunter legen. Nur bei Großstädten, wie z.B. München geht das nicht mehr, weil da schon soviel gps-Tracks sind, dass das Herunterladen zum Vergleichen nicht mehr (in angemessener Zeit) geht, aber wahrscheinlich auch überflüssig ist. Redundanz kann ich aber auch ohne DB-Zugriff nach lokaler Sammlung feststellen. Ich fürchte aber nicht nur Redundanz, die ich in gewissen Umfang sogar für gut halte, ich habe eher Angst vor sinnlosen Ausreißern (schlechter Empfang), die man nur durch Redundanz bzw. Luft/Satbilder erkennt. Wie gesagt zum Konvertieren und Sichten und kontrollierten Hochladen erkläre ich mich bereit. Das Anlegen der eigentlichen Wege überlasse ich dann, denen die die besseren Ortskenntnisse haben. Wenn ich es mengenmäßig nicht schaffe, kann ich mich ja melden oder falls die Brauchbarkeit der Daten sinkt, dem Spender dankend um Beendigung bitten. Mit freundlichen Grüßen Thomas Schäfer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Unterstützung für die(?) Se rver
Hallo, Also, wenn einer von Euch der Top-MySQL-Mann ist (der also auch genau weiss, wie sich verschiedene Replikationseinstellung und Netzwerk- Latenz auf die Performance sehr grosser Datenbanken auswirkt, mit teils InnoDB und teils MyISAM und so weiter und so weiter - bitte kein ich hab mal gehoert, dies und das geht vielleicht...) - direkt bei Tom Hughes melden. (Nicht Nick Hill, der macht nichts mehr!) Hm, hat eigentlich mal jemand offiziell bei mysql AB angefragt? Menschen wie z.B. Kristian Köhntopp könnten da bestimmt passende Tipps geben :) Naja, ideal waere jemand, der dann auch beim Projekt mitarbeitet und nicht bloss Tips gibt, sondern die auch selber umsetzt ;-) Tip-Geber haben wir eine ganze Menge; der haeufigste Tip ist: Warum nehmt ihr nicht PostGIS, da ist das, was ihr braucht, doch alles schon einge- baut, und es ist eh alles viel besser und ausserdem ist MySQL doch jetzt boese! Was alles durchaus sein kann, bloss hat bislang nie jemand den ganzen Schmodder nach PostGIS portiert, und so bleibt es bei Spekulation. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Unterstützung für die(?) Se rver
Hallo alle zusammen, ich möchte mich kurz vorstellen: Ich heisse Christian und bin der, auf den fuesika vor einigen Tagen angespielt hat, also der, der den Server administriert. Zum Thema: Ich habe mich eben erst auf der Liste eingeschrieben, konnte daher nicht die ganze Diskussion verfolgen. Ich halte sehr viel von dem Projekt und denke dass wir viel erreichen werden :) Ich selber habe einige theoretische und praktische Erfahrung mit den Load-Balancing und Clustering-Thema. Jedoch ist es einige Zeit her, dass ich das mit MySQL gemacht habe und es hat sich sicher einiges geändert. Wenn ich mich für ein Szenario entscheiden müsste, würde ich, ohne die finanzielle Lage zu kennen, ein 5-Server-Cluster empfehlen. Dabei gibt es 2 Frontend-Server, auf denen der Webserver läuft, und 2 Backend-Server die die Datenbank beherbergen. Der 5te Server wäre ein Fileserver. Die Webserver greifen per NFS auf den Fileserver zu und holen die Daten von dort. Dabei besitzen die Webserver einen Disk-Cache, damit die Daten vom Fileserver nur mittels rsync partiell übertragen werden müssen. Die Backend-Server bestehen aus einem MySQL-Cluster die sich selbstständig abgleichen, indem sie die binären MySQL-Logs übertragen. So werden die Daten nach wenigen (Milli-) Sekunden abgeglichen sein und man kann auf beide Server gleichermassen zugreifen. Die Webserver würden in einer LoadBalancing-Farm laufen, wobei der Server der eine Anfage annimmt aus der IP des Clienten und der Zahl der aktiven Server errechnet wird. So passiert es nicht dass Sessions ungültig werden, weil der zuständige Server andauernd wechselt. Webserver A greift hauptsächtlich auf DB-Server A zu, dazu analog Server B. Wenn einer der DB-Server den Geist aufgibt, wird der Webserver das binnen Sekunden merken und auf den anderen Server zugreifen. Wenn der andere DB-Server wieder da ist, würde MySQL die Daten wieder vom anderen Server abgleichen. Wenn ein Webserver abstürzt, merkt das der andere Server am fehlenden Heartbeat und berechnet die Formel der Zuständigkeit neu, und übernimmt die gesamte Arbeit. Diese Architektur hat den Vorteil, dass sie nach oben Problemlos erweiterbar ist und dass nicht wirklich 5 Server benutzt werden müssen. Z.b. kann der Fileserver auch einer der Webserver sein, oder andere Variationen. Nachteil ist, dass das nichts für Ich habe einen Server frei ist, wo man mal schnell einen Server für 3 Wochen dazustellt. Besonders, weil die Netzwerkkabel zwischen den Servern gekreuzt sind, also jeder ein Kabel zu jedem anderen. Es müssten wohl alle in einem Serverschrank stehen. Zu der Sache, dass man Server schnell auf einen anderen Rechner schiebt (Ich habe einen Server frei), gibt es auch Möglichkeiten die wohl auf Xen o. ä. basieren würden. Xen kann Server durch die ganze Welt schieben, wobei die Ausfallzeit unter 100ms bleibt. Zu mir: Theoretisch (und auch praktisch) könnte ich ein Konzept wie dieses realisieren. Praktisch bin ich momentan Ausbildungssuchend und hoffe, dass ich baldigst etwas finden werde. Es wurde gefordert, dass sich da wirklich jemand drum kümmern muss, wozu ich aus dem oben genannten Grund keine Zeit habe. Ich pflichte dem jedoch bei, eine solche Aufstellung erfordert hohes Know-How und sehr viel Zeit. Besonders im Anfangsstatium wird man da viel schrauben müssen. Ich halte es leider für relativ unwahrscheinlich, dass jemand diese Zeit aufbringen kann, der das wenigstens die ersten 2-3 Jahre nicht als Fulltime-Job macht. Zu den Posts in der dev-Liste: Der root, der dieses Konzept erledigt, wird ohne, dass _alles_ mit ihm abgesprochen wird durchdrehen. Die Server müssen wirklich syncron bleiben, sonst klappt es nicht.. Ggf. sogar netboot-Maschinen die das Betriebssystem vom Fileserver holen. Es darf wenn sowas durchgeführt wird, nichts ohne Absprachen gemacht werden, und es sollte dringenst 2 roots geben, wobei einer die Entscheidungskraft hat und beide so arbeiten wie Programmierer beim Extreme-Programming. Soviel zur Theorie, es ist nicht einfach. Es spricht aber weniger dagegen, wenn, wie sicher auch schon vorher erwähnt, wenn untergeordnete Mirrors verwendet werden, die als Read-Only nur die Karte anzeigen. Problem hier ist, dass die nicht komplett syncron gehalten werden können, da sie optimalerweise in Ballungsgebieten aufgestellt würden und von dort die Anbindung nach London schlechter ist. Aber das wichtigste: Alle roots und Entwickler müssen gut miteinander klarkommen und nicht irgendsoeinen Quatsch wie z.b. bei den Debian-Development-Lists anfangen. Liebe Grüsse, Christian Frederik Ramm wrote: Hallo, Also, wenn einer von Euch der Top-MySQL-Mann ist (der also auch genau weiss, wie sich verschiedene Replikationseinstellung und Netzwerk- Latenz auf die Performance sehr grosser Datenbanken auswirkt, mit teils InnoDB und teils MyISAM und so weiter und so weiter - bitte kein ich hab mal gehoert, dies und das geht vielleicht...) - direkt bei Tom
Re: [Talk-de] ?Unterstützung für die(?) Se rver
Hallo, ich möchte mich kurz vorstellen: Ich heisse Christian und bin der, auf den fuesika vor einigen Tagen angespielt hat, also der, der den Server administriert. Willkommen bei OSM ,-) Wenn ich mich für ein Szenario entscheiden müsste, würde ich, ohne die finanzielle Lage zu kennen, ein 5-Server-Cluster empfehlen. Dabei gibt es 2 Frontend-Server, auf denen der Webserver läuft, und 2 Backend-Server die die Datenbank beherbergen. Fileserver und NFS brauchen wir vermutlich (an dieser Stelle) nicht; es gibt naemlich praktisch keinen statischen Content, der ausgeliefert wird. Den gibt es an anderer Stelle - bei den Tile-Webservern (der dev-Server fuer [EMAIL PROTECTED] und der tile-Server fuer Mapnik), aber das laeuft ganz separat von der Datenbank. Bevor man anfaengt, sich irgendwelche Replikations-Szenarien auszudenken, muss man erstmal schauen, was wir eigentlich haben, was wir wollen, und wo das Problem ist. Klar, das Problem ist, dass derzeit alles (alle Datenbank-Lese- und Schreib-Requests) ueber einen Server laufen. Das macht nicht nur unnoetig viel Last, sondern das gibt auch zuweilen im MySQL-Server einfach Haenger wegen des Locking (ein Prozess macht einen dicken SELECT, der 2 Minuten dauert, macht derweil ein Write-Lock, so dass andere zwar lesen, aber nicht schreiben duerfen; ein zweiter Prozess kommt und will schreiben, darf nicht, haengt in der Warteschlange; ein dritter Prozess kommt und will eigentlich nur lesen, darf aber nun auch nicht, weil der zweite Prozess erster war und schon einen Lock-Request eingequeuet hat). Ein sehr grosser Teil unserer Anfragen sind Lese-Requests. Die haben wir im Moment schon stark eingeschraenkt - man kann nicht mal mehr eine ganze deutsche Grossstadt auf einmal abrufen, weil so grosse Requests nicht erlaubt sind. Das ist nur ein Notanker - eigentlich waere es schoen, wenn jeder alles requesten darf, was ihn interessiert. Wir haben, damit sich keiner zu arg aergern muss, das planet file, einen Komplett-Dump aller Daten, der woechtenlich rauskommt. Jeder, der mit eine Woche alten Daten zufrieden ist, kann damit arbeiten (obwohl das auch zunehmend unhandlicher wird - eine Datenbank ist schon komfortabler als ein Riesenfile). Das planet file wird demnaechst vermutlich auch haeufiger kommen, oder es wird zumindest taegliche Updates dafuer geben, so dass es leichter ist, einigermassen aktuell zu blieben. Aber es ist und bleibt (finde ich) eine Kruecke. Ich skizziere mal eine Idee, die ich schon ewig mit mir rumtrage und bei jeder Gelegenheit wieder mal auf den Tisch bringe: Ich finde einen zentralen Server fuer alle Schreibrequests, einen zentralen Master, ok. (Man *koennte* durchaus auch partitionieren - der Master fuer Deutschland koennte in Deutschland stehen, und grenzueberschreitende Requests waeren dann durch geeignete Metaserver zusammenzusammeln. Hat auch viele Vorteile. Aber nehmen wir erstmal an, wir haben einen zentralen Server.) Dieser zentrale Master hat einen Slave, auf den er alle Aenderungen in Quasi-Echtzeit kopiert. Alle Lese-Requests sind von diesem Slave zu machen. Der Slave wiederum akzeptiert eine begrenzte Anzahl von Feeds. Ein Feed ist eine weitere Datenbank am Ende irgendeiner Leitung, die alle Updates oder nur bestimmte Updates geliefert bekommt. Ein Feed, der alle Updates bekommt, ist ein full feed; ein Feed koennte aber auch sagen: Ich will nur alles, was in dieser und jener Bounding box liegt (ein regionaler Feed), oder thematisch ich will nur alles, was railway=irgendwas ist. Diese Feeds koennen wiederum kaskadiert werden - wer in vor-IP-Zeiten Usenet gemacht hat, kann sich das vielleicht besser vorstellen: Nicht jeder kann einen Full-Feed von der Zentrale bekommen, aber es koennte einen Full-Feed irgendwo in Deutschland geben, an dem wiederum 10 unter-Feeds dranhaengen, und so weiter. Durch die entstehende Baumstruktur troepfeln dann Aenderungen mehr oder weniger schnell nach unten durch; letzten Endes kann jeder, ueberall auf der Welt, einen stets aktuellen OSM-Bestand von allem haben, was ihn interessiert. Wenn man nun mit JOSM oder so etwas aendert, kann man sich problemlos die Daten von einem halbwegs aktuellen Feed laden: Wir unterstuetzen ja eh keine transaktionalen Updates, d.h. selbst wenn ich mit JOSM direkt vom zentralen Server etwas lade und daran Aenderungen vornehme, kann es immer sein, dass mir jemand anders in die Quere kommt. Ob ich nun 10 Minuten alte Daten lade und daran eine halbe Stunde herumbastele oder ob meine Daten 10 Millisekunden alt sind, macht keinen Unterschied. Eine solche Architektur waere extrem leistungsfaehig und beliebig skalierbar. Superflexibel obendrein - denn Feeds muessten ja nicht alle die OSM-Software fahren, jemand kann durchaus auch direkt in eine Postgres-Datenbank hineinfeeden oder irgendwas anderes. Eine solche Architektur koennte allerdings nicht auf MySQL-Replikation aufgesetzt werden, sondern muesste eine Abstraktionsstufe weiter oben stattfinden, im
Re: [Talk-de] GPS Tracks zur Verfügung stellen
Frederik Ramm [EMAIL PROTECTED] writes: Das ist sicherlich das kleinere Problem. Etwas komplizierter ist, das diese Fahrzeuge ja staendig die gleichen Wege fahren (der OP sagte ja auch viele Daten redundant). Koennte man da nicht gerade was draus machen, und die alle averagen, und somit an Genauigkeit gewinnen? Ob es dafuer ein fertiges Skript gibt weiss ich allerdings nicht - ist sicher nicht ganz unkompliziert. Wenn *DOP-Daten drin sind koennte man auch danach filtern, und nur gute Tracks verwenden. Cheers Colin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] ?Unterstützung für die(?) Se rver
Hi Frederick, Willkommen bei OSM ,-) Danke :) Wenn ich mich für ein Szenario entscheiden müsste, würde ich, ohne die finanzielle Lage zu kennen, ein 5-Server-Cluster empfehlen. Dabei gibt es 2 Frontend-Server, auf denen der Webserver läuft, und 2 Backend-Server die die Datenbank beherbergen. Fileserver und NFS brauchen wir vermutlich (an dieser Stelle) nicht; es gibt naemlich praktisch keinen statischen Content, der ausgeliefert wird. Wie schon gesagt, ich kenne mich mit der aktuellen Infrastruktur nicht aus, aber ich dachte bei der rsync-Syncronisation an die Scripte die die Tiles, etc. generieren. Klar, Fileserver ist oversized für 20 PHP-Dateien aber ich habe ihn der Anschaulichkeit angeführt. Bevor man anfaengt, sich irgendwelche Replikations-Szenarien auszudenken, muss man erstmal schauen, was wir eigentlich haben, was wir wollen, und wo das Problem ist. ACK Klar, das Problem ist, dass derzeit alles (alle Datenbank-Lese- und Schreib-Requests) ueber einen Server laufen. Das macht nicht nur unnoetig viel Last, sondern das gibt auch zuweilen im MySQL-Server einfach Haenger wegen des Locking (ein Prozess macht einen dicken SELECT, der 2 Minuten dauert, macht derweil ein Write-Lock, so dass andere zwar lesen, aber nicht schreiben duerfen; ein zweiter Prozess kommt und will schreiben, darf nicht, haengt in der Warteschlange; ein dritter Prozess kommt und will eigentlich nur lesen, darf aber nun auch nicht, weil der zweite Prozess erster war und schon einen Lock-Request eingequeuet hat). Wäre es nicht möglich den Write-Lock zu umgehen, indem man die Write-Requests in einem temporärem Table erledigt? Nagut, ich kenne das System nicht - gefährliches Halbwissen :) Sehe ich richtig, dass es das Ziel sein sollte, die Write-Querys zu verkürzen/teiles um das Locking effektiver zu machen? Man könnte, wenn man einen MySQL-Cluster nutzt das Ziel mit LOW_PRIORITY-Updates machen. Wenn man dann noch wenige und effektive B-Trees in der Indexierung nutzt würde das sicher viel Wirkung zeigen. Oder wird das schon gemacht? Ein sehr grosser Teil unserer Anfragen sind Lese-Requests. Die haben wir im Moment schon stark eingeschraenkt - man kann nicht mal mehr eine ganze deutsche Grossstadt auf einmal abrufen, weil so grosse Requests nicht erlaubt sind. Das ist nur ein Notanker - eigentlich waere es schoen, wenn jeder alles requesten darf, was ihn interessiert. Wir haben, damit sich keiner zu arg aergern muss, das planet file, einen Komplett-Dump aller Daten, der woechtenlich rauskommt. Jeder, der mit eine Woche alten Daten zufrieden ist, kann damit arbeiten (obwohl das auch zunehmend unhandlicher wird - eine Datenbank ist schon komfortabler als ein Riesenfile). Statt planet-File könnte man im Grunde doch durch ein Planet-Table ersetzen? Das würde das Caching und die Performace der Datenbank nutzen. Oder sehe ich das falsch, dass das Planet-File eine Art SELECT * FROM alle_tabellen ist?! Das planet file wird demnaechst vermutlich auch haeufiger kommen, oder es wird zumindest taegliche Updates dafuer geben, so dass es leichter ist, einigermassen aktuell zu blieben. Aber es ist und bleibt (finde ich) eine Kruecke. Ich skizziere mal eine Idee, die ich schon ewig mit mir rumtrage und bei jeder Gelegenheit wieder mal auf den Tisch bringe: Ich finde einen zentralen Server fuer alle Schreibrequests, einen zentralen Master, ok. (Man *koennte* durchaus auch partitionieren - der Master fuer Deutschland koennte in Deutschland stehen, und grenzueberschreitende Requests waeren dann durch geeignete Metaserver zusammenzusammeln. Hat auch viele Vorteile. Aber nehmen wir erstmal an, wir haben einen zentralen Server.) Dieser zentrale Master hat einen Slave, auf den er alle Aenderungen in Quasi-Echtzeit kopiert. Alle Lese-Requests sind von diesem Slave zu machen. Der Slave wiederum akzeptiert eine begrenzte Anzahl von Feeds. Ein Feed ist eine weitere Datenbank am Ende irgendeiner Leitung, die alle Updates oder nur bestimmte Updates geliefert bekommt. Ein Feed, der alle Updates bekommt, ist ein full feed; ein Feed koennte aber auch sagen: Ich will nur alles, was in dieser und jener Bounding box liegt (ein regionaler Feed), oder thematisch ich will nur alles, was railway=irgendwas ist. Diese Feeds koennen wiederum kaskadiert werden - wer in vor-IP-Zeiten Usenet gemacht hat, kann sich das vielleicht besser vorstellen: Nicht jeder kann einen Full-Feed von der Zentrale bekommen, aber es koennte einen Full-Feed irgendwo in Deutschland geben, an dem wiederum 10 unter-Feeds dranhaengen, und so weiter. Durch die entstehende Baumstruktur troepfeln dann Aenderungen mehr oder weniger schnell nach unten durch; letzten Endes kann jeder, ueberall auf der Welt, einen stets aktuellen OSM-Bestand von allem haben, was ihn interessiert. Wenn man nun mit JOSM oder so etwas aendert, kann man sich problemlos die Daten von einem halbwegs aktuellen Feed laden:
Re: [Talk-de] Osnabrück ist in einem Tag weit gekomm en - Frida Daten sind in OSM importiert!
On 9/24/07, Ulf Lamping [EMAIL PROTECTED] wrote: Raphael Studer schrieb: On 9/24/07, Andreas Hubel [EMAIL PROTECTED] wrote: Raphael Studer schrieb: Guten Morgen, http://www.informationfreeway.org/?lat=52.268677003321734lon=8.046990082365921zoom=12layers=B000F000 (bis die Daten im Mapnik Layer auftauchen wird's wie gewohnt noch ein paar Tage dauern) Unglaublich wie schnell etwas auf einmal gehen kann :) Mir ist aufgefallen, dass die Stadt recht gelb wirkt. Sind das alles secondary Strassen und nicht teilweise auch residential? ich tippe bei dem leichten gelb mal auf teritary (oder wie man das auch immer schreibt) Jetzt wo dus sagst :) Find trotzdem, dass es etwas gar viele von diesem Typ Strasse hat. Sind solche Strassen doch Residential. Ich tagg die jeweils so. Wenn Ihr denn mal auf die ToDo Liste unter Genaueres zum Stand der Dinge ist unter: http://wiki.openstreetmap.org/index.php/Frida zu finden. angeschaut hättet, wäre euch bestimmt mein Kommentar dazu aufgefallen ;-))) Uh, die Seite hat sich auch recht gemacht :) Hm soviel ich weiss gibts doch ein Einweg Tag (oneway=yes). Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
