Re: [Talk-de] - optisch aufgearbeitete OSM History
Hallo, UMAX974 wrote: vor einiger Zeit hab ich mal eine Seite gesehen, auf der die OSM History einer Ortes optisch dargestellt war. Ich könnt mir vorstellen, dass es so etwas evtl sogar in Form eines kleinen Filmes gäbe. Ich fände das z..B für OSM Präsentationen eine Tolle Sache, wenn man für einen beliebigen Ort diese OSM Wachstum darstellen könnte. Gibt es so etwas? Ich habe einen recht primitiven Dienst, mit dem man sich eine Grafik, die nur Nodes anzeigt, fuer einen beliebigen Ort erzeugen lassen kann: http://labs.geofabrik.de/history/ Ausserdem habe ich vorfabrizierte Bilder fuer einige Regionen mit richtigem Mapnik-Rendering: http://www.geofabrik.de/gallery/history/ Die sind aber zuletzt im Dezember aktualisiert worden. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine - Vollständigkeitsauswertu ng
Hallo, Ulf Lamping wrote: ich dachte, es wäre inzwischen ALLEN klar, dass Relationen NICHT zum Gruppieren (zusammenstellen von Objekten) dienen soll. Da gab es vor einigen Wochen mal wieder Diskussionen drüber. +1 Das eine sind normallerweise recht eng geografisch zusammen gehörende Objekte: turn-restriction, Buslinie, site. Diese Informationen sind nicht automatisiert aus den anderen Daten zu bekommen. Das andere sind logische Gruppierungen alle Objekte einer Art: Packstationen, Stolpersteine, etc., die jeweils den gleichen Tag tragen - und das über die ganze Welt verteilt. Die Info kann man dann aber genauso gut über Datenbankabfragen (z.B. XAPI) abholen. Ja, ich denke, das trifft den Unterschied ganz gut. Alles, was man einfach als Tag formulieren kann, bedarf keiner Relation. Zum Beispiel wuerde man ein Haus mit architect=Friedensreich Hundertwasser taggen und nicht eine Relation alle Haeuser von Hundertwasser anlegen. Die Relation erfuellt hier den Charakter einer Kategorie, und das ist unerwuenscht (http://wiki.openstreetmap.org/wiki/Relations_are_not_categories). Zugegeben: Es ist derzeit leichter, alle Haeuser von Hundertwasser runterzuladen, wenn es so eine Relation gibt, weil man dann die XAPI nicht braucht, aber wir sollten nicht anfangen, unsere Datenbank mit Zugriffs-Vereinfachungen zuzupflastern (als naechstes kommt dann die Relation alle Objekte, die Fred je bearbeitet hat, damit ich immer leicht gucken kann, wie es meinem Werk geht...) Warum hier nicht einfach jeweils ein entsprechendes Tag historic=stolpersteine dranhängen und auf die meist problematische Relation ganz verzichten? Das wuerde ich auch empfehlen. Eine Relation muesste man wohl dann bemuehen, wenn dasselbe Objekt Teil verschiedener Gruppen sein koennte, also wenn es sowohl ein Stolperstein als auch ein Schloss ist, dann will man ja kein historic=stolperstein;castle haben... aber dann koennte man immer noch ein eigenes Tag fuer die Stolpersteine erfinden. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine - Vollständigkeitsauswertu ng
Hallo, Jan Tappenbeck wrote: Dann frage ich mich allerdings was dann eine Paketbox-Relation [1] soll. Die ist in meinen Augen genauso sinnfrei wie eine Relation Bundesstrassen in Nordrhein-Westfalen oder McDonald's-Filialen in Deutschland oder Strassenlaternen, die mit Gas betrieben werden. Oder anders - der Sinn fuer den Ersteller ist vermutlich meistens, wie ich schrieb, die Leichtigkeit des Zugriffs, weil er lieber eine /relation/.../full-Abfrage an die API stellt statt einen XAPI-Request formuliert, aber das sollten wir lieber nicht anfangen - das ist nicht mehr und nicht weniger als ein vorformulierter Suchbegriff. Als naechstes kommen dann die Relationen Gullydeckel an Nebenstrassen und Feldwegen im suedlichen Rheinland-Pfalz und Gotische Kirchen mit goldenen Windfahnen in Norddeutschland ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine - Vollständigkeitsauswertu ng
Hallo, Andre Joost wrote: - und das über die ganze Welt verteilt. Die Info kann man dann aber genauso gut über Datenbankabfragen (z.B. XAPI) abholen. genauso gut nicht, weil man mit der XAPI neben der bounding box nur genau ein Kriterium abfragen kann. Fuer den konkreten vorliegenden Fall trifft genauso gut aber zu. Und wie verträgt sich das mit dem immer gern vorgetragenen Chaos-Prinzip von OSM? Eben gar nicht. Relationen, bei denen man erwartet, dass jeder, der ein Objekt erfasst, es auch in diese Relation eintraegt, damit man es spaeter leichter findet, widersprechen dem Chaosprinzip ;-) Grundsaetzlich sind Mapper bei uns eine knappe Ressource, wir sollten also dem Mapper so wenig wie moeglich Arbeit aufbuerden, und einen Stolperstein einfach als solchen zu taggen und es dem Suchenden zu ueberlassen, was er suchen will, ist sicherlich leichter als sich erst einmal zu informieren, in welche Relationen ein Stolperstein aufzunehmen ist, diese herunterzuladen und zu ergaenzen. Sowas kann man machen, wenn es aus technischen Gruenden nicht anders geht, aber in den meisten Faellen, wo Relationen als Kategorien missbraucht werden, ist es unnoetig. Zugegeben: Es ist derzeit leichter, alle Haeuser von Hundertwasser runterzuladen, wenn es so eine Relation gibt, weil man dann die XAPI nicht braucht, aber wir sollten nicht anfangen, unsere Datenbank mit Zugriffs-Vereinfachungen zuzupflastern Ja stimmt, bei inzwischen fast 1 Million Relationen tut eine für Stolpersteine in der Tat weh :-( Jeder, der einen Stolperstein hinzufuegt oder entfernt, hat durch diese Relation mehr Arbeit, und jeder, der einen Stolperstein herunterlaedt, bekommt die Relation mit allen Stolpersteinen (oder ggf. die mit allen in seinem Ort) aufs Auge gedrueckt. Darum geht es, nicht um einen zusaetzlichen Eintrag in der Datenbank. Und warum soll man sich das Arbeiten an OSM nicht durch hierarchische Relationen vereinfachen, auch und weil wenn es kein Renderer auswertet? Das Arbeiten an OSM wird dadurch erschwert. Vereinfacht wird lediglich der Zugriff. Jede Huerde, die wir fuer potentielle Mitarbeiter aufbauen, schadet uns. Oder die Wanderwege (oder Buslinien oder Hochspannungsleitungen oder ...) des Vereins A sich mit den Wanderwegen des Vereins B räumlich vermischen, man aber speziell nur die des Vereins A haben möchte. Wanderwege und Buslinien sind in der Regel eh als eigene Relation gemappt. Die Wanderweg-Relation hat dann ein Tag operator=Alpenverein oder sowas. Dafuer braucht man keine Extra-Relation Wanderwege des Alpenvereins. Das gleiche gilt fuer Buslinien oder Hochspannungsleitungen. Ob nebendran noch andere Wanderwege anderer Vereine verlaufen, spielt keine Rolle, denn diese werden eigene Relationen haben. Ein Problem gaebe es dann, wenn derselbe Wanderweg von zwei Vereinen zugleich betrieben wuerde (und damit ist *nicht* gemeint, dass zwei verschiedene Wanderwege sich einen Waldweg teilen), dann muesste man, um ein operator=Alpenverein;Wandervoegel zu vermeiden, eine Relation fuer Alpenverein-Wanderwege und eine fuer Wandervoegel-Wanderwege haben. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine - Vollständigkeitsauswertu ng
Hallo, Andre Joost wrote: Wenn ich alle Packstationen über die Relation einlade, fällt ein falscher tag (auch beim Operator, z.B. mit oder ohne AG, Gmbh usw) eher auf. Gerade bei Objekten mit nem Haufen Zusatztags schleichen sich da schnell Fehler ein. Das sollte man lieber ueber ein gescheites JOSM-Preset sicherstellen als ueber eine Relation1 Bei Bahn- und Buslinien ist der Gemeinschaftsbetrieb aber durchaus üblich Tatsaechlich? Das waere mir neu. Bei uns im KVV gibt werden durchaus verschiedene Linien von verschiedenen Betreibern gemanagt; mal machts der eine im Auftrag des andren, mal der andre im Auftrag des einen, aber der Betreiber ist immer einer. bei Hochspannungslinien gibts auch verschiedene Anbieter auf dem gleichen Mast. Deswegen haben die Leute ja angefangen, Hochspannungsleitungen genauso wie Routen als Relationen zu taggen - da gibt es also eine Relation fuer die 110kv-Leitung von X nach Y, mit operator=Z, und eine andere Relation fuer eine andere Leitung, die teilweise die gleichen Masten benutzt, mit einem anderen Operator. Das ist ja ein etabliertes Verfahren, da brauchen wir nicht drueber zu diskutieren - wenn mehrere Linien oder Routen die gleichen Wegstuecke benutzen, nehmen wir dafuer eine Relation. Wenn mehrere Postunternehmen sich die gleichen Packstationen teilen wuerden, muesste man darueber vielleicht auch bei Packstationen nachdenken. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine - Vollständigkeitsauswertu ng
Hallo, Andre Joost wrote: Dann mach mal ;-) Und solange dürfen keine Stolpersteine/Packstationen/Wanderwege gemappt werden! Klar duerfen sie. Bloss sollte man dafuer keine Relationen missbrauchen. Mal für den Bahnbereich: http://de.wikipedia.org/wiki/Stadtbahn_Bonn Immerhin drei Betreiber auf 6 Linien ohne eindeutige Abgrenzung Und wie habt ihr das tagging-maessig dann geloest? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Stolpersteine - Vollständigkeitsauswe rtung
Hallo, Jacques Nietsch wrote: Hallo André, du hast leider Recht! Mit JOSM 'Objekt laden' und der RelationsID bekomme ich in wenigen Sekunden alle Stolpersteine von Hamburg, sofern sie der Relation zugeordnet sind. Mit: wget.exe http://www.informationfreeway.org/api/0.6/node[memorial:type=stolperstein][bbox=9.89793319,53.51232979,10.13147049,53.64380279] -O stolper_hh.osm habe ich nach über 10 Minuten immer noch nichts bekommen. Das macht wirklich keinen Spass. Dann sind wir uns ja einig - diese Relation ist ein klassischer Hack, man setzt sie zu einem Zweck ein, zu dem Relationen eigentlich nicht gedacht wurden, um die Unzulaenglichkeit eines anderen Tools oder Systems zu umgehen. Solange solche Relationen nicht zum Prinzip erhoben werden, sondern jedem Beteiligten klar ist, dass es sich um einen Workaround handelt, der abgeschafft wird, sobald es eine vernuenftige Zugriffsmoeglichkeit gibt, ist die Sache ja in Ordnung. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland
Hallo, Guenther Meyer wrote: fuer openstreetmap.de, was ja in erster Linie deutschsprachige Benutzer anspricht, waere das sicher ganz sinnvoll so. Also eine zusaetzliche Angabe der Bezeichnung in fuer deutschsprachige Personen lesbarer Schrift. Ich koennte mir vorstellen, dass man das recht leicht einbauen koennte auf osm.de. Da waere ich eigentlich auch dafuer. Wir wollten ja immer auch einen gescheiten deutschen Map-Style haben (Stichwort blaue Autobahnen), dazu kam es bislang auch nie. Ich haette aber Bauchweh wegen der politischen Implikationen. Markus schrieb: name:de ist vorgesehen für Ortsnamen in *heute deutschsprachigen* Orten. Sollte /auf der Standard-OSM-Karte/ nur in Ausnahmefällen in anderssprachigen Orten verwendet werden... Ich persoenlich habe das nie so betrachtet, ich wuerde allem, was einen deutschen Namen hat, auch ein name:de=... geben - ist ja dann die Entscheidung des Renderers, in welchen Gebieten er welchen Namen rendern will. Aber genau diese Haltung (und ich weiss, dass viele andere das genauso machen) sorgt natuerlich fuer Probleme auf osm.de, denn wenn ich nun einfach so name:de rendere, dann durften sich diverse Opfer frueherer nationalsozialistischer Eroberungen angepisst fuehlen. Wir muessten also irgendwie ein Ausschlusspolygon definieren und sagen: Bei allem, was hier drin liegt, den name:de auf keinen Fall rendern, selbst wenn vorhanden ;-) Oder wir muessten die Daten in Richtung von Markus' Empfehlung aufraeumen. Dazu muesste man dann erstmal gruendlich schauen, fuer was ueberall name:de benutzt wird und das dann ggf. abaendern auf ein geeignetes name:de:19xx-19xx oder sowas. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Viele Punkte
Hallo, M∡rtin Koppenhoefer wrote: das sollte man nicht zulassen, weil es grob gegen unsere Regeln verstößt: dadurch wird die history sabotiert, weil der Zugang extrem erschwert wird und die Verlaufsinformationen nicht mehr am eigentlichen Objekt hängen. Deswegen ist der User auch schon ein paarmal gesperrt worden, und wir haben jetzt eine zero tolerance policy - sobald der wieder auftaucht und Mist macht, wird er gesperrt, ohne lang nachzudenken. Manchmal macht er aber auch keinen Mist, und das darf er. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland - Schrift
Hallo, Markus wrote: Danke für die vielen Informationen! Ich bin gespannt, wie wir das alles zu einem verständlichen und nachvollziehbaren Schema zusammenbauen können. Ich weise darauf hin, dass es durchaus auch denkbar waere, verschiedene Namen eines Objekts *nicht* in OSM selbst, sondern in einer getrennten Datenbank zu haben. Schon heute scheinen Leute, die gezielt uebersetzen bzw. mehrsprachige Versionen pruefen wollen, nicht mit der Karte zu arbeiten, sondern sie machen sich lieber Auszuege z.B. von allen city-Nodes und gucken die an, sie arbeiten also mit Listen statt mit Geodaten. Wieso sollte das ein Renderer nicht genauso tun? Ich befuerchte, dass, wenn an dem Node London der chinesische oder arabische Name dranhaengt, dieser ziemlich leicht kaputt gehen kann (wenn jemand ohne entspr. Sprachkenntnisse den Node aendert und versehentlich auf die falsche Taste kommt...). Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland - Schrift
Hallo, Markus wrote: Wenn das für den Renderer-Workflow möglich ist, scheint mir das ideal. OSM baut eine eigene weltweite multilinguale *OSM-Geo-Namen-DB*. Aus der sich die Renderer, Router und anderen Anwendungen bedienen. Wo ein Wille ist, ist auch ein Weg. Man kann ja im Mapnik-Style beliebige selects angeben, also auch einen, bei dem ich z.B. einen OSM-Namen mit einer Fremdtabelle joine, um ggf. dort den passenden Namen fuer die Karte auszulesen. Laienhaft stelle ich mir vor, dass man die Geodaten-DB um ein paar hundert Ortsnamen-Tabellen erweitert (für jede Sprache eine)? Oder wären das zwei Datenbanken? Das ist dann ein Implementierungsdetail. Ich denke, beim Rendern sollte man eine zusaetzliche Tabelle haben, in der man den in OSM gefundenen Namen nachschlaegt, und die Tabelle hat dann fuer jede Sprache/Schrift/whatever eine Spalte. Die Sprachtabelle muesste im Renderer vorgehalten werden und koennte unabhaengig von OSM-Daten aktualisiert werden. Wie die Sprachtabelle editiert und verbreitet wird, darueber habe ich mir keine Gedanken gemacht. OSM waere dafuer nicht das richtige Medium. Vielleicht eine Wikiseite, oder Google Docs ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rendering vom Ausland - Schrift
M?rtin Koppenhoefer wrote: Wie die Sprachtabelle editiert und verbreitet wird, darueber habe ich mir keine Gedanken gemacht. ... Vielleicht eine Wikiseite, oder Google Docs ;-) Das ist wohl beides nicht Dein Ernst, oder? Eine Wikiseite würde das Wiki doch extrem aufblasen, oder Google Docs, wo man auf das Gutdünken von Google angewiesen ist, dass das ganze nicht mal ein kostenpflichtiger Service wird? Von Google Docs halte ich selber wenig, aber ich wuerde das denen ueberlassen, die die Uebersetzungen pflegen moechten. Und das mit der Wikiseite meine ich so halb-ernst, schliesslich wurde hier schon davon gesprochen, man koennte die Interwiki-Links aus Wikipedia automatisch abgreifen. Hieraus eine Tabelle fuer Mapnik zu machen, waere trivial; wenn jemand dann eine zusaetzliche Uebersetzung wuenscht, muesste er nur in der Wikipedia einen Interwiki-Link erstellen. Das setzt natuerlich voraus, dass dieser ganze Mechanismus nur fuer Orte zur Anwendung kommt, die fuer die Wikipedia relevant genug sind. Eventuell waere es auch eine Moeglichkeit, diese Namensliste in der OpenGeoDB zu pflegen, vielleicht haben die ja ein einfaches Interface fuer sowas. Was wir bei OSM an Editoren haben, ist dafuer ja eher nix. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Häuser einzeichnen?
Hallo, Christopher Reimer wrote: Darf man GeoThings.net wirklich nutzen? Geothings.net an sich ist nur ein Dienst, keine Datensammlung. Geschrieben von einem OSMer, also grundsaetzlich ist die Benutzung schon ok, aber jeder kann dort beliebige Daten hochladen, also muss man schon drauf schauen, von *was* man da gerade abmalt! Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Bernhard, Bernhard Zwischenbrugger wrote: Wer auf der englischen Liste mitliest, kennt meine map library wahrscheinlich schon. Jetzt funktioniert die Map auf den meisten Browsern und ich poste das jetzt auch auf diese Liste. Kannst Du mal einen kurzen Sales Pitch fuer uns machen - warum sollte man Deine Library benutzen anstatt OpenLayers, was sind aus Deiner Sicht die Vorteile/Unterschiede - und wo hat OpenLayers Dir vielleicht noch Features voraus? Welche grundsaetzlichen Maengel bei OpenLayers haben Dich dazu bewogen, etwas eigenes zu machen? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Arbeiten mit Osmosis (war: Re: W ohnmobil-Stellplätze bei OSM)
Hallo, Thomas Ineichen wrote: Ich arbeite hier mit dem Schweizer Ausschnitt (ca. 80 MB). Wenn ich mit Osmosis alle Toiletten (amenity=toilets) kopiere, dann dauert das 30 Minuten - ein Import der Schweiz mit osm2pgsql klappt aber in nur 6 Minuten und ich bin danach viel flexibler.. Kommt drauf an, was Du machen willst. Osmosis erzeugt Dir halt einen echten OSM-Datensatz, den Du auch z.B. in den JOSM laden und bearbeiten und wieder hochladen kannst. *Diese* Flexibilitaet hast Du mit osm2pgsql nicht. Auch wird Osmosis Dir alle Tags extrahieren, osm2pgsql nur die, die Du per style-File anforderst (ausser natuerlich, Du bastelst mit dem neuen hstore-Zeug rum). Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Inkonsistente Küstenlinien
Hallo, NopMap wrote: Eigentlich ist die Aufgabenstellung ganz einfach: Ich versuche, eine Garminkarte von Mitteleuropa zu erzeugen, mit Meerespolygonen, die per mkgmap aus den natural=coastline Tags erzeugt werden. Kannst Du nicht die processed_p-Kuestenlinien nehmen und daraus schnell Pseudo-OSM-Daten fuer den mkgap bauen? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, Bernd Wurst wrote: Wäre die Frage, ob du dich hier als eierlegende Wollmichsau aufstellen willst und alle Anwendungsgebiete optimal abbilden möchtest oder ob du sagst, dir ist eine Alternative zu OpenLayers wichtig, die eben eine andere Zielgruppe hat. Wenn ich das richtig verstanden habe, ging es darum, dass das sanfte Zoomen halt besser in die iWhatever-Welt mit der Fingerbedienung passt. Vielleicht waere es ein guter Kompromiss, wenn das Standardverhalten der Library vom User Agent abhinge? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neue Slippy Map (khtmlib)
Hallo, Johann H. Addicks wrote: Aber das war's dann auch schon. Benutzen möchte man den Pixelmatsch nicht... Naja, ich kann mich (trotz Apple-Abstinenz) da schon reinversetzen. Wenn ich auf einer Europakarte den Zeigefinger auf Karlsruhe und den Daumen auf Muenchen lege und das beides nun scherenmaessig auseinanderschiebe, will ich ja, dass nach Ende der Bewegung immer noch der Zeigefinger auf Karlsruhe und der Daumen auf Muenchen ist - und solange man kein Force Feedback hat, um vom Geraet aus die Finger an die richtige Stelle zu schieben, muss man halt Zoomzwischenstufen benutzen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenerfassung mit Taxis
Hallo, aighes wrote: die Idee ist nicht neu. Das Problem ist, dass es nicht von oben (Chef) angeordnet werden kann. Stichwort Überwachung der Mitarbeiter. Man müsste also gezielt die Taxifahrer/Busfahrer/Müllmänner ansprechen und fragen, ob sie den Logger eine Woche spazieren fahren. Bedingung sollte dann sein, dass der Zeitstempel verfälscht wird. Wenn ich Guerilla-maessig einen Magnetsender an ein Taxi oder Muellauto dranmache und am Abend wieder entferne, um die Tracks zu sammeln, gegen welches Recht verstosse ich dann? Datenschutz kann es nicht sein, denn ich sammle ja keine personenbezogenen Daten - ich habe keinerlei Mittel, den Bezug zu einer Person herzustellen, denn ich weiss (im Gegensatz zu der Taxifirma) nicht, wer wann im Fahrzeug sass. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Datenabruf vom API
Hallo, die aufwendigste Anfrage, die man an die API stellen kann, ist der sogenannte map-Aufruf, mit dem man alle Daten in einem bestimmten Bereich herunterlaedt. Dieser Aufruf belastet die Rechner und die Datenbank recht stark, weil er zu vielen einzelnen und aufwendigen Datenbank-Abfragen fuehrt: * gib mir alle Nodes in diesem Bereich. * nun gib mir alle Wege, die mindestens einen dieser Nodes benutzen * und alle Relationen, die mindestens einen dieser Nodes oder einen der vorhin gefundeneen Wege als Member haben * nun gib mir noch alle Nodes, die von den bisher gesammelten Wegen benutzt werden, aber ausserhalb des Bereichs liegen Nicht ohne Grund ist dieser Aufruf auf ein Gebiet von maximal 0,25°² beschraenkt (sowie auf maximal 50.000 Nodes). Jeder, der mehr Daten herunterladen will, ist gehalten, auf Daten-Extrakte auszuweichen (entweder fertige wie von download.geofabrik.de, oder mit Osmosis selbstgemachte, oder einen Mix aus beiden). Alternativ kann auch die XAPI benutzt werden. Leider kommt es regelmaessig vor, dass Benutzer die Groessenbeschraenkung absichtlich umgehen, indem sie ein Skript schreiben, dass nacheinander viele einzelne, nebeneinander liegende Bereiche abruft. Da gehoert ja auch nicht viel dazu - bitte tut es trotzdem nicht. Wenn ihr das macht, seid ihr keine coolen Hacker, sondern laestige Stoerer. Die Serverbetreiber muessen regelmaessig - so auch heute wieder - solche Massen-Downloader sperren, um den Betrieb fuer die anderen aufrecht zu erhalten. Die Mehrzahl dieser Massen-Downloader kommen aus Deutschland, daher in diesem Forum die Bitte: Nehmt Ruecksicht und haltet Euch an die Regeln. Die sind nicht gemacht, um Euch zu aergern, sondern damit der Laden fuer alle einigermassen laeuft. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenerfassung mit Taxis
Hallo, M∡rtin Koppenhoefer wrote: Ich finde es nicht besonders verlockend, irgendwelche Tracks von Taxis und Müllautos zu bekommen (vor allem nicht in Deutschl.), da die meiste Arbeit ja nicht das Tracksammeln ist, sondern die dazu passenden Informationen zu dokumentieren und einzugeben. Ein ueber mehrere Wochen von Muellautos zusammengetragenes Grundnetz waere m.E. etwa vergleichbar mit einem mittelmaessig aufgeloesten Luftbild. Man koennte immerhin die Geometrien der Strassen erfassen und sich auf die Weise die Arbeit teilen. Ein Ortsansaessiger kann die Namen an die Strassen selbst dann dranschreiben, wenn er kein GPS hat. In Deutschland sehe ich dafuer auch wenig Bedarf, aber nicht ueberall stehen wir so gut da. Natuerlich gibt es auch nicht ueberall eine Muellabfuhr, die jede letzte Seitenstrasse befaehrt ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenabruf vom API
Hallo, Stephan Wolff wrote: Passiert so etwas nicht auch, wenn man in JOSM die Daten entlang eines langen Tracks herunterladen lässt? Ja, das habe ich unsere Jungs in England auch gefragt, aber die Antwort war, dass der JOSM-User-Agent-Header diesbezueglich noch nie negativ aufgefallen ist. Ich denke mal, wenn Du das mit einem GPS-Track von einer Weltumsegelung probierst, dann *wuerde* es auffallen ;-) Wenn ich bei 100km Autofahrt über Landstraßen etwa 150 Waypoints bei potentiell in OSM fehlenden Punkten gesetzt habe, was ist dann eine nutzer- und serverfreundliche Methode die OSM-Daten in JOSM zu laden? Es gibt nicht fuer alles eine nutzer- und serverfreundliche Methode. In Deinem Fall wuerde ich vermutlich mit gpxbabel die Waypoints in einen Track konvertieren (so dass Du einen Track mit nur 150 Trackpoints bekommst) und dann die download along track-Funktion von JOSM benutzen. Dadurch laedt JOSM Dir dann 150 Inseln herunter anstatt eines kontinuierlichen Bereiches. Wie ich das so schrieb, fiel mir auf, dass man das eigentlich auch in die Daten entlang Track herunterladen-Funktion von JOSM einbauen koennte. Das hab ich jetzt grade gemacht, deshalb hat die Antwort auch etwas laenger gedauert ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] open way/node by ID in josm/potlatch
Hallo, Marcus Wolschon wrote: Ich habe hier eine ganze Reihe von Wegen/Nodes in denen Sanity-Checks Probleme finden (Wege mit 2 nodes, ungültige PLZ, ...). Gibt es einen einfachen Weg mit der ID eines Weges/Nodes diesen in JOSM oder Potlatch zu öffnen um nachzusehen? In JOSM: 1. manuell: File - Download Object, ID eingeben 2. per OSM-File: Datei mit lauter way id=x version=1 / drin anlegen, in JOSM laden, dann File - Update JOSM und Potlatch haben auch beide eine Moeglichkeit, direkt ein Objekt zum Editieren aufzurufen, aber dazu musst Du einen URL generieren, der den jeweiligen Bereich angibt, in dem sich das Objekt befindet, also entweder http://www.openstreetmap.org/edit?lon=1.72543lat=52.56012zoom=18way=50759614 fuer Potlatch oder http://127.0.0.1:8111/load_and_zoom?left=8.19right=8.20top=48.605bottom=48.590select=node413602999 fuer JOSM. Letzteres setzt voraus, dass JOSM bereits laeuft und das RemoteControl-Plugin installiert ist. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Notaufnahme-Frisör
Hallo Klaus, Klaus Hanauer wrote: beim mappen eines Klinikums bin ich auf einen Frisörsalon mit dem Namen Notaufnahme gestoßen. Falls es sich weder um eine med. Einrichtung noch um ein Friseurgeschäft in einem Krankenhaus handeln sollte, gehe ich von einer groben Irreführung aus. Der Name ist zwar tatsaechlich etwas fragwuerdig, aber es scheint sich sogar um eine ganze Friseurkette zu handeln: http://www.notaufnahme.com/DE/standorte.php Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] trunk_link - trunk im großen stile - etc.
Hallo, Walter Nordmann wrote: Jeder NODE seiner ansonstens vernünftigen radwege ist als highway=cycleway getaggt und nicht nur der way. Kann mir jemand dieses Riesen-Changeset erklaeren: http://www.openstreetmap.org/browse/changeset/4814936 500 Radewege quer durch Hessen/RLP auf einmal neu angelegt? Ist das ein sinnvoller Edit? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] trunk_link - trunk im großen stile - etc.
Hallo, Walter Nordmann wrote: ich stimme in der noch nicht eröffneten abstimmung fuer revert beider sets vom 26.5 und zur sperrung des accounts. Das mit dem Revertieren wird natuerlich umso schwieriger, je mehr Leute schon von Hand die highway-Tags an den Nodes entfernt haben ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] trunk_link - trunk im großen stile - etc.
Hallo, Walter Nordmann wrote: der hat die daten - wo immer er die auch her hat - einfach reingeknallt. aufgefallen ist mir das, da jeder einzelne node als highway=cycleway getaggt war und josm das natuerlich als falsch anzeigt. zusätzlich liegen die wege deutlich neben den entsprechenden straßen und sind auch dort neu wo bereits radwege vorhanden waren. Hab ihm mal geschrieben: Zitat Anfang Hallo Oberförster, in http://www.openstreetmap.org/browse/changeset/4814936 hast Du rund 500 Radwege hochgeladen, die offenbar in keinem Zusammenhang mit bereits existierenden Daten stehen. Die Wege überkreuzen sich wild mit existierenden Strassen, verdoppeln zum Teil sogar von Dir selbst früher hochgeladene Radwege. Diese Daten sind nicht sinnvoll. Ist Dir da ein Fehler unterlaufen? Kannst Du das selber wieder reparieren, oder brauchst Du Hilfe dabei? Zitat Ende Schaun wir mal, ob was kommt. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM für Feuerwehr
Hallo, Tirkon wrote: Mit OSM wäre es einfach, Hydranten, Aufstellplätze und andere feuerwehrspezifische Dinge endlich selbst mappen zu können. Bisher operiert man noch mit Papierplänen. Nach meinem Hinweis, dass jeder an den Daten etwas ändern könnte, stellte sich dieses als Nachteil heraus. Im Einsatzfall muss man sich logischerweise auf stimmige Pläne verlassen können. Hierzu gibt es viele verschiedene Dinge zu sagen. Zunaechst einmal ist die Annahme seitens Deines Feuerwehr-Bekannten, er verfuege selbst ueber stimmige Plaene, mit an Sicherheit grenzender Wahrscheinlichkeit falsch. Der Beweis, dass ein alle koennen alles aendern in OSM unterm Strich zu weniger verlaesslichen Daten fuehrt als die natuerliche Alterung plus menschliche Fehler auf Seiten derer, die im Augenblick die Plaene pflegen, steht aus. Dass es in OSM keine nicht veraenderbaren oder nur von einem privilegierten Personenkreis veraenderbaren Daten geben kann, sollte auf der Hand liegen; das liefe der Grundidee des Projekts zuwider. Nun koennte man einerseits einfach einen parallelen Datenbestand halten, wie Du es skizziert hast; die Technologie eignet sich schon dafuer, wie Peter gesagt hat, gibt es ein paar Huerden zu ueberspringen, aber gehen taet's schon. Was man dabei verschenkt, ist die Mitarbeit der Community. Wenn man einen Parkplatz als Aufstellplatz markiert und der Parkplatz irgendwann in der Groesse halbiert wird, weil eine Skater-Bahn errichtet wird, dann wuerde das bei einem echten OSM-Parkplatz automatisch gemappt, aber wenn die Feuerwehr den Platz in ihrer Privatdatenbank haben will, dann gibts diesen Vorteil eben nicht. - Man koennte das, was Du schilderst, auch komplett abseits der OSM-Toolchain machen, z.b. koennte man die Hydranten und Aufstellplaetze mit QGIS in einem Shapefile speichern, mit dem UMN Mapserver zeichnen und mit OpenLayers als transparenten Layer ueber OSM-Tiles darstellen lassen. Die Technologie dafuer existiert schon laenger und unabhaengig von OSM, aber erst in den letzten Jahren ist QGIS halbwegs nicht-GIS-Experten-Anwenderfreundlich geworden. Fuer besser hielte ich ein Konzept, bei dem die Leute die Daten tatsaechlich in OSM pflegen und sich auf andere Weise ihrer Korrektheit versichern. Immer wieder kommt der Vorschlag mit irgendwelchen Hashes und kryptographischen Pruefsummen, aber das halte ich fuer Quatsch, denn die OSM-API stellt ja schon sicher, dass jeder, der ein Objekt veraendert, sich authentifizieren muss, d.h. es ist triival, zu einem Objekt die Liste aller Personen zu ermitteln, die es veraendert haben (oder von mir aus nur die letzte veraendernde Person). Dein Feuerwehrmann fuehrt also einfach eine Liste von (fuer ihn) vertrauenswuerdigen Mitmachern und uebernimmt Aenderungen an gewissen Objekten nur dann, wen nsie von jemandem aus der vertrauenswuerdigen Gruppe gemacht werden. Dazu muesste man auch ein bisschen Code schreiben, aber das ginge schon. Noch besser, wenn auch weniger sicher, waere eine Ueberwachung im Nachgang, wie es hier im Thread auch schon vorgeschlagen wurde - man benutzt einen ganz normalen OSM-Mirror, aber man laesst sich von einem Skript alarmieren, immer wenn irgendwas, was als Hydrant getaggt war, veraendert wird. Man koennte ja auch die Kachel-Generierung oder die Garminkarten-Herstellung immer erst anstossen, nachdem man einen Blick in die Liste der relevanten Aenderungen seit dem letzten Mal geworfen hat. Natuerlich, und das muss ihm auch ganz klar sein, erfordert das Arbeit - er bekommt die Mitarbeit der Community, aber investieren muss er Zeit, wenn er glaubt, bestimmte Sachen besser zu wissen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geoflags verwendet OSM-Daten
Hallo, Alexander Matheisen wrote: Und ohne auf rechtliche Dinge einzugehen: Irgendwie gefällt es mir persönlich nicht, dass sie zwar OSM-Daten verwenden, aber das auf einer Google Maps Karte. Das hat durchaus einen lizenzrechtlichen Aspekt. Google hat naemlich in deren Bedingungen irgendwo sowas drinstehen, dass der Nutzer ihnen das Recht einraeumt, Bilder von der Applikation frei zu verwenden oder so. Streng genommen ist daher die Abbildung von OSM-Daten auf einer Google-Karte problematisch, denn derjenige, der diese Abbildung vornimmt, hat ja gar nicht das Recht, Google irgendwelche Rechte an den OSM-Daten einzuraeumen. Aber das ist schon sehr spitzfindig. Dort kann man auch POIs eingeben, aber mich würde mal interessieren, ob die auch wieder in OSM einfließen. Unwahrscheinlich, aber das muessen sie auch nicht. Eventuell ist das sogar der Grund, warum sie eben keine OSM-Karte einsetzen, denn dann waere OSM der Ansicht, dass durch das Setzen von POIs durchaus ein abgeleitetes Werk entsteht, das unter CC-BY-SA rausgegeben werden muesste. Nehmen sie Google als Basis, so entsteht zwar ein abgeleitetes Werk aus Google-Daten, aber Google scheint da (siehe z.B. Wikimapia, das ist das gleiche in gruen) keine Probleme zu haben. So macht es mir eher den Eindruck eines OSM-Konkurrenz-Portal (zumindest will es das anscheinend sein, nur auf andere Weise, die mich nicht so anspricht). POI-Sammel-Portale gibt es wie Sand am Meer. Da spielt OSM in einer ganz anderen Liga. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geoflags verwendet OSM-Daten
Hallo, Manuel Reimer wrote: Wo steht denn, dass man alles, was man auf der Openstreetmap anzeigt auch wieder unter CC-BY-SA gesetzt werden muss? Das ist nicht der Fall. Aber wenn Du ein Interface anbietest, mit dem Leute auf einer OSM-Karte neue POIs eintragen koennen, ist davon auszugehen, dass die Leute sich dabei an der OSM-Karte orientieren - z.B. jemand weiss, dass an der Ecke Bachstr/Goethestr ein Briefkasten ist und traegt den auf der Karte ein; *wo* diese Ecke aber ist, die Info kommt aus OSM, also Briefkasten = abgeleitetes Werk. Wenn man den Briefkasten anderswo herhat und nur ueber OSM anzeigt, ist das was anderes. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geoflags verwendet OSM-Daten
Hallo, Alexander Matheisen wrote: Das war mir schon klar, aber ich fände es irgendwie schöner, so eine Art Gegenleistung von denen, dafür dass sie unsere Daten verwenden. Ich bin derzeit eigentlich dankbar fuer jeden, der unsere Daten verwendet und damit unseren Bekanntheitsgrad steigert. Solang wir eine Lizenz haben, die den Leuten Vorschriften macht, sollten wir uns m.E. damit zufriedengeben, dass die Leute die Lizenz einhalten, anstatt selbst dann noch nach einer Gegenleistung zu fragen! Wie man sieht, es es ja schwierig genug, die Lizenz einzuhalten; ich finde, dass Geoflags es nicht korrekt macht, aber sie machen es besser als viele andere OSM-Nutzer, die nicht mal dazusagen, wo die Daten herkommen. POI-Sammel-Portale gibt es wie Sand am Meer. Da spielt OSM in einer ganz anderen Liga. Aber gibt es sonst noch solche Portale, die dies mit OSM-Daten als Basis tun? Weiss ich nicht, aber ich bin fast sicher. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM für Feuerwehr
Hallo, Tirkon wrote: Sie braucht noch eine ganze Reihe mehr. Ich weiß nur, Auszüge zu nennen: Lagerorte von Gefahrenstoffen. Pläne über den Standort besonderer Gerätschaften, die nicht mit einem beliebigen Löschmittel gelöscht werden dürfen. Wo ist der Schalter, der die Energieversorgung in welchem Bereich kappt. Wo befinden sich die Schalter für fest installierte Lösch- und Schutzmechnismen. Wo befinden sich die fest installierten Löschschläuche vor Ort. Welchen Bereich kann jeder einzelne abdecken. Wo befinden sich die Zugangsstellen zu besonders gesicherten Bereichen. Welches sind die Brandschutzbereiche. Wo sind Sollbruchstellen und und und. Vieles davon darf einer Öffentlichkeit nicht preisgegeben werden. Das ist eine sehr konservative Haltung, die auf einem ueberholten Sicherheitsmodell beruht (in IT-Kreisen nennen wir das Security by Obscurity, Sicherheit durch Unklarheit). In den USA gab es kuerzlich einen Gesetzesvorschlag: Man moege bei Strafe verbieten, dass Online-Karten sensitive Details wie z.B. Zugaenge zu Belueftungssystemen von Schulen oder Krankenhaeusern sichtbar machen. Dahinter steckte genau der gleiche Gedanke: Sicherheit durch Unklarheit. Aber in Wahrheit ist das keine Sicherheit, sondern nur ein in-Sicherheit-Wiegen: Die Attentaeter vom November 2008 in Mumbai verfuegten nach uebereinstimmenden Zeugenaussagen ueber bessere Plaene der angegriffenen Einrichtungen als alle Helfer und die Polizei! Waeren hier alle Plaene oeffentlich gewesen, so haette dies einen *Vorteil* fuer die Betroffenen bedeutet. Nun sage ich nicht, dass wir jetzt hier in Deutschland sofort alle umdenken muessen und Du Deinen Bekannten bei der Feuerwehr davon ueberzeugen musst, dass die jahrzehntelang gelebten Sicherheitsprinzipien heute nicht mehr gelten. Aber wenigstens erwaehnen koennte man es schon. Erstens ist bei weitem nicht alles, was Du gesagt hast, eine fuer Feuerwehrleute exklusive Information. Zweitens ist nicht sichergestellt, dass der Informationsfluss innerhalb einer Organisation - hier der Feuerwehr - ueberhaupt so gut ist, dass ein Fehler, den einer bemerkt, am Ende auch zu einer Korrektur der Daten fuehrt. Erstaunlich oft haben Organisationen hier grosse Defizite. Ich denke, ich konnte ansatzweise die Tragweite deutlich machen. Ein normaler Mapper, ja selbst ein einfacher Feuerwehrmann hat hier nicht den Hauch einer Chance, irgendetwas zu mappen oder zu verbessern. Das ist eine sehr ueberhebliche Annahme, die in der Regel hauptsaechlich jene treffen, die mit der Herstellung von diesen geheimen Karten zu tun haben ;-) Für jede andere Einsatzgruppe, sei es DLRG, technisches Hilfswerk dürfte Ähnliches gelten. Ja, die glauben auch, sie wuessten mehr ;-) Mir ist klar, dass hier die Wünsche von OSM und dem Anwender gegenläufig sind. Ich glaube, dass man in Deinem konkreten Fall durchaus eine Loesung finden kann, von der alle profitieren. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geoflags verwendet OSM-Daten
Hallo, olvagor wrote: Von daher würde ich empfehlen: freuen, dass jemand OSM benutzt und auf die neue Lizenz warten. Wobei das ja noch nicht 100% klar ist, ob die neue Lizenz tatsaechlich kommt. Aber ich teile Deine Ansicht. Natuerlich ist es jedem Projektteilnehmer unbenommen, auf eigene Faust gegen Lizenzverletzer vorzugehen; trotzdem sollte man auch das Bild unseres Projekts in der Oeffentlichkeit im Kopf behalten. Es hat in der Vergangenheit Aktionen Einzelner gegeben, die durchaus geeignet waren, unser Projekt als eine Ansammlung verbissener Geeks dastehen zu lassen - und dabei wollen wir doch vorallem die Botschaft es macht Spass, jeder kann mitmachen rueberbringen. Die Data Working Group, in der ich auch mitarbeite, hat grundsaetzlich die Aufgabe, Lizenzverletzungen jeder Art zu untersuchen. Wir sind allerdings tendenziell eher mit Faellen beschaeftigt, in denen OSMer die Lizenz von anderen verletzen als umgekehrt ;-) ausserdem ist es utopisch, anzunehmen, eine Gruppe von Freiwilligen, die ab und zu eine Telefonkonferenz machen, koennte sich um jeden Fall kuemmern, in dem irgendwer irgendwo nicht richtig dazuschreibt, dass er Daten von OSM hat. Das muss mehr verteilt werden, da muss es kleine Arbeitsgruppen in jedem Land geben. Auf der SOTM wird es einen kleinen Beitrag von der Data Working Group geben, im Rahmen dessen auch diese Zukunft diskutiert werden soll. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM-Buch: Dritte Auflage ist draussen!
Hallo, ab sofort kann man die dritte Auflage von unserem OSM-Buch kaufen. Sie hat nochmal 32 Seiten mehr als die zweite (384 Seiten) und ist natuerlich komplett ueberarbeitet und aktualisiert. Der Preis ist gleich geblieben (29,95 Euro). Details hier: http://www.openstreetmap.info/de/news/2010-05-31-neue-auflage.html Beim Verlag ist das Buch sofort (ohne Versandkosten und ohne Registrierung) erhaeltlich: http://www.lob.de/isbn/9783865413758/ Die Lehmanns-Filialen werden das Buch im Laufe der Woche erhalten. Der sonstige Online-Buchhandel wird vermutlich ab naechster Woche liefern koennen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM mit Berliner Zoo auf ars technica
Hallo, das US-Technikblog ars technica berichtet ueber OSM und zeigt den Berliner Zoo als Paradebeispiel: http://arstechnica.com/open-source/news/2010/06/crowd-sourced-world-map.ars Spaeter benutzen sie ganz stilecht Potlatch, um die Brooklyn Bridge zu vandalisieren ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Hallo, steffterra wrote: Keine Ahnung, vlt. ist auch das Komma mit Leerzeichen ungewöhnlich und man sollte auch beim ref eher Semikolon und kein Leerzeichen verwenden? Weiss da jemand mehr darüber, was bei anderen Tags üblich ist? Wenn es irgend geht, sollten mehrere Werte in einem Tag vermieden werden. Ich weiss, dass es nicht immer geht, aber eine Aufazehlung mit Trennzeichen ist immer die zweitbeste Loesung. Im Falle von ref wuerde ich z.B. Relationen benutzen und am Way selbst nur eine, oder sogar gar keine, der Strassenbezeichnungen setzen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Hallo, steffterra wrote: Also jede einzelne Auffahrt und jede Abfahrt als Relation erfassen? Ich habe die Auffahrt-Problematik nicht praesent; falls Du gerade vorschlaegst, ein ref=A3 an eine Auffahrt zu setzen, die auf die A3 fuehrt, so wuerde ich dem widersprechen - ref=A3 soll m.E. nur an Strassenstuecke, die Teil der Autobahn sind. Daher ist es auch ein leichtes, die alle in eine Relation A3 zu packen. Die Auffahrt braucht m.E. keine Relation. Das destination=A;B laesst sich auch nicht gut durch eine Relation ersetzen, aber in diesem Fall ist das ja eh weniger ein computerlesbares Tag sondern nur ein abgeschriebenes Verkehrsschild. Darf ich mal eine Grundsatzfrage stellen? Ich lese ja erst seit kurzem mit. aber ich bemerke immer wieder zwei Lager: die einen, die am liebsten _alles_ in Relationen packen würden und die Verfechter der Meinung, das kurze prägnante neue Zusatztags viele Vorteile bieten. Was sind denn die großen Vorteile von Relationen für _alles_? Relationen fuer alles ist Quatsch. Relationen sollten da benutzt werden, wo mehrere Objekte zusammengehoeren und/oder wo ein Tag alleine nicht ausreicht. Also z.B. wenn Du an ein Haus architect=Friedensreich Hundertwasser dranschreibst als Tag ist das voellig ok, eine Relation dafuer waere ueberfluessig (Leute machen das manchmal, weil sie auf einfache Weise alle Haeuser von Hundertwasser aus der Datenbank laden wollen, das geht mit einer Relation gut, aber ich halte das fuer einen Missbrauch). Sobald Du aber anfangen musst, mit einem Semikolon zu operieren, weil ein Stueck Strasse sowohl zum Wanderweg A als auch zum Wanderweg B gehoert, ist eine Relation fuer beide Wanderwege sinnvoll. Oftmals - aber nicht immer - funktioniert die folgende Faustregel: Mappe ich eine wesentliche Eigenschaft eines Objekts, kommt das in ein Tag. Mappe ich hingegen etwas, wo das Objekt nur eine Rolle spielt, dann ist eine Relation besser. Wenn die Stadtverwaltung sich heute entscheidet, dass der Stadtrundgang kuenftig durch die A-Strasse und nicht mehr durch die B-Strasse fuehren soll, dann aendert sich dadurch weder die A-Strasse noch die B-Strasse, sondern der Stadtrundgang - also sollte das auch nicht in ein Tag, sondern in eine Relation. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Trennzeichen bei Aufzählungen im Wert eines Tags (war: motorway und motorway_link um destination-tag ergänzen)
Hallo, steffterra wrote: Der Kausalität nach gehört imho die Auffahrt zur Autobahn und die Abfahrt zur Bundesstraße zu der sie führt. Demensprechend ref-Autobahn an Auffahrt ref-Bundesstraße an die Abfahrt. Diese Logik ist imho sehr klar und kann so auch an komplizierten AB-Kreuzen/Anschlussstellen durch reine Logik konsequent umgesetzt werden. Das mag ja sein, dass diese Logik sehr klar und durch reine Logik konsequent umsetzbar ist, aber genauso klar waere es, wenn ich sagen wuerde, dass Auf- und Abfahrten grundsaetzlich gar kein ref-Tag haben sollten; das waere sogar ohne Logik konsequent umsetzbar. Ich bin weiterhin der Ansicht, dass mit ref=A5 nur das zu taggen ist, was tatsaechlich die A5 ist, und nicht irgendwas, was irgendwann irgendwo auf die A5 drauf fuehrt. Taggst Du dann auch die Service-Wege einer Raststaette mit A5? Wo steht das eigentlich im Wiki? Hab unter Key:ref nichts gefunden. Ich will mich da nicht weiter reinhaengen, weil ich kein Autobahnexperte bin. Ich koennte mir vorstellen, dass es Leute gibt, die davon ausgehen, dass alles, was mit A... getaggt ist, in Verwaltung des Bundes ist und alles, was mit L... getaggt ist, in Verwaltung des Landes ist; was Du mit Deiner Logik produzierst, wenn eine Autobahnabfahrt auf eine Landesstrasse fuehrt, ist eine Auf-/Abfahrt, die halb in Bundes- und halb in Landesverwaltung ist. Aber vielleicht entspricht das ja sogar der Realitaet, wie gesagt, ich kenne mich mit Autobahnen nicht so aus. Es geht _nicht_ darum, Schilder zu taggen. Dafür gibt es die Schilder-Relationen. Das Ablesen des Schildes ist nur als Informationsquelle für den destination-key gedacht. Dieser wiederum kann leicht von Software wie z.b. routern ausgelesen und direkt für sehr natürliche Anweisungen genutzt werden, weil der Fahrer die gleiche Anweisung dann auf dem Schild zu lesen bekommt - Also geht es doch darum, ein Schild zu taggen? Denn wenn das Schild nicht da waere, oder wenn es anders beschriftet waere, waere ja auch der Inhalt des destination-Tags nicht sinnvoll. Wenn man nun alle motorway_links mit Relationen zusammen fassen würde - was würde das für einen Vorteil bringen? Welchen direkten Nutzen habe ich derzeit davon? Ich wuerde nicht empfehlen, *alle* motorway_links mit Relationen zusammenzufassen. Ich sehe darin keinen besonderen Sinn. Was man hoechstens machen koennte, waere, alle Auf- und Abfahrten, die gemeinsam ein Kreuz oder eine Anschlussstelle ausmachen, in eine gemeinsame Relation zu tun. Da koennte man dann sowas wie einen Mautpunkt speichern oder eben den Namen der AS (den man sonst ja bei einem AK an 4 verschiedenen Abfahrten taggen wuerde). Ich wuerde Auffahrten gar nicht mit ref taggen. Wenn Du es doch machen willst und wenn eine Auffahrt auf eine Autobahn fuehrt, die zwei verschiedene ref-Tags hat, wuerde ich nur den wichtigeren der beiden ref-Tags taggen, denn der hypothetische Router wird eh nicht sagen: Fahren Sie nun auf die A5 beziehungsweise E13 bloss weil da ref=a%;E13 steht. Grundsaetzlich ist die Frage welchen direkten Nutzen habe ich derzeit davon nicht immer eine, die OSM zu verbessern hilft. Man kann von Glueck sagen, dass die Leute, die vor 5 Jahren mit OSM angefangen haben, nicht vorrangig diese Frage gestellt haben ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ref =/ Referenz? und andere philosph . Fragen (war: Re: Trennzeichen bei Aufzählunge n im Wert eines Tags)
Hallo, steffterra wrote: Nunja ref ist laut wiki die Abkürzung für reference das heisst einfach übersetzt Referenz oder Bezug Und wenn ich dem highway_link den ref= A 3 gebe, dann sage ich damit aus, dass dieser Link zur A 3 einen Bezug hat, nämlich den der Auffahrt (was wiederum der highway_link aussagt) Man könnte eher umgekehrt argumentieren und sagen, die Autobahn selbst darf nicht ref tragen, da sie nicht nur einen Bezug zu dieser hat, sondern sie es selbst ist ;-) Wo ist das Problem? Das Problem ist zweierlei: Erstens wird nicht jedes Tag in OSM so benutzt, wie es der Bedeutung des Keys entspricht; zweitens geht, selbst wenn das der Fall sein sollte, eine solche Bedeutung oft beim Versuch der Uebersetzung verloren. Im Englischen ist eine reference number eine Nummer, unter der man etwas aufsuchen oder nachschlagen kann, und hat mit Bezug (im Sinne des Bezugs zweier Objekte zueinander) nichts zu tun. Deine ganze Argumentation bricht damit in sich zusammen - aber wie gesagt, es ist sowieso fahrlaessig, solche Behauptungen allein aus der (vermuteten) Bedeutung des Worts, das als key eingesetzt wird, abzuleiten. Und was spricht gegen die Nutzung von OSM als Router? Nichts natuerlich. Aber man sollte Daten nicht falsch eintragen, nur damit ein (schlecht programmierter?) Router bessere Arbeit machen kann. Und meines Erachtens ist es falsch, ein ref=A5 an etwas zu haengen, was nicht die A5 ist. nein, denn ref heisst Referenz . siehe oben. Genau, siehe oben ;-) Unglücklich gewählte Wortbedeutung? Hätte man etwas anderes nehmen sollen als ref? Fuer dieses Stuck Strasse fuehrt auf etwas, das A5 heisst wuerde ich in der Tat ein eigenes Tag erfinden. (Gibts uebrigens auch im innerstaedtischen Gebrauch manchmal - Strassenschilder mit Amselweg, Zugang zu Drosselweg oder so.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [Taggen von] GPS-Verleih-[Stationen]
Hallo, RalfGesellensetter wrote: Hintergrund ist, dass wir Anfang Juli eine Schüleraktion zu OSM planen, die Geräte der Geofabrik zu diesem Termin aber bereits an der Ostsee im Einsatz sind. Ich muss an der Stelle mal leicht korrigieren, um mich nicht mit fremden Lorbeeren zu schmuecken: Die Geraete waren nie von der Geofabrik, sie waren von B1 Systems und dem Linuxhotel gespendet worden, und die Geofabrik hat nur die Logistik gemacht (also das durch-die-Gegend-Schicken). Mittlerweile machen wir nicht mal mehr das, und Jan-Benedict Glaw macht die ganze Arbeit allein. Ich kriege gar nichts mehr mit vom GPS-Verleih, aber ich glaube, das ist ein gutes Zeichen. Danke, Jan-Benedict ,-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Quellen- und Lizenzangabe im Fernsehen
Hallo, Markus wrote: Aber bereits bei Fernsehfilmen wird der Abspann aus Kostengründen sehr kurz gehalten, da werden gerade mal der Autor und die Redaktion genannt. Und bei Nachrichtenbeiträgen fehlt sogar der Hinweis auf den Autor. Grundsaetzlich ist die Lizenz da recht freizuegig: Such credit may be implemented in any reasonable manner; provided, however, that in the case of a Derivative Work or Collective Work, at a minimum such credit will appear where any other comparable authorship credit appears and in a manner at least as prominent as such other comparable authorship credit. Kurzfassung: Autoren muessen in irgendeiner geeigneten Form genannt werden, aber mindestens so prominent wie andere Autoren, die einen vergleichbaren Beitrag leisten. Es geht also nicht, dass man heute eine Google-Karte in den Nachrichten zeigt, auf der gross Google in der Ecke steht, und morgen eine OSM-Karte, auf der das OSM nur halb so gross ist. Aber gerade bei Nachrichtensendungen werden Karten regelmässig eingesetzt. Dafür gilt es eine optimale Form zu finden. Wenn wir auf eine Public-Domain-Lizenz schwenken, fallen diese ganzen Fragen weg ;-) Ich denke, dass ein Lizenzhinweis sich nicht umgehen laesst, denn ich moechte wetten, dass irgendwo bei so einer Nachrichtensendung schon ein Hinweis auf das Urheberrecht ist ((c) 2010 ARD oder sowas). Dieser wuerde dann, in Abwesenheit eines Ausnahmehinweises, auch fuer die OSM-Karten gelten; der Sender wuerde damit nicht nur eine OSM-Karte ohne Lizenzhinweis abbilden, sondern sogar irrefuehrenderweise behaupten, die OSM-Karte unterlaege seinem Copyright, und der Nutzer wuerde (im besten Fall) erst nach einem Anruf beim Sender erfahren, dass die Nutzung frei ist. Jeder beliebige OSMer koennte den Sender deshalb vor Gericht zerren. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mautdaten
Hallo, hat jemand schon mal Mautdaten fuer deutsche Autobahnen in OSM erfasst? Vom Gefuehl her wuerde ich sagen, dass man fuer jede Anschlusstelle eine Relation machen muss, die alle highway=motorway_junction-Nodes dieser Anschlusstelle enthaelt, und dann fuer jedes Paar von benachbarten Anschlusstellen eine Relation (member sind dann die zwei AS-Relationen), in der praktisch das Autobahnsegment modelliert wird: Zwischen AS X und AS Y sind es 3,7 Mautkilometer. Oder? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mautdaten
Hallo, Stefan Dettenhofer (StefanDausR) wrote: korrelieren diese Daten nicht teilweise mit den TMC-Segmenten? Das weiss ich nicht, aber von den TMC-Segmenten halte ich mich lieber fern, sie sind mir nicht menschenlesbar genug ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Quellen- und Lizenzangabe im Fernsehen
Hallo, Markus wrote: Ich fürchte auch, dass es problematisch sein könnte, dass wir uns manchmal so schwer tun, klare verbindliche Aussagen zu machen (und unsere Partner dann immer ein bisschen Angst haben müssen, von irgend einem zänkischen Menschen vor Gericht gezerrt zu werden). Das Wort Partner ist nicht angebracht fuer jemanden, der eine OSM-Karte in einer Fernsehsendung verwendet. Das von Dir geschilderte Problem ist nur loesbar, indem man entweder auf Public Domain schwenkt (wird in absehbarer Zeit m.E. nicht passieren), oder indem jeder seine Rechte an eine Organisation (z.B. OSMF) abtritt, die dann verbindlich entscheiden kann, ob etwas zulaessig ist oder nicht. Im GPL-Bereich wird das in manchen Projekten so gemacht, dass alle ihre Rechte an die FSF abtreten, vor allem, damit die dann auch mit groesseren Erfolgsaussichten klagen kann. Ich stehe so etwas eher kritisch gegenueber, ich mag maechtige zentrale Organisationen nicht so. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wahlen zum Vorstand der OSMF
Hallo, anlaesslich der diesjaehrigen State of the Map-Konferenz in einem Monat wird es auch eine Mitgliederversammlung der OpenStreetMap Foundation (OSMF) geben, auf der mindestens drei neue Vorstandsmitglieder gewaehlt werden. Der Vorstand besteht derzeit aus Steve Coast * Mike Collinson Simone Cortesi Henk Hoff Mikel Maron * Ulf Moeller * Andy Robinson Die mit einem * markierten Personen haben bereits erklaert, dass sie ihre Posten raeumen werden. Fuer die anderen steht moeglicherweise keine Wiederwahl an, so genau weiss ich das gar nicht, aber fest steht, dass mindestens drei Vorstandsmitglieder neu gewaehlt werden muessen. Da mit Ulf auch unser Mann bei der OSMF ausscheidet, und da Deutschland immerhin um die 40% der aktiven OSM-Community stellt, faende ich es extrem wuenschenswert, wenn sich ein oder zwei Leute aus unseren Reihen faenden, die im OSMF-Vorstand mitzuarbeiten bereit sind. Die kommende Amtszeit wird ohne Frage spannend, weil ja der Lizenzwechsel ansteht - irgendwann wird feststehen, wie viele Leute ihre Daten re-lizensieren und wie viele nicht, und dann wird der amtierende Vorstand entscheiden muessen, ob man die ganze Sache kippt oder weitermacht, und was genau dann mit den alten Daten passiert. Natuerlich beschaeftigt sich die OSMF auch mit anderen Dingen wie dem Einwerben von Sponsorengeldern und der Verwaltung der Hardware und so weiter. Die Foundation arbeitet mit regelmaessigen (ich glaube, einmal monatlichen) Telefonkonferenzen. Wer sich also in den Vorstand waehlen laesst, muss weder staendig nach England reisen, noch ueberhaupt zur SOTM anwesend sein (die meisten Mitglieder geben ihre Stimmen eh im Vorfeld per Email ab). Was man sein muss, ist OSMF-Mitglied, aber das ist eine Sache von fuenf Minuten. Die genauen Wahlmodalitaeten sind noch nicht klar, das wird alles wieder mal ziemlich knapp, aber ich rechne damit, das die OSMF in Kuerze um die Meldung von Kandidaten bitten wird. Also ueberlegt Euch mal, ob das was fuer Euch waere - ich waere froh, wenn wir wieder jemanden aus Deutschland entsenden koennten. Wer Ulfs Vortrag ueber die OSMF-Arbeit auf der FOSSGIS nicht gehoert hat, dem wird Ulf sicher gern auch per E-Mail Fragen dazu beantworten. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder in Website einbinden
Hallo, Markus wrote: Ich suche nach einer Möglichkeit, Luftbilder so in eine Website einzubinden, dass man umschalten kann zwischen OSM-Karte und Luftbild, wobei sich die jeweiligen Ausschnitte und Zoomstufen entsprechen sollen. Um eine geeignete Technologie vorschlagen zu koennen, muesste man wissen, welcher Art die Luftbilder sind, also von was fuer einer Art Server sie kommen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Luftbilder in Website einbinden
Hallo, Markus wrote: Um eine geeignete Technologie vorschlagen zu koennen, muesste man wissen, welcher Art die Luftbilder sind Die Luftbilder sind von der Art, wie sie von der Stadt Lauf kommen. Als Pilotprojekt könnte die Einbindung auf der Website der Stadt erfolgen. Dann kannst Du auf der Client-Seite OpenLayers einsetzen, und auf der Serverseite brauchst Du entweder einen WMS-Server, der die Bilder bereitstellt (z.B. UMN Mapserver), oder Du musst die Bilder vorher alle in Kacheln umrechnen und auf einem Webserver bereitstellen. Die Serverseite ist dabei vermutlich der aufwendigere Teil. Sven Geggus macht das ja fuer osm.de. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eilt - Bitte meine Changesets 4940188, 4940508 und 4940548 zurücknehmen
Hallo, Dietmar wrote: Bitte diese drei Changesets komplett zurücksetzen, danke und großes Sorry für die Mühe! Schon dabei, Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jogging-Rundstrecken
Hallo, Werner Hoch wrote: Hier wird als Rolle stop_nummer empfohlen: http://wiki.openstreetmap.org/wiki/EN:Switzerland/Parcoursvita (Den Link hatte ich vorhin vergessen.) Die Mischung von Rolle und Nummer finde ich nicht gut. Das ist vermutlich noch aus der Zeit, als Relationsmitglieder nicht geordnet waren und man daher staendig mit einer Durchmischung rechnen musste. Das braucht man heute nicht mehr. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Pressebericht - Reaktionen des Rathauses
Hallo, Jens Frank wrote: http://www.maerkischeallgemeine.de/cms/beitrag/11817773/61939/Christopher-Lorenz-digitalisiert-die-Heimatregion-Im-Rathaus-laesst.html findet sich ein Bericht über einen Openstreetmapper. Interessant ist der letzte Absatz. Das passiert oefters, dass Presseleute uns mit Google in einen Topf werfen bzw. eben nicht zwischen Karten und Streetview unterscheiden. Ich versuche immer, das prophylaktisch irgendwo in die Erklaerung einfliessen zu lassen, wenn ich sage, wie Mappen geht - nach dem Motto: Viele von uns machen auch Fotos, um die Strassennamen spaeter ablesen zu koennen, aber zu mehr brauchen wir die Fotos nicht, denn es geht uns ja um eine Karte... oder so. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Multipolygone
Hallo, Christian H. Bruhn wrote: Allerdings habe ich dieses Tagging bisher kaum gesehen. Meckern nicht auch alle Überprüfungs-Tools über die Wege ohne Tags rum? Falls das zutrifft, waere es hoechste Zeit, die Ueberpruefungstools zu reparieren ;-) Wäre es dann nicht auch sinnvoll, das MP-Plugin in JOSM so zu gestalten, daß die Tags vom äußeren Way auch die Relation verschoben werden? Ich kenne das Plugin gar nicht; was macht das denn, wenn man mehrere aeussere Ways hat? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki bzgl. ref auf motorway_link ändern/ergänzen und ref dort ersetzen/entfernen? (war: Re: motorway_link mit ref taggen oder etwa nicht ???)
Hallo, steffterra wrote: Dass man nun eine Unterscheidung zwischen einem highway_link im Verkehrsraum Autobahn und einem highway_link außerhalb des Verkehrsraums Autobahn (normale Abfahrt auf Bundesstraße) macht, geht weder aus der Wiki-Seite für ref, noch aus der wiki-Seite für motorway noch aus der für motorway_link hervor. (Das gleiche analog dazu für trunk_link und secondary_link). Ich finde ehrlich gesagt ein ref an einer Ueberleitung von einer Autobahn auf die andere genauso irrefuehrend wie irgendwo sonst an einem motorway_link. Auf der Seite zu ref findet sich dazu nichts im Wiki. Auf der englischen Seite zu motorway_link wurde am 10.5.2008 von Henry Loenwind folgendes ergaenzt: Note: For Germany the links between the main motorways should be tagged with the ref=* of the motorway they are going to. Er gibt dazu keinerlei Kommentar oder Quelle an. Als im Dezember 2008 die deutsche Version der Seite erstellt wurde, ist das einfach so uebernommen worden. Ich wuerde empfehlen, das einfach zu entfernen. Ich weiss nicht, wer sich das ausgedacht hat; sein for Germany zeigt ja, dass es offenbar schon damals eine deutsche Spezialsache war. Von einer grossflaechigen Entfernung von ref-Tags an motorway_links wuerde ich aber trotzdem abraten - so wichtig ist die Einheitlichkeit dann auch wieder nicht, als dass man da mit der Drahtbuerste ueber die Daten rueberfahren muss. In ein paar Tagen macht eh wieder jemand ein ref irgendwo dran ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wehrkiche?
Hallo, aighes wrote: Die Diözesengrenzen wird wohl irgendwer irgendwann eintragen (ist das dann boundary=roman_catholic? grübel), fürchte ich... ;) Auch wenn ich es persönlich interessant finden würde, bin ich der Meinung, dass das nicht in OSM gehört. Ansonsten haben wir bald alle möglichen Grenzen. Mit dem gleichen Recht wie Dioezesengrenzen koennte man auch das Aldi-Nord-Gebiet und das Aldi-Sued-Gebiet eintragen (boundary=retail) oder die Einzugsbereiche der Lokalgruppen der tausenden bundesweiten Vereine. Solche Grenzen orientieren sich manchmal an vorhandenen Landes- , Kreis- oder Gemeindegrenzen, manchmal aber auch nicht. Das wird dann ein ganz schoenes Dickicht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wehrkiche?
Hallo, Bernd Wurst wrote: Auch beim Einzugsgebiet z.B. eines Vereins oder einer Lokalgruppe von irgendwas gibt es keine klare Grenze, jeder kann problemlos im Sportverein der Nachbargemeinde Mitglied werden wenn er Bock drauf hat. Nein, viele deutschlandweite Vereine haben da ganz klare Grenzen, wenn einer in A wohnt, gehoert er zu diesem Lokalverein, wenn er in B wohnt, zu einem anderen. In der untersten Ebene bei den Kirchengemeinden gibt es aber ähnlich zu weltlichen Verwaltungseinheiten eine klare Zuordnung jedes Wohnhauses zu einer Kirchengemeinde. Ich gehe schon davon aus, dass das irgendwann in OSM landet, denn es macht irgendwie Sinn. Hier in Baden-Wuerttemberg haben wir sowas auch fuer Grundschulen, da gibt es eine Ordnungsebene, die oft noch unterhalb der Stadtteilgrenzen liegt, bei der auch jedes Haus einer bestimmten Grundschule zugeordnet ist. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Gewässerrelationen
Hallo Lothar, Lothar Beck wrote: Soweit ich das gemäß: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Gew%C3%A4sser verstanden habe gehört jedes Fließ-Gewässer in eine Relation und die Relation im Wiki eingetragen. Das ist beides eine sehr seltsame Idee, ich habe das auf der Wikiseite mal verbessert. Genauso, wie wir eine Strasse in mehreren verschiedenen Ways modellieren koennen, ohne dafuer eine Relation zu brauchen, ist das auch fuer Fluesse. Es gibt gar keinen Grund, fuer jeden kleinen Fuzzelfluss eine Relation anzulegen - bzw. wer immer sich das ausgedacht hat, wollte damit wohl erreichen, dass man leichter aus dem Wiki auf die Fluesse verlinken kann, aber auch das ist *nicht* der Zweck von Relationen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Währungen mappen
Hallo, Tobias Knerr wrote: Ich will jetzt nicht sagen, dass OSM der beste Platz für diese Information ist - Wikipedia wird aber auch nicht allen Anforderungen gerecht und ist eben insbesondere keine Datenbank. *Wenn* man sowas in OSM mappt, sollte man es nicht an eine Grenze haengen, denn die Waehrung ist keine Eigenschaft der Grenze. Man sollte wenn schon eine Relation fuer ein Land anlegen, mit den Tags: name=... waehrung=... einwohnerzahl=... ... und den Members hauptstadt=(node) grenze=(relation der grenz-ways) ... oder dem entsprechenden englischsprachigen Aequivalent. Finde ich zumindest. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Frage zu Gewässerrelationen
Hallo, Karl Eichwalder wrote: Außerdem hattest du mal gesagt, dass wir wahrscheinlich für jede straße mal eine relation brauchen werden ;) Ich hab auch schon gesagt, dass wir irgendwann fuer jede Strasse eine Flaeche haben werden. Aber sowas zu sagen und eine Wikiseite zu machen, auf der steht, dass fuer jede Strasse eine Flaeche gemappt werden muesse, sind doch zweierlei Dinge ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
Hallo, Nun aber zur Frage. Die Firma bietet kostenlose Seiten an und auch kommerzielle Produkte und würde gerne ihr Material durch OSM Material für Fuß- und Radwege ergänzen. Wir beide waren uns aber nicht sicher, ob das lizenzrechtlich überhaupt möglich ist. Die Karten verwenden momentan NavTeq- und firmeneigenes Material. Besteht nun die Möglichkeit OSM Material mit entsprechendem Hinweis einzubauen oder nicht und wenn ja, was für Konsequenzen hätte das für das komplette Produkt? Kann das die alte Lizenz beibehalten oder muss die CC Lizenz auf das Gesamtpaket angewendet werden? Du hast nicht genau genug gesagt, worum es geht, um diese Frage zu beantworten. Im allgemeinen ist die Faustregel: Wenn OSM-Daten und andere Daten in ein untrennbares Ganzes vermischt werden, dann muss das Ganze unter CC-BY-SA stehen. Wenn die Firma z.B. Routinggeraete anbietet und nun Navteq-Daten und OSM-Daten vermischt und daraus ein Datenfile fuer die Geraete macht, muss das Datenfile unter CC-BY-SA stehen. Oder wenn die Firma Karten zum Download anbietet, dann die gesamte Karte. Wenn die Daten aber getrennt bleiben, also wenn die Firma z.B. an die Kunden eine OSM- und eine Navteq-Datei ausliefert und die Software kundenseitig dann beides einliest und daraus ein Routing berechnet o.ae., dann koennten beide Datensaetze unter ihrer jeweiligen Lizenz bleiben. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] REGEX in PERL wieder mal
Hallo, Florian Lohoff wrote: On Fri, Jun 11, 2010 at 08:53:00PM +0200, Claus Färber wrote: Ansonsten nimm einen echten XML-Parser wie XML::Parser. Den gibt es fertig auf CPAN und ist oft eh schon installiert. Der punkt ist das fast alle scripte die OSM daten weiterverarbeiten keinen wirklichen XML parser nehmen sondern meist nur mit perl dahingebastelte sachen die exakt fuer dieses format passen. Dazu kommt das die OSM Daten auch sicherlich nicht mit beliebigem inhalt gefuellt sein koennen weil defakto nur eine datenbank gedumped wird deren format reichlich steif ist. Richtig. Ein guter Hacker weiss eben, wann er welche Technik am besten einsetzt - und gerade in Perl ist das Parsen mit Regex gern mal um den Faktor 10 schneller. Wenn ich also eh weiss, dass ich nur Planetfiles verarbeiten will, ist ein XML-Parser oft Overkill. (Insbesondere kann man beim Parsen von Hand solche Spielchen machen wie mit seek() und binaerer Suche innerhalb von 1 Sekunde an den Anfang der way-Sektion zu springen, wenn man die zuerst einlesen will, statt erstmal 100 GB Nodes zu parsen und dann wegzuwerfen.) Andererseits muss man sich im Klaren sein, dass man irgendwelche seltsamen UTF8-Spaesse o.ae. oder gar ein von Drittprogrammen ausgegebenes, erweitertes XML eben nicht unbedingt erwischt. Ach ja - und wir koennen ja nochmal ein libxml vs handcraftet shootout fuer das planet file machen ;) http://lists.openstreetmap.org/pipermail/dev/2009-November/017811.html Im moment spiele ich ein wenig mit parallelen libxml parsern rum um das planet in endlicher zeit zu lesen und in space optimized abzuspeichern bzw im speicher zu halten (Koennte ab 16GB gehen) ... Ich fand dies hier spannend (ueber ein neues Binaerformat): http://lists.openstreetmap.org/pipermail/dev/2010-April/019370.html an entire planet, including all metadata, can be read in about 12 minutes and written in about 50 minutes on a 3 year old dual-core machine Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 1-Euro-Jobber als Mapper einsetzen
Hallo, Thomas wrote: Weiß jemand, ob es ähnliche Projekte schon gibt oder gegeben hat? Ich weiss von keinen. Denkt Ihr, dass das gut gehen kann? Normalerweise mappen bei OSM Leute, die das gerne wollen, nicht Leute, die dafuer bezahlt werden. Wenn jemand an OSM mit der Haltung sag mir genau, was ich machen muss, sonst gehts nicht rangeht, wird das nichts. Ich koennte mir vorstellen, dass mein paar von den Teilnehmern tatsaechlich anfixen kann, dass sie verstehen, dass sie da wirklich was Sinnvolles tun. Wenn man das hinkriegt - eventuell sogar etwas Zeit investiert, auf den Einzelnen einzugehen und irgendwas zu finden, wo OSM z.B. fuer ein Hobby einen sichtbaren Nutzen bringt, dann koennte das vielleicht sogar was werden. Bloss wer lustlos zu Werke geht, ist fuer OSM wenig nuetzlich. Es steht und faellt also mit den ueblichen Bildungstraegern, von denen Du sprichst... Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 1-Euro-Jobber als Mapper einsetzen
Hallo, Sven Geggus wrote: Die Gemeinde dürfte bereits im Besitz hochgenauen Ausgangsmaterials sein das einfach nur zur Verfügung gestellt werden müsste. Aber sagen wir nicht immer selbst, dass die offiziellen Daten gar nicht so gut sind? Ich zumindest sage das. Und ob die dann auch die Briefkaesten und Telefonzellen enthalten? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
Hallo, Josias Polchau wrote: wie ist es mit der neuen lizenz? im wiki habe ich dazu nichts gefunden... Das Wiki hat ungefaehr 40 Seiten zur neuen Lizenz: http://wiki.openstreetmap.org/wiki/Category:Open_Data_Licence generell wurde doch gesagt dass sich um großen und ganzen nichts ändern wird... ist das korrekt? Wenn die Frage etwas konkreter gewesen waere, dann haette ich darauf eingehen koennen, aber da der OP nicht gesagt hat, worum es eigentlich geht, faellt es mir schwer, hier etwas sinnvolles zu sagen. Es gibt einige wenige Anwendungsfaelle, bei denen sich durch die neue Lizenz viel aendert (also bei denen man etwas nicht mehr so machen kann wie vorher), aber bei den meisten wird alles beim alten bleiben. Die wichtigste Aenderung ist dort, wo jemand bisher OSM-Daten und proprietaere Daten zu einer gemeinsamen Datenbank zusammengefuehrt und daraus dann ein abgeleitetes Werk produziert hat - Beispiel: Du hast Verkehrsdichte-Infos und faerbst danach OSM-Strassen ein und bringst das als PNG auf Deine Webseite. In solchen Faellen galt bisher: das PNG muss CC-BY-SA sein, nach Deinen Verkehrsdichte-Daten kraeht kein Hahn. Kuenftig: Deine Verkehrsdichte-Daten muessen ODbL sein, nach dem PNG kraeht kein Hahn. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 1-Euro-Jobber als Mapper einsetzen
Hallo, Sven Geggus wrote: Ich halte es daher ehrlich gesagt für völlig Blödsinnig öffentliche Gelder für das abzeichnen von Luftbildern oder gar für GPS basiertes Mapping einzusetzen. Ich will gar nicht weiter pro oder contra 1-Euro-Jobber argumentieren, aber 1. geht geht es, wie hier bereits festgestellt wurde, bei der Sache primaer darum, ein Vehikel zu finden, um Menschen etwas halbwegs sinnvolles arbeiten zu lassen; 2. Meiner Ansicht nach ist es auf jeden Fall sinnvoll, diese Daten zu erheben, auch wenn das Katasteramt vielleicht schon welche hat; wir haben in der Vergangenheit gesehen, dass die Realitaet und die amtlichen Daten nicht selten auseinanderklaffen. 3. Wie wir ebenfalls aus eigener Erfahrung wissen, ist es oft mit weniger Aufwand verbunden (und daher auch oekonomisch sinnvoller), Daten selbst neu zu erfassen, als auf administrativen Wegen ihre Herausgabe zu erreichen - besonders dann, wenn die Daten womoeglich in vielen verschiedenen Aemtern gehalten werden (A hat die Restaurants, B die Briefkaesten, C die Strassenbeleuchtung und D die Strassenbahnschienen). Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
Hallo, Josias Polchau wrote: Das gilt nicht nur für Veröffentlichungen sondern auch für interne Prozesse (zb Vergleiche), oder? Wenn am Ende des internen Prozesses eine Veroeffentlichung steht, ja. dh man kann auch keine OSM Daten mit andern Daten vergleichen? Das kann man so pauschal nicht sagen. So richtig ins Detail hat sic das auch bisher kaum jemand ueberlegt. Streng genommen kommt es dabei vermutlich auf den Algorithmus an. Angenommen, Du vergleichst OSM- und Navteq-Daten, und willst eine eingefaerbte Deutschlandkarte herstellen (rot=Navteq hat mehr, gruen=OSM hat mehr). Dann wuerdest Du ja intern zunaechst fuer jedes Planquadrat eine OSM-Strassenkilometer-Zahl berechnen und eine Navteq-Strassenkilometer-Zahl. Diese wuerdest Du dann zu der Information rot/gruen verknuepfen. Meiner Ansicht nach muesstest Du nun die rot/gruen-Datenbank freigeben, also welches Planquadrat welche Farbe hat. Mehr nicht. Aber das ist ein interessantes Thema, ich werde das gleich mal auf legal-talk in die Runde werfen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
Hallo, Benjamin Lebsanft wrote: es ging einfach nur darum, ob es möglich ist OSM und NavTeq Daten in einem Produkt zu verwenden, ohne das Gesamte unter CC-SA-BY stellen zu müssen. Da das ja mit NavTeq Daten nicht geht, hat sich die das Ganze schon geklärt. Ich glaube uebrigens, dass das auch schon von Navteq-Seite aus schwierig ist, zumindest weiss ich, dass man Navteq und TeleAtlas nicht mergen darf - ob das jetzt an den Lizenzbestimmungen von Navteq oder denen von TeleAtlas liegt, weiss ich nicht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fragen zur CC-BY-SA Lizenz
Hi, Josias Polchau wrote: wie macht das dann google? die benutzen ja schließlich auch verschiedene anbieter... Eventuell ist es zulaessig, verschiedene Quellen auf die gleiche Karte zu rendern, aber nicht, sie in einer Datenbank zu vermischen. - Oder Google hat aufgrund seiner Marktmacht eine Ausnahme bekommen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 1-Euro-Jobber als Mapper einsetzen
Hallo, Ulf Möller wrote: Soweit ich sehe, kann die Behörde Ein-Euro-Jobber sowieso nicht verpflichten, eine Lizenz für ihre Daten zu erteilen. D.h. für OSM wären die so erfassten Daten nutzlos... Bist Du da sicher? Fuer Computerprogramme ist das sogar direkt im UrhG geregelt: http://www.gesetze-im-internet.de/urhg/__69b.html Ich denke aber, dass fuer Erfindungen und andere schoepferische Leistungen normalerweise was im Arbeitsvertrag steht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausdruck Karten
Hallo, M∡rtin Koppenhoefer wrote: Ist irgendwo beschreiben, wie man gerenderte (nicht Vektorkarten) OSM-Karten verschiedener Renderer (z.B. Cyclemap) in hoher Auflösung und z.B. A0-Größe gekachelt auf A4 ausdruckt? Oder geht so etwas prinzipiell nicht? es geht in der Tat prinzipiell nicht befriedigend in hoher Auflösung mit Karten, die für niedrige Auflösung gerendert sind, da die Schrift- und Icongrößen sowie die Linienbreiten und alles andere logischerweise nicht angepasst sind. Mit Vektoren wäre es dagegen problemlos möglich. Vorausgesetzt, man kommt ueberhaupt an Vektordaten, was im Falle der als beispiel genannten Cyclemap nicht ohne weiteres moeglich ist. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausdruck Karten
Hallo, Wolfgang Wienke wrote: Ich hatte mir mal Vektorkarten geladen. Da sie ALLE Details enthalten haben sie auch eine erheblich Dateigröße. Wenn Du mit Mapnik eine SVG-Datei erzeugst, sind da mitnichten alle Details enthalten, sondern nur die, die Mapnik im entspr. Zoomlevel auch rendert. So gehe ich normalerweise vor, wenn ich grossformatige Karten drucken will. Voraussetzung ist, dass man die gesamte interessierende Gegend mit osm2pgsql in eine PostGIS-Datenbank eingelesen und die aktuellen Styles aus dem OSM-SVN installiert hat. Dann kann man so eine hochaufloesende Haiti-Karte z.B. so erzeugen: nik2img.py stylesheet_tile.xml -sepsg:900913 -fsvg -b -74.59 17.91 -71.61 20.02 -d 6000 4254 image.svg (-b ist der Ausschnitt, -d ist die Ziel-Aufloesung, die bei Vektor-Ausgabe natuerlich nicht wirklich eine Pixelzahl ist, sondern nur ein Anhaltspunkt, anhand dessen Mapnik die Detailstufe waehlt). Dann wandelt man vor dem Drucken in ein PNG um: rsvg -d200 -p200 image.svg haiti.png Das alles geht aber eben nicht z.B. fuer die Cyclemap, weil davon die Styles nicht offen vorliegen (und ausserdem noch einige Huerden bezgl. der Hoehenschummerung zu ueberwinden waeren). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Hallo, Alexander Matheisen wrote: Meine Vorstellung dazu ist, nur eine Sprache in das neue Format zu bringen und die alten in ihrem Format zu lassen. Das ist doch aber eine ziemlich obskure Loesung. Nachher hat man also Objekte, die so getaggt sind: wikipedia=de:Baum wikipedia:en=Tree wikipedia:fr=... - das kann doch niemand allen Ernstes gutheissen? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ausdruck Karten
Hallo, M?rtin Koppenhoefer wrote: Am 20. Juni 2010 14:43 schrieb Frederik Ramm frede...@remote.org: nik2img.py stylesheet_tile.xml -sepsg:900913 -fsvg -b -74.59 17.91 -71.61 20.02 -d 6000 4254 image.svg rsvg -d200 -p200 image.svg haiti.png hat das Vorteile, hier über die svg zu gehen, wenn man zum Drucken dann doch ein png macht? Kannst Du das svg nicht über ps drucken? Das kommt drauf an, mit welcher Technologie man druckt. Wenn man nicht gerade einen Plotter benutzt, muss eine Rasterisierung irgendwann stattfinden, und ich habe da mit dem rsvg bislang die besten Erfahrungen gemacht. Aber man koennte auch das SVG z.B. in PDF wandeln und dann drucken, je nachdem, was der Drucker eben frisst. Wenn ich ein png haben wollte würde ich wohl gleich mapnik verwenden, weil der eigentlich ein ganz gutes antialiasing macht. Das kannst Du tun, wenn Du den development-Branch mapnik_resolution compilierst. Die gewoehnlich im Umlauf befindlichen Mapnik-Versionen sind nicht in der Lage, die Druckaufloesung unabhaengig vom Massstab zu setzen, d.h. Du kannst also immer nur 96dpi-PNGs erzeugen. Ein Workaround ist es, das Map-File per Skript so anzupassen, dass alle Schriftgroessen und Strichstaerken ca. ver4facht werden. Aber das ist alles sehr laestig, und der Weg ueber SVG, wie von mir geschildert, geht besser. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Hallo, Alexander Matheisen wrote: Man kann sie auch löschen, im Prinzip ist es mir egal, mie man damit verbleibt. Für mich interessant wäre eben nur, dass ein Tag in der Form wikipedia=de:Baum da ist. Ja, das habe ich verstanden. Aber Ulf hat recht, wenn er sagt, dass ich bin nicht in der Lage, die Daten geeignet nachzubereiten, und moechte gern moeglichst bequem alles finden, was irgendeinen Wikipedia-Link hat kein ausreichender Grund ist, ein etabliertes Taggingschema ueber den Haufen zu werfen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bot zur Änderung von Wikipedialinks?
Hallo, Alexander Matheisen wrote: Aber man sollte natürlich auch aus rein technischer Sicht sehen, was sinnvoller ist: Allesfressende, langsame Anwendung oder konsistente, Regeln folgende Datenbasis. Die Datenbasis folgt im konkreten Fall ja Regeln, bloss gefallen Dir diese Regeln nicht. Es ist aber faktisch unmoeglich, fuer jede Art der Anwendung die richtigen Regeln zu haben. Deswegen ist es vernuenftig, im Wege der Datenaufbereitung die Daten genau so hinzubasteln, wie man sie fuer die Anwendung braucht - so macht es ja z.B. auch das osm2pgsql/Mapnik-Gespann. Nicht vernuenftig hingegen ist die Annahme, dass das Datenformat, das fuer einen selbst gerade mal praktisch ist, auch fuer alle anderen praktisch ist, und dass doch deswegen am besten alle das benutzen sollten, was man selber braucht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrrad-Access-Map
Hallo, Andreas Tille wrote: Fahrradrouten haben aber einen Namen, Hinweisschilder von wo nach wo, einen Operatoer etc. Das alles trifft für oben genannte Gegebenheit nicht zu. Ich denke nicht, dass das Fehlen einer Beschilderung gleich auch bedeutet, dass das keine Fahrradroute ist. Aoßerdem stellt sich die Frage: Bevorzugen Router für Fahrräder Teile von oben genannten Fahrradrouten oder richten sie sich ausschließlich nach den verwendeten Tags. Das ist sicherlich von Router zu Router unterschiedlich. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Daten auf Verlangen löschen oder nich t ...?
Hallo, irgendeine Art von Rechtsanspruch auf Loeschung (oder Nichterhebung) der Daten besteht nicht. Trotzdem wollen wir ja von der Bevoelkerung nicht als Feinde wahrgenommen werden. Ich wuerde also im konkreten Fall auf eine Erfassung des Wegs verzichten, wohl wissend, dass sich OSM niemand in den Weg stellen kann - wir der Weg heute nicht von mir gemappt, kommt morgen jemand anders. Frueher oder spaeter kriegen wir Sie ;-) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] xybot / name tag korrektur
Hallo, Andreas Labres wrote: xybot soll keine Namen aendern - full stop. Namen unterliegen keinen Regeln. +1 Das ist auch schon immer meine Ansicht gewesen. Man kann natuerlich daruber Mutmassungen anstellen, ob die Freiherr-von-Stein-Schule eigentlich eher haette Freiherr-vom-Stein-Schule heissen sollen, aber wenn sie nun mal eben mit N geschrieben ist, dann muss man das so hinnehmen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Hochauflösende Aufnahmen der Erdkugel
Hallo, On 06/26/2010 03:18 PM, Jan Kolarik wrote: Ich nehme an die Daten werden mangels Veröffentlichung, ausreichend freier Lizenz, bzw. immer noch unzureichender Auflösung für OSM uninteressant sein(?). Auf der Webseite zum Launch ist ein Videofilm, in dem es unter anderem heisst, die wissenschaftliche Verwertung der Daten wuerde von der DLR uebernommen, und die Daten haetten natuerlich auch einen betraechtlichen kommerziellen Nutzen. Da hoere ich heraus, dass es im allerbesten Fall eine fuer OSM immernoch ungenuegende noncommercial-Lizenz geben kann. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gaststättenkarte
Hallo, Christian Schmitt wrote: schöne Karte, Kompliment, 1 kleiner Bug ist mir noch aufgefallen: die Farben scheinen invertiert, Nichtraucherlokale sind grün und Raucherlokale rot markiert, wäre es nicht anders rum logisch? Du meinst: Aus der Sicht des Rauchers? Nein, bei Logik geht es nicht darum, aus wessen Sicht, genauso wenig wie es bei der Addition von 1 und 1 auf die Sichtweise ankommt. Eine rote Ampel signalisiert ein Verbot (des Weiterfahrens). Eine Gaststaette, in der das Rauchen verboten ist, sollte also logischerweise mit einer roten Ampel gekennzeichnet werden. Es ist ja nicht so, dass Nichtrauchern der Zutritt zu einer Rauchergaststaette verwehrt wuerde. Mir ist schon klar, dass die politische Intention dieser Karte ist, Rauchergaststaetten als negativ darzustellen und dass daher diese Farbwahl getroffen wurde. Es ist auch jedermanns gutes Recht, eine Karte so zu gestalten, dass sie den von ihm gewuenschten politischen Effekt hat (dazu werden Karten benutzt, seit es sie gibt). Nur logisch ist die Karte so nicht, da hat Martin voellig recht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wahlen zum OSMF Board
Hallo, Lars Francke wrote: wie einige von euch vielleicht mitbekommen haben werden bei der State of the Map am 11. Juli drei neue Mitglieder für das Board der OpenStreetMap Foundation gewählt. Ich habe entschlossen mich dort aufzustellen[1], da mit Ulf Möller das letzte deutsche Mitglied im Board ausscheiden wird und ich denke, dass wir als große Community eine Vertretung gebrauchen können. Ausser Lars steht auch noch Oliver Kuehn (ebenfalls hier von der Liste bekannt) zur Wahl, und ferner noch Kate Chapman und Thea Clay (USA), Ivan Sanchez (Spanien) und Emilie Laffray (UK/Frankreich). Ich freue mich, dass sich mit Lars und Oliver gleich zwei Kandidaten aus Deutschland gefunden haben und danke beiden fuer ihre Bereitschaft, bei der OSMF mitzuarbeiten. Ich wuensche beiden, dass sie gewaehlt werden - als groesste und aktivste nationale OSM-Community waere es durchaus ok, wenn wir auch in der OSMF gut vertreten sind. OSM ist zwar ein internationales Projekt, aber in der Vergangenheit hat sich doch schon oefter gezeigt, dass alles moegliche - gute wie schlechte - bei OSM in Deutschland zuerst probiert wird, und dadurch bringen Kandidaten aus Deutschland immer so ein bisschen den Blick in die Zukunft rein. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo Routingfunktion openstreetmap,org
Hallo, On 07/03/2010 09:24 AM, steffterra wrote: Ist doch noch heavy beta. Ist ja nicht umsonst nur auf der dev-Seite. Also warum nicht erstmal abwarten, was noch passiert, und dann nochmal drüber schauen, ob das gewünschte funktioniert. Weiss eigentlich jemand, ob da cloudmade seine Finger mit im Spiel hat, oder ob das von denen _völlig_ unabhänig ist? Cloudmade hat damit nichts zu tun. Der hier benutzte Algorithmus ist eine Imlpementierung von Nic Roets, der vor Jahren der erste war, der mit gosmore ueberhaupt Roting auf OSM-Daten gemacht hat. Cloudmade selbst bietet auch Routing an, aber das basiert auf einem ganz anderen Algorithmus und hat nichts mit Nics Arbeit zu tun. Ich finde Nics Demo interessant, nehme aber an, dass sie fuer den praktischen Einsatz auf www.openstreetmap.org nicht in Frage kommt, weil sie nicht schnell genug dafuer sein wird (@Sven G.: pfeilschnell ist bei mir was anderes!); er verwendet einen zwar flexiblen, aber recht langsamen Algorithmus. Aber Frontend und Backend sind hier ja relativ gut separierbar, also man koennte durchaus spaeter mal hinter das gleiche Frontend ein leistungsfaehigeres Backend bauen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konflikt lösen beim Hochladen mit JOSM
Hallo, Chris66 wrote: Mir ist aufgefallen, dass der schnelle Mapnik Update nicht mehr funktioniert. Hat das was mit dieser Replication zu tun ? Ja, Mapnik hat eine eigene Datenbank, die minuetlich mit Osmosis+osm2pgsql aktualisiert wird. Keine Replikation heisst, dass die Osmosis-Updates nicht gehen. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (J)OSM Flickr
Hallo, Benjamin Lebsanft wrote: Alle die am Projekt mitmachen? Weil wenn jemand geschützte Daten einpflegt und alles in dem Bereich gelöscht wird, dann leidet das gesamte Projekt. War damals glaub in Irland mal der Fall. Litauen. Wir haben im Maerz 2009, nach rund einem halben Jahr Nachforschung, praktisch ganz Litauen geloescht und sogar alte Planet-Files bereinigt: http://lists.openstreetmap.org/pipermail/talk/2009-March/035290.html So grosse Sachen passieren aber selten. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP
Hallo, Thorsten Kunkel wrote: sehr guten WMS mit Luftbildern abzeichnet. Aufgrund der gemappten Wege habe ich den WMS des Landesamtes für Vermessung und Geoinformation (LVG) Bayern im Verdacht. Ich hatte mit dem Benutzer im August 2009 Kontakt, und er versprach damals, diese Quelle nicht mehr zu verwenden. Wie sicher ist es, dass er es dennoch tut? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutsche OSM-Technik-HowTos
Hallo, Jan Tappenbeck wrote: Habe aber einmal eine ganz andere Frage in diesem Zusammenhang - wenn ich mit Postgis arbeite, dann muss diese DB immer auf dem Server laufen oder ...? Dann hätte ich mit einfachem Webspace vermutlich schlechte Karten oder ... ? Ja, mit einfachem Webspace kommst Du nicht weit. Aber je nachdem, welche Gegend und bis zu welchem Zoomlevel Du rendern willst, kannst Du die Tiles natuerlich vorbereiten und dann einfach auf einen Server kopieren, fuer den Server reicht dann einfacher Webspace. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ... pack - ftp - unpack ....
Hallo, Jan Tappenbeck wrote: hat einer von euch schon einmal eine lösung gebastelt bei der die tiles lokal gezippt werden, dann dieses große file hochgeladen wird (soweit auch für mich kein problem) und dann erst auf dem webserver ausgepackt werden. % cd /wo/meine/tiles/liegen % tar -czf - . | ssh mein.web.server cd /wo/dort/die/tiles/hinsollen; tar -xzf - Da muss man nichts basteln, das geht einfach so ;) Wenn Du FTP benutzen musst, kannst Du ja das tar.gz (oder auch zip-File) rueberkopieren und auf der anderen Seite auspacken. Falls Du eine Loesung meinst, bei der die grossen Files auf dem Webserver liegen bleiben und erst bei Anforderung ausgepackt werden, sowas hat Nop fuer seine Wanderkarte eine Zeitlang gemacht, aber das ist relativ langsam, weil das PHP nicht gerade ideal ist, um irgendwelche PNGs zu zerhacken. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ... pack - ftp - unpack ....
Hallo, Thomas Ineichen wrote: Aufgabe: 530'000 Tiles in 25'000 Ordnern (~300 MB) packen in 400 Dateien (pro Zoom-Level 1-5 Ordner, 17 verschiedene Layer) tar -cjf: 22 Minuten, 250 MB tar -cf 20 Minuten, 675 MB 10% schneller, aber dafür sind die gepackten Dateien doppelt so gross wie die Originale? Mache ich etwas falsch? :) Die gepackten (komprimierten) sind nicht groesser als die Originale. Die einfach so eingetarten sind groesser, weil tar eine gewisse Blockgroesse benutzt (glaube so 10k oder so) und daher die Dateigroessen aufgerundet werden. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo ist das *.osm Format beschrieben
Hi, Schlauchboot wrote: Wie stabil ist das Format eigentlich? Ggf waere eine formale Beschreibung als XML-Schema sinnvoll... Es gibt immerhin eine DTD: http://wiki.openstreetmap.org/wiki/API_v0.6/DTD Eine weitere Formalisierung ist aber nicht sinnvoll, denn dann denken die Programmierer immer, wenn sie sich nur ans Schema halten, ist alles korrekt, und in Wahrheit kann auf Serverseite jederzeit was dazuerfunden werden ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] State Of Country Posters - Deadline 8/07/2010 10AM
Hallo, Emilie Laffray wrote: the deadline for posters for State Of Country is on 8/07/2010 10am (tomorrow morning). The poster is A1 vertical. An example can be found at the following link: http://dl.free.fr/mcXHIJPi4 It would be good to have a link for it. You can reply to that email. Das erwischt mich jetzt auf dem falschen Fuss, ich wusste gar nicht, dass die wollen, dass wir ein Plakat machen ;) Die Idee ist offenbar, dass jedes Land so ein A1-Hochkant-Plakat macht, auf dem ein paar Highlights des vergangenen Jahres dargestellt sind. Eventuell kriege ich da noch schnell was hin - helft mir mal beim Brainstorming: * Luftbilder Lauf * Luftbilder Dortmund * vielleicht ein paar von den Wikimedia-Toolserver-Spezialbasteleien mit Erwaehnung von hstore? * irgendeinen netten Screenshot mit Strassenlisten-Vollstaendigkeits-Analyse (Ideen?) * ...? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wo ist das *.osm Format beschrieben
Hallo, Schlauchboot wrote: Das sehe ich nicht so. Der Datenproduzent (Server) könnte z.B. für die Spezifikation verantwortlich sein, und er müßte sich exakt an seine eigene Spezifikation halten. Ändert er was, muß er eine neue Version der Spezifikation veröffentlichen. Eben, und genau das wird nicht passieren, und deswegen ist eine Spezifikation nichts wert - sie wird nur zu beleidigten Beschwerden der Datenverbraucher fuehren (ihr seid schuld, ich hab alles richtig gemacht!). So eine Versionsänderung kann dann abwärtskompatibel sein, oder auch nicht. Alle Nutzer wissen dann aber immer genau, woran sie sind. Damit könnte man auch ein Verfahren verbinden, wie nicht kompatible Änderungen einzuführen wären. Normal machen wir nichtkompatible Aenderungen mit neuen API-Versionsnummern. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] State Of Country Posters - Deadline 8/07/2010 10AM
Hallo, Sven Geggus wrote: Die i18n Karten und den Query To Map könnte man da als Anwendungsbeispiele bringen. Zu spaet, die Deadline war vor einer Stunde, ich habe das hier hingeschickt: http://www.remote.org/frederik/tmp/sog.pdf Nicht mein bestes Plakat, aber das beste, was ich in der kurzen Zeit hingekriegt hab... Bye Frederk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gewerbe landuse
Hallo, Claus Färber wrote: Ihr habt eine sehr seltsame Definition von Gewerbe. Auch ein Stahlwerk (industrial), eine Einzelhandel (retail) oder eine Bank (commercial) ist ein Gewerbe. Ja, aber da ist auch ein bisschen die Bezeichnung Gewerbegebiet schuld, die es hier bei uns oft gibt (und die nicht selten mit so einem kleinen Fabriksymbol illustriert ist) - in einem Gewerbegebiet findest Du in Deutschland in der Regel weder Banken noch Einzelhandel, oder? Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapnikstyle Germanica
Hallo, Sven Geggus wrote: Beides kann man machen. Ein lokaler Mapnik ist natürlich insofern geschickter als dass man da einfach mal schnell ne handvoll Tiles rendern kann und direkt über das Dateisystem und Openlayers auf die frisch erzeugten Tiles zugreifen kann. Wie das alles geht ist aber im Wiki brauchbar beschrieben. Ein weiterer Vorteil ist, dass man sich beliebige Testdaten erzeugen kann (wie sieht das eigentlich aus, wenn eine Strasse unter dem Haus in einem Tunnel langfuehrt und eine obendrueber als Bruecke...). Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum ist die Mercator Projektion für OSM vorteilhaft?
Hallo, Schlauchboot wrote: Warum verwendet OSM die Mercator-Projektion einer Kugel, und nicht die des WGS-84 Ellipsoiden? Schließlich sind alle Koordinaten in der DB WGS-84 Koordinaten. Die Eingangsfrage bezog sich auf JOSM; Du beziehst Dich auf die Karten-Kacheln. Gurgle macht das auch so, aber das ist nicht das Argument, oder? Die Tatsache, dass eine bestimmte Kartenkachel bei Google von der abgedeckten Flaeche ganz genau einer bestimmten Kartenkachel bei uns entspricht, macht durchaus vieles einfacher. Bei sphaerischen Mercator-Projektion ist die Welt ausserdem auch exakt quadratisch - auch das vereinfacht viele Dinge. Es ist aber durchaus moeglich, Kartenansichten in anderen Projektionen zu erzeugen, sogar gekachelte. Der Grund, warum wir die Mercator-Projektion in JOSM benutzen (und nicht wie frueher EPSG:4326), ist, dass Quadrate darin eingermassen quadratisch und Kreise einigermassen rund aussehen. Mit 4326 musste man, wenn man einen Kreisverkehr in unseren Breiten erfasst hat, ein Oval zeichnen - das ging zwar genauso, war aber weniger intuitiv. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus im Bereich WM/GAP (war: Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP)
Hallo, Thorsten Kunkel wrote: Jetzt verschwinden auch Wege und Flächen, die definitiv von mir gemappt wurden. Ich würde daher von großflächigem Vandalismus sprechen. Kann man dagegen was unternehmen und wenn ja, was?? Ich habe den Benutzer alegria6208 gebeten, zu den Vorwuerfen Stellung zu nehmen. Es kam zunaechst ein alles gelogen, ich hab das alles selbst erfasst zurueck. Ich habe geantwortet, dass das unglaubwuerdig ist, und einige der hier diskutierten Indizien gebracht (exakte Landuse-Flaechen wie im Bayernviewer etc.). Ich habe dem Benutzer geschrieben, dass ich verstehen kann, dass man mal uebers Ziel hinausschiesst und dass ich auch nicht daran zweifle, dass er das Projekt voranbringen will, aber dass das Abmalen vom Bayernviewer halt nicht geht (das hatte er ja schon vor einem Jahr eingesehen und zu unterlassen versprochen). Ich habe ihn freundlich, aber bestimmt, gebeten, alles, was er vom Bayernviewer abgemalt hat, zu entfernen. Er hat daraufhin - was mir in solchen Faellen leider schon oefter passiert ist, obwohl ich mich wirklich um freundliche und verstaendnisvolle Formulierungen bemuehe - beleidigt reagiert und angekuendigt, das Projekt zu verlassen. Was schade ist, denn er hat sich ja, wenn auch mit zuweilen unzulaessigen Mitteln, sehr um die Verbesserung von OSM bemueht. Aber irgendwo ist bei mir auch Ende mit der Diplomatie; ich habe ihm geschrieben, dass wir einen so emsigen Mapper nur ungern verlieren moechten und dass es odch fuer uns alle am besten waere, wenn er einfach seinen Fehler korrigiert und dann ohne Bayern weitermacht. Wenn er das nicht will - seine Entscheidung. (Ich kann mir auch vorstellen, dass man, wenn man erstmal gewohnt ist, von guten Luftbildern abzumalen, wenig Spass mit althergebrachten Methoden hat.) Ich wuerde sagen, wir warten jetzt mal diese Loesch-Aktion ab. Nachher koennen wir in Ruhe analysieren, was alles geloescht wurde und ob er hie oder da uebers Ziel hinausgeschossen ist und das dann wiederherstellen. Im Grunde finde ich es gut und richtig, dass er seine eigenen Sachen loescht. Sonst haetten wir die Arbeit. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum ist die Mercator Projektion für OSM vorteilhaft?
Hallo, Schlauchboot wrote: Das verstehe ich nicht. Die Mercator-Projektion bildet die Kugel/den Ellipsoiden auf einen unendlich langen abgewickelten Zylinder ab. Da ist nix quadratisch. Für die OSM-Karten wird die Welt dann dadurch quadratisch gemacht, dass man einen maximalen nördlichen und spiegelbildlich dazu einen größten südlichen Breitengrad gerade so definiert, daß die dadurch beschnittene Welt quadratisch wird. Ergo wird man auch die Umgebung der Pole auf keiner OSM-Karte finden -- falls auch dort der eine oder andere Mapper unterwegs sein sollte ;-) Das stimmt. Die Pole selbst wuerde man allerdings auch dann nicht auf der Karte finden, wenn man sie nicht abschnitte, weil sie ja am Ende des unendlichen Zylinders liegen ;) Das kann man aber genauso bei der echten, ellipsoidalen Abbildung machen. Man erhält dadurch nur etwas (im Prozentbereich) andere maximale Breitengrade. Da hast Du wohl Recht. Nur der direkte, einfache Vergleich mit Gurgel wird dadurch wohl verloren gehen... Nicht nur der Vergleich - derzeit kann man ja mit wenigen Zeilen Code eine Webseite, die auf Google-Kacheln basiert, auf OSM umstellen. Das ginge dann nicht mehr so leicht. Das beantwortet meine Frage eigentlich nicht: Wenn JOSM und die Karte genau dieselbe Projektion verwenden, dann kann man auf dem Bildschirm eine beliebige geometrische Figur zeichnen und sieht auf der Karte bis auf einen Skalenfaktor genau dieselbe geometrische Figur -- ohne jede Verzerrung. Ja. Trotzdem wuerde, wenn diese Projektion beispielsweise EPSG:4326 waere, ein Kreisverkehr in Deutschland (sowohl in JOSM als auch auf der Karte) oval aussehen. Das wollen wir nicht. Eine echte Mercator-Projektion kaeme natuerlich in Frage. Man koennte es auch ganz professionell machen und eine Web-Karte stricken, die zumindest beim Reinzoomen ueberall auf der Welt die jeweils ortsuebliche Projektion verwendet. Zusammengefaßt bleibt als Antwort auf meine Frage also nur das Argument Gurgle übrig... Es ist ja nicht nur Google, auch Bing und Yahoo benutzen das gleiche Schema. Aber ich denke mal, man kann das so sagen. OSM folgt dem Industriestandard ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vandalismus im Bereich WM/GAP (war: Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP)
Hallo, Thorsten Kunkel wrote: zunächst vielen Dank an Frederik für die Kontaktaufnahme mit alegria. Immerhin scheint jetzt angekommen zu sein, dass es so nicht geht. Leider hat Dietmar recht: alles, was alegria irgendwann mal angefasst hat, fällt nun der Löschwut zum Opfer. Darunter auch Teile der B2, B472, der Bahnstrecken München-Garmisch und Weilheim-Schongau, sowie Teile der Ammer. :-( Ich kuemmere mich darum, diejenigen Objekte ausfindig zu machen, die alegria nicht selbst erstellt, sondern nur veraendert hat, und werde versuchen, sie auf den Stand zurueckzusetzen, den sie vor alegrias erstem Eingreifen hatten. Das wird aber nicht immer moeglich sein. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strategie zur korrekten Entfernung der alegria-Aktionen, war Vandalismus im Bereich WM/GAP (war: Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP)
Hallo, Dietmar wrote: ich sehe hier gewisse Parallelen zum späteren Prozedere bei der Lizenzumstellung, als wenn alegria der Umstellung nicht zugestimmt hat. Stimmt. Ob die Regeln dafür technisch aber schon erstellt (und getestet) sind, keine Ahnung. Sind sie nicht. Vermutlich wird es da auch keine festen Regeln geben. Wenn das eine eher händische Sache für Frederik ist: wenn die Regeln klar wären, würden bestimmt einige bereit sein, das auszuführen (ich würde mitmachen). Ich habe ein Skript, mit dem ich Objekte auf den Stand zuruecksetzen kann, denn sie hatten, bevor ein bestimmter User sie zuerst bearbeitet hat. Ich mache nun folgendes: * alle Objekte anschauen, die alegria jetzt loescht * wenn er sie selber auch erstellt hatte - ok * wenn jemand anders sie erstellt hatte - letzte Version vor erster Bearbeitung durch alegria wiederherstellen Ulkigerweise, sehe ich an meinen Logs, stelle ich dadurch eine ganze Menge von Objekten wieder her, die pfoten_weg_!_ zuletzt bearbeitet hatte, die beiden scheinen im gleichen Gebiet untewegs zu sein. Dabei gehen natuerlich alle Bearbeitungen verloren, die durch andere nach der ersten Bearbeitung von alegria vorgenommen wurden. Eine Methode, um diese Bearbeitungen zu analysieren und z.B. Tag-Aenderungen zu behalten, habe ich leider nicht. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strategie zur korrekten Entfernung der alegria-Aktionen, war Vandalismus im Bereich WM/GAP (war: Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP)
Hallo, M∡rtin Koppenhoefer wrote: * alle Objekte anschauen, die alegria jetzt loescht * wenn er sie selber auch erstellt hatte - ok ist das eindeutig so? Im Prinzip gehören sie ja nicht ihm/ihr, auch wenn sie sie selbst erstellt hat. Klar, wenn es Müll ist, gehört es weg, aber ansonsten? Wir gehen im Moment davon aus, dass alegria alles, was er/sie loescht, mit unzulaessigen Hilfsmitteln erstellt hat. Dadurch gehoeren diese Objekte der bayrischen Landesregierung ;) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Strategie zur korrekten Entfernung der alegria-Aktionen, war Vandalismus im Bereich WM/GAP (war: Problem mit den Editierungen eines anderen Benutzers im Bereich WM/GAP)
Hallo, Frederik Ramm wrote: Ich habe ein Skript, mit dem ich Objekte auf den Stand zuruecksetzen kann, denn sie hatten, bevor ein bestimmter User sie zuerst bearbeitet hat. Ich mache nun folgendes: Ich bin jetzt soweit durch. Allerdings gibt es Probleme mit ein paar Relationen: 133148 178422 23413 31495 405119 405121 405131 405133 410383 410389 Die sind vor relativ langer Zeit von alegria angefasst worden. Wenn ich die nun auf den Stand von davor zuruecksetzen will, muss ich lauter Ways wiederherstellen, die damals Teil dieser Relationen waren, inzwischen aber laengst geloescht wurden. Das wird, fuerchte ich, zu ziemlichem Kuddelmuddel fuehren. Vielleicht mag sich jemand das ja mal anschauen. (Um die 31495 ist es, wenns nach mir geht, nicht schade, solche Sammelrelationen machen nur unnoetig Arbeit, wie das hier wieder zeigt.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel
Hallo, Andreas Labres wrote: IMO kann man aus der History einfach nicht herauslesen. Punkt. Drum finde ich es nicht ok, daß beim Lizenzwechsel der erste Bearbeiter jetzt als der Urheber des Objektes angesehen wird. Das heißt für mich, ich muß jetzt alle Objekte, die ich je angefasst habe, neu machen, damit ich sichergehe, daß mein Werk als solches anerkannt wird und nicht durch widrige Umstände das Objekt gelöscht wird. -- Sorry, aber die Idee finde ich von Grunde auf falsch. Das ist aber auch nicht so. Streng genommen ist jedes Objekt gemeinsames geistiges Eigentum aller Beteiligten. Wenn auch nur einer dem Lizenzwechsel nicht zustimmt, muesste das Objekt dann auf den Stand von vor dessen Bearbeitung zurueckgerollt werden. Es wird aber auch Faelle geben, in denen eine Bearbeitung klar zu trivial ist, um ein geistiges Eigentum zu begruenden - als ganz einfaches Beispiel mal so ein typischer pfoten_weg-Edit, bei dem gar nichts geaendert wird. Wenn nun pfoten_weg dem Lizenzwechsel nicht zustimmt, sollte das von der rechtlichen Beurteilung her keinen Einfluss haben. Wie das in der Praxis spaeter umgesetzt wird, ist noch abzuwarten - da werden ganz gewiss noch viele Skripte geschrieben werden muessen. Wenn Du ein Objekt, das vor Dir 10 Leute angefasst haben, loeschst und neu machst, dann schneidest Du natuerlich die Historie ab und rettest das Objekt davor, dass einer in der Kette Nein zur Lizenz sagt. Streng genommen kann derjenige Dich aber dann verklagen, weil Du sein geistiges Eigentum genommen und unter einer von ihm nicht akzeptierten Lizenz veroeffentlicht hast - es ist also nicht ganz korrekt. Klar gibt es Edits, die so weitreichend sind, dass vom Original praktisch nichts mehr uebrig bleibt. Auch die sollten bei einer was loeschen wir-Entscheidung beruecksichtigt werden. Wird alles nicht leicht! Aber kein Grund, jetzt in Aktionismus auszubrechen. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
