Re: [Talk-de] Eigene OSM-Wikiseite für Radfahr-Verei ne
malenki o...@malenki.ch wrote: Es muss aber möglich sein, die offiziellen Routen von den inoffiziellen/privaten Routen zu separieren. Stell dir mal vor, es werden jetzt Relationen angelegt, a la Mein Arbeitsweg oder Abteilungskanufahrt 2005... Wer solche Daten sammeln will, kann das gern tun, aber bitte auf einer eigenen Seite und z.B. mit Openlayers mit einer OSM-Karte überlagern. Aber für die OSM-Datenbank ist das nichts, auch mit einem Privat- oder inoffiziell-Tag. Damit wären wir jetzt bei einer Relevanzdiskussion angekommen. *göbel* Nicht wirklich. Was nicht existiert, wird nicht gemappt. Hmm, wir haben beispielsweise Adressangaben mit Ortsnennung auch außerhalb geschlossener Ortschaften, die aber bei der Navigation zu Adressen unverzichtbar sind. Auf dem Lande ist die Bebauung nun mal nicht so dicht, dass jedes Haus durch Ortsbeschilderung eindeutig zuzuordnen wäre. Die Ortsangabe in der Adresse ist also hier vor Ort in vielen Fällen nicht ermittelbar, sondern nur anhand der Grenzgesetzgebung feststellbar. Die Frage ist also, wie man existiert definiert. Man kann natürlich Reizworte zum Anheizen verwenden. Anheizen war nicht meine Absicht. Es ging mir dabei eher um das Gegenteil und um den Bezug zu dem Thread Von Wikipedia lernen, wo dieses Reizwort schon Thema war, wie ich im Weiteren in meinem Posting auch ausgeführt habe. Spätestens jetzt, wo Missverständnisse bezüglich der Intention des Wortgebrauches auftreten, komme ich daher auch zu dem Entschluss, mein ursprüngliches Ansinnen einer Wikiseite für Radfahrvereine fallen zu lassen. Sie könnte potentiell umstrittenen Stoff in OSM hineinspülen und dafür ist sie mir nicht wichtig genug. Ich hoffe, das macht deutlich, dass ich eher auf Deeskalation als auf Anheizen bedacht bin. Es geht mir schließlich in der Hauptsache um Aquirierung von Mappern in einem dünn besiedelten und daher OSM-mäßig schlecht erschlossenen Bereich, in dem zudem auch nur wenige offizielle Routen existieren. Die gibt es offensichtlich nur in den Köpfen insbesondere der Radfahrvereine, aber nicht ausgeschildert. Das war meine Intention. Aber OSM dürfte für radfahrende und wandernde Vereine auch ohne Wikiseite und eigene Routen ihren Nutzen haben. Vielleicht gibt es irgendwann mal einen OSM Datenbank Layer für nichtoffizielle Routen. Dann wäre die ganze Diskussion nämlich vom Tisch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bundesrepublikanische Grenzrelation unterbrochen
Norbert Kück o...@nk-bre.net wrote: Hallo, am 08.05.2010 21:41 schrieb Tirkon: ich habe die bundesrepublikanische Grenzerelation http://www.openstreetmap.org/?relation=62781 (Download dauert) Dir ist aber schon klar, dass die Relation nicht die Grenze darstellt? Ja, nicht umsonst habe ich hier eine Diskussion um die Dokumentation der deutsch-niederländischen Grenzauseinandersetzung angestoßen. Das Ding (so die damalige Diskussion) soll die Landmasse darstellen - tut sie aber nicht, wie man an der Wesermündung erkennen kann. Theoretisch müsste es dann jeden Flußlauf bis zur Quelle nachstellen. Jetzt verstehe ich auch, wieso da die Entscheidung im Falle der Elbmündung so schwer fiel. Denn genau dort fehlt das Aufeinandertreffen der Landmassen von Niedersachsen und Schleswig-Holstein. Hinzu kommt die bisher nicht abgeschlossene Grenzauseinandersetzung in diesem Bereich. Ist eigentlich die Landmasse von Niedersachsen Relation 454192 ebenso zweckfrei? Bei Landkreisen zählt nur die Landmasse. Bei Bundesländern weiß ich es nicht. Weil ich das als zweckfreie Malerei einstufe, stört es mich aber nicht weiter. Dann werde ich sie mit Deinem Einverständnis auch als Landmasse titulieren und willkürlich an einer Annäherung der Landmassen Niedersachsens und Schleswig Holstein schließen. Denn wenn man unvermuteterweise mit dem Teil bei der grenznahen Ortsgrenzenbestimmung in Konflikt kommt, stört es, weil man nicht weiß, wie man damit korrekt umgehen soll. Wenn das Teil zumindest einigermaßen der Intention gemäß geschlossen ist, hat man wenigstens diese Sorge weniger. Sonst thematisiert sich das immer wieder. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene OSM-Wikiseite für Radfahr-Vere ine
Thomas Wedekind tom-wedek...@web.de wrote: ... Wäre m.E. der wirkliche Grenzfall für die Aufnahme in OSM. Vielen Dank für die Aufklärung. Ein Grund mehr, lökalen Sachverstand bezüglich der Radrouten nach OSM zu holen, den ich insbesondere in der großen betreuten Fläche nicht habe. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bundesrepublikanische Grenzrelation unterbrochen
Norbert Kück o...@nk-bre.net wrote: [...] Könnte man zusammenfassend sagen, dass jede seegerichtete Grenze bei OSM fraglich ist? Oder haben wir auch etwas Dahingehendes, das zumindest nahezu richtig ist? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Eigene OSM-Wikiseite für Radfahr-Verei ne
Moin, um OSM in Ostfriesland ein wenig bekannter zu machen und um Mapper zu aquirieren, plane ich den Besuch lokaler ADFC Treffen. Dabei stellt sich die Frage, ob man den Gruppen auf Wunsch eine Seite im OSM Wiki zugestehen könnte, auf der sie ihre Routen und Touren verlinken und gegebenenfalls kommentieren können, welche in der OSM Karte existieren. Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene OSM-Wikiseite für Radfahr-Verei ne
aighes h.scholl...@googlemail.com wrote: Allerdings fände ich es besser, wenn die Routen auf einer Seite gesammelt werden würde. Das Übliche im Wiki halt: Man beginnt mit einer ADFC-Seite, die Unterkapitel nach Bundesländern hat und weiter nach Kreis- und Ortsverbänden. Wenn sich für ein Bundesland ein größerer Bedarf auftut, expandiert man auf eine eigene Seite und verlinkt diese auf der ADFC-Seite. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene OSM-Wikiseite für Radfahr-Verei ne
Carsten Gerlach daswaldh...@gmx.de wrote: Es muss aber möglich sein, die offiziellen Routen von den inoffiziellen/privaten Routen zu separieren. Stell dir mal vor, es werden jetzt Relationen angelegt, a la Mein Arbeitsweg oder Abteilungskanufahrt 2005... Wer solche Daten sammeln will, kann das gern tun, aber bitte auf einer eigenen Seite und z.B. mit Openlayers mit einer OSM-Karte überlagern. Aber für die OSM-Datenbank ist das nichts, auch mit einem Privat- oder inoffiziell-Tag. Damit wären wir jetzt bei einer Relevanzdiskussion angekommen. Soweit ich den bisherigen Konsens interpretiere, sind den meisten OSM-Usern die entsprechenden Relevanz-Regeln und -Diskussionen auf Wikipedia lästig bis zuwider und daher auf OSM kein Thema. Einige sehen in OSM sogar den Konterpart zur Wikipedia und wollen hier zeigen, dass Alles und nicht nur Ezyklopädisches dokumentierbar sei. Man könne durch technische Massnahmen den Stoff genügend gliedern und filtern, um dasjenige zu finden, was man braucht. Das Einzige, was von einer Mehrheit für OSM zumindest bisher wegen fehlender Recourcen ausgeschlossen wurde, sind fiktive und nicht mehr existente geschichtliche Objekte. Eventuell könnte diese Begrenzung auch für Privates und Inoffizielles herangezogen werden. Dann aber müsste man definieren, was offiziell und inoffiziell ist und hätte die erste Relevanzregel, die unter die Rubrik Geschmackssache fiele und über deren Formulierung und Auslegung man geteilter Meinung sein kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
AssetBurned openstreet...@assetburned.de wrote: Deine Zitierweise könnte man so interpretieren das du mir unterstellen willst ich würde die admins da ausdrücklich in eine rechte ecke stellen wollen. Dies unterstreichst du mit gleich zwei links die ich nicht gepostet habe sondern du. Im gegenzu löscht du den link den ich gepostet habe und um so anderen den zugang zu alternativ bedeutungen zu erschweren. also wer führt hier eine diskussion mit Ideologien? (um hier mal dieser mail etwas vorzugreifen) Ich wollte Dir lediglich vor Augen führen, das Du da einen zumindest negativ konotierten Begriff benutzt. Das hat nicht damit zu tun, was ich oder Du dem Begriff zuschreiben. Und egal, was jetzt tatsächlich seine Bedeutung ist: Es wird schon etwas an dem so Bezeichneten hängenbleiben. Und wenn man jemanden so bezeichnet, dann kann man nicht mehr erwarten, dass dieser noch bereit ist, wohlwollend zu diskutieren. Das war die Kernaussage. Alles Weitere, was Du da in Deinem Gesamtposting bezüglich meiner Person konstruierst, ist an den Haaren herbeigezogen. Man zitiert den zentralen Punkt, auf den man reagiert. Alles andere kann man in den Postings zuvor nachlesen. Würde jeder hier ein Fullquoting der Vorpostings machen, würde das nach spätestens zehn Antworten niemand mehr lesen wollen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eigene OSM-Wikiseite für Radfahr-Verei ne
AssetBurned openstreet...@assetburned.de wrote: hast du dir schonmal die OSM datenbank angeguckt? http://tagstat.hypercube.telascience.org/search.php?query=game was bitte soll sowas? aber beschwert sich da wer drüber? Falls die Frage an mich gerichtet war: Ich kann Deine Frage nicht beantworten, weil ich die Technik nicht verstehe. Ich weiß weder, was der Link technisch bezweckt noch was er aussagt. Wenn man sich beschweren sollte, tu es. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] bundesrepublikanische Grenzrelation unterbrochen
Moin, ich habe die bundesrepublikanische Grenzerelation http://www.openstreetmap.org/?relation=62781 (Download dauert) sortiert. Dabei fiel mir auf, dass Sie an der Elbmündung in die Nordsee ein Loch hat. Könnte vielleicht jemand mit Ortskenntnissen drüberschauen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Müssen Gebiete verbunden sein? la nduse=residential mit name-Tag?
M?rtin Koppenhoefer dieterdre...@gmail.com wrote: Ich würde das nur tun, wenn der Name der des Gebiets ist (Wohngebietsname). Das ganze Dorf sollte per place-polygon (oder Node) definiert sein, dort gehört dann der Dorfname hin. Hmm, Es sind nicht immer nur nur Wohngebiete, die zu einem Dorf gehören. Da kann zum Beispiel auch Industrie oder Landwirtschaft sein. Wie wäre es mit einer boundary=administrative und admin_level=11? http://wiki.openstreetmap.org/wiki/DE:Grenze#Kommunale_Ebene_-_Ortsteile_-_admin_level.3D9-11 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM zeigt beteiligte Relationen nicht an
Moin, ich wähle in JOSM eine boundary=administrative aus. Obwohl diese Mitglied in zwei Relationen ist, wird nur eine davon im Eigenschaftenfeld angezeigt. Ist das nach Eurer Auffassung ein Bug? Nach meiner Auffassung schon. Denn jetzt erstelle ich eine Relation, die schon existiert. Von Potlatch her kannte ich diesen Fehler nicht. Der zeigt immer alle beteiligten Relationen an. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Relationsbündel in JOSM herunterladen
Moin, mit JOSM kann ich gezielt einzelne Relationen herunterladen. Dies ist recht mühsam, da man zunächst einmal außerhalb von JSOM die IDs der Realtionen ermitteln muss und dann einzeln heruntwerladen. Habe ich jetzt ein Bündel von Relationen zusammengestellt, so möchte ich dieses immer wieder aufrufen. Kann ich die Auswahl dieses Relationsbündels irgendwie abspeichern und später wieder aufrufen? Ich benötige das Ganze, um in einem Gebiet alle Orts- und Ortsteilgrenzen auf dem Schirm zu haben. Gibt es da andere Möglichkeiten, als die oben beschriebene, dies zu bewerkstelligen? Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM zeigt beteiligte Relationen nicht an
bundesrainer o...@bundesrainer.de wrote: ich wähle in JOSM eine boundary=administrative aus. Obwohl diese Mitglied in zwei Relationen ist, wird nur eine davon im Eigenschaftenfeld angezeigt. Ist das nach Eurer Auffassung ein Bug? Hm, wie hast du denn die Grenze in JOSM geladen? Über einen Kartenausschnitt? Oder hast du sie als Objekt geladen bzw. über das Remote-Plugin? Das Letztere. Den zweiten Fall kenne ich auch und ich bin schon einige mal darüber gestolpert. Da musst die Elternrelationen nachladen (Strg + Alt + D) Auf der einen Seite wäre es hilfreich, wenn JOSM das im Falle des Anklickens selbst anstoßen könnte. Auf der anderen Seite könnte das vermutlich viel unnötige Serverlast erzeugen. Kein Weg aus dem Dilemma? Nach meiner Auffassung schon. Denn jetzt erstelle ich eine Relation, die schon existiert. Oder du machst Änderungen an den Wegen die in andere Relationen nicht übernommen werden. Auch ärgerlich. Ahja, das erklärt Einiges. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM zeigt beteiligte Relationen nicht an
Sebastian Klein basti...@googlemail.com wrote: Von Potlatch her kannte ich diesen Fehler nicht. Der zeigt immer alle beteiligten Relationen an. Potlatch bedient sich ja auch direkt bei der Datenbank und ist nicht auf die API angewiesen... Hat das Verfahren, sich bei der Datenbank zu bedienen, nur Vorteile oder auch Nachteile? Warum benutzt JOSM es nicht? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM zeigt beteiligte Relationen nicht an
bundesrainer o...@bundesrainer.de wrote: Nach meiner Auffassung schon. Denn jetzt erstelle ich eine Relation, die schon existiert. Oder du machst Änderungen an den Wegen die in andere Relationen nicht übernommen werden. Auch ärgerlich. Dazu noch eine Zusatzfrage: Leider braucht man in Ostfriesland als Außengrenze die Recourcen-fressenden niedersächsischen, bundesdeutschen und niederländischen Relationen im Boot. Reicht es, wenn diese unvollständig, nämlich nur im bearbeiten Bereich geladen sind? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationsbündel in JOSM herunterladen
Frederik Ramm frede...@remote.org wrote: Wenn man sich ein File anlegen wuerde, in dem nur die Relations-Ruempfe stehen: osm version=0.6 relation id=897709 version=1 / /osm Dann kann man das in JOSM laden Du meinst über den Öffnen Dialog? Kann man für das Laden dieses Files auch Irgendetwas in JOSM anlegen, das man nur noch anklicken muss? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationsbündel in JOSM herunterladen
Florian Lohoff f...@zz.de wrote: Also ich mache das anders - Einfach im JOSM eine kleines stueck der Grenze downloaden - Es reicht ein einziger node - Damit bekommt man den weg - Dann die relation aufmachen und die childs downloaden. Damit hat man die gesamte relation bzw ganze grenze auf einmal drin ohne den restlichen ramsch. Meinst Du mit childs die Members der Relation? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Relationsbündel in JOSM herunterladen
bundesrainer o...@bundesrainer.de wrote: Es ist ganz nett, wenn du eingezeichnete Grenzen auch dokumentierst [1] Im Moment bastele ich noch im Zusammenhang mit den Straßenlisten daran. Dann gehen die lokalen User drüber und zuletzt werden sie veröffentlicht. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fw: Bezugsquelle aktuelles Gemeindestrassenverzeichnis?
Torsten Breda torst...@gmail.com wrote: Sehr erfolgreich ist man, wenn man direkt bei der Gemeinde vorbei schaut. Dann gibts die Liste meist in die Hand gedrückt (reicht ja für den internen Abgleich schon aus) oder man kommt an jemand Informierten, der einem die weitere Verarbeitung erlaubt. Leider sitzen manche Verwaltungen auf den Listen. Mit den Politikern im Gemeinde- oder Stadtrat trifft man auf so etwas wie deren Arbeitgeber. Und diese Kommunalpolitiker wollen sich in den Ratssitzungen gern profilieren. Dort gibt es regelmässig eine Bürgerfragestunde, die häufig Unangenehmes und Kosten nach sich zieht. Wenn man dort nach solch einer Straßenliste für OSM fragt, wird das wohl in den meisten Fällen mit Freuden positiv beschieden. Denn so billig, einfach und ohne jeden Ärger kommen die Politiker in der Fragestunde selten davon. Wenn man dann seine Bitte mit einer kurzen Vorstellung von OSM verbindet, und sich dabei auch den anwesenden Lokalreportern zuwendet, beißen diese mit etwas Glück auch noch an und wollen mehr wissen. Beim Vortrag sollte man das Wort ehrenamtlich einige Male fallen lassen. Das kommt gut an. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Warum heißen Landkreise nicht Landkrei s?
Moin, am Beispiel des Kreises Mettmann http://www.openstreetmap.org/browse/relation/62423 hätte ich gern mal gefragt, warum Kreise/Landkreise in OSM nicht so heißen? Zumindest habe ich keine gefunden. So kommt Mettmann in der Karte zweimal vor, einmal als Bezeichnung des Kreises Mettmann und einmal der Kreisstadt Mettmann. Hat das einen tieferen Sinn oder kann ich den Kreisnamen zu Kreis Mettmann ändern? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Warum heißen Landkreise nicht Landkrei s?
Gerry Light gerrylight...@googlemail.com wrote: Ich bin der gleichen Meinung, weil das Zusammensetzen hinterher wesentlich leichter ist als das Auseinanderpfrimeln. Mir ist nicht ganz klar, was Du zusammensetzt und auseinanderfrimelst. Könntest Du das am Beispiel des von mir genannten Kreises/Stadt Mettmann mal klarmachen? Ich schlage das Tag name:prefix vor (habe das mal bei ein Gemeinderelationen aus der Not heraus erfunden). Sorry, aber ich verstehe nur Bahnhof. Wir haben einen kryptischen admin_level, der die Hierarchiestufe angibt, bei Kreisen admin_level=6. Soll das name Tag das Ganze nicht in Klartext übersetzen? Wenn nein, wozu ist es da? Irgendetwas muss dem Renderer doch sagen, was er nun in die Karte schreiben soll. Und bisher bin ich immer davon ausgegangen, dass das name Tag dafür zuständig sei. Wie wäre das name Tag und das name:prefix konkret anzuwenden? So?: Kreis Mettmann: admin_level=6 name=Mettmann name:Kreis Stadt Mettmann: name=Mettmann name:prefix=Stadt Landkreis Wittmund: admin_level=6 name=Wittmund name:prefix=Landkreis Stadt Wittmund: name=Wittmund name:prefix=Stadt Stadt Düsseldorf: (kreisfreie Stadt) admin_level=6 name=Düsseldorf name:prefix=Stadt Was aber sagt dem Renderer nun, dass er in der Karte bei der Stadt das prefix wegläßt und beim Kreis/Landkreis nicht? Bisher habe ich die Zuständigkeit für den Karteneintrag immer beim name Tag gesehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Legende deutsche OSM Karte: Kreisstra ßen
In der Legende zur deutschen OSM Karte sind Landstraßen (secondary) und Kreisstraßen (tertiary) ab Zoom =9 in einem Atemzug genannt und beiden die Farbe orange zugeordnet. Tatsächlich sind die Kreisstra0en entweder nicht vorhanden (Zoom 9), grau (Zoom 10 bis 12) oder gelb (Zoom =13). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Skobbler berücksichtig turn-restrictio ns! / Sammelstelle für Routingfehler
Oliver Kuehn (skobbler) osm.oliver.ku...@gmx.de wrote: [1] http://beta.skobbler.de/osmbugs Wobei sich die Cloudmade Darstellung in den höheren Zoomstufen erst nach zigmaligem Wechsel mit beispielsweise Mapnik einstellt. Beim ersten Anzeigen kommt meist nichts. Bei jedem Wechsel gibt es - wenn man Glüch hat - ein Zugabe. Wenn überhaupt die Darstellung vollständig wird, braucht man dazu zehn oder ein mehrfaches an Wechseln. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behandlung parallel zur Straße verlauf ender Fuß-/Radwege
Thomas Ineichen osm.mailingl...@t-i.ch wrote: Einziger Konsens ist, dass man (im Normalfall) nicht die Arbeit anderer löscht. Wenn sich also jemand die Mühe gemacht hat, die Fusswege einzeln einzuzeichnen, dann sollte man sie auch in OSM lassen. Andererseits ist es auch Konsens, nicht korrektes Mapping zu löschen. Wenn Du an obigem Kartenausschnitt etwas ändern möchtest, dann verbinde die Fusswege an den Kreuzungen mit den (Auto-)Strassen, damit die Fusswege auch fürs Routing benutzt werden können. Hmm, aber genau hier liegt doch die Krux. Wenn ich das Original-Posting richtig verstanden habe, dann besteht nicht nur an den Kreuzungen sondern an jeder Stelle eine fußläufige Verbindung zur Straße. Damit ist sie an jeder Stelle querbar. Und genau das gibt der getrennt gemappte Fu0weg nicht wider. Streng genommen ist das Mapping damit zumindest nicht korrekt und daher zumindest ein Nachdenken über ein Löschen des Fußweges nicht ganz unberechtigt. Es müsste demnach tatsächlich über eine Ersatzlösung nachgedacht werden, welche die fußläufige Verbindung zur Straße an jeder Stelle auch widergibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Behandlung parallel zur Straße verlauf ender Fuß-/Radwege
Rainer Kluge rklug...@web.de wrote: Meine Frage war wohl falsch formuliert. Es handelt sich um einen Gehsteig, so wie er innerorts an fast allen Strassen beidseitig zu finden ist, auch Bürgersteig oder Trottoir genannt, auf Englisch sidewalk. Ich glaube irgendwo gelesen zu haben, dass man innerorts, wenn nichts anderes angegeben ist, davon ausgeht, dass sich rechts und links der Straße ein solcher Gehweg befindet. Tja, das mag in Städten so sein. Hier auf dem Land ist das die Ausnahme. Meist einseitige kombinierte Rad-/Fußwege gibt es innerorts fast nur an Bundes-, Landes- und Kreisstraßen. Auf den innerörtlichen Gemeindestraßen insbesondere in den Eigenheim-Siedlungen läuft man fast immer auf der Straße. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
AssetBurned openstreet...@assetburned.de wrote: komme ich also wieder zu den punkt: wenn die WP mehr zeit in sinnvolle arbeit (hier also ausbau der MediaWiki) stecken würde, und nicht in Blockwart verhalten... dann könnte man mit der WP deutlich mehr spass haben und es gäbe auch weniger zoff. Ich beschränke mich in der Wikipedia auf die Artikelarbeit und kann keine kompetenten Aussagen zur Programmierung machen. Offensichtlich war es so, dass die freiwilligen Programmierer das von Dir Geforderte nicht schultern konnten. Auch beim letzten CCC Kongress wurde Wikipedia thematisiert und auch dort wurden die Forderungen nach verbesserter Benutzerfreundlichkeit laut. Ein entsprechender Aufruf an das mit Programmierern reich gesegnete CCC-Auditorium fand allerdings wohl keine Resonanz. Und deswegen wurde wohl nun auch der Programmierer bei Wikimedia eingestellt. Die Beta Version von Mediawiki kann jetzt - allerdings nur als angemeldeter Benutzer der Wikipedia - eingeschaltet werden und macht beispielsweise ausgiebig vom Mouse-Hoovering (Drüberhalten) auch innerhalb eines Artikels Gebrauch. Es gibt auch einen Rückmeldekanal. Vielleicht magst Du reinschauen und Deine hier geäußerte Kritik formulieren. Mit der Einstellung des Programmierers fördert Wikimedia nicht nur die Wikipedia, sondern auch jedes andere Projekt, das die Mediawiki Software nutzt, also auch OSM. Möglicherweise ein Grund mehr für diejenigen, welche als Programmierer die Möglichkeiten ahnen, dort Stellung zu beziehen. Blockwart -- http://de.wikipedia.org/wiki/Blockwart Ich finde das bei allem Verständnis für Verärgerung eine unangemessene und diskriminierende Bezeichnung für Leute, welche die Drecksarbeit machen, z.B. Tag für Tag und unendlich oft f..., Ar... sowie sonstiges Gestrüpp aus Wikipedia entfernen, das man ansonsten anstatt von Artikeln zu sehen bekäme. Die Wikipedia verkäme zu einer Müllhalde, die weder Inkludisten noch Exkludisten sehen wollten. Die Bezeichnung ist geeignet, Fronten zu verhärten anstatt aufzuweichen. Ich würde es als einen guten Willen zum Aufbau einer Internet Kultur mit Anstand ansehen, wenn man da eine angemessenere Bezeichnung finden könnte. Mit dem Begriff Hausmeister könnte ich mich schon eher anfreunden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
AssetBurned openstreet...@assetburned.de wrote: wenn dann aber bei der durchsicht der ausgaben auffällt das eigentlich nur ein einziger proxy von der wikimedia deutschland finanziert wurde (um die antwortzeiten für europäische nutzer zu verringern) Naja, ganz so schlimm ist es nun doch nicht: Beispielsweise wurden für 15.000 Euro drei Server angschafft, die OSM für Wikipedia spiegeln und OSM-bezogene Tools hosten, z.B. Karte in Landessprache der jeweiligen Wikipedia. und auch diese anschaffung eher ein verlegenheitslösung war, da ansonsten nur geld für reisekosten, büromaterialen und anderer krams ausgegeben wurde... da musste ich schon einige überzeugungsarbeit leisten das dieses geld nicht verpufft und aufgrund neuer räumlichkeiten dezentraler strukturen (reisekosten) und ähnlichen ausgegeben wurde. Es gibt Wikipedia Autoren, die leicht vierstellige Beträge aus der Privatschatulle für Literatur ausgegeben, um ihre Artikel schreiben zu können. Wenn dann aber zur weiteren Verbesserung ein Einzelwerk benötigt wird, das schon dreistellig die Privatkasse belastet, hört der Spass auf. Dann bewilligt Wikipedia für engagierte Autoren Literaturstipendien: http://de.wikipedia.org/wiki/Wikipedia:Literaturstipendium Auch der eingestellte Mediawiki Programmierer dürfte im mehrfachen fünfstelligen Bereich jährlich zu Buche schlagen. Übrigens: Ich weiß nicht, woran es liegt. Aber wenn ich bei Deinen Postings auf Zitieren klicke, erscheinen sie - anders als bei jedem anderen Poster - ohne Zeilenumbruch. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
AssetBurned openstreet...@assetburned.de wrote: Blockwart -- http://de.wikipedia.org/wiki/Blockwart oh ein parade beispiel dafür wie blindes vertrauen in die wikipedia zum schuß nach hinten werden kann. und übrigens gerade in diesen konkreten fall schon ein sehr altes beispiel. Ich kenne das Artikel-Versionsarchiv und die Diskussionsseiten. http://de.wikipedia.org/w/index.php?title=Blockleiteraction=history allerdings sind diese personen in meinen augen... nun sie treten halt nicht ausreichend in den vordergrund. warum auch immer. und irgendwann greift leider, in solchen fällen, die sippenhaft. Ich weiß nicht. Für mich klingt Dein letzter Beitrag reichlich ideologisch und steht so vollkommen im Gegensatz zu der IMHO wohlabgewägten Analyse, mit der Frederik den Thread begonnen hat. Bist Du ernsthaft der Meinung, mit solchen Mitteln zu einem Ergebnis zu kommen? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
Ulf Lamping ulf.lamp...@googlemail.com wrote: Dafür gibt es zuviele unterschiedliche Interessen - und ich persönlich möchte keinem sagen wollen: du kommst hier nicht rein, weil deine Interessen nicht zu unserem Ziel passen. Ich meine, den bisherigen Diskussionen entnehmen zu können, dass historische und nicht mehr existente Strukturen als auch imaginäre Welten in der OSM Datenbank zumindest derzeit aus technischen Gründen mehrheitlich abgelehnt werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
AssetBurned openstreet...@assetburned.de wrote: On 28.04.2010, at 23:24, Tirkon wrote: OSM dito. Das wird sich dann verschärfen, wenn die Karte mit immer Details übersäät wird und nur der technisch Versierte zu filtern in der Lage ist. Das Gleiche gilt für die Zunahme der Komplexität z.B. der Relationen. Nur der technische Versierte wird sich zurechtfinden, wenn die Linienbündel nicht mehr mehr explizit, sondern per Relation gebildet werden. Hier kann nur eine entsprechende benutzerfreudliche Software helfen, mit der man die Spuren/Linien zusammenklicken kann. Du beginnst hier zwei punkte zu vermengen. Ich habe hier nur exemplarisch ein Beispiel herausgegriffen, wie es jemand sehen könnte, da ich hier kein umfassendes Buch schreiben möchte. Im Prinzip geht es darum, dass ein Projekt niemals wirklich frei sein kann. Und der Grund dafür ist: aber die interessen sind grundsätzlich unterschiedliche. in genau diesen fall zeigt die WP nämlich wie man es nicht machen sollte. Sowohl bei der anwendung der relevanzkriterien als auch bei der begründung jener. Einen gemeinsamen Nenner wird es wohl nicht geben. Es gibt einfach zuviele selbsternannte Richter, welche teilweise sehr rigide argumentieren. So etwas findet man aber auch im restlichen Internet und nicht nur bei Wikipedia. Und das müssen nicht unbedingt Administratoren sein. Es gibt IMHO unter den einfachen Usern auch genügend solche. Ich kann nur dazu raten, solche emotionalen Diskussionen schlichtweg zu ignorieren und den Blick auf die restlichen 99,x Prozent zu richten. Einen Großteil der heiß diskutierten Punkte in Artikeln interessiert ein Jahr später kein Schwein mehr. Das ist interessanterweise oft auch dann der Fall, wenn sich jemand ein Herz genommen hat und diese Stelle qualitativ hochwertig ausgebaut hat. Eine Community wirkt nach innen und später auch nach außen so schlecht oder so gut, wie sie sich fühlt. Wenn ich einen artikel suche wo mir nur stichworte bekannt sind, suche ich per Google in der Wikipedia... die suche ist eine wirkliche zumutung und kommt mit einer kombination aus mehreren wörtern einfach nicht zu recht. Selbst zur zeit wo die WP entwickelt wurde mit damaligen mitteln hätte man die suche schon besser machen können. man hätte zum beispiel direkt eine funktion einbinden können um Personensuchen zu ermöglichen oder die treffer auf bestimmte themen gebiete (medizin, sport...) einschränken zu können. aber das wurde nie gemacht. Es geht schlicht darum, dass man anhand des Namens einer Person diese auch findet - und zwar ohne Hintergrundinfos. Eine Angela Merkel Bundeskanzler wäre problemlos zu finden. Auch hier nur exemplarisch genannt, um deutlich zu machen, dass ich bei einer ausufernden Wikipedia immer mehr Hintergrundinformationen brauche, um die richtige Person/Artikel zu finden. Dabei sind das gerade die Hintergrundinformationen, die ich aus dem Artikel gewinnen möchte. wenn eine ordentliche suche möglich wäre, wären relevanzkritärien wie sie aktuell genutzt wären überflüssig. Um es klar zu sagen: Es müssen bessere Mittel und auch Inhalte zum Auffinden der Infos addiert werden. Blödes Beispiel: Anhand des Namens einer Anschlussstelle muss die zugehörige Autobahn identifizierbar sein. Aber das, was ich hier beschreibe, hat nichts mit einer wirksamen Suchfunktion zu tun. Warum soll der 16jährige torschützenkönig aus der kreislieger nicht auch in die WP dürfen ... Die Frage ist nicht, ob er in die Wikipedia darf. Die Frage ist, ob er !!muss!!. Unter dem Deckmantel eines Wikipedia Artikels werden hier alle Personen aufgefordert, die etwas über sein Leben aussagen können, dieses in aller Akribie und Detailliertheit an eine Weltöffentlichkeit zu zerren, während man andererseits die Staatsschnüffelei sowie Fehler und Methoden bei sozialen Netzwerken geißelt. Wenn dann Wikipedia noch ausufert, wird kein Hausmeister mehr in der Lage sein, diese Person vor Denunziation zu schützen. Und dieser Malus schlüge alles bisher Dagewesene bei Wikipedia. Manches Lokalblatt hätte bald seinen örtlichen Aufhänger. Die Person rückt also noch weiter ins öffentliche Licht ... und wird für Wikipedia noch relevanter. Man kann über Relevanz diskutieren. Aber gerade bei Personen plädiere ich daher für eine hochrestriktive Relevanz. Es darf nicht sein, dass das Kind erst in den Brunnen fällt. Hier muss der Schutz präventiv sein. Eine Wikipedia, die das nicht leistet, wäre sicher das wirkliche Ende für viele engagierte Autoren. Der freie Geist des Einen beschränkt den freien Geist des Anderen. Von Kaputttramplen mag ich daher nicht reden. Wenn jemand nicht bereit ist, seine Software benutzerfreundlich zu machen, so ist das sein freier Geist und aus seiner Sicht sein gutes Recht. Gleichzeitig verschafft er sich damit einen Machtvorsprung vor demjenigen, der technisch nicht so versiert ist. Und schon ist der Ärger da. wofür die WP ein parade beispiel ist. Aus der Sicht von technisch weniger bedarften Usern kann OSM
Re: [Talk-de] Von Wikipedia lernen
Frederik Ramm frede...@remote.org wrote: Ohne Relevanzregeln wäre der Weg zum Artikel über Begtriffsklärungen ein unendlich langer. Um zum Beispiel eine Frau Merkel zu finden, von der man nur den Namen kennt, müsste man sich im Extremfall durch ein weltweites Telefonbuch mit allen Merkels kämpfen müssen. Ein schier hoffnungsloses Unterfangen, wenn man nicht wenigstens Anfangskenntnisse zur Person hat. Die Relevanzkritereien stellen hier sicher, dass eine maximale Anzahl von Usern in einer maximalen Anzahl der Fälle dasjenige findet, was er sucht. Naja, oben schreibst Du in Bezug auf OSM, dass gute Software durchaus solche Probleme auffangen kann - kann man dann vielleicht formulieren: So etwas wie die Relevanzregeln entsteht, wenn ein eher technisches Problem (wie finde ich aus allen Merkels weltweit schnell den Eintrag, der mich interessiert) aus Mangel an technischer Kompetenz auf anderem Wege zu loesen versucht wird. Hier geht es darum, dass man zum Auffinden eines Artikels Hintergrundinformationen braucht, die man eigentlich dem Artikel entnehmen wollte. Das kann man mit keiner Suchfunktion kitten. Nun hatte ich ja gerade postuliert, dass gute Technik einen eben gerade vor willkuerlichen Regeln schuetzen kann. Gibt es zwischen mangelhafte Technik, daher ueberforderte Menschen, die diese Ueberforderung durch willkuerliche Regeln a la Relevanzkriterien zu kompensieren suchen und ueberhandnehmende Technik, die den Menschen alles vorschreibt und keine Freiheiten laesst einen guten Mittelweg? Manche Programme haben mehrere Userlevel, die man bei Interesse nach und nach erschließen kann. Bei Wikipedia ist man wenigstens so ehrlich, dass man diese Regeln für jeden sichtbar auch bekanntgibt. Bezogen auf diese Liste hier: Sie schirmt sich durch eine Mailingliste ab, in welche man nur mit Hilfe eines Clients schreiben kann, der nur mit eingehendem technischen Verständnis konfigurierbar ist. Ich frage mich manchmal, ob man vielleicht auch einen ganz anderen Weg der Ehrlichkeit gehen kann: Indem man naemlich ehrlich sagt fuer 99% der Weltbevoelkerung ist OSM nichts. Dass man also gar nicht erst den Anschein erweckt, hier koennte einfach so jeder ohne technischen Sachverstand mitmachen (nur um dann, bewusst oder unbewusst, eben doch wieder Huerden aufzubauen wie eine Mailingliste). Da ich hier kein Buch schreiben möchte, war das nur exemplarisch gedacht. schliesslich bezahltes Personal beschaeftigen muessen, weil wir unseren eigenen Freiwilligen nicht mehr ueber den Weg trauen koennen Das ist zumindest bei Wikimedia Deutschland nicht so. Das eingestellte Personal soll ausdrücklich nur unterstützen, aber nicht in die Enzyklopädie an sich eingreifen. Da waere meine Haltung halt: Entweder, das Projekt hat genug Power, dass diese Arbeit von Freiwilligen gemacht wird, oder man laesst es. Irgendwann habe ich gesehen, dass der Wikimedia e.V. eine Zeitung herausgibt, da dachte ich mir, Junge Junge, die haben wohl zu viele Germanisten eingestellt und wissen jetzt nicht wohin mit der Arbeitskraft. So ähnlich stellt sich das Vielen dar. Ich vermag das nicht zu beurteilen. Auf jeden Fall dürften in der nächsten Zeit Uservorschläge auflaufen. Mein Vorschlag wäre es in diesem Zusammenhang, den Usern professionelle Rechtshilfeartikel an die Hand zu geben. Bei OSM könnten wir so etwas auch gut gebrauchen. Denn denn die Rechtsfragen bleiben hier recht ungeklärt. Der freie Geist des Einen beschränkt den freien Geist des Anderen. Von Kaputttramplen mag ich daher nicht reden. Wenn jemand nicht bereit ist, seine Software benutzerfreundlich zu machen, so ist das sein freier Geist und aus seiner Sicht sein gutes Recht. Gleichzeitig verschafft er sich damit einen Machtvorsprung vor demjenigen, der technisch nicht so versiert ist. Und schon ist der Ärger da. Da waere zu ueberlegen, ob man daran arbeiten muss, diese Zustaende abzuschaffen, oder ob man sie stattdessen zum Prinzip erheben, dann aber auch ehrlich dokumentieren sollte, indem man etwa ganz klar sagt, dass Programmierer in OSM mehr Macht haben als Nichtprogrammierer und dass das auch so gewuenscht ist. Das wäre zum Beispiel ein erheblicher Unterschied zu Wikipedia. Die Bots dürfen da nur recht wenig. Eine Rücksprache mit der Community ist sehr erwünscht. Ein Bot muss langsam und von jedem zu stoppen sein. Das ist aber alles ein so vager und spekulativer Bereich, dass ich mir nie anmassen wuerde, irgendein rosiges Ziel zu proklamieren, wenn ich nicht solide Informationen haette - und da hoffe ich halt ein bisschen darauf, dass man durch Analyse der sozialen Prozesse bei der Wikipedia solche Informationen gewinnen koennte. Wir brauchen jetzt Philosophen. ;-) Du sprachst vom Beispiel Wikipedias und was OSM daraus lernen könne. Ich bin dort schon einige Jahre unterwegs. Nach meinem Empfinden sollte ein Wikipedia Autor der Vermittler zwischen Quellen und Leser sein. Das ist ein Journalist aber auch.
Re: [Talk-de] Von Wikipedia lernen
AssetBurned openstreet...@assetburned.de wrote: Ich lasse jetzt mal die Grundsatz-Wikipedia Debatte raus. Das hat schon an anderen Orten zu keinen Ergebnissen geführt. das arschl* von admin mag mich ja eh nicht ... Mein Tipp: Als IP schreiben. ok also diskussionen aller der ars* von admin ist ja eh immer gegen artikel zu diesen thema! ;-) Um nicht missverstanden zu werden. Man soll nicht als IP schreiben, um das arschl* von admin sagen zu konnen. Vielmehr sollte man seine Artikel als IP schreiben, um zu vermeiden, dass der Admin (oder wer auch immer) meine Beiträge nur deswegen löscht oder ändert, weil er mich nicht mag. was bitte ist dadran so falsch die kategorien als weitere suchkriterien herran zu ziehen? wenn ich eine Angla Merkel suche, weiß ich zunächst nicht ob ich eine politikerin suche oder gar eine sportlerin. richtig, aber dann möchte ich bitte auch alle aufgelistet bekommen. wenn ich hingegen weiß das es eine Bundeskanzlerin ist die ich da suche, dann dürfte es doch nicht so schwierig sein ein kleines kreuzchen bei politik zu setzen. gerne auch mit multi auswahl wenn ich nicht weiß ob es eine politikerin oder eine sportlerin ist die ich suche. wenn ich nach dem begriff MAD suche suche ich ihn im kontext zu etwas (nachichtendienst, zeitschrift, militär, politik) oder ich weiß es nicht und will nur wissen was die abkürzung bedeutet, dann will ich ne liste haben. all das GIBT ES SCHON in der wikipedia. artikel sind in kategorien, warum werden diese nicht zur suche benutzt? darauf will ich raus. Dem widerspreche ich nicht, sondern befürworte es. Ich widerspreche nur einer Artikelfülle, die vor lauter ähnlichen Lemmas die relevanten nur mit Hilfe der Hinmtergrundinformationen (Kontext, Suchwörter) finden lassen, die ich eigentlich im Artikel erfahren wollte. wenn ich das so in Google angebe bekomme ich ja auch einen sinvollen hit. http://tinyurl.com/376eufl (google suche nach MAD militär und wikipedia) also wo bitte ist das erschlagende menge an informationen? da beisst sich die katze in den schwanz. auf der einen seite wird argumentiert wir brauchen bessere such machanissmen um mehr informationen verwalten zu können und auf der anderen seite wird gesagt och die suche geht doch wie sie ist, wir ham ja alles (durch löschen unwichtiger sachen) unter kontrolle. zurück zu OSM geht das leider nicht so einfach, da das rendern der kacheln nicht über solch halbwegs einfach zu bedienenden oberflächen möglich wäre. Das wäre eine Richtung, in welche man die Idee von der Kundenorientiertheit weiterspinnen könnte. ... na da komm wir doch auf einen nenner :-) ... +1 genau so wie zum rest :-) Schön :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
M?rtin Koppenhoefer dieterdre...@gmail.com wrote: Um nicht missverstanden zu werden. Man soll nicht als IP schreiben, um das arschl* von admin sagen zu konnen. Vielmehr sollte man seine Artikel als IP schreiben, um zu vermeiden, dass der Admin (oder wer auch immer) meine Beiträge nur deswegen löscht oder ändert, weil er mich nicht mag. und so einen Laden willst Du als Vorbild hinstellen?? Ich denke mal, aus dem Rest meines Postings geht hervor, dass ich so etwas nicht gutheiße, was aber nichts zu meiner Meinung zum Gesamtergebnis der Wikipedia aussagt. Man wird bei einem Projekt, das den unbeschränkten Zugang benötigt und so prominent ist, negative Elemente nicht ausschließen können und damit leben müssen. Zudem steht es jedem zu, in einem Fork zu zeigen, dass es besser geht oder Wikipedia selbst zu einem Besseren zu verändern. Einen existierenden Ableger von enttäuschten Wikipedianern kann man - zumindest bisher - als gescheitert ansehen: http://www.wikiweise.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
Tobias Knerr o...@tobias-knerr.de wrote: Abstraktes Beispiel: WP sortiert weiter in relevant und irrelevant, löscht aber nicht. Bei einer Volltextsuche werden erst alle relevanten Ergebnisse genannt, danach die irrelevanten. Das funktioniert deswegen nicht, weil Wikipedia ein Wiki ist. Dann geht nämlich der Streit darum los, ob irrelevante Artikel in relevanten verlinkt werden dürfen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
Frederik Ramm frede...@remote.org wrote: schliesslich bezahltes Personal beschaeftigen muessen, weil wir unseren eigenen Freiwilligen nicht mehr ueber den Weg trauen koennen, und und und. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Von Wikipedia lernen
Frederik Ramm frede...@remote.org wrote: ich mache mir Sorgen, wenn ich die Wikipedia betrachte. Sich sorgen, ist in vielen Fällen der Anfang allen Übels, auch in der Wikipedia. Es wird nach meinem Dafürhalten zu wenig betont, was letzendlich bisher herausgekommen ist. Ich denke, es ist besser, es nicht als Sorge zu empfinden und einen möglichst kühlen Kopf zu bewahren, was natürlich - auch mir - nicht immer leichtfällt. ;-) Trotz allem, was die Wikipedia erreicht hat, ist das kein Projekt mehr, dass ich irgendwie sympathisch finde. Das Projekt macht auf mich den Eindruck, als ob es langsam an Buerokratie zu Grunde geht. Die Dynamik und der freie Geist, den das Projekt frueher hatte, werden erstickt in Regeln, Rechten, Hierarchien. Etwas Analoges ist bei OSM schon fleissig im Gange. Aber anders als Du denkst, wie ich unten im Detail ausführen werde. Zunächst aber in Richtung Makrokosmos: Das Problem ist weder ein Wikipedia- noch OSM-Spezifisches und spiegelt das Übliche wider: Eine Welt beginnt mit Anarchie, in der sich Regeln herausbilden, bei denen manche besser und manche schlechter wegkommen. Manche nutzen die Regeln im Sinne des Erfinders. Andere machen sie zur Institution, ohne die Intention der Väter zu kennen oder kennen zu wollen. Gerichtsurteile, über welche die Welt den Kopf schüttelt, sind das Ergebnis. Diejenigen, die schlechter dabei wegkommen, beschweren sich, sofern sie es realisieren. Das passiert insbesondere dann, wenn die Ressourcen knapp werden. Bezogen auf Wikipedia wären das die Beiträge, die man selbst zu leisten in der Lage ist, aber schon von Anderen besetzt sind und bei OSM analog. Auch bei OSM gibt es im Gegensatz zu Wikipedia ein Machtinstrument, mit dem Regeln durchgesetzt werden können, nämlich die Software. Zumindest zur Zeit ist die Macht, damit eine Regel durchzusetzen, größer als man sie mit einer lediglich geschriebenen Regel bei Wikipedia durchsetzen könnte. Hier wäre auch noch die englische/deutsche Homepage von OSM zu nennen, auf welche die OSM-Community im Gegensatz zur en/de Wikipedia Hauptseite keinen Zugriff hat. Alle Machtinstrumente lassen sich sowohl zum Positiven als auch zum Negativen nutzen. So kann beispielsweise ein angebotener proprietärer OSM-Editor dazu genutzt werden, dessen User auszuspähen, obwohl das Projekt an sich ein freies ist - insbesondere dann, wenn dieser eine Anmeldung erfordert. Um aber störende Fehler der OSM Datenbank nachzuvollziehen und deren Entstehung im Editor zu überprüfen, kann man nicht umhin, sich dort anzumelden. (Zur Erinnerung hier noch drei Regelwerke, die sich aus der Anarchie entwickelten: Bei den Regeln der großen Welt - sprich der Erde - kommen die Menschen offensichtlich ganz gut weg, denn letztendlich wird nahezu keiner von Tieren beherrscht oder gefressen, während man sich umgekehrt von Kindesbeinen an ihrer ohne jeden Skrupel und wie selbstverständlich nach Belieben bedient. So konnte sich der Mensch dem Regelwerk in der Tierwelt, nämlich dem dort existierenden Kannibalismus entziehen.) Mich erinnert das manchmal an die Kritik, die gern an Hilfsorganisationen geuebt wird: Von einem Euro, die man an die Organisation X spendet, kommen nur 10 Cent bei den Beduerftigen an! - bei der Wikipedia scheint mir inzwischen, dass von der insgesamt geleisteten Arbeit 10% in die Verbesserung der Inhalte fliessen, waehrend der ganze Rest irgendeinem Buerokratie-Eiertanz zum Opfer faellt. Altgediente Wikipedia-Mitarbeiter wenden sich ab; Leute, die Jahre ihres Lebens wirklich mit dem Herzen am Projekt hingen, sind verbittert und enttaeuscht. Es bildet sich eine Clique, ein innerer Kreis. Dito bei OSM, zum Beispiel in dieser Liste und bei den Konferenzen. Die Presse greift das dann natuerlich gerne auf - zum Beispiel hier ein Zitat aus dem Spiegel vom Januar (http://www.spiegel.de/spiegel/0,1518,689588,00.html): In diesem Fall ist die Presse im wahrsten Sinne des Wortes nur ein vorgehaltener Spiegel, allerdings nur für den inneren Kreis. Die schweigende Mehrhet der Autoren juckt das wenig. Sie produziert weiter 500 Artikel pro Tag und baut existierende weiter aus, so dass 3100 lesenswerte und unermesslichen Content. Die . Die Wikipedia ist kein Projekt vieler, sondern ein Projekt weniger. Es ist ein verbreiteter Irrtum, dass alle Nutzer gemeinsam und demokratisch zu ihr beitragen, dass sie ein Produkt von Schwarm-Intelligenz sei. Die deutsche Wikipedia hat mehrere hunderttausend angemeldete Nutzer. Aber [...] Ein halbes Prozent aller aktiv gewordenen Nutzer ist für fast zwei Drittel der Editierungen verantwortlich - ein Kreis von nicht einmal 2000 Personen. OSM dito. Das wird sich dann verschärfen, wenn die Karte mit immer Details übersäät wird und nur der technisch Versierte zu filtern in der Lage ist. Das Gleiche gilt für die Zunahme der Komplexität z.B. der Relationen. Nur der technische Versierte wird sich zurechtfinden, wenn die Linienbündel nicht mehr mehr explizit, sondern per
Re: [Talk-de] Frage: Bebauungsplan == frei von copyright, weil amtliches Dokument?
Toni Erdmann toni.erdm...@web.de wrote: ich stoße in letzter Zeit immer wieder auf Bebaungspläne im PDF Format und frage mich, ob ich die verwenden kann. Hier werden Bundesgesetze veröffentlicht: http://www2.bgbl.de/Xaver/start.xav?startbk=Bundesanzeiger_BGBl Dort ist oben auf der Seite zu lesen: Mit der weiteren Nutzung des Bundesgesetzblatt online erkennt der Nutzer an, dass er von diesen Nutzungsbedingungen Kenntnis genommen hat. Die elektronische Version des Bundesgesetzblattes genießt generell Datenbankschutz nach§§ 87a ff UrhG. Dies bezieht sich auch auf die einzelne Ausgabe des Bundesgesetzblattes, die deshalb nicht ohne Zustimmung des Verlages außerhalb der gesetzlichen Vorschriften genutzt werden darf. Eine unveränderte Weiterverwendung entnommener pdf-Dateien im Original, die über den privaten Gebrauch hinausgeht, ist daher nicht statthaft. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki Qualitätsoffensive
M?rtin Koppenhoefer dieterdre...@gmail.com wrote: ja, das ist ja sowieso so: jeder schreibt das ins WIki auf die Art, wie er will. Ja, hatte ich auch so bekundet: Ich würde daher sagen, ein jeder mache es so, wie er kann und möchte. Hier ging es wohl mehr darum, dass im Wiki gefordert wurde, Texte bevorzugt auf deutsch zu schreiben. So eine allgemeine Empfehlung (die im Wiki formuliert auch den Anschein erzeugt, Gruppenkonsens zu sein) ist was anderes als eine persönliche Entscheidung zu treffen und dem kann man ruhig widersprechen. Ja, und zwar für jegliche Sprachversion. Eines ist mir aus Deinem Plädoyer noch nicht ganz klar geworden: Ich habe zunächst einmal weitere zu den bisher im Thread beschriebenen Vor- und Nachteilen der einen oder anderen Wiki Sprachversion beschrieben. befürwortest Du dann auch deutschsprachige tags? Das wäre doch die logische Konsequenz, oder? Es ging um das Wiki und schwierig zu beschreibende Zusammenhänge. Das Wiki beeinflusst nicht die Funktionalität der OSM Programme, Tags hingegen schon. Letztere sind aber wesentlich einfacher auch auf Englisch zu verstehen, als komplizierte Sachverhalte im Wiki. Im Moment ist die Welt der Tags noch reichlich in Bewegung. Übersetzungen könnten da mehr Probleme als Nutzen stiften. In JOSM werden die Tags auf Deutsch übersetzt. Ich persönlich empfinde das als unpraktisch, wenn aus dem deutschen Ausdruck nicht immer sofort klar ist, welche der in Englisch möglichen Übersetzungen zutrifft. Hier geht es ja eher darum, für ein Objekt mit gewissen Eigenschaften, einen bestimmten Begriff von mehreren möglichen festzulegen. So wurde highway für etwas genommen, das man genauso auch road hätte nennen können. Inzwischen ist road aber mit einer anderen Bedeutung belegt. Und das wäre dann auch in Deutsch ein Problem. Schreibe ich nun Telefonzelle oder Telefonhäuschen? Insgesamt würde ich daher bei den Tags eher zu einheitlich englischsprachigen tendieren. Anders könnten das diejenigen sehen, die muttersprachlich nicht in lateinischer Schrift schreiben. Es hat sich außerhalb von OSM etabliert, die wichtigsten Schriften der Welt zu unterstützen. Da müsste die Frage nach dem Aufwand an diejenigen weitergegeben werden, welche die Programmierarbeit machen. Spätestens dann stellt sich auch die Frage, ob es zu diesem Zwecke notwendig wird, zumindest die etablierten Bezeichnungen (wie beispielsweise highway und road) festschreiben, um eineindeutige (bijektive) Sprachbeziehungen herstellen zu können. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Raststättenstraßen an Autobahnen zu niedrig eingestuft
Gerry Light gerrylight...@googlemail.com wrote: Das führt dazu, dass die Raststättensstraßen erst ab einer hohen Zoomstufe überhaupt sichtbar werden. Nach meinem Gefühl geschieht das - gemessen an deren Bedeutung - beim Taggen mit service erst viel zu spät. Raststättenstraßen sind sogar eine eigene Gattung: services http://wiki.openstreetmap.org/wiki/Tag:highway%3Dservices. Vielleicht erschlägt das schon einige Deiner Kritikpunkte. Gemäß der Beschreibung gilt das Tag für nodes aber nicht für Straßen. Ich kann Dein Anliegen in gewissem Maße nachvollziehen (auch wenns mich selbst überhaupt nicht stört), aber bitte keine etablierten Strukturen mißbrauchen. Wegen Deines letzen Argumentes habe ich es thematisiert und nicht einfach durchgezogen. primary, secondary etc. sollte also nur die _Verkehrs_bedeutung im Sinne von Verbindungsqualität und nicht nur die reine Nutzungsfrequenz addressieren. Was fehlt, ist ein Tag, das solche Straßen signalisiert, die ausschließlich dem Zweck der Fahrtunterbrechung auf einer Autobahn dienen, und dem Renderer so die Möglichkeit gibt, entsprechend zu reagieren und z.B. die Straßen schon ab einer höheren Zoomstufe anzuzeigen und möglicherweise einzufärben. Das von Dir erwähnte highway=services gilt laut Beschreibung aber nicht für Straßen. Ist insofern dss highway nicht etwas unglücklich gewählt? Man könnte überlegen, es auch auch für Straßen zu benutzen. Dann ist aber wegen der Ähnlichkeit zu highway=service die Verwechslung vorprogrammiert. Wie wäre es in Anlehnung an motorway_link und motorway_junction mit highway=motorway_service. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki Qualitätsoffensive
Sven Geggus li...@fuchsschwanzdomain.de wrote: Es ist nunmal Fakt, dass es doppelte Arbeit macht Artikel in zwei Sprachen zu erstellen und daher reicht IMO wie gesagt eine englische Doku fürs erste zunächst mal aus. Und worauf willst Du letztlich raus? Wenn überhaupt dazu imstande, dürften die meisten für einen englischen Wiki-Artikel ein mehrfaches an Zeit und Mühen benötigen, als für einen englischen. Daher darf er gern auch auf Deutsch sein, und zwar auch dann, wenn es keinen englischsprachigen Text gibt. Es ist nunmal Fakt, dass es doppelte Arbeit macht Artikel in zwei Sprachen zu erstellen und daher reicht IMO wie gesagt eine englische Doku fürs erste zunächst mal aus. Man kann nicht die Englischkenntnisse der häufig im Forum als Elite bezeichneten Userschaft der Mailingliste als Maßstab nehmen. Ich könnte mir gut vorstellen, dass die schweigende deutschsprachige Mehrheit der OSM-User da anderer Ansicht ist. Mit schlechtem Englisch kannst Du ein Verhungern vermeiden und vermutlich auch die wichtigsten OSM Tags übersetzen. Wenn man aber im täglichen Leben nicht regelmässig mit Englisch in Berührung kommst, wird man Feinheiten, wie sie für die Beschreibung von OSM notwendig sind, in einer Vielzahl der Fälle nicht verstehen und erst recht nicht formulieren können. Daraus ergibt sich, dass aus der Sicht einer deutschsprachigen Community heraus, die Nutzungsintensität eines englischsprachigen Kanals (englischsprachige Texte von Deutachsprachigen für eben diese) trotz besten Willens um Dimensionen dünner seim wird, als die eines deutschsprachigen. Aus Sicht des internationalen Abgleiches von OSM ist der deutsprachige Text natürlich weniger geeignet. Die Empfehlung, aus Gründen der Internationalität die englische Sprache zu benutzen, wovon insbesondere im Akademikerbereich reichlich Gebrauch gemacht wird, bevorteilt natürlich englische Muttersprachler, da diese nun ohne jegliche Fremdsprachenkenntnisse die Texte optimal verstehen können, während das für das Gros der Nicht-Muttersprachler und selbst für die Landsleute des Verfassers nicht gegeben ist. Denn nur wenige haben muttersprachgleiche Englischkenntnisse. Somit haben sie mehr muttersprachliche Quellen, als jeder anderssprachige. Und das nenne ich mal die Gnade der ortsrichtigen Geburt. Jede Version hat Vor- und Nachteile. Daher kann ich nicht guten Gewissens die eine oder andere empfehlen. Auch wenn mancher deutsche Politiker da einfordert, was er selbst nicht zu leisten imstande ist: Ich würde daher sagen, ein jeder mache es so, wie er kann und möchte. Die Beschreibung kann also gern auch auf Deutsch sein, und zwar auch dann, wenn es keinen englischsprachigen Text gibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Raststättenstraßen an Autobahnen zu niedrig eingestuft
Gerry Light gerrylight...@googlemail.com wrote: Entweder Du machst es wegen der Abwärtskompatibilitat als subtyp(en) von service (was meinem Gefühl nach auch gar nicht so verkehrt wäre) Du meinst also: highway=service + service=motorway_service ? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Raststättenstraßen an Autobahnen zu niedrig eingestuft
Die Straßen an Raststätten und Parkplätzen an Autobahnen werden nach meinem Eindruck mit zumeist highway=service vollkommen unterbewertet getaggt. Schließlich wird eine primary Straße nicht deshalb zur residential abgestuft, weil sie von Wohnhäusern gesäumt ist. Das führt dazu, dass die Raststättensstraßen erst ab einer hohen Zoomstufe überhaupt sichtbar werden. Nach meinem Gefühl geschieht das - gemessen an deren Bedeutung - beim Taggen mit service erst viel zu spät. Ähnlich wie die primary Wohnstraßen, sollten auch Straßen an Raststätten und Parkplätzen nach ihrer Bedeutung und nicht nach ihrer Funktion getaggt werden. So können die Stra0en an vielen Raststätten locker mit der Verkehrsbelastung einer primary (Größenordnung) konkurrieren, Toiletten mit secondary und reine Parkplätze mit tertiary. Das wäre dann auch der zu gebende Anhaltspunkt, den man im Wiki für solche Straeßen angeben könnte, der natürlich abweichend angepasst werden kann. Zum Beispiel kann ein großer und bevorzugter Truckerparkplatz auch höher eingestuft werden. Die kleineren Neben- und Erschließungsspuren eines Raststättengeländes könnten nach wie vor mit service getaggt werden. Ferner könnte man dann im Ausfahrt- und Einfahrtbereich die Raststätten- und Parkplatzstraßen mit einem motorway link an die Autobahn anbinden. Im Ganzen sähe das beispielsweise so aus: ---motorway \-motorway link--primarymotorway link-/ \ / \--service--/ \ Tankstelle Raststätte / \ / \---service---/ Parkplatz Was meint ihr? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wiki Qualitätsoffensive
Sven Geggus li...@fuchsschwanzdomain.de wrote: Und die Weltspreche ist nun mal _schlechtes_ englisch Und das eignet sich zwar zum Überleben, aber nicht, um die diffizilen Zusammenhänge im OSM Umfeld zu verstehen oder gar selbst zu formulieren. Regelmäßigen Umgang im täglichen Leben mit dem Englischen, der für Letzteres Voraussetzung wäre, haben wohl nur die Wenigsten. Folglich wird eine erdrückende Mehrheit für OSM nur in Deutsch und nicht in Englisch formulieren können. Bei allem Respekt für Anderssprachige bleibt es in der Praxis eine Tatsache, dass ein englischsprachiger Text von Deutschsprachigen für Deutschsprachige einen um Dimensionen geringeren Nutzwert und Nutzungsintensität hat. Ebenso bleibt es eine Tatsache, dass sich in gewissen Lebensbereichen englische Muttersprachler der Gnade der ortsrichtigen Geburt erfreuen dürfen, weil ihnen deutlich mehr und bessere Quellen zur Verfügung stehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS-Konferenz sucht Veranstaltungsor t für 2011
Marco Lechner - FOSSGIS e.V. marco.lech...@fossgis.de wrote: http://www.fossgis.de/konferenz/w/images/f/f5/FOSSGIS-2011_CfL.pdf In dem Dokument ist zu lesen: Seit 2010 ist sie auch die Konferenz der deutschsprachigen OpenStreetMap-Community. Als Termin ist diesmal nur Dienstag bis Donnerstag angegeben. Heißt das, dass obiger Satz schon wieder Geschichte ist und OSM diesmal nicht mit einem eigenen Teil an der Konferenz partizipiert? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Anfrage Datenimport
Fabian sh...@nurfuerspam.de wrote: benötigen wir Ihre vollständige Anschrift sowie die des Portalbetreibers. Wie wäre es mit dem Betreiber der Website?: http://www.whois2.org/?domain=openstreetmaptld=orgid=20361968 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Karten in Wikipedia
Markus liste12a4...@gmx.de wrote: Da war doch vor geraumer Zeit mal geplant, OSM-Karten in Wikipedia zu verwenden. Dazu sollte von WP die DB gespiegelt und zusätzliche HW angeschafft werden. Die Server wurden schon vor Ewigkeiten von Wikimedia Deutschland angeschafft und laufen offensichtlich schon. Denn angemeldete Wikipedia User können auf die neue Betaversion umschalten. Dann findet sich hinter jeder Koordinate im Wikipedia Artikel ein OSM Link, der bei Klick die OSM-Karte unmittelbar in den Artikel einblendet. Von Seiten der OSM-Wikipedia Zusammenarbeit scheint die Arbeit demnach zunächst getan. Mal sehen, ob der Wikipedia Kartenserver hält, wenn die Beta standardmässig online geht. Als wünschenswert empfände ich es noch, wenn die Karte - ähnlich wie bei den Fotos - im Wikipedia Artikel frei positionierbar und in frei bestimmbarer Größe eingeblendet werden könnte. Aber mit dem Wunsch warte ich, bis die Beta Standard ist. Denn damit haben die Programmierer im Moment mehr als genug zu tun. Und das, obwohl inzwischen zumindest einer dafür fest angestellt wurde. Ein weiterer Wunsch wäre es, auf dieser Karte einen Link zur OSM-Vollversion zu haben. Da würde mich interessieren, ob unser Server überhaupt solch einem immensen Wikipedia Ansturm standhalten könnte? Ebenso war geplant, georeferenzierte WP-Artikel auf OSM zu verlinken. Auch das geht schon lange für OSM und Google gleichermaßen: http://toolserver.org/~kolossos/osm/wp-on-osm.php?lat=53.550556lon=9.99zoom=15lang=de Die Umkehrung, nämlich die Darstellung der in OSM händisch eingetragenen Wikipedialinks hat Norbert oben schon angegeben. Import der URL zu den georeferenzierten Artikeln Du meinst, aus allen Wikipedia Artikel diejenigen mit Koordinatenangabe aussieben, diese Koordinate in OSM als Point of Interest markieren und mit der URL des Wikipedia Artikels versehen? Wenn ja: Dazu habe ich irgendwo - vermutlich in dieser Liste - gelesen, dass man dies von Seiten OSM nicht tun möchte. Denn die Wikipedia Koordinaten stammen nicht aus freien Quellen, sondern in der gewaltigen Mehrzahl von proprietären Karten im Internet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM folgt niederländischer Grenzauffas sung
Lennard l...@xs4all.nl wrote: I thought you already had official German boundaries? At present there is no way to get the official german boundaries by an open license. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Straßenliste aus Pulldown Menü ausle sen
Florian Lohoff f...@zz.de wrote: So habe ich die mal extrahiert. http://silicon-verl.de/home/flo/tmp/listen-landkreis-aurich.zip Vielen Dank! :-) Die muessen noch nachbearbeitet werden ... Wird gemacht ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM folgt niederländischer Grenzauffas sung
AssetBurned openstreet...@assetburned.de wrote: na wenn ich mir das so genauer anschaue dann follgt OSM da weder der DE noch der NL meinung sondern vertritt ne eigene. Ich denke mal, dass allgemein die meisten Karteh auf Wikipedia keinen Anspruch auf exakte Georeferenzierung erheben, sondern lediglich illustrierenden Charakter haben. Viele wurden von den Autoren der Gebietsartikel (z.B. Regionen, Städte, Ortsteile) initiiert, die ihre Artikel zu bebildern haben. Insbesondere sind diese froh, überhaupt eine zumindest illustrierende Grenzdarstellung ohne Georeferenzierung ergattern zu können. (Hier könnte OSM wirklich hilfreich sein). Insofern kommt die OSM Grenzdarstellung der holländischen Auffassung zumindest qualitativ doch schon recht nahe. Aber egal, wie man sich entscheidet - wobei ich allerdings dazu neigen würde, beide Auffassungen darzustellen: Es wird daran scheitern, dass wir weder der einen noch der anderen amtlich festgestellten Linie unter einer freien Lizenz habhaft werden können - das übliche Dilemma bei Grenzen eben. Wahrscheinlich wird sich das erst ändern, wenn sich OSM in den Amtsstuben eine ähnliche Reputation wie Wikipedia erworben hat, wo langsam aber sicher die Dämme zu brechen beginnen und sich eine Kommunikation auch mit lokalen Projekten anbahnt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] SOTM vs FOSSGIS 2010 Konferenz
Die Early Bird Registrierung für die SOTM ist eröffnet. Hier kann man die Teilnahmegebühren einsehen: http://stateofthemap.org/register-now/ Wenn man berücksichtigt, dass diese noch reduziert sind, wird erst so richtig klar, auf was für einem Silbertablett uns die FOSSGIS 2010 eigentlich serviert wurde. Denn dort war die Teilnahme vollkommen kostenfrei. Obendrein wurden wir den ganzen Tag bestens beköstigt. Zumindest aus meiner Sicht hätte ich ein ständig gepflegtes Dauerbuffet und dann in dieser Qualität sowie Kaltgetränken im Umfeld einer solchen Community-Veranstaltung niemals erwartet. Ich denke, spätestens bei diesem Vergleich wird deutlich, dass die Initiatoren und Organisatoren der Veranstaltung wirklich bis auf das i-Tüpfelchen alles richtig gemacht haben. Dafür an dieser Stelle ein herzliches Dankeschön, das auch dem FOSSGIS Verein gilt. Ich hoffe, das es uns allen gelingt, im nächsten Jahr bei uns vor Ort für diese Veranstaltung zu werben, damit sie auch von der Teilnehmerzahl ein noch größerer Erfolg wird. Ist eigentlich inzwischen bekannt, wieviel OSMler zugegen waren? Nach den Schätzungen einiger Befragten waren es ungefähr 150 Teilnehmer. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Straßenliste aus Pulldown Menü ausle sen
Moin, auf der Webseite des Landkreises Aurich (Ostfriesland) befindet sich ein Müllabfuhrkalender mit Straßenlisten für die Orte des Kreises. Da nach Feststellung an anderer Stelle diese amtlich bekanntzumachen und somit frei sind, möchte ich sie für OSM nutzen. Das Problem ist allerdings, dass die Listen in einem Pulldown Menü verborgen sind. Um diese Pulldown Menüs zu erreichen, führe man auf dieser Seite http://www.landkreis-aurich.de/abfuhrplan2010.html Folgendes durch: # wähle Ort im Pulldown Menü # klicke Straßen anzeigen # Klicke A-Z Nun sind sämtliche Straßen des Ortes in dem erscheinenden Pulldown Menü enthalten. Weder Markieren mit Tastatur und Maus (unter Windows XP) noch Alles Markieren aus dem Firefox-Menü funktioniert innerhalb der ausgeklappten Straßenliste. Auch Strg-c und anschließendes Einfügen in Word bringt nur das auf Webseite Sichtbare, nicht jedoch die Straßenliste zum Vorschein. Ebenfalls bei Rechtklick auf die ausgeklappte Straßenliste erscheint kein Menü. Es ergeht daher die Frage an die Webexperten, ob und wie ich diese Straßenliste aus dem Menü auslesen kann. Da ich selbst Webseiten nur mit DragnDrop-Baukästen erstellen kann, würde ich anfragen, ob bei notwendigen Fachkenntnissen jemand das Auslesen der Straßenliste für die vorhandenen Orte übernehmen könnte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] User macht Werbung -Link korrigiert
Johann H. Addicks addi...@gmx.net wrote: Haben wir denn eine Policy, welche Inhalte ein Benutzer auf seine Nutzerseite stellen darf und was nicht? In anderen Wikis, z.B. in der Wikipedia hat man nach Überhandnehmen der Spamer-Accounts die Regelung eingeführt, dass Userpages im Sinne des Projektes zu verwenden seien. Ein Homepageersatz ist jetzt nicht mehr statthaft. Das wird aber moderat gehandhabt. Zumindest mir ist kein Fall bekannt, wo ein Link zur eigenen Homepage oder die Nennung von Hobbys gelöscht worden wären. Wobei Letzteres im Sinne von Wikipedia zu interpretieren wäre, da sich die Sachgebietskompetenzen widerspiegeln. Im Zuge der Vermeidung von Sockenpuppen bezüglich Abstimmungen dürften aber Firmen-Accounts ebenfalls nicht statthaft sein. Es sollen eben nur natürliche Personen genau eine Stimme haben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] strassen - 2
Hallo Walter, vielen Dank für Deine Antwort. Es funktioniert. :-) Aber mir ist nicht ganz klar, 1) wie ich Deinen Post löschen sollte? 2) wieso ich Deinen Post löschen sollte? 3) warum Deinen Post niemand sehen sollte? Gruß Tirkon -Ursprüngliche Nachricht- Von: talk-de-boun...@openstreetmap.org [mailto:talk-de-boun...@openstreetmap.org] Im Auftrag von walter.nordm...@web.de Gesendet: Montag, 29. März 2010 03:27 An: Talk-de@openstreetmap.org Betreff: [Talk-de] strassen - 2 hi, seite aufrufen, gemeinde auswählen dann rechte maustaste und webseite abspeichern als file (z.b. seite speichern unter) im editor deiner wahl öffnen die strassen stehen in einer einzigen sehr langen zeile. musst etwas suchen der reste ist frimelei gruß walter p.s. wenns klapt, loesche bitte den post. muss ja nicht jeder sehen ;-) gruss walter bei fragen: walter.nordm...@web.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM folgt niederländischer Grenzauffas sung
Moin, bezüglich der derzeitigen Grenzerfassungsbemühungen mit zugehöriger Diskussion bei OSM hat mich ein ostfriesischer Wikipedia Kollege auf ein neues Kapitel aufmerksam gemacht: OSM folgt der niederländischen Grenzauffassung: http://de.wikipedia.org/wiki/Deutsch-Niederl%C3%A4ndische_Grenzfrage OSM: http://www.openstreetmap.org/?way=50680691 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM ist grenzenlos (was: OSM folgt n iederländischer Grenzauffassung)
Sven Geggus li...@fuchsschwanzdomain.de wrote: Au Mann, ihr immer mit eurem Grenzenquatsch ich finde OSM ist ein grenzenloses Projekt und wir sollten uns besser um die Erfassung real existierender Objekte kümmern. Offenbar sind da die Begehrlichkeiten je nach Anwendung unterschiedlich. Gerade diejenigen Autoren des ebenfalls internationalen Projektes Wikipedia, die sich durch ausgewogene, umfassend informierende und immerhin prämierte Regionsartikeln auszeichnen, freuen sich im Rahmen des Standardkapitels Gebiet über passende grenzillustrierende Karten zum Artikel, die man sinnigerweise am liebsten von seelenverwandten sprich freien Projekten bekäme. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Editor without relation-support makes sense?
I found some discussions within OSM, that it would make sense to offer an OSM editor especially for beginners. To make it easy enough, they should not confuse the beginner with complicated stuff like relations and thus not show and support them. But does that make sense? The user, who does not know about relations, will not have the chance to see, that some nodes of the street have got an important function. Such a node could be a member of a straight way i.e. a street: o.o..o From the view of the user of an editor without relation-support the node in the middle has no function. So he can move or delete it without problem. But this point could be the a beginning point of a route relation or member of a relation. As far as I can see at the moment, an editor, that does not show relations, is dangerous for OSM-data. Ich want to state reasons below: It is really hard, to setup in particular a long route relation. You need excellent knowledges of all places in detail. Because this is not possible i.e for an e-road with about 5000 km length, people set up projects in the wiki in order to establish this relation within month' and years as teamwork. The same applies i.e. to the public transport net, which is collected in many towns nearly complete, the relations of motorways, national- and other referenced roads, the boundaries (of towns and suburbs) or by relation splitted lanes of multilane roads with left-turn, right-turn-function etc etc. One of the most important advantages of the cycle- and hiking-map are the routes, which are long in many cases as well. With destroyed routes these maps lose much of their sense of exist. And all these routes can be destroyed within seconds by harmless editings and shoot down this long lasting work within seconds. For example it is really hard, i.e. to insert a short OSM-way. at the correct position of the relation, if you do not have excellent knowledge 1) of the object and 2) of every place in detail. Try it and you know, what I mean. That means, you have to wait for a person that has both and finds this dispersed way. And that could last very long. If the one, who established the route possibly in a rurely area, does not come back, the chances are good lasting years. If one founds this mistake in his home-area, he has no chance to heal it, if he has no clue i.e. from this bycycle-route or the public-transport. Thus an editor, that does not show relations, is dangerous for the OSM-data. Is it possible to establish an editor, that is easy enough for beginners without being dangerous for OSM? I think, yes. But excluding the relations is not the solution. However really helpful for beginners would be, if an editor could make the relations graphically editable or make their use as easy as tags. Pros and Contras are welcome. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Editor without relation-support makes sense?
Frederik Ramm frede...@remote.org wrote: Tirkon, Tirkon wrote: I found some discussions within OSM, that it would make sense to offer an OSM editor especially for beginners. To make it easy enough, they should not confuse the beginner with complicated stuff like relations and thus not show and support them. But does that make sense? Not showing (i.e. shielding the user from) relations while secretly handling them might make sense if the editor does a good job. It will be much harder to write such an editor than to write an editor which has a relation editor and forces the user to deal with all the problems ;-) I can imagine many examples, where this is not possible. Here is a simple one: Assuming a straight street. way1 and way2 together constitute a route-relation, but way3 does not belong to it. That means the route-relation begins at node1 and ends at node3: node1--way1--node2way2--node3---way3node4 All nodes are within a straight line. The user moves node3 within the straight line. The street keeps the same form and length. But afterwards the route begins at another point. How will you handle this secretly? How will you make clear to the user the consequences without showing or knowledge of relations? Not supporting relations is impossible anyway; the API will not allow the deletion of a node that is part of a relation. Will this apply to the node3 in the example above as well, because the node itself is not member of the relation. It is only part of a way, which is member of the relation. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Reporting bugs (was Re: What do you wish you'd known?)
Richard Fairhurst rich...@systemed.net wrote: Serious point: if you find a bug or issue or what-have-you in any editor, you need to actually tell us about it rather than just mithering unhappily. As I wrote above: Not every editor is usable with the OSM-account. Possibly in future (or at present?) you have to pay for it. Thus you cannot find out, whether the user is the problem or the editor. I honestly didn't know that the relation ordering issue was the case until last week when Frederik pointed it out on this list. I'm now told there'd been some prior discussion of it on talk-de but that doesn't really help a whole load. I'm very happy to fix the bug (although I don't use ordered relations myself, nor in fact did I write Potlatch's excellent relations code) but I do need to know about it first! Thank you for fixing and your detailed answer. :-) Did you fix the changing direction of a way within a route-relation described above as well? Which version do we have to await? At present you have to use both editors. Potlatch to make the faults and JOSM to find them. But nearly nobody does this. The problem seems to be, that the more expirienced users use JOSM and the Potlatchers are rather hushed within the community. I experienced that the answers to questions concerning editing complicated objects with potlatch are not known in the community. The only answer I hear is: Use JOSM. My general impression is, that potlatch is near at the map. This is much better as in JOSM. But if you come to the complicated objects, it lets you alone. A potlatch with the possibilities of JOSM would be really good. That would also help to notice the potlatch bugs concerning complicated objects. At present you have to use both editors. Potlatch to make the faults and JOSM to find them. The problem of damaging unwanted things without being aware, is a big one. The most beginners seem to start with clicking to edit, without being aware, that this is Potlatch. I think, this applies to many users coming from Wikis like Wikipedia, where clicking edit has no special name. Every node, where a relation (or a tag) begins, ends or changes or is itself the member of a relation could be such a critical point. Moving or deleting such a node could harm the data without being aware, because the user only sees it as a node, that describes the route of the way and nothing more. Possibly there are more critical cases concerning relations, that do not come to my mind at the moment. Some of the problems may be handled automaticly. others not. Possibly it could be helpful, if every critical node is marked similar to the double nodes. Would it be useful, to initiated a kind of collecting-basin at the wiki, where all the unawares are collected in order to be a guideline for all coders of editors? Possibly togeteher with a list, which editor can handle it an which not. By the way: The problem shows, that it seems not to be possible, to write an editor, that does not support relations. The place to submit bugs is http://trac.openstreetmap.org/ . If you don't know that - trac is a bit of an obscure name, after all - then you can just search for 'Bugs' on the wiki and it'll direct you to the right place. By the way: The trac is not made for users without coding experience. It asks questions, you do not know i.e. task, milestone, priority, kayword, cc, assign to. Many people will be lost and deterred. Further the answer I dont know should be possible at component and present and I dont know at version, I dont know preselected. Present would be useful for applications provided by the Web, because you are not aware of the version. i.e. at mapnik. We're a _collaborative_ project, but that only works if you collaborate! Many non native persons will be able to survive, if they have to speak english. But to describe (or read) such complicated stuff only with school-english and with nearly no experience in the dayly life is another dimension. That is where the collaboration will end for many OSM people. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Grenze folgt der Küstenlinie
Chris-Hein Lunkhusen chris66...@gmx.de wrote: Man müsste bestimmte Objekte sperren können, aber das ist noch Zukunftsmusik. Bei den Nordsee-Inseln ist mir das auch aufgefallen, zB. Borkum Hmm, die Ostfriesischen Inseln wandern nicht unerheblich ostwärts z.B.: http://de.wikipedia.org/wiki/Juist#Inselschutz Seit der Existenz von OSM sind da immerhin 30 Meter ins Wasser gefallen. Und auch die hiesige ostfriesische Küstenlinie ändert sich durch fortschreitende Verlandung. Jüngere großflächige Inbesitznahmen, die aufgrund fortschreitender Verlandung erfolgten, sind beispielsweise hier beschrieben: http://de.wikipedia.org/wiki/Leybucht Ein weiteres aber älteres Beispiel ist der heute 100 km^2 große Dollart: http://commons.wikimedia.org/wiki/File:Dollart-Geschichte.svg?uselang=de Das ist aber noch nichts im Vergleich zu den riesigen Einpolderungen (http://de.wikipedia.org/wiki/Koog) in Westfriesland, wo beispielsweise innerhalb eines halben Jahrhunderts eine komplette Provinz von zwölfen der Niederlande dem Meer abgerungen wurde. http://de.wikipedia.org/wiki/Flevoland Und es ist noch nicht zu Ende. Fazit: Die Nordseeküste ist in Bewegung. Ich könnte mir gut vorstellen, dass da amtlicherseits laufend korrigiert wird. Leider ist der Kontakt zu einem Küsten- und Wattforscher vor einigen Jahren abgebrochen. Heute hätte ich ihm einige Fragen zu stellen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aerowest-Luftbilder von Dortmund jetzt v erfügbar
Gehling Marc m.gehl...@gmx.de wrote: Ab sofort stehen die hochauflösende Luftbilder der Dortmunder Firma Aerowest http://www.aerowest.de für das Gebiet der Stadt Dortmund zur Verfügung. Kann man eigentlich die Luftbilder aus Dortmund bei Aerowest direkt verlinken oder geht das nur über deren Menü? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] What do you wish you'd known?
SteveC st...@asklater.com wrote: What are the thing or things you know know that you wish you'd known when you started with OpenStreetMap? The most annoying thing, I wish I had known before is, that editors destroy things without any warning, but you do not have the chance, to take notice of that fact. I.e. potlatch destroys the correct order of the ways in a route relation, i.e. if you divide a way into two parts. And you do not have the chance to take notice, because potlatch does not show the order of the ways in the relation. Further you are not able to notice, that changing the direction of a way destroys a route relation, because in this case the direction of this way is not changed in the relation automatically. These are only two examples of many more. Warnings concerning these facts are not brought up in the description and videos for beginners. Thus I destroyed many relations by making basic and alleged harmless editings, until another user told me. Fortunately he was creator and the maintainer of these relations and the user of another editor. So he could take notice of my destroying. Otherwise I would have gone on. And thus I wish I had known this before. And today I find other users destroying relations. Possibly they wish, they had known it before, too. The problem is, that you cannot distinguish, whether the user is the problem or the editor: Cause there are many new editors on the road, i.e. for smartphones. These editors need registration. You cannot edit with your OSM-account. That means, you need many registrations in order to test these editors. Possibly some of the editors in future will cost money. Thus without all these accounts and paying money you cannot distinguish, whether the user slips up or the editor. Off topic: As far as I know, everybody is allowed to offer a new editor. If their number will grow and destroy the OSM-data as shown above, the maintainers could lose interest and thus the quality of OSM-data decrease. Possibly there should be some considerations, how the unwanted damage of the data by the editor-software could be avoided in general. Sorry for my bad (not native) english. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What do you wish you'd known?
John Smith deltafoxtrot...@gmail.com wrote: On 20 March 2010 18:50, Tirkon tirko...@yahoo.de wrote: The most annoying thing, I wish I had known before is, that editors destroy things without any warning, but you do not have the chance, to take notice of that fact. I.e. potlatch destroys the correct order of the ways in a route relation, i.e. if you divide a way into two parts. And you do not have Relations in general are poorly handled at this point in time, and because they can't easily be shown graphically people don't deal with them as well as they should until it's too late and they've been told of the consequence of their action. Also as best as I can tell, JOSM handles ordering properly as long as all members of the relation are loaded. Today I know all this. But I wish, I had known it before in answer to Steve's question: What are the thing or things you know know that you wish you'd known when you started with OpenStreetMap? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What do you wish you'd known?
John Smith deltafoxtrot...@gmail.com wrote: you shouldn't have to know this. I am the opposite opinion, because ... It is really hard, to setup in particular a long route relation. You need excellent knowledges of all places in detail. Because this is not possible i.e for an e-road with about 5000 km length, people set up projects in the wiki in order to establish this relation within month' and years as teamwork. The same applies i.e. to the public transport net, which is collected in many towns nearly complete, the relations of motorways, national- and other referenced roads, the borders of towns and suburbs, by relation splitted lanes of multilane roads with left-turn, right-turn-function etc etc. One of the most important advantages of the cycle- and hiking-map are the routes, which are long in many cases as well. With destroyed routes these maps lose much of their sense of exist. And all these routes can be destroyed within seconds by harmless editings and shoot down this long lasting work within seconds. Cause it is really hard, i.e. to insert a short OSM-way (misleaded by the editor-software) at the correct position of the relation, if you do not have excellent knowledge 1) of the object and 2) of every place in detail. Try it and you know, what I mean. That means, you have to wait for a person that has both and finds this dispersed way. And that could last very long. If the one, who established the route possibly in a rurely area, does not come back, the chances are good lasting years. If one founds this mistake in his home-area, he has no chance to heal it, if he has no clue i.e. from this bycycle-route or the public-transport. In the case of navigation systems, their users could be misguided because of such harmless editings. I.e. in case of a destroyed left-turn-lane-relation you have to Go straight ahead! Thus I am the opinion, I should have to hnow this. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What do you wish you'd known?
John Smith deltafoxtrot...@gmail.com wrote: On 20 March 2010 21:07, Tirkon tirko...@yahoo.de wrote: John Smith deltafoxtrot...@gmail.com wrote: you shouldn't have to know this. I am the opposite opinion, because ... It is really hard, to setup in particular a long route relation. You I meant the editor shouldn't screw up relations like you previously mentioned, if the editors did better relation handling newbies wouldn't need to know that editors can screw them up. O.K. Then I am with you. :-) This is a concern to OSM, that is close to my heart. The problem is, that - as far as I know - every person may offer an editor. If this is true, with more and more editors the problem will grow in future. Cause one popular editor, that is not aware and does not follow these roules, could be one editor too much, because it could damage OSM-database and in particular the laborious relations considerably. And because of required special registration and possibly paying money for the editor-software, it will be more and more hard, to test and bugfix them. And what will be, if the coder is not willing or able to fix? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] highway=service an Tankstellen
Wie taggt man den highway=service an Tankstellen sinnvollerweise im Detail? Zunächst einmal gilt wohl access=permissive. Darüber hinaus würde ich auch access=destination annehmen. Denn sonst könnte von einem Navigator eine Straßenecke über eine Tankstelle abgekürzt werden. Weder im Falle von Radfahrern (Gefährdung) noch im Falle von Autos (Gefährdung der Tankstellenbenutzer und Aufnahmekapazität) wäre das sinnvoll und wird vermutlich von keinem Navigationssystem so gehandhabt. Zudem wird es offensichtlich kein Tankstellenbesitzer tolerieren wollen, dass der gesamte Autoverkehr einer stark befahrenen mehrspurigen Straße über seine Tankstelle rollt. Der §1 STVO kann hier wegen Privatgelände nicht zur Anwendung kommen, oder? Gibt es also ein Tag, dass access=permissive und access=destination kombiniert? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service an Tankstellen
Chris-Hein Lunkhusen chris66...@gmx.de wrote: Tirkon schrieb: Wie taggt man den highway=service an Tankstellen sinnvollerweise im Detail? Zunächst einmal gilt wohl access=permissive. Darüber hinaus würde ich auch access=destination annehmen. Ist es denn verboten dort einfach so einen Schlenker drüber zu machen? Das ist die Frage. Als Einzelfahrzeug nicht?, aber in der Masse schon? Jedenfalls stehen meist keine Anlieger frei oder Privatgelände - befahren auf eigene Gefahr Schilder dort. Deshalb ist m.E. ein highway=service vollkommen ausreichend. Aus Sicht einer reinen Straßenbeschreibung mag das reichen. Da OSM aber auch Navigator-Grundlage ist, müssen mehr Infos her. Ich könnte mir durchaus vorstellen, dass der gesamte Verkehr einer Hauptverkehrsstraße (und seien es auch nur die Radfahrer), der die Abkürzung über eine Tankstelle nähme, im Sinne der Aufrechterhaltung der öffentlichen Ordnung durch die Polizei unterbunden würde. Das käme einem access=destination recht nahe. Dessen Nutzung würde es uns ersparen, ein weiteres Tag einzuführen, das dem Navi/Router die tankstellenüblichen Verhältnisse auf diesem service anzeigt. Im Zweifelsfall bräuchte man ein Tag service=fuel oder access=fuel. Das ließe dem Navi die Möglichkeit, solche service-ways gesondert und entsprechend zu behandeln. Zumindest das Privatgelände impliziert sich aus der Aufmachung als Tankstelle. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=service an Tankstellen
Norbert Wenzel n_wen...@gmx.net wrote: Imho sollte jedes Routing für alle Servicestraßen access=destination annehmen. Alles andere würde ich als Bug bezeichnen. D.h. ich erwarte von einem Routing nur dann auf einer service zu enden, wenn es keine andere Möglichkeit gibt. ... abgesehen von Radfahrern und Fußgängern, die Parkplätze als Abkürzung nutzen könnten. Bei Tankstellen könnte man das möglicherweise anders sehen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spielwiese
malenki o...@malenki.ch wrote: Es müsste so gestalltet sein, dass es täglich (0:00 Uhr GMT) zu einem definierten Stand zurückgesetzt wird. Dann würde ab ~23:00 GMT niemand mehr üben wollen, weil es eh gleich wieder weg ist. Besser fände ich, dass Daten eines gewissen Alters gelöscht werden (meinetwegen 48h), Nicht gut, da manche Web-Anwendungen so schnell nicht reagieren. Und man will ja auch immer wieder nachbessern, bis Alles wie gewünscht funktioniert. Es sollte Sorge dafür getragen werden, dass der Ort in Europa liegt, damit auch dahingehend beschränkte Anwendungen, wie z.B. die ÖPNV Karte auch funktionieren. Möglicherweise kann man sich durch landuse=user:xy:date einen Abschnitt für bis zu einem Monat nach date reservieren. Danach können Nachfolger den Bereich löschen, wenn man es zuvor nicht inklusive landuse selbst getan hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] OSM-discussions/votings dispersed -bundle under one official umbrella
There is an ongoing discussion in order to integrate more OSM-applications to the main site. But the same problem applies to the discussions, votings and solutions. Not only the OSM software, but also the discussions and votings about OSM are dispersed to many locations (i.e. forums, mailing lists, OSM-Wiki, websites etc.). Every group does its own thing, discusses the same subject and votes or agrees to different solutions. One needs countless accounts and countless passwords in order to participate. This mailing list here and the following location is one of the examples: http://osm.uservoice.com/forums/41047-general?lang=en It would be wise, to bundle the discussions to one location. Because this cannot be done for all languages, there should be !!ONE!! official location, where all the language discussions and votings are under !!ONE!! official umbrella. A good example is Wikipedia, where all the discussions, votings and solutions are done and published at Wikipedia itsself. A appropriate solution should be found for OSM as well. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM-discussions/votings dispersed -bundle under one official umbrella
Tirkon tirko...@yahoo.de wrote: There is an ongoing discussion in order to integrate more OSM-applications to the main site. But the same problem applies to the discussions, votings and solutions. Not only the OSM software, but also the discussions and votings about OSM are dispersed to many locations (i.e. forums, mailing lists, OSM-Wiki, websites I forgot the user account discussions: http://www.openstreetmap.org/user/Tirkon etc.). Every group does its own thing, discusses the same subject and votes or agrees to different solutions. One needs countless accounts and countless passwords in order to participate. This mailing list here and the following location is one of the examples: http://osm.uservoice.com/forums/41047-general?lang=en It would be wise, to bundle the discussions to one location. Because this cannot be done for all languages, there should be !!ONE!! official location, where all the language discussions and votings are under !!ONE!! official umbrella. A good example is Wikipedia, where all the discussions, votings and solutions are done and published at Wikipedia itsself. A appropriate solution should be found for OSM as well. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] wikipedia: towns/cities pages include a osm-direct-link
Gaz Davidson g...@bitplane.net wrote: On 7 March 2010 00:59, Tirkon tirko...@yahoo.de wrote: The developers also think about integrating the georeferenced Commons photos into an OSM map as it is known from Google Maps together with http://www.panoramio.com/. That's a really cool idea. It would also be nice if there was a way to add locations to Commons images using some form of embedded OSM widget, like how it's done on Panoramio. If I understand you correct, this should do it: http://commons.wikimedia.org/wiki/Commons:Geocoding ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?
Für den ÖPNV wird im Wiki und auch hier in der Liste erwähnt, dass als Werte für from und to dasjenige einzutragen wäre, was vorn draufsteht. http://wiki.openstreetmap.org/wiki/DE:%C3%96pnvkarte Nun ist das, was vorne draufsteht (Zielbeschriftung) nicht immer identisch mit der Benennung der Zielhaltestelle. Daher würde ich hier das Ganze noch einmal präzisieren wollen. Zum Beispiel heißt die Zielhaltestelle München Hauptbahnhof. Auf dem Bus, der dorthin fährt, steht als Zielbeschriftung aber nur München. Gegeben sei so ein Fall, dass der Name der Zielhaltestelle und Zielbeschriftung voneinander abweichen. Was soll die Angabe from/to bewirken? 1) Soll from/to dem Benutzer der Karte bei tatsächlicher Benutzung des Verkehrsmittels einen Service bieten? Soll er die from/to Angabe mit der Zielbeschriftung vergleichen, so dass er in der richtigen Fahrtrichtung einsteigt? 2) Soll from/to den exakten Namen der Zielhaltestelle angeben, wie sie in der Relation erfasst ist, damit die Relation weiß, welches die Zielhaltestelle ist? Falls wirklich das, was vorne draufsteht, (Fall 1) angegeben werden soll: Woher weiß die ÖPNV-Relation dann, welches die Zielhaltestelle ist? Denn wenn ich es richtig sehe, wurde die Rolle terminal abgeschafft. Weiß die Relation dies anhand der Reihenfolge, in der die Haltestellen in der Relation erfasst sind? Weitere Frage: Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch getrennte Routenrelationen erfasst werden, die Angabe der Rolle forward/backward bei den beinhalteten ways nicht mehr erforderlich? Gilt das auch für die ÖPNV Karte? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?
Jochen Topf joc...@remote.org wrote: Weitere Frage: Ist eigentlich im Falle, dass die beiden Fahrtrichtungen durch getrennte Routenrelationen erfasst werden, die Angabe der Rolle forward/backward bei den beinhalteten ways nicht mehr erforderlich? Ja. Zur Sicherheit: Ja heißt? 1) Rolle forward/backward bei den beinhalteten ways ist !!nicht!! erforderlich. 2) Rolle forward/backward bei den beinhalteten ways ist erforderlich. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV: from to: das, was vorne dr aufsteht?
Helder Aguiar helder.agu...@teamore.net wrote: Der from= und to= -Tag sollte aber wirklich nur Start- und Zielhaltestelle angeben. Gut, Deine Meinung widerspricht offenbar derjenigen der Gruppe um Jochen Topf, die das Oxomoa Prinzip seinerzeit ausgekocht haben. Aber mit den gegebenen Infos hat die from/to Angabe lediglich Infocharakter und ist zum korrekten Funktionieren der Relation nicht erforderlich. Das war der entscheidende Punkt, um den es mir bei meiner Frage ging. Man kann sich also ohne Funktionalitätseinbuße streiten, was man einträgt. http://wiki.openstreetmap.org/wiki/User:Oxomoa/%C3%96PNV-Schema ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Baumkataster
Mirko Küster webmas...@ts-eastrail.de wrote: Ich hatte das mal bei mir mit einzelnen Bäumen durchgespielt. Da kommt dann sowas bei raus (grüne Punkte). http://www.openstreetmap.org/?lat=51.29571lon=11.43631zoom=17layers=B000FTF Marcel Reich-Ranicki hätte sicher seine helle Freude, dieses weiter auszuschmücken: Denn wer hätte je gedacht, dass selbst ein trockenes Stück Software vom Type Renderer aich in eine Auseinandersetung mit der Linguistik begeben und ach so alten Lebensweisheiten geschlagen geben müsse, denn Sie sähe den Wald vor lauter Bäumen nicht. ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche Laenderexperten
Mirko Küster webmas...@ts-eastrail.de wrote: Nur ganz entfernt. Wenn ich bei OSM mitmache, meine Daten da rein setze, dann weil ich es allen komplett frei zur Verfügung stellen will. In der Hoffnung das andere es gleich tun, Daten ergänzen oder Ecken liefern, wo mir Daten fehlen und wo ich mich für interessiere. Das ganze möchte ich dann auch nach belieben nutzen. Andere können meine Daten auch nach belieben nutzen. Ich mache aber nicht die Arbeit für irgendein Freibier Portal, was mich wieder einschränkt und wo ich letztendlich nichts von habe, außer Arbeit. Wenn ich irgendwelche detailierten Spezialkarten gegen Cash liefern will, dann mache ich das selber und kassiere für meine Arbeit auch selber. Wenn du eine angemessene Beteiligung an den Kartenersteller ausschüttest dann könnte man sich auf anderer Basis für wirklich spezielle Sachen ergänzen. Ich mache die Arbeit, du bietest die Plattform zur Vermarktung. Habe ich absolut nichts gegen. Aber arbeit machen und dritte kassieren schön die Lizenzkosten dafür, nee, Da kann man auch gleich dieses Goggle Teil nutzen. Da sehe ich gewisse Parallelen zu den proprietären Bild-Datenbanken im Internet, denen deren User ihre hochqualitativen Fotos zur Verwendung nach deren Gutdünken zur Verfügung stellen, obwohl es mit http://commons.wikimedia.org/wiki/Hauptseite eine freie Variante gibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda torst...@gmail.com wrote: Die Komplexität beispielsweise eines Straßenzuges besteht in der Wirklichkeit aus wechselnden Eigenschaften, wie Maxspeed, Befahrung durch Buslinie, Wechsel des Stra0ennamens etc. Diese in der Realität existierende Fakten müssen in OSM 1:1 abgebildet werden. Eine Lösung kann also niemals weniger komplex als die Wirklichkeit sein. Das wage ich zu bezweifeln. Natürlich hat das Abbild der Daten eine entsprechende Komplexität. Auf Userseite muss dies jedoch nicht gegeben sein. Man bearbeitet ja auch kein Foto pixelweise, nur weil es aus Pixeln besteht. Ich will das Ganze einmal abkürzen, da Ich vermute, dass wir hier aneinander vorbeireden. Möglicherweise habe ich nicht weit genug ausgeholt und vermeintlich Selbstverständliches fortgelassen. Wenn ich eine Karte als Foto ansehe und pixelweise bearbeitete, dann ist das ja gerade die unnötige Verkomplizierung (und zwar in höchster Vollendung), gegen die ich mich in meinem gesamten Posting stemme. Ziel meines Modells ist es, eine Geschwindigkeitsbeschränkung, den Verlauf einer Buslinie, die ununterbrochene Mittlinie oder die Leitlinie etc. genau dort in die Karte einzuzeichnen, wo man sie in Wirklichkeit vorfindet (und das nenne ich Komplexität(sgrad) der Wirklichkeit), ohne dabei die Straße unnötig an jedem Punkt aufsplitten zu müssen, an dem sich eine Eigenschaft ändert. Denn in Wirklichkeit ist die Straße an diesen Punkten auch durchgehend. Hält man sich dies vor Augen, wird klar, dass Deine Lösung nicht funktionieren kann, wie ich unten an Beispielen zeigen werde. Das stimmt nicht. Vielleicht hast du mich in der Lösungsbeschreibung nicht richtig verstanden. Um das zu prüfen, folgendes Beispiel. - | Modul | editierbar | sichtbar | - | Straßen |o | x | - | Landnutzung |o | x | - | Gebäude |o | o | - | Routen |o | o | - | Grenzen |x | x | - | ÖPNV|o | o | - Bei dieser Oberfläche gäbe es beispielsweise die Möglichkeit, ÖPNV auf sichtbar und editierbar zu schalten, aber die Straßen in beiden Fällen außen vor zu lassen ... oder umgekehrt. Es geht darum unnötige Fakten auszublenden und, im Gegensatz zu einer editorbasierten Lösung, ein System zu schaffen, dass Bearbeitungen an Teildatenmengen erlaubt, ohne andere Daten zu beschädigen. Richtig! Dennoch kann ich beispielsweise eine Buslinie nicht getrennt von einer Straße bearbeiten. Der Bus kann eben nur dort fahren, wo auch eine Straße existiert. Wenn ich also die Buslinie bearbeite, muss zwangsläufig auch der Straßenverlauf beachtet werden oder der Bus fährt über die Wiese oder durch Häuser. Umgekehrt muss sich bei der Manipulation des Verlaufes der Straße, auch der Verlauf der Buslinie ändern. Ebenso kann ich einen auf der Straße markierten Bushaltepunkt[1] nicht ausblenden, wenn ich die Straße verschiebe, denn die Haltestelle muss ebenfalls verschoben und daher neu verortet werden. Das ist aber nicht möglich, wenn diese ausgeblendet bleibt. (Das gilt natürlich analog für diejenigen Punkte, wo eine Straßeneigenschaft (z.B. Maxspeed) beginnt oder endet.) OT: Kann mir jemand sagen, warum ich nicht so auf Kosenamen auf der Mailingliste stehe? Warum ich mich schwer tue, Teilnehmer mit Kosenamen genau so ernst zu nehmen, wie solche, die ihren Realnamen dabeischreiben? Wobei ich hiermit nicht Tirkon meine, über den ich mir auf der Fossgis bereits mein eigenes Bild machen konnte. Natürlich kann ich Dir auf diese rhetorische Frage keine Antwort geben. Ich kann Dir nur erklären, welche Beweggründe es geben kann, einen Nick zu verwenden. Die heutige Datensammelwut und -Zusammenführung (Stichwortbeispiele: Vorratsdatenspeicherung und ELENA) schafft einen gläsernen Menschen. Der Nickname kann dagegen schützen. Die Verwendung des Realnamens allerorten macht eine Zusammenführung der Daten einfach. Insofern empfinde ich den von einigen Personen in deutschen Newsgroups geforderten Realnamen für nicht mehr zeitgemäß. Gerade in naturwissenschaftlichen Gruppen wird dies auch zunehmend nicht mehr moniert. Die große Mehrheit akzeptiert dort inzwischen Nicknames. Bei englisch- und französischsprachigen Gruppen ist das ohnehin kein Thema. Auch in der Wikipedia sind Nicks gang und gäbe. Ferner hilft der Nick solchen Personen, welche (zumindest lokal) im öffentlichen Licht stehen. So können sie sich eine kleine Privatsphäre schaffen, in der sie wie jeder andere in der Community operieren können, ohne dass sein Restleben dort immer wieder thematisiert wird
Re: [Talk-de] Newsreader gestört ?
Johann H. Addicks addi...@gmx.net wrote: Das ist kein Problem des Newsreaders, sondern des Newsservers. Deswegen schrieb ich ja bei gmane ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda torst...@gmail.com wrote: Ziel meines Modells ist es, eine Geschwindigkeitsbeschränkung, den Verlauf einer Buslinie, die ununterbrochene Mittlinie oder die Leitlinie etc. genau dort in die Karte einzuzeichnen, wo man sie in Wirklichkeit vorfindet (und das nenne ich Komplexität(sgrad) der Wirklichkeit), ohne dabei die Straße unnötig an jedem Punkt aufsplitten zu müssen, an dem sich eine Eigenschaft ändert. Denn in Wirklichkeit ist die Straße an diesen Punkten auch durchgehend. Du erzeugst dadurch Pseudo-Ways. Das macht es nicht einfacher. Im Gegensatz zum Zeichnen sollte das Einzeichnen (von Maxspeed, Busroute, Mittellinie) in die Karte suggerieren, dass man nicht irgendwo in der Gegend rummalt, sondern dieses mehr oder weniger genau entlang eines Straßenzuges erfolgt. Der Editor gibt dann beispielsweise durch Einfärbung der Route Rückmeldung, welche Straße er als getroffen ansieht und speichert sie schließlich als Relation und !!nicht!! als Pseudo-Way ab. Jetzt kann ich jede Relation für sich grafisch ausweiten oder kürzen, ohne eine andere zu schädigen. Wenn ich den Verlauf der Straße zurechtzupfe, könnten die Relationen durch verschiedenfarbige Farbbalken parallel zur Straße dargestellt werden. Eventuell reicht es auch, einen einzelnen Balken zu nutzen, der an jedem Anfang/Ende einer Relation, zwischen zwei Farben wechselt und für unaufgelöste Hotspots eine weitere Farbe verwendet, welche zur besseren Wahrnehmung eine Mindestgröße annimmt. Auch getaggte Punkte auf der Straße, wie Bahnübergänge und Zebrastreifen, werden gekennzeichnet. So wird unmittelbar beim Zupfen des Verlaufs klar, wenn man einen Problempunkt mit der Maus in der Hand hält. Bei Mausdrüberhalten oder Anklicken eines Problempunktes könnten nähere Infos (Anfang/Ende von Maxspeed, Buslinie) und zur Lösch- bzw Verschiebeproblematik angezeigt werden. Ich weiß, dass so etwas nicht einfach zu programmieren ist. Mir fällt allerdings kein Mittel ein, welches das OP-Problem besser mildern und transparenter machen könnte. Bei dieser Oberfläche gäbe es beispielsweise die Möglichkeit, ÖPNV auf sichtbar und editierbar zu schalten, aber die Straßen in beiden Fällen außen vor zu lassen ... oder umgekehrt. Wer sagt dir, das diese Möglichkeit bestehen würde Das wäre doch Unsinnig. Natürlich würde ÖPNV auch Straßen mitaktivieren, aber eben nicht umgekehrt. Ich dachte, das wäre klar gewesen. Eben nicht. Das war der Knackpunkt. Jetzt erklärt sich vieles, auch unter der Kategorie nie behauptet. Das musst du mir nicht erklären. In meinem Eingangsposting (vielleicht noch mal lesen) habe ich geschrieben, dass es Regeln geben soll, die die Abhängigkeit der Module untereinander beschreibt. Und genau da setzt das von mir beschriebene Konzept der unteilbaren Wege mit Eigenschaftsrelationen an. Analog zur obigen grafischen Beschreibung stellt die Unteilbarkeit der Straßenzüge den ununterbrochenen Straßenkörper dar, auf dem die Relationen unabhängig voneinander aufgebracht werden. (Wie die darunter liegenden Schichten das in der Datenbank darstellen, steht auf einem anderen Blatt.) Durch diese Unabhängigkeit brauchen Abhängigkeitsregeln für die Relationen untereinander erst gar nicht aufgestellt zu werden. Es bleiben also nur noch die Regeln zwischen Straßenkörper (way) einerseits und Relation sowie getaggte Punkte andererseits. Durch das Konzept können nun diese beiden Mengen mit wenig Aufwand bestimmt werden: 1) Knickpunkte der Straße 2( Anfangs- und Endpunkte der Relationen sowie getaggte Punkte. Wenn ich mich nicht täusche, braucht man zur Abhängigkeitbeschreibung der Module untereinander für die Gruppe 1) und für die Gruppe 2) jeweils eine Lösch- und eine Bewegungsregel, die nicht allzu kompliziert sein dürfte. Dann wäre mit vier Regeln das gesamte Gefahrpotential beschrieben. Eine geringe Anzahl von Regeln hilft natürlich ungemein. Sobald man sich alle verinnerlicht hat, kann man für jede ein Handlungsschema einüben und möglicherweise veröffentlichen. Man ersetze in obiger Beschreibung Straße durch way und verallgemeinere sie so. Wermutstropfen: Eventuell machen Vaterrelationen sowie Areas das Regelschema komplexer. Falls dies für Veterrelationen zutrifft, könnte man möglicherweise durch Auflöung der Vaterrelation in die Elemente Tochterrelationen diesem beikommen. Dabei bleibt aber aus Usersicht die Vaterrelation erhalten. In dieser Richtung kann ich das Problem noch nicht so ganz greifen. Es muss wohl erst einmal sacken. Ich kenne mich mit der OSM Datenbank nicht aus. Intuitiv vermittelt sich mir das beschriebene Prinzip als eines, das vom bisherigen Schema abweicht und eventuell eine Konvertierung des Datenbestandes notwendig machen könnte. Daher der Begriff OSM 2.0. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Einige Gedanken zu OSM - Datenbanken nic ht croudsource-fähig?
Torsten Breda torst...@gmail.com wrote: Die Komplexität der OSM-Welt nimmt ständig zu. Auch ich habe das schon einmal thematisiert. Mein Vorschlag war #hnlich wie Deiner, nämlich eine All-in-One konfigurierbare Karte zu haben. die als Hintergrund für den Editor geschaltet, nur das Editieren der sichtbaren Objekte zulässt. Aber auch dies ist nicht unproblematisch und nur in Grenzen machbar. Wie kann man das Lösen? Die Komplexität beispielsweise eines Straßenzuges besteht in der Wirklichkeit aus wechselnden Eigenschaften, wie Maxspeed, Befahrung durch Buslinie, Wechsel des Stra0ennamens etc. Diese in der Realität existierende Fakten müssen in OSM 1:1 abgebildet werden. Eine Lösung kann also niemals weniger komplex als die Wirklichkeit sein. Sie kann höchstens vermeiden, dass durch ihre Implementierung zusätzliche Komplexität geschaffen wird. Hält man sich dies vor Augen, wird klar, dass Deine Lösung nicht funktionieren kann, wie ich unten an Beispielen zeigen werde. Was aber getan werden kann, ist es, die Sache nicht unnötig zu verkomplizieren. Verschiebe ich also eine Straße, so müssen zwangsläufig deren Eigenschaften mitverschoben werden. Aus diesem Grunde ist Dein Vorschlag nicht umsetzbar, Relationen von der Sie beheimatenden Straße loszulösen. Und daher kann der ÖPNV in Form von Bussen nicht unabhängig von einer Straße editiert werden. Das Problem bei der Sache ist es. dass sich beispielsweise Busse innerhalb des ÖPNV nicht von den Straßen trennen lassen, weil sie als Relationen auf den Straßen liegen. Wenn man zum Beispiel einen Straßenabschnitt in zwei Teile zerlegen muss, weil sich beispielsweise die Höchstgeschwindigkeit ändert, dann ändert sich auch die Relation eines dort fahrenden Busses. Beide Abschnitte müssen dort jetzt in der richtigen Reihenfolge aufgenommen werden. (Ein Punkt, an dem Potlatch übrigens scheitert, weil er die Teilstücke durcheinanderwürfelt und somit jede jede betroffene Relation beim Teilen einer Straße zerstört.) Die Relation wird also infolge der Änderungen an der Straße geändert. Es gibt aber auch umgekehrte Beispiele, bei denen eine Änderung an der Relation eine Änderung an der Straße nach sich zieht. Wenn ein Bus beispielsweise links abbiegt und die darunter liegende Straße durchgehend ist, muss ich die Straße an der Abbiegestelle teilen. Hier ist es also die Erfassung der Buslinie (Relation), welche ursächlich ist. Beide genannten Fälle sind aber eine zusätzliche unnötige Verkomplizierung, welche nicht durch die Realität, sondern durch das verwendete Datenmodell verursacht wird. Hier könnte also eine Vereinfachung ansetzen. Eine bessere Trennung von Straßenkörper, seiner Eigenschaften und der Eigenschaften untereinander ist aber erst dann machbar, wenn ein weiterer Vorschlag von mir umgesetzt würde: Das Straßennetz ist so aufgebaut, dass jede Straße grundsätzlich unteilbar von Verzweigungknoten bis Verzweigungsknoten läuft. Geteilt wird nur noch, wenn ein neuer Verbindungsknoten eingefügt wird. Alle Eigenschaften werden nur noch als Relationen getaggt. Diese Eigenschaftsrelationen, welche dann die Tags ersetzen, können im Rahmen einer vorbestimmten Auflösung an jedem Punkt auf der Straße (bzw way) beginnen oder enden. All dies käme aber einem OSM 2.0 gleich. Die neuen Relationen müssen in der Lage sein, eine ganze Straße (von Verzweigungknoten bis Verzweigungsknoten) aufzunehmen. Darüber hinaus müssen sie Teile einer solchen Straße von Koordinate X1Y1 bis Koordinate X2Y2 (oder bis zum Ende) aufnehmen können, ohne die Straße selbst hierfür teilen zu müssen. Solche durch Relationen verursachten Punkte könnten in der Straßendarstellung anders dargestellt als die Verzweigungsknoten. Dadurch wird klar, dass hier eine neue Eigenschaft beginnt oder endet und dieser Punkt ohne nähere Prüfung nicht verschoben werden darf. Dadurch wird die abgebildete Komplexität der Wirklichkeit in OSM besser deutlich. Denn auch in der Wirklichkeit geht ein Haltevorbot, eine Buslinie, eine durchgezogene Mittellinie, ein Bürgersteig, Maxspeed etc von hier über diese Route nach dort. Und genau so würde es dann in OSM abgebildet, ohne dass der Straßenkörper hierzu verkomplizierend in immer mehr Stücke zerteilt werden muss. Wenn dann noch jemand das Ganze grafisch programmieren könnte, könnte man jede Eigenschaft von hier über diese Route bis dort in die Karte reinmalen. Die 1:1 Abbildung der Realität würde nochmals verbessert. Eine weitere Vereinfachungsmöglichkeit kann es nicht geben, da die Komplexität durch die abzubildende Wirklichkeit gegeben ist. Das OSM 2,0 stellt aber sicher, dass sie durch das Datenmodell nicht zusätzlich verkompliziert wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Newsreader gestört ?
Jan Tappenbeck o...@tappenbeck.net wrote: Moin ! kann mir einer sagen ob der Newsreader gestört ist ??? Ich bekomme nur die gebündelten eMails - im Newsreader kommt nichts an ! Gruß Jan :-) Hatte das Problem in den vergangenen Tagen bei gmane auch. Einige Postings kamen im Newsreader an, andere (so auch meine eigenen) nicht. Im Moment flutscht es wieder. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mapzen!?
Nick Black nickbla...@gmail.com wrote: 2010/3/9 UMAX974 umax...@googlemail.com: CloudMap möchte halt gerne etwas mehr über Dich wissen ;-) Am 09.03.2010 um 08:34 schrieb Torsten Breda: Warum reicht bei Mapzen kein normaler OpenStreetMap-Account? Man muss sich extra anmelden. Das ist bei den anderen Editoren nicht so. Gruß Torsten ___ 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 -- What is it trying to tell us? ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM gewiinnt auf der CeBIT Linux New Media Award
Tirkon tirko...@yahoo.de wrote: Nachdem OpenStreetMap schon 2009 den Linux New Media Award in den Kategorien Outstanding contribution to Linux and Open Source und innovativstes Open-Source-Projekt abgeräumt hatte [1], gewann das Projekt in letzterer Kategorie abermals im Jahre 2010 [2] und ist damit das erste Projekt, das diese Auszeichnung zweimal in Folge erlangte. Die Verleihung des Preises fand auf CeBIT 2010 statt. Am OSM Stand auf der Fossgis 2010 konnten die Mapper die Verleihung live verfolgen. [1] http://www.linux-magazin.de/NEWS/Cebit-2009-Openstreetmap-erntet-zwei-Linux-New-Media-Awards [2] http://www.heise.de/open/meldung/CeBIT-Linux-New-Media-Awards-verliehen-946400.html Sorry, leider war wohl der Versand über gmane gestört. so dass ich nur eine selektive Auslese der Postings erhalten habe. Daher blieb mir verborgen, dass dies schon zuvor thematisiert wurde. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] wikipedia: towns/cities pages include a osm-direct-link
colliar colliar4e...@aol.com wrote: As we are working together with wikipedia, it would be nice to include direct-links to osm or even a small part of the map to the city/town pages. This is already done in the beta version of Wikipedia. You can run it if you have got a Wikipedia account. Every given coordinate in an Wikipeida article has got an OSM-link now, which will open an embedded OSM-map. I think this would be a good promotion towards osm. I am not much into editing wikipedia but I just wanted to get the ball rolling. The german OSM and german Wikipedia each has got 3 high-end servers for OSM-applications. On the FOSSGIS 2010 with included OSM congress, which ended yesterday, the developers of both projects together performed a workshop concerning that stuff: http://www.fossgis.de/konferenz/2010/events/113.de.html They told us, that there are many things on the road, like i.e. maps in every Wikipedia language. For this application the name:language: tag will be important. The advantage is, that you can read i.e russian or chinese parts of OSM maps in latin letters or vice versa. I.e. here is a tool by one of the developers in order to establish a multilingual country-list: http://toolserver.org/~mazder/multilingual-country-list/ Furthermore the free multimedia database Wikimedia Commons is now integrated into OSM. That means, that every photo you can find in Wikipedia articles you can embed in OSM-Wiki article as well. Here is an OSM Wiki example with many Commons photos embedded: http://wiki.openstreetmap.org/wiki/DE:Tag:highway%3Dtrunk Vice versa OSM people can upload their (georeferenced) photos at the free multimedia database Wikimedia Commons now: http://commons.wikimedia.org The developers also think about integrating the georeferenced Commons photos into an OSM map as it is known from Google Maps together with http://www.panoramio.com/. As you can see, the ball is rolling. :-) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] OSM gewiinnt auf der CeBIT Linux New Media Award
Nachdem OpenStreetMap schon 2009 den Linux New Media Award in den Kategorien Outstanding contribution to Linux and Open Source und innovativstes Open-Source-Projekt abgeräumt hatte [1], gewann das Projekt in letzterer Kategorie abermals im Jahre 2010 [2] und ist damit das erste Projekt, das diese Auszeichnung zweimal in Folge erlangte. Die Verleihung des Preises fand auf CeBIT 2010 statt. Am OSM Stand auf der Fossgis 2010 konnten die Mapper die Verleihung live verfolgen. [1] http://www.linux-magazin.de/NEWS/Cebit-2009-Openstreetmap-erntet-zwei-Linux-New-Media-Awards [2] http://www.heise.de/open/meldung/CeBIT-Linux-New-Media-Awards-verliehen-946400.html ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Sebastian Klemm osm-l...@freenet.de wrote: Wenn Dir eine derartige Erklärung im Wiki fehlt, dann nichts wie rein damit, ich konnte jedenfalls keine groben Unzulänglichkeiten entdecken. done: http://wiki.openstreetmap.org/wiki/DE:Relations ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Inquiry about Egnos / Indoor mapping
Aun Johnsen li...@gimnechiske.org wrote: EGNOS require clear view of the sky in the same way that the GPS needs From Middle-Europe you require a clear view nearly to the south (similar to Astra TV-satellite, look at the antennas), because the EGNOS satellites are in a geostationary orbit above Africa and from Middle-Europe-sight not too far away from Astra. For other receiving-positions look at the EGNOS satellite positions: http://en.wikipedia.org/wiki/European_Geostationary_Navigation_Overlay_Service#Satellites Many GPS-Loggers (i.e. Garmin, satellite view, letter D for DPGS) support EGNOS, because the signal is already available for a few years as beta. Look at the description of your logger. If a satellite is not available, there is possibly another solution. I did not try it and I am not really sure. Look at http://www.gpsbabel.org/htmldoc-development/filter_track.html and look for ²DPGS. That sounds to me as if GPS-Babel could support EGNOS. If this true, you possibly can throw your track into GPS-Babel, configure it accordingly and it will automaticly fetch the EGNOS-data by internet and correct the track, assumed the time stamps in the track are correct. Otherwise do not use it. If your GPS-Logger is supported by GPS-Babel, it will also import the tracks to your PC. All that inclusive outputting your desired format (i.e. OSM compatible GPX) will be done in one turn, if you configure GPS-Babel accordingly. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Nils Heuermann w...@oemmes.net wrote: Erst einmal vielen Dank für Deine ausführlichen Antworten. :-) Damit das System funktioniert (vorausgesetzt, die Logik hat keine Macken), braucht man natürlich einen grafischen Editor, mit dem man sich die einzelnen Spuren usw. auf einfache Weise zusammenklicken kann. Da muss noch etwas Programmierarbeit reingesteckt werden :) Spuren zusammenklicken - Das ist Musik in meinen Ohren. Das wäre exzellent und eine neue Qualität der Usability und des Editierens bei OSM. :-) Gerade in ländlichen Gebieten steht ein Mapper häufig allein vor einem großen Gebiet, so dass er vor Ort die einfachsten Änderungen z.B. Umbenennung der Straße wegen des Vorhandenseins von Wayparts nicht mehr aktualisieren könnte. Das wäre kein Problem. Die wayparts beschreiben den Querschnitt der Straße und ggf. spurabhängige Einschränkungen (z. B. Busspur). Der Name und andere allgemeine Eigenschaften (highway, surface, ...) bleiben weiterhin am ganz normalen Way (letztere könnten allerdings für einzelne Spuren überschrieben werden). Das begreife ich irgendwie nicht. In Deinem ganzen Konstrukt finde ich keine Tags für den ganz normalen way, wie beispielsweise name oder ref der Gesamtstraße: http://wiki.openstreetmap.org/wiki/DE:User:%C3%96mmes/Wayparts Und genau das ist es, was mir derzeit einen Zugang zum Grundverständnis dieses Konstruktes verwehrt. Können eigentlich von Radweg und Straße eingeschlossene Eisenbahnlinien auch mit Waypart in die Linienbündelung eingeschlossen werden? Theoretisch ist das möglich. Man sollte allerdings abwägen, ob es in so einem Fall nicht sinnvoller ist, die Dinge als einzelne Wege zu erfassen. In diesem Falle gerechtfertigt. Denn hier wäre wegen der Enge des Raumes bei Fuß-/Radweg neben der Straße und dahinter die Eisenbahn, selbige quasi durch die Wohnzimmer der Straßenanlieger in der geschlossenen Ortschaft gefahren. Daher hat man die Eisenbahn neben die Straße und als dünnes Polster zu den Häusern den Fu0- und Radweg dahinter gelegt. Denn es fahren besser Fahrräder durchs Wohnzimmer als Güterzüge mit gerne 50 Waggons der sechsachsigen Schwerklasse. Hier hat jeder Hauseingang und jede Fuß-/Rad- Straßenquerung seine eigenen drei Andreaskreuze ohne Vorbaken. Vermutlich ist das die massivste Ansammlung dieser Schilder ever. ;-)( Das war früher ein nicht endendes Pfeifkonzert der Lok, bis dieses per Sondergenehmigung abgeschafft wurde. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Nils Heuermann w...@oemmes.net wrote: Also als *Voraussetzung* für wayparts braucht man erstmal eine Straße/Way. Das war der springende Punkt. Ich habe in Deinem Konstrukt gesucht, wo der denn nun versteckt und verwurstet sei. Er war also gar nicht enthalten. Damit wird der Konstrukt klar und die Basisdaten bleiben auch für Otto Normalmapper problemlos editierbar. Nochmals vielen Dank für Deine Erläuterungen. :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Johann H. Addicks addi...@gmx.net wrote: Als Potlacher hat man so oder so verloren, da man Relationen nur wie durch's Schlüsselloch sieht. Man kann zwar etwas ändern, aber wenn's kaputt geht, dann bekommt man es garantiert nimmer repariert, weil man nix wiederfindet. Neben der Schlüssellochsichtweise kann man immer nur ein Objekt nach dem Anderen in eine Relation packen. Die Zielrelation muss man bei jedem Hinzufügen erneut auswählen. Bei JOSM kann man sehr viele Objekte mit einem einzigen Schwung in die Relation aufnehmen. Zwei Dinge sind in Potlatch überhaupt nicht implemetiert: 1) Das Anzeigen und Editieren der Reihenfolge der Member in einer Relation 2) Die Anzeige, ob sich eine Relation in einer (Vater-) Relation befindet sowie das Hinzufügen bzw Herausnehmen einer Relation zu/aus einer (Vater-) Relation. Diese Dinge kann man nur auschließlich in JOSM anschauen und editieren. Dafür ist Potlatch wesentlich intuitiver und ohne Anleitung erlernbar. Zudem erfolgt bei Potlatch der Downlaod des Umfeldes des Editierbereiches automatisch, während man JOSM jedesmal wieder umständlich von Hand nachladen muss. Besonders fummelig wird das, wenn man ein großes Objekt pflegen möchte. Auch das Aufsuchen des zu editierenden Kartenausschnitts über die ganz normale OSM-Karte ist bei Potlatch wesentlich besser gelöst. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?
Oliver Kuehn (skobbler) osm.oliver.ku...@gmx.de wrote: Zwei Punkte müssen wir aber noch abschließend klären: (1) Ist der GPS-Empfänger des iPhones ausreichend genau genug (dazu kommen ja auch schon in dem Thread Anmerkungen und Zweifel)? Alle, die das iPhone für Navigation genutzt haben, wissen, dass der Empfänger nicht der Beste ist, warum ja auch einige Anbieter aktive Fahrzeughalter mit seperatem GPS-Empfänger anbieten. Da wir die Ergebnis bisher hauptsächlich für die Anwendungsoptimerung genutzt haben, müssen wir uns das Ergebnis mal ansehen, wenn wir mehrere Tracks über die Karte legen. Sehr löblich, dass Ihr dabei so umsichtig vorgeht und Euer gewonnenes Fachwissen auch im Dienste von OSM einsetzt. Denn weder uns noch Euch wäre geholfen, wenn sich das OSM Material hierdurch verschlechtern würde. Das ist durchaus eine vertrauensbildende Maßnahme, welche den vorsichtigen Anfangs-Pessimismus gegenüber Skobbler mildern könnte. Wenn man nämlich Google als Vergleich heranzieht, dann ist das existierende OSM Material zumindest in Deutschland in der Regel schon recht präzise. Um festzustellen, ob Google als Referenz dienen kann, habe ich schon vor meinen OSM-Zeiten Google punktuell in Niedersachsen mit den amtlichen Karten verglichen. Und das war in der Regel überzeugend. Wenn es Abweichungen gab, dann waren die gleich so gravierend, dass sie eindeutig als Bearbeitungsunglück identifizierbar waren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Johann H. Addicks addi...@gmx.net wrote: Am 27.02.2010 15:48, schrieb Martin Koppenhoefer: Schwierig wird's in der Tat bei Zufahren in Form von service. Da bräuchte es dann wieder pro Einfahrt eine Abbiegerelation, da es ja eine Kreuzung gibt, die obige Regel (außerhalb von Kreuzungen) aufheben würde. ja eben. Und selbst diese ausserhalb von Kreuzungen-Regel funktioniert m.E. nicht, weil man gar nicht mehr erkennt, wo eine Kreuzung ist... Wenn NoUTurn=irgendwas, dann Wenden nur noch an Kreuzungen ab residential/unclassified aufwärts. Ausnahmen wieder per Abbiegerelation. Oder anders: Wieviele Abbiegerelationen willst Du bauen, wenn auf eine Straße mit durchgezogener Mittellinie haufwenweise service-ways von Geschäften etc. münden? Jedes Mal den Way nochmal durchhaken und eine turn-restriction-relation draufbauen? Oder überall getrennt Richtungsfahrbahnen mappen, wo gar keine solchen vorhanden sind? Ihr vergesst bei Eurer Diskussion, dass sich nicht alle vorkommenden Fälle durch Tags darstellen lassen. Als einfachstes Gegenbeispiel sei hier ein Knotenpunkt mit drei Straßen genannt, die ich A, B und C nennen will. Mittels Tags kann man nicht darstellen, ob an dem Knoten eine nicht unterbrochene durchgezogene Mittellinie von A nach B, B nach C oder C nach A durchläuft. Das Ganze lässt sich mit der durchgezogene-Mittellinien-Relation darstellen, die ich schon unter was: Motivation zum Beheben von Bugmeldungen von kommerziellen Verwertern der OSM Daten?!? beschrieben habe: Man packt einfach alle Straßénabschnitte einer durchgezogenen Mittellinie von deren Anfang bis Ende in eine Relation und gibt dieser ein passendes englisches Tag Richtungsfahrbahntrennung. Geht die durchgezogene Linie an Straßenknoten (Kreuzungen, Abzweigungen) durch, so läuft auch die Relation durch. Ist die durchgezogenen Linie an Straßenknoten unterbrochen, so endet die Relation dort und eine neue beginnt. Dies ist mit den heutigen Mitteln von OSM zu bewerkstelligen. Möchte man allerdings aus Gründen der Übersichtlichkeit der Relations-Zerstückelung durch an Knotenpunkten unterbrochenen Nittellinien entgegen wirken, bräuchte man ein neues Feature in OSM. Dies wären (durchgehende-Mittelinien-) Relationen, welche Knotenpunkte explizit ausschließen können, nämlich dann, wenn die Mittellinie dort unterbrochen ist. Der Vorteil dieser Methode ist auch die 1:1 Darstellung der Realität. Eine Relation entspricht genau einer durchgezogenen Mittelinie in ihrer Gesamtlänge. Sie kann also nun auch einfach in die Karte eingezeichnet werden. Gleichzeitig könnt ihr die ganze unübersichtliche Ansammlung von Umkehrverboten und Abbiegebeschränkungsrelationen vergessen, die eigentlich in der Realität auch nicht explizit vorkommen, sondern lediglich Folge des Überfahrverbotes der durchgehenden Linie sind. Es ist nun Aufgabe der Navigations-/Router-Software durch entsprechendes Routen das Überfahren der durchgehenden Mittellinie zu unterlassen. Für Fußgänger und (abgestiegene) Radfahrer ist dies natürlich weiterhin möglich. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Nils Heuermann w...@oemmes.net wrote: Theoretisch kann man es auch jetzt schon lösen, indem man die jeweiligen Nodes in die Relation mit einer entsprechenden Rolle aufnimmt. Wenn man das genau definiert, können es die Programme auch auswerten. Ich habe bisher keine Beschreibung von Rolle finden können und weiß daher auch nicht, was das ist. Könntest Du vielleicht einmal nichttechnisch beschreiben, was der Sinn und Zweck einer Rolle ist? Welches Problem war ursächlich dafür, dass man sie erfinden musste? Weiter ist mir unklar, wieso nicht nur hier wie selbstverständlich von einer Rolle gesprochen wird, obwohl nirgends beschrieben. Könntest Du daher auch einmal beschreiben, woher Du dieses Wissen hast? Ist Rolle vielleicht ein Import aus einem anderen Fachgebiet außerhalb von OSM? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Nils Heuermann w...@oemmes.net wrote: Was ist eine Rolle? Wenn man einer Relation [1] einen Weg oder Punkt (oder auch eine andere Relation) als Mitglied (member) hinzufügt, kann man dem jeweiligen Objekt eine Rolle (role) [2] zuordnen. Zum Beispiel gibt es bei Abbiegebeschränkungen [3] die Rollen from, to und via, um anzugeben, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Hoffe, das war verständlich :) Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Relations [2] http://wiki.openstreetmap.org/wiki/Roles [3] http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung [4] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts#Mitglieder Ahja, Vielen Dank! :-) Relationen sind für viele User von OSM ein Buch mit sieben Siegeln. Das schreibe ich einmal der algorithmisch korrekten Beschreibung im Wiki zu. Vielleicht sollte man zur Einführung erst einmal alle Fünfe gerade lassen, und ein anfängliches Grundverständnis vermitteln, indem man auf dem Weg erst einmal verkomplizierende Sachverhalte wegläßt und die Wahrheit nur stückweise ans Tageslicht gelangen läßt. So gerüstet kann der User dann auf die algorithmisch korrekte Erklärung losgelassen werden. Ich versuche im Folgenden einmal, dieses Basisverständnis von Relationen, deren Sortierung und Rollen für Nichtprogrammierer bzw. Otto Normalmapper zu vermitteln: Manche Dinge in OSM lassen sich nicht durch die üblichen Punkte und Wege mit angeschlossenen Tags in den Griff bekommen. Um komplexere Zusammenhänge zu beschreiben, gibt es daher die sogenannten Relationen. Eine einfache Relation ist zunächst einmal nur eine Auswahl von Wegen und Punkten, genannt Members (Mitglieder), welche in die Relation wie in einen Korb eingesammelt werden. Der Typ der Relation beschreibt, zu welchem Zweck die Relation dient. Ist der Zweck beispielsweise die Beschreibung einer Route, werden die betroffenen Wegstücke in die Relation eingesammelt. Obwohl dem User intuitiv klar ist, dass die Wegstücke in der richtigen Reihenfolge anzuordnen sind, ist die OSM Datenbank nicht in der Lage, die korrekte Reihenfolge zu erkennen. Daher muss man die Members in der richtigen Reihenfolge sortieren. Abgesehen von der Reihenfolge stehen die Members einer Relation vom Typ Route gleichwertig nebeneinander. Bei anderen Typen von Relationen können die Members nicht gleichwertig sein, sondern müssen spezielle Aufgaben in der Relation erfüllen. Diese spezielle Aufgabe nennt man Rolle. Hierzu hat jedes Member einer Relation ein Textfeld, in das diese Rolle eingegeben werden kann. Die Rolle darf nur aus einem einzigen Wort bestehen. Bleibt dieses Rollenfeld leer, wie im Falle der Routenrelation, dann hat das Member keine spezielle Aufgabe/Rolle, sondern nur eine Standardaufgabe. Anders in einer Relation vom Typ Abbiegerelation. Hier muss spezifiziert werden, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Dazu werden den Membern die Rollen from, via und to zugewiesen. Es muss also zunächst festgelegt werden, von welchem Typ die Relation ist. Erst dann weiß man, welche Werte die Rolle annehmen kann. Ohne die Typangabe der Relation ist die Angabe einer Rolle also sinnlos. Auch eine Menge von Relationen können wiederum in eine Vaterrelation eingesammelt werden. [Ende des Erklärungstextes] Was mir jetzt noch nicht klar ist: Was passiert, wenn beispielsweise *eine dem Relationstyp nicht zugeordnete Rolle verwendet wird? *eine notwendige Rolle fehlt? *eine Rolle, die es eigentlich nur einmal geben sollte, mehrfach vorkommt? Funktioniert dann die Relation nicht mehr? Ist es von der Anwendung abhängig, wie diese damit umgeht? Was passiert, wenn eine Routenrelation unsortiert bleibt? Ist die Sortierung ein reiner Service (,der aber empfohlen wird) für die Anwendung oder ist sie zwingend gemäß der Spezifikation der Datenbank?/der Routenrelation? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Durchgezogene Mittellinien / U-Turns verboten (was: Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?)
Nils Heuermann w...@oemmes.net wrote: Wenn man einer Relation [1] einen Weg oder Punkt (oder auch eine andere Relation) als Mitglied (member) hinzufügt, kann man dem jeweiligen Objekt eine Rolle (role) [2] zuordnen. Zum Beispiel gibt es bei Abbiegebeschränkungen [3] die Rollen from, to und via, um anzugeben, *von* welcher Straße man *über* welchen Punkt *in* welche Straße (nicht) fahren darf. Hoffe, das war verständlich :) Viele Grüße, Nils [1] http://wiki.openstreetmap.org/wiki/Relations [2] http://wiki.openstreetmap.org/wiki/Roles [3] http://wiki.openstreetmap.org/wiki/DE:Relation:restriction#Mindestanforderung [4] http://wiki.openstreetmap.org/wiki/DE:User:Ömmes/Wayparts#Mitglieder Ahja, Vielen Dank! :-) Ich habe einen neuen Thread aufgemacht, um die Thematik des Erklärens weiter zu führen: Otto-Normalmapper-kompatible Erklärung von Relationen Bei den wayparts habe ich für die einzelnen Wege, für die man Spuren eintragen möchte, die Rolle way vorgesehen [4]. Man könnte dann z. B. für die im Thread diskutierten Ausnahmen eine Rolle except (oder wie immer man sie auch nennt - deshalb erfinden/definieren) für Punkte/Nodes festlegen. Ist eigentlich das Aussschließen von Knotenpunkten aus einer Relation deswegen nicht möglich, weil die Editoren es nicht bereitstellen, oder weil die Datenbank es nicht speichern kann? Wayparts sind allerdings ohne speziellen, nahe an der Kartendarstellung arbeitenden grafikartigen Editor für Otto Normalmapper kaum mehr nachvollziehbar. Gerade in ländlichen Gebieten steht ein Mapper häufig allein vor einem großen Gebiet, so dass er vor Ort die einfachsten Änderungen z.B. Umbenennung der Straße wegen des Vorhandenseins von Wayparts nicht mehr aktualisieren könnte. Ich und auch viele meiner OSM-Nachbarn sähen sich außerstande, dies in seinem Gebiet zu tun. Wayparts wären - wie jedes komplizierte Relationengebilde - mit dem grafikartigen Potlatch nicht mehr zugreifbar. Wird Dein Waypart Plugin da Abhilfe schaffen, indem er einen solchen nahe an der Karte arbeitenden Editor bereitstellt? Oder ist das Plugin im üblichen JOSM (für mich undurchschaubaren) Text- und Fenster-Bastelstil für Relationen gehalten? Können eigentlich von Radweg und Straße eingeschlossene Eisenbahnlinien auch mit Waypart in die Linienbündelung eingeschlossen werden? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Otto-Normalmapper-kompatible Erklärung von Relationen
Matthias Versen s...@mversen.de wrote: Es ist ein undefinierter Zustand wenn solche Fehler vorhanden sind. Was die jeweilige Software daraus macht ist Zufall, die kann den Fehler ausbügeln aber es kann zu einer fehlerhaften Interpretation kommen bis zu kompoletten ignorieren/verwerfen der Relation. Dann wäre also Folgendes denkbar: 1) Es existiert eine Buslinien Relation. Diese taucht aber in der ÖPNV-Karte nicht auf. Grund dafür könnte sein, dass an einer einzigen Haltestelle ein Tippfehler bei der Rolle existiert. 2) Das von der ÖPNV Karte unterstützte ÖPNV Schema wurde geändert. Eine ehemals unterstützte Rolle wird in einer neuen Version nicht mehr verwendet. Folge: Die Buslinie verschwindet von der Karte. 3) Ein Straßenstück hat eine Richtung. Diese Richtung wird von einer Relation benutzt. Der Editor Potlatch unterstützt Relationen nur rudimentär. Es ist dort nicht erkennbar, dass die Straßenrichtung von einer Relation benutzt wird. Ein User dreht daher die Richtung um. Die betroffene Relation verschwindet komplett aus der Anwendung. 4) Ein gerades Straßenstück besteht aus drei Punkten. Der mittlere Punkt erscheint zunächst überflüssig, ist aber Mitglied einer Relation. Ein User löscht den mittleren Punkt. Die Relation verschwindet aus der Anwendung. ... Es gibt da einen User, der Videoanleitungen für das Editieren in OSM herausgibt. In diesen Anleitungen löscht er solche überflüssigen Punkte, ohne den Anwender auf die mögliche Verwendung dieses Punktes in einer Relation hinzuweisen. Der Name des Autors dieser Anleitung ist ... SteveC. ;-) http://www.youtube.com/watch?v=8MF4oJIHuQwfeature=player_embedded ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FOSSGIS/OSM-Konferenz: Anmeldung noch bis 26.Februar möglich
Frederik Ramm frede...@remote.org wrote: Russ Nelson hat auch mal einen Rueffel bekommen, weil er ein Perlskript geschrieben hat, das seine eigene Heimatposition in Minischritten veraendert hat, so dass er Schritt fuer Schritt ueber die 10 Mapper in meiner Naehe alle Leute bekam, die in seiner gegend ihre Heimatposition hatten... So habe ich das für die hiesige Region gemacht, allerdings nicht per Script, sondern per Hand. Es waren rund fünfzehn Heimatpositionen nötig. Eine Handvoll User wurden auch per Zufall durch mehrfache Edits in der Region gefunden. Ferner habe ich bei jedem so gefunden User von Hand geprüft, ob er laut seiner Bearbeitungsliste mindestens drei Seiten Edits vornehmlich im Gebiet hatte. Dass von 25 Angeschriebenen fast die Hälfte - teilweise sogar sehr dankbar - geantwortet hat, werte ich das Ganze mal als möglichst belästigungsarme Methode. In der Liste hier wird oftmals empfohlen, bei Unstimmigkeiten erst einmal den Editierenden anzuschreiben. Da er aber dazu keine Zustimmung gegeben hat, wäre selbst dieses unzulässig. Folglich wäre es auch unmöglich, eine lokale Community insbesondere in ländlichen Regionen zusammen zu bekommen. Das würde ich den Hardlinern, die gegen den Spam mit allen Mitteln vorgehen würden, zu bedenken geben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?
Oliver Kuehn (skobbler) osm.oliver.ku...@gmx.de wrote: Da Du Dich als Skobbler-Angehöriger geoutet hast, ein Posting mit Fragen und Anmerkungen: Marcus hat auf dem skobbler-Blog dazu einige Gedanken zusammengefasst: http://blog.skobbler.de/2010/02/skobbler-osm-segen-fluch-1v2/ Welche Funktion hat Marcus innerhalb von Skobbler? Und hier noch Teil 2 der Ausführungen von Marcus: http://blog.skobbler.de/2010/02/skobbler-osm-segen-fluch-2v2/ Und damit alles OSM-Bezogene beisammen ist: http://blog.skobbler.de/2010/02/zwischenstand/ Zitat aus dem Links: Letztlich kann sich die OSM-Community auch aus diesem Grund sicher sein, dass wir alles daran setzen werden, die Verbesserung der OSM-Karte mit aller Kraft zu unterstützen. In den Links ist ferner die Rede von fehlenden wichtigen Bestandteilen in den Karten, wo Skobbler OSM unterstützen möchte. Ich will hier - bezogen auf das Navigieren/Routen - zwei der wichtigsten Mängel in OSM darstellen: Ortsgrenzen in Deutschland: Für eine funktionierende Navigation (nach Adressen) sind die Grenzen der Ort(steil)e unverzichtbar. Bisher sind nur die Außengrenzen von kreisfreien Städten erfasst, welche aus einer freien Datenbank stammen. Bei einer Handvoll davon gibt es auch die Ortsteile. Bei fast allen anderen Städten und Gemeinden gibt es keine Außengrenzen und erst recht keine Ortsteilgrenzen in OSM. Es steht nicht in der Macht der Mapper, diese vor Ort zu erfassen. Hätte oder kennt Skobbler da Mittel und Wege, um diese zu beschaffen? durchzogene Mittellinie: Ferner gehen die Links auf die fehlenden Abbiegeverbote ein. Im selben Atemzug müsste man - bezogen auf das Navigieren/Routen - auch die durchgehende Mittellinie zählen, deren wirklichkeitsäquivalente Abbildung durch eine Relation möglich wäre, bei der sich ein Verbindungsknoten von Straßen explizit ein- und ausschließen ließe. Punkte von Relationen auszuschließen, ist aber in OSM bis dato nicht möglich. Die ersatzweise Darstellung einer durchgezogenen Mittellinie durch zwei getrennte Richtungsfahrbahnen (wie bei Autobahnen) würde nur die verkehrliche Funktion, nicht aber den tatsächlichen Straßenkörper äquivalent darstellen. Die Methode wird insbesondere in Großstädten praktiziert. Eine andere Ersatzdarstellung der durchgezogenen Mittellinie als eine Ansammlung von Linksabbiegeverboten und Umkehrverbot halte ich aus mehreren Gründen für untragbar: Eine durchgezogene Mittelinie verbietet das Überfahren. Das Umkehr- und Linksabbiegeverbot ist lediglich ein Resultat des Überfahrverbotes. Insofern ist das Abbiegeverbot nicht die wirklichkeitsäquivalente Darstellung der Mittellinie. Was diese Darstellung nun vollkommen disqualifiziert, ist die Tatsache, dass insbesondere bei gemappten Hauseinfahrten das Linksabbiegeverbot an jeder dieser zu wiederholen wäre. Das grenzt aber schon fast an Spam von Objekten, die dort nicht vorhanden sind. Denn in der Realität stehen dort keine Scharen von Linksabbiegeverboten. Diese Methode ist zudem für Otto Normalmapper nur schwer durchschaubar und verwirrend, insbesondere mit zunehmender Länge der durchgezogenen Mittellinie. Eine OSM Karte, in der eine durchgezogene Mittellinie genau dort eingezeichnet ist, wo sie sich befindet, ist die realitätskonformste Darstellung, die man sich vorstellen kann. Und ein Editor, der es ermöglicht, diese direkt in die Karte einzuzeichnen, wäre der Beste, den man sich dafür vorstellen könnte. Das funktioniert aber nur zusammen mit der oben genannten Relation, welche Straßenknoten explizit ausschließen kann. Der Ausschluß des Knotenpunktes erfolgt dann, wenn die durchgezogene Mittellinie an einer Kreuzung oder Abzweig unterbrochenen ist. Zur Darstellung der Unterbrechung in der OSM Karte wird die durchgezogenen Mittellinie im gesamten Überlappungsbereich der beteiligten Straßen(breiten) gelöscht. Wie gehabt, ist die Ausschlussfunktion von Punkten bei Relationen bisher nicht realisiert und müsste implementiert werden. Es bleibt dann die Sache von Skobbler, das Überfahren der durchgezogenen Mittellinie durch entsprechende Routenführung zu verhindern. Dazu gehört möglicherweise auch, ein dort befindliches Endziel bei der Schlussanfahrt von rechts anzufahren, damit man in die Hauseinfahrt einbiegen kann. In diesem (und auch anderem) Zusammenhang wäre es günstig, bei Autos das Umkehren auf einer Straße möglichst zu vermeiden - auch wenn es nicht verboten ist (Stichwort: Blockumfahrung). Zuletzt noch zu dem Punkt in den Links, wo es um die bessere Erfassung von Navigations/Routing- relevanten Infos in OSM: Hierzu wäre es sinnvoll, wenn ein Routing in die OSM Hauptseite - wie bei den kommerziellen Kartendiensten (z.B. Google, Map24) - integriert wäre. Denn dann würde eine maximale Anzahl von Usern diesen benutzen und die entsprechenden Mängel bemerken. Überhaupt wäre eine größere Anzahl von Karten auf der OSM Hauptseite sinnvoll. Noch besser wäre natürlich eine WMS-ähnliche, vom User konfigurierbare Karte, welche bestimmte Objektgruppen
Re: [Talk-de] Motivation zum Beheben von Bug-meldungen von kommerziellen Verwertern der OSM Daten?!?
addi...@gmx.net (Johann H. Addicks) wrote: Anyway, gebt den Nutzern die einfache Möglichkeit, Tracklogs zu fertigen und diese anonymisiert hochzuladen. Denn gerade in schwierigen Empfangslagen wird uns nur massiv mehr Tracks zu ROUTINGTECHNISCH nutzbaren Karten verhelfen. Denn was nützen uns toll gestylte Online Karten bei denen jede zweite Innenstadt-Kreuzung 25m daneben liegt. Der Fußgänger mit dem Kartenausdruck findet das toll, der Router jedoch nicht, wenn er sich beständig in Parallelstraßen wähnt. Ich weiß nicht genau, ob es stimmt: Laut c't wären zur Erfassung die speziellen GPS-Tracker den Handys und auch den iPhones klar vorzuziehen. Wenn das stimmt, so wäre der OSM Datenbank und sekundär natürlich auch Skobbler damit weniger geholfen. Vermutlich kann Skobbler das aufgrund umfangreicher Erfahrungen besser beurteilen und berichten, als jeder Andere. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
