[Talk-de] Lizenzwechsel-View im OSM Inspector
Hallo, der OSM Inspector hat jetzt eine Lizenzwechselkarte, die taeglich aktualisiert wird und alle (*) Objekte zeigt, die vermutlich vom Lizenzwechsel betroffen sind: Auf tools.geofabrik.de/osmi gehen und dann oben im Dropdown License Change auswaehlen. Oder: http://tools.geofabrik.de/osmi/?view=wtfelon=-1.80469lat=35.88371zoom=2 Es gibt auch Statistiken dazu: http://tools.geofabrik.de/osmi/munin.html Der View wird fuer Zoomlevel 0-9 aus einem grossen Rasterbild berechnet, fuer Zoom 10 und hoeher direkt aus Shapefiles. Diese Shapefiles haben fuer jeden Node und jeden Way in OSM, deren History mindestens einen Nichtzustimmer enthaelt (**), die Geometrie und den Lizenzstatus (1/rot = Nichtzustimmer hat das Objekt angelegt, 2/orange = Nichtzustimmer hat das Objekt bearbeitet, 3/gelb = wie 2, jedoch ist die Bearbeitung vernachlaessigbar). Die Shapefiles sind daher auch als Rohmaterial geeignet, falls jemand selbst etwas mit den Daten anfangen will, und sie koennen auf diesem temporaeren Server heruntergeladen werden: http://176.9.53.72/ (ebenfalls taeglich neu). Eine etwas detaillierte Dokumentation zum Zustandekommen der Daten und zur Nutzung gibt es hier auf Englisch: http://wiki.openstreetmap.org/wiki/Remapping/License_Change_View_on_OSM_Inspector (*) Dieser View ist sicher nicht perfekt, und wem ein Fehler auffaellt, der moege das bitte sagen. Die groessten Probleme, die ich derzeit sehe, sind: 1. Das Zuruecksetzen eines Objekts in einen Zustand, der lizenzmaessig unbedenklich ist, weil alle von Nichtzustimmern gemachten Edits nicht mehr in der aktuellen Version enthalten sind, sollte idealerweise zu einer Umfaerbung orange-gelb fuehren, tut es aber nicht, weil diese Analyse nur schwer zu machen ist. 2. Triviale Edits werden nicht automatisch erkannt - Beispiel: Der User xybot hat der Lizenz zugestimmt und ist daher kein Problem, aber wenn er nicht zugestimmt haette, waeren alle Objekte, bei denen er je was korrigiert hat, erst mal orange. - Wer aber Changesets ausfindig macht, die offensichtlich von einem Nichtzustimmer mit einem Bot gemacht wurden, der kann die (idealweise nach Ruecksprache mit dem Ersteller) auf der Seite http://wiki.openstreetmap.org/wiki/WTFE unter Changeset Overrides melden. 3. Keine Erkennung von Way-Joins/Way-Splits - einige Ways, die jetzt fuer ok gehalten werden, koennten sich im Nachhinein als problematisch erweisen; oft sieht man das aber an den Nodes. 4. Keine Visualisierung von Relationen 5. Nodes werden immer als rot eingezeichnet, auch wenn der Ersteller ausser Koordinaten nichts angegeben hat und spaetere Verschieber des Nodes daher praktisch alles, was der Node je an Infos hatte, durch ihre eigenen ersetzt haben. Das ist ein offener Diskussionspunkt, wie man damit umgeht, und im Augenblick zeichnet die Karte lieber mehr rot als weniger. Wichtig zum Verstaendnis: Diese Karte ist kein offizielles Produkt der LWG, sondern auf meinem Mist gewachsen (urspruenglich gestartet in London auf dem Hack-Weekend vor 2 Wochen). Die Karte zeigt nicht verbindlich an, welche Objekte beim Lizenzwechsel geloescht oder revertiert werden muessen; da gibt es noch eine Reihe von Policy-Entscheidungen eben gerade zu Fragen wie unter 5. diskutiert. (**) Die Overrides von http://wiki.openstreetmap.org/wiki/WTFE werden wie Zustimmer behandelt und tauchen weder in der Karte noch in den Shapes auf. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Hi, Ich denke, was wir bräuchten - und dann hielte ich es für sinnvoll - wäre ein Kataster-Overlay, bei dem man zusätzliche Daten ablesen kann, während man editiert. Klar: Wir müssen auch dazu kommen, dass Leute aufhören, ausschließlich von Luftbildern abzuzeichnen. Aber Ein Kataster-Overlay, das Fehler finden hilft, im Bedarfsfall meine Notizen von den Hausnummern stützt etc., wäre schon hilfreich. Aber warum sollte man Hausumrisse nach einem katasteroverlay nachpinseln? Das ist doch wie früher als 1000de Chinesen Telefonbücher abtippten statt das die Telekom die Daten raus gab. Da käme ich mir als mapper echt verarscht vor wenn mir einer das nahe legen würde. Ja, sehe ich ähnlich ... ich habe bei uns für ein gefühltes fünftel der Stadt die Häuser von bing abgezeichnet .. mir fehlt aktuell die Zeit und die Lust daran weiter zu machen (allen anderen in diesem Gebiet offensichtlich auch). Insbesondere wenn ich sehe dass es die Daten schon alle gibt/gäbe. Die wenigen Gebäude von denen ich weiß, dass sie in Bing falsch oder veraltet sind, update ich gerne, aber die anderen 99% abzumalen befriedigt auf Dauer echt nicht. Oder ich hoffe darauf, dass wieder ein User Maler vorbeikommt und nicht nur alle Wege abmalt sondern auch noch alle Häuschen. Eine Importmöglichkeit bei der ich ein Overlay hätte und die einzelnen Objekte übernehmen kann wäre da ECHT hilfreich. Die Building/Src/.. Tags vergeben ist im Vergleich dazu ja harmlos. Just my 2c. Franz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Hallo, On 12/13/11 08:55, Markus wrote: Wir tun gut daran, eventuelle negative Entwicklungen im Keim zu entdecken und rechtzeitig umzusteuern. Wenn es also OSMer gbt, die für OSM brennen, und das plötzlich (meist schleichend oder mit bestimmten Ereignissen verbunden) nicht mehr tun, dann sind das ernstzunehmende Zeichen. Der Unmut, sinnlos zu mappen oder gar für die Tonne ist ein solches. Jein, da muss man vorsichtig sein. Als zum Beispiel die flaechendecken Yahoo-Luftbilder kamen und das noch was ganz neues war, gab es in einigen Teilen der Community da durchaus Widerstand und Unmut. Die Luftbild-Abmaler wurden als unsportlich gesehen, weil sie mit unfairem Vorteil zum Teil erstaunlich produktiv sein konnten - jemand, der in wochenlanger Kleinarbeit jeden Weg im Ort mit GPS gemappt hatte, musste ploetzlich sehen, wie andere ihren Ort ratz-fatz von einem Luftbild abzeichnen konnten. Unmut bei den einen - Freude bei den anderen. Damals haette man auch sagen koennen: Nee, Luftbilder wollen wir nicht, das zerstoert unsere Outdoor-Kultur. Man muss also schon immer genau schauen, um was fuer einen Unmut es geht, und welche Kultur dieser Unmut viellicht bedroht; nicht jeder Unmut muss bekaemft und nicht jede - vermutete - Kultur erhalten werden. Da reicht es nicht, darauf zu hoffen, dass schon genügend andere nachrücken werden. Denn auch wenn sie das tun: die Kultur wäre zerstört. Fuer mich ist bei importierten Hausumrissen eine Grenze ueberschritten - ich sehe da unsere Selbermach-Kultur in Gefahr. Ich glaube, dass viele unserer Erfolge darauf basieren, das wir selber machen und nicht warten, dass/bis uns gegeben wird. Ich wuerde mir auch wuenschen, dass wir, wenn wir Haeuser wollen, diese selbst von aktuellen Luftbildern abdigitalisieren - nicht zuletzt, weil ich den Wert von OSM auch darin sehe, eine zweite Meinung zu sein inmitten des Wusts von Geodaten, die alle aus der gleichen Quelle abgeschrieben sind. Haueser zu importieren bringt auf jeden Fall kurzfristig einen Vorteil; die Karte sieht huebscher aus, und auch Martins Argument, dass man mit Bezug auf die Haeuser dann Zusatzinfos erfassen kann, ist korrekt. Mittel- und langfristig stuetzt man damit (mit dem Importieren - nicht notwendigerweise mit anderen Arten der Erfassung) aber den Gedanken, dass OSM mehr eine Sammelstelle fuer Geodaten Dritter ist als ein Projekt, in dem diese Geodaten selbst erhoben werden. Das finde ich nicht gut; ich denke, dass das Selber-Erheben ein wichtiger Teil unserer Kultur ist. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Hi, Am 13.12.2011 09:43, schrieb Frederik Ramm: Fuer mich ist bei importierten Hausumrissen eine Grenze ueberschritten - ich sehe da unsere Selbermach-Kultur in Gefahr. Ich glaube, dass viele unserer Erfolge darauf basieren, das wir selber machen und nicht warten, dass/bis uns gegeben wird. Ich wuerde mir auch wuenschen, dass wir, wenn wir Haeuser wollen, diese selbst von aktuellen Luftbildern abdigitalisieren - nicht zuletzt, weil ich den Wert von OSM auch darin sehe, eine zweite Meinung zu sein inmitten des Wusts von Geodaten, die alle aus der gleichen Quelle abgeschrieben sind. Prinzipiell stimme ich zu - in Regionen in denen sehr wenige Mapper aktiv sind ist das aber eine ends-mühselige Arbeit. Die Licence-Change-Map ist kurz davor, mir den Motivations-Todesstoß zu geben. Einen vollautomatischen Import finde ich (wie bei fast allen vollautomatischen Methoden) äußerst risikoreich. Aber eine Art Overlay mithilfe dessen ich einfach(er) Umrisse übernehmen kann ohne alles selbst zu zeichnen wäre ENORM hilfreich - dann könnte ich parallel auch noch ein paar von den ODBL-violated Wegen neu abzeichnen. Meine Zeit (und Motivation) ist nun mal leider begrenzt. Und zum selber erheben gibt es wahrlich noch genug mag ich meinen. Adressen, Briefkästen, Wegbeschaffenheit, Straßenschilder, POIs, ... Fazit: Nein zum vollautmatischen Import Ja zu einer bequemen Möglichkeit einzelne Häuser schnell zu übernehmen. Grüße Franz Graf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Hi, On 12/13/11 09:59, Franz wrote: Einen vollautomatischen Import finde ich (wie bei fast allen vollautomatischen Methoden) äußerst risikoreich. Aber eine Art Overlay mithilfe dessen ich einfach(er) Umrisse übernehmen kann ohne alles selbst zu zeichnen wäre ENORM hilfreich Das wuerde aber schon weitgehend aufs gleiche hinauslaufen. In Frankreich haben sie das auch gedacht, und den Mappern vor Ort fertige JOSM-Files gegeben, damit die die pruefen und hochladen koennen. 99% ist ungeprueft hochgeladen worden, weil dem Mapper vor Ort Quantitaet vor Qualitaet ging. Wenn Du erstmal die Katasterdaten auf Knopfdruck uebernehmen kannst, machst Du Dir dann wirklich die Muehe, bei einer kleinen Abweichung im Luftbild was zu korrigieren? Nichtsdestotrotz ist so was, wie Du es hier beschreibst, gerade fuer Potlatch in Arbeit - Andy Allan arbeitet da an Code fuer CycleStreets, bei dem man einen Datensatz in den Hintergrund laden und dann selektiv Objekte uebernehmen kann - man kann sogar, wenn das Objekt in OSM schon vorhanden ist, selektiv nur einzelne Attribute vom Hintergrundobjekt auf das OSM-Objekt kopieren. Der Original-Einsatzzweck sind wohl von der UK-Regierung freigegebene Daten zu Fahrradwegen, die keinesfalls direkt importiert werden koennen, bei denen aber ein Abgleich mit OSM spannend ist. Man kann glaube ich sogar die Daten im Original-Datensatz dann als erledigt markieren und auf die Weise gemeinsam flaechendeckend einen Fremd-Datensatz verwursten. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Am 13.12.2011 10:06, schrieb Frederik Ramm: Einen vollautomatischen Import finde ich (wie bei fast allen vollautomatischen Methoden) äußerst risikoreich. Aber eine Art Overlay mithilfe dessen ich einfach(er) Umrisse übernehmen kann ohne alles selbst zu zeichnen wäre ENORM hilfreich Das wuerde aber schon weitgehend aufs gleiche hinauslaufen. In Jein - du beschreibst ja unten dass für Potlach sowas gemacht wird ;) Frankreich haben sie das auch gedacht, und den Mappern vor Ort fertige JOSM-Files gegeben, damit die die pruefen und hochladen koennen. 99% ist Da fehlt mir noch der nötige manuelle Schritt. Ich würde schon gern(?) noch jedes Objekt anklicken müssen bevor es einfach hoch geladen wird. ungeprueft hochgeladen worden, weil dem Mapper vor Ort Quantitaet vor Qualitaet ging. Wenn Du erstmal die Katasterdaten auf Knopfdruck uebernehmen kannst, machst Du Dir dann wirklich die Muehe, bei einer kleinen Abweichung im Luftbild was zu korrigieren? Da muss man vielleicht am Prozess feilen, dass noch so weit Hand angelegt werden muss aber trotzdem noch eine Erleichterung vorliegt -- andererseits frage ich mich, ob man da nicht mit Bildanalyse auch noch was machen kann .. wäre ich nicht schon fast fertig, würde ich eine Abschlussarbeit für so etwas ausschreiben. Nur dass der Prozess in Frankreich teils misslungen ist, muss nicht heißen dass das Vorhaben per se falsch war. Vielleicht nur suboptimal umgesetzt. Nichtsdestotrotz ist so was, wie Du es hier beschreibst, gerade fuer Potlatch in Arbeit - Andy Allan arbeitet da an Code fuer CycleStreets, bei dem man einen Datensatz in den Hintergrund laden und dann selektiv Objekte uebernehmen kann - man kann sogar, wenn das Objekt in OSM schon vorhanden ist, selektiv nur einzelne Attribute vom Hintergrundobjekt auf das OSM-Objekt kopieren. Der Original-Einsatzzweck sind wohl von der UK-Regierung freigegebene Daten zu Fahrradwegen, die keinesfalls direkt importiert werden koennen, bei denen aber ein Abgleich mit OSM spannend ist. Man kann glaube ich sogar die Daten im Original-Datensatz dann als erledigt markieren und auf die Weise gemeinsam flaechendeckend einen Fremd-Datensatz verwursten. Na das wär ja schon was! Muss ich mir nur mit Potlach anfreunden -- aber DAFÜR würd ichs vermutlich tun. Dann warte ich mal ab und harre der Dinge die da kommen. Grüße Franz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Am 13.12.2011 09:43, schrieb Frederik Ramm: Unmut bei den einen - Freude bei den anderen. Damals haette man auch sagen koennen: Nee, Luftbilder wollen wir nicht, das zerstoert unsere Outdoor-Kultur. Man muss also schon immer genau schauen, um was fuer einen Unmut es geht, und welche Kultur dieser Unmut viellicht bedroht; nicht jeder Unmut muss bekaemft und nicht jede - vermutete - Kultur erhalten werden. Da reicht es nicht, darauf zu hoffen, dass schon genügend andere nachrücken werden. Denn auch wenn sie das tun: die Kultur wäre zerstört. Ich meine das die Qualität von OSM eben nur durch outdoor-Kultur aufrecht erhalten werden kann. Entsprechend hat jeder User seinen Aktionsradius den er hegt und pflegt und das funzt wenn ich mir meine Nachbarn so ansehe recht passabel. Auch wenn die Produktivität so zwangsweise ein wenig mit der Zeit nachlässt da die Wege die man zurückzulegen hat weiter werden. Man kann eben vieles nicht auf dem Sat.-Bildern erkennen. Den Nutzen der Sat.-Bilder sehe ich in erster Linie darin das man bequem und auch gut die Flächennutzung mappen kann (Wald, Acker, Wiese, etc.). Für Wege ist es mir eher eine zusätzliche Referenz um den GPS Log abzugleichen (Genauigkeit, Kurvenverlauf etc.) Beim neu mappen von Wegen über Sat.-Bilder entsteht immer der fade Beigeschmack das es nicht optimal ist (tracktype usw.) und ich früher oder später sowieso (immer mal wieder) vor Ort vorbei muss um mir anzuschauen was Sache ist. Wege in Wäldern per Satbilder mappen zu wollen kann man sowieso nahezu vergessen. Jeder Import braucht einen Mapper mit Ortskenntnis. Fuer mich ist bei importierten Hausumrissen eine Grenze ueberschritten - ich sehe da unsere Selbermach-Kultur in Gefahr. Ich glaube, dass viele unserer Erfolge darauf basieren, das wir selber machen und nicht warten, dass/bis uns gegeben wird. Ich wuerde mir auch wuenschen, dass wir, wenn wir Haeuser wollen, diese selbst von aktuellen Luftbildern abdigitalisieren - nicht zuletzt, weil ich den Wert von OSM auch darin sehe, eine zweite Meinung zu sein inmitten des Wusts von Geodaten, die alle aus der gleichen Quelle abgeschrieben sind. Bei dem Punkt Häuser bin ich der Meinung das es mit der bisher überwiegend vorliegenden Luftbildauflösung keinen Sinn macht da was abzumalen. Es gibt immer anderes zu tun was man machen kann bevor ich mich aus absoluter Langeweile damit beschäftige und dann wenn eine höhere Auflösung oder gar die millimetergenauen Daten (eingemessene Gebäude) vom Katasteramt vorliegen ich feststellen muss es war sowieso im weitesten Sinn für die Katz. Genausowenig habe ich Wälder gemappt bevor die Bilder von Bing verfügbar waren. Die yahoo Bilder vorher waren so grob da hat man mal 100m daneben gelegen. Waldgrenzen mit dem GPS Logger abzulaufen habe ich mal testweise gemacht und für nicht effizient (ziemlich ätzend) und auch nicht im Ergebnis gut befunden verglichen mit Satbildern. Dahabei ch mich erstmal mit anderem beschäftigt. Mit dem GPS Logger bei +5m Genauigkeit Gebäude in die OSM bringen zu wollen halte ich ebenso für eine Verzweiflungstat aus Langeweile. ;) Die zweite Meinung von OSM sehe ich in der Ortskenntnis/Qualitätssicherung eine Mappers vor Ort. Egal worin die Ursprungsquelle der Daten mal bestanden hat. Wenn es Hilfsmittel wie Sat.-Bilder oder Importe gibt die den reinen Erfassungsvorgang dem Mapper erleichtern und er sich mehr auf die Qualitätssicherung im weitesten Sinn beschränken kann ist das nur sinnvoll. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Betreff bearbeiten, richtig zitieren, War: Re: [bulk]: Re: [bulk]: Re: [bulk]: Re: irgendein Thema
Wenn man die Mailingliste auf bulk (Sammelmails) gestellt hat und antworten will, bitte vor dem Absenden den Betreff anpassen, damit es halbwegs übersichtlich bleibt. (D.h. Thema sollte entweder dem entsprechen, wie es der Originalposter erstellt hat, oder sollte ein neues Thema sein und über neues Thema war: urspr. Thema einen Bezug zum ursprünglichen Thread enthalten (falls die Diskussion sich entwickelt und nichts mehr mit dem ursprünglichen Thema zu tun hat). Bitte beim Antworten nur die Teile zitieren, auf die man explizit antwortet und die Antworten jeweils inline unter die entsprechenden Absätze. Das erleichtert uns allen die Teilnahme an den Diskussionen bzw. verkürzt die Zeit, die mit unnötigem doppeltem Lesen verbunden ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Remapping Anleitung unbrauchbar?
Am 13. Dezember 2011 06:58 schrieb Tirkon tirko...@yahoo.de: Mit Potlatch kann man nicht korrekt remappen. Ich habe das mal in der englischen und deutschen Version vermerkt. Danke Tirkon. Solche Dinge sollte man durchaus vermerken, da immer wieder behauptet wird, Potlatch sei ein Anfängereditor, aber die Realität ist, dass er für viele Dinge ungeeignet ist, und wieso sollten Anfänger 2 Editoren lernen müssen (Erst Potlatch um zu bemerken, dass er nicht wie gewünscht funktioniert, und dann JOSM)? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
On 11.12.11 14:11, Martin Koppenhoefer wrote: Dazu kommt, dass die Unterscheidung von exit und entrance sowieso nur sehr selten unveränderlich baulich bestimmt ist Schon. Aber der wichtigste Nutzen für so einen entrance-Node ist doch kleinräumiges Routing (Behindertennavigation z.B.) und da ist doch grade Ein- vs. Ausgang essentiell wichtig! Oder was würdest Du davon halten, wenn Du in ein Gebäude hinein willst und dann stehst Du vor dem (von außen verschlossenen) Ausgang? /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Am 12.12.2011 10:56, schrieb Markus: Idee Expertenmodus: Für besondere Aufgaben kann man die Hausumrisse schon beim Runterladen weglassen? (Nachteil: man kann Objekte irrtümlich so zeichnen, dass sie sich mit Gebäuden kreuzen - könnte man aber vielleicht beim Hochladen prüfen? und ggf nachfragen) Ich sehe da kein Problem drin wenn es solche Überschneidungen gibt - im Gegenteil, man wird so zu genaueren Daten kommen weil der Fehler offensichtlich wird - sonst wird immer nur so lange hin- und her geschoben bis die Optik stimmt. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Am 13. Dezember 2011 09:43 schrieb Frederik Ramm frede...@remote.org: Als zum Beispiel die flaechendecken Yahoo-Luftbilder kamen und das noch was ganz neues war, gab es in einigen Teilen der Community da durchaus Widerstand und Unmut. Die Luftbild-Abmaler wurden als unsportlich gesehen, weil sie mit unfairem Vorteil zum Teil erstaunlich produktiv sein konnten - jemand, der in wochenlanger Kleinarbeit jeden Weg im Ort mit GPS gemappt hatte, musste ploetzlich sehen, wie andere ihren Ort ratz-fatz von einem Luftbild abzeichnen konnten. einerseits spielte das sicher mit rein, andererseits waren die Yahoo-Bilder aber auch (mind. teilweise=hier) grottenschlecht referenziert und schlecht aufgelöst, und der echte Unmut kam dann auf, wenn sorgfältig per GPS erhobene Daten (z.T. ganze Stadtteile) dann zig Meter verschoben wurden, um mit den schlechten Luftbildern übereinzustimmen. Fuer mich ist bei importierten Hausumrissen eine Grenze ueberschritten - ich sehe da unsere Selbermach-Kultur in Gefahr. Ich glaube, dass viele unserer Erfolge darauf basieren, das wir selber machen und nicht warten, dass/bis uns gegeben wird. Ich wuerde mir auch wuenschen, dass wir, wenn wir Haeuser wollen, diese selbst von aktuellen Luftbildern abdigitalisieren - nicht zuletzt, weil ich den Wert von OSM auch darin sehe, eine zweite Meinung zu sein inmitten des Wusts von Geodaten, die alle aus der gleichen Quelle abgeschrieben sind. +1, die zweite Meinung finde ich auch extrem wichtig. Praktisch alle anderen kopieren die immer gleichen Daten (und Fehler) aus den 1-2 Datensätzen, die es gibt. Haueser zu importieren bringt auf jeden Fall kurzfristig einen Vorteil; die Karte sieht huebscher aus, und auch Martins Argument, dass man mit Bezug auf die Haeuser dann Zusatzinfos erfassen kann, ist korrekt. Mittel- und langfristig stuetzt man damit (mit dem Importieren - nicht notwendigerweise mit anderen Arten der Erfassung) aber den Gedanken, dass OSM mehr eine Sammelstelle fuer Geodaten Dritter ist als ein Projekt, in dem diese Geodaten selbst erhoben werden. da kann ich nicht mehr ganz folgen, da ja gerade diese Zusatzinfos (die sich nicht nur unmittelbar auf die Hausumrisse beziehen, sondern auch auf alles, was drum rum in Bezug dazu steht) originäre OSM Daten sind, also selbst erhoben und nicht blind von anderen übernommen. Defakto ist ordentliches Arbeiten (z.B. in Bezug auf Winkel und Bezüge von Gebäuden zueinander (Fluchten)) mit unseren Tools nach wie vor kaum möglich (mit ein paar Workarounds und dem Extudieren-Tool kommt man zwar schon recht weit, muss aber dann gelegentlich doch die Rechtwinkligkeit wieder nur annähern, damit man zu gemeinsamen Punkten kommt). Echte Katasterdaten wären da ein Fortschritt (so sie denn überhaupt flächendeckend digital zur Verfügung stehen). In Italien werden derzeit in ein paar Regionen Gebäudedaten importiert, diese kommen aber nicht vom Kataster sondern von den CTR (~technische Grundkarten, glaub 1:10.000), welche ihrerseits wiederum von Luftbildern abgeleitet wurden (wohl ähnlich wie ATKIS in Deutschland), d.h. die Erfassung erfolgte da ähnlich wie wir es in OSM machen, und es handelt sich keineswegs um millimetergenau vermessene Objekte. Ich bin daher (und aufgrund des Alters der Daten) auch ein Gegner dieser Importe. Das finde ich nicht gut; ich denke, dass das Selber-Erheben ein wichtiger Teil unserer Kultur ist. ja, wobei das nicht aufhören müsste (im Gegenteil) nur weil man Hausumrisse (eher nicht unser Hauptaugenmerk) importiert. Uns interessieren ja meistens mehr die Dinge, die sich im Haus befinden als das Haus selbst. Bis diese Umrisse (falls überhaupt) für OSM zur Verfügung stehen (könnten) haben wir vermutlich sowieso schon alles abgemalt ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] key:entrance
Am 13. Dezember 2011 11:57 schrieb Andreas Labres l...@lab.at: On 11.12.11 14:11, Martin Koppenhoefer wrote: Dazu kommt, dass die Unterscheidung von exit und entrance sowieso nur sehr selten unveränderlich baulich bestimmt ist Schon. Aber der wichtigste Nutzen für so einen entrance-Node ist doch kleinräumiges Routing (Behindertennavigation z.B.) und da ist doch grade Ein- vs. Ausgang essentiell wichtig! Oder was würdest Du davon halten, wenn Du in ein Gebäude hinein willst und dann stehst Du vor dem (von außen verschlossenen) Ausgang? ja, volle Zustimmung, bin ja auch für das deutlichere Kennzeichnen von reinen Ausgängen (zum Zeitpunkt der Erfassung) durch ein exit im Wert. Der oben zitierte Satz bezieht sich darauf, im Schlüssel dennoch von entrance zu sprechen (und damit sowohl Ein- als auch Ausgänge zu meinen, es also als Übergang von aussen nach innen aufzufassen). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten - Motivation
Hallo Frederik, danke für diese Ergänzung und Differenzierung: genau schauen, um was fuer einen Unmut es geht, und welche Kultur dieser Unmut viellicht bedroht; nicht jeder Unmut muss bekaemft und nicht jede - vermutete - Kultur erhalten werden. Entscheidend ist gemeinsam zu wissen, was die Kernelemente unserer Kultur sind, diese zu fördern, und Hindernisse rechtzeitig zu erkennen und zu beseitigen. unsere Outdoor-Kultur. Ja, das war und ist ein wesentliches Kulturelement von OSM. Derzeit wird es zunehmend ergänzt durch weitere wertvolle Elemente: - Luftbilder-Abmalen - Synergie mit Fremddaten die OpenData werden Entscheidend ist, dass wir es schaffen, die Synergie zu fördern (und nicht in dysfunktionale Konkurrenzen zu geraten). unsere Selbermach-Kultur Diese ist m.E. das wesentlichste Kultur-Element von OSM: daraus entsteht der berechtigte Stolz auf das eigene Werk. bei Importen in Gefahr Ja, diese Gefahr sehe ich auch. Aber ebenso die Gefahr des Motivationsverlustes, wenn man Vorhandenes und nun Freies stumpf abmalen müsste. Die Lösung liegt m.E. beim synergetischen kontrollierten halbmanuellen Import, und beim nachträglichen Bearbeiten und Pflegen mit intelligenten Werkzeugen in bewährter Selbermach-Kultur. eine zweite Meinung zu sein inmitten des Wusts von Geodaten, die alle aus der gleichen Quelle abgeschrieben sind. Ja, auch darauf dürfen wir stolz sein. Haueser zu importieren bringt auf jeden Fall kurzfristig einen Vorteil :-) Mittel- und langfristig stuetzt man damit aber den Gedanken, dass OSM mehr eine Sammelstelle fuer Geodaten Dritter ist als ein Projekt, in dem diese Geodaten selbst erhoben werden. Das kommt auf das Verhältnis an. Und vor allem auf das Bewusstsein: OSM-Daten sind die Guten - aber nur dann, wenn sie outdoor und durch lokales Wissen und immer wieder neu verifiziert sind. OSM und die Dritten werden zunehmend zusammenwachsen. Sei es indem Dritte unsere Daten verwenden, oder indem sie unsere Methodenund unsere Kultur adaptieren. Langfristig wird es so oder so zu Synergie und OpenData führen. ich denke, dass das Selber-Erheben ein wichtiger Teil unserer Kultur ist. Einer der wichtigsten! Zusammen mit das haben wir gemeinsam geschafft Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Hi, Am 13.12.2011 um 00:12 schrieb Markus: Hallo Tim, Mich würde mal interessieren, wieviele Euros sie dafür beim Bundesamt für Kartographie und Geodäsie hingeblättert haben. Aus gut unterrichteten Kreisen verlautet: ~ 200'000 € das ist so lächerlich, noch ein Grund mehr, endlich alles als OpenData (PD) freizugeben. Mfg Marc ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Potlatch and relation handling
(Sorry, tried to send this yesterday but my subscription to talk-de appeared to have died! Apologies in advance for posting in English.) Tirkon's claim about Potlatch and relation handling is complete nonsense. To edit a relation in Potlatch 2: * select a node or way which is a member of that relation * select 'Advanced' on the left to see the relation list * double-click the relation Then, click 'Members' to see the members in order. You can change the order by dragging the list entries. To add this relation to another, 'parent' relation, click 'Advanced' and then 'Add to'. So there you go, full support for nested and ordered relations. Tirkon, I would be grateful if you would stop repeating the claim that there is no support. Martin, I've long since stopped expecting anything you say to be founded in any form of reality. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Remapping Anleitung unbrauchbar?
Martin Koppenhoefer wrote ... und wieso sollten Anfänger 2 Editoren lernen müssen (Erst Potlatch um zu bemerken, dass er nicht wie gewünscht funktioniert, und dann JOSM)? Schlimmer noch ist es, NICHT zu bemerken, dass etwas schief geht. Meine Potlatch-Phase hat ca 2 Wochen gedauert, da ich damals (2009) 1 Woche brauchte um Josm unter Linux zum Rennen zu bringen. Aber diese Probleme (wmsplugin) sind ja längst erledigt. Gruss Walter - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Remapping-Anleitung-unbrauchbar-tp7084698p7089746.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Remapping Anleitung unbrauchbar?
Am 13.12.2011 13:26, schrieb Walter Nordmann: Martin Koppenhoefer wrote ... und wieso sollten Anfänger 2 Editoren lernen müssen (Erst Potlatch um zu bemerken, dass er nicht wie gewünscht funktioniert, und dann JOSM)? Schlimmer noch ist es, NICHT zu bemerken, dass etwas schief geht. Meine Potlatch-Phase hat ca 2 Wochen gedauert, da ich damals (2009) 1 Woche brauchte um Josm unter Linux zum Rennen zu bringen. Aber diese Probleme (wmsplugin) sind ja längst erledigt. Gruss Walter Hm ich habe vor gut 2 Jahren mit Josm angefangen und Pottloch noch keines blickes gewürdigt :-) Bin bis jetzt immer ganz gut ohne klar gekommen ... Gruß Tobi - Wenn du den Wald vor lauter Bäumen nicht siehst, fälle die Bäume und du wirst sehen, dass da kein Wald ist. -- View this message in context: http://gis.638310.n2.nabble.com/Remapping-Anleitung-unbrauchbar-tp7084698p7089746.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch and relation handling
2011/12/13 Richard Fairhurst rich...@systemed.net: So there you go, full support for nested and ordered relations. happy to see this (actually I discovered it myself just a few hours ago). Martin, I've long since stopped expecting anything you say to be founded in any form of reality. LOL, that's a good one. I was basing my comment on what you (or some other Richard Fairhurst?) were writing more then once to the lists, examples: 1. http://gis.638310.n2.nabble.com/Odd-Potlatch-2-rendering-td5892790.html RichardF: Potlatch 2 will only draw multipolygons which consist of 1 outer way and 1+ inner ways, and where the tags are on the outer way. This multipolygon has several outer ways so will not be rendered properly. You could call this a bug but, to be honest, if people are going to invent insanely complicated relation structures (aka advanced multipolygons) and completely go against existing OSM tagging practice (putting way tags on relations), I feel no obligation to waste a week of my life supporting it. It would be an exceptionally complex one to fix, as you'd potentially need to load extra data from the server if all the outer ways weren't in the current bbox. 2. http://trac.openstreetmap.org/ticket/4048#comment:1 - a few weeks ago you closed a trac ticket concerning this issue with the comment won't fix. 3. http://gis.638310.n2.nabble.com/osm2pgsql-and-only-named-multipolygons-tt6858105.html Richard:So for the tools I contribute to, principally P2 and an upcoming Ruby PDF renderer, I've taken a decision not to spend time on anything more than rudimentary multipolygon support (one outer, tags on outer way), rather than spending a month coding all-singing-all-dancing support and then have to rewrite it when the area tag comes along. YMalmost certainlyV. :) and: Frederik Ramm wrote: While multipolygons with more than one outer *ring* are uncommon, those with more than one outer *way* are heavily used where I live That's all right, everyone where you live uses JOSM anyway. :) The issue from my point of view is one of UI. I can't countenance a UI, or a render, that is any different for tagging shapes depending on whether they have holes in or not. So P2's tagging code would need to get some layer of indirection saying if this is a multipolygon, the tag panel needs to deal with the relation tags, unless there are already tags on the way. Otherwise it needs to deal with the way tags. Meanwhile, the rendering code would need to render fills differently for items with more than one outer way (which is additionally complicated by the fact they might not all be loaded yet). That's far too much like brainache for me to want to code, especially when that code will need rewriting in a year or so. But if someone else who does come from a land where people use bonkers complicated multipolygons came up with a decent patch, I imagine we'd be very happy to accept it. So in the end I am happy that someone recently coded the missing relation support for Potlatch2, but given your statements from previous discussions (as well as you closing relative tickets with won't fix) wasn't really encouraging to think that this has been done in the past few weeks. Neither do I recall any announcement about this huge progress, nor would I have guessed this from the developer's comments on git: https://github.com/openstreetmap/potlatch2/commits/master?page=1 cheers, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch and relation handling
Martin Koppenhoefer wrote: So in the end I am happy that someone recently coded the missing relation support for Potlatch2, but given your statements from previous discussions (as well as you closing relative tickets with won't fix) wasn't really encouraging to think that this has been done in the past few weeks. What on earth are you on about? Potlatch 2 has full support for nested and ordered relations. Potlatch 2 has _always_ had full support for nested and ordered relations. That is what Tirkon was disputing in his wiki posting to which http://lists.openstreetmap.org/pipermail/talk-de/2011-December/090998.html referred; that is what you supported in the follow-up message, http://lists.openstreetmap.org/pipermail/talk-de/2011-December/091009.html; and that is what I was correcting. This has absolutely nothing to do with whether Potlatch 2 has an abstraction model for one particular (broken) tagging paradigm, by which tags created in simple mode are applied to a 'containing' multipolygon relation rather than the way itself. That is the subject of your trac tickets. I have already explained why, given the likelihood of a proper area datatype to replace this nasty hack, I will not spend my own time coding that; but suggested: If you want it to be changed to additionally support tagging the relation, submit a good patch. I will be happy to help with the coding and UI issues for this patch. and again: if someone else who does come from a land where people use bonkers complicated multipolygons came up with a decent patch, I imagine we'd be very happy to accept it. But I realise that would require you to actually do some work rather than just endlessly, parasitically criticising others' work on the mailing lists. Richard -- View this message in context: http://gis.638310.n2.nabble.com/Potlatch-and-relation-handling-tp7089701p7089929.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Remapping Anleitung unbrauchbar?
Am 13. Dezember 2011 13:26 schrieb Walter Nordmann walter.nordm...@web.de: Martin Koppenhoefer wrote ... und wieso sollten Anfänger 2 Editoren lernen müssen (Erst Potlatch um zu bemerken, dass er nicht wie gewünscht funktioniert, und dann JOSM)? Schlimmer noch ist es, NICHT zu bemerken, dass etwas schief geht. wobei man sagen darf, dass es aufwärts geht. Richtige Unterstützung für Relationen, wie man sie von JOSM schon lange kennt, gibt es ansatzweise jetzt auch in Potlatch (immerhin werden alle tags und members sowie deren Rollen angezeigt, automatisches Erkennen von angeschlossenen ways und derlei fehlt momentan noch, aber theoretisch muss man nichts mehr automatisch kaputtmachen, und hat die Chance, alle Daten zu sehen). Ganz gut wäre es m.E., den Hauptunterschied von Potlatch und JOSM nicht im Ziel-Publikum Anfänger und Experten darzustellen, sondern die Typologie Online und Offline-Editor mit Darstellung der jeweils impliziten Vor- und Nachteile (Installation vs Flash, definiertes Runterladen vs. permanentes Laden, WMS-Support, etc.) Damit beziehe ich mich z.B. hierauf: http://wiki.openstreetmap.org/wiki/Beginners_Guide_1.3.2 erster Satz: Potlatch is an editor for OSM data. It is recommended for beginners. --- wieso ist der für Anfänger empfohlen? Ich würde diese Anfänger-Empfehlung komplett weglassen und nur Charakteristiken beschreiben (Potlatch is an editor for OSM data. It is based on Flash and because it is an online editor, you do not have to install anything but a permanent internet connection is required.) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google maps nutzt Geobasisdaten
Hallo Garry, man kann Objekte irrtümlich so zeichnen, dass sie sich mit Gebäuden kreuzen Ich sehe da kein Problem drin wenn es solche Überschneidungen gibt - im Gegenteil, man wird so zu genaueren Daten kommen weil der Fehler offensichtlich wird - sonst wird immer nur so lange hin- und her geschoben bis die Optik stimmt. Ja, das klingt sinnvoll. Bedingt aber einvernehmliche Qualitätskriterien. Wie erkennt man, dass etwas Formgerechtes auch lagerichtig ist? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Die Eisenbahninfrastruktur ist aber auch für die vielen Eisenbahnunternehmen oder Bahnmuseen interessant, auch wenn die vielleicht jetzt noch nicht unsere Karten nutzen. Genau deswegen sehe ich hier Handlungsbedarf und einen Grund diese Informationen einzutragen. Meine Frage ist nun: Kann ich Daten aus Führerstandsmitfahrten wie man sie z.B. auf Youtube findet, Nutzen und eintragen? Prinzipiell wird es doch sicherlich schwierig Streckendetails zu erfassen, da die wenigsten von uns im Führerstand sitzen ;-) Mich würde die praktische Erfassung der Daten daher sehr interessieren. Entweder man geht zu Fuß, etc. an die Gleise ran (wirklich nur soweit es erlaubt ist). Bei mir am Niederrhein sind die Gleise vor allem außerhalb der Bebauung leicht zugänglich, oft führen Feldwege parallel zum Gleis. Innerhalb von Bahnhöfen kann man natürlich auch von den Bahnsteigen aus alles fotografieren. Bei Videos auf Youtube würde ich immer den jeweiligen Ersteller fragen. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch and relation handling
2011/12/13 Richard Fairhurst rich...@systemed.net: But I realise that would require you to actually do some work rather than just endlessly, parasitically criticising others' work on the mailing lists. I do not think you have necessarily to be able to code Flash and improve Potlatch to be allowed to criticize it or point out bugs. After all it is still the most promoted editor (default editor on the start page, first shown and advertized for beginners in the beginner's tutorial). Btw: I am not aware of the concept of parasitical criticism, what do you intent? - reply offlist preferred to keep the noise low cheers, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Am Dienstag, 13. Dezember 2011, 06:38:43 schrieb ssho...@gmx.de: Moin, Die Eisenbahninfrastruktur ist aber auch für die vielen Eisenbahnunternehmen oder Bahnmuseen interessant, auch wenn die vielleicht jetzt noch nicht unsere Karten nutzen. Genau deswegen sehe ich hier Handlungsbedarf und einen Grund diese Informationen einzutragen. Meine Frage ist nun: Kann ich Daten aus Führerstandsmitfahrten wie man sie z.B. auf Youtube findet, Nutzen und eintragen? Prinzipiell wird es doch sicherlich schwierig Streckendetails zu erfassen, da die wenigsten von uns im Führerstand sitzen ;-) Mich würde die praktische Erfassung der Daten daher sehr interessieren. Die Standorte der Signale kann man auch gut auf den Aerowest-Bildern erkennen. Wenn man geübt ist, kann man an den Schatten sogar Signaltyp oder Größe erkennen... ;) Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] deutsche Abkürzungen in Eisenbahn-Spezialtags
Und woher kommen die freien Informationen? Solange du nur Signale und LZB-Kabel einträgst, wird niemand daran Anstoß finden. Aber die wesentlichen Details sind eher Höchstgeschwindigkeiten und zulässige Achslasten. Höchstgeschwindigkeiten lassen sich für Mapper natürlich nur anhand von Schildern eintragen. Bei Achslasten wirds dann praktisch unmöglich für Außenstehende. Wobei sich die Streckenklassen evtl. auch durch lange Beobachtung der verkehrenden Loks und Wagen ungefähr ermitteln lassen. Erstere kannst du ja noch per GPS mitscheniden, aber bei letzteren könnte der Verdacht aufkommen, dass jemand vom Infarstrukturregister, dem Eisenbahnatlas oder zur freien Verwendung von DB-Mitarbeitern überlassene interne Dokumente verwendet werden. Nicht von dir, aber vielleicht von anderen eintragenden. Man kommt als Mapper vielleicht jetzt noch nicht auf legalem Wege an diese Daten, aber möglicherweise (vor allem in anderen Ländern) gibt es in Zukunft auch Datenspenden von Staat, Bahnunternehmen, etc. Oder aber es gibt zukünftig vielleicht einzelne Privatbahnen, die das für ihre Strecke veröffentlichen. Nur weil ich das Tag vorgeschlagen hab, heißt das ja nicht, dass man die Informationen auch unbedingt eintragen muss. Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Frederik Ramm wrote: der OSM Inspector hat jetzt eine Lizenzwechselkarte, die taeglich aktualisiert wird und alle (*) Objekte zeigt, die vermutlich vom Lizenzwechsel betroffen sind: Auf tools.geofabrik.de/osmi gehen und dann oben im Dropdown License Change auswaehlen. Ein ganz großes Dankeschön dafür! Der Inspector war schon immer Gold wert und wird durch dieses Feature nun noch wertvoller! 3. Keine Erkennung von Way-Joins/Way-Splits - einige Ways, die jetzt fuer ok gehalten werden, koennten sich im Nachhinein als problematisch erweisen; oft sieht man das aber an den Nodes. Soll heißen: Wenn ich es schaffe alle kritischen Nodes loszuwerden (und alle kritischen Ways), dann ist mit großer Wahrscheinlichkeit alles bestens? Auf jedem Fall ist das eine tolle Basis um Wege, anhand von GPS-Daten, bereits jetzt komplett neu zu erstellen. Ich wollte ohnehin einmal für alle Wege, die hier noch keine GPS-Daten hinterlegt haben, diese ermitteln und hochladen. Mit Hilfe deiner Karte weiß ich nun welche Wege ich zuerst machen sollte. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] FOSSGIS-Conference - Call for papers - Deadline now: December, 23
Dear Free and Open Source GI-Software- and OSM-Users, please apologize any cross-postings.. FOSSGIS is a German-language conference (Free and Open Source GI Software and OpenStreetMap) primarily for a German audience. The program committee will, however, also consider applications for talks or workshops held in English if they are deeemed to add to the quality of the conference. So if you don't speak German, but are a FOSS/Open Data celebrity, or have a story that only you can tell, please do submit your talk. We are unlikely to be able to provide interpreters, but we'll make sure you don't get lost in Germany. Please be aware that you can submit paper until December, 23.: http://www.fossgis.de/konferenz/2012/callforpapers/ We are looking forward to see you in Dessau from March, 20. to March, 23. http://www.fossgis.de/konferenz/2012/ Your FOSSGIS-Team In German: Potsdam, 13. Dezember 2011 - Die FOSSGIS und OpenStreetMap Konferenz 2012 – die größte deutschsprachige Anwenderkonferenz für Freie Geo-Informationssysteme und freie Geodaten – findet vom 20. bis 22. März 2012 an der Hochschule Anhalt in Dessau-Roßlau statt. Die Konferenz bietet Ihnen die Möglichkeit, Ideen, Themen oder Anwendungen zum Thema OSM und Freie Geo-Informationssysteme und freie Geodaten zu präsentieren. Hierfür wurde die Frist für das Einreichen von Vorträgen, Poster oder Workshops noch bis zum 23.12.2011 verlängert. Ideen und Anreize finden Sie auch in den Vorträgen aus dem letzten Jahr unter http://www.fossgis.de/konferenz/2011/programm/index.de.html FOSSGIS ist die Abkürzung für Freie und Open Source Software für Geoinformationssysteme und ist die führende Konferenz zu diesem Thema im deutschsprachigen Raum. Ausgerichtet wird die FOSSGIS Konferenz 2012 vom gemeinnützigen Verein FOSSGIS e.V, der OpenStreetMap Community und der Open Source Geospatial Foundation (OSGeo) in Zusammenarbeit mit der Hochschule Anhalt in Dessau. Weitere Informationen finden Sie unter http://www.fossgis.de/konferenz/2012/callforpapers/ Wir freuen uns über Ihr Interesse und über eine aktive Teilnahme an der FOSSGIS 2012! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch and relation handling
Martin Koppenhoefer wrote: Btw: I am not aware of the concept of parasitical criticism, what do you intent? - reply offlist preferred to keep the noise low Replied offlist. Richard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Hallo, On 12/13/11 15:30, Manuel Reimer wrote: 3. Keine Erkennung von Way-Joins/Way-Splits - einige Ways, die jetzt fuer ok gehalten werden, koennten sich im Nachhinein als problematisch erweisen; oft sieht man das aber an den Nodes. Soll heißen: Wenn ich es schaffe alle kritischen Nodes loszuwerden (und alle kritischen Ways), dann ist mit großer Wahrscheinlichkeit alles bestens? Es ist keine Garantie. In einem Fall, in dem Nichtzustimmer A einen Way mit 50 Nodes anlegt und Zustimmer B den dann aufsplittet in zwei, wird der OSMI nur die eine Haelfte des Ways rot einmalen und die andere fuer sauber halten; in diesem Fall erkennt man aber an den Nodes, die ja dann alle rot sind, dass da etwas faul ist, und man wuerde vermutlich ohnehin den Way komplett neu erfassen. Es ist auch der umgekehrte Fall denkbar - Zustimmer A legt Way mit 25 Nodes an, Nichtzustimmer B merged den mit einem von ihm angelegten Way, der resultierende 50-Node-Weg ist nun rot, obwohl nur die Haelfte wirklich problematisch ist. Aber ich denke mal, dass es pragmatisch ist, das Problem zunaechst zu ignorieren. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Remapping Anleitung unbrauchbar?
Martin Koppenhoefer dieterdre...@gmail.com wrote: Danke Tirkon. Solche Dinge sollte man durchaus vermerken, da immer wieder behauptet wird, Potlatch sei ein Anfängereditor, aber die Realität ist, dass er für viele Dinge ungeeignet ist, und wieso sollten Anfänger 2 Editoren lernen müssen (Erst Potlatch um zu bemerken, dass er nicht wie gewünscht funktioniert, und dann JOSM)? Ich musste mich gerade eines Besseren belehren lassen: http://wiki.openstreetmap.org/wiki/User_talk:Tirkon#Please%20don%27t%20talk%20rubbish Kann jemand, der sich mit dem neuesten Potlatch auskennt, die Aussage von Richard bestätigen? Allerdings hatte Richard versehentlich auch den Punkt gelöscht, dass man zuvor auf Relationen prüfen sollte. Den habe ich wieder eingesetzt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
On 12/13/2011 09:18 AM, Frederik Ramm wrote: 2. Triviale Edits werden nicht automatisch erkannt -[...] wie steht es mit Trivial-Edits wie Created By entfernt? In meinem Fall betrifft das unter anderem Version #2 in http://www.openstreetmap.org/browse/node/315330552/history eine Änderung aus dem recht großflächigen Changeset http://www.openstreetmap.org/browse/changeset/107048 Ich habe mir nicht das gesamte Changeset angeschaut, aber zumindest bei einem Node und einem Way aus meiner näheren Umgebung ist das entfernte Created by tatsächlich die einzige Änderung. Nach einer Bot-Aktion sieht das allerdings nicht aus ... -- hartmut ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Hi, On 12/13/11 17:19, Hartmut Holzgraefe wrote: Ich habe mir nicht das gesamte Changeset angeschaut, aber zumindest bei einem Node und einem Way aus meiner näheren Umgebung ist das entfernte Created by tatsächlich die einzige Änderung. Nach einer Bot-Aktion sieht das allerdings nicht aus ... Sieht mir nach einem Fehler aus. Solche Aenderungen sollten als banal erkannt und nicht gewertet werden. Der was ist banal-Algorithmus kann hier ausprobiert werden: http://wtfe.gryph.de/harmless/node/315330552 Hier wird die ulfl-Aenderung als added tags erkannt, das scheint mir falsch. Ich untersuche das mal. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Frederik Ramm wrote: In einem Fall, in dem Nichtzustimmer A einen Way mit 50 Nodes anlegt und Zustimmer B den dann aufsplittet in zwei, wird der OSMI nur die eine Haelfte des Ways rot einmalen und die andere fuer sauber halten; in diesem Fall erkennt man aber an den Nodes, die ja dann alle rot sind, dass da etwas faul ist, und man wuerde vermutlich ohnehin den Way komplett neu erfassen. Wissenschaft für sich ;) Einen Verbesserungsvorschlag hätte ich noch: Könnte man beim Rotfärben unterscheiden zwischen Mapper hat noch garnicht reagiert und Mapper hat abgelehnt? Ich habe gerade festgestellt, dass bei uns die allermeisten Wege ursprünglich von ein und derselben Person erstellt wurden, die noch garnicht reagiert hat. Eine (hoffentlich) freundliche Nachricht mit Bitte um Zustimmung habe ich gerade gesendet. Anders sieht es bei so einigen Stromleitungen aus. Der hier zuständige Mapper hat abgelehnt. Eine Nachricht spare ich mir in dem Fall. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Potlatch and relation handling
Richard Fairhurst rich...@systemed.net wrote: Tirkon, I would be grateful if you would stop repeating the claim that there is no support. Hi Richard, The last time I used Potlatch, it did not work. So I changed to JOSM. Because I did not know this for sure I brought this question up at the discussion page of remapping: http://wiki.openstreetmap.org/wiki/Talk:Remapping But nobody had disagreed within more than two weeks so far. Thus I took it into the text. Thanks for clearing that up. But you deleted accidently more than this statement. Thus I have reinserted the rest: Be aware that every node and way can be a member of a relation and their parent-relations. It is recommended, to study and note down the structure of these relations before you delete any node and thus destroy relations i.e public transport, referenced roads (i.e. motorways), bicycle routes, borders and multipolygons. After replacing ways and nodes the old structure of the relations has to be reestablished. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Lizenzwechsel, OSMI und JOSM-Plugin sind sich nicht einig
Hallo, an dieser Stelle [1] fällt mir auf, dass der OSMI die Grambker Heerstraße anmeckert, während das Licensechange-Plugin (V27206) in JOSM (V4655) an der Straße nichts Böses findet - power:line wird gekennzeichnet. Schöpfen nicht beide aus einer Quelle? Gruß nk [1] http://tools.geofabrik.de/osmi/?view=wtfelon=8.71700lat=53.14204zoom=16opacity=0.44overlays=overview,wtfe_point_harmless,wtfe_line_harmless,wtfe_point_modified,wtfe_line_modified_cp,wtfe_line_modified,wtfe_point_created,wtfe_line_created_cp,wtfe_line_created ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] GPS Tracks vereinfacht hochladen?
Hallo, ich logge generell einen Punkt pro Sekunde. Bisher lade ich das Resultat auch so bei OSM hoch. Gerade habe ich gesehen, dass gpsbabel auch Tracks vereinfachen kann. Sollte man Tracks vor dem Hochladen so bearbeiten oder werden unveränderte Tracks lieber gesehen? Ist es sogar sinnvoll die Tracks zu vereinfachen, um Speicherplatz zu sparen? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Tracks vereinfacht hochladen?
Am 13. Dezember 2011 18:07 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: ich logge generell einen Punkt pro Sekunde. Bisher lade ich das Resultat auch so bei OSM hoch. Gerade habe ich gesehen, dass gpsbabel auch Tracks vereinfachen kann. Sollte man Tracks vor dem Hochladen so bearbeiten oder werden unveränderte Tracks lieber gesehen? Ist es sogar sinnvoll die Tracks zu vereinfachen, um Speicherplatz zu sparen? Ich finde Originaltracks am besten, manche manipulieren aus Datenschutzgründen das Datum (ist für bestimmte Anwendungsfälle auch schon weniger gut, wenn man das macht am Besten ein Datum vor GPS wählen, damit man es erkennen kann), Punkte rausrechnen würde ich eher nicht, aber das kommt auch drauf an, ob man nur Daten in Bewegung geloggt hat, oder auch Wolken aus längerem Aufenthalt drin sind. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OL statt Google-Api
Hallo Markus, aus vorherigem Thread: - - - - Any hints or help on how to start quickly porting the Google maps Api functionality into OSM would be highly appreciated. What is the best practice to overlay a large number of markers on OSM? - - - - Eine Art Migrations-Anleitung gibt es wohl eher nicht. Allgemein zu OpenLayers gibt es halt die üblichen Links [1][2]. Speziell für viele Markers wäre vermutlich eine PostGIS DB Anbindung über eigenes Script mit Vector Layer und BBox Strategy geeignet [3], evtl. mit anderem Format als Text, z.B. GeoJSON. Optional auch noch mit Clustering [4]. Generell würde ich solche direkten Anfragen an talk oder help.openstreetmap.org verweisen, dann kann man besser direkt nachfragen. Gruß, ikonor [1] http://openlayers.org: Examples and User documentation [2] http://wiki.openstreetmap.org/wiki/OpenLayers [3] http://openlayers.org/dev/examples/dynamic-text-layer.html [4] http://www.openlayers.org/dev/examples/?q=cluster Am 12.12.2011 20:10, schrieb Markus: Hallo Bernhard, Danke für die KHTML-Tips. Wer kann erklären, wie man es mit *OL* macht? how to start porting the Google maps Api functionality into OSM Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Ich habe hier http://odbl.poole.ch/garmin/ mal experimentelle Garmin Karten mit Frederiks Daten generiert. Das ganze braucht auf jeden fall noch etwas Tuning die Karten aber sind an sich schon brauchbar. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel, OSMI und JOSM-Plugin sind sich nicht einig
Hi, On 12/13/2011 06:08 PM, Norbert Kück wrote: an dieser Stelle [1] fällt mir auf, dass der OSMI die Grambker Heerstraße anmeckert, während das Licensechange-Plugin (V27206) in JOSM (V4655) an der Straße nichts Böses findet - power:line wird gekennzeichnet. Beide sollten aus einer Quelle schoepfen. Im konkrten Fall ist zumindest das noerdliche Stueck von einem anonymen Nutzer gezeichnet, der nicht zugestimmt hat - rot ist also richtig. Das JOSM-Plugin scheint das nicht korrekt anzuzeigen. 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-View im OSM Inspector
Hallo, On 12/13/2011 05:45 PM, Manuel Reimer wrote: Einen Verbesserungsvorschlag hätte ich noch: Könnte man beim Rotfärben unterscheiden zwischen Mapper hat noch garnicht reagiert und Mapper hat abgelehnt? Eigentlich hatte ich das gerade auch in JOSM umgestellt mit dem Gedanken: Jetzt wird es langsam Zeit, wer bis jetzt noch nicht zugestimmt hat, auf den koennen wir auch nicht laenger warten. So viele der noch-nicht-Zustimmer sind unerreichbar oder unwillig, da waere es bloss Augenwischerei, wenn man die auf der Karte noch als irgendwie rettbar hinstellt. - Umgekehrt koennte man ja auch bei einem Ablehner durchaus versuchen, ihn umzustimmen - das hat schon bei einigen geklappt. 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] Nutzung OpenData der Vermessungsverwaltung Bayern
Hallo, wie bereits erwähnt, habe ich bei der Vermessungsverwaltung angefragt, unter welchen Bedingungen die unter CC-BY veröffentlichten Daten genutzt werden dürfen. Mittlerweile habe ich Antwort erhalten. Die E-Mail hängt im Original an diesem Posting. Im Wiki habe ich schonmal einen Versuch gemacht, die entsprechende Namensnennung wie vorgeschrieben durchzuführen: http://wiki.openstreetmap.org/wiki/Contributors#Germany Wer kann http://www.openstreetmap.org/copyright editieren? Soweit ich das verstanden habe, legt die Vermessungsverwaltung viel Wert auf den exakten Wortlaut bei der Quellennennung. Irgendwo sollte also Datenquelle: Bayerische Vermessungsverwaltung – www.geodaten.bayern.de stehen. Am besten in Klammern. Ich würde das www.geodaten.bayern.de nicht verlinken und stattdessen einen Link auf http://vermessung.bayern.de/opendata setzen. Verwirrend ist (wie auch aus der E-Mail ersichtlich) die Tatsache, dass nicht alles auf der Seite auch unter CC-BY lizenziert ist...! Gruß Manuel P.S. Am Konverter von ovl nach gpx bin ich noch dran. Ich versuche noch diese Woche etwas fertiges zu veröffentlichen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel, OSMI und JOSM-Plugin sind sich nicht einig
Hallo, am 13.12.2011 20:48 schrieb Frederik Ramm: On 12/13/2011 06:08 PM, Norbert Kück wrote: an dieser Stelle [1] fällt mir auf, dass der OSMI die Grambker Heerstraße anmeckert, während das Licensechange-Plugin (V27206) in JOSM (V4655) an der Straße nichts Böses findet - power:line wird gekennzeichnet. Beide sollten aus einer Quelle schoepfen. Im konkrten Fall ist zumindest das noerdliche Stueck von einem anonymen Nutzer gezeichnet, der nicht zugestimmt hat - rot ist also richtig. Das JOSM-Plugin scheint das nicht korrekt anzuzeigen. Scheinbar hat JOSM (+ Zubehör) noch mehr Probleme mit dem Lizenzwechsel-Akzeptanz-Status: Das Fenster Versionsprotokoll zeigt keine Häkchen mehr für die Nutzer. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-View im OSM Inspector
Hallo, On 12/13/2011 05:28 PM, Frederik Ramm wrote: On 12/13/11 17:19, Hartmut Holzgraefe wrote: Ich habe mir nicht das gesamte Changeset angeschaut, aber zumindest bei einem Node und einem Way aus meiner näheren Umgebung ist das entfernte Created by tatsächlich die einzige Änderung. Nach einer Bot-Aktion sieht das allerdings nicht aus ... Hier wird die ulfl-Aenderung als added tags erkannt, das scheint mir falsch. Ich untersuche das mal. Argh, Tomaten auf den Augen. Du hattest als Erstautor ein tag cusine gesetzt, und Ulf hat das auf cuisine verbessert! Im Sinne des Urheberrechts duerfte das schon eine triviale Aenderung sein, die Ulf keine Schutzansprueche bringt. Aber wie mach ich das dem Computer klar? Kann/soll man sagen, dass alles, was nur ein Buchstabe Unterschied ist, unproblematisch ist oder...? Ich vermute, jede Regel, die man sich ausdenkt, geht irgendwo schief ;) 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-View im OSM Inspector
Hi, On 12/13/2011 09:56 PM, Frederik Ramm wrote: Argh, Tomaten auf den Augen. Du hattest als Erstautor ein tag cusine gesetzt, und Ulf hat das auf cuisine verbessert! Ich hab mein was sind harmlose Aenderungen-Skript mal dahingehend ergaenzt, dass es simple Aenderungen an einem Key als harmlos einstuft. Ich bin aber nicht sicher, ob das tragfaehig ist, und habe es daher mal noch nicht fuer die grosse Karte eingeschaltet. Der hier diskutierte Node wuerde dadurch gelb statt orange: http://wtfe.gryph.de/harmless/node/315330552 Auch die emergency=fire_hydrant-Spielchen von JohnSmith werden hierdurch nicht mehr als wichtig bewertet: http://wtfe.gryph.de/harmless/node/775733979 Fallen Euch Beispiele ein, bei dem das Austauschen eines Keys ein echtes Werk sein koennte? 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] GPS Tracks vereinfacht hochladen?
Am 13.12.2011 18:48, schrieb Martin Koppenhoefer: Am 13. Dezember 2011 18:07 schrieb Manuel Reimermanuel.s...@nurfuerspam.de: ich logge generell einen Punkt pro Sekunde. Bisher lade ich das Resultat auch so bei OSM hoch. Gerade habe ich gesehen, dass gpsbabel auch Tracks vereinfachen kann. Sollte man Tracks vor dem Hochladen so bearbeiten oder werden unveränderte Tracks lieber gesehen? Ist es sogar sinnvoll die Tracks zu vereinfachen, um Speicherplatz zu sparen? Ich finde Originaltracks am besten, [...] [...] aber das kommt auch drauf an, ob man nur Daten in Bewegung geloggt hat, oder auch Wolken aus längerem Aufenthalt drin sind. +1 Ich bereinige mit RouteConverter grundsätzlich auf 1 m Abstand, um die angesprochenen Punktwolken zu beseitigen. Auch prüfe ich auf absolute Ausreißer und bereinige diese entsprechend - mein Navi zeichnet je nach verwendeter Software auch schonmal ab den ersten Satellitendaten auf, da sind dann schonmal sehr schlechte Werte dabei. Speicherplatz würde ich nicht als Problem ansehen - aber so manche hochgeladenen Original-Tracks dienen anscheinend eher dazu, die Spuren zu verwischen ... Die von Martin angesprochenen bestimmten Anwendungsfälle erfordern allerdings auch unter entsprechenden Anwendungsfällen aufgezeichnete Tracks - meine Mapping-Praxis weicht dazu doch zu sehr vom Verkehrsfluss ab, mehr als ich war mal da bieten sie nicht an sinnvoller Information. Allein aus dem Grund lade ich sie auch als Privat hoch, damit sie nicht irrtümlich Verkehrsfluss-Analysen verfälschen. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
