Re: [Talk-de] Konzentrationslager/Arbeitserziehungslager
Zitat Mirko Küster: Darum geht es ja nicht, sondern darum, dass die Einrichtung nicht mehr existiert und das Gelände neu überbaut ist. Das wurde an anderen Beispielen diskutiert, woraus klar wurde, dass es nicht darum geht, ob einigen vielleicht die Erinnerung unangenehm wäre. Sowas wird leider gerne immer wieder überlesen, mögliche Probleme einfach ignoriert. Ich kann gerne mal den Test machen und zu Testzwecken die Muna in Espelkamp kurzzeitig wieder aufleben lassen. Wobei die dortigen Anwohner selber bestens im Bilde sind und sicherlich aus gutem Grund selbiges bis heute unterlassen haben. Gerne auch, wenn was im Archiv vorhanden, in den jeweiligen Heimatorten der Freiheit für alles und jeden Fraktion. Mal sehen wie erquickend dann das Urteil ausfällt, wenn der aktuelle Zustand in keinem Editor mehr klar erkenn- und vor allem editierbar ist. Um das ueberhaupt beurteilen zu koennen, musst du deine Daten wohl mal eintragen. Denn mir ist bis jetzt kein Fall bekannt, wo durch historische oder temporaere Objekte eine von dir postulierte massive Behinderung beim Editieren normaler Objekte aufgetreten ist. Es geht nicht im geringsten darum irgendwen irgendwas zu verbieten. Sondern um das Problem das wir hier alle irgendwie miteinander auskommen müssen und das ganze in der jetzigen Form einfach Grenzen hat, wo man schlich mal abwägen muss. Wer waegt was ab? Warum gehst du davon aus, dass Leute wie der OP vorhaben, einfach ohne Ruecksicht auf bereits vorhandene Objekte ihre Daten in den Bestand zu druecken? Was macht dich glauben, dass Leute, die bei OSM neue Dinge ausprobieren wollen, nicht genau so verantwortungsvoll und vorsichtig vorgehen, wie normale Mapper? Man braucht keine Glaskugel um festzustellen, dass wenn ich einen Ort mit dutzenden historischen Datenschichten regelrecht zukippe, die Mapper der Gegenwart unter umständen massiv behindert werden. Nein, keine Glaskugel, sondern Beispiele. Ausgang offen. Sind dort erfahrene Mapper dann könnte das nebenher vielleicht sogar funktionieren. Kann aber auch in einem Edit War enden oder in der völligen Löschung der histortischen Daten, was dann nichts weiter als vergeudete Zeit war. Du orakelst hart an der Grenze zu FUD. Die Wahrscheinlichkeit, dass jemand komplette Objekte einfach so loescht, nur weil sie ihn beim Editieren hinderlich sind, geht gegen Null. Und selbst wenn, sie sind ja nicht weg. Und wegem letzterem warte ich lieber ab. Meine Ordner und CDs laufen nicht weg. Wohl aber die Arbeitszeit, wenn man sich die Arbeit umsonst macht, weil das ganze wegen störung des aktuellen Betriebes oder Unklarheit immer mehr rausfliegt. Du moechstest also warten, bis eine fertige Loesung fuer das Problem vorliegt? Woher soll diese Loesung kommen, wenn niemand an konkreten Faellen Erfahrungen mit dieser Materie sammeln kann? Und selbst wenn trotz fehlenden Leidensdruckes sich jemand aufrafft, eine Loesung zu erarbeiten, wie ist gewaehrleistet, dass diese auch praxistauglich ist und er sich seinerseits nicht die ganze Arbeit umsonst gemacht hat? -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stadtteil- und Stadtbezirkgrenzen - wertigkeit
On Thu, Dec 17, 2009 at 04:35:48PM +0100, Jan Tappenbeck wrote: ich habe gerade die Stadtteil- und Stadtbezirksgrenzen von Lübeck erhalten und mir daraufhin die Key im Wiki angesehen. Danach gibt es folgende Level: 8 Stadtgrenze 9 Stadtbezirk 10 Stadtteil Demnach steht der Stadtbezirk über dem Stadtteil - bei uns ist es aber genau anders herum ! Der Stadtbezirk ist die kleinste Einheit. Würdet Ihr die Level jetzt so übernehmen oder auch tauschen. Die Hierarchie ist wichtiger als die Bezeichnungen. D.h. für Dich: mach es andersrum und Du kannst auf der Wiki-Seite entsprechend dokumentieren, dass es in HH anders ist. Dann noch eine Frage zu den Linien die später in einer Relation zusammengefaßt werden. Was wird den einzelnen Linien zugewiesen ? nur Boundary = administrative und der Level dann nur in der Relation ?!?!? boundary=administrative und Level sollte beides auch an die Grenz-Ways. Damit kann man nämlich die Grenzen passend zeichnen, ohne die Relationen anschauen zu müssen. Die Relationen braucht man nur, wenn man die Fläche braucht. Wenn ein Way die Grenze mehrerer Levels ist, dann wird an den Way nur der mit der niedrigsten Zahl (also der höchsten Wertigkeit) geschrieben. Weiter Tags wie Namen des Bereiches oder so gibt an den Ways nicht, dafür muss man dann an die Relation. 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] Fahrtzeiten in Staus
Marcus Wolschon schrieb: Nur hat niemand den rohen Event-Code und s zur Hand wenn er im Auto sitzt. Außerdem kann ich Glücklich sein überhaupt mal 2 oder 3 Messwerte per email zu bekommen. nur bringen Dir die Messwerte nur dann etwas, wenn Du auch weißt, wie die Verkehrsbehinderung in TMC dargestellt wurde. Weil was nutzt es, wenn Du Die Meldung bekommst: ich bin zwischen A und B 30 min in Stau gestanden und TMC meldet stockender Verkehr. War es dann Stau oder stockender Verkehr. Nochmals zu GoPal: Dort wird übrigens -per Default- überhaupt nur für Stau und stockender Verkehr ein penalty vergeben und der Wert sieht eher nach Pi mal Daumen aus. Was ich sagen will: Einen exakten Reisezeitverlust kann man -so glaube ich- nicht berechnen. Für den Anfang reichen m.E. wirklich ganz grob geschätzte penalty-Werte, die man dann in der Praxis überprüfen und verbessern kann. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] komplettes Wiki durchsuchen
Hallo Ralf, unser OSM-Wiki ist ein *Mediawiki* MediaWiki ist eine freie Webanwendung zum Betrieb eines Wikis, die ursprünglich für die freie Enzyklopädie Wikipedia entwickelt wurde. Inzwischen wird es auch für verschiedene andere Projekte der gemeinnützigen Wikimedia-Stiftung und, da es für jeden frei verfügbar ist, auch für zig-tausende anderer Projekte im Internet oder in Intranets verwendet. Es ist unter der GPL lizenziert und in der Skriptsprache PHP geschrieben. Zum Speichern der Inhalte nutzt MediaWiki die relationale Datenbank MySQL. http://www.mediawiki.org/wiki/MediaWiki/de?uselang=de *Suche* funktioniert so: 1. Suchbegriff eingeben Return 2. wenn es einen Artikel mit genau diesem Seitentitel gibt, wird dieser angezeigt 3. wenn nicht, startet die Volltextsuche im Index 3a) mit Volltext kann man die Volltextsuche auch direkt auslösen http://de.wikipedia.org/wiki/Wikipedia:Suche Gruss, Markus MoinMoin-Wiki MoinMoin-Wikis sind eine ganz andere Baustelle. Dahinter steht eine Python-SW. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] komplettes Wiki durchsuchen
Hallo, Markus wrote: *Suche* funktioniert so: 1. Suchbegriff eingeben Return 2. wenn es einen Artikel mit genau diesem Seitentitel gibt, wird dieser angezeigt Ausser wenn er Umlaute enthaelt, wie Johannes richtig bemerkte ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farmland bei Weideland (was : Bauern-/Guts-/Ausliegerhof mappen - 100%ige L ösung? )
Am 17. Dezember 2009 17:02 schrieb Bernd Wurst be...@bwurst.org: (Acker ist es erst wenn es 5 Jahre am Stück als Acker bewirtschaftet wird. Man darf eine Wiese [Dauergrünland] auch mal mit Getreide bewirtschaften, wenn es nur Zeitweise ist. Bei uns ist z.B. offiziell alles Wiese und ich werde nicht jedes Jahr die Tags ändern nur weil der eine oder andere mal ein paar Jahre Getreide anbaut.) Nennst Du mir bitte noch die Quelle oder das Umfeld aus dem diese Definition stammt? Meine Laiendefinition von Acker/Weide/Wiese wäre eine andere gewesen und ich befürchte da sind wir wieder an einem Punkt wo sich für eine Sache verschiedene Definitonen finden lassen -- je nach persönlichem Hintergrund des Mappers. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] komplettes Wiki durchsuchen
Hallo Frederik, *Suche* funktioniert so: 1. Suchbegriff eingebenReturn 2. wenn es einen Artikel mit genau diesem Seitentitel gibt, wird dieser angezeigt Ausser wenn er Umlaute enthaelt, wie Johannes richtig bemerkte ;-) Ein Test mit Düsseldorf: http://wiki.openstreetmap.org/wiki/Special:Search?search=düsseldorffulltext=Search Prioritäten der Ausgabe: (Hypothese) 1. Seiten mit Suchbegriff /als/ Titel 2. Seiten mit Suchbegriff /im/ Titel 3. (nicht mehr sortiert): - Seiten mit Suchbegriff in Infobox - Unterseiten, deren Hauptseite den Suchbegriff im Titel hat - Suchbegriff in Kapitelüberschrift - Suchbegriff im Einleitungstext - Suchbegriff im Kapiteltext - Suchbegriff im unstrukturierten Seitentext Das ü kann ich hier nicht als Übeltäter ausmachen. (fände ich auch eigenartig, denn Mediawiki arbeitet mit UTF-8) Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farmland bei Weideland (was : Bauern-/Guts-/Ausliegerhof mappen - 100%ige Lösung ? )
Am Freitag 18 Dezember 2009 11:35:09 schrieb Falk Zscheile: Nennst Du mir bitte noch die Quelle oder das Umfeld aus dem diese Definition stammt? Meine Laiendefinition von Acker/Weide/Wiese wäre eine andere gewesen und ich befürchte da sind wir wieder an einem Punkt wo sich für eine Sache verschiedene Definitonen finden lassen -- je nach persönlichem Hintergrund des Mappers. Ich kann dir so spontan keine schriftliche Quelle nennen, aber das ist die Quintessenz dessen was man nach jahrlangem Hin-und-her mit dem Landwirtschaftsamt in Ba-Wü halt so weiß. Gruß, Bernd -- frank can you help me install GTA3? knightmare first, shut down all programs you aren't using frank has quit IRC. (Quit) knightmare ... 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] Worldfile vom 16. Dezember 2009
Hallo, die, neuen Daten liegen wie immer zum Download bereit unter http://wiki.openstreetmap.org/wiki/User:Computerteddy Wer es noch nicht heute braucht, möge doch bitte auf den Spiegel auf GwdG warten, der dann morgen aktuell ist. -- Viele Grüße Computerteddy ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
On Fri, 18 Dec 2009 10:47:46 +0100, Stefan Dettenhofer (StefanDausR) o...@dentro.info wrote: Marcus Wolschon schrieb: Nur hat niemand den rohen Event-Code und s zur Hand wenn er im Auto sitzt. Außerdem kann ich Glücklich sein überhaupt mal 2 oder 3 Messwerte per email zu bekommen. nur bringen Dir die Messwerte nur dann etwas, wenn Du auch weißt, wie die Verkehrsbehinderung in TMC dargestellt wurde. Weil was nutzt es, wenn Du Die Meldung bekommst: ich bin zwischen A und B 30 min in Stau gestanden und TMC meldet stockender Verkehr. War es dann Stau oder stockender Verkehr. Schau dir die Event-Codes halt an. * Entweder ich bekomme eine Durschschnitts-Geschwindigkeit und die Länge, dann ist alles klar. * Ich bekomme eine Stau-Länge, dann muss ich mir diesen Werten rechnen. * Ich bekomme eine feste Verzögerungs-Zeit, dann ist auch alles klar. Was ich sagen will: Einen exakten Reisezeitverlust kann man -so glaube ich- nicht berechnen. Für den Anfang reichen m.E. wirklich ganz grob geschätzte penalty-Werte, die man dann in der Praxis überprüfen und verbessern kann. Ich will ja auch nichts exakt berechnen sondern einen educated guess machen. ALLES ist besser als Pi Mal Daumen. Statt in's Blaue hinein zu raten eben eine Schätzung aufgrund realer Zeiten machen. Die kann genauso daneben liegen aber sollte im Mittel besser sein. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farmland bei Weideland (was : Bauern-/Guts-/Ausliegerhof mappen - 100%ige Lösun g? )
Am Freitag 18 Dezember 2009 12:03:22 schrieb Bernd Wurst: Ich kann dir so spontan keine schriftliche Quelle nennen Nicht ganz genau das, aber die 5-Jahres-Frist findest du auch hier: http://de.wikipedia.org/wiki/Gr%C3%BCnland#Dauergr.C3.BCnland.2C_Wiese.2C_Weide Nochmal zur Klarstellung meiner Intention: Es gibt sicher regional verschiedene Festlegungen für diese Unterscheidung. Allerdings möchte ich stark appellieren, dass man keine Pseudo-Genauigkeit einträgt. Ob etwas landwirtschaftliche Fläche ist, sieht man i.A. Wenn man sich minimal auskennt, weiß man auch ob etwas eine Dauer-Weidefläche ist oder nicht (Holzpfosten macht man nicht so zum Spaß in die Erde). Aber grade wenn es darum geht, Wiesen und Äcker auseinander zu halten sollte man nicht zu naiv drangehen und im Zweifel lieber nur das mappen was man weiß. Was ich sagen will: Bitte keine Details mappen die absehbar in Kürze wieder ungültig sind. Gruß, Bernd -- Von all den Dingen, die mir verloren gegangen sind, habe ich am meisten an meinem Verstand gehangen. - Ozzy Osbourne (engl. Schauspieler und Musiker) 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] Stadtteil- und Stadtbezirkgrenzen - wertigkeit
Jan Tappenbeck schrieb: Moin ! ich habe gerade die Stadtteil- und Stadtbezirksgrenzen von Lübeck erhalten und mir daraufhin die Key im Wiki angesehen. Danach gibt es folgende Level: 8 Stadtgrenze 9 Stadtbezirk 10 Stadtteil Demnach steht der Stadtbezirk über dem Stadtteil - bei uns ist es aber genau anders herum ! Der Stadtbezirk ist die kleinste Einheit. Würdet Ihr die Level jetzt so übernehmen oder auch tauschen. Dann noch eine Frage zu den Linien die später in einer Relation zusammengefaßt werden. Was wird den einzelnen Linien zugewiesen ? nur Boundary = administrative und der Level dann nur in der Relation ?!?!? Gruß Jan :-) Ich muss die Frage 2 nochmal etwas ausweiten ! einigen Stadtbezirke sind gleichzeitig auch Stadtteil. = nur eine Boundary mit dem höchsten Status ? = zwei mit unterschiedlichen Levels ? = ??? Wie würdet Ihr das machen ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] landuse=farmland bei Weideland
Hi Johann, landuse=farmland (die Flächen). Wobei ich mir dafür eine weitere Attributierung wünsche, um zwischen Acker-, Weideland unterscheiden zu können. gibts doch: # landuse=farm (beige dargestellt in mapnik), das ist eine Vorstufe, wenn nichts Näheres bekannt ist. landuse=farmland (dargestellt?) - steht das in der tagwatch? Gefunden habe ich, gleichwertig (da auch merhdeutig) und besser da kürzer =farm ansonsten: # landuse=meadow (grün dargestellt in mapnik) - bei Weideland (artenreicher) # landuse=grass (grün dargestellt in mapnik wie meadow) selten verwandt, für Intensivgrünland (also häufigere Neueinsaat, daher weniger Grasarten - heute in N/M-Eu verbreiteter) bleibt / fehlt eine explizite Bezeichnung für Acker oder Feldfrüchte: # landuse=field (braun dargestellt in mapnik) gibt noch :agriculture (nicht dargestellt in mapn.) # landuse=orchard - Fruchtgehölze (dargestellt?) + trees=apple_trees ... # ... landuse=farmyard (der Hof) ... landuse hat eine Nähe zu Ertrag/Bewirtschaftung (regelmäßige Eingriffe) natural zur natürlichen Ausstattung/Betrachtung (selten/kaum direkter menschl. Einfluß) - z.B. natural:meadow (nicht dargestellt in mapnik), was wäre das? Almweide, Biberwiese, Lichtung, Salzwiese am Watt - bzw. nach der Begrifflichkeit -weide? Auch wenn nicht NICHT vorschlage, Weiden und Wiesen zukünftig im Mapnik grün zu rendern (wir haben schon genug Grün-Töne), aber das satte Braun von Farmland lässt doch Skrupel aufkommen, das überhaupt zu mappen. Malste ein Bild? ;-) Die Fähigkeiten der software/Renderer mapnik etc. hat nichts draußen zu tun ... viele Grüße, t. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPS Trackingpunkte aus einer DB importieren
Hallo zusammen, ich bin noch relativ neu hier und äußere deshalb einfach mal direkt meine Frage: Ich bin einem Unternehmen tätig, welches eine Telematiksoftware entwickelt. Wir würden gerne etwas zu dem OSM Projekt beitragen. Nach Absprache mit unseren Kunden hätten wir die Möglichkeit sämtliche von uns aufgezeichneten Trackingpunkte (leider keine kompletten Tracks) zur Verfügung zu stellen. Durch die Häufigkeit mit der unsere Kunden, beziehungsweise deren Fahrzeuge die Strecken abfahren haben wir eine große Dichte der einzelnen Punkte. Nun bin ich auf der Suche nach einer API oder einem Ansprechpartner mit dem man ein solches Projekt durchsprechen könnte. Viele Grüße aus Heitersheim Benjamin Rheinberger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stadtteil- und Stadtbezirkgrenzen - wertigkeit
On Fri, 18 Dec 2009 13:04:48 +0100, Jan Tappenbeck o...@tappenbeck.net wrote: einigen Stadtbezirke sind gleichzeitig auch Stadtteil. = nur eine Boundary mit dem höchsten Status ? = zwei mit unterschiedlichen Levels ? = ??? Wie würdet Ihr das machen ? nur eine Boundary mit dem höchsten Status Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzentrationslager/Arbeitserziehungslager
Um das ueberhaupt beurteilen zu koennen, musst du deine Daten wohl mal eintragen. Denn mir ist bis jetzt kein Fall bekannt, wo durch historische oder temporaere Objekte eine von dir postulierte massive Behinderung beim Editieren normaler Objekte aufgetreten ist. Das ist zum Glück noch nicht das große Thema, weil eben bisher nachgedacht und nicht einfach massiv ausgekippt wurde. Wir können den Test aber gerne mal machen. Obwohl ich es ehrlich gesagt erstaunlich finde, dass in dich gemappten Ecken mehrere Schichten Linien übereinender und Nodewolken nicht stören sollen. Mutige Behauptung. Wer waegt was ab? Warum gehst du davon aus, dass Leute wie der OP vorhaben, einfach ohne Ruecksicht auf bereits vorhandene Objekte ihre Daten in den Bestand zu druecken? Was macht dich glauben, dass Leute, die bei OSM neue Dinge ausprobieren wollen, nicht genau so verantwortungsvoll und vorsichtig vorgehen, wie normale Mapper? Diese verantwortungsvolle Vorgehensweise setze ich ja gerade voraus. Deswegen sage ich ja aufpassen und nicht mach mal, das gibt nirgends und nie Probleme. Du orakelst hart an der Grenze zu FUD. Die Wahrscheinlichkeit, dass jemand komplette Objekte einfach so loescht, nur weil sie ihn beim Editieren hinderlich sind, geht gegen Null. Und selbst wenn, sie sind ja nicht weg. Ich orakele nicht sondern Mappe viel und überall, sehr detailreich, bekomme entsprechendes auch mit. Es gibt Leute die beispielsweise Landuses kicken, weil es sie bei Luftbildern behindert. Auch ansonsten bleibt lange nicht alles stehen. Und natürlich sind die Sachen noch in der History, aber die gleich wieder zurück zu holen endet unter umständen im Sinnlosen Editwars und ist auch bei nicht einfach zurückstellbaren Einzelnodes eher sinnlose Zeitverschwendung. Du moechstest also warten, bis eine fertige Loesung fuer das Problem vorliegt? Woher soll diese Loesung kommen, wenn niemand an konkreten Faellen Erfahrungen mit dieser Materie sammeln kann? Und selbst wenn trotz fehlenden Leidensdruckes sich jemand aufrafft, eine Loesung zu erarbeiten, wie ist gewaehrleistet, dass diese auch praxistauglich ist und er sich seinerseits nicht die ganze Arbeit umsonst gemacht hat? Die Leier mit dem Leidensdruck. Leidensdruck haben wir in vielen Bereichen und das garantiert leider auch nicht das eine Lösung kommt. Für das Problem muss man auch nicht erst die Daten versauen. Das Problem sind meherere Objekte übereinander die man trennen muss. Dazu müsste beispielsweise ein noch nicht existenter Namensraum erfunden werden. Male dir einfach 5 Gebäudeformen übereinander und du hast ein Beispiel an dem du üben kannst. Im Moment gibts in der Richtung null komma nichts, nichtmal eigene Tags. Alte Straßen müsste man entweder mit dem vorhandenem taggen, wass sie aber auch in der Karte sichtbar macht oder ohne Haupttag lassen. Beides murks. Deswegen warten bis sich Fachleute mal dem Thema annahmen und dann kann man auch sinnvoll loslegen. Hier springen soviele Studenten herum, da sind sicher auch interessierte dabei die in Geschichte und Archäologie fit sind und noch die eine oder andere Idee hätten. So lange rede kurzer Sinn. Ich werde mich jetzt mal dran machen und ein Beispiel mit vorhandenen Tags aus einem Teil von Espelkamp machen. Mal sehen wie lange das stehen bleibt. So ein Rangierbahnhof auf der Hauptstraße dürfte sicher keinen stören. lol Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren
Rheinberger, Benjamin brheinber...@couplink.net wrote: Nach Absprache mit unseren Kunden hätten wir die Möglichkeit sämtliche von uns aufgezeichneten Trackingpunkte (leider keine kompletten Tracks) zur Verfügung zu stellen. Ich würde sowit gehen zu behaupten, dass Punkte ohne Reihenfolge für das Projekt nutzlos sind. Konkret können wir mit soetwas durchaus etwas anfangen (linien sind aus der Reihenfolge abgeleitet): 33 | 1--2--3... | 34 Damit: X X X X X Aber überhaupt nichts Bevor wir zur konkrten Realisierung kommen stellt sich also die Frage welchen Typ von Daten du uns anbieten kannst. Gruss Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /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] Konzentrationslager/Arbeitserziehungslager
Hallo, Michael Buege wrote: Man braucht keine Glaskugel um festzustellen, dass wenn ich einen Ort mit dutzenden historischen Datenschichten regelrecht zukippe, die Mapper der Gegenwart unter umständen massiv behindert werden. Nein, keine Glaskugel, sondern Beispiele. Michael hat recht, wenn er sagt, dass es in OSM noch nie ueblich war, mit der Erfassung von irgendwelchen Daten zu warten, bis irgendein Renderer irgendwas unterstuetzt. Das geht meiner Ansicht nach so lange gut, wie man die on the ground rule befolgt - solang man Sachen mappt, die im entferntesten heute noch sichtbar sind. Da wuerde ich auch jedem empfehlen: Macht einfach. Wenn wir uns in einen Bereich begeben, wo die on the ground rule nicht mehr beachtet wird, wo also Dinge gemappt werden, die vielleicht vor langer Zeit mal da waren, aber jetzt nicht mehr da sind, dann muss ich Mirko recht geben, wenn er vor Problemen warnt. Ich selbst habe das mal in Gedanken mit dem alten Rom durchgespielt. Ich habe zu Hause einen Stadtplan von Rom zur Zeit Caesars haengen. Einige der Gebaeude auf diesem Plan gibt es heute noch, und einige der Strassen sogar; aber die allermeisten Gebaeude sind heute nicht mal mehr in Form von Ruinen existent, und Strassen und Wege heute nicht mehr erkennbar. Zeichnete ich diese ein, so liefen sie in der Tat quer durch heutige Wohnbebauung. Ich muesste sogar beim Einzeichnen vorsichtig sein, dass mein Editor nicht versehentlich einen geminsamen Node zwischen einer historischen Strasse und einem heutigen Gebaeudegrundriss erzeugt (ausser, wenn es an der Stelle tatsaechlich Grund zu der Annahme gibt, dass beide zusammenhaengen). OSM hat kaum Regeln, und schon gar keine festgeschriebenen, aber die on the ground rule ist schon eine ziemlich weit verbreitete Norm. Natuerlich wird von ihr bereits abgewichen, z.B. beim Mapping von Grenzen, aber eine flaechige Eintragung von Kartendaten des Altertums koennte hier tatsaechlich den Rahmen sprengen. Andererseits, und da hat Michael wieder einen guten Punkt, wuerde, wenn ich das alte Rom einzeichnete, eventuell der eine oder andere Hobbyhistoriker auf den Plan gerufen, um antike Karten aus OSM zu zeichnen, und die Editor-Entwickler wuerden sich, wenn auch vielleicht etwas schimpfend, an die Arbeit machen, dafuer zu sorgen, dass meine historischen Daten niemanden stoeren... Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren
Wir können die Punkte in der Reihenfolge zur Verfügung stellen in der sie abgefahren wurden. Hier mal grob zusammengefasst welche Infos wir mit übermitteln können: TRACKINGID DATETIMELATITUDELONGITUDE DIRECTION SPEED Wir benutzen diese Punkte auch um die Fahrspuren in eine Karte zu zeichnen. Dass die Spuren noch nachbearbeitet werden müssten ist klar, jedoch dürften wir so eine gute Grundlage erzeugen können oder was meint ihr? -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von Sven Geggus Gesendet: Freitag, 18. Dezember 2009 14:44 An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren Rheinberger, Benjamin brheinber...@couplink.net wrote: Nach Absprache mit unseren Kunden hätten wir die Möglichkeit sämtliche von uns aufgezeichneten Trackingpunkte (leider keine kompletten Tracks) zur Verfügung zu stellen. Ich würde sowit gehen zu behaupten, dass Punkte ohne Reihenfolge für das Projekt nutzlos sind. Konkret können wir mit soetwas durchaus etwas anfangen (linien sind aus der Reihenfolge abgeleitet): 33 | 1--2--3... | 34 Damit: X X X X X Aber überhaupt nichts Bevor wir zur konkrten Realisierung kommen stellt sich also die Frage welchen Typ von Daten du uns anbieten kannst. Gruss Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren
Hallo, Sven Geggus wrote: Ich würde sowit gehen zu behaupten, dass Punkte ohne Reihenfolge für das Projekt nutzlos sind. Das stimmt nicht. Richtig ist, dass Punkte mit Reihenfolge einen hoeheren Wert haben. Aber auch ohne Reihenfolge kann man aus Punkten ein Strassennetz ableiten (wenn sie dicht genug sind). Lade mal in JOSM die GPS-Tracks von einer Stadt und schalte die Linien zwischen den Punkten aus, das ist doch immer noch nicht schlecht! Ferner koennen selbst dann, wenn die Punkte nicht dicht sind, sondern z.B. nur im Minutentakt aufgenommen wurden, aus einer grossen Punktmenge Rueckschluesse gezogen werden: Da ist ein GPS-Punkt - also muss da auch irgendwie eine Strasse sein - wenn OSM da keine hat, ist OSM offenbar unvollstaendig. Auch das kann fuer uns eine wertvolle Information sein, besonders wenn jemand eine groessere Menge solcher Punkte fuer uns hat. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzentrationslager/Arbeitserziehungslager
Michael hat recht, wenn er sagt, dass es in OSM noch nie ueblich war, mit der Erfassung von irgendwelchen Daten zu warten, bis irgendein Renderer irgendwas unterstuetzt. Ob das üblich ist oder nicht ist Wurscht. Es geht darum nicht auf Teufel komm raus jeden Mist in die DB zu drücken und damit anderen eventuell das Leben schwer zu machen. Das muss nicht sein. Das geht meiner Ansicht nach so lange gut, wie man die on the ground rule befolgt - solang man Sachen mappt, die im entferntesten heute noch sichtbar sind. Da wuerde ich auch jedem empfehlen: Macht einfach. Darum gehts doch die ganze Zeit überhaupt nicht, das war unbestritten. Ich schreibe jetzt schon zum 5 mal, dass es eben um Dinge geht, die man heute nicht mehr sieht, weil das Gelände eben schon lange überbaut ist. Das hat zur Folge das man x Schichten Geschichte übeinander legen muss, was definitiv in der jetzigen Form suboptimal ist und stört. Andererseits, und da hat Michael wieder einen guten Punkt, wuerde, wenn ich das alte Rom einzeichnete, eventuell der eine oder andere Hobbyhistoriker auf den Plan gerufen, um antike Karten aus OSM zu zeichnen, und die Editor-Entwickler wuerden sich, wenn auch vielleicht etwas schimpfend, an die Arbeit machen, dafuer zu sorgen, dass meine historischen Daten niemanden stoeren... Und damit es was zum abwägen gibt, nagele ich gerade die Muna über Espelkamp. Ich machs so das man es gleich wieder entfernen kann und so das nichts vorhandenes berührt wird, eben ohne möglichen Schaden. Ich möchte damit nur mal zeigen das es so eben nicht so einfach geht und die Verfechter der allumfassenden Freiheit sich mal ein Auge holen können. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren
Moin, Sven Geggus schrieb: Rheinberger, Benjamin brheinber...@couplink.net wrote: Nach Absprache mit unseren Kunden hätten wir die Möglichkeit sämtliche von uns aufgezeichneten Trackingpunkte (leider keine kompletten Tracks) zur Verfügung zu stellen. Ich würde sowit gehen zu behaupten, dass Punkte ohne Reihenfolge für das Projekt nutzlos sind. ich denke, Du betrachtest das in einem zu großen Maßstab. Die GPS-Spuren, die sich z. B. in JOSM vom Server laden lassen, haben auch keine Reihenfolge mehr - trotzden lassen sich - in diesem Fall unter der Voraussetzung, das es sich um Kfz handelt - aus den Daten zumindest highway= roads ermitteln. Natürlich nur in einem kleineren Maßstab, aber überland könnte das evtl. zumindest die eine oder andere Lücke ansatzweise überbrücken. Eine Vorab-Begutachtung der Daten halte ich aber auch für erforderlich. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren
Hallo, Georg Feddern wrote: Die GPS-Spuren, die sich z. B. in JOSM vom Server laden lassen, haben auch keine Reihenfolge mehr Das wiederum ist auch nicht korrekt; zwar sind theoretisch hier Punkte aus verschiedenen Spuren durcheinandergewuerfelt, aber alle sind immer noch streng aufsteigend nach Timestamp sortiert, so dass sich in den allermeisten Faellen die korrekte Reihenfolge einstellt. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren
Rheinberger, Benjamin brheinber...@couplink.net wrote: Hier mal grob zusammengefasst welche Infos wir mit übermitteln können: TRACKINGID DATETIMELATITUDELONGITUDE DIRECTION SPEED Wir benutzen diese Punkte auch um die Fahrspuren in eine Karte zu zeichnen. Das ist doch super. Mehr hat der Durchschnittsmapper meist auch nicht zur Verfügung. Abgesehen von den zusätzlichen Waypoimts und Notizen natürlich :) Klingt für mich so als ob die Daten relativ problemlos in GPX Tracks konvertierbar sind. Letztere wiederum kann man direkt auf unsere Server hochladen! Gruss Sven -- C is quirky, flawed, and an enormous success (Dennis M. Ritchie) /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] Fahrtzeiten in Staus
Original-Nachricht Datum: Thu, 17 Dec 2009 07:22:42 +0100 Von: Marcus Wolschon mar...@wolschon.biz An: talk-de@openstreetmap.org Betreff: [Talk-de] Fahrtzeiten in Staus Mit der Weihnachtszeit stehen auch wieder sie Staus an. Nachdem ich in der vergangenheit ein wenig mit dem Thema Staus und Reisezeitschaetzung verbandelt war, ein wenig Senf von mir dazu: Bei der Reisezeitschaetzung hat man zwei unterschiedliche Datenquellen. Zum einen die klassische Methode ueber Querschnitte, also die Induktionsschleifen oder andere Detektoren die die Bewegungen ueber einen Querschnitt zaehlen. Die zweite und modernere Methode ist das 'floating car' also das Fz, das im Verkehr mitschwimmt und dabei Statusmeldungen abgibt. Bei der Querschnittserfassung gibts zwar massig staatlich erhobener Daten, auch dank der Streckenbeeinflussungen (Schilderbruecken mit variablem Tempolimit), die wie Pilze aus dem Boden spriessen. Allerdings ist die Reiszeitschaetzung ueber diese Daten nicht besonders genau, da man nur lokale Effekte messen kann, ein Stau aber ein Effekt ist, der irgendwo dazwischen beginnen und enden kann. Meine Erfahrungen mit den entsprechenden Methoden waren jedenfalls nicht das gelbe vom Ei. Frueher wurde die TMC-Daten fast ausschliesslich ueber diese Daten erhoben oder noch schlimmer ueber die beruehmte Schaetzung der Polizei vor Ort, die auch so in den verkehrsmeldungen rueberkommt. Entsprechend duenn ist (war?) die Aussagekraft. Die Navihersteller wollen verkaufen und wurschteln das rein, so gut wies eben geht. Gemeinerweise kann man ja immer nur eine Route gleichzeitig fahren und erfaehrt so selten, ob die andere schneller gewesen waere ;) Nun zur zweiten Erfassungsmethode, die Floating cars. Leider bin ich nicht mehr in diesem Geschaeft und weiss nicht wie sich das entwickelt hat. Grundsaetzlich gibts aber ein ziemliches Problem, Floatingcar-Daten oeffentlich zu erheben und verfuegbar zu machen. Wir haben damals schon einiges damit gemacht, z.B. mit Taxiflotten, die die Daten online Kommunen zur Verfuegung gestellt haben, aber da gibts natuerliche Grenzen. Das geniale dran ist, dass man im Idealfall ein exaktes Profil des Staus bekommt und auch exakt den Zeitverlust (gemessene Fahrtdauer abzueglich Standardfahrzeit). Klar gibts da auch Fehlerquellen, aber die lassen sich eigentlich ganz gut filtern. Ich denke, wenn man schon Staus vergleicht, sollte man versuchen, das auf eine moeglichst objektive Basis zu stellen. Da viele von uns ein GPS haben und auch so manches mittracken, gibts auch immer mal einen Track, der einen Stau beschreibt. Diese Tracks waeren eine tolle Ergaenzung zu den einfachen Stauberichten, die hier vorgeschlagen werden. Gruesse Hubert -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
So ein Track wäre natürlich Genial. Super Idee. Marcus On 2009-12-18, qbert biker qbe...@gmx.de wrote: Original-Nachricht Datum: Thu, 17 Dec 2009 07:22:42 +0100 Von: Marcus Wolschon mar...@wolschon.biz An: talk-de@openstreetmap.org Betreff: [Talk-de] Fahrtzeiten in Staus Mit der Weihnachtszeit stehen auch wieder sie Staus an. Nachdem ich in der vergangenheit ein wenig mit dem Thema Staus und Reisezeitschaetzung verbandelt war, ein wenig Senf von mir dazu: Bei der Reisezeitschaetzung hat man zwei unterschiedliche Datenquellen. Zum einen die klassische Methode ueber Querschnitte, also die Induktionsschleifen oder andere Detektoren die die Bewegungen ueber einen Querschnitt zaehlen. Die zweite und modernere Methode ist das 'floating car' also das Fz, das im Verkehr mitschwimmt und dabei Statusmeldungen abgibt. Bei der Querschnittserfassung gibts zwar massig staatlich erhobener Daten, auch dank der Streckenbeeinflussungen (Schilderbruecken mit variablem Tempolimit), die wie Pilze aus dem Boden spriessen. Allerdings ist die Reiszeitschaetzung ueber diese Daten nicht besonders genau, da man nur lokale Effekte messen kann, ein Stau aber ein Effekt ist, der irgendwo dazwischen beginnen und enden kann. Meine Erfahrungen mit den entsprechenden Methoden waren jedenfalls nicht das gelbe vom Ei. Frueher wurde die TMC-Daten fast ausschliesslich ueber diese Daten erhoben oder noch schlimmer ueber die beruehmte Schaetzung der Polizei vor Ort, die auch so in den verkehrsmeldungen rueberkommt. Entsprechend duenn ist (war?) die Aussagekraft. Die Navihersteller wollen verkaufen und wurschteln das rein, so gut wies eben geht. Gemeinerweise kann man ja immer nur eine Route gleichzeitig fahren und erfaehrt so selten, ob die andere schneller gewesen waere ;) Nun zur zweiten Erfassungsmethode, die Floating cars. Leider bin ich nicht mehr in diesem Geschaeft und weiss nicht wie sich das entwickelt hat. Grundsaetzlich gibts aber ein ziemliches Problem, Floatingcar-Daten oeffentlich zu erheben und verfuegbar zu machen. Wir haben damals schon einiges damit gemacht, z.B. mit Taxiflotten, die die Daten online Kommunen zur Verfuegung gestellt haben, aber da gibts natuerliche Grenzen. Das geniale dran ist, dass man im Idealfall ein exaktes Profil des Staus bekommt und auch exakt den Zeitverlust (gemessene Fahrtdauer abzueglich Standardfahrzeit). Klar gibts da auch Fehlerquellen, aber die lassen sich eigentlich ganz gut filtern. Ich denke, wenn man schon Staus vergleicht, sollte man versuchen, das auf eine moeglichst objektive Basis zu stellen. Da viele von uns ein GPS haben und auch so manches mittracken, gibts auch immer mal einen Track, der einen Stau beschreibt. Diese Tracks waeren eine tolle Ergaenzung zu den einfachen Stauberichten, die hier vorgeschlagen werden. Gruesse Hubert -- Preisknaller: GMX DSL Flatrate für nur 16,99 Euro/mtl.! http://portal.gmx.net/de/go/dsl02 ___ 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] Fahrtzeiten in Staus
On Thu, Dec 17, 2009 at 07:22:42AM +0100, Marcus Wolschon wrote: Warum? Im mit den neuen TMC-Verkehrsmeldungen auch sinnvolle Navigations- Entscheidungen treffen zu können muss halt die Geschwindigkeit durch einen Stau vorhergesagt werden. Schliesslich ist es nicht immer Sinnvoll jeden kleinen Hänger zu umfahren. Die Geschwindigkeit 0 wäre eine ziemlich falsche Annahme und ich würde ungern raten, wo es kein Problem ist echte Messwerte zu sammeln. Die Ergebnisse werden dann im Wiki für alle die hier Routen-Berechnung oder Navigation machen veröffentlicht. Aber steht nicht in den TMC meldungen genau die zu erwartende verzoegerung in Minuten? Zumindest erinnere ich mich da an was. Flo -- Florian Lohoff f...@rfc822.org Es ist ein grobes Missverständnis und eine Fehlwahrnehmung, dem Staat im Internet Zensur- und Überwachungsabsichten zu unterstellen. - - Bundesminister Dr. Wolfgang Schäuble -- 10. Juli in Berlin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] gelöschtes Element fehlt beim Zugriff über die API
Hi, ich habe versucht die XML-Version eines gelöschen Elementes herunterzuladen. Aber zu sehen bekomme ich nichts. z.B. Dieser Weg in der Webansicht http://www.openstreetmap.org/browse/way/26802382 Bzw. über die API: http://www.openstreetmap.org/api/0.6/way/26802382 Oder mit wget über die API: ~ wget http://www.openstreetmap.org/api/0.6/way/26802382 --2009-12-18 17:12:33-- http://www.openstreetmap.org/api/0.6/way/26802382 Auflösen des Hostnamen »www.openstreetmap.org« 128.40.168.98 Verbindungsaufbau zu www.openstreetmap.org|128.40.168.98|:80... verbunden. HTTP Anforderung gesendet, warte auf Antwort... 410 Gone 2009-12-18 17:12:33 FEHLER 410: Gone. Gibt es eine andere Möglichkeit über die api auf ein gelöschtes Objekt zuzugreifen? Die gesamte Historie eines Objektes will ich nicht herunterladen. Ich bin an der Versionsnummer und dem Löschdatum des gelöschten Objektes interessiert. Grüße Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Trackingpunkte aus einer DB importieren
Nach Absprache mit unseren Kunden hätten wir die Möglichkeit sämtliche von uns aufgezeichneten Trackingpunkte (leider keine kompletten Tracks) zur Verfügung zu stellen. sofern die Punkte auch die Höhe enthalten: waere das nicht etwas für eine Höhenkarte? Da wollte doch auch schon mal jemand ran. Gruß, Schusch___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API
Werner Hoch wrote: Hi, ich habe versucht die XML-Version eines gelöschen Elementes herunterzuladen. Aber zu sehen bekomme ich nichts. Ist ja auch logsich, es ist gelöscht und es gibt nichts mehr zu sehen. Gibt es eine andere Möglichkeit über die api auf ein gelöschtes Objekt zuzugreifen? WO nichts ist da kann man auch nichts runterladen. Aber Du kannst eine alte Version herunterladen : http://www.openstreetmap.org/api/0.6/way/26802382/9 das ist Version9, wo das Objekt noch nicht gelöscht war. und das ist die Version die gelöscht wurde : http://www.openstreetmap.org/api/0.6/way/26802382/10 Matthias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API
Am Freitag 18 Dezember 2009 17:24:27 schrieb Werner Hoch: ich habe versucht die XML-Version eines gelöschen Elementes herunterzuladen. Aber zu sehen bekomme ich nichts. z.B. Dieser Weg in der Webansicht http://www.openstreetmap.org/browse/way/26802382 Bzw. über die API: http://www.openstreetmap.org/api/0.6/way/26802382 Oder mit wget über die API: ~ wget http://www.openstreetmap.org/api/0.6/way/26802382 --2009-12-18 17:12:33-- http://www.openstreetmap.org/api/0.6/way/26802382 Auflösen des Hostnamen »www.openstreetmap.org« 128.40.168.98 Verbindungsaufbau zu www.openstreetmap.org|128.40.168.98|:80... verbunden. HTTP Anforderung gesendet, warte auf Antwort... 410 Gone 2009-12-18 17:12:33 FEHLER 410: Gone. Gibt es eine andere Möglichkeit über die api auf ein gelöschtes Objekt zuzugreifen? Die gesamte Historie eines Objektes will ich nicht herunterladen. Musst du aber. Eine Löschung ist eine neue Version des Objekts mit visible=false im XML. In dieser neuesten Version fehlen dann auch alle Tags. d.h. was dich vermutlich interessiert ist die zweitneueste Version, nämlich die letzte mit Sinn. Und die ist in der History drin. http://www.openstreetmap.org/api/0.6/way/26802382/history Ich bin an der Versionsnummer und dem Löschdatum des gelöschten Objektes interessiert. Das steht in dem XML ganz unten. Gruß, Bernd -- Wenn du kritisiert wirst, dann mußt du irgendetwas richtig machen. Denn nur derjenige wird angegriffen, der den Ball hat. 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] Koordinaten aus Ort abfragen
Moin ! gibt es irgendwo einen Geocoder um eine Adresse für OSM zu suchen die man über eine Art API nutzen kann ?? Gruß Jan .-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] doppelte entities nach diff-update mit osmosis verhindern
Hallo zusammen! ich versuche, einen Ausschnitt aus dem planet-File mit hourly diffs zu aktualisieren: osmosis --rci workingDirectory=/pfad/verz --rx alt.osm --ac --bb left=1 top=2 right=3 bottom=4 idTrackerType=BitSet completeWays=yes completeRelations=yes --wx neu.osm Das läuft auch fehlerfrei durch. Allerdings finde ich im Ergebnisfile die geänderten nodes/ways/relations mehrfach, nämlich in alter und neuer Version (unterscheidbar durch version-Attribut und timestamp). Ich nehme einmal an, daß das beabsichtigtes Verhalten ist(?) Kann ich osmosis dazu bringen, von allen entities nur die jeweils letzte Version auszugeben? danke für den Tip, lG Harald ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API
Hallo Bernd, On Freitag, 18. Dezember 2009, Bernd Wurst wrote: Gibt es eine andere Möglichkeit über die api auf ein gelöschtes Objekt zuzugreifen? Die gesamte Historie eines Objektes will ich nicht herunterladen. Musst du aber. Eine Löschung ist eine neue Version des Objekts mit visible=false im XML. In dieser neuesten Version fehlen dann auch alle Tags. Das ist ok. Mich interessieren dieselben infos, die ich auch übers Webfrontend sehe. d.h. was dich vermutlich interessiert ist die zweitneueste Version, nämlich die letzte mit Sinn. Und die ist in der History drin. Ja, mich wird meistens die zweitneueste interessieren. Dazu benötige ich aber die Versionsnummer der neuesten, gelöschten Version. http://www.openstreetmap.org/api/0.6/way/26802382/history Ich bin an der Versionsnummer und dem Löschdatum des gelöschten Objektes interessiert. Das steht in dem XML ganz unten. Das habe ich gesehen. Ich will aber nicht eine ganze Historie runterladen, nur um an das Löschdatum und die Versionsnummer zu kommen. Bei Objekten mit sehr vielen Versionen dauert das u.U. zu lange. ggf. könnte ich durch bisecting solange die Versionen durchprobieren, bis ich die richtige Version gefunden habe. Das wäre aber eher subobtimal. Ich will mir ein Skript schreiben mit dem ich einen Weg oder eine Relation zu einem bestimmten Datum herunterladen kann. z.B. einen Tag vor der Löschung, ... Grüsse Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API
Hallo Matthias, On Freitag, 18. Dezember 2009, Matthias Versen wrote: ich habe versucht die XML-Version eines gelöschen Elementes herunterzuladen. Aber zu sehen bekomme ich nichts. Ist ja auch logsich, es ist gelöscht und es gibt nichts mehr zu sehen. Übers Webfrontend kann ich noch auf die gelöschte Version zugreifen. Die Information ist also immer noch da. Gibt es eine andere Möglichkeit über die api auf ein gelöschtes Objekt zuzugreifen? WO nichts ist da kann man auch nichts runterladen. Aber Du kannst eine alte Version herunterladen : http://www.openstreetmap.org/api/0.6/way/26802382/9 das ist Version9, wo das Objekt noch nicht gelöscht war. Woher soll ich wissen welche Version die vorletzte ist und wann die Löschung stattgefunden hat? Grüsse Werner ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Koordinaten aus Ort abfragen
Am 18. Dezember 2009 17:54 schrieb Jan Tappenbeck o...@tappenbeck.net: Moin ! gibt es irgendwo einen Geocoder um eine Adresse für OSM zu suchen die man über eine Art API nutzen kann ?? http://wiki.openstreetmap.org/wiki/Namefinder#XML_interface Gruß Jan .-) Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzentrationslager/Arbeitserziehungslager
So jetzt haben wir eine Spielwiese zum testen. http://www.openstreetmap.org/?lat=52.379lon=8.6247zoom=14layers=B000FTF http://www.openstreetmap.org/browse/changeset/3403956 Ich wollte die Daten erst so hochladen, habe dann aber allen Schlüsseln ein historic: vorangestellt, um den dortigen Mappern wenigstens das Rendering nicht auch noch zu versauen. Wer einen eigenen Renderer betreibt muss nur nach diesen Schlüsseln filtern und diese zum Rendern entfernen. Ich habe jetzt nur das wichtigste im Kernbereich erfasst. Die Details und Außenlager habe ich erstmal gelassen. Möglich wäre noch bis auf Versorgungsleitungsebene. Dazu käme noch der damalig dichte Waldbewuchs auf dem Gelände. Unabhängig davon sind die Daten der Gegenwart auch noch nicht wirklich dicht. Man stelle sich dazu noch alle Häuser und POI usw. vor. Ich denke aber mal das es so reicht, um sich ein Bild zu machen, ob und wie das nun stören könnte oder nicht. Ich bin auf die Meinungen gespannt, auch darauf ob das so stehen bleibt und wieviele böse Mails ich morgen bekomme. Vielleicht nimmt sich unabhängig davon auch mal ein Macher an, gequatscht wurde eigentlich genug. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] gelöschtes Element fehlt beim Zugriff über die API
Werner Hoch wrote: Ich will mir ein Skript schreiben mit dem ich einen Weg oder eine Relation zu einem bestimmten Datum herunterladen kann. z.B. einen Tag vor der Löschung, ... Und das Objekt selbst (ID) ist bekannt? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Leih-GPS Material gesucht
Jonas Stein schrieb: Hat jemand schonmal ein Tutorial zur Bedienung geschrieben/gefilmt? Hat jemand ein Formular zur Ausgabe erstellt? Weder noch. Was ich aber sagen kann ist, dass die Leih-GPS mit einer Anleitung kommen. Allerdings ist die auch nur begrenzt. Und ein paar notwendige/empfehlenswerte Einstellungen der GPS sind evtl nicht enthalten. Grüße, Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrtzeiten in Staus
marcus.wolsc...@googlemail.com schrieb: Was ich sagen will: Einen exakten Reisezeitverlust kann man -so glaube ich- nicht berechnen. Für den Anfang reichen m.E. wirklich ganz grob geschätzte penalty-Werte, die man dann in der Praxis überprüfen und verbessern kann. Ich will ja auch nichts exakt berechnen sondern einen educated guess machen. ALLES ist besser als Pi Mal Daumen. Statt in's Blaue hinein zu raten eben eine Schätzung aufgrund realer Zeiten machen. Die kann genauso daneben liegen aber sollte im Mittel besser sein. Die Stauursache dürfte die interessanter Information sein - 5km Stau bei geräumter Unfallstelle lässt im Gegensatz zu einer Neumeldung LKW-Unfall mit Gefahrenguttransportere einen deutlich zurückgehenden Reisezeitverlust erwarten. Die einfachen Staumeldungensn kann man eigentlich nur mit guter Orts- und Ereigniskenntnis bewerten (Berufsverkehr, Veranstaltungsstau, Baustellenstau,...) Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
