[Talk-de] Gary68s Nachrichten
Hallo alle zusammen, anbei die (wöchentlichen) Nachrichten von Gary68... MotorwayCheck http://wiki.openstreetmap.org/wiki/MotorwayCheck Daten aktualisiert OSB Reports http://wiki.openstreetmap.org/wiki/OSB_Reports Daten aktualisiert. Bugs werden mehr, aber auch die je Woche gelösten. Osmdiff http://wiki.openstreetmap.org/wiki/Osmdiff_reports - Alle Berichte und Grafiken neu erstellt. - HESSEN monthly ist aktualisiert! SomeChecks (Area) http://wiki.openstreetmap.org/wiki/SomeChecks Alle Daten neu gerechnet Unmapped Places http://wiki.openstreetmap.org/wiki/Unkartografiert Fast alles neu gerechnet. Bekomme bei ganz großen Bundesländern langsam Speicherprobleme. Werde das angehen und auch gleich versuchen, neue Qualitätskriterien zu präsentieren. WayCheck http://wiki.openstreetmap.org/wiki/DE:WayCheck Einige ausgewählte Berichte sind aktualisiert. Wenn ich mitbekomme, dass jemand was arbeitet... Daher bitte immer im Wiki eintragen! Ciao und frohe Weihnachten weiterhin! Gerhard Gary68 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Worldfile vom 24. Dezember 2008 Xmas-Edition
Hallo, die neuen Daten liegen wie immer zum Download bereit unter: http://wiki.openstreetmap.org/wiki/User:Computerteddy Es fehlen noch ein paar Komplettpakete, aber man hat ja dieser Tage immer noch einiges zu tun -- Viele Grüße und ein Frohes Fest Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Am Mittwoch, 24. Dezember 2008 13:00:01 schrieb talk-de-requ...@openstreetmap.org: > On Tue, Dec 23, 2008 at 11:10:10PM +0100, Wolfgang Wienke wrote: > > Sascha Rogmann schrieb: > > > Beispiel: Radwege am Ring in M?nster. > > > > > > http://www.openstreetmap.org/?lat=51.972437&lon=7.633982&zoom=18&layers > > >=00B0FTF > > > > Endlich finde ich mal einen "Detail-Radwegmapper". Ich kenne nat?rlich > > nicht die Kreuzung in M?nster. Mapps Du so auch Radwege, die direkt auf > > dem B?rgersteig liegen und von diesem nur z.B. durch die Farbe getrennt > > sind? - Ich w?rde das f?r sinnvoll halten, sehe daf?r aber oft nur ein > > DAZUGESETZTES cycleway=track oder highway=path mit bicycle=yes. > > An gr??eren Stra?en, z.B. Durchgangsstra?en, mappe ich auch Radwege, > die auf dem B?rgersteig liegen, von diesem aber farblich getrennt sind. > Dort sind dann leichte Schlenker zu sehen wenn f?r ein kurzes St?ck > (z.B. 80m) der Radweg und der bisher nicht gemappte Fu?weg durch > eine Baumreihe getrennt sind. > > Beispiel: Lublinring in M?nster mit vielen GPS-Traces im JOSM. > Ein Baumreihenwechsel ist oben links (links vom WLAN-X). > > http://www.rogmann.org/osm/josm_lublinring.png > (JOSM-Ansicht zur oben angegebenen Beispiel-URL). > > Gru?, > Sascha Rogmann Also, ich weiß, diejenigen die meinen einen straßenbegleitenden Radweg als einen Extraweg anzulegen, meinen es gut! Aber ich denke das es in den meisten Fällen weit über das Ziel hinausschießt! Für den Mapper: Es macht viel extra Arbeit, in der Zeit könnte man die leeren Flächen füllen. Das würde einen größeren Nutzen haben! Und dann ist diese Arbeit durch kaum Nutzen zu rechtfertigen. Für das Kartenbild: In den meisten Fällen wird das Kartenbild nur unübersichtlich. Eine unübersichtliche Karte ist wieder schlecht nutzbar, kommerzielle Ersteller überlegen sich sehr gut, was sie in die Karte bringen und was nicht. Und zwar nicht, weil sie etwas verschweigen wollen oder zusätzlich teuer verkaufen (jedenfalls meistens) Fürs Routing mit Navigeräten: Der Routinganweisungen werden so kompliziert und folgen so schnell aufeinander das man das wiederum schlecht nutzen kann. Es ist günstiger der Radwegführung vor Ort zu folgen und die Routinganweisungen ein wenig simpler zu lassen, das ist in der Praxis hilfreicher. Übrigens geben Garmingeräte bei der Routenberachnung häufig auf, weil wir mit zuvielen Nodes und eben manchmal auch zuvielen Wegen arbeiten.. Das ist schade! Denn genau das wollen wir doch damit machen? Jeder, der vorhat, das so zu mappen, sollte sich das mal praktisch angucken und versuchen dies so zu nutzen. Inzwischen kann man das Routing mit Garmingeräten gut nachvollziehen. Es gab auch einen Workshop zu diesem Thema: http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel Das soll jetzt nicht bedeuten, das man das Vorhandensein eines Radweges nicht erfassen sollte! Das ist auf jeden Fall sinnvoll! Das läßt sich ja auch durch die vorhandenen tags gut machen. Siehe: http://wiki.openstreetmap.org/wiki/DE:Map_Features#Fahrradwege Übrigens ist das Radwegerouting noch so sehr unausgegoren, das man dort erstmal einen vernünftigen Konsens, besser eine Regelung, finden müßte um das sinnvoll machen zu können. Dazu gibt es auch Ansätze und interssante Gedanken: http://wiki.openstreetmap.org/wiki/DE:Bicycle/concept_routing Noch etwas: Wir versuchen immer die Wirklichkeit so genau wie möglich abzubilden. Das ist zwar löblich, aber am Ende ist wichtiger, das die Daten benutzbar sind und bleiben! Absolute Genauigkeit gibt es nicht! Dafür sind die Methoden und Geräte mit denen wir arbeite zu ungenau. Selbst wenn sie das Optimum erreichen verändern sich die Koordinaten laufend durch Kontinentaldrift. Das heißt sie müssen laufend gepflegt werden sonst veralten sie auch! (sehr langsam, aber immerhin) Radwege und ihre Verläufe haben sowieso eine noch geringere Halbwertzeit als das Straßennetz. Gleichzeitig sind sie häufig nicht benutzbar, z.B. wegen Bauvorhaben etc. Sehr vieles spricht dafür dies also so effizient und schlank wie möglich zu machen! Ebenso wie bei alles übrigen Daten! Dies sollte immer wieder vorher bedacht werden! Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gary68s Nachrichten
Danke Gerhard für deine tollen Tools. Unmapped placeses lasse ich jeden Tag beim erzeigen von neuen Garminkarten "mitlaufen". zu finden unter http://osm.flacus.de die Verzeichnisstruktur kann sich in den nächsten tagen da noch ändern. daher geben ich einfach nurmal das Grundverzeichnis an. Grüße Flacus Am 25. Dezember 2008 09:09 schrieb Gary68 : > Hallo alle zusammen, > > anbei die (wöchentlichen) Nachrichten von Gary68... > > > MotorwayCheck > http://wiki.openstreetmap.org/wiki/MotorwayCheck > Daten aktualisiert > > OSB Reports > http://wiki.openstreetmap.org/wiki/OSB_Reports > Daten aktualisiert. Bugs werden mehr, aber auch die je Woche gelösten. > > Osmdiff > http://wiki.openstreetmap.org/wiki/Osmdiff_reports > - Alle Berichte und Grafiken neu erstellt. > - HESSEN monthly ist aktualisiert! > > SomeChecks (Area) > http://wiki.openstreetmap.org/wiki/SomeChecks > Alle Daten neu gerechnet > > Unmapped Places > http://wiki.openstreetmap.org/wiki/Unkartografiert > Fast alles neu gerechnet. Bekomme bei ganz großen Bundesländern langsam > Speicherprobleme. Werde das angehen und auch gleich versuchen, neue > Qualitätskriterien zu präsentieren. > > > WayCheck > http://wiki.openstreetmap.org/wiki/DE:WayCheck > Einige ausgewählte Berichte sind aktualisiert. Wenn ich mitbekomme, dass > jemand was arbeitet... Daher bitte immer im Wiki eintragen! > > > Ciao und frohe Weihnachten weiterhin! > > Gerhard > Gary68 > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > -- Wikipedia -- http://tools.wikimedia.de/~flacus/IWLC/ OSM -- http://osm.flacus.de/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Am Donnerstag, 25. Dezember 2008 00:17:17 schrieb talk-de-requ...@openstreetmap.org: > >> Eine etwas vern?nftigere Datenstruktur und in einigen F?llen die > >> Vermeidung von Kopieroperationen w?rde hier Wunder wirken. > > > > W?re es dann nicht eine Idee, so etwas wie eine plattformunabh?ngig > > Dev-Group zu bilden, die sich um solche Probleme (Datenstrukturen, > > Algorithmen) Gedanken macht? Dann k?nnen Editor-Entwickler sich mehr > > auf das "Frontend" (und was sonst noch alles dazu geh?rt) > > konzentrieren und Leute, die viel von den ben?tigten Datenstrukturen > > und Algorithmen verstehen, k?nnen sich an der Basis einbringen und > > einen Dienst f?r jedwede Sprache leisten, ohne gleich einen > > alternativen Editor entwickeln zu m?ssen oder Java zu lernen. > > Eher nicht. Das Hauptproblem ist nicht das Design, sondern die > Implementierung. Ideen f?r bessere Strukturierung des JOSM-Codes habe ich > reichlich (immerhin programmiere ich schon ein paar Jahre), nur die > Umsetzung ist alles andere als trivial. > > Deswegen fangen viele Anf?nger auch lieber von vorn an. Das ist > erstmal einfacher. Keiner will sehen, dass wenn ein wenig Zeit vergangen > ist, das eigene tolle neue Projekt genau die gleichen Probleme hat, wie das > alte. Nur hat sich das alte in der Zwischenzeit weiterentwickelt. > > In JOSM z.B. hat sich (auch durch meinen Mithilfe :-) dieses Jahr einiges > getan. Permanent aufholen ist nicht so leicht wie mancher denkt. > > >> Statt st?ndig neuen Editoren w?ren Verbesserungen an JOSM viel > >> hilfreicher. Bis n?mlich der gleiche Funktionsumfang > >> nachprogrammiert ist, kann schon eine sehr lange Zeit vergehen. > >> Meist wird das Projekt vorher einschlafen. > > > > Ich pers?nlich f?nde einen Alternativeditor nicht schlecht, da ich mit > > JOSM ehrlich gesagt, einige Probleme habe. Die Einstiegsh?rde ist mir > > etwas zu hoch. Hier k?nnte sich wahrscheinlich ein zweites oder > > drittes Editor-Dev-Team komplett losgel?st von JOSM neue Gedanken > > machen, die dann nat?rlich auch bei Erfolg in JOSM einflie?en k?nnen. > > Momentan haben wir 3+1 Editoren (Potlatch, JOSM, Merkaartor und JOSM-NG). > Jetzt kommt noch einer dazu. Das sollte eine Weile reichen. Das Potential > an Softwareentwicklern ist nicht unendlich und je mehr man sich hier > zersplittert, desto schlechter sind die einzelnen Projekte. Andererseits > belebt Konkurrenz das Gesch?ft. Der richtige Mittelweg ist nicht so leicht > > :-) > > Nur so als Hinweis - Obwohl ich JOSM mitentwickle finde ich > 1) ein Java-Editor ist nicht der Weisheit letzter Schlu? > 2) die interne Struktur ist (teilweise stark) ?berarbeitungsbed?rftig > 3) eine Menge Designentscheidungen sind nicht optimal > > Nichtsdestotrotz bringe ich JOSM voran statt von vorn anzufangen. Wir > haben alle mehr davon. > > > Gebe ich dir recht. Ich rege mich nur immer extrem dar?ber auf, wenn > > so etwas in einer Mailing List aufkommt, da es, wie Hobby Navigator in > > seiner Mal schrieb, eine gewisse Frustschwelle gibt, an der ich > > bereits bei einem Projekt gescheitert bin. Daher bin ich > > Von Mails sollte man sich nicht abschrecken lassen. Unkonstruktives > einfach ignorieren, den Rest zumindest ?berdenken oder beherzigen. > > Ciao > -- > http://www.dstoecker.eu/ (PGP key available) Auf Dauer wäre ein Editor, der in ein gut funktionierendes Navi auf OSM Basis integriert ist, sehr wichtig! Das wäre eine Vision und ein Wunsch für die Zukunft von mir. Ich habe festgestellt es gibt noch mehr Leute hier die eine ähnliche Idee bereits hatten! So etwas sollte man entwickeln, denke ich. Effizienter und schneller kann man vor Ort Änderungen wohl nicht erfassen. Ich denke an Tomtom Mapshare als Anregung wie so etwas gehen und funktionieren könnte. Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 2. RFC für Internet Cafes
Stefan Hirschmann schrieb: > Wichtigste Sachen zusammen gefasst: > * Zusätzlich zum Tag wird auch der Namespace internet:access= erlaubt. Das halte ich für großen Blödsinn und extrem überflüssig. Meine Argumente dagegen: 1. OSM kennt keine Namespaces. Alle Keywerte müssen OSM-global unique sein, die Datenbank und die API interessieren sich absolut nicht für den Doppelpunkt innen drin, und selbst wenn der Doppelpunkt in XML als Zeichen für Namespace-Trennung verwendet wird, so gilt dies nicht für die aus OSM exportierbaren XML-Dateien, weil der Key dort ein Attributwert ist, kein Tag-Name. 2. Es ist ebenso unsinnig, für einunddasselbe ZWEI Keys zu erfinden. Das bürdet den Mappern auf, sich für eines von beiden zu entscheiden (welches nimmt man schlauerweise?), und den Renderern das Verarbeiten von zwei Regeln zum Malen der optischen Erscheinung beider Varianten. Und da ich im Moment auch nicht erkennen kann, dass sich für den ersten Wortbestandteil "internet" so wahnsinnig viele weitere Nutzungen aufdrängen, sehe ich nicht ein, warum "internet:access" ein sinnvoller Key sein sollte. Sollte es Dinge wie "internet:backbone", "internet:CIX" oder "internet:satlink" irgendwann wirklich geben, würde es diese Dinge auch als "data_wire", "internet:infrastructure=CIX, operator..." oder "building=satellite_uplink" geben können - je nachdem, was zu dem Zeitpunkt dann der jeweilige Stand der Diskussion und Tag-Entwicklung ist. Wenn das Namespace-Argument schon irgendwie ziehen soll, dann wäre das allerhöchstens für die sich eventuell andeutenden Extrainformationen zu "internet_access", also z.B. "internet_access:price" oder "internet_access:speed". Da will man nämlich keine doppelten Doppelpunkte haben. > * Es werden versch. Arten des Internets unterschieden. Ich frage mich, warum es "internet_access=service" gibt. Warum nicht "internet_access=public". Ich würde allerdings vorschlagen, einfach mal Bilder von Beispielen zu sammeln. Je mehr Beispiele es gibt, desto klarer wird das Bild, wie unterschiedlich auf der Welt Internetzugänge aussehen können, und dann kann man anhand der Bilder auch gleich Beispieltagging demonstrieren, sollte das Proposal einmal akzeptiert werden. > * Internet_access berücksicht keine Kosten, aber durch Namespace > internet: möglich, allgemeine Tags für Internet zu spezifizieren. Ja, ich bin sehr dafür, keine Preise zu taggen, allenfalls die Information, ob ein Angebot kostenlos ist oder nicht. > * Wichtig: Internet_access ist ein Zusatzattribut. D.h. ein Internet > Cafe wird als > amenity=cafe > internet_access=terminal > getaggt. Es gibt in OSM keine "Zusatzattribute", nur Attribute, also "Hauptattribute". Das Proposal muss also damit klarkommen, dass es auch alleinstehend funktioniert. Deshalb sollte besser schon jetzt daran gegangen werden, die Argumentation so auszurichten, dass dieses Tag sich ausschließlich darauf konzentriert, das Vorhandensein des Internetzugangs zu dokumentieren, unabhängig von möglichen weiteren Eigenschaften des Ortes, die sich in anderen Tags widerspiegeln. So wie man nicht "highway=private_residential" taggt, sondern "highway=residential, access=private", um sich das Erfinden von hundert Kombinationsstraßentypen zu sparen, so zielt dieses Tag eben auf den Internetzugang ab. Egal ob es nun "amenity", "shop" oder gar nichts Zusätzliches an dem Ort gibt. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
Melchior Moos schrieb: > 2008/12/22 Johann H. Addicks > >> Im Irc erreichte mich die Frage, von wem das ÖPNV-Layer ist, was unter >> http://81.89.97.206/oepv.html >> abrufbar ist. >> > > Meine Wenigkeit... Schöne Sache. Verbesserungsvorschlag: Setze auf die Seite noch einen Link zu einer Wikiseite, in der beschrieben wird, wie die Relationen zu taggen sind, die du da farblich hervorhebst. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Nick ohne Realnamen
Hatto von Hatzfeld schrieb: > Simon Kokolakis wrote: > >> Man muss ja nicht zwangsläufig seinen echten Namen benutzen, sondern von >> mir aus auch einen erfundenen Realnamen. Für die Leser ist es nicht >> wichtig ob hinter dem Namen wirklich die exakte Person steckt oder >> nicht. Hautsache man ist mit dem Namen immer zu identifizieren. > > Das ist auch der wichtige Unterschied zwischen Nicknames und Pseudonymen. > Wer in einem Realnamen-Umfeld (darauf kommt es an!) nämlich Nicknames > nutzt, der signalisiert, dass er sich verstecken will und nicht > identifiziert werden möchte. Wer ein Pseudonym verwendet, der ist zwar auch > nicht leichter mit seinem Realnamen zu identifizieren, aber er gibt kein > entsprechendes Signal. Mit einem Pseudonym hat man sozusagen ein anderes > Gesicht, mit einem Nickname eher eine Maske. Sorry, aber diese Gedankengänge kann ich absolut nicht nachvollziehen, und ich plädiere dafür, lieber mal eine etwas offenere eigene Geisteshaltung zu probieren, anstatt dieses tote Pferd noch weiter zu reiten. Ein Nickname ist nichts Böses, Abstoßendes oder zu Verurteilendes. Es ist ein Künstlername, wie es ihn in der realen Welt schon seit vielen Jahrzehnten gibt - vielleicht nur mit mehr Sonderzeichen. Als Erinnerung: "Heino" und "Atze Schröder" sind beides keine Realnamen, sondern erfunden mit der Motivation, noch deutlicher erkennbar zu sein, unverwechselbar zu werden. Und genau so sollte man auch Nicknames sehen, die im Internet verwendet werden. In jedem Kulturkreis (z.B. dieser Mailingliste) ist der Nickname der unverwechselbare Identifikator einer Person. Alle Argumente hinsichtlich "der will sich verstecken", "der hat nur böses im Sinn", "der wechselt seinen Namen einfach schnell, wenn er dumm aufgefallen ist" sind vollkommen absurd, weil das kein Alleinstellungsmerkmal von Nicknames ist, sondern für alle Namen zutrifft. Ich sehe es so: Nicknames sind der Default, dass ein Nickname tatsächlich dem bürgerlichen Namen entspricht, ist eher der Sonderfall - zur Bewertung der Aktionen und Aussagen einer Person ziehe ich aber primär die Aktionen und Aussagen heran, nicht den Nickname. Natürlich spiegelt der Nickname immer auch eine gewisse Selbsteinstellung wider. "l33tOSMhax0r" provoziert Vorurteile. Aber erst wenn diese Person durch entsprechende Äußerungen bestätigt, was man vorher nur vermuten kann, wäre eine entsprechende Einschätzung gerechtfertigt. > Letzteres aktiviert naturgemäß > Vorbehalte bei Kommunikationspartnern, die keine Maske bzw. keinen Nickname > tragen. Nicht das Tragen eines anderen Namens erregt Aggression, sondern > die (- wie gesagt - in einem Realnamen-Umfeld so zu verstehende) Botschaft, > dass man nicht identifiziert werden und dementsprechend nicht mit seiner > ganzen Person zu seinen Äußerungen stehen will. Die Frage ist doch: Warum werden Realnamenträger aggressiv? Ärger über die verpasste Chance, sich mit einem Nickname deutlicher zu individualisieren? Ich habe übrigens bei etlichen Namen dieser Mailingliste die Vermutung, dass es sich nicht um Realnamen handelt. "Hatto von Hatzfeld" gehört dazu. Aber das ist mir auch vollkommen egal, weil ich den Namen als Identifikation einer Person verwende (gleicher Name == gleiche Person), aber nicht als Inhaltsfilter und Vorverurteilungsindikator. Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo, >Für den Mapper: Es macht viel extra Arbeit, in der Zeit könnte man die >leeren Flächen füllen. >Für das Kartenbild: In den meisten Fällen wird das Kartenbild nur >unübersichtlich. das läßt sich auch kombinieren, wenn ein Bereich zu unübersichtlich ist weiger ich mich dort zusätzliches zu mappen. Man sollte sich wenn es 2 Möglichkeiten gibt etwas zu mappen überlegen wie ihr Informationsgehalt ist und wie der Aufwand ist. Das häufigste Argument für einzeln gemappte Fahrradwege ist: "der ist baulich getrennt" aber was steht da in den Map_Features: ycleway track Ein baulich abgesetzter Radweg (cycle track), z.B. durch einen Bordstein, der meist neben der Fahrbahn verläuft. Also hat ein parallel neben der Straße verlaufender Fahrradweg keinen zusätzlichen Informationsgehalt zu cycleway=track, vorallem wenn er einfach nach Augenmaß eingezeichnet wurde statt ihn wirklich zu mappen. Zusätzliche Information würde man erst erhalten wenn man den genauen Verlauf eintragen würde, interessant würde dies aber erst wenn zwischen Straße und Fahrradweg mehrere Meter Abstand sind. Eine andere Zusatzinfo wäre, wenn man jede Verbindung zwischen Straße und Fahrradweg einzeichnen würde. Ob dies nützlich wäre sei dahingestellt. Aber diese Mühe machen sich die wenigsten. Es müßte dann jede Bordsteinabsenkung eingetragen werden, und auch jedes zusätzliche Hindernis, also z.B. ein zusätzlicher Grünstreifen. Oder auch ob zwischen Fahrradweg und Straße ein Parkstreifen ist. Vor allem aber muß gewährleistet werden, daß diese zusätzlichen Wege mit der Straße über Relations o.ä. verbunden werden. Sonst sind sie wie schon oft berichtet wurde eher verwirrend für Router u.ä.. Und das ganze muß irgendwie so von Josm/Potlach unterstützt werden, daß es nicht zu zu vielen Fehlern führt. Die meisten Fehler die ich so in den Daten finde hängen mit komplexen Straßen zusammen. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
On Thu, Dec 25, 2008 at 12:12:14PM +0100, Sven Rautenberg wrote: > Melchior Moos schrieb: > > 2008/12/22 Johann H. Addicks > > > >> Im Irc erreichte mich die Frage, von wem das ÖPNV-Layer ist, was unter > >> http://81.89.97.206/oepv.html > >> abrufbar ist. > >> > > > > Meine Wenigkeit... > > Schöne Sache. > > Verbesserungsvorschlag: Setze auf die Seite noch einen Link zu einer > Wikiseite, in der beschrieben wird, wie die Relationen zu taggen sind, > die du da farblich hervorhebst. Das Datum des letzten updates waere auch super - Ich habe versucht eine BUS route relation zu bauen und die wird nicht gerendert - Im moment rate ich ob ich zu bloede bin oder das einfach nur daran liegt das seit ein paar tagen das nicht geupdated wurde ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] 2. RFC für Internet Cafes
Am Donnerstag 25 Dezember 2008 schrieb Sven Rautenberg: > Stefan Hirschmann schrieb: > > Wichtigste Sachen zusammen gefasst: > > * Zusätzlich zum Tag wird auch der Namespace internet:access= erlaubt. > > Das halte ich für großen Blödsinn und extrem überflüssig. > > Meine Argumente dagegen: > 1. OSM kennt keine Namespaces. Alle Keywerte müssen OSM-global unique > sein, die Datenbank und die API interessieren sich absolut nicht für den > Doppelpunkt innen drin, und selbst wenn der Doppelpunkt in XML als > Zeichen für Namespace-Trennung verwendet wird, so gilt dies nicht für > die aus OSM exportierbaren XML-Dateien, weil der Key dort ein > Attributwert ist, kein Tag-Name. > osm kennt viele dinge nicht, die sinnvoll waeren, vielleicht weil es auch bewusst einfach und flexibel gehalten ist. das heisst aber noch lange nicht, dass man sowas wie z.B. namespaces nicht verwenden kann. auch wenn es datenbank und api nicht kann - anwendungen, die diese daten nutzen, koennen das sehr wohl auswerten. ausserdem wird auch die api weiterentwickelt, um dinge zu unterstuetzen, die es vorher nicht gab. > 2. Es ist ebenso unsinnig, für einunddasselbe ZWEI Keys zu erfinden. Das > bürdet den Mappern auf, sich für eines von beiden zu entscheiden > (welches nimmt man schlauerweise?), und den Renderern das Verarbeiten > von zwei Regeln zum Malen der optischen Erscheinung beider Varianten. > das mag unsinnig sein, passiert aber. ausserdem kann es ja durchaus sein, dass etwas neues einfach aus verschiedenen gruenden besser passt oder funktioniert, als etwas bereits verwendetes... > Und da ich im Moment auch nicht erkennen kann, dass sich für den ersten > Wortbestandteil "internet" so wahnsinnig viele weitere Nutzungen > aufdrängen, sehe ich nicht ein, warum "internet:access" ein sinnvoller > Key sein sollte. Sollte es Dinge wie "internet:backbone", "internet:CIX" > oder "internet:satlink" irgendwann wirklich geben, würde es diese Dinge > auch als "data_wire", "internet:infrastructure=CIX, operator..." oder > "building=satellite_uplink" geben können - je nachdem, was zu dem > Zeitpunkt dann der jeweilige Stand der Diskussion und Tag-Entwicklung ist. > du gibst selbst bereits moegliche nutzungen an, kannst dir solche aber nicht vorstellen? seltsam... > Wenn das Namespace-Argument schon irgendwie ziehen soll, dann wäre das > allerhöchstens für die sich eventuell andeutenden Extrainformationen zu > "internet_access", also z.B. "internet_access:price" oder > "internet_access:speed". daher kommts ja auch urspruenglich... > Da will man nämlich keine doppelten > Doppelpunkte haben. > wie meinen? > > * Es werden versch. Arten des Internets unterschieden. > > Ich frage mich, warum es "internet_access=service" gibt. Warum nicht > "internet_access=public". > lies, was auf der wiki seite steht, dann sollte das klar sein. > Ich würde allerdings vorschlagen, einfach mal Bilder von Beispielen zu > sammeln. Je mehr Beispiele es gibt, desto klarer wird das Bild, wie > unterschiedlich auf der Welt Internetzugänge aussehen können, und dann > kann man anhand der Bilder auch gleich Beispieltagging demonstrieren, > sollte das Proposal einmal akzeptiert werden. > klingt gut. wobei das bei internetzugaengen mit fotos zum teil nicht so einfach ist... > > * Internet_access berücksicht keine Kosten, aber durch Namespace > > internet: möglich, allgemeine Tags für Internet zu spezifizieren. > > Ja, ich bin sehr dafür, keine Preise zu taggen, allenfalls die > Information, ob ein Angebot kostenlos ist oder nicht. > das ist wieder so eine osm-sache... wer haelt was fuer sinnvoll? ein mindest-tagging ob kostenlos oder nicht halte ich auf alle faelle fuer wertvoll. wenn jemand einen sinn darin sieht, exakte preise einzutragen, sollte man ihn nicht davon abhalten. > > * Wichtig: Internet_access ist ein Zusatzattribut. D.h. ein Internet > > Cafe wird als > > amenity=cafe > > internet_access=terminal > > getaggt. > > Es gibt in OSM keine "Zusatzattribute", nur Attribute, also > "Hauptattribute". Das Proposal muss also damit klarkommen, dass es auch > alleinstehend funktioniert. > aus anwendungssicht gibt es diese unterscheidung sehr wohl! dass sich in der datenbank alles auf derselben ebene abspielt, ist schon klar. aber nimm doch mal das beispiel strassen: da ist es doch allgemeiner konsens, dass "highway" als haupt- und alles andere als nebenattribut gesehen wird. oder etwa nicht? > Deshalb sollte besser schon jetzt daran gegangen werden, die > Argumentation so auszurichten, dass dieses Tag sich ausschließlich > darauf konzentriert, das Vorhandensein des Internetzugangs zu > dokumentieren, unabhängig von möglichen weiteren Eigenschaften des > Ortes, die sich in anderen Tags widerspiegeln. > genau darum geht's ja. niemand hat bisher was anderes behauptet. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreet
Re: [Talk-de] Tagging von Gewässern
Das sehe ich anders, wir taggen ja nicht nur um damit einen 2D-Karten-Renderer zu füttern. Die Summe der gemappten Daten sollte viel mehr als eine geographische Datenbank bilden, deren Daten in vielerlei Hinsicht visuell aufbereitet werden können. Ansonsten können wir ja auch folgendermaßen taggen area="blue" Gruß Sven Andreas Labres schrieb: > Sven Geggus wrote: > >> Diese Objekte sind ja vieles, aber ganz >> bestimmt nicht "natural". >> > > Die Diskussion hamma doch ständig und irgendwie isses müßig... > > Wasser is Wasser und immer "natural". Wie die Ansammlung von Wasser > zustandekommt, ist doch in erster Linie irrelevant. Relevant ist für den > Renderer, daß er da "Blau" hinpappt, und für den Router (zumindest für die > Straßen/Wege-gebundenen), daß es ein Hindernis ist. > > Wenn's dann Bauwerke gibt, die am Zustandekommen dieser Wasseransammlung > beteiligt sind (Dämme oder sowas...), dann bin ich dafür, die zu mappen und zu > taggen und den Renderern beizubringen, das anzuzeigen. > > Aber die blaue Fläche ist blaue Fläche (blau im Sinne von Wasser und Fläche im > Sinne von "da ist oberflächlich kein "Land"). Und dann vielleicht noch die > Tiefe. > > Servus, Andreas > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Dimitri Junker schrieb: > Hallo, > > >> Für den Mapper: Es macht viel extra Arbeit, in der Zeit könnte man die >> leeren Flächen füllen. >> Für das Kartenbild: In den meisten Fällen wird das Kartenbild nur >> unübersichtlich. > > das läßt sich auch kombinieren, wenn ein Bereich zu unübersichtlich ist > weiger ich mich dort zusätzliches zu mappen. > Man sollte sich wenn es 2 Möglichkeiten gibt etwas zu mappen überlegen > wie ihr Informationsgehalt ist und wie der Aufwand ist. > Das häufigste Argument für einzeln gemappte Fahrradwege ist: "der ist > baulich getrennt" aber was steht da in den Map_Features: > yclewaytrack Ein baulich abgesetzter Radweg (cycle track), > z.B. > durch einen Bordstein, der meist neben der Fahrbahn verläuft. > Kommt drauf an was man mit "baulich getrennt" genau meint. Ich verstehe darunter nicht nur einen etwas abgesetzten Radweg mit Bordstein, sondern eine tatsächliche Trennung. Sobald man nämlich über eine Mauer klettern oder mehrere Meter durch Wiese stapfen muss, kann man nicht mehr so einfach überall auf die Straße wechseln. Da ergibt es von der Bedeutung her schon Sinn einen extra Weg einzuzeichnen. Wenn der Radweg nur abgesetzt ist, reicht auch das entsprechende Tagging der Straße. Das könnte dann auch entsprechend gerendert werden, z.B. durch veränderte Ränder der Straße (fett, farbig, was auch immer). So würde man auch direkt den Unterschied zwischen "baulich getrennt" und "baulich abgesetzt" sehen und wüsste ob man hier die Straße problemlos überqueren kann (sofern es der Verkehr zulässt natürlich). Ansonsten weiß man nie ob man einen Zaun oder nur ein paar Zentimeter Bordstein überwinden muss. Sicherlich könnte man sowas auch mit Relationen lösen, die die Beziehung zwischen den einzelnen Wege beschreiben, aber das dürfte höchstens für wirklich komplexe Fälle notwendig sein. In sehr vielen Fällen dürfte sich das mit maximal einer Handvoll Tags beschreiben lassen. Ob ein Weg ein paar Meter einen Schlenker macht, dürfte in der Praxis kaum einen Unterschied machen. Wenn der Schlenker weiter von der Straße wegführt, liegt vermutlich sowieso wieder eine bauliche Trennung vor. Liegt der Schlenker an einer großen Kreuzung oder sowas (also bedingt durch breitere Straße), müsste eben die Straße entsprechend breiter gerendert werden, wenn man solche Details möchte. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
Sven Rautenberg schrieb: > Melchior Moos schrieb: >> 2008/12/22 Johann H. Addicks >> >>> Im Irc erreichte mich die Frage, von wem das ÖPNV-Layer ist, was unter >>> http://81.89.97.206/oepv.html >>> abrufbar ist. >>> >> Meine Wenigkeit... > > Schöne Sache. > > Verbesserungsvorschlag: Setze auf die Seite noch einen Link zu einer > Wikiseite, in der beschrieben wird, wie die Relationen zu taggen sind, > die du da farblich hervorhebst. > Fände ich auch Nett. Das beste was ich finden konnte war: http://wiki.openstreetmap.org/wiki/Relation:route Damit "bewaffnet" hab ich am 22.12. die drei U-Bahnlinien von Nürnberg als Relations (#60.012, #60.016, #60.017) getaggt, und zwar mit: type=route route=subway ref=U1 (bzw. U2 / U3) und dazu jeweils die einzelnen ways als "unbenamste" Mitglieder. Hab gerade mal unter: http://81.89.97.206/oepv.html?lat=49.4514&lon=11.0753&zoom=13 geschaut. Die U-Bahn taucht noch nicht auf - ne Idee warum? Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo, >Sobald man nämlich über eine Mauer klettern oder mehrere Meter durch >Wiese stapfen muss, kann man nicht mehr so einfach überall auf die >Straße wechseln. Da ergibt es von der Bedeutung her schon Sinn einen >extra Weg einzuzeichnen. Da sind wir uns einig, nur ich beobachte da anderes, es werden extra Fahrradwege gezeichnet die genau dem entsprechen wofür cycleway=track gedacht ist. >Sicherlich könnte man sowas auch mit Relationen lösen, die die Beziehung >zwischen den einzelnen Wege beschreiben, aber das dürfte höchstens für >wirklich komplexe Fälle notwendig sein. Relations sind meiner Meinung nach immer notwendig wenn man mehrere Wege für eine Straße zeichnet. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Dimitri Junker [Thu, Dec 25, 2008 at 03:29:52PM CET]: [...] > > Da sind wir uns einig, nur ich beobachte da anderes, es werden extra > Fahrradwege gezeichnet die genau dem entsprechen wofür cycleway=track > gedacht ist. Ich mache das überall dort so, wo die Radwege einseitig angelegt sind, und verbinde diese auch mit (auch gegenüber) abzweigenden Wegen. Damit bleibt die Information erhalten, die mit cycleway=track verloren ginge, und die vielen Radlern wichtig ist. -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi") ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo! Johannes Huesing schrieb: > Dimitri Junker [Thu, Dec 25, 2008 at 03:29:52PM CET]: > [...] > >>Da sind wir uns einig, nur ich beobachte da anderes, es werden extra >>Fahrradwege gezeichnet die genau dem entsprechen wofür cycleway=track >>gedacht ist. > Der größte Nachteil dieser Methode ist nun mal, dass ich unterschiedliche Verhältnisse auf beiden Seiten der Straße nicht abbilden kann, und die sind für den Radfahrer sehr wichtig. All das hier geschriebene spricht eigentlich nur dafür, dass die Mappingregeln in diesem Bereich DRINGEND grundlegend geklärt und mehr festglegt werden sollten. Es ist sehr frustrierend, wenn man sich in diesem Bereich z.B. durch Abfahren der Wege mit GPS Mühe gibt und dann hört "die Wahrheit ist zu kompliziert, können wir nicht darstellen" (ein Radweg-Rendrer müßte es natürlich können). Ob ein Radweg ein Track auf dem Bürgersteig oder eine lane auf der Straße ist, ist für unsichere, ältere Radfahrer sehr entscheidend. Dann müßte man ehrlicherweise sagen: Eine Radfahrkarte (speziell im städtischen Breich) werden wir niemals hinbekommen. -- Mit freundlichen Gruessen Wolfgang Wienke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] TMC
Hallo. Halbwegs off-topic, aber ich hoffe mal, jemand weiß dazu etwas... Wenn ich mir jetzt ein einfaches Garmin-Navi mit TMC-unterstützung kaufe, besteht dann die chance (jetzt oder irgendwann), dass diese TMC-Infos korrekt auf die Straßenabschnitte projeziert werden? Ich stelle mir das mit den aktuellen Daten halbwegs unmöglich vor, da ich nicht glauben mag, dass die TMC-Daten Freitext a la "A8 zwischen Kreuz Stuttgart und Dreieck Leonberg" enthalten sondern ich würde erwarten, dass es da irgendwie um Abschnittsnummern geht, die wir bisher so nicht erfasst haben. Ist das System dokumentiert und nutzbar, so dass man die OSM-Garmin-Karten theoretisch daraufhin anpassen kann? Oder tut das alles jetzt schon? Oder ist das alles prorietär, keiner weiß was davonund man kann sich die Mehrkosten erstmal sparen sofern man nur OSM-Karten nutzen will? ;-) Gruß, Bernd -- Das war das Schlaueste was ich je gesagt habe, und niemand hat es gehört. Nen! - Homer, Die Simpsons signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
On Thu, 2008-12-25 18:23:24 +0100, Bernd Wurst wrote: > Wenn ich mir jetzt ein einfaches Garmin-Navi mit TMC-unterstützung kaufe, > besteht dann die chance (jetzt oder irgendwann), dass diese TMC-Infos korrekt > auf die Straßenabschnitte projeziert werden? Vorerst nicht. > Ich stelle mir das mit den aktuellen Daten halbwegs unmöglich vor, da ich > nicht glauben mag, dass die TMC-Daten Freitext a la "A8 zwischen Kreuz > Stuttgart und Dreieck Leonberg" enthalten sondern ich würde erwarten, dass > es > da irgendwie um Abschnittsnummern geht, die wir bisher so nicht erfasst haben. Nee, das läuft anders... > Ist das System dokumentiert und nutzbar, so dass man die OSM-Garmin-Karten > theoretisch daraufhin anpassen kann? Oder tut das alles jetzt schon? > Oder ist das alles prorietär, keiner weiß was davonund man kann sich die > Mehrkosten erstmal sparen sofern man nur OSM-Karten nutzen will? ;-) Dokumentiert ist das, nutzbar eher nicht. TMC wird digital im Radio mitgesendet; mit passenden Radio-Empfängern kann man die ganzen digitalen Daten sogar unter Linux abgreifen. Speziel bei TMC wird nur mitgeteilt, daß zwischen Punkt A und Punkt B ein Ereignis XYZ (-> klassifiziert) ist. "A" und "B" sind 16bittige Integer-Werte, die mittels einer Tabelle auf den realen Straßenpunkt abgebildet werden müssen. Das Problem ist, an diese Tabelle heranzukommen. Florian Lohoff hat da mal hinterhergegraben: Die wird von einer Behörde gepflegt, die Daten dürfen aber nicht weitergegeben werden, wenn man von denen bekommt. Damit können die wohl nicht in die OSM-Datenbank einfließen. "Angriffe" gegen dieses Szenario wäre, die TMC-Daten mitzuprotokollieren und Verkehrsfunk zu hören. Solange, bis man aus den unterschiedlichen Kombinationen herausbekommen hat, wofür welche Zahl steht... MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: What we do for ourselves dies with us. What we do for the second : others and the world remains and is immortal. (Albert Pine) signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Bernd Wurst wrote: > Hallo. > > Halbwegs off-topic, aber ich hoffe mal, jemand weiß dazu etwas... > > Wenn ich mir jetzt ein einfaches Garmin-Navi mit TMC-unterstützung kaufe, > besteht dann die chance (jetzt oder irgendwann), dass diese TMC-Infos korrekt > auf die Straßenabschnitte projeziert werden? > > Ich stelle mir das mit den aktuellen Daten halbwegs unmöglich vor, da ich > nicht glauben mag, dass die TMC-Daten Freitext a la "A8 zwischen Kreuz > Stuttgart und Dreieck Leonberg" enthalten sondern ich würde erwarten, dass > es > da irgendwie um Abschnittsnummern geht, die wir bisher so nicht erfasst haben. > > Ist das System dokumentiert und nutzbar, so dass man die OSM-Garmin-Karten > theoretisch daraufhin anpassen kann? Oder tut das alles jetzt schon? > Oder ist das alles prorietär, keiner weiß was davonund man kann sich die > Mehrkosten erstmal sparen sofern man nur OSM-Karten nutzen will? ;-) Hi, ich habe mal ausführliche Infos dazu in den Händen gehabt. Hab zuletzt für jemand anders auf dieser Liste schon mal danach geforscht (aber meine Unterlagen bisher noch nicht wiedergefunden). Was ich weiss ist, daß alle Zustände sowie auch Abschnitte etc. numerisch kodiert sind. Es gibt eine "Location-List". Es könnte also ggf. sinnvoll sein hier eine Zuordnung zu schaffen bzw. für einzelne Abschnitte die Zuordnung ggf. direkt in die OSM-Daten aufzunehmen. Och Mensch ... wo hab ich die Sachen nur ... Zentraler Kontakt für einen Dienst den wir damals angedacht hatten war die Polizei NRW (ich glaube in Düsseldorf), die auch zentral eine Schnittstelle anbieten über die die Verkehrsinfos zu beziehen wären ... übrigens kostenlos und per TCP als Feed. PS: Was der WDR aussendet sind nochmal etwas aufbereitete Infos, die arbeiten auch noch mit dem ADAC sowie ihren eigenen Staumeldern zusammen und ergänzen. Grüße, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Hallo, Die TMC-Daten für Deutschland erfasst und verwaltet die BAST. Dort bekommt man wohl auch -unter Angabe eines guten Grundes- die nötigen Infos und Daten. Übertragen wird bei TMC nur der sog. location-code, der angibt, wo eine Störung beginnt und auf wie viele Abschnitte er sich erstreckt. Weiterhin wird ein event-code übertragen, der angibt, was los ist. Die Eventliste findet man im Internet auch. Die location-codes werden eben von der BAST vergeben und definieren "wichtige" Abschnitte. Also z.B. bei einer Autobahn normalerweise die Strecke zwischen zwei Ausfahrten oder auch ein Tunnel. Es gibt auch codes für Bundes und Landstraßen und wichtige andere Straßen (teilweise auch innerorts). Die "locations" sind aber auch in der Liste mit Koordinaten hinterlegt, so dass man sie auf einer Karte anzeigen könnte. Gruß, Stefan Bernd Wurst schrieb: > Hallo. > > Halbwegs off-topic, aber ich hoffe mal, jemand weiß dazu etwas... > > Wenn ich mir jetzt ein einfaches Garmin-Navi mit TMC-unterstützung kaufe, > besteht dann die chance (jetzt oder irgendwann), dass diese TMC-Infos korrekt > auf die Straßenabschnitte projeziert werden? > > Ich stelle mir das mit den aktuellen Daten halbwegs unmöglich vor, da ich > nicht glauben mag, dass die TMC-Daten Freitext a la "A8 zwischen Kreuz > Stuttgart und Dreieck Leonberg" enthalten sondern ich würde erwarten, dass > es > da irgendwie um Abschnittsnummern geht, die wir bisher so nicht erfasst haben. > > Ist das System dokumentiert und nutzbar, so dass man die OSM-Garmin-Karten > theoretisch daraufhin anpassen kann? Oder tut das alles jetzt schon? > Oder ist das alles prorietär, keiner weiß was davonund man kann sich die > Mehrkosten erstmal sparen sofern man nur OSM-Karten nutzen will? ;-) > > Gruß, Bernd > > > > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
Ich denke mal, nach den Feiertagen wird sich MM zu Wort melden. Derzeit scheint sich auf jeden Fall rendermäßig nichts zu tun. Kann eigentlich jemand bestätigen, dass ab Zoom 14 gar nichts mehr angezeigt wird? Ich sehe nur grau... Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Stefan Dettenhofer (StefanDausR) schrieb: > Hallo, > > Die TMC-Daten für Deutschland erfasst und verwaltet die BAST. Dort > bekommt man wohl auch -unter Angabe eines guten Grundes- die nötigen > Infos und Daten. > > Die letzten Diskussionen über TMC für OSM liegen ja inzwischen schon eine Weile zurück.. Inzwischen ist OSM ja schon einiges bekannter und vollständiger geworden. Wäre doch ein Versuch wert sich mal wieder an die BAST zu wenden ob die nicht vielleicht doch ihren Beitrag zu OSM leisten wollen. Inzwischen kann ja auch schon daran gedacht werden ein ein eigenes OSM-"TMC" aufzubauen- Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
On Thu, Dec 25, 2008 at 07:43:02PM +0100, DarkAngel wrote: > Subject: Re: [Talk-de] ÖPNV-Layer > > Ich denke mal, nach den Feiertagen wird sich MM zu Wort melden. Derzeit > scheint sich auf jeden Fall rendermäßig nichts zu tun. > > Kann eigentlich jemand bestätigen, dass ab Zoom 14 gar nichts mehr > angezeigt wird? Ich sehe nur grau... Das meine ich ist works-as-designed - ich denke eine super weiterentwicklung waere wenn man dem OpenLayers kram das abgewoehnt das man ueberhaupt weiter als z14 zoomen kann :) Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Moin, > Kann eigentlich jemand bestätigen, dass ab Zoom 14 gar nichts mehr > angezeigt wird? Ich sehe nur grau... Kann ich bestätigen. Ich habe bei mir in der Gegend testweise eine Busroute eingetragen, mal abwarten wann und wie sie gerendert wird. Gruß Patrick - -- E-Mail: patrick.kol...@web.de Jabber: patrick.kol...@jabbermx.org GnuPG: 0xB8C38BA3 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFJU+Iqj2Ju6rjDi6MRAq6jAKCR3YAYxeG3QyuENyEpVOaFKQrhgQCgsAKS CmOKV3M8rRhWeIqT7tWAzSc= =oMSN -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Benutzung von is_in
Guten Tag,
ich bin Gerhard, bin neu hier auf dieser Liste.
Ich bin Deutscher, lebe seit etwa 25 Jahren in Frankreich,
derzeit in Sudfrankreich etwa 60 km nord-westlich von Montpellier,
und beteilige mich gelegentlich an OSM hier in Frankreich.
Bei uns hier ist die Frage aufgetaucht,
wie man die Sache mit Gemeinde-Teilen und Gemeinde-Zusammenlegungen
tagggen könnte/sollte/müsste,
damit wir das relatif einheitlich, und von Rechnern auswertbar,
zusammenstupfeln.
Und wo ich Deutscher bin,
und in Deutschland viele derartige Zusammenschlüsse existieren,
hat man mich angestiefelt um nachzuforschen, wie Ihr das macht...
Ich bitte Euch um Hilfe oder Rat, wie Ihr das seht.
Sowas mit "relations" zu machen, gefällt uns derzeit nicht besonders,
das System ist noch nicht klar,
und auch die Renderers verarbeiten das nocht nicht.
Im Archiv Talk-de bin ich auf den Thread "is_in" gestossen, sowie auf
die Seite http://wiki.openstreetmap.org/wiki/Hierarchy_of_places,
das hilft uns aber nicht weiter :-(
---
Wenn ich die OSM-Karte Deutschland ansehe, und das Data-Layer
drüberlege,
finde ich unterschiedliche Vorgehensweisen.
--
Z. B. eine Klassifizierung openGeoDB, so etwa
"is_in:Stadt,Kreis,Bundesland,Land,Kontinent".
Das scheint mir logisch,
Da müsste man für jede Hierarchiestufe einen Komma-Platz definieren,
damit ein Puter das sauberle auswerten kann
und später mal per Robot in "relations" umetzen kann...
(Wir haben hier eine Liste der offiziellen Verwaltungseinheiten,
aufgestellt vom hiesigen "statistischen Amt", der INSEE.
Diese Liste hört aber auf der Rathausebene auf, Ortsteile, Weiler usw
sind da nicht aufgelistet,
und die parallelen strukturellen Verwaltungen sind nicht berücksichtigt,
sodass in dieser Liste dreimal die Hälfte der Informationen fehlt...).
Hier in F ist jedoch eine derartige Hierarchie-Struktur nicht direkt
anwendbar :
Es gibt hier Stadtviertel, Stadtteile, Weiler, Wahlbezirke,
Gemeinden, Gemeindezusammenschlüsse (mit einem gemeinsamen Rathaus),
Kantone (die auch Wahlbezirke sind),
Verwaltungsgruppierungen (die uns "von oben" aufgedrängt worden sind),
freiwillige Gemeinde-Gemeinschaften (wo jedes Dorf seine eigene
Verwaltungshoheit beibehält, jedoch gemeinsame Aufgaben wie Müll,
Schulen, Sportinstallationen, Ortskernentwicklung, Bauraumplanung,
GIS usw der gemeinschaftlichen Verwaltung überträgt),
Entwicklungsverträge zwischen Gemeinden ("Contrat de Pays"), wo sich
Gemeinden zu einem gemeinsamen Ziel zusammentun, wenn die
Verwaltungseinheiten nicht den topografischen oder ökonomischen
Gegebeheiten entsprechen :
Zu Beispiel das "Pays de Trocnçais", ein Vertrag, der um den Wald von
Tronçais enstanden ist, und über vier Départements und drei Régions
reicht.
Und auch Interessens-Zusammenschlüsse für Skigebiete und Strandbäder,
die mehrere Départements
Plus die üblichen Départements und Régions
(und natürlich auch irgendwelche "touristische Strassen" wie die
Route Jacques Cœuer, die Route des Vins, usw).
Das heisst, es gibt mehrerere Hierarchie-Ordnungen, zu denen ein
Weiler gehören kann...
Und vielleicht kommt übermorgen die Verwaltung mit noch einem neuen
Sparmaßnahme-Eumel daher,
der alles wieder über den Haufen schmeisst und umstrukturiert.
Sodass mit "Komma-Stellen" als Platzanweiser für eine Hierarchiestufe
hier nix réelles zu machen ist :-(
--
Ich sehe auf der Deutschlandkarte, dass Stadtteile nicht im Namen
ausgewiesen sind,
nicht "Stuttgart Bad Cannstatt" sondern "Bad Canstatt",
nicht "Göppingen Hohenstaufen" sondern "Hohenstaufen",
nicht "Karlsruhe Rüppurr" sondern "Rüppurr" usw.
Ist das gewollt ?
Dann muss man die "Zugehörigkeiten" mit "is_in" ausdrücken (?).
Das schein in D nicht immer konsequent der Fall zu sein, dehalb mein
Frage.
Zum Beispiel sind aussenliegende Ortsteile von Göppingen nicht per
"is_in" als solche ausgewiesen.
Oder ist Karlsruhe-Bulach als "place:suburb" und "name:Bulach" gezeigt,
ohne Bezug auf Karlsruhe.
Das sind in keinsterweise irgendwelche Kritiken ! Ich versuch' nur,
herauszufinden,
was die gemeinsamen Prinzipien sind, oder der kleinste gemeinsame
Nenner ist,
damit wir von Euch "abschreiben" können... ;-)
Wie haltet Ihr das, im Allgemeinen ?
--
Ist es notwendig,
in jedem Weiler die ganze Hierarchie bis 'rauf nach Europe zu
wiederholen,
oder genügt es, die jeweils höhere Hierarchiestufe einzugeben,
damit die Verzweigung/Gruppierung für die auswertenden Programme
funktionniert ?
--
Hier schagen manche vor,
Teilorte von Zusammenschlüssen als "suburb" zu taggen.
Sowas scheint angebracht, wenn ein grosser Stadtkern "seine Kinder
gefressen hat",
wie Grünwinkel oder Rintheim für Karsruhe,
oder Boutonnet für Montpellier,
aber nicht, wenn es sich um geografisch distante und getrennt
gewachsene Ortschaften handelt,
wie Berhausen (Pfinztal, Karlsruhe), oder
"Suburb" scheint mir als "Vorstadt" (de) oder "banlieue" (fr)
übersetzbar zu sein,
aber nicht als Teilort (?).
Auch wenn es um einen Zusammenschlus
Re: [Talk-de] TMC
Garry schrieb: > Stefan Dettenhofer (StefanDausR) schrieb: > >> Hallo, >> >> Die TMC-Daten für Deutschland erfasst und verwaltet die BAST. Dort >> bekommt man wohl auch -unter Angabe eines guten Grundes- die nötigen >> Infos und Daten. >> >> >> > Die letzten Diskussionen über TMC für OSM liegen ja inzwischen schon > eine Weile zurück.. > Inzwischen ist OSM ja schon einiges bekannter und vollständiger geworden. > Wäre doch ein Versuch wert sich mal wieder an die BAST zu wenden ob die > nicht vielleicht doch ihren > Beitrag zu OSM leisten wollen. > Am besten mal bei http://www.openrouteservice.org/ bzw. http://wiki.openstreetmap.org/wiki/OpenRouteService nachfragen, schließlich werden dort TMC-Daten angezeigt. Also sind die offenbar an die nötigen Informationen dafür rangekommen. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benutzung von is_in
On Thu, Dec 25, 2008 at 09:03:07PM +0100, g.d wrote: > Bei uns hier ist die Frage aufgetaucht, > wie man die Saczhe mit Gemeinde-Teilen und Gemeinde-Zusammenlegungen > tagggen könnte/sollte/müsste, > damit wir das relatif einheitlich, und von Rechnern auswertbar, > zusammenstupfeln. Es gibt keinen einheitlichen weg schonmal vorweg - Die is_in sind nur eine hilfe um jetzt schon gewisse abhaengigkeiten dartzustellen. Grundsaetzlich sind da nur die administrativen zusammenhaenge dargestellt jedoch nicht dinge wie Wahlbezirke oder aehnliches. > Sowas mit "relations" zu machen, gefällt uns derzeit nicht besonders, > das System ist noch nicht klar, > und auch die Renderers verarbeiten das nocht nicht. Das stoesst auch auf der talk-de immer wieder auch auf ablehnung - Das pflegen der relations ist leider sehr fehleranfaellig. > Das heisst, es gibt mehrerere Hierarchie-Ordnungen, zu denen ein > Weiler gehören kann... Er gehoert aber administrativ nur zu einer darueberliegenden oder? Also kann ein Mensch der in einem Weiler wohnt zu mehreren Passstellen gehen? > Ich sehe auf der Deutschlandkarte, dass Stadtteile nicht im Namen > ausgewiesen sind, > nicht "Stuttgart Bad Cannstatt" sondern "Bad Canstatt", > nicht "Göppingen Hohenstaufen" sondern "Hohenstaufen", > nicht "Karlsruhe Rüppurr" sondern "Rüppurr" usw. > Ist das gewollt ? Ja - der Stadtteil heisst ja "Bad Cannstatt" und ist ein Stadtteil von Stuttgart - D.h. der is_in sollte das klar machen das dieser place zu Stuttgart gehoert - der place type stellt klar das es ein Stadtteil ist. > Dann muss man die "Zugehörigkeiten" mit "is_in" ausdrücken (?). > Das schein in D nicht immer konsequent der Fall zu sein, dehalb mein > Frage. Konsequent ist bei OSM nix - Jeder so wie er mag - Ich habe mal angefangen das auch mit einem bot in D zu reparieren und alle pfade wo moeglich automatisiert umzustelen und zu ergaenzen - nichtsdestotrotz fehlen die is_in bei vielen places und sind bei vielen auch so kaputt das sie nicht automatisiert zu reparieren sind - Also viel stupide handarbeit fuer jemanden der Vater _und_ Mutter erschlagen hat. > Ist es notwendig, > in jedem Weiler die ganze Hierarchie bis 'rauf nach Europe zu > wiederholen, > oder genügt es, die jeweils höhere Hierarchiestufe einzugeben, > damit die Verzweigung/Gruppierung für die auswertenden Programme > funktionniert ? Es muss immer der gesamte Pfad sein da andernfalls bei darueberliegenden gleichnamigen places keine eindeutigkeit mehr existiert. Es gibt viele Langenberg, Neuenkirchen oder Neustadt - d.h. Stadtteile von Neustadt sind nicht eindeutig zugeordnet solange nicht der gesamte pfad dort existiert. > aber nicht, wenn es sich um geografisch distante und getrennt > gewachsene Ortschaften handelt, > wie Berhausen (Pfinztal, Karlsruhe), oder > > "Suburb" scheint mir als "Vorstadt" (de) oder "banlieue" (fr) > übersetzbar zu sein, > aber nicht als Teilort (?). > > Auch wenn es um einen Zusammenschluss zweier etwa gleichwertigen > Ortschaften geht, > wie "Lichtenwald" für Hegenlohe plus Thomashardt, > oder Schanbach, "suburb" von "Aichwald" (wo weder "Aichwald" noch > "Lichtenwald" historische Orte sind, > sondern Kunstnamen), > da scheint mir "suburb" nicht angebracht, eher "village". > Wie haltet Ihr das ? Das ist nicht eindeutig geklaert weil im prinzip zwischen suburb und village was fehlt. Ich halte das so das ortsteile deren Bebauung durchgehend ist ich als "suburb" tagge und ortsteile die wirklich voneinander entfernt sind, ohne durchgehende bebauung (Oft auf dem Lande) da mache ich ein village drauf. > Auch hat sich hier die Frage gestellt, > wo man eigentlich den Node mit dem Ortsnamen (einer "echten" > Ortschaft) hinkleben soll, auf der Karte... > Diesen Node in den geometrischen Schwerpunkt der Gemeindefläche zu > kleben, > (wie es unsere hiesige Verwaltung tut) hat keinen Sinn, > das kann je nach der Topographie der Gemeinde irgendwo jwd draussen > in Busch und Felsen sein, > weitab von Weg und Haus, > sodass kein Routing-Programm etwas damit anfangen kann :-( > Hier gibt's mehrere Ansichten : > - In den Schwerpunkt der besiedelten Fläche (was auch in irgendeinen > Vorort oder Stadtpark führen kann...), > - oder in die am meisten belebte Strasse/Platz (Innenstadt, > Einkaufsstraße, > da wo auch die Strassenschilder "Centre Ville" hinführen). > Wie macht Ihr das ? In die Mitte ;) So nach Gefuehl. Der Punkt ist das dieser node derzeit von der Straßensuche in den Navis als ausgangspunkt genutzt wird d.h. das sollte schon halbwegs in der mitte der Bebauung sein. > Manchmal finde ich "doppelt gemoppeltes" : > - Einerseits ein "Area" residential mit dem Namen der Ortschaft, > - und andererseits einen Node auch mit dem Namen des Orts, > plus weiteren Angaben. > > Ich nehme an, dass die Namen in den "Areas" Überreste aus den > Anfangszeiten sind ? > Oder hat das einen tieferen Sinn, der mir entgeht ? Nein - Beides ist richtig - Die residential area
Re: [Talk-de] Kreuzung Radwege
Hallo, >Ich mache das überall dort so, wo die Radwege einseitig angelegt sind, Ist aber auch unsinnig, sinnvoller wäre hier endlich einseitige Tags einzuführen. Gruß Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Hallo, >Der größte Nachteil dieser Methode ist nun mal, dass ich >unterschiedliche Verhältnisse auf beiden Seiten der Straße nicht >abbilden kann Keine der Methoden ist ausgereift, beim getrennt-Mappen fehlen die Relations um die Wege zu verbinden und bei der 1-Weg für alles Methode fehlen sachen wie cycleway=track_left (oder wie auch immer) >Es ist sehr frustrierend, wenn man sich in diesem Bereich z.B. durch >Abfahren der Wege mit GPS Mühe gibt und dann hört "die Wahrheit ist zu >kompliziert, können wir nicht darstellen" Deshalb sollten wir uns endlich auf eine vernünftige Methode einigen. 1) Soll cycleway=track wenn immer sinnvoll benutzt werden, also immer außer wenn die Situation von der Norm abweicht, der Fahrradweg also nicht unmittelbar neben der Straße verläuft. Falls Ja: Die Probleme lösen, also Fahrradweg nur auf einer Seite, oder auf einer Seite als cycleway=track und auf der anderen als cycleway=lane Falls Nein: Die Probleme lösen, also die verschiedenen Wege zu einer Einheit per Relation kombinieren, u.a. damit aus einer Kreuzung nicht 3 werden, damit Adressen sowohl per Auto als auch per Fahrrad erreichbar sind,... . Wozu gehört der Bürgersteig? Zur Straße oder zum Fahrradweg, oder muß der auch einzeln gemappt werden. Meist ist ja der Fahrradweg zwischen Straße und Bürgersteig -> es kann also nicht sein, daß man innen die Straße mit Bürgersteig mappt und außen den Fahrradweg, vor allem wenn man "die Wirklichkeit möglichst genau mappen will". >Ob ein Radweg ein Track auf dem Bürgersteig oder eine lane auf der >Straße ist, ist für unsichere, ältere Radfahrer sehr entscheidend. Diese Unterscheidungsmöglichkeit gibt es derzeit aber nur bei der 1-Weg Methode, nämlich cycleway=lane oder track. Zeichnet man den Fahrradweg einzeln ist er highway=cycleway, da gibt es (noch) keine Unterscheidung. >Dann müßte man ehrlicherweise sagen: Eine Radfahrkarte (speziell im >städtischen Breich) werden wir niemals hinbekommen. Unsinn, die ist mit beiden Methoden machbar. Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Layer
Florian Lohoff schrieb: > On Thu, Dec 25, 2008 at 12:12:14PM +0100, Sven Rautenberg wrote: >> Melchior Moos schrieb: >>> 2008/12/22 Johann H. Addicks >>> Im Irc erreichte mich die Frage, von wem das ÖPNV-Layer ist, was unter http://81.89.97.206/oepv.html abrufbar ist. >>> Meine Wenigkeit... >> Schöne Sache. >> >> Verbesserungsvorschlag: Setze auf die Seite noch einen Link zu einer >> Wikiseite, in der beschrieben wird, wie die Relationen zu taggen sind, >> die du da farblich hervorhebst. > > Das Datum des letzten updates waere auch super - Ich habe versucht eine > BUS route relation zu bauen und die wird nicht gerendert - Im moment > rate ich ob ich zu bloede bin oder das einfach nur daran liegt das seit > ein paar tagen das nicht geupdated wurde ... Ja, das wäre absolut super. So in der Art "Basis des derzeitigen Renderns sind die OSM-Daten vom $Datum $Uhrzeit". Es ist ja auch nicht schlimm, wenn die Karte nur alle paar Tage oder Wochen neu gerendert wird, aber man kann sich besser drauf einstellen, wenn man die Info hat. Dass es mit dieser Info dann Leute geben wird, die sich drüber beschweren, dass das nicht schneller geht, dürfte mit Sicherheit passieren, aber einem geschenkten Gaul... Viele Grüße Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benutzung von is_in
Moin, > Bei uns hier ist die Frage aufgetaucht, > wie man die Sache mit Gemeinde-Teilen und Gemeinde-Zusammenlegungen > tagggen könnte/sollte/müsste, > damit wir das relatif einheitlich, und von Rechnern auswertbar, > zusammenstupfeln. mit den uns derzeit zur Verfügung stehenden Mitteln ist sowas relativ schwierig umzusetzen. Verwenden könnte man * is_in * Polygone * Relationen is_in verwende ich persönlich nicht, weil es mir irgendwie widerstrebt, an alle möglichen Objekte redundant immer wieder die selben Informationen zu hängen. Ein Vorteil den ich sehe liegt darin, dass man sich ein beliebiges Objekt zusammenhangslos herausgreifen kann und alle Informationen beisammen hat, ohne "weiter 'drüber nachdenken" zu müssen. Das ist aber IMO gleichzeitig ein Nachteil, weil die Objekte wenig "voneinander wissen". Polygone eignen sich IMO auch nicht, weil es dann im Falle räumlich getrennter Objekte zu seltsamen Polygonen führen würde (ich stelle mir bildlich das interessante Polygon um Grönland und Dänemark vor :) . Blieben Relationen, mit denen man solche Sachen zwar recht schön modellieren kann, allerdings ist das für den durchschnittlichen Mapper schlicht zu kompliziert. Editiert man an Objekten herum, die in einer Relation stecken, muss man höllisch aufpassen, nichts kaputt zu machen. Schließlich lebt unser Projekt auch davon, dass die Einstiegsschwelle für Neulinge möglichst niedrig liegt. Relationen könnten *irgendwann mal* genau das richtige Mittel sein, um solche Sachen in den Griff zu bekommen. Bis unsere Infrastruktur aber soweit ist, muss man als "Durchschnittsmapper" (Vorreiter, die erstmal was ausprobieren, damit man was dazulernt, ausgenommen) entweder auf das Abbilden solcher Zusammenhänge verzichten, oder vorübergehend das nehmen, was zur Verfügung steht. Ist ja egal ob das dann is_in oder belongs_to oder sonstwas ist. Um auf die "Suburbs" in Karlsruhe zurückzukommen: Die stammen aus einer Zeit, als wie in Karlsruhe froh waren, überhaupt mal was auf der Karte zu haben. Als ich vor 2,5 Jahren anfing, gab es hier _nichts_. Ein Node auf der Karte macht da halt gleich was her. Der Node an sich sagt aber ansonsten recht wenig aus. Zum Karlsruher Stadtgebiet gehören auch Orte wie Grünwettersbach, Stupferich und so weiter, die doch etwas außerhalb liegen. Die könnte man mit einem Adminpolygon umrahmen, an das man dann belongs_to=Karlsruhe hängt (ich verschweige jetzt lieber dass es ein gleichnamiges Dorf in den Staaten gibt ;) . Es gibt auch Kommunen, die aus Orten namens A, B und C bestehen, aber D heißen. Straubenhardt[1] habe ich beispielsweise als einen wahllos in die Landschaft gesetzten Node angelegt, um ein Rendering zu bekommen (nein, ich mappe selbstverständlich niemals für "die Renderer" :) . Dann habe ich diesen und die einzelnen Ortsteile zusammen in eine Relation gestopft, um den administrativen Zusammenhang herzustellen. Alles nur Stückwerk. Ich persönlich würde mir mehr Unterstützung für Relationen durch Renderer wünschen. Aber bevor nicht unsere Editoren dazugelernt haben, ist das einfach nichts, was man mehr als sporadisch in der Datenbank haben möchte. Beste Grüße aus Karlsruhe, ce [1] http://tinyurl.com/8p2alu ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
On Thu, 2008-12-25 21:27:27 +0100, John07 wrote: > Garry schrieb: > > Stefan Dettenhofer (StefanDausR) schrieb: > > > Die TMC-Daten für Deutschland erfasst und verwaltet die BAST. Dort > > > bekommt man wohl auch -unter Angabe eines guten Grundes- die nötigen > > > Infos und Daten. > > > > > Die letzten Diskussionen über TMC für OSM liegen ja inzwischen schon > > eine Weile zurück.. > > Inzwischen ist OSM ja schon einiges bekannter und vollständiger geworden. > > Wäre doch ein Versuch wert sich mal wieder an die BAST zu wenden ob die > > nicht vielleicht doch ihren > > Beitrag zu OSM leisten wollen. > > Am besten mal bei http://www.openrouteservice.org/ bzw. > http://wiki.openstreetmap.org/wiki/OpenRouteService nachfragen, > schließlich werden dort TMC-Daten angezeigt. Also sind die offenbar an > die nötigen Informationen dafür rangekommen. Das Herankommen an die Daten ist nicht das Problem. Das /Verbreiten/ macht die Probleme. MfG, JBG -- Jan-Benedict Glaw jbg...@lug-owl.de +49-172-7608481 Signature of: Alles wird gut! ...und heute wirds schon ein bißchen besser. the second : signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benutzung von is_in
Danke für die aufschlussreichen Infos, ich wart' mal ab, ob Andere auch Komentare haben bevor ich den "Meinen" hier Bericht erstatte... :-) Le 25 déc. 08 à 21:36, Florian Lohoff a écrit : > On Thu, Dec 25, 2008 at 09:03:07PM +0100, g.d wrote: >> Bei uns hier ist die Frage aufgetaucht, >> wie man die Sache mit Gemeinde-Teilen und Gemeinde-Zusammenlegungen .../... > Es gibt keinen einheitlichen weg schonmal vorweg Das dachte ich mir, Macht ja auch hier jeder seine eigene Sauce, mehr oder minder... .../... > Grundsaetzlich sind da nur die administrativen zusammenhaenge > dargestellt jedoch nicht dinge wie Wahlbezirke oder aehnliches. Tscha, die Wahlbezirke *sind* hier wichtige administrative Zusammenhänge. Napoléon oblige... .../... >> Das heisst, es gibt mehrerere Hierarchie-Ordnungen, zu denen ein >> Weiler gehören kann... > > Er gehoert aber administrativ nur zu einer darueberliegenden oder? > Also > kann ein Mensch der in einem Weiler wohnt zu mehreren Passstellen > gehen? Ja doch... Zu seiner Ortsverwaltung, zu seinem Rathaus, zu seiner UnterPräfektur (die hatte ich in der Liste vergessen), oder zu seiner Präfektur. Und in Paris auf die PolizeiPräfektur. Wenn's jedoch um die Wasser/Abwasserrechnung geht, dann geht's die Präfekturen nix an, sondern andere parallele Verwaltungen von Ortszusammenschlüssen. Und wenns um Schultransport geht, dann geht's das Département an, oder gar die Region - aber nicht die zentrale Schulverwaltung (die ûbrigens nix mit der régionalen oder départementalen Kulturverwaltung zu tun hat). Das ist hier sehrstens differenziert. Kafka ist da Kindermärchen dagegen, wie's hier läuft (oder nicht läuft)... :-( .../... > nichtsdestotrotz > fehlen die is_in bei vielen places und sind bei vielen auch so kaputt > das sie nicht automatisiert zu reparieren sind - Also viel stupide > handarbeit fuer jemanden der Vater _und_ Mutter erschlagen hat. Ups, also eben von Hand häkeln... Kein "Grundprinzip" in Aussicht :-( .../... > Es muss immer der gesamte Pfad sein da andernfalls bei > darueberliegenden > gleichnamigen places keine eindeutigkeit mehr existiert. Es gibt viele > Langenberg, Neuenkirchen oder Neustadt - d.h. Stadtteile von Neustadt > sind nicht eindeutig zugeordnet solange nicht der gesamte pfad dort > existiert. Mist alors :-( Das gibt fürchterliche Rattenschwänze von "is_in" ! Aber stimmt schon, sonst kriegt man Paris in France durcheinander mit Paris im Illinois, und Stuttgart in Deutschland mit Stuttgart, Arkansas. Irgendwie hätte ich jedoch gehofft, dass die Angabe nur der nächsthöheren Hierarchie derartige Verwechslungen ausschliessen könnte, zusammen mit den geographischen Grenzen der Gemeinden und Kreise... .../... >> da scheint mir "suburb" nicht angebracht, eher "village". >> Wie haltet Ihr das ? > > Das ist nicht eindeutig geklaert weil im prinzip zwischen suburb und > village was fehlt. Ich halte das so das ortsteile deren Bebauung > durchgehend > ist ich als "suburb" tagge und ortsteile die wirklich voneinander > entfernt sind, ohne durchgehende bebauung (Oft auf dem Lande) da mache > ich ein village drauf. Persönlich halt' ich das auch so. (Bei uns hat ein Massenimport der INSEE-Liste alle Orte mit wenig Einwohnern als "hamlet" robotisiert, wobei jedoch alle Ortschaften dieser Liste eigenständige Ortschaften sind, sodass man jetzt die Hälfte unserer sechunddreissigtausend Dörfer von Hand auf "village" umstricken muss...) .../... >> Auch hat sich hier die Frage gestellt, >> wo man eigentlich den Node mit dem Ortsnamen (einer "echten" >> Ortschaft) hinkleben soll, auf der Karte... > .../... > In die Mitte ;) So nach Gefuehl. Der Punkt ist das dieser node derzeit > von der Straßensuche in den Navis als ausgangspunkt genutzt > wird .../... Deshalb meinte ich, daß wir diesen Node vielleicht ins echte Lebeszentrum setzen sollten, Einkaufsstraße, Marktplatz oder so, da wo die Schilder "Centre Ville" hinweisen, und vielleicht auch einen Node eines bestehenden Ways dafür wählen sollte (und nicht einen isolierten Node setzen), weil sonst vielleicht "naive" Navis diesen Node gar nicht ans Strassennetz linken, und nie wirklich am Zielort "ankommen" ? .../... >> Manchmal finde ich "doppelt gemoppeltes" : >> - Einerseits ein "Area" residential mit dem Namen der Ortschaft, >> - und andererseits einen Node auch mit dem Namen des Orts, >> plus weiteren Angaben. >> >> Ich nehme an, dass die Namen in den "Areas" Überreste aus den >> Anfangszeiten sind ? >> Oder hat das einen tieferen Sinn, der mir entgeht ? > > Nein - Beides ist richtig - Die residential area markiert die bebaute > flaeche - d.h. die art der Nutzung der flaeche. Der place node die > mitte > der Stadt. Nö, das meinte ich nicht, sondern : Ich habe auf der Deutsche OSM-Karte mehrere residential areas angetroffen mit name:Name_der_Ortschaft, wo aber kein Node place ist. Und andererseits gibt es derartige areas mit name:Name_der_Ortschaft, wo zusätzlich auch ein Node mit
Re: [Talk-de] TMC
Jan-Benedict Glaw schrieb: > On Thu, 2008-12-25 21:27:27 +0100, John07 wrote: > >> Garry schrieb: >> >>> Stefan Dettenhofer (StefanDausR) schrieb: >>> Die TMC-Daten für Deutschland erfasst und verwaltet die BAST. Dort bekommt man wohl auch -unter Angabe eines guten Grundes- die nötigen Infos und Daten. >>> Die letzten Diskussionen über TMC für OSM liegen ja inzwischen schon >>> eine Weile zurück.. >>> Inzwischen ist OSM ja schon einiges bekannter und vollständiger geworden. >>> Wäre doch ein Versuch wert sich mal wieder an die BAST zu wenden ob die >>> nicht vielleicht doch ihren >>> Beitrag zu OSM leisten wollen. >>> >> Am besten mal bei http://www.openrouteservice.org/ bzw. >> http://wiki.openstreetmap.org/wiki/OpenRouteService nachfragen, >> schließlich werden dort TMC-Daten angezeigt. Also sind die offenbar an >> die nötigen Informationen dafür rangekommen. >> > > Das Herankommen an die Daten ist nicht das Problem. Das /Verbreiten/ > macht die Probleme. > Sofern ich das richtig verstanden habe, braucht man Tabellen, um die TMC-Daten den OSM/Navigations-Daten zuzuordnen. Bei Openrouteservice ist das ja möglich, warum sollte es also nicht auch für jede andere OSM-Anwendung möglich sein bzw. wenn ORS die Daten nutzen kann/darf, warum dann nicht auch andere OSM-Anwendungen? Außerdem haben die von ORS wohl Erfahrung mit TMC in Verbindung mit OSM, daher finde ich meinen Hinweis durchaus nützlich. Gruß Jonas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Dimitri Junker schrieb: > Hallo, > > >> Ich mache das überall dort so, wo die Radwege einseitig angelegt >> > sind, > > > Ist aber auch unsinnig, sinnvoller wäre hier endlich einseitige Tags > einzuführen. > > Gruß > Dimitri > > ___ > Talk-de mailing list > Talk-de@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-de > > oder man könnte sich mit der Lane-Relation und der im Linienbündel-Workshop vorgestellten Lane-Plugin für JOSM näher beschäftigen. Mit diesem Tool wär sowohl dem Routing, der Anzeige und dem Mapping selber eine große Hilf erwiesen. http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel bzw. http://tobias-knerr.de/josm/lanetool/ Effektiver kann man IMHO Spuren nicht erfassen. schnell und exakt und bildet unsere Wirklichkeit im Rahmen unserer Genauigkeit ab. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
John07 schrieb: > Sofern ich das richtig verstanden habe, braucht man Tabellen, um die > TMC-Daten den OSM/Navigations-Daten zuzuordnen. Bei Openrouteservice ist > das ja möglich, warum sollte es also nicht auch für jede andere > OSM-Anwendung möglich sein bzw. wenn ORS die Daten nutzen kann/darf, > warum dann nicht auch andere OSM-Anwendungen? > Außerdem haben die von ORS wohl Erfahrung mit TMC in Verbindung mit OSM, > daher finde ich meinen Hinweis durchaus nützlich. Dann google doch mal ein wenig bevor du fragst (hab ich auch gemacht) ;-) Die Liste kannst du kostenlos unter: http://www.bast.de/nn_42544/DE/Aufgaben/abteilung-v/referat-v2/Location-Code-List/location-code-list-start.html zugeschickt bekommen, wenn du einer Reihe von Bedingungen zustimmst und genau beschreibst wofür du das ganze haben willst. Problematisch dabei: 3. Der Nutzer erhält eine kostenfreie Lizenz zur Nutzung der LCL 7.01 für den angegebenen Verwendungszweck. Für fortgeschriebene Versionen der Location Code List gilt dieses Nutzungsrecht nicht. Die Weitergabe der Location Code List durch den Nutzer an Dritte ist nicht zulässig. Somit kommst du an diese List wohl ran, aber einfach so in OSM einpflegen ist wegen dieser Lizenz einfach nicht drin. Nett fragen kann ja mal *einer* (der vielleicht mit sowas schon etwas Erfahrung hat) beim Bast, die Behörden scheinen in letzter Zeit ja allgemein kooperativer als noch vor nem halben Jahr zu sein :-) Gruß, ULFL P.S: Die andere Info die man braucht sind die Event Codes (sowas wie ID 17=Stau), die konnte ich aber nicht so ohne weiteres finden (gibt's irgendwo in einer IEEE/ISO Norm für so 230Dollar) ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM-Geschwindigkeit
Am Donnerstag 25 Dezember 2008 11:30:27 schrieb Sven Sommerkamp: > Auf Dauer wäre ein Editor, der in ein gut funktionierendes Navi auf OSM > Basis integriert ist, sehr wichtig! Hi, hast du dir schon einmal Merkaator angesehen? Aber auch für JOSM gibt es ein livegps-Plugin. Schöne Feiertage! Ralf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Ulf Lamping schrieb: > > P.S: Die andere Info die man braucht sind die Event Codes (sowas wie ID > 17=Stau), die konnte ich aber nicht so ohne weiteres finden (gibt's > irgendwo in einer IEEE/ISO Norm für so 230Dollar) ... Möglicherweise hier: http://dev.inversepath.com/download/rds/srdsd (am Ende). Die Liste kommt aus UK, also eventuell nicht in "Good Old Germany" zu gebrauchen. Halb-OT: Event Codes gibt's... $Event[1478] = "terrorist incident"; $Event[1481] = "air raid, danger"; $Event[1516] = "bomb alert"; Grüße, Michi signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] TMC
Michael Bemmerl schrieb: > Ulf Lamping schrieb: >> P.S: Die andere Info die man braucht sind die Event Codes (sowas wie ID >> 17=Stau), die konnte ich aber nicht so ohne weiteres finden (gibt's >> irgendwo in einer IEEE/ISO Norm für so 230Dollar) ... > > Möglicherweise hier: http://dev.inversepath.com/download/rds/srdsd (am > Ende). Die Liste kommt aus UK, also eventuell nicht in "Good Old > Germany" zu gebrauchen. Laut Wikipedia http://de.wikipedia.org/wiki/Traffic_Message_Channel: "Die Meldung ist nach dem Alert-C-Standard codiert. Dieser beinhaltet eine Liste mit ungefähr 1460 Ereignissen. Mit Hilfe dieser Liste kann die Meldung in eine für den Benutzer verständliche Form umgesetzt werden." Alert-C wird scheinbar bei TMC überall verwendet, sollte also auch "für hier" passen. > > Halb-OT: Event Codes gibt's... > > $Event[1478] = "terrorist incident"; > $Event[1481] = "air raid, danger"; > $Event[1516] = "bomb alert"; > "Wir sind auf alles vorbereitet". Und dann kam der große Krötenumzug und von "toad" stand nix in der Liste ;-) Wenn jetzt noch einer einen übers Internet zu beziehenden TMC stream kennt :-) Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Benutzung von is_in
Danke, Christoph. Le 25 déc. 08 à 23:25, Christoph Eckert a écrit : > Moin, .../... > Verwenden könnte man > * is_in > * Polygone > * Relationen Wie Du sagst, Relationen wären sicherlich das "logisch" geeignetste Mittel, aber man kann Newcomers nicht da drauf loslassen, das gäbe fürchterliches Durcheinander, die Denkweise der Relations ist eben fondamental invers zu der traditionnellen "tag=Eigenschaft"s-Denkweise, und wenn ich ansehe, was hier (gutwillige, begeisterte und willige) Anfänger mit potlach anstellen können, da wird mir Angst und bange beim einfachen Gedanken, was sie aus Relationen machen könnten... Solange die Renderers nicht mitspielen (und man sofort das Ergebnis sieht), und diese doppelspurige Logik tag <-> relation nicht klar aufm Wiki erklärt wird, sehe ich wenig praktische Anwendung. -- Die Geschichte mit Polygonen ist zwar logisch konsequent, scheint mir aber ein Rückschritt in die Anfangszeiten der GIS/SIGs :-( Da hat man dann Flâchen, die mit hin-und-her-Linien auf den gleichen Nodes zusammenhängen, die aber auch die gleichen Nodes als Grenzlinien benutzen, das wird quasi unmöglich zu editen, selbst in JOSM :-( Dazu braucht man Editoren die besser 'für gemacht sind. Kommt noch dazu, dass manche Renderer Drehsinn-empfindlich sind. Das ist "has-been". > ich stelle mir bildlich das > interessante Polygon um Grönland und Dänemark vor :) Oder die Anspruchsgebiete in der Antarktis ! Um diese als Polygone mit ihren Ländern zu verbinden, kriegt man topologische Probleme, braucht eine vierte Dimension, oder muss Alles auf unterschiedliche Layers schieben. Nö, die tag-Methode hat den Vorteil, dass man zeichnen kann, was ist, ohne daß es unbedingt in ein Schema passen muss. -- Sodass derzeit der Tag "is_in:" der einzige praktikable Ausweg zu sein scheint... Selbst wenn es auch mich ärgert, die Datenbasis mit redundanten "France,Europe" vollzustopfen ! Irgendwie hätte ich gedacht, dass wir seit Hollerith diese Einzwängung abgeschüttelt hätten, und dass unsere Programme diskriminieren könnten zwischen einem "Neuburg" an der Donau und einem "Neuburg" in Nordrhein-Westfalen, schon mal anhand der verschiedenen Grenz-Polygone, innerhalb welcher sich das eine und das andere Neuburg befindet. Aber scheints ist die graue Masse noch nicht so weit :-( Theoretisch müsste ein hierarchisch übergeordnetes Element gar nichts "wissen" davon, aus was es besteht, es genügt, dass die untergeordneten Elemente "wissen", zu welchem (eindeutig identifizierten) übergeordneten Element sie gehören. Der "Rest" ist Sache der Abfrage, Definition der Suchbegriffe. Das gilt auch, wenn ein Element mehreren, unterschiedlichen Hierarchien untergeordnet ist : Mehrere "Wurzelwerke" können sich schneiden und gemeinsame Punkte haben (Das ist sogar unumgänglich für einen lebenden Organismus). Umso wniger mag ich die ganze Hierarchie in jedem Dorf und Weiler wiederholen. Meiner Ansicht nach obliegt es den auswertenden Programen, aus den (eindeutigen) Daten die Zusammenhänge wiederherzustellen, für ihre Suche. Jedes OptimierungsProgramm arbeitet auf solcher Basis. .../... Dazu käme noch, wenn man den Teufel im Detail suchen würde, dass zum Beispiel Französisch-Guyana zwar geographisch auf dem Kontinent Sudamerika liegt, Saint-Pierre-and-Miquelon vor der kanadischen Küste, und Wallis-et-Futuna irgendwo im Pazifik so etwa auf Höhe von Samoa schwimmt, jedoch politisch und verwaltungsmässig irgendwie zur Europäischen Union gehören, also irgendwie "is_in:France,Europe" sind (?). Wie vermutlich spanische, portugiesische, englische und italienische Kolonien auch. Aber derart Fragen und Aspirinverbrauch überlasse ich der Nachwelt. Derzeit geht's mir einfach drum, wie man Zusammenlegungen und Ortsteile taggen kann, weil's da Widersprüche zwischen Verwaltung un Realität gibt, und wo OSM eher die Realität wiedergeben will... .../... > Um auf die "Suburbs" in Karlsruhe zurückzukommen: Die stammen aus > einer Zeit, > als wie in Karlsruhe froh waren, überhaupt mal was auf der Karte zu > haben. Nu, ist doch gar nicht schlecht, ich finde Karlsruhe und Umland ziemlich gut strukturiert, im Vergleich mit manchen anderen Ecken ! :-) (So in schnellem Überflug, von aussen gesehen...) > (ich > verschweige jetzt lieber dass es ein gleichnamiges Dorf in den Staaten > gibt ;) . Das müsste ein Vergleich mit den Daten der umliegenden Grenzpolygonen klarkriegen, ohne dass man im "is-in:" bis aufs Niveau Europe beschreibt :-) > Dann habe ich diesen > und die einzelnen Ortsteile zusammen in eine Relation gestopft, um den > administrativen Zusammenhang herzustellen. Aha, jetzt versteh' ich besser, weshalb der Text 'Straubenhardt' und auch 'Mannheim' wie 'Ludwigshafen' ab zoom 15 verschwindet : Das sind relations... Und wird quasi unmöglich, zu managen :-( .../... > Aber bevor nicht unsere Editoren > dazugelernt haben, ist das einfach nichts, was man mehr als > sporadisch in der > Datenbank haben möchte.
Re: [Talk-de] Kreuzung Radwege
Wolfgang Wienke schrieb: > Hallo! > Johannes Huesing schrieb: >> Dimitri Junker [Thu, Dec 25, 2008 at 03:29:52PM >> CET]: >> [...] >> >>> Da sind wir uns einig, nur ich beobachte da anderes, es werden extra >>> Fahrradwege gezeichnet die genau dem entsprechen wofür cycleway=track >>> gedacht ist. > Der größte Nachteil dieser Methode ist nun mal, dass ich > unterschiedliche Verhältnisse auf beiden Seiten der Straße nicht > abbilden kann, und die sind für den Radfahrer sehr wichtig. > > All das hier geschriebene spricht eigentlich nur dafür, dass die > Mappingregeln in diesem Bereich DRINGEND grundlegend geklärt und mehr > festglegt werden sollten. > Die Tags auf rechts/links zu erweitern ist ja nicht sonderlich schwer, wurde auch schon mehrfach vorgeschlagen (z.B. [1]), auch für Bürgersteige, die ja auch manchmal nur auf einer Seite verlaufen oder garnicht vorhanden sind. Für kompliziertere Fälle müssen dann eben Mapping Schemas mit Relations entwickelt werden. Damit ließen sich dann auch Abbiegeregeln und sowas erfassen. Allerdings braucht man das sicherlich nicht für alle Radwege, die meisten ließen sich auch mit einfachen Tags brauchbar erfassen. Der Vorteil an einfachen Tags ist nunmal einfaches Editieren. Für Tags mit rechts/links muss der Editor lediglich eine Warnung/Automatik beim Umdrehen von Wegen implementiert haben. Und selbst wenn er das nicht kann, geht es notfalls auch von Hand, auch wenn das nicht optimal ist. Gruß [1] http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_cycleway ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Mario Salvini schrieb: > oder man könnte sich mit der Lane-Relation und der im > Linienbündel-Workshop vorgestellten Lane-Plugin für JOSM näher > beschäftigen. Mit diesem Tool wär sowohl dem Routing, der Anzeige und > dem Mapping selber eine große Hilf erwiesen. > http://wiki.openstreetmap.org/wiki/WikiProject_Germany/Workshops/Linienb%C3%BCndel > bzw. > http://tobias-knerr.de/josm/lanetool/ > Effektiver kann man IMHO Spuren nicht erfassen. schnell und exakt und > bildet unsere Wirklichkeit im Rahmen unserer Genauigkeit ab. > Das ist definitv ein geniales Tool, das durchaus Potential hat. Allerdings lassen sich sehr viele einfache Fälle auch mit einigen wenigen Tags beschreiben. Das Problem mit dem Tool ist eben, dass es nur in JOSM vorhanden ist. Bevor man das großflächig einsetzt, sollten es auch zumindest die populärsten Editoren implementiert haben. Sonst stehen die Mapper plötzlich vor einer Menge unübersichtlicher Relationen. Ansonsten ist es natürlich schon interessant, gerade für komplexere Fälle wie größere Kreuzungen. Ich weiß ja nicht wielange der Autor dafür gebraucht hat, aber daran sieht man mal, wie sehr ein hübsches Tool doch das Mappen vereinfachen kann. Wäre schön wenn der Support für die anderen Relationstypen auch mal verbessert würde. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Ehem. Militäranlage
Hallo ! kurze frage, vielleicht bin ich zu doof, oder es liegt dran das ich grad erst anfange mit diesem schönen "Hobby" Wie kann ich ehemalige Militärgelände kennzeichnen ? Es gibt davon recht viele, die würde ich gern eintrag, evt. auch mit den Straßen, Gebäuden und Bunkern darauf - aber Bunker. z.B hab ich nur in "aktiv" gefunden . Wie kann ich da sachen anlegen ? Danke ! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Plaedoyer fuer Realnamen
Sven Geggus wrote: > P.S.: Ich empfinde es eher als Last einen fast eindeutigen Namen zu > haben. Sven Guckes ist der einzige, mit dem ich bisher verwechselt > wurde und die Leute waren dann immer ganz entsetzt wenn ich erzählt > habe, dass ich mit vi nicht umgehen kann :) Er war jedenfalls ganz überrascht, als ich ihm erzählte, ihn im Radio gehört zu haben - es warst wohl du gewesen, der über OSM erzählt hatte. Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Ehem. Militäranlage
Markus [Fri, Dec 26, 2008 at 04:16:54AM CET]: > Bunkern darauf - aber Bunker. z.B hab ich nur in "aktiv" gefunden . > Wie kann ich da sachen anlegen ? Es gibt Diskussion darüber, wie so etwas im allgemeinen Fall erledigt werden soll. Ein guter Ausgangspunkt ist im Wiki nachzulesen: http://wiki.openstreetmap.org/wiki/Comparison_of_life_cycle_concepts -- Johannes Hüsing There is something fascinating about science. One gets such wholesale returns of conjecture mailto:johan...@huesing.name from such a trifling investment of fact. http://derwisch.wikidot.com (Mark Twain, "Life on the Mississippi") ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Am Donnerstag, 25. Dezember 2008 16:07:33 schrieb talk-de-requ...@openstreetmap.org: > Dimitri Junker schrieb: > > Hallo, > > > >> F?r den Mapper: Es macht viel extra Arbeit, in der Zeit k?nnte man die > >> leeren Fl?chen f?llen. > >> F?r das Kartenbild: In den meisten F?llen wird das Kartenbild nur > >> un?bersichtlich. > > > > das l??t sich auch kombinieren, wenn ein Bereich zu un?bersichtlich ist > > weiger ich mich dort zus?tzliches zu mappen. > > Man sollte sich wenn es 2 M?glichkeiten gibt etwas zu mappen ?berlegen > > wie ihr Informationsgehalt ist und wie der Aufwand ist. > > Das h?ufigste Argument f?r einzeln gemappte Fahrradwege ist: "der ist > > baulich getrennt" aber was steht da in den Map_Features: > > ycleway track Ein baulich abgesetzter Radweg (cycle > > track), z.B. durch einen Bordstein, der meist neben der Fahrbahn > > verl?uft. > > Kommt drauf an was man mit "baulich getrennt" genau meint. Ich verstehe > darunter nicht nur einen etwas abgesetzten Radweg mit Bordstein, sondern > eine tats?chliche Trennung. Sobald man n?mlich ?ber eine Mauer klettern > oder mehrere Meter durch Wiese stapfen muss, kann man nicht mehr so > einfach ?berall auf die Stra?e wechseln. Da ergibt es von der Bedeutung > her schon Sinn einen extra Weg einzuzeichnen. Ganz genau! Ein Bordsteinradweg ist nicht baulich getrennt! Denn ich kann an fast beliebigen Stellen die Fahrbahn überqueren und z.B. zurück fahren. Das ist der springende Punkt! > > Wenn der Radweg nur abgesetzt ist, reicht auch das entsprechende Tagging > der Stra?e. Das k?nnte dann auch entsprechend gerendert werden, z.B. > durch ver?nderte R?nder der Stra?e (fett, farbig, was auch immer). Das ist z.B. bei den ADFC Karten so und funktioniert sehr gut! > So > w?rde man auch direkt den Unterschied zwischen "baulich getrennt" und > "baulich abgesetzt" sehen und w?sste ob man hier die Stra?e problemlos > ?berqueren kann (sofern es der Verkehr zul?sst nat?rlich). Ansonsten > wei? man nie ob man einen Zaun oder nur ein paar Zentimeter Bordstein > ?berwinden muss. > > Sicherlich k?nnte man sowas auch mit Relationen l?sen, die die Beziehung > zwischen den einzelnen Wege beschreiben, aber das d?rfte h?chstens f?r > wirklich komplexe F?lle notwendig sein. In sehr vielen F?llen d?rfte > sich das mit maximal einer Handvoll Tags beschreiben lassen. > > Ob ein Weg ein paar Meter einen Schlenker macht, d?rfte in der Praxis > kaum einen Unterschied machen. Wenn der Schlenker weiter von der Stra?e > wegf?hrt, liegt vermutlich sowieso wieder eine bauliche Trennung vor. > Liegt der Schlenker an einer gro?en Kreuzung oder sowas (also bedingt > durch breitere Stra?e), m?sste eben die Stra?e entsprechend breiter > gerendert werden, wenn man solche Details m?chte. So, ist es! > > Gru? Gruß Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Digest, Vol 29, Issue 269
Am Donnerstag, 25. Dezember 2008 16:07:33 schrieb talk-de-requ...@openstreetmap.org: > Hallo, > > >F?r den Mapper: Es macht viel extra Arbeit, in der Zeit k?nnte man die > >leeren Fl?chen f?llen. > >F?r das Kartenbild: In den meisten F?llen wird das Kartenbild nur > >un?bersichtlich. > > das l??t sich auch kombinieren, wenn ein Bereich zu un?bersichtlich ist > weiger ich mich dort zus?tzliches zu mappen. > Man sollte sich wenn es 2 M?glichkeiten gibt etwas zu mappen ?berlegen > wie ihr Informationsgehalt ist und wie der Aufwand ist. > Das h?ufigste Argument f?r einzeln gemappte Fahrradwege ist: "der ist > baulich getrennt" aber was steht da in den Map_Features: > ycleway track Ein baulich abgesetzter Radweg (cycle > track), z.B. durch einen Bordstein, der meist neben der Fahrbahn verl?uft. > > Also hat ein parallel neben der Stra?e verlaufender Fahrradweg keinen > zus?tzlichen Informationsgehalt zu cycleway=track, vorallem wenn er einfach > nach Augenma? eingezeichnet wurde statt ihn wirklich zu mappen. Zus?tzliche > Information w?rde man erst erhalten wenn man den genauen Verlauf eintragen > w?rde, interessant w?rde dies aber erst wenn zwischen Stra?e und Fahrradweg > mehrere Meter Abstand sind. Eine andere Zusatzinfo w?re, wenn man jede > Verbindung zwischen Stra?e und Fahrradweg einzeichnen w?rde. Ob dies > n?tzlich w?re sei dahingestellt. Aber diese M?he machen sich die wenigsten. > Es m??te dann jede Bordsteinabsenkung eingetragen werden, und auch jedes > zus?tzliche Hindernis, also z.B. ein zus?tzlicher Gr?nstreifen. Oder auch > ob zwischen Fahrradweg und Stra?e ein Parkstreifen ist. > Vor allem aber mu? gew?hrleistet werden, da? diese zus?tzlichen Wege mit > der Stra?e ?ber Relations o.?. verbunden werden. Sonst sind sie wie schon > oft berichtet wurde eher verwirrend f?r Router u.?.. Und das ganze mu? > irgendwie so von Josm/Potlach unterst?tzt werden, da? es nicht zu zu vielen > Fehlern f?hrt. Die meisten Fehler die ich so in den Daten finde h?ngen mit > komplexen Stra?en zusammen. Das in etwa mein ich > > Dimitri ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzung Radwege
Am Donnerstag, 25. Dezember 2008 20:42:45 schrieb talk-de-requ...@openstreetmap.org: > Message: 1 > Date: Thu, 25 Dec 2008 18:22:04 +0100 > From: Wolfgang Wienke > Subject: Re: [Talk-de] Kreuzung Radwege > To: johan...@huesing.name, Openstreetmap allgemeines in Deutsch > > Message-ID: <4953c13c.10...@gmx.net> > Content-Type: text/plain; charset=UTF-8; format=flowed > > Hallo! > > Johannes Huesing schrieb: > > Dimitri Junker [Thu, Dec 25, 2008 at 03:29:52PM > > CET]: [...] > > > >>Da sind wir uns einig, nur ich beobachte da anderes, es werden extra > >>Fahrradwege gezeichnet die genau dem entsprechen wof?r cycleway=track > >>gedacht ist. > > Der gr??te Nachteil dieser Methode ist nun mal, dass ich > unterschiedliche Verh?ltnisse auf beiden Seiten der Stra?e nicht > abbilden kann, und die sind f?r den Radfahrer sehr wichtig. Doch das könnte man auch mit dem entsprechenden Tagging hinkriegen > > All das hier geschriebene spricht eigentlich nur daf?r, dass die > Mappingregeln in diesem Bereich DRINGEND grundlegend gekl?rt und mehr > festglegt werden sollten. Mein Reden! > > Es ist sehr frustrierend, wenn man sich in diesem Bereich z.B. durch > Abfahren der Wege mit GPS M?he gibt und dann h?rt "die Wahrheit ist zu > kompliziert, k?nnen wir nicht darstellen" (ein Radweg-Rendrer m??te es > nat?rlich k?nnen) Deswegen habe ich lobend erwähnt das ich schon sehe das sich manche sehr viel Mühe geben! Danke dafür! Das ist das Problem, viele Dinge sind unausgegoren, oder wir sind nicht in der Lage verbindliche Regeln zu finden. Das führt zu Frust, weil man sich mit etwas Mühe gibt und der nächste es ändert, weil er es für falsch hält. Darum brauchen wir verbindlichere Regeln auf die wir uns irgendwie einigen müssen! Ein Konsens reicht nicht! Denn was ist denn Konsens, da werden wir schon Probleme haben das zu spezifizieren > . Ob ein Radweg ein Track auf dem B?rgersteig oder eine > lane auf der Stra?e ist, ist f?r unsichere, ?ltere Radfahrer sehr > entscheidend. cycleway=track und cycleway=lane unterscheiden das. > > Dann m??te man ehrlicherweise sagen: Eine Radfahrkarte (speziell im > st?dtischen Breich) werden wir niemals hinbekommen. Doch das bekommt man trotzdem hin! Und als Radfahrer, der ich bin, wünsch ich mir das auch! Und arbeite daran! > > > -- > Mit freundlichen Gruessen > > Wolfgang Wienke Mit freundlichen Grüßen Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kreuzug Radwege
Am Freitag, 26. Dezember 2008 08:17:45 schrieb talk-de-requ...@openstreetmap.org: > Wolfgang Wienke schrieb: > > Hallo! > > > > Johannes Huesing schrieb: > >> Dimitri Junker [Thu, Dec 25, 2008 at 03:29:52PM > >> CET]: [...] > >> > >>> Da sind wir uns einig, nur ich beobachte da anderes, es werden extra > >>> Fahrradwege gezeichnet die genau dem entsprechen wof?r cycleway=track > >>> gedacht ist. > > > > Der gr??te Nachteil dieser Methode ist nun mal, dass ich > > unterschiedliche Verh?ltnisse auf beiden Seiten der Stra?e nicht > > abbilden kann, und die sind f?r den Radfahrer sehr wichtig. > > > > All das hier geschriebene spricht eigentlich nur daf?r, dass die > > Mappingregeln in diesem Bereich DRINGEND grundlegend gekl?rt und mehr > > festglegt werden sollten. > > Die Tags auf rechts/links zu erweitern ist ja nicht sonderlich schwer, > wurde auch schon mehrfach vorgeschlagen (z.B. [1]), auch f?r > B?rgersteige, die ja auch manchmal nur auf einer Seite verlaufen oder > garnicht vorhanden sind. > > F?r kompliziertere F?lle m?ssen dann eben Mapping Schemas mit Relations > entwickelt werden. Damit lie?en sich dann auch Abbiegeregeln und sowas > erfassen. Allerdings braucht man das sicherlich nicht f?r alle Radwege, > die meisten lie?en sich auch mit einfachen Tags brauchbar erfassen. > > Der Vorteil an einfachen Tags ist nunmal einfaches Editieren. F?r Tags > mit rechts/links muss der Editor lediglich eine Warnung/Automatik beim > Umdrehen von Wegen implementiert haben. Und selbst wenn er das nicht > kann, geht es notfalls auch von Hand, auch wenn das nicht optimal ist. > > Gru? > > [1] > http://wiki.openstreetmap.org/wiki/Proposed_features/Advanced_footway_and_c >ycleway Das würde ich auch vorschlagen! Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
