Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 27.08.2018 um 15:25 schrieb Florian Lohoff: Alle anderen definitionen sind ohne Konsenzbildung/Abstimmung irgendwann mal in die Deutsche Fassung des Wiki Artikels geschmuggelt worden. Aus der ALLERERSTEN Version der engl. highway=track-Seite 26. Mai 2008: > Description > unpaved/unsealed roads for agricultural use; gravel roads in the forest etc. ETC.!!! Ist SO mit dem "etc." in die engl. highway-Seite als Erstbeschreibung am 16.8.07 eingebaut worden: https://wiki.openstreetmap.org/w/index.php?title=Key%3Ahighway=revision=44789=44694 Ergo: Im Wiki war track offenbar noch nie exklusiv auf Feld und Wand festgelegt. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 27.08.2018 um 15:34 schrieb Florian Lohoff: und so wenn das dann freigegeben ist: http://www.wsa-regensburg.wsv.de/images/Deg_klein_00018.JPG "Frei für Fußgänger und Radfahrer auf eigene Gefahr" und Motorfahrzeuge verboten. Landeswaldgesetz BW: § 37 Betreten des Waldes (1) Jeder darf Wald zum Zwecke der Erholung betreten. Das Betreten des Waldes erfolgt auf eigene Gefahr. ... Etc. Radfahren erlaubt, Motorfzg. nicht. Also sehr ähnliche Regeln auf den Betriebsgeländen der Forstwirtschaft. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 26.08.2018 um 22:49 schrieb Florian Lohoff: Wasserwirtschaft hat aber nichts mit Wasserstraßen zu tun. Habe ich ja ausführlich dargelegt. Wassewirtschaft ist Wassergewinnung. Das ist AUCH Wasserwirtschaft, Wasserbau an Gewässern gehört aber auch zur Wasserwirtschaft. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 27.08.2018 um 10:18 schrieb Martin Koppenhoefer: Track + in den meisten Fällen Fahrradweg bzw. Fahrradstrasse, oder Wanderweg, wie taggt man denn track und Fahrradweg auf demselben way? Wer mal in Wald- oder Naturschutzgesetze (für Feldwege) schaut, wird feststellen, dass auch Feld- und Waldwege für Fußgänger und Radfahrer nur ein eingeschränktes Nutzungsrecht haben, insbesondere ist es stets eine Benutzung auf eigene Gefahr, "typische Waldgefahren" wie rumliegende Äste gehen zu Lasten der Radfahrer. Insofern ist das zum "Benutzung auf eigene Gefahr" bei Wasserwirtschaftswegen sehr ähnlich. Ohne abweichende Beschilderung läuft die Radroute eben über einen track. Nix überraschendes in uneren Landen ... Sollte dort ein blaues Radwegschild nach StVO stehen, ggfs. mit "...wirtschaftlicher Verkehr frei" sieht die Verteilung der Rechte m.E. anders aus: Der Radfahrer (und Fußgänger) wäre nicht mehr Gast, sondern Hauptnutzer, der Wirtschaftsverkehr nur noch nachrangiger Nutzer und m.E. auch eine andere Verkehrssicherungspflicht. Das würde dann einen cycleway oder Artverwandtes rechtfertigen mit motor_vehicle=passendes Hier geht es um "Firmengelände" Wenn man denn die WSV als "Firma" bezeichnen will - das wäre dann aber auch beim Landwirt so (auch wenn die Firma einen Kleinbauern viel kleiner ist als die WSV (wobei die Landwirtschaften durch Industrialisierung und Fusionierung immer grösser werden). das Betriebsgelände ist der Weg, analog wäre das beim Landwirt der > Feldweg. Diese sind aber meist öffentliches, unparzelliertes Land. Eben! "Firmengelände" der Bauern etc. Und nicht überall ist der Feld- oder Waldweg in öffentlichen Besitz, viele sind auch in Privatbesitz. Also so kompliziert finde ich die Sache nicht ... Noch zwei meiner Antworten aus dem Forum: Wirtschaftswege dienen bzgl. Motorfahrzeugen nur einem sehr eingeschränkten Nutzerkreis, nämlich den Bewirtschaftenden, bei Feldern den Landwirten, bei Wäldern den Forstwirten und Jägern, an Gewässern und Brunnen eben den Wasserleuten. Bzgl. nichtmotorisierten Verkehrsteilnehmern wird diesen nur ein eingeschränktes Gastrecht mit Benutzung auf eigene Gefahr eingeräumt. Nichtwirtschaftswege dienen dagegen auch Nichtwirtschaftenden als Fahrweg, bei "Anlieger frei" auch der Tante des Bauern, die auf Kaffeebesuch kommt, dem Postboten, Hafennutzer, ... Ohne "Anlieger frei" jedem x-beliebigen Menschen, also Erholungssuchende. Verkehrssicherungspflichten gelten vollumfänglich, Nichtmotorisierte haben nicht nur ein eingeschränktes Gastrecht auf den Wegen. Wirtschaftswege und Nichtwirtschaftswege werden auf vielen Karten anders gerendert, ohne dass man Details beim Anschauen aufgedrängt bekommt. Schon auf flüchtigem Blick sollte ich ungefähr rausbekommen können, ob ich da lang darf oder nicht ... Der Haupttag sollte also stimmig sein und nicht durch 1024 Zusatztags umgedreht werden. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 12.08.2018 um 18:34 schrieb Martin Koppenhoefer: Zufahrten zu anderen technischen Anlagen wie Häfen, Staudämmen, Brunnen und Transformatoren, etc. könnte man immer sagen, die Wege dienten der “Bewirtschaftung”. Bei einem Hafen gibt es Wirtschaftsverkehr, keinen Bewirtschaftungverkehr, genauer gesagt: *Jedermann*, der Waren versenden/empfangen will, ist im Hafen willkommen und in einigen Hafenteilen auch jeder Jedermann ohne Verschiffungsabsichten ... Beim Rest kommt's drauf an. Ist am Staudamm eine Eckkneipe, ist's wieder allg. Wirtschaftsverkehr ;-) Oder ein Parkplatz für jedermann ... Brunnen wiederum wären für mich eher Wirtschaftswege. Bei den drei mir bekannten Brunnenwegen änderte sich das aber in letzter Zeit: Der war bis kürzlich track: https://www.openstreetmap.org/way/154310584/history Der bis vor einem Jahr auch: https://www.openstreetmap.org/way/4325103/history Der bis vor 2 Jahren: https://www.openstreetmap.org/way/158364694/history ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 13.08.2018 um 14:18 schrieb Florian Lohoff: Wir lesen den Absatz zuende: Eigentlich müßig, weil das lediglich die Frage betreffen könnte, ob jemand aus einem Wasserwirtschaftsweg (egal, ob Flüsse, Bäche, Teiche, Talsperren, Kanäle oder Meerdeiche bewirtschaftet werden) beim Einfahren in eine übergeordnete Straße Vorfahrt haben könnte, weil diese nicht explizit in § 8 erwähnt werden. Um diesen evtl. StVO-Mangel mögen sich die Anwälte udn Richter kloppen, trotz evtl. offener Vorfahrtsfragen bleibt ein Wirtschaftsweg ein Wirtschaftsweg, egal was bewirtschaftet wird ... ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 09.08.2018 um 09:57 schrieb Christoph Hormann: Bei highway=track ist die land- und forstwirtschaftliche Nutzung übrigens keine abschließende Aufzählung von möglichen Nutzungen, im Englischen steht da ein 'etc.' dran. Hier kann man die wasserwirtschaftliche Nutzung in Analogie durchaus mit einbeziehen, denn da sind ja erhebliche Ähnlichkeiten. Wie der Feldweg primär zum generellen Zugang zu den angrenzenden Feldern dient, dient der wasserwirtschaftliche Weg zum Zugang zum angrenzenden Gewässer in der Strecke. +1, insbes. zum "etc." ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] access tag / was möglich oder erlaubt ist Was: Wege des WSV an den Kanälen / tagging
Am 10.08.2018 um 00:49 schrieb Martin Koppenhoefer: Treppen sind Fußwege, an Gehwegen steht auch nicht überall ein Schild, > trotzdem darf man die nicht befahren. Treppen sind keine _Fahr_bahnen. par.2 StVO https://www.gesetze-im-internet.de/stvo_2013/__2.html § 2 ist aber eigentlich nur bei Straßen anwendbar mit mehreren Straßenteilen, dann folgert aus der sichtbaren Existenz eines straßenbegleitenden Gehwegs die Separierung in Fuß- und Radverkehr nach den §§ 2 und 25. Treppen sind selten straßenbegleitend ... Bei separaten Wegen ohne Fahrbahn nebendran ist es ohne Schild nicht mehr eindeutig, ob es Gehweg, Radweg, Feldweg, schmale Straße, ... ist ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wege des WSV an den Kanälen / tagging
Am 22.08.2018 um 13:43 schrieb chris66: Habe im Forum eine (inoffizielle) Abstimmung eingestellt: Meine dortige, von schon zweien bestechend empfundene Antwort auch hier: Ich weiß nicht, wie man da auf service kommen soll ... In der Reihe ... - Forstwirtschaftsweg, - Landwirtschaftsweg, - Wasserwirtschaftsweg ... gibt es die Gemeinsamkeit "Wirtschaftsweg", also track Würde man ... - das Erreichen des eigenen Kanals ... als bestimmend annehmen, um es als service zu bezeichnen, müsste man ... - das Erreichen des eigenen Ackers, - das Erreichen des eigenen Waldstücks oder Hochsitzes ... auch als Anlass nehmen, alle sonstigen tracks zu service zu machen ... Ach und noch was: Die Nutzungsbedingungen sind bei den drei Wirtschaftswegen auch im Prinzip gleich, wenn man sich das abgebildete Schild anschaut: - Kfz nur ein ganz spezieller Nutzerkreis (kein Postbote zum Gehöft) - Rad und Fuß alle, aber auf eigene Gefahr Feld- und Waldwege sind auch oft Privateigentum, je nach alten Gewohnheiten der Gegend. ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Mal wieder: Remapping - was darf, was nicht
Am 01.03.2012 02:36, schrieb Stephan Wolff: Die Entscheidung der LWG, Splits nicht zu berücksichtigen, macht die technische Auswertung viel einfacher, aber sie führt Bewertungen der Urheberschaft an einzelnen Tags ad absurdum. Quelle? Das würde in der Tat den ganzen Relizenzierungsprozess (merke: die Löscherei wird ausschließlich wegen dem Urheberrecht gemacht!) vollends ad absurdum führen ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Wiki-Text zu remapping
Am 29.11.2011 21:01, schrieb Frederik Ramm: On 11/29/2011 05:01 PM, Martin Koppenhoefer wrote: berücksichtigst Du eigentlich auch Löschungen? Werden mit der Lizenzumstellung die Objekte, die von Zustimmern erstellt und von Nichtzustimmern wieder gelöscht wurden, dann wieder hergestellt? Müsste man doch eigentlich, oder? Ich rechne nicht damit, dass bei der Lizenzumstellung solche Objekte, die von Ablehnern geloescht wurden, wiederhergestellt werden. Wenn ein Objekt erstmal eine Zeit lang geloescht war, dann gehe ich davon aus, dass es an Nuetzlichkeit verloren hat (weil es natuerlich niemand aktualisiert, verifiziert, korrigiert hat). Das ploetzliche Wiederauftauchen lauter solcher Objekte waere glaube ich eher stoerend. Oftmals ist bspw. ein POI Vorläufer eines buildungs. Beim Umstellen auf zweigleisige Darstellung von Straßenbahnstrecken habe ich bspw. oft zwei Gleise vom Stadtzentrum aus nagelneu gemappt und dabei die alte Linie stückweise gelöscht. Von daher gehören alte/neue Objekte oft genug direkt zusammen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Oneway bei Bachläufen?
Am 18.11.2011 14:26, schrieb Dennis Hesse: Vor allem, weil halt die Zeiten nicht immer gleich sind, anders als bei Einbahnstraßen, die zeitabhängig die Richtung ändern. ... = obey_moon ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Oneway bei Bachläufen?
Am 18.11.2011 13:14, schrieb Jo: oneway bezieht sich auf die Farhtrichtung des Schiffes. Die Fliessrichtung des Wassers ist das eigentlich überhaupt wichtig? Wenn Du in einem Ruderboot sitzt, könnte die Stärke der Gegenströmung auf Dauer relevant werden ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] [bulk]: Re: Oneway bei Bachläufen?
Am 18.11.2011 13:23, schrieb Dennis Hesse: Das geht so weit, dass die Schifffahrt gerne genau den Kenterpunkt der Tide weiss, um mit dem Höchststand der Tide im Hafen loszumachen und auszulaufen, um möglichst viel Wasser unterm Kiel zu haben … ... oder um einfach, um mit möglichst wenig Energieaufwand ein- oder aislaufen zu können. ... oder um den Zeitpunkt einer Dockschleusung zu kennenm wenn man 'n beten groß ist für die Schleuse ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tidenzeiten [war:Re:Oneway bei Bachläufen?]
Am 18.11.2011 15:30, schrieb lulu-...@gmx.de: Wanderweg Cuxhafen - Neuwerk durch's Watt bekommt dann Richtige Havenstädte schreiben sich mit v! Nur Möchtegernehäven weit wech von salzighaltiger Luvt wie Ludwigs- und Friedrichshafen schreibt man välschlich mit f! Opening_Hours=Niedrigwasser-2h bis Niedrigwasser+1h und wann Tide ist kann man aus dem Längengrad errechnen. Allns kloar? Da spielt lokal noch 'n beten mehr als der Längengrad rein ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] vermehrt geplante Straßen
Moin Ein Mapper MrWebber http://www.openstreetmap.org/user/MrWebber scheint di eletzte Zeit einige geplante Straßen in OSM eingebaut zu haben. Darunter in Karlsruhe auch die Nordtangente http://www.openstreetmap.org/?lat=49.0388lon=8.3388zoom=15layers=M wobei deren Verlauf im Westen ein ziemlich veralteter Stand sein muss, die mit der Trasse im aktuellen Flächennutzungsplan http://geodaten.karlsruhe.de/nvk/index.jsp?x=3452000y=5434000scale=2layer=layer2_1 nix mehr zu tun hat (die wiederum inkompatibel zur aktuellen Planfeststellung 2. Rheinbrücke ist ... http://www.rp-karlsruhe.de/servlet/PB/menu/1326356/index.html ) Auch um den Hopfenbergtunnel und die B35 bei Bruchsal ist es politisch ziemoiuch ruhig geworen, ohne den exakten Status zukennen ... Vielleicht sollte man seine Eintragungen mal generell genauer auf Aktualität etc. prüfen und ggfs. mal nach den Quellen fragen (Ich kann's derzeit leider nicht, da er in Forum und Wiki nicht zu finden ist.). Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterschiedliche Ansichten zu surface-Werten
Am 28.10.2011 10:03, schrieb Martin Koppenhoefer: Man könnte auch einen Key einführen, der klarer ist, so was wie maximale Korngröße der Hindernisse, d.h. man könnte dort den Maximaldurchmesser der üblichen Oberflächensteinchen taggen, evtl. auch in festgelegten Klassen (z.B. 0-3 mm, 3-10mm, 10-25mm, 25-60mm, 60-150 mm, über 150mm), evtl. aber auch explizit, dann ergibt sich das Problem, zwischen Sand, Kies, Split, Feinkies, Grobkies etc. abzugrenzen vielleicht weniger... Eigentlich sind die Korngrößen für Sand, Kies, ... durchaus definiert. Ob international einheitlich oder nicht, da müsste man sich mal durch die Wikipedias etc. recherchieren, um sie dann ggfs. in unser Wiki zu übertragen ... Am 28.10.2011 10:30, schrieb Peter Wendorff: Klingt gut, aber dann müssten konsequenterweise auch andere Eigenschaften mit aufgenommen werden: - Kantigkeit (zwischen zerbrochenen Muschelschalen und kleinen, runden Kieseln ist ein himmelweiter unterschied, wenn ich barfuss drüber laufen will) Das geht m.E. durchaus aus den verwendeten Begriffen für lose surface-Materialien hervor. Rundkies ist pebblestone oder so, wären kantiger Schotter (fine_)gravel wäre. Muscheln kommen hierzuland eher seltener vor, weswegen ich das gerade nicht auswendig weiß ;-) - Einsinkbarkeit - mir fehlt der passende Begriff, aber wer in sandigen Gebieten schonmal unbefestigte Wege mit dem Rad gefahren ist, weiß vermutlich, was ich meine Für die losen Materialien (sand, gravel, ...) kann man von einer gewissen Einsiknkbarkeit ausgehen, während der Materialmix von künstlich angelegten wassergebundenen Wegen (oder auch im Laufe der Zeit entstandenen Materialmischungen, wiel jemand Schotter auf Naturboden warf oder so, nicht immer klar erkennbar) eigentlich für eine gewisse Stabilität sorgt = compacted Daneben gibt es ja auch noch den key smoothness mit seinen Abstufungen, der für einsinkfähige Untergründe nie sonderlich gut ausfallen kann ... Von daher braucht es nicht unbedingt neue tags. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Unterschiedliche Ansichten zu surface-Werten
Moin Gibt's eigentlich Vorgehensweisen für Streitigkeiten/edit wars im Wiki? http://wiki.openstreetmap.org/wiki/Disputes scheint nur Streitigkeiten in der Karte selbst zu behandeln, aber nicht im Wiki? Und es sind nur 3 Personen benannt, die nicht den Anschein machen, als sprächen sie deutsch, was aber glaub praktisch wäre, weil auch deutsche Seite betroffen sind und der Streit im dt. Forum startete: http://forum.openstreetmap.org/viewtopic.php?id=14098 Dort bevorzugt Taunide eine Interpretation von fine_gravel die nicht der original englishcen sruface-Seite entsprach, wobei seine Definition ungefähr der schon länger vorhandenen Definition von compacted entsprach, die es schon so seit 2,5 Jahren im Wiki gibt, fine_gravel kam erst später Betroffene Wikiseiten: http://wiki.openstreetmap.org/w/index.php?title=DE:Reitenaction=history http://wiki.openstreetmap.org/w/index.php?title=Template:De:Map_Features:surfaceaction=history http://wiki.openstreetmap.org/w/index.php?title=Template:Map_Features:surfaceaction=history Diskussion nun auch dort neben Forum: http://wiki.openstreetmap.org/wiki/Talk:Key:surface#gravel_.2F_water-bound_.2F_macadam http://wiki.openstreetmap.org/wiki/Talk:Key:surface#fine_gravel Es scheint unter http://wiki.openstreetmap.org/wiki/Category:Wiki_templates auchnix zu geben, dass anzeigen könnte, dass es gerade strittige Sachen in einer Wikiseite gibt. Bevor ich mir da mit Taunides bisheriger Einzelmeinung edit wars ausfechte, wüsst eich gerne, wie sowas sonst gelöst wird. MfG Heiko / Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gesperrte Wege im Nationalpark Harz
Am 14.07.2011 23:09, schrieb Peter: 2) Tourismus/Nationalparkverwaltung. Die wollen nicht das es den Wanderern aus 1) so geht wie dort beschrieben. Dazu wollen die nicht das die Wanderer dann doch den verbotenen Weg gehen und seltene Pflanzen zertrampeln. Wenn man sich Sorgen um seltene Pflanzen macht, dann renaturiert man den Weg eh und ruckzuck ist nix mehr da, was die Bezeichnung Weg verdient und somit kann man auf highway=abandoned umtaggen oder was auch immer, nix mehr rendern ... Wenn überhaupt was mappenswertes vorgefunden wurde, dann wohl deswegen, weil der Weg für den internen Gebrauch erhalten bleibt und somit passierbar ist auch für Bein kaputt, Blut. Humpeln mit Kumpeln. Dann ist der Grund der Sperrung des Weges eher im Schutz des Wildes und der brütenden Vogelwelt etc. zu suchen. Von ganz wenigen Ausnahmen mal abgesehen nähme das wohl nur Schaden, wenn dort regelmäßig Touris langdappen, aber nicht, wenn alle halbe Jahre die Naturparkverwaltung zur Bewirtschaftung durch muss oder der eine humpelnde Kumpel alle paar Monate. Die Wildtiere müssen ja auch mit freilaufenden/-fliegenden Raubtieren rechnen, leben also eh nicht absolut stressfrei. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] highway=axis
Am 01.07.2011 00:44, schrieb Frederik Ramm: PS: Gibt es das eigentlich ueberhaupt, dass Strassen und Schienen ueber die gleiche Bruecke fuehren? Ich kenne, zumindest in Deutschland, glaub ich nur separate Bruecken, selbst wenn beides direkt benachbart ist. Ein besonders schönes Drehbrücken-Exemplar mit Gleisen nicht in der Fahrbahn (wie bei der Wintersdorfer Brücke bspw.): http://www.brueckenweb.de/2content/datenbank/bruecken/2brueckenblatt.php?bas=4861 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fahrradstraszen
Am 22.06.2011 03:55, schrieb phobie: Leider gibt es bis heute keinen Tag für Fahrradstraßen und das Rendering ist bis heute unbefriedigend. Osmarender rendert k=bicycle_road|cycleroad|cyclestreet v=yes k=cycleway v=cyclestreet k=highway v=cycleroad jeweils in den Varianten mit/ohne Autoverkehr in graphischer Analogie Fahrradstr. ohne Autoverkehr wie Fußgängerzone Fahrradstr. mit Autoverkehr wie verkehrsberuhigter Bereich unter Verwendung der Geh- bzw. Radwegfarbe bicycle_road=yes ist davon die wikifizierte tagging-Variante http://wiki.openstreetmap.org/wiki/Key:bicycle_road 131x verwendet Andere Varianten wurden vorher praktisch genutzt, heute laut taginfo: cycleroad=yes 8x cyclestreet=yes 56x cycleway=cyclestreet 95x highway=cycleroad scheint ausgestorben, gab es laut osmdoc 2009 8x Zu tram: Ich kenne bis heute keine bessere Möglichkeit um zu beschreiben, das Bahnschienen in der Straße verlaufen. tram ist es trotzdem nicht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:zone
Am 22.06.2011 10:08, schrieb Wolfgang: Sachlich gesehen ist es so, dass auch die richtige Straßenbahn früher Güterwagen auf den Straßen befördert hat. Trotzdem war's eine Straßenbahn Außerdem ist in einigen Städten der Übergang zwischen Straßenbahn und Eisenbahn fließend. Als Karlsruher, also sozusagen Ortskundiger bzgl. der Erfindung des angeblich fließenden Übergangs, der vor Sperrung der Unentschiedenen noch das Karlsruher Schienennetz (Eisenbahn wie Straßenbahn) gleistreu mappte, kann ich sagen, dass da nix überfließt, weil tram = BOStrab rail = EBO stets sauber getrennt sind aus vielerlei Gründen. Dass der genaue Punkt manchmal nur mit sehr viel Ortskunde und Recherche zu finden ist, steht auf einem anderen Blatt, aber wer behauptet schon, OSM sei ein stets triviales Hobby ;-) Andere Sachen wie tram contra light_rail sind da fließender und mag auch sein, dass tram/rail in anderen Ländern fließt ... Dann nehmen wir dafür waterway ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnen in der Straße und Straßenbahnen (war: DE:zone)
Am 22.06.2011 14:59, schrieb Wolfgang: Ich mappe, was ich sehe. So lange ok, so lange man sich nicht über Korrekturen beschwert von Leuten, die besser wissen, was drangenagelt sein müsste ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DE:zone
Am 22.06.2011 14:57, schrieb M∡rtin Koppenhoefer: Am 22. Juni 2011 14:43 schrieb flylowfligh...@googlemail.com: +1, ich war schon immer für highway=cycleroad (o.ä.) aber bisher (=in den letzten Jahren) war die Mehrheit dafür, das nicht zu machen. das gehört in eine zusatz tag analog zu motorroad=yes. -1, warum? Gehört highway=pedestrian auch in einen Zusatztag? Und highway=cycleway? Es ist eine eigene Klasse, und daher gehört es auch in keinen Zusatztag. highway=living_street würde ich auch als Unfall definieren und in ich nicht. Warum sollte das ein Fehler gewesen sein? Da es highway=pedestrian (auch da kann Fahrzeugverkehr zugelassen sein) und living_street schon länger gab, hätte highway=cycleroad prima da reingepasst. Nun denn *schulterzuck*, mit bicycle_road=yes wird die Welt auch nicht untergehen ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderwegeverlauf und Kartenwerk der Landesvermessung
Am 17.06.2011 00:03, schrieb Simon Poole: Ich hab mir mal kurz die Mühe gemacht und eine Markenrecherche in FR gemacht. Der Wanderverband ist recht fleissig in Markeneintragen, was aber wohl relevant ist, ist die französische Marke 3283810. Bildmarke: rotes Quadrat mit weissem GR. Eingetragen für die Klassen 18, 21 und 41. Also dürfte ich Griechische Rosinen mit weiße, GR auf rot verkaufen (vermutlich, bin jetzt zu faul zum Nachschlagen der 18, 21, 41) Am 16.06.2011 23:41, schrieb Simon Poole: Also es ist eigentlich genau andersherum, GR dürfte man als Bezeichnung für Äpfel etc verwenden, aber nicht für Wanderwege. Ich gehe mal davon aus, dass der Wanderverband Routenführer oder ähnliches herausgibt und für solche die Marke nutzt, d.h. eine Routenbeschreibung oder Darstellung, die die gleiche Bezeichnung verwendet könnte sehr wohl die Rechte des Verbandes verletzen. Dürfte aber wohl eher eine sehr schwache Marke sein, aber wer hat schon Lust so was auszufechten. Normalerweise darf im Markenrecht außer Porsche selbst keiner Autos bauen und unter dem Namen Porsche vemarkten. Es ist aber kein Problem, wenn man eine Annonce schaltet Ich verkaufe meinen Porsche 911, man muss sich nicht vekünsteln mit Ich verkaufe mein Auto, das unter dem Ergebnis von 811+100 bekannt ist Und natürlich ist es kein Problem, in OSM ein Porsche Autohaus aufzunehmen oder so. Und s.a. Copyrigth-Hinweis auf http://de.wikipedia.org/w/index.php?title=Datei:Porsche_logo.png Vielleicht könnte man auch alle Porsche-Autohäuser in OSM mit dem Porsche-Logo markieren nach dieser Regel, müsste man prüfen. M.E. heißt das für GR: Natürlich darf NICHT der Tourismusverband Région Kleinkleckère sein eigenes Wandernetz mit GR markieren, damit es interessanter klingt. Aber wenn er sagt Intretoupfe liegt am GR 4711 dürfte das nach meinem Verständnis von Markenrecht legal sein. Oder ticken die Franzosen so anders? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tagginghilfe innerstädtische Fußwege
Am 10.06.2011 13:27, schrieb Markus Straub: gibt es das: highway=footway area=yes Ja, ist aber ein PLATZ für Fußgänger area=yes kommt dann zum Einsatz, wenn geschlossene Polygone doppeldeutig sind: - ringförmiger Weg oder doch eher - ein Platz? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deichflächen
Am 06.06.2011 14:17, schrieb Claudius: Am 06.06.2011 12:28, Jan Tappenbeck: In der Regel sind die Führungslinien - oftmals Wege - als embankment=yes getaggt. Leider wird hierfür ja wohl derzeit keine Signatur gerendert. man_made=dyke t@h-Karte rules, da werden embankment und dyke auch unterschiedlich gerendert. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kandidaten fuer weitere tile layer auf osm.org?
Moin Es ist also wichtig diese Vielfalt herauszuheben und diese Neueinsteigern moeglichst gut zu vermitteln. Eine (einfache) Moeglichkeit diese Vielfalt etwas besser der breiten Oeffentlichkeit klar zu machen waere indem man zusaetzliche (spezialisierte) Karten auf der Homepage von OpenStreetMap.org anzeigen wuerde. Schöne Idee. Angesichts der Kriterien wird es wohl nicht allzu viele Kandidaten geben. Vielleicht wäre es daher eine Idee, *zusätzlich* auch eine Liste verfügbarerer anderer Karten anzubieten a la ... [2] http://wiki.openstreetmap.org/wiki/Featured_tiles ... wo ja auch schon Infos wie Aktualisierungsrhytmus, Serverstatus, ... gesammelt werden, fehlt nur noch der Link ;-) Plus Region vielleicht noch für eher regionales. So 'ne Liste gibt's sicher irgendwo schon und ganz sicher schlummert der Link dahin in meinen gefühlt 10.240 OSM-Bookmarks ... Was fehlt wäre eine solche Liste, die mit 1-2 Klicks von openstreetmap.org aus erreichbar ist unter weitere Karten bspw. im Block Hilfezentrum, Dokumentation, ... (Wenn sich dieser Klick auch noch den gerade aktuellen Ausschnitt samt Zoomlevel merken und auf die Links zu den Karten übertragen könnte, wäre das optimal ... Vielleicht geht das ja einfach, wenn man neben Permalink, Shortlink noch ein more maps einbaut und auf ein PHP-Script zielt?) Wenn man in so einer Liste die Karten mit starkem Server nach oben stellt und ansonsten sehr viele drin stehen, dürfte die einzelne Karte sicher nicht s oft geklickt werden, dass ein Server in die Knie gehen würde ... ... es sei denn, die Karte entpuppt sich als DER Hammer, dann ist sie es aber auch wert, dass sich jemand mit starkem Server ihrer annimmt ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 20:28, schrieb Henning Scholland: Im Falle vom Fußweg/Radweg/Straße bspw. könnte man kennzeichnen, dass der Radweg und der Fußweg zur Straße gehören und nicht einen eigenständigen Weg bilden. Das ist eine Info, die auch zum (Rad-)Routen nützlich ist. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Renderer-Zukunft, was: Re: Bahnstrecke vs. Gleis
Am 27.05.2011 17:13, schrieb Torsten Leistikow: Frederik Ramm schrieb am 26.05.2011 22:35: man muss das halt beim Rendern in den Griff kriegen. Solche Aussagen ohne konkrete Vorschlaege (oder auch nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Such mal im Wiki nach dem Stichwort Linienbündel Am 26.05.2011 22:35, schrieb Frederik Ramm: und es wirkte etwas seltsam, dass ein einzelner Way, der eine Trasse symbolisierte, sich an einem Bahnhof ploetzlich auffaecherte zu lauter Gleisen und dann hinter dem Bahnhof wieder zu einer Trasse zusammenlief - ziemlich unlogisch, aber ich habe immer angenommen, dass das halt ein voruebergehenden Zustand ist, bis irgendwann mal alle Gleise vollstaendig erfasst sind. Nicht unlogisch, sondenr normal. Das wird auch so gemacht auf Karten, auf denen die Zweigleisigkeit ggü. Eingleisigkeit durch 'nen Querstrich mehr dargestellt wird (bspw. TK50) oder auch nicht (Stadtplan KA 1:20.000). Auch da fächert sich ein Bahnhof durchaus auf in passenden Maßstäben. Aber nicht unbedingt zu voller Gleiszahl, sondern ca. der Hälfte. So war der K'her Hbf auch vorm gleistreuen Mapping. Im Gegensatz zu TK50 und K'her Stadtplan aber mit nach Osten korrekt raus geführten DREI Strecken. Die bei den amtlichen gezeigten Fusionen lassen Eisenbahnfans die Nackenhaare aufstellen ... ;-) Damals schon konnte man beobachten, dass das Auffaechern der Gleise auf den hohen Zoomstufen zwar gut war, auf mittleren Zoomstufen aber haessliche schwarze Flecken im Bahnhofsareal erzeugte. Bei Osmarender habe ich immerhin das Symbol ab einem bestimmten Maßstab gewechselt (wie auch bei Radwegen etc.) Aber vom Optimum ist das natürlich noch weit entfernt... Das ist eine Herausforderung, der man beim Rendern Herr werden kann und muss. Eventuell *kann* man dem Renderer irgendwie helfen, indem man eine Gruppe von Gleisen zu einer Bahntrassen-Relation zusammenfasst und dann neue Funktionalitaeten im Renderer einbaut, die in der Lage sind, solche gruppierten linienfoermigen Objekte geeignet zu vereinfachen. Man muss aber dabei auch den Fall abfangen, dass eine solche Relation fehlen koennte. Deswegen vielleicht eher ein Prozess, der versucht, automagisch das passende zusammenzuwürfeln und nur dort, wo was unpassendes rauskommt, Hinweise geben, was zusammengehört und was nicht ... Das Problem stellt sich ja auch beim Thema separat gemappte Rad- und Gehwege, Straße neben Fluss, aber auch bei Haus neben (mit dem Zoom wachsender) Straße, Sackgasse, die knapp vor Straße endet, ... Da wird man fuer das Standard-Rendering mindestens am osm2pgsql, wenn nicht sogar auch am Mapnik herumdrehen muessen. Das wird nicht leicht, aber danach haben wir eine Karte, die auf allen Zoomleveln besser aussieht als vorher. Ich fürchte, wir müssen langfristig Mapnik, Osmarender Co. ganz wegschmeißen, dann das sind alles keinerlei kartographische Programme, sondern einfachste Umetikettierer, die Null Möglichkeit zur Koordinatenveränderung haben (außer dass sie gelegentlich Kurven durch die Stützpunkte legen statt Geraden, auch nicht immer so doll... aber auch da bleiben die Stützpunktkoordinaten unverändert). Am deutlichsten wird es bei Osmarender, den's auch in einer (lahmen) XSLT-Variante gibt ... Problem ist auch das Ausgabeformat SVG, das in seinen Darstellungsmöglichkeiten limitiert ist, daran scheitert in Osmarender das Rendern einseitiger Radwege. Für alle genannten Probleme müssen aber Koordinaten gerechnet werden für - die Mittellinie (ob nun mit real existentem Objekt wie Tram, ähm, vorm gleistreuen Mapping, oder nur virtuell als Mitte zwischen zwei Fahrbahnen) - alle parallelen maßstabsabhängig (!) auf die Mitte abgestimmten Wege wie Gleise, Fahrbahnen, Radwege - alle Objekte wie Häuser, Bäume, POIs, Sackgassenenden, ... die ggfs. zur Seite geschoben werden müssen - ... Das ist vermutlich zu komplex, um es jedesmal zu machen, sprich: solche Geometrien muss man wohl zwischenspeichern und eine automatische Aktualisierung bei Veränderung der Basisgeometrien organisieren. Etc. Und man muss verstärkt gewisse Sachen wegwerfen und vereinfachen müssen in passenden Zooms wie jetzt schon einige Wegklassen peu a peu in Mapnik In der Zwischenzeit - solang eben die Renderer nicht gut genug sind - muessen wir Rueckschritte hinnehmen. Das ist an vielen anderen Fronten auch so (z.B. einzelne Haeuser, die man auf kleineren Zoomleveln eigentlich lieber als grosse bebaute Flaeche anzeigen will). Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Erst wenn genug Leidensdruck durch massenhaft Details aufgebaut ist, wird sich jemand dran setzen, obige Liste abzuarbeiten ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 27.05.2011 12:26, schrieb Garry: Am 27.05.2011 10:51, schrieb Steffen Grunewald: Es gibt Autobahnen, deren Richtungsfahrbahnen deutlich abweichende Verläufe haben. In der Nähe des Altmühltals habe ich so etwas mal gesehen. Bekanntestes Beispiel in D dürfe der Albaufstieg der A8 zwischen Stuttgart und Ulm sein, in bergigen Regionen kommt das öfter mal vor. Da isses platt wie 'ne Flunder: http://www.openstreetmap.org/?lat=52.7583lon=9.6679zoom=14layers=M Kennt da jemand zufällig den Grund? Unglückliche Lösung die neue Fehlerquellen schafft da hier willkürlich entgegen der Realität ein Gleis als Master definiert wird. +1 Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 09:19, schrieb Markus: Ich möchte gern mal über quo vadis sprechen... Ei, dann hätte das eben bei den Gleisen getippte besser hierher gepasst: Ctrl-C, Ctrl-V: Am 27.05.2011 17:13, schrieb Torsten Leistikow: Frederik Ramm schrieb am 26.05.2011 22:35: man muss das halt beim Rendern in den Griff kriegen. Solche Aussagen ohne konkrete Vorschlaege (oder auch nur Vorstellungen) ueber das Wie finde ich immer besonders hilfreich. Such mal im Wiki nach dem Stichwort Linienbündel Am 26.05.2011 22:35, schrieb Frederik Ramm: und es wirkte etwas seltsam, dass ein einzelner Way, der eine Trasse symbolisierte, sich an einem Bahnhof ploetzlich auffaecherte zu lauter Gleisen und dann hinter dem Bahnhof wieder zu einer Trasse zusammenlief - ziemlich unlogisch, aber ich habe immer angenommen, dass das halt ein voruebergehenden Zustand ist, bis irgendwann mal alle Gleise vollstaendig erfasst sind. Nicht unlogisch, sondenr normal. Das wird auch so gemacht auf Karten, auf denen die Zweigleisigkeit ggü. Eingleisigkeit durch 'nen Querstrich mehr dargestellt wird (bspw. TK50) oder auch nicht (Stadtplan KA 1:20.000). Auch da fächert sich ein Bahnhof durchaus auf in passenden Maßstäben. Aber nicht unbedingt zu voller Gleiszahl, sondern ca. der Hälfte. So war der K'her Hbf auch vorm gleistreuen Mapping. Im Gegensatz zu TK50 und K'her Stadtplan aber mit nach Osten korrekt raus geführten DREI Strecken. Die bei den amtlichen gezeigten Fusionen lassen Eisenbahnfans die Nackenhaare aufstellen ... ;-) Damals schon konnte man beobachten, dass das Auffaechern der Gleise auf den hohen Zoomstufen zwar gut war, auf mittleren Zoomstufen aber haessliche schwarze Flecken im Bahnhofsareal erzeugte. Bei Osmarender habe ich immerhin das Symbol ab einem bestimmten Maßstab gewechselt (wie auch bei Radwegen etc.) Aber vom Optimum ist das natürlich noch weit entfernt... Das ist eine Herausforderung, der man beim Rendern Herr werden kann und muss. Eventuell *kann* man dem Renderer irgendwie helfen, indem man eine Gruppe von Gleisen zu einer Bahntrassen-Relation zusammenfasst und dann neue Funktionalitaeten im Renderer einbaut, die in der Lage sind, solche gruppierten linienfoermigen Objekte geeignet zu vereinfachen. Man muss aber dabei auch den Fall abfangen, dass eine solche Relation fehlen koennte. Deswegen vielleicht eher ein Prozess, der versucht, automagisch das passende zusammenzuwürfeln und nur dort, wo was unpassendes rauskommt, Hinweise geben, was zusammengehört und was nicht ... Das Problem stellt sich ja auch beim Thema separat gemappte Rad- und Gehwege, Straße neben Fluss, aber auch bei Haus neben (mit dem Zoom wachsender) Straße, Sackgasse, die knapp vor Straße endet, ... Da wird man fuer das Standard-Rendering mindestens am osm2pgsql, wenn nicht sogar auch am Mapnik herumdrehen muessen. Das wird nicht leicht, aber danach haben wir eine Karte, die auf allen Zoomleveln besser aussieht als vorher. Ich fürchte, wir müssen langfristig Mapnik, Osmarender Co. ganz wegschmeißen, dann das sind alles keinerlei kartographische Programme, sondern einfachste Umetikettierer, die Null Möglichkeit zur Koordinatenveränderung haben (außer dass sie gelegentlich Kurven durch die Stützpunkte legen statt Geraden, auch nicht immer so doll... aber auch da bleiben die Stützpunktkoordinaten unverändert). Am deutlichsten wird es bei Osmarender, den's auch in einer (lahmen) XSLT-Variante gibt ... Problem ist auch das Ausgabeformat SVG, das in seinen Darstellungsmöglichkeiten limitiert ist, daran scheitert in Osmarender das Rendern einseitiger Radwege. Für alle genannten Probleme müssen aber Koordinaten gerechnet werden für - die Mittellinie (ob nun mit real existentem Objekt wie Tram, ähm, vorm gleistreuen Mapping, oder nur virtuell als Mitte zwischen zwei Fahrbahnen) - alle parallelen maßstabsabhängig (!) auf die Mitte abgestimmten Wege wie Gleise, Fahrbahnen, Radwege - alle Objekte wie Häuser, Bäume, POIs, Sackgassenenden, ... die ggfs. zur Seite geschoben werden müssen - ... Das ist vermutlich zu komplex, um es jedesmal zu machen, sprich: solche Geometrien muss man wohl zwischenspeichern und eine automatische Aktualisierung bei Veränderung der Basisgeometrien organisieren. Etc. Und man muss verstärkt gewisse Sachen wegwerfen und vereinfachen müssenin passenden Zooms wie jetzt schon einige Wegklassen peu a peu in Mapnik In der Zwischenzeit - solang eben die Renderer nicht gut genug sind - muessen wir Rueckschritte hinnehmen. Das ist an vielen anderen Fronten auch so (z.B. einzelne Haeuser, die man auf kleineren Zoomleveln eigentlich lieber als grosse bebaute Flaeche anzeigen will). Aber jetzt das Mapping-Rad zurueckdrehen, beim Mapping zu stagnieren, bloss weil der Renderer damit nicht Schritt halten kann, das waere kontraproduktiv. Erst wenn genug Leidensdruck durch massenhaft Details aufgebaut ist, wird sich jemand dran setzen, obige Liste abzuarbeiten ;-) Gruß Mueck
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 14:07, schrieb Peter Wendorff: Am 27.05.2011 12:20, schrieb Markus: Ich könnte mir das so vorstellen: Mapper E-Verarbeitungsschicht DB ... Da hast du mich falsch verstanden! Ich bin für Mapper DB ... Die Daten des Mappers (1) werden von einem intelligenten Editor entgegengenommen und vorverarbeitet und in die Eingangs-Verarbeitungsschicht gespeichert (2). so intelligent kann die Schicht nicht sein, dass dadurch keine Informationen verloren gehen. Außerdem ist einiges in dem Bereich nicht sinnvollerweise bei jedem Upload durchzuführen. Ich wäre auch vorsichtig, allzu viel in die E-Schicht zu packen. Eins jedoch sollten Editoren -- oder wenn die es nicht machen -- die Eingangschicht der DB machen: Splits und Vereinigungen erkennen und eine saubere Historie auch für diese erzeugen. Das ist nicht nur DER Knackpunkt der Relizenzierung (ohne saubere Historie auch bei Splits und Vereinigungen ist die rechtlich angreifbar), sondern auch ganz generell lästig, wenn man die Entstehungsgeschichte eines Objekts verfolgen möchte, wann und von wem und warum bspw. Tag X drangehängt wurde an die Y-Straße ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 09:19, schrieb Markus: Andererseits brauchen wir kartografisch sinnvolle Generalisierung, und routentechnische Berechnungseffizienz. Beides fängt m.E. mit einem gemeinsamen Schritt an: Zusammenfassen, was zusammen gehört, s.a. Ctrl-C+Ctrl-V-Mail ;-) Linienbündel etc.: Sowohl beim Rendern ( Radweg/Fahrbahn sollen sich nicht überdecken), als auch beim Generalisieren (Straße mit/ohne Radweg) als auch beim Routen (Rafahrer über Fahrbahn oder Radweg) braucht man die Zusammenhänge paralleler Strukturen. Einige Teilaufgaben brauchen paar mehr (Verdrängung Straße contra Fluss), die andere nicht brauchen (oder? Hmmm... nicht zu weit rechts fahren, sonst *platsch* ;-) ), aber der geometrische Ansatz ist derselbe. Das geht alles in Richtung GIS als Zwischenschicht. Oder sowas in der Art. Jedenfalls etwas, das Koordinaten nicht nur umbildet von geographisch/WGS84 in Karten-x/y, sondern richtig analysiert und verändert: Was ist parallel zueinander? Was stößt in einem Winkel darauf? Was endet kurz davor? Und all das darf sich nicht von unsauberem Mapping beeinflussen lassen wie unterschiedlich dichte und verteilte Stützpunkte bei parallelen Fahrbahnen, Unterbrechungen durch Brücken (die tw. versetzt zueinander sind, wenn was in spitzem Winkel gekreuzt wird etc. Oder beim parallelen Radweg fehlt die Brücke ...), ... Und muss dennoch erkennen, ob ein eine Weile paralleler Radweg doch irgendwo abschwenkt ... Und dann: Was gehört davon zusammen, was nicht? Was für Aufgabe A (Verdrängung), B (Rendern), C (Routen), D (...), ...? Und wie speichert man diese Zusammengehörigkeiten ab? Wie hält man die aktuell, wenn jemand die Basisgeonetrie ändert? Und wie steuert man die, wenn die Automagik falsch zusammenstöpselt? Oder nur manuell, aber was, wenn die fehlt? Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Konzept für Daten, Karte und Renderer
Am 27.05.2011 20:02, schrieb Heiko Jacobs: Und dann: Was gehört davon zusammen, was nicht? Was für Aufgabe A (Verdrängung), B (Rendern), ... wobei da ja noch stark der Maßstab reinspielt und die Zeichenregeln des Renderers. In z18 kann man noch fast alles unverändert zeichnen. Wann die Objekte zusammenstoßen und Variationen an den Koordinaten benötigen, ist beim renderer mit dicken Linien früher der Fall als bei dem mit den dünnen ... Das macht das mit dem zwischenspeichern von Hilfsgeometrien nicht einfacher ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 26.05.2011 20:01, schrieb Torsten Leistikow: Zum Teil liegt es gerade eben daran, dass es bei railway nicht von Anfang an so praktiziert wurde. Wenn man zum Vergleich die Karten von vor 1 Jahr hat und dann sieht, dass die heutigen in dieser Beziehung schlechter geworden sind, dann muss doch irgendwas hier nicht ganz richtig laufen. Viele gleistreue Ecken im Osten der Bundesrepublik sind mind. 2 Jahre alt, Rund um Stuttgart wurde vor mind. 2,5 Jahren gleistreu gemappt. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] man_made=cutline Darstellung mapnik
Am 25.05.2011 08:06, schrieb M: Am 24.05.2011 schrieb Heiko Jacobs: Deswegen ist Suggested rendering is dashed, black line auch Murks ... Weiß oder 50% transparent wäre schon besser, aber bei Mapnik ist es so wie jetzt leicht mit einer unclassified verwechselbar ... Ja sowas in der Richtung. Strichlinie sollte es schon sein, weiss, 50% transparent, weiss, 50% transparent, Breite wie highway=path. Wenns gleichzeitig ein highway=track oder etwas anderes 'höheres' ist sollte natürlich das gerendert werden. Müsste natürlich jetzz jemand der 'mapnik Mechaniker' mitlesen. (?) ;) Bin nur 'n Osmarender-Mechaniker ... ;) Apropos ... Am 24.05.2011 11:30, schrieb M: [1] http://wiki.openstreetmap.org/wiki/Cutline ... wäre das auch was für Rückeschneisen/Rückewege? Verstehe nicht was du meinst, eine Rückegasse die nicht gleichzeitig eine 'Schneise' ist ? Im wiki steht ja folgendes: cutline=border - for cutlines that denote ownership border; cutline=section - cutlines that split forests in sections for maintenance; cutline=firebreak - cutlines that are intended to stop or delay forest fire; cutline=loggingmachine - logging machine tracks that are impassable due to lopwood; cutline=piste - skiing piste without visible tracks in the summer; cutline=pipeline - above an underground pipeline; cutline=hunting Da fehlt für mich eindeutig eine DE:-Variante ... dict.leo.org und Webster scheitern am lopwood ... loggingmachine habe ich noch nicht versucht zu finden ... Ins Auge stechen tut mir jedenfalls nichts, was ich für Rückegassen nehmen täte, die man mit Waldwegen velwechsern könnte ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 24.05.2011 17:40, schrieb Torsten Leistikow: selbst die 1:25000 Messtischblaetter enthalten zwar einzelne Gebauede aber unterscheiden nicht einzelne Gleise an. Die 25.000er in Frankreich und in der Schweiz wiederum sind wunderhübsch gleistreu! Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 24.05.2011 17:40, schrieb Torsten Leistikow: Dazu kommt dann noch das Problem Linien-Relationen, die sich auch meist nicht sinnvoll auf einzelne Gleise abbilden lassen. Die Karlsruher Straßenbahnrelationen, die schon weitgehend nach dem neueren Relations-Modell des ÖV je Richtung eine eigene Relation haben, konnte ich wunderbar dem einzelnen Gleis zuordnen, auf das sie gehören, statt dass sie sich zu zweit auf eine Strecke quetschen müssen ... Im Fernverkehr sieht das anders aus, ja, allerdings gab es dazu erst vor wenigen Monaten eine Diskussion, ob die so Sinn ergeben, weil kaum ein ICE die ganze ICE-Nummer so von Nord nach Süd komplett durchfährt, die meisten fahren nur Teile. Ich glaube aber, die Alternativenfindung versickerte. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 23.05.2011 18:02, schrieb M∡rtin Koppenhoefer: aber man sollte dafür einen eigenen Tag entwickeln und nicht den für Gleise missbrauchen oder gar umdeuten. Aus einem versickerten Proposal: http://wiki.openstreetmap.org/wiki/Proposed_features/Railway#Way tracks=n hänge ich davon an analog zu lanes=n bei Straßen. Damit alleine wäre Streckenmapping contra Gleismapping schon halbwegs erkennbar. (Nur halbwegs, weil bei echten Bahnhöfen mit mehreren Gleisen an eingleisigen Strecken ist es so noch nicht erkennbar) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] man_made=cutline Darstellung mapnik
Am 24.05.2011 11:30, schrieb M: Im Wiki steht ja bereits : Suggested rendering is dashed, black line (with possible variations based on type). If road or path is tagged alongside cutline, it takes precedence over the cutline Eine Verwechslung mit highway=path sollte natürlich ausgeschlossen werden. Deswegen ist Suggested rendering is dashed, black line auch Murks ... Weiß oder 50% transparent wäre schon besser, aber bei Mapnik ist es so wie jetzt leicht mit einer unclassified verwechselbar ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] man_made=cutline Darstellung mapnik
Apropos ... Am 24.05.2011 11:30, schrieb M: [1] http://wiki.openstreetmap.org/wiki/Cutline ... wäre das auch was für Rückeschneisen/Rückewege? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 24.05.2011 13:15, schrieb Garry: Richtungsfahrbahnen sind bei der Bahn weniger eindeutig definiert wie bei der Autobahn, die Bahnstrecken sind häufig für den Gleiswechselbetrieb eingerichtet. Sagt ja niemand, dass man Einzelgleise alle mit oneway=yes taggen muss. Das mache ich nur im Straßenbahnbereich, wo Gleiswechselbetrieb doch eher selten ist ... Ausserdem muss man berücksichtigen dass bei unseren Nachbarländern häufig Linksverkehr auf dem Gleis herrscht (Wüsste spontan nicht wo ausser in D noch rechts gefahren wird). Elsaß und Teile Lothringens ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Am 24.05.2011 13:07, schrieb Garry: Bei Pforzheim werden(wurden?) wurden ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] fest liegende Veranstaltungsschiffe
Am 22.05.2011 15:39, schrieb Falk Zscheile: Am 22. Mai 2011 15:19 schrieb Henning Schollando...@aighes.de: ...es ist auch ein klein wenig taktisch unklug, solch eine Sache nur regional zu klären und dann nicht zu kommunizieren. Ich würde im übrigen ein building=boat oder fixed_boat einem einfachen yes vorziehen. Da hast du natürlich recht, mittlerweile sind wir bei building=* auch etwas weiter als damals. Der Streit drehte sich dazumal eher um die Frage, ob Schiffe, die fest liegen überhaupt building=* sind. Insoweit bleibe ich weiter bei meiner Empfehlung building=* zu nutzen. Beim Wert den man setzt bin ich flexibel. Falls ihr euch einig werdet: In Bremerhaven habe ich auch für paar Schwimmdocks den Anker geworfen, als ich meine Heimat gebingt habe Ende des Jahres, auch nur mit schlichtem building=yes. (Wegen akuter Entscheidungsschwäche bzgl. Lizenz kann ich, von Zeitknappheit mal abgesehen, gerade nicht selbst umtaggen ...) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
Moin Am 22.05.2011 16:39, schrieb Torsten Leistikow: frueher war es eigentlich ueblich, dass railway=* als way eine komplette Bahnstrecke bezeichnet hat. Letztens scheint aber jemand entschieden zu haben, dass ihm das Tag viel besser auf einzelne Gleise angewand gefaellt. Als Folge davon bekommt man jetzt aber in den groeberen Zoom-Stufen keine ordentliche Kartenansicht der Bahnstrecken mehr hin, da es ausser den Einzelgleisen keinerlei Bahnwerte mehr in der Datenbank gibt. Wie bekommt man das wieder in den Griff? Einfach so die (meist doppelten) nebeneinander liegenden railway=* Wege wieder zusammenfassen will nicht, da sich damit ja jemand ziemliche Arbeit gemacht hat, auch wenn er damit einiges kaputt macht. Keine Ahnung, von welcher Ecke der Welt Du redest, aber zumind. in zwei Ecken (Karlsruhe und Bremerhaven) war ich es, der Schienennetze gleistreu (um)mappte nach Bing im Bhv und lokalem Luftbild in KA. Bei letzterem konnte ich mich gerade noch vom schienen- und schwellentreuen Mappen zurückhalten ;-) Ich bin aber nicht der einzige gleistreue Mapper in deutshcen Landen, der Trend wird unaufhaltbar sein Das Problem nur noch Einzelgleise statt Strecke gibt es in ähnlicher Form auch bei anderen Objekten. Geradezu klassisch ist dieser Streit bzgl. des Themas, ob man (Fuß- und) Radwege als von der Hauptfahrbahn unabhängiges Objekt (highway=cycleway bzw. path, was wiederum ein weiteres klassisches Streitthema ist) oder lieber als Zusatzeigenschaft der Gesamtstraße (cycleway=track etc.) Aber schon bei der Unterbrchung einer Straße durch eine Brücke gehen Zusammenhänge flöten. Oder bei Straßen mit getrennten Fahrbahnen. Mit Aufkommen der abmalen Luftbilder werden sicher auch Konflikte aufkommen bzgl. detailliertem Flächenmapping (Vorgarten, Haus, Garagenzufahrt, ...) kontra Wohnviertel via einfachem landuse=residential, wobei man das immerhin einfacher koexistent mappen kann ... Irgendwann kommt sicher auch das Mappen einzelner Fahrstreifen, da wohl zumind. im Autobahnbereich einige kommerzielle Navis Tipps wie Einordnen auf die 2. Spur von rechts beherrschen?! Da werden viele OSMler besser sein wollen, indem sie Fahrstreifen flächendeckend umsetzen ;-) Eine gewisse Ordnung kann man reinbringen, indem man auch usage=main/branch (dazu gab's relativ kürzlich eine kontroverse Diskussion im Forum http://forum.openstreetmap.org/viewtopic.php?id=10348 und glaub auch in der ML) service=spur/siding/yard etc. eifrig nutzt. In KA habe ich das jedenfalls peu a peu gemacht (und auch andere tags sehr ausführlich), in Brhv weiß ich's gerade nicht auswendig (da habe ich aber die VzG-Streckennummern, die schon jemand anders getaggt hatte, fortentwickelt etc.) Damit könnte ein Renderer ab gewissen Zoomstufen bspw. service weglassen. Beim Übergang zum gleistreuen Mappen gibt's sicher noch paar Fragen zu klären (bspw. wo gehört das Bahnübergangstag hin, von mir hier angesprochen http://forum.openstreetmap.org/viewtopic.php?id=11082 ), aber das renkt sich ein. Die topologischen Zusammenhänge zwischen den einzelnen Gleisen wird man sicher auch in Griff kriegen, bspw. mit Relationen für die Strecken. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche in OpenSteetMap
Am 20.05.2011 22:59, schrieb Sven Geggus: OSM hat haufenweise exklusive Inhalte die man finden würde, wenn Google unsere DB im Index hätte. Paar Sachen schafften es doch irgendwie in Google rein. Sucht mal nach Altes Leherheider Moor genau so mit den Fiel mir mal auf, als ich nachschauen wollte, was es mit diesem Wald auf sich hatte, weil er geometrisch etwas eigenartig gemappt war. Aber außer OSM kam da nix, was mich erleuchtet hätte ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dorf - Landuse reidental oder Bauernhof
Am 16.05.2011 13:00, schrieb Chris66: Am 16.05.2011 12:45, schrieb Falk Zscheile: Nimm eine Schwerpunktabgrenzung vor. z. B. mehr Rinder als Menschen -- Bauernhof Das ist aber auf den Bing-Bildern schwierig zu erkennen. Ganz und gar nicht! Bei Anwendung des Prinzips mehr Rindviecher als Menschen können wir ruhig einen Bot schreiben, der alle residentials in farmyard ändert, der hätte eine Zuverlässigkeit von 99,9% ;-) Und alle highways in farmyardtrack für Rindviecher kann er auch gleich ändern ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Am 19.05.2011 12:10, schrieb M∡rtin Koppenhoefer: interessante Arbeit mit (zum damaligen Lizensierungsstand) beeindruckender Visualisierung der Auswirkungen auf die Karlsruher Innenstadt. In der Tat ... Dann sähe das Bild sicherlich ziemlich anders aus. Ein dickes Problem wurde dezent ausgeklammert: S. 15: Teilen (und m.E. auch Vereinigen) von Wegen. In Bezug auf den Lizenzwechsel ist das problematisch, da bei der Analyse das Urheberrecht an diesen Objekten unterschlagen würde. Das drückt m.E. sehr drastisch, aber auch wahrheitsgemäß aus, dass wir ohne Lösung dieses Problems den Lizenzwechsel auch aus rechtlichen Gründen knicken können, da das Ergebnis dann höchst angreifbar wäre ... Die folgende Frage habe ich schon diverse Male gestellt, aber mir ist keine Antwort erinnerlich ...: Arbeitet jemand schon an diesen Problem, die Versionsgeschichte incl. Teilungen/Vereinigungen komplett zu kriegen? Wäre ja nicht nur für Lizenzfragen interessant, sondern auch ganz trivial, um bei Edits die Entwicklung eines ways besser nachvollziehen zu können, bspw. um rauszufinden, wer x=y drangehängt hat zum fragen warum dies ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnübergang
Am 11.05.2011 18:00, schrieb Wolfgang: ich habe im Wiki nichts über beschrankt/unbeschrankt etc gefunden. Habe ich etwas übersehen? Im Forum gab's relativ kürzlich eine ähnliche Fragestellung: http://forum.openstreetmap.org/viewtopic.php?id=11082 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzwechsel-Simulation / Bachelor-Arbeit von Jakob Altenstein
Am 19.05.2011 14:39, schrieb Robert Kaiser: Es ist so weit ich weiß nicht mal klar, ob wir aus rechtlichen Gründen *irgendwas* löschen müssen, um den Lizenzwechsel durchzuführen, es gäbe wahrscheinlich einige rechtliche Lücken, durch die wir schlüpfen könnten und alle Daten in die neue Lizenz befördern könnten - zumindest gibt es dazu einige einschlägige Meinungen. Auf welchen von mir wohl verpassten Diskussionen baust Du diese Meinung auf? Und wo kann man nachlesen, dass wir die Zuständigen schon nahezu überzeugt haben? ;-) Deine Botschaft höre ich wohl, allein mir fehlt der Glaube daran ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 20.04.2011 10:06, schrieb Jochen Topf: Aber Trac wollte mich nicht einloggen lassen, ohne dass ich meine Meinung zu den Contributor Terms sage. Bei trac auch? *grummel* Was ist eigentlich der Grund, dass man a) keine Fehler mehr melden darf? b) Seine Nutzerseite nicht mehr ändern darf? c) Seine Nachrichten nicht mehr lesen darf? d) ... und wer weiß was sonst auch nicht mehr ... ... ohne irgendwas klicken zu müssen, was man jetzt noch nicht klicken will und was mit a) - d) eigentlich überhaupt nix zu tun hat? Oder stehen trac-Fehler künftig auch unter ODBL? x) Lästig war im übrigen auch, dass ein Klicken von Abmelden nicht half, um einfach nur wieder die Karte anschauen zu können. Ich musste im Feuerfuchs den Keks explizit meucheln ... Darf ich jetzt an die Arbeit zurück und was programmieren? Hoffentlich ein besseres Login-management für a) - d) und x) ? ;-) Am 20.04.2011 10:17, schrieb Chris66: Aber ok, ist Dein gutes Recht und solange nicht den ganzen Tag die Kaffeetassen durch's Büro fliegen ist alles in Ordnung... ;-) Dann wird ein neuer Karton OSM-Tassen bestellt und der Verkaufspreis dezent wegen erhöhter Materialkosten angepasst ... ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 19.04.2011 09:31, schrieb Georg Feddern: Formal gesehen ist das doch die einzige Möglichkeit einer Enthaltung im Rahmen dieser Lizenzumstellung. Und somit die einzige Möglichkeit, seinen Unmut über die ünglückliche Form bzw. den Ablauf der Lizenzumstellung auszudrücken, die man nicht auch noch ausdrücklich bejahen möchte - und gleichzeitig der Übernahme seiner Daten nicht im Wege zu stehen. Nein, diese Möglichkeit gibt es nicht, da man PD doch nur dann anklicken und abschicken kann, wenn man auch ODBL akzeptiert hat, oder? Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 19.04.2011 06:28, schrieb Bernd Wurst: Ich weiß nicht wie die OSMF mit der Frage umgehen wird, aber ich würde da ganz einfach sagen: Es wurde immer klar gesagt, man soll GPS-Tracks hochladen die echte GPS-Punkte enthalten (Fakten). Die kreative Schaffensarbeit des Track-Erstellers ist also nicht gegeben und auch nicht vergleichbar mit der Schaffensarbeit aus den Tracks dann Straßen zu machen. Wenn ich da mal an meine eigenen Tracks denke von einer recht alten Magellan-Möhre ... Die kreative Schaffenskraft liegt im Gerät selbst! ;-) Ohne das recht kreative Eigenleben dieser Kiste beim Anlegen des tracks zu kennen, biste verraten und verkauft beim Erzeugen von Wegen daraus. Diese Eigenarten zu berücksichtigen ist wiederum nur meiner kreativen Schaffeneskraft zu verdanken, ohne die so mancher Waldweg eigenartige Loopings schlagen würde auf der slippy map ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lizenzumstellung - verschollene Mapper
Am 19.04.2011 12:46, schrieb Falk Zscheile: Unterstellen wir, das der Arbeitgeber das Nutzungsrecht hat. Wie jetzt weiter? Der Mapper selbst ist mit vertretbarem Aufwand nicht auffindbar. Sein Account verwaist. Keiner kennt das Passwort. Vermutlich würde sich nicht einmal der Mapper selbst an sein Passwort bei OSM erinnern ... Die Adresse des ehemaligen Arbeitgebers an stelle des Mappers setzen lassen, so dass der Arbeitgeber zustimmen kann? Wenn's so ist: Am 19.04.2011 11:52, schrieb Falk Zscheile: Die bei OSM hinterlegte E-Mailadresse ist seine nun deaktivierte Arbeits-E-Mail. Dann sollte der Arbeitgeber doch die Möglichkeit haben, in seiner ureigenen Domain fritzchen.map...@arbeitgeber.de wieder zu aktivieren und auf che...@arbeitgeber.de umzubiegen und sich dann ein neues Passwort zuschicken zu lassen?! Wenn Fritzchen Mapper natürlich neben der Arbeit auch noch auf private Eigeninitiative hin paar Sachen gemappt hat, die nicht vom Arbeitsauftrag abgedeckt sind, wird's womöglich kritisch mit dem Nutzungsrecht des AG ... Googeln nach Fritzchen Mapper hilft nicht? ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bäche mit layer=-1
Am 19.04.2011 12:41, schrieb André Joost: Am 19.04.11 12:28, schrieb Peter Wendorff: Bitte layer=0 nicht angeben, das ist unnötig. Ansonsten: Brücken bekommen layer=1, Tunnel layer=-1, sonst keine Layer. Und entweder ist's eine Brücke oder ein Tunnel (Rohr unter Weg), aber normalerweise nicht beides Eigentlich sollten layer-Angaben nichtmal da notwendig sein - Hier sind sie notwendig: http://www.openstreetmap.org/?lat=51.68177lon=6.61007zoom=17layers=O Immer diese Hochstapler! ;-) Im übrigen: http://www.openstreetmap.org/?lat=51.68518lon=6.61529zoom=17layers=O *zweifelanmeld* ;-) ob das die Renderer aber bisher hinkriegen, weiß ich nicht genau. Osmarender ja, Mapnik nein. Berücksichtigt Mapnik überhaupt irgendwie layer? Mich beschleichen da regelmäßig Zweifel ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 18.04.2011 12:03, schrieb Bernd Wurst: Jetzt hat derjenige Nein gesagt, ist also durchaus noch aktiv. Jegliche kleine Änderung die er jetzt (vielleicht auch nur aus Trotz) an einem von z.B. mir eingetragenen Objekt macht, erzeugt ein Objekt das später Probleme macht. ... nur wenn genug Zustimmer(-Daten) zusammen kommen für eine Umstellung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 18.04.2011 12:36, schrieb Dermot McNally: Weil ein nicht-Zustimmer die Macht hat, zu bestimmen dass meine Arbeit irgendwann aus dem Map rausfliegt obwohl ich selber zugestimmt habe und die Lizenzumstellung für unbedenklich halte. Nach deutschem UrhG hätten m.E. Zustimmer durchaus einen Anspruch gegen Nichtzustimmer an gemeinsamen Werken: http://bundesrecht.juris.de/urhg/__8.html http://bundesrecht.juris.de/urhg/__9.html Sprich: ein Löschen einfach so wäre eigentlich nicht legal ... Aber die Diskussion zu obigen §§ hatte ich vor einiger Zeit schon mal angestoßen, für diese Brücke zu einem Erhalt der Daten interesierte sich niemand ernsthaft ... Überhaupt sah ich vor einiger Zeit, als ich zuletzt intensiv drüber diskutierte, irgendwie keine wirklich ernsthaften Bemühungen, Wege zur Datenrettung zu suchen ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 18.04.2011 11:32, schrieb Martin Czarkowski: Am 18.04.2011 11:27, schrieb Doru Julian Bugariu: Wieso geht es irgendwem an,*wer* auf disagree klickt? wieso denn nicht? Stehst Du nicht zu Deiner Meinung? Man kann die Sachen der disagree-Mapper schon mal neu erfassen, ich find das gut. Solche Tendenzen, an den Daten rumzuvandalieren, wären ein Grund, die Entscheidung erstmal zu vertagen ... Mir behagt eh keiner der beiden Buttons. Weder Disagree = die Daten verweigern, noch Accept = einen für mich unakzeptablen Umgang mit den Daten akzeptabel finden. Leider sind ja Abstimmung über Lizenz der eigenen Daten und Lizenzwechsel bei dieser unsäglichen Sache miteinaner verknüpft ... Aber egal, die nächsten 5 Wochen pressiert's bei mir nicht, drei Wochen im Urlaub und davor noch genug anderes zu tun. Und danach schaun mer mal ... Die Sachen, die mir noch wichtig waren zu mappen, habe ich noch schnell gemappt. Und es wurde mal vn vielen versprochen, dass ja berhaupt keine Daten gelöscht würden, denn der letzte CC-Planet würde ja auf nahezu ewig im Netz stehen für alle CC-Fans. Es wäre schön, wenn das wirklich so wäre und jetzt nicht Scharen von ODBLern die CC-Daten durch womöglich qualitativ minderwertig nachgemappte Daten verhunzen ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 18.04.2011 10:46, schrieb Frederik Ramm: 2. Die Nein-Entscheidung ist noch nicht endgueltig. Es waere also verfrueht, jetzt hinzugehen und zu sagen: Ah, der User xy1234 hat Nein gesagt, also loesche ich mal alle seine Daten und erfasse sie neu; ... Also bitte keine ueberhasteten Aktionen - ... *dickunterstreich* S.a. anderer Beitrag von mir Falls ihr auf Leute trefft, die sagen: ODbL find ich im Prinzip ok, aber die Contributor Terms lehne ich ab, Bei mir ist's vorrangig der Umgang mit den gesammelten Daten der Community, dem wertvollsten, was eine Community haben kann. Jedes Rumpfuschen daran nur aus rechtstheoretischen Gründen ist für mich ein No-Go. Für die Dateninitegrität und ein ungeforktes Projekt wäre ICH bereit, auch ehedem unglücklich formulierte Lizenzen oder auch künftig weniger optimale Lizenzen (die aber keine Löschungen erfordern) hinzunehmen. dann gibt es theoretisch die Moeglichkeit, dass die OSMF per Einzelfallentscheidung diesen User trotzdem weitermachen laesst. Das ist eine Sache, die nur in Ausnahmefaellen in Frage kommt, weil sie zu Laste der Freiheit kuenftiger Generationen in OSM geht - Daten, die ohne CT-Einverstaendnis in der Datenbank bleiben, werden bei einem eventuellen spaeteren Lizenzwechsel wieder den gleichen Stress verursachen, den wir jetzt haben. Aber denkbar ist es zumindest. Was ist der Hintergrund dieses Einwurfes? Gibt es dazu was von der OSMF oder wen anderes? Habe in letzter Zeit zu wenig Diskussionen um die Lizenz verfolgt und lieber gemappt was noch zu mappen war ... ;-) Gruß Mueck PS: Sollte mir in nächster Zeit was zustoßen (wenn man den PC gegen frische Luft tauscht und das passiert demnächst im Urlaub bei mir, dann besteht, wie man aus Asterix weiß, ja die Gefahr, dass einem der Himmel auf den Kopf fällt ...), dann vefüge ich hiermit schon mal prophylaktisch quasi testamentarisch, dass jemand anderes accept für mich klickt ... PSPS: Hoffentlich kommt jetzt niemand auf dumme Gedanken, ich sollte besser meine Adresse aus dem Netz entfernen ... Hmmm PSPSPS: Ich fürchte, die steht an zu vielen Stellen ... Mist ... ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Verkehrsmessung/Profile
Am 18.04.2011 09:45, schrieb Florian Lohoff: irgendwann wird ja sowas wie IQ routes etc mal interessant. Dafuer muesste man die Daten ja mit Verkehrsprofilen anreichen - also peak/offpeak zeiten oder aehnliches. Dafuer mueste man so in meiner kleinen Gedankenwelt ja Verkehrsmessungen veranstalten d.h. wieviele Autos kommen in welcher Stunde an welchem Wochentag da so vorbei. Interessante Daten nicht nur für Routing, sondern auch für Hobbyverkehrsplaner und -politiker wie mich: - Ist die Umgehungsstraße X wirklich nötig? - Lässt sich die Straße Y von 4 auf 2 Spuren zurückbauen? - ... Leider sind solche Daten selten öffentlich und meine für KA von 1995 veraltet ... Von den Rheinland-Pfälzern weiß ich, dass die paar Dauermessstellen im Land haben, die's auch irgendwo online gibt, wenn ich nur noch wüsste wo ... An der Rheinbrücke bei Karlsruhe ist bspw. eine. Welche die Lizenz wohl haben mögen ... Ich hatte mal ueber eine Microcontrollerbasierte zaehlung nachgedacht, d.h. ein altes Auto schlachten und die Ultraschallsensoren aus dem PDC missbrauchen um vom rand die Anzahl der durchgefahrenen Autos zu zaehlen. Das koennte man einfach mal eine Woche hinhaengen und am schluss kann man schoen die Rush-Hour/Peak zeiten ermitteln. Am besten zwei Sensoren am Auto vorne und hinten -- aus dem Zeitunterschied der beiden: Geschwindigkeitsprofil - zähflüssig? -- aus der Dauer der Vorbeifahrt + Geschwindigkeit: Länge - Lkw-Anteil Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
Am 18.04.2011 11:47, schrieb M∡rtin Koppenhoefer: Andererseits ist das wohl ein Spezialtag der Pufferküsser, wo man evtl. davon ausgehen kann, dass das nur von Leuten verwendet wird, die die rechtliche Definition kennen. Ob das so ist, könnte man z.B. durch Befragen der mapper herausfinden, die den tag verwendet haben. Bei mir ist's bspw. so, als ich das in KA drangehängt habe. Im übrigen, was ich noch vergaß: Die reale Verkehrsbedeutung abseits der amtlichen Einteilung in Haupt- und Nebenbahn kann man anders viel besser erfassen als über usage. Linien als Relationen zu taggen, setzt sich ja immer mehr durch. An diese noch tags zu hängen, die die Art des Verkehrs spezifizieren (Bummelzug, Regional-Express, IC oder ICE, ...) oder dessen Dichte, halte ich für zielführender. Oder anders: In zwei Forumsdiskussionen aus letzter Zeit habe ich dazu die Idee eingeworfen, die Fahrplankarten (u.a. von meinem VCD) nachzubilden statt wie dort angestoßen Fahrpläne zu erfassen. http://forum.openstreetmap.org/viewtopic.php?id=11874 http://forum.openstreetmap.org/viewtopic.php?pid=146321#p146321 Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel Phase 3
Am 18.04.2011 13:54, schrieb Frederik Ramm: Die ODbL+CT-Kombination erlaubt uns, die Lizenz zu einem spaeteren Zeitpunkt erneut zu aendern, und dabei haben wir dann weitaus weniger Bauchschmerzen als jetzt. Wenn sich irgendwann im Projekt eine breite Einsicht durchsetzt, dass PD (oder von mir aus CC0 oder wie man es auch immer nennt) besser oder zeitgemaesser ist, dann haben wir die Moeglichkeit dazu, der Prozess ist dann ganz klar definiert. ... Aber ich finde, dass allein diese Moeglichkeit, spaeter weitgehend saubere Lizenzwechsel durchzufuehren, wenn die ueberwiegende Mehrheit des Projekts das will, es wert ist, jetzt die Umstellung mitzumachen, ... Was wäre denn in dem Falle, dass bei einem erneuten Lizenzwechsel Teile der Daten nicht kompatibel zur dann neuen Lizenz wären? Vermutlich wird man das nur bei Importen (oder evtl. bei Luftbilabzeichnungen) überhaupt erkennen können, um dann d was löschen zu müssen. Die Erleichterung dürfte sein, dass einfache Einzelmapper-Daten nicht mehr zur Disposition stehen könnten? Wenn dem so wäre: Was hat dagegen gesprochen, Wechsel der CT und Wechsel der Lizenz zu entkoppeln? Zuerst CT wechseln mit vermutlich besserer Zustimmungsquote, vielleicht noch mit paar Tricks Altdaten von Verschollenen retten (wir wechseln ja gar nicht die Lizenz, also ...) Und DANACH nach NEUEM Procedere die Lizenz wechseln? Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auswertung der ersten Reaktionen auf Lizenzwechsel?Phase 3
Am 18.04.2011 13:53, schrieb Sven Geggus: Heiko Jacobsheiko.jac...@gmx.de wrote: Es wäre schön, wenn das wirklich so wäre und jetzt nicht Scharen von ODBLern die CC-Daten durch womöglich qualitativ minderwertig nachgemappte Daten verhunzen ... Dieses Problem sehe ich jetzt überhaupt nicht. Denn die Vorliebe für die eine oder andere Lizenz hat nicht die Bohne damit zu tun ob jemand gewissenhaft mappt oder nicht. Ich habe jedenfalls in der bisherigen Datenbank definitiv schon mehr Schrott gesehen wie mir lieb ist. Je nachdem, was es war. Die letzten Tage hatte ich noch fehlende landuses eingebaut, DIE könnte ein anderer vermutlich sogar viel besser mappen, weil's bei mir eher grob war. Bei anderen Edits der letzten Monate floss dagegen auch viel Fachwissen in tags und Geometrie, das nicht viele so haben. Die könnten verhunzt werden durch nachmappen, es sei denn, tags und Koordinaten werden 1:1 übetragen, womit wir dann streng genommen bei einer Copyright-Verletzung wären (sofern wir prinzipiell eins für gegeben ansehen, was ja der Fall ist, sonst hätten wir das Löschproblem ja nicht ...) Übereifriger Aktionismus beim Nachmappen ist wirklich nicht angeraten. Zumal jemand sich ja auch noch umentscheiden könnte. Die Ablehner wären Überredungen sicher nicht zugänglicher, wenn sie sähen, wie zwischenzeitig ihre Daten womöglich vermurkst werden ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
Am 18.04.2011 17:35, schrieb Felix Hartmann: On 18.04.2011 13:54, Heiko Jacobs wrote: Die reale Verkehrsbedeutung abseits der amtlichen Einteilung in Haupt- und Nebenbahn kann man anders viel besser erfassen als über usage. Linien als Relationen zu taggen, setzt sich ja immer mehr durch. An diese noch tags zu hängen, die die Art des Verkehrs spezifizieren (Bummelzug, Regional-Express, IC oder ICE, ...) oder dessen Dichte, halte ich für zielführender. Oder anders: Gibt es dazu irgendwelche Docs? Nein, in sowas wie http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport kommt die Angebotsdichte und -art bisher praktisch nicht vor Weil es macht jetzt ja wenig Sinn, wenn jedes Land hier seinen eigenen Müll zusammenschreibt. Man will ja nicht ICE, TGV, Shinkansee, etc... und alle Zugtypen kennen müssen um entscheiden zu können was es ist. Ob das international klappt ... Wir kriegen ja noch nicht mal sauber die nationalen Straßenklassen überall sauber gleich hin, weil sie halt jedes Land ein wenig anders definiert ... Ob so ein Tag per Relation vorkommt, oder an der Schiene selber ist eigentlich egal. Wobei am besten wäre es, wenn man klar definiert dass man Relationen benutzt, und die Relation immer nur auf EIN (möglichst mittiges) Gleis legt (falls die Gleise seperat gemapped werden). Mittig geht nur bei einleisig ;-) Ansonsten gibt's formal nur zweigleisig ohne Mitte für Relationen. Und wenn außerhalb on Bahnhöfen mehr als zwei Gleise liegen, sind es in .de schon formal zwei verschiedene Strecken! Im Nahverkehr (Bus und Straßenbahn) wird schon gerne je Richtung eine eigene Relation gemappt, die kann man dann gleistreu legen. Im Eisenbahnverkehr hat sich das noch nicht durchgesetzt So könnte man am besten die Karten für niedrige Zoomstufen aufbereiten. Aber es braucht eine klare Dokumentation bezüglich der Verkehrsbedeutung von Zugrelationen! Weil etwa nur weil 10 Relationen auf einem Gleis hängen, bedeutet das ja nicht, dass die Verbindung überregionale Bedeutung hat. Richtig. Definitionen aufstellen und darüber diskutieren müssen wir aber erst noch ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
Am 18.04.2011 18:44, schrieb Felix Hartmann: Dasselbe Problem wird kommen, wenn wir in OSM irgendwann flächendeckend Fahrspuren mappen. Das Problem HABEN wir schon. Stichwort: straßenbegleitende Radwege ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
Am 18.04.2011 18:38, schrieb Felix Hartmann: BTW. Es gibt ein European Agreement on Main International Railway Lines (AGC) Das wäre ein guter Anhaltspunkt (wenngleich etwas von der falschen Zugangsseite, da hier auf die Infrastruktur, und nicht die tatsächliche Benutzung abgezielt wird - aber prinzipiell wird ja nichts auf 300km/h ausgebaut für Züge, und dann für Schnellbahnverkehr verwendet...). Das Dokument wurde sogar erstmals 1985 ausgearbeitet. Setz man die Gewichtsklassen um auf http://de.wikipedia.org/wiki/Streckenklasse und schaut man bspw. in den Schweers+Wall-Eisenbahnatlas, findet man, dass ziemlich viele Strecken in .de in die Klasse D4 fallen Für die zukässigen Profile gibt's dort leider keine Karte. Nimmt man die Bezeichnung Magistrale beim Wort, wären dagegen wohl nur sehr wenige Strecken Hauptbahn im Sinne dieses Dokuments. http://www.ris.bka.gv.at/GeltendeFassung.wxe?Abfrage=BundesnormenGesetzesnummer=20002138ShowPrintPreview=True hat auch eine Liste. Oder dort: http://www.unece.org/trans/conventn/agc_a1e.pdf Eine kartographische Umsetzung dazu fand ich noch nicht. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
Am 16.04.2011 15:29, schrieb Felix Hartmann: Irgendwie kommen mehr und mehr User drauf, die meinen usage=main würde auch etwa für Schnellbahnstrecken (etwa die kaum benutzte Ostlinie in Wien) gelten. Ich hab das im Wiki mal geändert, wäre aber eigentlich für eine bessere Aufteilung wie nur usage=main // usage=branch. Ich denke usage=main (ICE/IC/IR Züge befahren die Gleise) usage=secondary (Eilzüge, Regionalzüge) usage=branch (Schnellbahnen, Zubringerbahnen) würde deutlich mehr Sinn machen. siehe. http://wiki.openstreetmap.org/wiki/DE:Key:usage Zumindestens für Deutschland ist die Unterscheidung Hauptbahn / Nebenbahn in der EBO geregelt: http://bundesrecht.juris.de/ebo/__1.html ... und hat übehraupt nix damit zu tun, was für Züge auf der Strecke fahren. Ich vermute mal stark, dass das in AT ähnlich ist ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
Am 16.04.2011 18:11, schrieb Felix Hartmann: Das mag so beschrieben sein, hat aber mit Openstreetmap usage wenig zu tun. Wenn das so sein soll, dann sollte hier auch geschrieben werden dass es nur um Gesetzliche Regeln geht, dazu schmeißen wir industrial, tourism und Co rauß, und nutzen halt priority stattdessen vernünftig. Genauso ist ja auch primary/secondary/tertiary und Co nicht von der offiziellen Klassifikation abhängig, sondern hängt von der tatsächlichen Verkehrswichtig ab. Das zu verwursten ist aber Schwachsinn. Entweder wir haben hier einen Schlüssel für bundesrechtliches Gesetze, oder wir legen die tatsächliche Wichtigkeit fest. Ich sehe nicht dass usage bisher rechtlich interpretiert wurde.. Bei primary/... ist die Übersetzung Hauptstraße/Nebenstraße/... nicht genormt, während sich die Normung Bundesstraße/Landesstraße/Kreisstraße im ref-tag wiederfindet, von daher beißt sich da nix, wenn man primary etc. nach Verkehrsbedeutung flexibel handhabt. Bei usage=main ist die Übersetzung Hauptbahn dagegen im deutschen Sprachraum genormt, eben durch die EBO, von daher ist dieser Fall denkbar ungeeignet dafür, ohne Diskussion einen Schnellschuss durch Ändern einer einzelnen Sprachversion und ohne Ändern der Definition von usage anderswo im Wiki zu starten ... industrial muss man nicht rauswerfen, auch nichtöffentliche Anschlussbahnen sind in .de natürlich extra geregelt ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
... im übrigen übersetzt man nach Leo http://dict.leo.org/ branch eher mit Zweigstrecke, was relativ gut zu dem passt, was die EBO unter Nebenbahn versteht, weniger gut zu Strecken auf denen bspw. Regional-Expresse verkehren. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access für Spezialgruppen, Hier Ausflugsbusse
Am 12.04.2011 19:59, schrieb M∡rtin Koppenhoefer: Nachdem eine Nachfrage auf tagging wenig ergiebig war, versuche ich es mal hier: http://www.23hq.com/dieterdreist/photo/6610385 dieses Schild soll sowas wie Durchfahrt verboten für Ausflugsbusse (Touristikbusse) bedeuten (eine Einbahnstraße kann es nicht sein, da es eine Sackgasse ist). Gibt es dafür schon eine Fahrzeuggruppe? Was haltet Ihr von tourist_bus=no ? Ich hätte spontan gesagt: motor_vehicle=yes bus=no psv=yes ... sehr aber gerade, dass in OSM bus auf Linienbus eingeschränkt ist ... Das ist ... hmmm ... ... ungünstig... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] befestigte Weg für die Feuerwehr
Am 12.04.2011 09:03, schrieb Jan Tappenbeck: Diese habe ich als highway=service gesehen - erst einmal mit access=private ergänzt, da ja nicht jeder einfach da entlang fahren soll. http://wiki.openstreetmap.org/wiki/Tag:service%3Demergency_access ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ICE-Relationen
Am 12.04.2011 06:27, schrieb Thomas Reincke: Am 11.04.2011 16:07, schrieb fly: Ich frage mich ob man bei den ICE-Relationen nicht lieber Relationen für die Strecke zwischen einzelnen Bahnhöfen anlegt und diese Relationen jeweils den ICE-Relationen zuordnet. Im Momment sind die ICE-Relation doch sehr groß und auf manchen Strecken fahren eine ganze Menge ICEs ganz zu schweigen von EC/ICs und sonstigen Verbindungen. Im Unterschied zu Bus/Straßenbahn-Linien verlaufen diese Linien lange auf der selben Strecke. Was ist Eure Meinung ? Dieses Verfahren wäre mir für alle ÖPNV-Linien das liebste gewesen. Eine Relation für die Teilstrecke Haltestelle - Haltestelle (bzw. Platform - Platform). Alle Relationen zusammen geben die Relation für Linie/Richtung/Variante. Aber damit habe ich mich leider nicht durchsetzen können, da zu kompliziert. :-( In der Tat ... Im Nahverkehr liegen an bspw. an einer Straßenbahnstrecke zwischen Abzweig X und Wendeschleife Y ja n Haltestellen und man müsste aus der Strecke Kleinholz in Dosen machen, um Dein Modell zu nutzen. Im Fernverkehr ist's umgekehrt, da liegen zwischen ICE-Halt A und ICE-Halt B dutzende von ways dank Brücken und Abzweige etc. Von daher klingt der flys Ansatz für den Fernverkehr so unvernünftig nicht ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OLM 6
Am 04.04.2011 18:43, schrieb Alexander Matheisen: * Die Positionen der Marker werden nun aus einer eigenen Datenbank genommen, die nur die darzustellenden Punkte enthält, Habe am 6.4. mal an zwei Objekten website=... drangehängt und vermutete, dass die nach der Aktualisierung am 9.4. eigentlich eingekringelt sein sollten für POI-Details, sind sie aber nicht ... Hmmm... Die Suche findet sie aber und man kriegt dort dann ein Popup ... Hängt der POI-Detail-Kringel noch an was anderem, tag-mäßig bzw. aktualisierungsmäßig? Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Großflächige Edits von Defaults
Moin Mir fallen gerade paar größere Edits auf zu access und surface unter http://www.openstreetmap.org/user/changchun_1/edits Der Informationsgewinn von surface=paved und access=agricultural auf besagten Wegen mag nicht sehr hoch sein, weil man sie als Default betrachten könnte ... Ich setze diese daher auch eignetlich nie in solchen Fällen ... Aber Bauchschmerzen habe ich bei solchen Massen-Edits trotzdem irgendwie ... (auch wenn sie noch Welten von gewissen Oberförstern trennen ...) Was meinen andere dazu? Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wohnort
Am 21.03.2011 08:17, schrieb Bernd Wurst: Im Gegensatz zu dem ganzen Umland, das ja niemandem gehört oder wie? Ob der Pilzesammler im Wald oder im Hausgarten steht, ist rechtlich relevant ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgrenzung Rail - tram
Am 17.03.2011 01:14, schrieb Stephan Wolff: Am 16.03.2011 23:48, schrieb Johannes Huesing: Maßgeblich ist für mich (in Deutschland) der Betrieb nach Eisenbahnbetriebsordnung (ja ich weiß, das ist für den Laien nicht ohne Weiteres erkennbar). Für Gleise auf Industrie- und Hafenflächen gilt die EBO laut Wikipedia meist nicht. Richtig, da ist's die BOA (A=Anschlussbahnen), ist aber eher nebensächlich, denn zum BOStrab-Gleis wird's dadurch noch immer nicht ... tram/subway/light_rail = BOStrab = Straßenbahn und Verwandte rail = EBO/ EBO FV-NE / BOA / ... = richtige Eisenbahn incl. S-Bahn BOA sieht man gelegentlich in Natura, weil dann gelegentlich Tafeln Privatanschluss der Firma Cronimet o.ä. neben dem Gleis stehen. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgrenzung Rail - tram
Am 16.03.2011 07:22, schrieb Georg Feddern: Sonst könne man ja nicht erkennen, das der Individualverkehr die Schiene auf der ganzen (highway-)Fläche kreuzen kann. Streng genommen müsste man um's Hafengebiet ein landuse=crossing mappen ;-) Denn am Eingang stehen oft Tafeln mit Hafengebiet, Schienenfahrzeuge haben Vorrang oder so ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgrenzung Rail - tram
Am 16.03.2011 02:16, schrieb Bartosz Fabianowski: Da kann ich Dir nur zustimmen. Wir haben zum Beispiel in Dublin Hafengleise (siehe http://osm.org/go/es@WCOqfv-- ). Diese sind nicht nur Normalspur sondern irische Normalspur, also 1,6 Meter Gleisabstand. Das hat mit Straßenbahnen echt nix zu tun. Das ist keine Frage der SPurweite. Ab 1500 ff http://de.wikipedia.org/wiki/Liste_der_Spurweiten#Spurweiten_1500_bis_1599_mm tauchen auch immer wieder mal Straßenbahnen auf ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgrenzung Rail - tram
Am 16.03.2011 01:59, schrieb Stephan Wolff: Moin, in Hafengebieten oder Industiegeländen sind Normalspurgleise manchmal in befahrbare Flächen eingebettet. Ein Mapper bezeichnet diese Gleise konsequent als railway=tram (z.B. [1]). Quark Nach meinem Verständnis wäre dafür railway=rail richtig. In der Tat! Ich würde umgekehrt auch Straßenbahngleise, die ein Stück außerhalb der Straßenfläche verlaufen, als tram eingeben. Wenn ein Gleis kein Hindernis ist, sondern in einer befestigten Fläche liegt, sollte man dies besser als Zusatztag anfügen. Allerdings fällt mir kein treffender Begriff ein. Dazu braucht's kein Zusatztag, Dann liegen einfach zwei ways übereinander, einer für Individualmobile, einer für Ferrophile. Man könnte sich aber Gedanken machen, ob man die Schienenumgebung mit surface=gravel/grass/asphalt/concrete/cobblestone *) angeben sollte ...?! *) Für den Unterschied concrete/cobblestone muss man in KA ganz genau hingucken, seitdem man abschnittsweise Schienen in Kopfstein-Imitat aus Beton verlegt hat ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Abgrenzung Rail - tram
Am 17.03.2011 22:07, schrieb Johannes Huesing: Heiko Jacobsheiko.jac...@gmx.de [Thu, Mar 17, 2011 at 07:45:54PM CET]: [...] tram/subway/light_rail = BOStrab = Straßenbahn und Verwandte rail = EBO/ EBO FV-NE / BOA / ... = richtige Eisenbahn incl. S-Bahn Hm, für die hier verlaufende Oberrheinische Eisenbahn bin ich ja schon mit light_rail zufrieden und verteidige den Status Quo ab und zu gegen welche, die den gesamten Linienweg auf tram runterstufen wollen. Ich muss gestehen, dass im Raum KA auch einige EBO-Strecken light_rail sind. Das hat aber seine Ursache auch darin, dass in der DE:Map_Features lange Zeit ein Übersetzungsfehler war und light_rail mit S-Bahn gleichgesetzt war, da passte das eher ... Bei der Albtalbahn, die seit den 50ern quadi wie eine Überlandstraßenbahn betrieben wird, auch wenn sie tw. EBO ist, sehe ich auch keinen Bedarf auf Änderung... Bei der Kraichgaubahn konnte sich light_rail schon länger nicht durchsetzen, bei paar anderen Strecken mit 15 kV ist es noch als Relikt von damals so und sollte vielleicht mal umgetaggt werden bei Gelegenheit ... Schön wäre es aber, wenn man dominant als S-Bahn betriebene EBO-Strecken mit tw. abweichenden Bauausführungen (Bahnsteighöhen insbesondere, in HH und B auch andere Elektrifizierung) entsprechend taggen könnte, aber a gibt's glaub noch nix, oder? Genausowenig wie Betrieb als reine Güterverkehrsstrecke. Ein altes propoal hat sich glaub nicht durchgesetzt und ist versickert. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnhöfe von U-Bahnen und Zügen
Am 15.03.2011 19:44, schrieb Andre Joost: Mal abgesehen davon, dass in DE die Definition von US ziemlich schwammig ist: Nirgends auf der Welt sind S- und U-Bahn so klar voneinander getrennt als in DE, zumind. die *Infrastruktur*. Es gilt entweder die Eisenban-Bau- und -Betriebs-Ordnung EBO -- S-Bahn, sonstige Züge (rail) oder die Betriebsordnung Straßenbahn BOStrab -- U-Bahn (subway), Stadtbahn (light_rail), Straßenbahn (tram) *innerhalb* der letzteren ist es etwas schwammiger, weil es Städte gibt, die ihre Stadtbahn als U-Bahn aufwerten, obwohl nur München, Nürnberg, Hamburg und berlin in DE echte U-Bahnen haben (überall vom Straßenverkehr getrennt, ok, Wuppertal noch ;-) ) und weil die Übergänge Straßenbahn/Stadtbahn fließend sind. Bei den Fahrzeugen gibt es in der Tat Orte, wo diese die BOStrab-/EBO-Grenze überwinden. Manchmal unauffällig (Köln/Bonn ist tw. nach EBO konzessioniert, wie auch die OEG und RHB in MA/HD/LU), manchmal auffällig wie in Karlsruhe, wo Straßenbahnen zwischen richtigen Eisenbahnen herumfahren ;-) Aber da wir die geostationäre Infrastruktur mappen und nicht den mobilen Fahrzeugen hinterherhecheln, ist das ja kein Problem ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Taggen von übereinanderliegenden Ways
Am 13.03.2011 15:36, schrieb Bartosz Fabianowski: In dem einen Way befinden sich Informationen über Straßenbahn und Straßenbahnrelationen und in dem anderen Way steht die Straßenklassifizierung. Für mich gehören die Tags für beide an denselben Way. Das ist im Wiki auch so beschrieben und wird korrekt gerendert. Es gibt in Karlsruhe Straßen wo - Straßenbahnen in beide Richtungen auf einem Gleis, Autos nur in eine Richtung fahren dürfen (Schillerstr.) - Straßenbahnen nur in eine Richtung auf einem Gleis, Autos aber in beide Richtungen fahren (Kastenwörtstr.) Wohin gehört nun das oneway, wenn in beiden Fällen alles auf demselben way liegt? Gruß Mueck, der in den letzten Wochen in KArlsruhe dank guter Luftbilder das Problem durch Umstellung auf gleistreues Mapping größtenteils gelöst hat, wodurch der Beidrichtungs-Straßen-way nicht mehr auf den Einzelgleisen liegt, bis auf bspw. in den besagten Straßen und bis jemand in manchen Straßen jemand fahrbahntreu mappt ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Funkmasten in SH - geheim und jeder kann es lesen
Am 08.03.2011 09:01, schrieb Jan Tappenbeck: Die dürfen wir nicht bekommen weil diese geheim sind - siehe Bauschild - stehen dort wegen möglicher Rettungsdienstanforderungen. Steht auch dabei, auf welches Bezugssystem die Koordinaten bezogen sind? Und wie die zu entschlüsseln sind? Vielleicht ist der Ellipsoid (Bessel oder WGS84 oder SHgeheim) ja DAS Geheimnis! ;-) Sie stehen laut Schild 49.4711 8.0815? Dann lassen sie mich dekodieren und umrechnen ... Wir schicken den Rettungswagen dann nach 49.0815 8.4711! Ivryr Tehrffr Zhrpx! ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rad- und Fusswege mit dem Rest der Welt verbinden
Am 04.03.2011 23:51, schrieb Stephan Wolff: - Bei Straßeneinmündungen gibt es meist eine kurze, asphaltierte Verbindung, die man als Rad- und Fußweg eintragen kann (Puristen können highway=path verwenden, weil die 1m lange Verbindung meist nicht explizit beschildert ist). Da orientiere ich mich an den Tags des ways, zu dem der Stich hinführt, ganz pragmatisch und unpuristisch ;-) - Bei Einmündungen von Wald- oder Feldwegen gibt es oft keine bauliche Verbindung zum Radweg, aber der Radfahrer/Fußgänger kann den Grünstreifen leicht überqueren. Dann könnte man allenfalls eine virtuelle Verbindung eintragen. Wenn ich beim Mappen von Waldwegen solche nicht real existenten Verbindungen zwischen Parallelweg und Hauptfahrbahn an Einmündungen finde, fliegen die raus, so wie ich die real existierenden, aber in OSM fehlenden ergänze. Wenn schon separates Mapping, dann auch korrekt. Als Radfahrer nutze ich solche Grünverbindungen auch nur im Notfall, wenn mir eine real nicht existente Verbindung allzu große Umwege aufzwingen würde. Man weiß nie, was sich im oder unterm mehr oder weniger dichten Bewuchs alles an Überraschungen verbirgt. Bevor ich durch eine solche Überraschung auf der Schnauze lande, fahre ich lieber ein Stück auf der Fahrbahn, bis eine real existierende Verbindung kommt. Wenn bei OSM Router die Waldwege bevorzugen, die über auch real existierende Verbindungen laufen, dann ist das kein Fehler in meinen Augen. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 04.03.2011 02:43, schrieb Henning Scholland: Warum manche Tags populärer sind als andere hängt auch maßgeblich mit dem Wissen um ihre Auswertung zusammen. Wenn die MTB'ler wissen, dass sie damit ihre Wege kategorisieren können und damit das Routing für sie verbessern (OpenMTBMap), nutzen sie dieses Tag natürlich auch. Bei smoothness ist diese Nutzung aber meiner Erfahrung nach recht unbekannt. Es gibt theoretisch mind. eine Karte, die smootness als Layer anzeigte: http://maxspeed.osm.lab.rfc822.org/?lat=48.98lon=8.34zoom=14layers=0BTinput=smoothness ... aber die ist ja gerade nicht erreichbar ... Aber vielleicht läst sich ein smoothness-Layer ja irgendwo anders einbauen. Es hat, meine ich, auch niemand gesagt, dass smoothness perfekt ist. Das ist es auch nicht. Es ist aber eindeutiger als eine Unterteilung in viele Unterkategorien. Diese werden nicht flächig verfügbar sein. ... Das wird das Problem sein ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 16:13, schrieb Joerg Fischer: Der extrem seltene Ausnahmefall Ja aber da liegt heute Schnee und jetzt darf ich _doch_ ist für die Praxis und das Routing nicht relevant. Es geht hier nicht um schlechtes Wetter, sondern u.a. um die Randziffer 23 in http://bernd.sluka.de/Recht/StVO-VwV/VwV_zu_2.txt bzgl. mehrspurigen Rädern/Anhängern etc. In .de gummimäßig formuliert,ist man in .at restriktiver und untersagt ab einer gewissen Hängerbreite das Fahren auf Radwegen. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 17:10, schrieb M∡rtin Koppenhoefer: Zum Beispiel wird wheelchair=* doch auch direkt getaggt, dagegen hat komischerweise niemand was - obwohl es auch aus smoothness=* hervorgeht. da drückt man ein Auge zu, ganz korrekt im Sinne des Schemas ist das auch nicht. Es mus ja nicht ins Schema pasen, denn wheelchair ist kein access-tag wie bicycle, denn Rollis DÜRFEN überall dort hin, wo auch Fußgänger hindürfen (Turborollis mit 6 km/h oder so lasse ich mal außen vor) sondern ein Eignungs-Tag, ob man dort, wo man hin DARF, auch hin KANN. Deswegen auch die Werte yes/no/limited statt destination Co. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 13:11, schrieb M∡rtin Koppenhoefer: ja, Übersetzungsfehler bzw. Auslassung im Deutschen: grade1 schließt Wege mit ein, die zwar nicht asphaltiert sind, die aber eine Oberflächenstruktur haben, die dem faktisch gleichkommt (extrem verdichtet). Was den für's Radfahren nicht unwichtigen Rollwiderstand betrifft und die jahreszeitliche Konstanz der Benutzbarkeit kommt eine wassergebundene Decke, auch wenn sie nagelneu noch perfekt ist, eben nicht einer asphaltierten/betonierten Decke gleichwertig. Ich möchte daher keine wassergebundenen Decken in grade1 finden, auch wenn ich nicht mit Rennrad unterwegs bin ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 18:13, schrieb Christian Müller: Und was macht man z.B. mit Holz? Ich würde schon sagen, dass manche hölzerne Wege als befestigt gelten können (Hausbrücken z.B.), andere, wo nur ein paar logs verstreut im Sumpf liegen, eher nicht. surface=* ist auch nicht perfekt, aber es ist _wesentlich_ besser zu handhaben und brauchbarer, auch was die unmittelbare Lesbarkeit des tags betrifft, als tracktype/smoothness.. surface=asphalt ohne smoothness hilft Dir aber auch nix. Ich habe auch schon surface=asphalt in smoothness=intermediate oder in wenigen Fällen m.E.n. gar in bad eingestuft. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 03:27, schrieb Ulf Lamping: [1] Natürlich könnte man eine Art wissenschafliche Untersuchung starten (Welligkeit, Löcher, Rillen, ..., jeweils mit Höhe, Abstand, Form, Größe, Tiefe). Will sich aber wohl keiner antun. ... weil Ergebnis nur bis zum nächsten Regen gültig smoothness gilt immerhin bis zur nächsten Holzabfuhr ;-) ... womit wir schon beim Thema wären, dass eins daneben bei tracktype und smoothness im Rauschen der jahreszeitlichen Änderungen in Wald und Flur untergehen, wodurch sich jedes exaktere tagging eh obsoletiert ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Status Fahrradwege-Tags
Am 02.03.2011 07:58, schrieb Joerg Fischer: Das sehe ich eher andersrum. bicycle=yes heißt, das das Radfahren dort nicht verboten ist. Mißbraucht wird es allenfalls dann, wenn ich einen Weg fahre, denke, der geht aber gar nicht und bicycle=no dran pappe. Das ist *eigentlich* falsch, denn das Radfahren ist dort ja nicht verboten. Das wiki erreiche ich gerade nicht, aber ich meine, zumind. in einigen Sprachversionen ist oder war [div. access] = no doppelt belegt durch rechtlich unmöglich und technisch unmöglich/ungeeignet oder so. Selbst wenn man sich da auf eins einigt: Es wird das jeweils andere fehlen und zu tag-Verklemmungen führen. Wir werden um ein =gehtnicht wohl nicht rumkommen mittelfristig ... Was wir auch noch bräuchten, wäre ein Wert bicycle=beachteseparateradwege oder cycleway=separatgemappt bzw. cycleway=teilweiseseparatgemappt Dann bicycle=no wird auch öfters falsch benutzt, um das Radrouting von der Fahrbahn auf die Radwege zu verbannen, wenn die nicht als cycleway an der Fahrbahn hängen, sondern separat gemappt sind. Auch da ist aber das bicycle=no aber so aus div. Gründen auch nicht richtig. Wenn wir dann noch eine klarere Linie in yes/designated/official bringen, um entlang von Straßen die verschiedenen Fällevon Benutzungspflicht abzubilden, und smoothness verinnerlichen, dann haben wir's doch ... ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenbank der Luftbilder für JOSM
Moin Bedeutet das, daß ich als Laie generell davon ausgehen kann, daß die amtlichen DOPs die relativ höchste Lagegenauigkeit haben, oder ist hier keine Verallgemeinerung möglich? Keine Regel ohne Ausnahme, aber ich würe davon ausgehen, dass Google, Bing und Yahoo tendentiell hauptsächlich zum Angucken, das aber gerne weltweit bestellen, da ist dann die Fläche der Preistreiber, und dass amtliche Stellen die Bilder bestellen, um mit ihnen richtig zu arbeiten, die Daten also zum Verschneiden mit anderen Daten haben wollen, wo es auf die Lagegenauigkeit ankommt und dass man daher mehr Geld in die Genauigkeit investiert (und auch investieren kann). Das merke ich auch daran, wie groß oder vielmehr klein die Versatzfehler sind, da man ja stets aus vielen kleinen Luftbildern das Endergebnis als Mosaik zusammen bastelt. Bei Bing und Google sind an Übergängen verschiedener Quellen und tw. auch innerhalb oft Versatzfehler zu sehen, die man in Dekameter beziffern kann, während die in dem amtlichen Luftbild, in dem ich gerade rummale, das ganze eher in Dezimeterbereich anzusiedeln ist, WENN man sowas überhaupt mal irgendwo bemerkt ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Küstenlinie Neuseeland wird nicht neu gerendert
Am 25.02.2011 16:58, schrieb Jochen Topf: Das ist nicht nur in Neuseeland so. Ich hab im Sommer Küstenlinien in England korrigiert, die auch nicht aktualisiert wurden. Offenbar hängt der Prozess. Nicht prinzipiell. Um Weihnachten gebingte coastline-Stückchen in Bremerhaven sind mittlerweile neu gerendert. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Jetzt Live: True Offset
Am 18.02.2011 01:16, schrieb Dermot McNally: True Offset soll verhindern, dass Mapper von unkalibrierten Luftbildern abmalen. Kann man damit auch lösen, dass Mapper vom falschen / schlechteren Luftbild abmalen? Sprich: Wenn es lokal ein besser aufgelösteres und aktuelleres Luftbild als Bing gibt, kann man dann ein Polygon definiert mit der Botschaft Nimm lieber mich! und wenn ja wie? Oder vielleicht ist ja stellenweise yahoo besser als bing etc. Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Lagegenauigkeit
Am 18.02.2011 15:27, schrieb Florian Lohoff: Fuer Nutzer ist es viel wichtiger zu wissen auf welcher Straßenseite der Briefkasten steht als das die Straße 5m neben irgendwelchen Koordinaten liegt. In der Tat. Wobei jeder m mehr Lagegenauigkeit die Wahrshceinlickeit verbessert, dass man mit GPS-Unterstützung den Briefkasten findet. Lagegenauigkeit wird IMHO total ueberschaetzt. Du unterschätzt aber völlig den Aspekt, dass eine lagegenau schön runde Straßenbahnwendeschleife unbestritten viel ästhetischer wirkt als ihr eckiges, nur topologisch korrekte Gegenstück! ;-) Gruß Wendeschleifenrundmacher-Mueck ;-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Karte im heutigen Hamburger Abendblatt...
Moin 3. Der kleine Park im Abendblatt ist in OSM nicht vorhanden udn auch die Form der umgebenden Straßen ist ebi OSM anders. Bspw. rum um das Elisabethgehölz http://www.openstreetmap.org/browse/way/8081390 ist die Form im Abendblatt charakteristisch anders (und falsch) im Vergleich zu allen anderen und OSM scheint die halbwegs korrekte Geometrie mindestens seit 2007 zu haben ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Neue Oberförsterrunde
... wird hier gemeldet: http://forum.openstreetmap.org/viewtopic.php?pid=142942#p142942 Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Idee für Relationssplittung
Am 25.01.2011 15:40, schrieb André Joost: Am 25.01.11 15:33, schrieb Jan Tappenbeck: ich habe hier eine Relation die soll nur bis zu einem bestimmten Punkt gehen und dann soll eine neue Anfangen. Nun sind da schon einem Vielzahl von Elementen angehängt. Hat einer eine Idee wie man die Elemente am einfachsen von der einen Relation absplittet und in die andere (schon vorhandene Relation) überführt? In josm: Relation im Relationseditor sortieren lassen (Symbol A..Z) dem letzten/ersten Element an der Trennung ein role-Tag verpassen Relation duplizieren (Pfeil nach unten rechts) in jeder der beiden Relationen die überflüssigen von/bis zu den role-getaggten rauslöschen (Symbol Papierkorb) Kennt jemand den Macher des Relations-Analyzer? Weil der sortiert ja vermutlich intern, um Lücken rauszufinden, hat also das wichtigste nötige Werkzeug schon eingebaut, da sollte es ein leichtes (?) sein, die Einzelsegmente als eigene Relation ausgliedern zu lassen vom RA. Dann bräuchte man nur an der passenden Stelle kurzfristig ein Loch reinzubasteln, bevor man RA bemüht ... Am besten gleich eine Master-Relation mit anlegen lassen, wenn noch nicht da. Oder generell eine Option, den RA die Relation sortiert auf den Server zu laden. Die Ideen kamen mir kürzlich mal, als ich den RA paar größere Relationen prüfen ließ. Oder man baut im RA gleich ein teile nach dem Weg _-Eingabefeld ein ;-) Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Darstellung von landuse=military in Mapnik-Karte
Am 23.01.2011 13:06, schrieb Wolfgang: Am Sonntag 23 Januar 2011 12:01:41 schrieb M∡rtin Koppenhoefer: landuse=military ist für alle Arten militärischer Landnutzung, feinere Unterteilungen könnte man einführen, sind aber im Moment AFAIK noch nicht in Gebrauch. wurde (wird?) im Zusammenhang mit military=baracks anders gerendert als ohne. Sieht im anderen verlinkten Beispiel http://www.openstreetmap.org/?lat=51.05lon=13.7561zoom=12layers=M so aus. Weil der Unterschied zwischen rot gestreift auf rosa rechts und rot gestreift auf weiß links scheint genau das Zusatztags Baracken zu sein ... Gruß Mueck ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
