Re: [Talk-de] Spezialgebiet Fahrrad-Mapping
zwar bei vielen nicht so beliebt, aber man könnte gut fahrbahre Strecken - mit class:bicycle hervorherben - gerade wenn diese auf primary-tertiary im Stadtgebiet entlangführen - da man höherrangige Straßen im Stadtgebiet normalerweise eher abwertet. On 05.10.2013 14:51, Wolfgang Schuch wrote: Hallo zusammen, ich bin seit eben neu in dieser Liste, weil ich für mein Spezialgebiet keine adäquate Informations- und Diskussionsmedium gefunden habe. Ich hoffe, dass ich hier die Info bekomme, wo ich für mein Interessengebiet die richtige Gruppe finde, denn ich will nicht alles mitbekommen ;-) Ich verfolge OSM schon lange und habe immer ein schlechtes Gewissen, dass ich mich aus Zeitmangel nicht mehr einbringe. Denn ich habe Informatik und Geographie studiert, bin seit fast 30 Jahren im ADFC auf Bundesebene aktiv, bin von Beruf Radverkehrsplaner (Spezialgebiet Radverkehrsnetze und Wegweisung). Ich will einerseits mein Fachwissen einbringen, andererseits beginnen zumindest die Netze, an denen ich beruflich beteiligt war in OSM korrekt abzubilden. Langfristig möchte ich gerne dafür sorgen, dass die Planersoftware der Radverkehrsplaner eine Exportfunktion nach OSM beinhalten. Ich bin auf der Suche nach einer Liste / Forum / Wiki in dem mein Spezialgebiet behandelt wird. Ich habe zwar einiges (mehr als vor 5 Jahren) gefunden, aber weder den Überblick, noch sicher alles. Über Hilfe würde ich mich freuen. Wolfgang Schuch RadWW ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-de
[Talk-at] Was soll eigentlich das überdrübergeniale footway=sidewalk Mapping im 4. Bezirk, und wie kann man den Südtiroler Platz korrekt mappen? Oder ein Rant an die Micromappingfraktion...
Hab mich grad mal wieder über das mapping der highway=footway, footway=sidewalk im 4. Bezirk geärgert. Wenn man schon meint das separat mappen zu müssen (sidwalk=yes würde an der Straße komplett ausreichen, da keine bauliche separierung), dann doch bitte gescheit, und nicht so einen Topfen zusammenmappen wie bisher. Etwa sind viele highway=footway auch für Fahrradfahrer nicht verboten - ergo müssen diese footways auch an die Straßen angeschlossen werden, und nicht nur an highway=footway footway=sidewalk - welche Tabu sind für Fahrradfahrer. Dazu gehören footway=crossing highway=footway, welche über eine Straße gehen, und damit die Straße kreuzen, auch mit der Straße verbunden (Node), anstelle diese einfach zu überqueren ohne gemeinsamen Node. IMHO ist der 4. Bezirk, untauglich verschandelt (oder Argentinierstraße - highway=cycleway separat gemappt, anstelle an der Straße cycleway=track, aber noch ein segregated=yes drangehängt. Dazu separat gemapped, highway=footway. Das die Lagegenauigkeit so natürlich absolut nicht mehr stimmt, ist die eine Sache, dass da dann aber mal wieder Kreuzungen komplett falsch verbunden sind, eine andere Sache...).. Dazu setzt der Südtiroler Platz, dem ganzen die Hauben auf. Hier sind die Fahrbahnen auch komplett verqueert gemapped. Kennt sich jemand im Lane Mapping aus, und kann das korrigieren? - Etwa überqueert man den Südtiroler Platz von Süd nach Nord, fährt man in Wirklichkeit nur gradeaus, und nicht mal mit Linksdrift, mal mit Rechtsdrift, um irgendwie queerende Straßen zu treffen. Ergo der separat gemappte Tunnel von je cycleway und highway unterm Hauptbahnhof hindurch, ist so definitiv falsch. Es gibt hier nur einen Tunnel, und den teilt sich ein highway und der cycleway - also cycleway=track (oder ist das sogar lane?) Das ganze Micromapping anstelle cycleway und footway Tag an der Straße, führt wie man hier schön sieht, ganz schön in die Scheiße! -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Was soll eigentlich das überdrübergeniale footway=sidewalk Mapping im 4. Bezirk, und wie kann man den Südtiroler Platz korrekt mappen? Oder ein Rant an die Micromappingfraktion...
ja, highway=corridor sollte kaum eine Karte darstellen (außer jene für indoor mapping). footway=corridor oder ähnliches ist keine gute Lösung - da es dafür extra Code bräuchte... On 18.07.2013 18:29, Manuela Schmidt wrote: On 18.07.2013 14:49, Norbert Wenzel wrote: On 2013-07-18 13:24, Stefan Tauner wrote: Das alte TU-Gebäude ist auch durchaus *ähem* interessant in Hinblick auf footways... http://osm.org/go/0JrIcECyg-- Ach du Sch Sollte man beim Indoor Mapping nicht highway=corridor verwenden? So ist das tatsächlich nur Müll. Das kann kein Mensch mehr routen, nichtmal wenn man sich auskennt. Und wie's ausschaut brauch ich eh net kommentieren, oder? Die Daten im TU-Hauptgebäude wurden im Rahmen der Lehrveranstaltung Location-based services erfasst, um Indoor-Routing mit verschiedenen Algorithmen zu testen - die anscheinend auch alle gut funktioniert haben. Wenn ihr dazu Feedback/Fragen habt - Ansprechperson dafür ist mein Kollege Huang Haosheng (Englisch-sprachig)[1] - oder ihr kontaktiert die Studierenden, die die Daten erfasst haben, über die Usernames direkt (ebenfalls großteils Englisch-sprachig). Kann man mit highway=corridor verhindern, dass die Wege im Standardrendering angezeigt werden? Wenn ja, wäre es vermutlich sinnvoll, das nachträglich einzufügen. lg Manu [1] http://cartography.tuwien.ac.at/haosheng-huang/ ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Treppen und Räder (steps access)
In der velomap und openmtbmap werte ich das schon aus ob up oder down. Velomap routet kaum über Treppen. Openmtbmap gerne bergab aber nicht bergauf. Und bitte bei mehr wie 5-6 stufen Highway=steps On Jul 16, 2013 7:27 AM, Peter Wendorff wendo...@uni-paderborn.de wrote: Hallo Dirk, Am 16.07.2013 01:11, schrieb Dirk Sohler: chris66 schrieb: incline=up sagt, dass der Weg in OSM-Way-Richtung aufsteigt. Also muss das Navigationsgerät auch die Richtung auswerten, in der die Linie gezogen wurde, die als Weg deklariert wurde? Ja und nein. Genauso wie bei Einbahnstraßen ist bei Treppen diese Richtung wichtig, aber das Navigationsgerät kennt die nicht mehr. Im Navi liegt ja nicht die .osm-Datei mit ihren Tags vor, sondern eine Datei, die daraus erstellt worden ist. Ja: Das Programm, das diese Konvertierung übernimmt, muss die Digitalisierungsrichtung der Ways berücksichtigen. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-at] Stammtisch im Wieden Bräu Wien - Heute 18:30
nur mal so zur Erinnerung da sich im Wiki bisher nur 3 eingetragen haben http://wiki.openstreetmap.org/wiki/Wien/Stammtisch -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Höhe von Berggipfeln, Almhütten, etc.
Wenn dein Wintec, keinen Altimeter hat, gehe davon aus, dass die Höhe falsch angezeigt wird. Nur mit Altimeter der durch GPS kalibriert wird, hat man sehr genaue Höhenangaben. (bei Garmin GPS nach 30min und gutem Empfang - ist danach +-5m selbstverständlich, die reine GPS Höhe wäre aber eher +-50m ). On 15.12.2012 18:52, Christian Aigner | caigner wrote: Hallo! Ich hab mein GPS-Gerät (Wintec WBT202) so eingestellt, daß es mir die Geoid-korrigierte Höhe eines Ortes anzeigt. Jetzt hab ich auf der OSM-Karte und auch vor Ort bei einer Almhütte doch um einiges abweichende Höhenangaben gefunden. Welche Höhe stimmt denn jetzt nun und welche soll als ele= eingetragen werden? LG, Christian ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Höhe von Berggipfeln, Almhütten, etc.
Dein Dakota 20, kalibriert aber auch den Altimeter dauernd per GPS. Schalt das mal aus, und schaus dir dann an, da hast dann schnell üble Schwankungen, auch auf Gipfeln... Dazu kalibriert es via DEM in Karte, falls vorhanden. Hier also am besten gar keine Karte für Tests verwenden (gibt ja auch noch Höhenpunkte die zum kalibrieren verwendet werden aus der Karte). On 16.12.2012 01:12, Friedrich Volkmann wrote: On 15.12.2012 18:52, Christian Aigner | caigner wrote: Jetzt hab ich auf der OSM-Karte und auch vor Ort bei einer Almhütte doch um einiges abweichende Höhenangaben gefunden. Welche Höhe stimmt denn jetzt nun und welche soll als ele= eingetragen werden? Die Höhenangaben an Hütten stammen machmal aus Zeiten, wo man noch nicht so genau messen konnte. Die Nemecek-Hütte bei Gießhübl ist höher angegeben als der Gipfel. Nimm am besten die Höhe aus dem Laserscan. Richtwerte: Vermessungsstein des BEV ... 0-1 m Laserscan ... 1-2 m Höhenkote des BEV ohne Vermessungsstein ... ~2m Barometer kurz nach Kalibrierung an Vermessungsstein ... ~3m GPS bei gutem Empfang ... ~5m Angaben an Hütten ... ~10m Barometer einen halben Tag nach Kalibierung ... 5-50 m On 15.12.2012 19:35, Felix Hartmann wrote: Wenn dein Wintec, keinen Altimeter hat, gehe davon aus, dass die Höhe falsch angezeigt wird. Nur mit Altimeter der durch GPS kalibriert wird, hat man sehr genaue Höhenangaben. (bei Garmin GPS nach 30min und gutem Empfang - ist danach +-5m selbstverständlich, die reine GPS Höhe wäre aber eher +-50m ). Fehler bis 50m kann man schon mal haben, aber nicht auf Bergipfeln. Da ist der Empfang meist doch recht gut, und wenn mein Garmin Dakota 20 viele Balken (=Satelliten) und eine Genauigkeit von 3m anzeigt. dann bewegt sich nach meiner Erfahrung auch die Höhe meistens in dieser Genauigkeit. Mein Rekord war eine Anzeige von 2m Genauigkeit am Zeilerberg, und da sagte das GPS exakt die selbe Seehöhe, die auch das BEV angibt. -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Taggen weicher Kriterien bei Radwegen
Du kannst class:bicycle benutzen, mir ist es zu müßig da jetzt dazulegen, warum es sinnvoll ist. Ich finde das es für stark abweichende (besonders gut zum fahren, besonders schlecht zum fahren) Abschnitte sehr sinnvoll ist. Sprich wenn objektive Kriterien nicht helfen, dann kannst du es über class:bicycle gut ausdrücken. On 12.12.2012 13:03, RainerU wrote: hallo, Im Zusammenhang mit der Erstellung einer lokalen Fahrradkarte stellt sich die Frage, ob es eine Möglichkeit gibt, Radwege und Radstreifen neben der auf der legalen Situation basierenden Attribute auch mit einer nutzerorientierten Klassifizierung zu versehen. Hintergrund ist der Wunsch, auf der Karte Wege, die zwar denselben Nutzungsver- und geboten unterliegen, aber auf Grund der Umstände für den Nutzer von ganz unterschiedlicher Qualität sind, optisch unterscheiden zu können. Ein Beispiel hierfür ist ein dedizierter Radweg (Zeichen 237), der aber aufgrund seiner Bauweise und Lage stark von Fußgängern frequentiert wird. Oder ein Radstreifen, der de facto seine Funktion nicht erfüllt, da die Markierung am Boden kaum erkennbar ist. Oder ein Radstreifen, dessen Benutzung wegen mangelnder Breite und/oder starken Lkw-Verkehrs für bestimmte Nutzergruppen unzumutbar ist. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezifische Radweg-Karte für Garmin?
Also das ist nicht so einfach wie du dir das vorstellst: a) häufig werden Relationen, und damit Routen zerstört, bzw fehlen auf Wegteilen b) Es gibt oft alternative und mehrere Routen - etwa dem Donauradweg in Krems folgen - ist egal ob mit oder ohne Karte, durch verschiedene Routen, bzw auf einmal aufhörende Beschilderung, ziemlich schwer. Gibt hier wohl unterschiedliche Ansichten von Behörden, Geschäften, Restaurants, wo der Wirtschaftsfaktor Donauradweg verlaufen soll. Ergo schauts in OSM da auch nicht ganz einheitlich aus. In Wien ist der Donauradweg auch mit mehreren Alternativrouten eingetragen. c) fehlen oft einfach noch Teile. Du könntest etwa bei der Velomap das Racing Bicycle Layout verwenden, da sind alle nicht asphaltierten Wege ganz dezent eingetragen, sprich du kannst die Route - die eh 6-10Pixel breit eingezeichnet wird, kaum verpassen. Oder du änderst halt ein .typfille ab, und verdoppelst dir die Breite alle Radrouten. Und Achtung, Radroute UNGLEICH Radweg. Du vermischst beides, was nicht grade zu Klarheit führt. -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezifische Radweg-Karte für Garmin?
On 04.09.2012 10:50, Lars Schimmer wrote: Und dennoch sind ALLE Radwege/Radrouten eingetragen. Schaue dir z.B. Holland/Belgien auf der OpenCycleMap an - alles blau. Dort einem Radweg/Radroute folgen ist schwer, wenn alles blau ist als Route. Deswegen will ich ja auch nur EINE Route haben, ggf. mit Alternativwegen, aber die alle zu der Router XYZ gehören (z.B. halt Donauradweg), die alle zum selben Ziel führen. Ich will nicht unterwegs die Route verwechseln und in 20km feststellen, das ich nun nicht mehr auf dem Donauradweg bin, sondern auf der Budapestrundfahrt, nur weil ich an einer Kreuzung alle Radwege/Strassen als Route farblich markiert sind und ich im Streß des Verkehrs nicht überlegen kann, welches denn die richtige ist... Oder du änderst halt ein .typfille ab, und verdoppelst dir die Breite alle Radrouten. Ich möchte auf der Karte aber nur EINE spezielle Radrouter markiert haben. Alle anderen sollen nicht aufscheinen als Route. Naja, daher hab ich in der Velomap etwa alle ICN/NCN in blau, und andere Routen in schwarz, man kommt also nicht so leicht ab. Aber nur eine Route, da musst du halt eine Overlaykarte benutzen. Einfacher ist, halt am PC eine Route vorplanen. Alle 10km einen Routenpunkt sollte reichen, will man nur auf Radrouten bleiben. 10x100 = 1000km kann man pro Route dann locker routen, und bleibt auf der Radroute. Bei neueren GPS gibts die Track Beschränkung so eh nicht mehr, da kann man auch mal 500km lange Tracks ans GPS senden (am einfachsten erstellt durch automatisch Konversion aus Route mit Basecamp). Und Achtung, Radroute UNGLEICH Radweg. Du vermischst beides, was nicht grade zu Klarheit führt. -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Spezifische Radweg-Karte für Garmin?
On 04.09.2012 10:50, Lars Schimmer wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-09-04 10:35, Felix Hartmann wrote: Also das ist nicht so einfach wie du dir das vorstellst: a) häufig werden Relationen, und damit Routen zerstört, bzw fehlen auf Wegteilen Ja, leider. Da müsste man entsprechend auffüllen. Ups, ganz vergessen darauf zu antworten. Aber genau das wird nicht funktionieren. OSM ist keine statische Datenbank, und Routenstücke wo Teile fehlen zu erraten, wird kein zufriedenstellendes Ergebniss bringen. Will man also wirklich nur Donauradwanderweg, dann am besten von einem Tourenportal Tracks in Tagesetappen runterladen, das wird zuverlässiger sein in dem Punkt wie OSM. Dazu nimmt man darunter eine Karte aus OSM, und es sollte sehr einfach sein Radroute XY zu folgen. -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] route/network=foot umwandeln in route/network=hiking
Was ist dafür die Begründung. route=foot hab ich mir bisher immer als innerstädtische Fußroute für Besichtigung von Attraktion usw vorgestellt. Dies auf einmal in route=hiking automatisch umzuwandeln, kann ich nicht verstehen On 28.08.2012 11:22, Jo wrote: Hallo, In Belgien werden wir alle route=foot und network=foot, umwandeln in ihre Synonyme route=hiking en network=hiking. Es gibt are welche die über die Grenze hingehen. Ist es für euch ein Problem das die auch umgesetzt werden, oder ist es besser dass ich diese Relationen trenne an der Grenze? Grüsse, Polyglot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
On 27.08.2012 07:55, Ronnie Soak wrote:
Sorry, bitte nicht falsch Verstehen. Ich habe nichts dagegen, dass ein
Router mir diesen Weg zeigen kann.
Aber das ist dann ein Feature des Routers, das eben auch bei diesem
implementiert gehört. Dort ist dann auch Platz für die Behandlung der
ganzen Nicht-Trivialitäten, die damit einhergehen (Öffnungszeiten,
Preise usw.).
Ich habe lediglich etwas dagegen, diese Funktionalität bereits jetzt,
quasi durch die Hintertür, ohne Anpassung der Router durch Tricks in
der Datenbank 'herbeigezaubert' werden soll.
HIer sind besagt Sonderfälle nämlich nicht mehr berücksichtigt, man
zwingt das Verhalten allen Routern auf und vermindernt den
Evolutionsdruck auf die Router ('Geht doch alles schon!')
Wobei weder ein Fussweg zur als-Node-gemappten Talstation noch
ordentlich ge-indoor-mappte Talstationsgebäude meiner Meinung nach als
'Tricks' zählen. Dass damit plötzlich das Routing funktioniert (ohne
Zeiten auszuwerten und extra Schalter anzubierten), würde ich eher als
Bug (oder besser: Übervereinfachung) im Router ansehen. Was für mich
ein no-go wäre, ist einfach mal geschätzte Fusswege durch Gebäude zu
zeichnen, nur damit das Routing klappt. Genau dafür (es gibt einen
Zusammenhang, aber keine (oder unbekannte) physische Verbindung) gibt
es Relationen.
Klar gibt es auch Router, auf die wir keinen Einfluss haben (z.B.
Garmin). Aber dann gehören diese Tricks wiederum in die tools wie
mkgmap und nicht in die Datenbank.
Allerdings bzw zur Klarstellung und Untermauerung:
Es gibt kein Routing durch die Hintertür (oh, auf einmal werde ich auf
einer Seilbahn geroutet), sondern es wird ermöglich, dass der Status
quo, der bis vor 1-2 Jahren herrschte, sprich Gondeln waren an Anfang
und Endnode mit Wegenetz verbunden, wieder hergestellt wird.
Ein Routing kann auch nur dann gehen, wenn Seilbahnen selber AUCH
routingfähig in der Karte eingetragen werden. Dies machen jedoch kaum
Karten.
Die Argumentation bzgl Tricks, wäre dagegen wirklich Mappen für die
Renderer - wenn befürwortet wird keine Wege zu den Seilbahnen
einzuzeichnen, damit dort nicht mehr geroutet wird! (was ja sowieso fast
nirgends, selbst bei direkter Anbindung an das Wegenetz passieren würde).
Und ein Fußweg durch ein Gebäude, ist ein Fußweg, der existiert auch
real! Und es gibt derzeit noch keine Definition, wann wie wo man Fußwege
nicht einzeichnen dürfte, weil sie in Gebäuden verlaufen. Generell
werden Fußwege in Gebäuden allgemeinen Interesses, eingezeichnet. (Etwa
Fußweg durch ein Eingangsgebäude in einen Park, hier sogar mit Entrance
Node klargestellt). Hier geht es eher um die Frage, wann und wo zeichnen
wir Wege in Gebäuden ein, und wie sollten wir diese Kennzeichnen. In
Krankenhäusern oder Einkaufszentren, sind etwa auch sehr viele Indoor
Wege gemappt!
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
On 23.08.2012 16:11, Ronnie Soak wrote: Ich frage mich dann allerdings schon, wo aus Sicht von OSM der Unterschied zwischen 'normalem' ÖPNV (keine 'Fußwege' zwischen Bahnhofseingang und Schiene) und Seilbahnen sein soll. Naja, der Unterschied ist für mich, dass man bei echtem ÖPNV-Routing halt noch viel viel mehr Dinge beachten/implementieren muss, die sonst bei 0815 Routing nicht beachtet werden müssen. a) Das Routing für ÖPNV kann nicht highway/railway basiert sein, sondern wird sich zu 99% an Relationen orientieren müssen. Dazu macht es ohne Fahrpläne oder zumindest Fahrzeiten, von z.Bsp 06:00 bis 23:30, keinen Sinn. Will ich auch noch vernünftige Hinweise geben wie man zu Fuß von Gleis X nach Gleis Y kommt, wirds nochmal viel viel komplizierter. Mehr oder weniger ist OSM hier derzeit einfach völlig ungeeignet. -- Will man dagegen nur Seilbahnen in das Routing von Wander/Mountainbike/Fahrradkarten einschließen, braucht es quasi nix neues, es muss halt nur eine Verbindung von aerialway=XXX zum highway=XXX geben. Die Wege mag natürlich mappen wer will (interessehalber: benutzt du einen speziellen Wegetyp für Laufwege in Gebäuden?), aber so etwas als 'gehört einfach dazu' zu bezeichen, finde ich dann doch etwas überzogen. Nein, ich würde nicht sagen so etwas gehört einfach dazu, nur war es vor 1-2 Jahren noch meist einfach dazugehörend. Nun wurden jedoch sehr viele dieser Wege einfach gelöscht, und das ohne Diskussionen, was ich als Vandalismus ansehe. Welchen Typ? Nun das kann man ja gerne diskutieren. Bisher hab ich meist footway oder service genommen. aerialway=platform oder ähnliches fände ich auch volkommen okay. Zumal sich direkt die Diskussion um komplizierte Zugangsbeschränkungen, Zugangszeiten, Preisen usw. anschliesst. Wohl eher nichts für den Otto-Normal-Mapper. Ich würde ebenfalls diese Wege nicht mappen, eben weil ich diese Punkte nicht klar beantworten kann, sie aber ein erheblicher Bestandteil des Weges sind. Ich möcht nämlich zum Beispiel nicht, dass mich mein Wanderrouting-GPS bei Bergwanderungen zum Lift lotst, weil da wichtige tags fehlen. Nun, derzeit wird es dich wohl zu keinem Lift lotsen, weil seltenst verbunden. Allerdings haben wir eben Fähren und Autoverladezüge schon direkt mit linien verbunden, eben genau damit hier Routing funktioniert. Und da beschwert sich auch niemand, wieso und wie er über den Ärmelkanal geroutet wurde Es wird wohl bei jedem Programm, Karte die Seilbahnen als Routingfähig einbaut, eine Möglichkeit geben eben dies auszuschließen. (bei Garmin etwa geht das easy). Wenn der Router nunmal kein Routing über Seilbahnen unterstützt und man OSM-untypische oder zumindest -unüblich Konstruktionen benötigt, um es doch durch die Hintertür zu ermöglichen, dann ist doch ganz klar der Feature-Request beim Router besser aufgehoben. Ich würde mal behaupten, dass die Anzahl funktionierender ÖPNV-Router noch überschaubar ist. Es sind nunmal keine untypischen Konstrukte, sondern bei Fähren etwa ganz normal, und dort auch nicht anders. Noch war es von 1-2 Jahren auch der Standard, dass man aerialway direkt an highway angeschlossen hat. Nur haben wohl viele, nach mappen der Stationsgebäude als viereckigen Kästen (genauer ist es ja selten), diese Wege einfach gelöscht. my 2 cents Chaos Am 23. August 2012 15:04 schrieb Felix Hartmann extremecar...@gmail.com: Das seh ich ganz anders, da gehören die Wege im Haus einfach dazu, und ich frag mich wer solche In Hause Wege halt etwa gelöscht hat, da ich diese schon recht oft angelegt hab. On 23.08.2012 14:49, Andreas Labres wrote: ReHi! Wenn Du z.B. bei Seegrube oder Patscherkofel schaust, da ist immer das Gebäude gemappt, sprich da endet der Bahn- oder Gondel-Way im Gebäude. Da kannst Du nur ein Öffi-Routing machen, indem man annimmt, daß man auf der Hungerburg (http://osm.org/go/0IUSihE3w--) von der Hungerburgbahn zur Seilbahn umsteigen kann. Da jetzt ein inhouse-Routing und vielleicht Fußwege von Gebäudeeingang zur Straße einzeichnen wäre wohl zu viel verlangt, oder... Also ich würde an Deiner Stelle diese Seilbahnendpunkte müssen mit Wegen verknüpft sein Idee eigentlich schnell wieder vergessen. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
On 24.08.2012 09:02, Andreas Labres wrote: On 23.08.12 15:00, Felix Hartmann wrote: im Bereich von railways und ÖPNV Routing, kann ich ja noch irgendwie einsehen, dass man dies vom Router verlangen soll, da es die Hauptaufgabe des Routers ist. Da es bei Bergbahnen, nun aber nicht um klassischen ÖPNV geht, IMO sind in Sachen Routing Berg/Seilbahnen um nix anders zu behandeln als jede andere Art Bahn. Aber warum behandeln wir dan Fähren anders? Würde jemand alle Wege zu fähren (da gibt es auch sehr häufig Zugangsgebäude) löschen, dann würde hier fast jeder von Vandalismus sprechen. Es gibt einfach noch keine Algorythmen die vernünftiges Flächenrouting beherschen, und selbst wenn diese existieren, wird es unverhältnismäßigen Aufwand bedeuten. Ich weiß nicht, wie Du jetzt auf Flächenrouting kommst, aber ja. Wenn es keine Verbindung per Linie gibt, dann braucht man folglich ein Flächenrouting, und das ist halt prinzipiell alles andere als optimal. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
On 24.08.2012 09:03, Andreas Labres wrote: On 23.08.12 15:04, Felix Hartmann wrote: Das seh ich ganz anders, da gehören die Wege im Haus einfach dazu, und ich frag mich wer solche In Hause Wege halt etwa gelöscht hat, da ich diese schon recht oft angelegt hab. Nicht bös sein, aber das ist einfach keine gute Idee, IMHO. Servus, Andreas Ah und noch ein weiterer Einwand. Wenn wir nun etwa aerialway=platform einzeichnen, aber nicht verbinden, dann haben wir einen größeren absoluten Fehler, wie wenn wir es verbinden. Noch dazu könnten wir etwa auch bei Seilbahnen, jedes Seil einzeln einzeichnen, schließlich laufen die ja meist mit 5-6m Abstand, oder bei Telegondeln/Sesseln die Schleife im Umlauf. Dies tun wir aber nicht - obwohl es sich hier um recht große absolute Fehler handelt. Bei Bahnlinien, zeichnen wir ja auch jedes Gleis ein, bei Seilbahnen nicht (und das halte ich auch nicht für sinnvoll). Es gibt einfach doch obwohl beides Bahn im Namen hat, sehr sehr große Unterschiede. -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
Ich hab grad ziemlich einen Schock bekommen, wie ich bemerkt hab, das Gondeln, Sessellifte und Schlepper in Österreich und Deutschland scheinbar nie man an das Wegenetz direkt angeschlossen sind. Vor gut ein zwei Jahren war das noch ziemlich anders. Hat da irgendjemand systematisch die Wege gelöscht? Teils sind dagegen Pisten direkt verbunden! Andere öffentliche Verkehrsmittel, haben wir schließlich auch verbunden mit dem Wege/Staßennetz (etwa Fähren, Autoverladung, Ubahnen, usw.). Ein Routing unter Einbezug der Gondeln, Sesselliften und Co. ist so unmöglich. Dazu kommt noch, dass kaum eine Gondel direkt mit einer Piste verbunden ist, auch im Winter (Sessellifte dagegen schon), so dass man doch schon Wege in OSM haben sollte. Frage ist daher, wie schaffen wir es Gondeln und Sessellifte so an das Wegenetz zu verbinden, das nicht wieder Vandalen dies löschen. Oder braucht es eine eigene Wegart für Wege vom öffentlichen Wegenetz zu Verkehrsmitteln des ÖPNV und Co? highway=service access=no foot=permissive ?? highway=footway ?? highway=path ?? -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
On 23.08.2012 13:59, Rainer Kluge wrote: Hallo, Am 23.08.2012 12:02, schrieb Felix Hartmann: Andere öffentliche Verkehrsmittel, haben wir schließlich auch verbunden mit dem Wege/Staßennetz (etwa Fähren, Autoverladung, Ubahnen, usw.). Was spricht dagegen, Seilbahnen genau so zu handhaben wie schienengebundene Bahnen, d.h. mit einer Plattform aerialway=platform, die mit dem Straßennetz verbunden ist? Dazu kommt noch, dass kaum eine Gondel direkt mit einer Piste verbunden ist, auch im Winter (Sessellifte dagegen schon), so dass man doch schon Wege in OSM haben sollte. Willst du die einzelnen Gondeln mappen? Ich vermute du meinst die Seilbahn, also die Trägermasten, das Kabel und die Berg- und Talstation. Logisch. Einzelne Gondeln sind ja mobil, und daher eh nicht mappbar. Frage ist daher, wie schaffen wir es Gondeln und Sessellifte so an das Wegenetz zu verbinden, das nicht wieder Vandalen dies löschen. Wenn es man mit aerialway=platform, dann stellt es sich für das Routing wie ein Bahnhof oder eine Straßenbahnhaltestelle dar. Und gegen Vandalen hilft nur Aufmerksamkeit. Dagegen spricht nichts (solange die platform dann auch mit dem Seil/bzw Trasse verbunden wird ) , nur dass dieser Tag einfach weder existiert, noch dokumentiert ist - siehe etwa: http://tagwatch.stoecker.eu/Colombia/Fr/tagstats_aerialway_platform.html So ein Tag kann gerne eingeführt werden, und hab ich in der ersten Mail ja auch vorgeschlagen. Der Status Quo, dass es scheinbar einige User gibt, die da konsequent footway und service gelöscht haben, ist schließlich nicht tragbar. Dazu fragt sich dann auch, von wo nach wo zeichnet man aerialway=platform. Will man damit nur den Einstiegsbereich taggen, oder zählt der Weg im Gebäude zum Einstiegsbereich auch schon als platform? Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
On 23.08.2012 14:38, Andreas Labres wrote: On 23.08.12 14:22, Felix Hartmann wrote: Dagegen spricht nichts (solange die platform dann auch mit dem Seil/bzw Trasse verbunden wird ) PMJI, aber das ist IMO ein Denkfehler... Bei Bahn/Straßenbahn wird die Plattform auch nicht mit dem Gleis verbunden. Das muß der Router sich ggf. schon zusammensuchen, dass er von der stop_position auf dem Gleis zur platform eine gedankliche Verbindung macht. gedankliche Verbindungen ... im Bereich von railways und ÖPNV Routing, kann ich ja noch irgendwie einsehen, dass man dies vom Router verlangen soll, da es die Hauptaufgabe des Routers ist. Da es bei Bergbahnen, nun aber nicht um klassischen ÖPNV geht, wäre die Konsequenz hieraus, OSM wird für 99% aller Anwendungen, im Punkt, Einbeziehung von Bergbahnen ins Routing, untauglich bleiben/werden. Es gibt einfach noch keine Algorythmen die vernünftiges Flächenrouting beherschen, und selbst wenn diese existieren, wird es unverhältnismäßigen Aufwand bedeuten. IMO muß man da einen Kompromiss machen: solange die Talstation (oder Bergstation oder was immer) als ein einziger Punkt gemappt wird, sollte auch ein Gehweg oder eine Piste in diesem Punkt enden. Macht man Micromapping, dann kann man z.B. den Weg von Gondelschienen (für ausgehakte Gondeln) mappen (wahrscheinlich mit einer stop_position; vielleicht auch mit eigenen Schienen-Tags) und getrennt davon die Plattform. Servus, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gondeln und Anschluss an das öffentliche Straßen/Wegenetz
Das seh ich ganz anders, da gehören die Wege im Haus einfach dazu, und ich frag mich wer solche In Hause Wege halt etwa gelöscht hat, da ich diese schon recht oft angelegt hab. On 23.08.2012 14:49, Andreas Labres wrote: ReHi! Wenn Du z.B. bei Seegrube oder Patscherkofel schaust, da ist immer das Gebäude gemappt, sprich da endet der Bahn- oder Gondel-Way im Gebäude. Da kannst Du nur ein Öffi-Routing machen, indem man annimmt, daß man auf der Hungerburg (http://osm.org/go/0IUSihE3w--) von der Hungerburgbahn zur Seilbahn umsteigen kann. Da jetzt ein inhouse-Routing und vielleicht Fußwege von Gebäudeeingang zur Straße einzeichnen wäre wohl zu viel verlangt, oder... Also ich würde an Deiner Stelle diese Seilbahnendpunkte müssen mit Wegen verknüpft sein Idee eigentlich schnell wieder vergessen. /al ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de -- keep on biking and discovering new trails Felix openmtbmap.org www.velomap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Mittwoch!
Nur mal so als Erinnerung, bisher haben sich erst 3 User im Wiki eingetragen... lg bis heute Abend, Felix On 09.07.2012 19:26, Andreas Labres wrote: On 09.07.12 19:14, Werner Macho wrote: Ich wollt mich nur kurz melden und euch sagen das Mittwoch für mich leider nicht geht. Ich bin grad mit Arbeit eingedeckt worden und fahre Donnerstag aber für ne Woche weg. Leider keine Chance die Neuigkeiten Agit zu Präsentieren .. Wobei ich aber ehrlich gesagt auch nicht gewusst hätte was ich dazu sagen soll .. Alles klar. Danke! Ich werde die Ankündigung im Wiki dann gleich auf 18:30 beim Wieden Bräu ändern... BTW, falls jemand früher dort ist, könnte im Garten zwei Tische besetzen... sie nehmen im Garten keine Reservierungen an... Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] was bedeutet bicycle:backward?
On 28.06.2012 13:07, Tobias Knerr wrote: Am 28.06.2012 10:52, schrieb Martin Koppenhoefer: Wie oben angegeben: bezieht sich bicycle:backward auf die Richtung des ways oder die Richtung der Einbahnstraße? Auf die Richtung des Ways. Spielt vor allem dann eine Rolle, wenn der tag oneway=-1 ist. Achtung: Zumindest nach den Auswerte-Regeln, wie sie im zugehörigen Proposal definiert wurden, kann man Einschränkungen nur durch andere Tags überschreiben, die denselben Grundschlüssel verwenden: Eine Ausnahme von maxspeed muss mit maxspeed:... anfangen, eine von maxweight mit maxweight:..., und eine für oneway eben mit oneway:...! Eine Ausnahme von der Einbahnstraßen-Regelung für Radfahrer muss nach diesem Schema also oneway:bicycle verwenden, um bei der Auswertung überhaupt berücksichtigt zu werden. Wer/wo hat den bitteschön bicycle:backward definitert? Es gibt ja schon cycleway:opposite=yes/no/both/lane/track (was wiederrum auch nichts über die Fahrtrichtung gegen Einbahn aussagt, sondern im Prinzip nur wo es Möglichkeiten zum Fahrradfahren gibt). Es braucht keinen zusätzlichen Tag Wildwuchs... oneway:bicycle=no/yes (meinetwegen auch oneway:bicycle=-1/reverse) ist das korrekte Tag. Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Cycle lanes cycle tracks - my findings and a proposal
p.s. Personally I feel that cycle TRACKS would be much easier to map if drawn as a separate highway=cycleway (despite any challenges the renderers and routers currently have with this) - it just makes things a lot easier!! No, no,no,no As for changing the cycleway key values: If we do that, we actually loose too much information. Yes, changing the current cycleway key, could be a rather good idea. But don't replace it by something not better. If we want to change it, then we should a) wait for the editors to support proper lane mapping b) wait for the editors to support proper junction mapping c) think about how to do it once the above is working and accepted. Don't change the cycleway key now. It ain't perfect, but with :left and :right it covers most situations and it isn't difficult to understand. Some places for thought: http://wiki.openstreetmap.org/wiki/Proposed_features/highway%3Djunction and http://wiki.openstreetmap.org/wiki/Proposed_features/Lane_group P.S. this is better placed on the tagging mailinglist ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Freeride Trail : wie taggen ?
On 11.05.2012 15:03, Chris66 wrote: Am 11.05.2012 14:27, schrieb Alech OSM: Natürlich ist ein Freeride Strecke für MTB ein „highway=path“ , Naja path ist erstmal ein Weg primär für Fussgänger/Radfahrer/Reiter. Also nicht vergessen die mtb:xyz Tags hinzuzufügen. So dass Router die Möglichkeit haben diese Wege fürs Routing herunter zu gewichten. Bzgl. der speziellen Hindernisse und Sprungschanzen hat sich noch nichts durchgesetzt IMHO. mtb:barrier = xyz fänd ich nicht schlecht. wenn schon mtb:obstacle ... weil es nun mal keine Barrieren sind, sondern Features und die englisch zum Mountainbiken unter obstacles zusammengefasst werden. Wenn du das wirklich machen willst, leg mtb:obstacle im wiki an, verlinke es auf der mountainbike Übersichtsseite, und stell mal die Haupttypen an obstacles mit Pic rein. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] online tool: track selector für tracks ohne tracktype
Ich sehe tracktype als eindeutig schlechter wie smoothness an, wenn es um Radeln geht. Surface ist im Prinzip zwar nett, in der Praxis liegt man da aber bei 5-10% komplett daneben, sprich surface werten man nur dann aus, wenn kein smoothness oder tracktype vorliegt, bzw für tracktype 5. tracktype 4/5 sind leider in den Tagginggewohnheiten sehr unterschiedlich, sprich beim auswerten weiß ich nicht was sich dahinter verbirgt. Ab tracktype 4/5 braucht man zusätzliche Attribute wie mtb:scale -- muss unterscheiden ob footway/path/track, oder das vermaledeite (weil häufig nicht verstandene) sac_scale oder eben auch surface. Wenn es um Wege geht die tracktype 3-5 sind, und nicht mit mtb:scale getagged sind, dann macht smoothness einfach viel mehr Sinn. Einen track selector halte ich daher für ziemlichen Stuss, weil eben häufig aus gutem Grund kein Tracktype angegeben ist (weil es nicht differenziert genug ist). Selbst bei grade1/2 gibt es ja genug Probs. Sprich sinnvoller wäre ein smoothness selector On 07.05.2012 13:48, Sven Geggus wrote: Adrian Stabiszewskimynewslet...@nitegate.de wrote: Danke fürs Feedback. Persönlich sehe ich surface als viel zu detailliert an, so dass ich mit tracktype ein Minimum an Information haben möchte, das aber gut zu verwenden ist. Dto. Als Radfahrer interressieren mich (mal abgesehen von surface=cobblestone) lediglich tracktype1, tracktype2 und notfalls tracktype3, der Rest ist nichts für normale Radler und für Mountainbike gibt es mtb:scale. Die Idee ist, die Erfassung der tracktypes zu vervollständigen, da wir bei geschätzten 90% liegen. Jepp, finde ich Klasse. Ich könnte Dir anbieten eventuell mit mapnik ein Overlay zu rendern. Außerdem sehe ich den tracktype aus der Radfahrerperspektive und hier brauche ich einfach nur die Info: Rennrad-tauglich (grade1), Trekkingrad-tauglich(grade1-3) und MTB (grade1-5). dto. Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] online tool: track selector für tracks ohne tracktype
cobblestone ist wirklich ziemlich genau vorstellbar - auch wenn es da große Unterschiede gibt. Aber surfaces wie sand, earth, sind total nutzlos. Sand kann etwa von Strand (unfahrbar mit Rad) zu sandigem Boden fast alles sein. Aber bleiben wir mal lieber bei der Liste der Häufigkeiten Absteigend. 1: Paved ::: nutzlos wenn smoothness oder tracktype angegeben ist 2. Unpaved ::: kann quasi alles bedeuten 3. Asphalt ::: das ist recht gut einschätzbar. Aber gibt auch noch ganz gute Unterschiede 4. Gravel ::: ist normalerweise grade2/3 -- recht gut einschätzbar. 5. Ground ::: nicht einschätzbar 6. Grass::: kann mal wieder fast alles bedeuten (von 50cm hoher Wiese bis super Fussballrasen) 7. Dirf ::: ROFL 8 Paving Stones ::: recht gut einschätzbar 9: Concrete ::: recht gut einschätzbar 10: Cobblestone. recht gut eischätzbar So jetzt rechnen wir mal zusammen unter allen relevanten typen sind grad mal so 33% einschätzbar. Wie man da von einem sinnvollen Tag sprechen kann ergibt sich mir leider überhaupt nicht. Ja zusätzlich ist surface super. Aber alleine meistens sinnlos Siehe: http://taginfo.openstreetmap.org/keys/?key=surface#values Wenn also mal wieder von den so toll auswertbaren surface values gesprochen wird, dann bitte beachten wie häufig die vorkommen On 07.05.2012 16:40, aighes wrote: Am 07.05.2012 16:19, schrieb Felix Hartmann: Surface ist im Prinzip zwar nett, in der Praxis liegt man da aber bei 5-10% komplett daneben, sprich surface werten man nur dann aus, wenn kein smoothness oder tracktype vorliegt, bzw für tracktype 5. Wie meinst du das mit dem daneben liegen? Wenn da surface=asphalt getaggt ist, sollte dem doch auch so sein. Ähnlich bei cobblestone, concrete und wie die ganzen anderen values lauten. Sicherlich gibt es da auch den einen oder anderen Fehler in den Daten, aber den hat man doch bei tracktype auch. Dazu muss man ja nur den thread hier zu lesen, wo da die Interpretationsgrenzen liegen. smoothness ist unabhängig von surface und tracktype auch sinnvoll, aber keiner der beiden macht eine Aussage über smoothness laut wiki-Definition aus. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] online tool: track selector für tracks ohne tracktype
On 07.05.2012 17:50, aighes wrote: Am 07.05.2012 17:15, schrieb Felix Hartmann: Aber bleiben wir mal lieber bei der Liste der Häufigkeiten Absteigend. 1: Paved ::: nutzlos wenn smoothness oder tracktype angegeben ist Sagt immerhin aus, dass ich da bei Dauerregen lang kann, ohne im Schlamm zu versinken, etc. Nein. Absolut nicht. Werte wie Gravel oder Earth sagen nichts über die Beschaffenheit von Wasserablaufrinnen in einem wenig befestigten Weg aus. Nur bei Asphalt oder anderen guten Werten kann man davon ausgehen. Aber auch hier kann seitlich Dreck draufgespült werden. Ich kann es vielleicht zu 70-80% annehmen, aber besser nicht. 2. Unpaved ::: kann quasi alles bedeuten Sagt halt aus, dass der Weg nicht befestigt ist. Je nach Interessengebiet kann das entscheidend sein oder nicht. Beide haben aber eine Aussage. Ob die nun fürs Radrouting sinnvoll erscheint, muss jeder selber wissen. Auf Karten der betroffenen Regionen (wo noch nicht alle Verbindungsstraßen asphaltiert sind) wird jedenfalls unterschieden zwischen befestigte Straße und unbefestigte Straße. Wenn diese Unterscheidung sinnlos wäre, würde man sie in den Karten wohl kaum unterscheiden. Henning Ja sie hat schon eine Bedeutung, aber viel aussagen tuts trotzdem nicht, denn die Überlappung ist viel zu groß. (was ist paved, was ist unpaved). Sinnvoll mit einem Zweck auswerten kann man es kaum. Sprich, existiert auch nir irgend ein anderer tag wie etwa smoothness, tracktype, usw, dann ist die surface in dem Fall komplett egal. Es ist nicht so dass ich Surface komplett als Unsinn empfinde, aber der größte für mich gute Nutzen wäre etwa beim Routen/Tourenplanen eine Statistik für die komplette Strecke mit Anteil, Erde, Anteil Gras, Anteil Asphalt usw anzuzeigen. Das wird man halbwegs gut hinbekommen (wobei die diversen neuen extrem spezifischen Werte natürlich viel ARbeit zum einpflegen bedeuten). Auf einer amtlichen, koherenten Karte, ist der Sinn zwischen unpaved und paved ganz anders. Da weiß man welche Kriterien mit hoher Genauigkeit zur Unterscheidung genutzt wurden. Bei OSM wissen wir es überhaupt nicht, selbst regional sind die Unterschiede oft schon groß. Ausserdem fällt es schwer (weil nirgendswo definiert) die zahlreichen surface values in paved/unpaved aufzuteilen. Gibt zu viele die weder noch sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auszeichnung fuer Bikepark gesucht
On 22.03.2012 10:17, aighes wrote: Am 22.03.2012 10:08, schrieb Schorschi: es wäre prima, wenn jemand aus der Bike- oder MTB-Fraktion noch mal seine Meinung abgibt. Ich hab jetzt mal folgendes genutzt: leisure=track mtb:type=bikepark sport=cycling und die folgenden habe ich auch noch angehängt, das ist aber eher Informations-Dopplung oder? Wenn leisure=track auch als Linie definiert ist, würde ich das area=yes setzen, ansonsten nicht. Wichtig fände ich noch die Oberfläche zu erfassen. Ist das nun eine Schlammbahn, oder eher sowas Halfpipe-ähnliches oder gar eine Strecke fürs Bahnradfahren. Das lässt das das sport=cycling noch offen. Kenne mich in der Szene aber zu wenig aus, als das ich hier Fachbegriffe für eine nähere Beschreibung abgeben könnte. Henning Also primär kann man natürlich beides mappen, die area und die Wege an sich. Hier muss man jetzt halt etwas aufpassen ob wir BMX zu Mtbike zählen oder nicht. Ich würde mal sagen ja, allerdings sollte das oben beschriebene eher mtb:type=dirtjump oder mtb:type=bmx heißen. Ein Dirtjumppark / BMX Strecke ist für mich kein Bikepark. Bei einem großen Bikepark ist es IMHO auch sinniger, wenn man nur die Trails an sich mapped, wir wollen ja nicht etwa das komplette Gebiet Portes du Soleil als Bikepark taggen - oder da um die ganzen Lifte rumherun Flächen ziehen. Skigebiete werden ja auch nicht als area gemapped, sondern die Pisten an sich. Bei einer kleinen BMX Strecke, Dirtjump park, wo sich alles schnell ändert (einmal die Wochen fahrens mit dem Caterpillar durch, und ändern alles) macht dies dagegen evtl schon Sinn. Weil die einzelnen Obstacles/Trails zu mappen nicht sinnvoll ist a) weil es sich zu schnell ändert b) weil man es für die Orientierung nicht braucht - die Übersichtlichkeit ist weil klein eh gegeben. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Karte mit Skipisten?
On 05.03.2012 18:43, Bodo Meissner wrote: On Mon, Mar 05, 2012 at 09:30:28AM +0100, Felix Hartmann wrote: Pisten anhand schwierigkeit habe ich etwa in der Openmtbmap.org bzw VeloMap integriert... Das ist schon fast, wie ich es mir vorgestellt hätte. piste:ref werde ich zum nächsten Update auch integrieren, hab den Key noch gar nicht gekannt Super, danke. Es gibt auch noch piste:name, aber das wäre für mich weniger wichtig. (Keine Ahnung, warum für die Pisten nicht einfach ref und name verwendet wird.) Ich hab mir schon gedacht dass piste:name auch existiert, und hab es daher gleich auch für den Namen gesetzt, allerdings nur wenn kein name existiert. Primär ist die Karte halt doch für den Sommersport gedacht, und manche Pisten(teile) haben halt mehrere Nutzungen. Es hängt vielleicht vom Skigebiet ab, ob zur Orientierung die Nummern oder Namen besser geeignet sind. (Ich hatte bisher an den Pisten nur Schilder mit Nummern.) Ich würde mir das so wünschen, daß die Pisten-Nummern direkt sichtbar sind und die Namen als Zusatzinformation angezeigt werden, wenn man mit dem Pfeil auf die Piste zeigt. Wenn keine Nummer definiert ist, könnte möglicherweise der Name direkt angezeigt werden. Es gibt keine Möglichkeit zwischen Pop Up Name und angezeigtem Name zu unterscheiden im Garmin Format. Mir ist aber auf meinem GPSMAP76CSx aufgefallen, daß die Pisten mit dem Pfeil nicht selektierbar sind. Bei mir wurde immer nur eine Bezeichnung für den Hintergrund angezeigt. (Bei Höhenlinien wird in einem Mini-Popup die Höhe angezeigt, wenn der Pfeil darauf steht.) Sind die Pisten für das Gerät andere Objekte als Wege oder Höhenlinien? Nur Pisten die als Polygone angelegt sind (sehr selten) sollten nicht anklickbar sein. Viele Grüße Bodo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Garmin-Karte mit Skipisten?
Pisten anhand schwierigkeit habe ich etwa in der Openmtbmap.org bzw VeloMap integriert... piste:ref werde ich zum nächsten Update auch integrieren, hab den Key noch gar nicht gekannt On 02.03.2012 20:26, Bodo Meissner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo alle, gibt es eine fertige Garmin-Karte auf der Skipisten dargestellt werden? Oder hat jemand schon eine geeignete Konfiguration, um eine solche Karte selbst zu generieren? Ich würde gern den Schwierigkeitsgrad (piste:difficulty) und die Nummer (piste:ref) erkennen. Viele Grüße Bodo -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAk9RHskACgkQnMz9fgzDSqc3oACcD7f7lCkFTOz7W3sVHxDZEkKf SHYAniFjCXpVRwvJ5YGuJIR9ogawW8TD =VtHB -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Anlieger
In fast allen Fällen gehört dort ein motor_vehicle=private/destination/... hin, und nur ganz selten ein access=? solche Fehler kommen leider viel zu häufig vor. Fahrverbote gelten meist nicht für Fußgänger, Pferde, Radfahrer, usw On 27.02.2012 10:06, Andreas Labres wrote: On 26.02.12 20:57, Norbert Wenzel wrote: Daher würd ich vorschlagen nur das allgemeine access=destination zu taggen, ACK, bzw., wenn dort eindeutig ein Fahrverbot steht oder was von Privatstraße, dann access=private. Danke für die Mail. Ich war heut in der Gegend und die Mail kam genau bevor ich extra vorbei gefahren wäre. Danke für die Warnung. ;-) Wenn ich Schottenhof fahre, liegt das auf meinem Weg... aber wie gesagt, man müßte sich mal mehr Zeit nehmen. Grade der Nordhang in Neustift wimmelt von Fahrverbotsschildern mit Anrainer-Ausnahmen (wohl sicherlich auch, um die Heurigen-Parker abzuhalten). Das sollte man mal systematisch durchschauen. Servus, Andreas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Wer kennt OSM in den Alpen bei Wien/Niederösterreich?
Ich würde mich schon ganz gut auskennen... du kannst mir ja mal die Kontaktdaten weiterschicken... On 23.02.2012 06:47, Friedrich Volkmann wrote: On 22.02.2012 23:14, Holger Schöner wrote: Ich stehe in Kontakt zu einer Reporterin vom ORF, die für die Sendung Newton jemanden sucht, der/die sich mit OSM in Wandergebieten (Alpen?) um Wien bzw. Niederösterreich auskennt (Gebiete mit sehr guten Daten, aber evtl. auch welche mit weniger guten; vielleicht auch Nutzung von OSM beim Wandern?). Da ich mich eher in Oberösterreich auskenne, würde ich ihr gerne jemanden vermitteln, der sich mit ihrem Interessensgebiet besser auskennt. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Orf.at mal wieder
Damit verletzen sie aber weiterhin meine Copyrights (Kaskadierung)... Andereseits promoted sich Herr Lehner mit meiner Arbeit... On 20.02.2012 10:06, Norbert Wenzel wrote: On 19.02.2012 19:06, Felix Hartmann wrote: Siehe http://salzburg.orf.at/news/stories/2521707/ Na scheint ja so, als hätte der ORF das mittlerweile auch korrigiert. In der Bildunterschrift ist mittlerweile die Standardfloskel eingebaut. Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Neue Idee für's lanes-mapping
On 02.02.2012 23:35, Martin Vonwald wrote: Hi! Aufbauend auf Walter Schlögl's Idee und nach ein wenig Brainstorming mit zverik haben wir derzeit folgende Idee für's spurgenaue Mapping: statt neuer Tags kann an bestehende Tags am Ende des Keys ein :lanes ergänzt werden. Die Werte pro Spur können dann mit , getrennt angegeben werden. Für die unterschiedlichen Richtung wird wie üblich :forward bzw. :backward abschließend ergänzt. Einfaches Beispiel mit Geschwindigkeitsbegrenzungen: lanes:forward=3 maxspeed:lanes:forward=80,80,50 Abgesehen davon dass ich das bisherige Proposal zu lanes deutlich besser finde, empfinde ich es einen Graus mehrere Values für einen Key zu benutzen. Das schafft nur Probleme in der Datenauswertung, aber auch bei der Eingabe un den Editoren. Ein Wert pro Schlüssel ist deutlich besser... ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[OSM-talk] Heute Abend OSM Stammtisch Wien
Nur mal so als kurze Erinnering. ab 17:00 Uhr im Wieden Bräu... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Geofabrik OSM-extract downloads langsam seit gut einer Woche
On 05.01.2012 11:33, Frederik Ramm wrote: Hi, Ich hab jetzt mal (reboot tut gut) den Rechner neu gestartet und ausserdem eine Anfrage an den Provider geschickt. Vielleicht war denen ja der Traffic zu viel ;) Es sieht aus, als ob die Stoerung tatsaechlich mutwillig vom alten Provider verursacht wurde. Ich bin jetzt mit dem Downloadserver zu Hetzner umgezogen und habe den DNS schon umgestellt. Die OSM-Auszuege sollten alle schon da sein, die Shapes brauchen noch einen Moment. Wenn jemandem was seltsames auffaellt, bitte sagen. Na dann hoffe ich mal das 10TB im Monat für Downloads vom Server ausreichen, weil ab dann wird AFAIK ja ziemlich krass der Speed runtergefahren bei Hetzner... (und pro TB zahlen wird ziemlich teuer) Außer sie haben ein Spezialangebot fürs hosten von OSM Extracts gemacht ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Request for Romano-British features
On 03.01.2012 11:36, Lester Caine wrote: Pieren wrote: If someone does this in my area, I'll revert the deletion as vandalism. Funny. I also consider adding non-existing stuff as vandalism. I hope we will never contribute on the same areas... This is the current reason *I* have been unable to contribute to OSM in the last few years. All of the material I am gathering relates to historic mapping and I want somewhere that I can share it with other like minded users. Perhaps now is the time simply to fork a version that is only intended for historic mapping. There does not seem to be any agreement on a cross database API as an alternative to destroying data as it is superseded by changes on the ground. But one of the rules that does apply is that data that has been generated by others SHOULD NOT simply be destroyed unless it is inappropriate. The thing is - historic data that doesn't exist anymore is inappropriate because it is confusing for anyone contributing to OSM. For the same reason we don't want to have anything that is in the air. E.g. if people would trace flight-routes into OSM, they would add lots of confusion, as they are not on the ground. Flight routes or historic AND not existing on ground anymore objects is simply confusing. Adding tags to a current street/way that states that it was once a Roman street on the other hand is of course okay (as long as it was important and is currently in a broader sense touristically important), because it is still on the ground. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] Geofabrik OSM-extract downloads langsam seit gut einer Woche
Weiß jemand warum die so langsam geworden sind? Gibt es irgendwelche Consumer Apps die evtl sich dort bedienen? Derzeit schwankt der Speed zwischen 50-200KB. Oder funktioniert das spiegeln der beliebtesten Länder auf gdwg derzeit nicht und ist der Speed daher so eingebrochen (da bin ich mir ziemlich sicher dass es nicht funktioniert)? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik OSM-extract downloads langsam seit gut einer Woche
Vielen Dank für die Rückmeldung... Hoffe mal, dass wenn Deutschland und Europa Spiegeln wieder funktioniert (Frankreich wäre, da inzwischen größer wie Deutschland - und doch recht beliebt evtl auch gut zu spiegeln) der Speed hoffentlich wieder brauchbar ist (und nicht 10 Stunden warten bis Frankreich mit Glück gedownloaded) die Downlaods wieder in akzeptabler Geschwindigkeit verfügbar sind. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Vandalismus bei Herr_P
Da die Diskussion ob Mtbiken erlaubt ist oder nichts, eh Off Topic ist - und zu nichts führt - fragt sich nun eher - was machen mit Herr_P. Nachdem er in PM zumindest zu mir gesagt hat, er würde die Änderungen wieder aufräumen, wenn es ihm ein Admin (damit meint er Frederik Ramm) sagt, sollte dies passieren. Denn es ist eben wie gesagt komplett egal ob legal oder illegal oder graubereich. Hier sind nützliche Informationen von vielen Wegen gelöscht worden, und Herr_P sollte dies wieder richtig stellen, oder gesperrt werden. Nur wird es viel Arbeit sein seinen Vandalismus wieder zu korrigieren. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
On 30.12.2011 13:27, Michael Maier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 30/12/11 13:18, Felix Hartmann wrote: Da die Diskussion ob Mtbiken erlaubt ist oder nichts, eh Off Topic ist - und zu nichts führt - fragt sich nun eher - was machen mit Herr_P. Nachdem er in PM zumindest zu mir gesagt hat, er würde die Änderungen wieder aufräumen, wenn es ihm ein Admin (damit meint er Frederik Ramm) sagt, sollte dies passieren. Hm - was is denn die Definition von Admin? Oder: Wer hat das sagen, welche Daten rein gehören und welche nicht? - - Die Community. Reverten kann jeder, wie Frederik schon geschrieben hat... Denn es ist eben wie gesagt komplett egal ob legal oder illegal oder graubereich. Hier sind nützliche Informationen von vielen Wegen gelöscht worden, und Herr_P sollte dies wieder richtig stellen, oder gesperrt werden. Nur wird es viel Arbeit sein seinen Vandalismus wieder zu korrigieren. Ich würd vorschlagen, dass du, wenn keine weiteren Einwände kommen, einfach die betroffenen Changesets in ein paar Tagen selbst revertest. Hatte dasselbe Spiel vor ein Wochen in Graz, da hab ich mich auch hingesetzt und einige Dutzend changesets reverted. lg, Michi Da bräuchte ich fast einen ganzen Tag dafür - die Sache ist die, dass Herr_P in PM schrieb, dass er sich an Frederiks Entscheidungen hält - es wäre doch vielen geholfen, wenn er selber die Sachen wieder aufräumt. Reverten ist ziemlich schwer - da das clean nicht mehr durchgeht. Ich würde halt die ganze Rax/Schneebergregion auf Stand 1. Oktober zurückstellen - das wäre das für mich einfachst durchführbare - Nur würde da halt auch andere Edits drunter leiden. Das Problem ist halt - dass Herr_P viele Wege auch einfach gelöscht hat und neuangelegt. ist leider ein totales Schlamassel. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
On 30.12.2011 14:29, Frederik Ramm wrote: Hallo, On 12/30/11 13:18, Felix Hartmann wrote: Nachdem er in PM zumindest zu mir gesagt hat, er würde die Änderungen wieder aufräumen, wenn es ihm ein Admin (damit meint er Frederik Ramm) sagt, sollte dies passieren. Ich bin ja gar kein Admin, bloss ein Mitglied der Data Working Group. Das einzige Sonderrecht, das ich bei OSM habe, ist, dass ich einen Benutzer bis zu 96 Stunden sperren und ihm wichtig klingende Verwarnungen aussprechen kann ;) Jip schon klar, aber Herr_P hat dies halt so angenommen. Auf der Mailingliste zu posten scheint er sich nicht zu trauen Denn es ist eben wie gesagt komplett egal ob legal oder illegal oder graubereich. Hier sind nützliche Informationen von vielen Wegen gelöscht worden, Ist das denn jetzt Konsens unter den Lesern hier, dass mtb-Tags an den betr. Klettersteigen richtig und erwuenscht sind? Ich habe den Eindruck, dass Felix und Boris laut ja sagen, waehrend alle anderen eher so mmmhh sagen ;) Ich hab noch nirgendswo gelesen in der Diskussion hier, dass die mtb-Tags unerwünscht sind. Es gab nur viele O.T. Posts bezüglich des legalen Graubereiches. Statt einem grossflaechigen Revert auf einen frueheren Stand koennte ich mir vorstellen, dass ich anhand einer Bounding-Box und eines Stichdatums die vorhandenen mtb:scale-Tags (und ggf. andere) extrahiere und vergleiche, inwiefern diese inzwischen abhanden gekommen sind. Das Ergebnis koennte ich dann Herrn_P zukommen lassen und der koennte die Sachen wieder in Ordnung bringen. Das Problem ist - er hat ja scheinbar nicht nur in der Rax-Schneeberggegend aufgeräumt. Eventuell koennte Herr_P ja an Strecken, bei denen er denkt, dass das Mountainbiken dort nicht zulaessig ist (und das sind ja wohl, wenn ich der Diskussion hier folge, die allermeisten) einfach zusaetzlich zu der mtb:scale ein mtb=no dranschreiben. Dann haette er seiner Meinung (und vermutlich auch der geltenden Rechtslage) Ausdruck verliehen, und die Mountainbiker koennten das einfach ignorieren, so wie sie es jetzt halt auch schon tun. Der mtb:scale-Tag waere ein reiner Wegbeschaffenheits-Tag, und die ganze ist das erlaubt oder nicht-Diskussion koennte sich am mtb=yes/mtb=no/mtb=permissive etc. austoben. Waere das ein Kompromiss, mit dem alle arbeiten koennten? Naja, dass sollte man zumindest im Wiki beschreiben was damit gemeint ist. Ein no wäre aber gemäss der bisherigen Regeln falsch. Da es sich im Prinzip auf explizite/klare Verbote handelt. Auf Straßen wo man wegen begleitendem Fahrradweg mit dem Fahrrad meist nicht fahren darf (gibt ja Ausnahmen, wie Unbefahrbarkeit des Fahrradweges, Anhänger, usw..) kommt ja auch kein bicycle=no drauf. Und es ist auch nicht gesetzlich festgelegt was ein MTB ist. Daher müsste schon eher ein bicycle=no an die Wege. Aber mir ist das ziemlich egal - und den meisten anderen wohl auch - wenn es auch nicht richtig ist. Der mtb:scale Tag ist und war schon immer ein reiner Wegbeschaffenheits-Tag - nirgends im Wiki stand was bezüglich legaler Situation der Befahrbarkeit. Ich hab das im englischen mtb:scale Artikel auch nochmal deutlicher klargestellt. Dabei gehe ich jetzt davon aus, dass die uebrigen Edits von Herrn_P im Grunde genommen nicht falsch sind. Wenn es natuerlich so waere, dass alles, wass Herr_P je geaendert hat, eher schadet als nuetzt, dann koennte man das auch komplett revertieren, aber ich denke mal, derlei Aussagen sind eher im Affekt getroffen worden, oder? Bye Frederik ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
Er hat mir jetzt geantwortet, dass er die MTB Informationen an Wanderwegen nicht will. Wenn er seine Edits also nicht bald rückgängig macht, ist er IMHO ein User den man sperren muss, da er sich eindeutig nur für seien eigene Meinung, aber nicht im geringsten für Standard OSM Konventionen und Wiki Beschlüsse hält.. (also a) lösche keine Informationen, außer sie sind falsch, b) tagge so wie es laut Wiki und Proposals als korrekt beschrieben ist). On 27.12.2011 14:46, Boris Cornet wrote: Servus! Ich hab's mir angesehen, offenbar ist er ein Feind der Mountainbiker, jedenfalls hat er konsequent alle mtb: tags gelöscht. Hast du den user schon angeschrieben, hat er geantwortet? Wenn er nicht antwortet, kann man ihm eine Sperre verpassen, bis er antwortet, die kannst du bei Frederik Rammfrede...@remote.org beantragen. Es gibt die Möglichkeit, Changesets zu reverten (dann sollten die betroffenen Wege aber möglichst unberührt sein. Leider ist das aber nicht einfach, soweit ich weiß kann auch das nur Frederik Ramm. Heute (27. Dezember) um 14:11 tippte Felix Hartmann: Ist außer mir noch jemand Herr_P extremst negativ aufgefallen, durch reines löschen von Informationen - insbesondere Tags? http://www.openstreetmap.org/user/Herr_P Handelt es sich hier um einen durchgedrehten Wiener Forstswegsbehördenmitarbeiter, oder wieso kommt jemand dazu so einen Schrott zu veranstalten? Hier ein paar Beispiele wo Herr_P einfach Tags gelöscht hat... http://www.openstreetmap.org/browse/way/38771822 http://www.openstreetmap.org/browse/way/84586365 Wie kann man denn einfach alle Changes eines Nutzers rückgängig machen? Hab keine Lust stundenlang wieder Wege neu zu taggen, nachdem Herr_P gewütet hat. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
Mountainbiken ist hier rechtlich in einer Grauzone. (es ist nicht definiert ob ein MTB ein Sportgerät oder ein Fahrzeug ist - je nachdem ist es rechtlich natürlich erlaubt oder nicht). mtb:scale stellt jedoch eindeutig nur die Eingung, nicht aber die rechtliche Situation dar. Evtl sollte ich dies nochmal auf mtb:scale im Wiki reinschreiben, weil wir dies eindeutig beim Proposal so festgelegt haben. Die rechtliche Situation eines Weges hat ja nun einmal nichts mit der Eignung zu tun, und beides kann sich unabhängig voneinander ändern. Im deutschen mtb:scale Wiki Artikel ist dies besser beschrieben für MTB Strecken sowie Wege die zum mtbiken geeignet sind. Ausserdem ist die Info mtb:scale=5 oder mtb:scale=6 als Zeichen für Unfahrbarkeit auch bei Verbot sinnvoll -- Auf der Rax wo Herr_P diese Infos gelöscht hat - waren Ende des Sommers etwa 2/3 Wanderer zu 1/3 Mountainbiker unterwegs. Es handelt sich um einen MTB Hotspot. Hier schein wohl Herr_P einen Hass zu haben, oder der Forstbehörde anzugehören, die auf der Rax derzeit Jagd auf Mtbiker macht (allerdings über den Umweg von Besitzstörungsanzeigen - da es eben kein klares Verbot gibt, sprich hier wird man noch sehen was die Gerichte dazu antworten - schließlich ist mtbiken auf Wanderwegen ein starker touristischer Faktor - wenn hier ein klares Verbot kommt - dann werden die Tourismusgebiete das Jammern anfangen, weil alle nach Schweiz/Italien zum mtbiken fahren werden, anderseits das explizite Ausschreiben von MTB Routen sehr kompliziert und kostenintensiv ist). Dazu hat Herr_P etwa auch incline gelöscht. Hier wird umso fraglicher wieso er dies löscht. Das kann scheinbar nur einem Hass auf Mtbiker entspringen, denn ob ein Weg bergauf oder bergab verläuft, ist derzeit halt primär für mtbiker und autorouting interessant - steht aber nicht im direkten Zusammenhang. mtb=no ist solange mtb nicht gesetzlich als eigenständig zu bewertendes Vehikel gezählt wird auch inkorrekt. Man kann aber durchaus ein zusätzliches Tag erfinden, für implizite Verbote. Denn bicycle=no steht im Prinzip fur für Wege - wo Explizit Fahrradfahren verboten Schilder stehen. On 28.12.2011 11:29, Frederik Ramm wrote: Hi, On 12/28/11 09:55, Felix Hartmann wrote: Er hat mir jetzt geantwortet, dass er die MTB Informationen an Wanderwegen nicht will. Wenn er seine Edits also nicht bald rückgängig macht, ist er IMHO ein User den man sperren muss, da er sich eindeutig nur für seien eigene Meinung, aber nicht im geringsten für Standard OSM Konventionen und Wiki Beschlüsse hält.. (also a) lösche keine Informationen, außer sie sind falsch, b) tagge so wie es laut Wiki und Proposals als korrekt beschrieben ist). Mir hat er auch geantwortet, allerdings schrieb er mir, dass das Mountainbiken an den Stellen, an denen er die Tags entfernt hat, *verboten* sei, da es sich um ausschliessliche Klettersteige handele. Koenntet ihr (=ihr in Oesterreich bzw. ihr mit Sachkenntnis der Rechtslage) das vielleicht mal inhaltlich klaeren. Wenn auf den Klettersteigen das Mountainbiken tatsaechlich verboten ist, und wenn die Mountainbiker gerne dennoch die Info drin haetten (nach dem Motto hier darf man nicht fahren, aber wenn man hier fahren wuerde, waere der Schwierigkeitsgrad X), dann muesste man vielleicht einen Kompromiss mit Herr_P finden und das ganze irgendwie mit mtb=no taggen oder so. - Ich denke mal, dass nicht jedem Mountainbiker die Rechtslage egal ist, d.h. die Leute werden es auch schaetzen, wenn eine Karte ihnen einen zulaessigen Weg anders darstellt als einen nichtzulaessigen. Sollte sich Herr_P irren und das Mountainbiken auf diesen Wegen jedoch tatsaechlich zulaessig sein, dann sollte man dies inhaltlich mit ihm klarstellen, anstatt einfach seine Edits rueckgaengig zu machen. Bye Frederik ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
Auf der Rax waren schon 2-3 (unter etwa 30 Wegen wo er Infos gelöscht hat) Klettersteige dabei, aber eben genau jene, wo man sein MTB noch tragen kann - wenn man sicher unterwegs ist beim klettern. Aber gerade diese Info ist nun weg- sprich, jetzt rennt man als Mtbiker evtl in Klettersteige rein - weil man denkt es geht eh - und mehr oder weniger Dank Herrn_P wird halt die Bergrettung losziehen müssen - um Leute zu retten die nur deswegen in der Bredouille sitzen, weil wichtige Karteninfos fehlen On 28.12.2011 12:36, Boris Cornet wrote: Guten Tag! Heute (28. Dezember) um 11:43 tippte Felix Hartmann: Auf der Rax wo Herr_P diese Infos gelöscht hat... Er hat sich auch in Tirol umgetrieben. Und es war kein einziger Klettersteig dabei! Eine via ferrata mit mtb:* zu taggen, wäre ja wirklich nicht sinnvoll, aber die Definition des Klettersteigs von Herr_P scheint mit der der restlichen Welt komplett inkompatibel zu sein ;-) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
On 28.12.2011 12:22, Frederik Ramm wrote: Hallo, On 12/28/11 11:43, Felix Hartmann wrote: mtb:scale stellt jedoch eindeutig nur die Eingung, nicht aber die rechtliche Situation dar. Evtl sollte ich dies nochmal auf mtb:scale im Wiki reinschreiben, weil wir dies eindeutig beim Proposal so festgelegt haben. Die rechtliche Situation eines Weges hat ja nun einmal nichts mit der Eignung zu tun, und beides kann sich unabhängig voneinander ändern. Im deutschen mtb:scale Wiki Artikel ist dies besser beschrieben für MTB Strecken sowie Wege die zum mtbiken geeignet sind. Ich kenne mich mit den einschlaegigen Kartendarstellungen nicht aus; Deine Karte ist doch die am meisten von Mountainbikern verwendete. Besteht denn die Gefahr, dass ein unbedarfter User Deiner Karte bei Vorhandensein von, sagen wir, mtb:scale=5 irrtuemlich den Eindruck bekommt, hier sei eine Strecke, auf der das Fahren erlaubt sei? Nein. Da ich ja explizit dazuschreibe dass meine Karte die rechtliche Situation eher nur periphär tangiert - sprich nur bei Gefahr bzw expliziten Verboten darstellen möchte. Mir scheint, dass wir hier eine Situation haben, wo die Nutzung eines Mountainbikes zumindest von der oertlichen Behoerde nicht geduldet wird (schreibst Du selbst). Ob die Behoerde dazu den Umweg ueber Besitzstoerungsanzeigen geht, waere mir als Mountainbiker ziemlich egal. Wenn ich als Mountainbiker auf einer Mountainbike-Karte einen Weg speziell markiert vorfinde, dann gehe ich eigentlich davon aus, dass ich *nicht* von Mitarbeitern des Forstamts angezeigt werde, wenn ich diesen Weg benutze. Davon gehe ich aus, wenn eine MTB Route dargestellt wird. Daher sollten Routen eben auch nur dort eingetragen werden, wo diese auch ausgeschildert sind. Und selbst dann kann es je nach Jahreszeit oder Tageszeit rechtlich im Graubereich sein - hier zu mtbiken (allerdings sollte man nach Dunkelheit des Wilds wegen auch generell - speziell im Winter - es vermeiden auf abseits gelegenen Wegen zu Fuß zu gehen. Fußgänger stören das Wild sogar mehr - da diese langsamer unterwegs sind. Das ist aber ein anderes Thema). Mal unabhaengig davon, ob Herr_P einen Hass hat, denn das spielt hier keine Rolle: Koennte ich auch als begeisterter Mountainbiker eventuell hier zwischen die politischen Fronten geraten - auf der einen Seite die Karte, die mir suggeriert, das Fahren sei hier ok, auf der anderen Seite die freundlichen Mitarbeiter des Forstamts und die Wanderer, die mir hinterherrufen, weil sie die Grauzone anders beurteilen als ich? Ist das denn eine wuenschenswerte Situation - stelle ich mir als Mountainbiker so meinen Urlaub vor? (Koennte eventuell sogar ein angepisster Mountainbiker nach einer Fahrt auf der Rax und anschliessender Verwarnung durch das Forstamt den Wunsch hegen, diese Tags zu entfernen, weil sie ihn verleitet haben, dort zu fahren?) Nein, die Situation so hat erst im Dezember angefangen. Und bisher scheint auch noch keine Anzeige erfolgt gehabt zu haben. Dafür dürfte sich die Behörde gerade ordentlich ins Abseits manövrieren, weil sie fälschlicherweise einige Wanderer anzeigen, die gar nicht mtbiken. Sprich die Gemeinde wird ihnen wohl bald einen Denkzettel erteilen. Was ich sagen will: Wir sollten versuchen, die Realitaet abzubilden. Wenn es ein Tag gibt, mit dem rein die Beschaffenheit des Weges unabhaengig von jeder rechtlichen Lage beschrieben wird, dann darf man das natuerlich ueberall setzen, egal, wie die Rechtslage ist. Aber Vorsicht - dieses Tag kann dann auch an eine Autobahn gesetzt werden oder an andere explizit fuer Mountainbiker verbotene Wege, und es zu loeschen damit der Weg auf der Karte nicht markiert wird waere dann Vandalismus. Eine MTB-Karte muesste zusaetzlich zu diesem Wegbeschaffenheits-Tag einen anderen Tag fuer die rechtliche Situation auswerten, und so, wie es mir scheint, braucht es hier mehr als yes und no ;) Das ist ein bisschen eine bloede Situation, denn was auf der MTB-Karte wie erscheint, ist natuerlich Deine (Felix's) eigene Entscheidung, und fuer den Rest von uns gilt, dass wir nicht fuer den Renderer taggen. Ja - aber hier gehts nicht nur ums mtbiken, sondern auch etwa um Fahrradfahren in highway=living_street, Fahren auf der Straße bei vorhandenen schlecht ausgebauten Radwegen, zu Fuß gehen abseits der öffentlichen Wege, Skitourengehen, usw. So ein Tag würde schon Sinn machen, aber in AT muss man dazu sagen, dass wohl 90% der Mtbiker - sprich ein doch großer Teil der Bevölkerung - gegen implizite Verbote verstößt. Daher braucht es auch nicht in die Karte. Jedem sollte klar sein - dass Wege die nicht mtb Routen sind, und nicht Teil eines kommerziellen Bikeparks und mtb:scale=1 oder schwerer sind, nicht wirklich legal benutzbar sind. Für die meisten deutschen Bundesländer gilt dasselbe. Dennoch waere allen gedient, wenn dem Nutzer der Karte *nicht* suggeriert wird, man koennte hier problemlos fahren, denn das kann man ja offenbar nicht
Re: [Talk-at] Vandalismus bei Herr_P
On 28.12.2011 17:32, Friedrich Volkmann wrote: On 28.12.2011 16:59, Felix Hartmann wrote: Auf der Rax waren schon 2-3 (unter etwa 30 Wegen wo er Infos gelöscht hat) Klettersteige dabei, aber eben genau jene, wo man sein MTB noch tragen kann - wenn man sicher unterwegs ist beim klettern. Sicher unterwegs ist relativ. Es gibt Leute, die tragen das Fahrrad den Haidsteig rauf. Andere trauen sich auf den Haidsteig sogar ohne Fahrrad nicht rauf, sind auf einfacheren Klettersteigen aber sicher unterwegs. Sobald man das Fahrrad tragen muss, ist das definitiv keine MTB-Strecke mehr. Also da passt von den ganzen mtb Tags bestenfalls noch mtb:scale=6. Am Haidsteig könnte man mtb:scale=6 eintragen. Allerdings auf jeden fall auch ein via_ferrata:scale oder wie auch immer der Tag hieß - und jeder verantwortungsvolle Kartenautor - sollte dem Vorrang geben. Hier waren eh keine mtb:scale Infos drauf. Aber gerade diese Info ist nun weg- sprich, jetzt rennt man als Mtbiker evtl in Klettersteige rein - weil man denkt es geht eh - und mehr oder weniger Dank Herrn_P wird halt die Bergrettung losziehen müssen - um Leute zu retten die nur deswegen in der Bredouille sitzen, weil wichtige Karteninfos fehlen Die sind dann aber selber schuld, wenn sie den Einsatz zahlen müssen. Denn eine Grundregel im alpinen Gelände ist, dass man nur so weit gehen soll, wie man auch sicher wieder umkehren kann. Und dass die Karten stimmen, darauf darf man sich sowieso nicht verlassen. Ein Hangrutsch und der Steig ist weg. Das sollte eh jedem klar sein. Es geht hier aber eh viel weniger um Klettersteige - sondern mehr um gewöhnliche Steige wie etwa Holzknechtsteig, Brandschneide, Törlweg, Peter-Jokel-Steig, Gsollhirnweg, usw. Klettersteige die mit MTB technisch für sehr versierten Mtbiker Sinn machen - sind nur auf der Nordseite ein paar. Etwa Bismarcksteig. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
On 27.12.2011 14:46, Boris Cornet wrote: Servus! Ich hab's mir angesehen, offenbar ist er ein Feind der Mountainbiker, jedenfalls hat er konsequent alle mtb: tags gelöscht. Nicht nur die, er hat auch gleich incline und foot und bicycle gelöscht... Dazu sac_scale nach seinem Belieben verändert und nicht unbedingt verbessert dabei. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Vandalismus bei Herr_P
Ist außer mir noch jemand Herr_P extremst negativ aufgefallen, durch reines löschen von Informationen - insbesondere Tags? http://www.openstreetmap.org/user/Herr_P Handelt es sich hier um einen durchgedrehten Wiener Forstswegsbehördenmitarbeiter, oder wieso kommt jemand dazu so einen Schrott zu veranstalten? Hier ein paar Beispiele wo Herr_P einfach Tags gelöscht hat... http://www.openstreetmap.org/browse/way/38771822 http://www.openstreetmap.org/browse/way/84586365 Wie kann man denn einfach alle Changes eines Nutzers rückgängig machen? Hab keine Lust stundenlang wieder Wege neu zu taggen, nachdem Herr_P gewütet hat. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Vandalismus bei Herr_P
On 27.12.2011 15:37, Frederik Ramm wrote: Hallo, On 12/27/11 14:46, Boris Cornet wrote: Hast du den user schon angeschrieben, hat er geantwortet? Wenn er nicht antwortet, kann man ihm eine Sperre verpassen, bis er antwortet, die kannst du bei Frederik Rammfrede...@remote.org beantragen. Oder auf englisch an d...@osmfoundation.org, da kann es zumindest theoretisch noch jemand anders bearbeiten ;) Man sollte den Nutzer auf jeden Fall erstmal anschreiben. Wenn er dann nicht (oder patzig) reagiert, kann man weitere Schritte ueberlegen. Man sollte auch davon ausgehen, dass er vielleicht in Urlaub sein oder seine Mail nicht regelmaessig lesen koennte, also nicht ueberstuerzt handeln. (Ausser, man schreibt einem, und der ignoriert das und editiert munter weiter. Der ist ja dann wohl nicht im Urlaub.) Auch wenn es in diesem Fall nicht so aussieht, manchmal ist es ja auch einfach ein Versehen. Manchmal liest einer irgendeine Wiki-Seite, da ist ein bestimmtes Tag nicht drauf, und schon denkt er, er tut was gutes, wenn er die alle loescht. Oder er hat einen veralteten Editor, der zeigt ihm das Tag als unbekannt an, und schwupps... kommt alles vor. Angeschrieben habe ich ihn schon. Da er aber an verschiedenen Tagen immer mal wieder mtb Infos gelöscht hat, gehe ich eindeutig von Vandalismus aus. Es gibt die Möglichkeit, Changesets zu reverten (dann sollten die betroffenen Wege aber möglichst unberührt sein. Leider ist das aber nicht einfach, soweit ich weiß kann auch das nur Frederik Ramm. Einen normalen Revert kann man mittlerweile sogar mit JOSM-Plugins machen, dazu braucht es keine Sonderrechte. Ich verwende beim Revertieren auch nur das normale API. Trotzdem kann dabei auch einiges falsch laufen (zum Beispiel: User aendert das gleiche Objekt zweimal, ich revertiere erst die spaetere Aenderung, nun sieht es durch diesen Revert so aus, als sei das Objekt in der Zwischenzeit bearbeitet worden, und ein weiteres Revert geht nicht... und sowas). Im Zweifel also lieber einen Fachmann oder eine Fachfrau fragen ;) Naja, teils hat er die Wege gelöscht, und neu angelegt, teils nur tags gelöscht. Mit dem normalen JOSM Plugin schaffe ich es nicht Changeset 9679430 zu reverten - da Conflicts auftreten die ich nicht bereinigen kann. Vielleicht ist ja jemand anders in der Lage dieses Changeset zu reverten - hier hat er echt übel rumgelöscht und auch andere Sachen verschlimmbessert. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] ODBL Status Garmin Karten
Hallo Simon, der Alternative Style verstößt eindeutig gegen meine Lizenzbestimmungen. Bitte Les die dir nochmal durch. Du kannst ihn gerne benutzen, aber das verlinken und nennen meines Styles möchte ich bitte beachtet haben... On 15.12.2011 14:29, Simon Poole wrote: Wie isch schon angekündigt habe, habe ich einen Satz von Garmin Karten online gestellt die auf Frederiks Daten für seinen OSMI viewer beruhen. Ich habe jetzt noch weitere Regionen hinzugefügt und auch noch einen zweiten Kartenstil gemacht. Mindestens die europäischen Karten werde ich versuchen täglich zu erneuern. Die Karten können von http://odbl.poole.ch/garmin/ bezogen werden. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ODBL Status Garmin Karten
ups sorry grad gecheckt dass es nur ein Overlay über einer meinen Karten ist Wäre trotzdem nett wenn du bei Screenshots meiner Karten auch dazuschreibt, dass sie von mir sind (ist sonst zumindest ein Verstoß gegen meine Lizenzbedingungen, wobei ich jetzt bezüglich FairUse nicht weiß ob es wriklich eine Verletzung der CCBYSA2.0 ist...) Dachte zuerst es handelt sich um eine komplette Karte und nicht nur ein Overlay... On 15.12.2011 17:07, Felix Hartmann wrote: Hallo Simon, der Alternative Style verstößt eindeutig gegen meine Lizenzbestimmungen. Bitte Les die dir nochmal durch. Du kannst ihn gerne benutzen, aber das verlinken und nennen meines Styles möchte ich bitte beachtet haben... On 15.12.2011 14:29, Simon Poole wrote: Wie isch schon angekündigt habe, habe ich einen Satz von Garmin Karten online gestellt die auf Frederiks Daten für seinen OSMI viewer beruhen. Ich habe jetzt noch weitere Regionen hinzugefügt und auch noch einen zweiten Kartenstil gemacht. Mindestens die europäischen Karten werde ich versuchen täglich zu erneuern. Die Karten können von http://odbl.poole.ch/garmin/ bezogen werden. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] GPS Tracks vereinfacht hochladen?
Wenn dein GPS Device intelligent loggen kann, dann mach es. Ein Punkt pro Sekunde ist meist vom Ergebnis deutlich schlechter wie ein intelligentes vermeiden zu vielen Punkte - vor allem da dein Device dann da die internen Qualitätsdaten noch vorhanden sind, Outlier rausschmeißen kann. Ausserdem braucht es auf einer Geraden nicht einen Punkt pro Sekunde, in Kurven wären evtl aber sogar 2 Punkte pro Sekunde besser (gibt aber nur sehr wenige PNA/PDA die ein kleineres Intervall als 1s aufnehmen können). Genauso macht natürlich auch 1 Punkt / Meter keinen Sinn. Gerade wer ein Garmin hat (weil weit verbreitet) errreicht mit Aufzeichnungsintervall automatisch / Datendichte am höchsten deutlich bessere Ergebnisse wie bei 1point/sec oder 1point/m. Dazu macht es auch Sinn am Anfang die ersten Punkte zu löschen - da es dauert bis der GPS Fix halbwegs stabil wird (Almanachdaten) , und natürlich auch vor dem hochladen den Track anschauen um evtl große Fehlerstellen (etwa Punktwolken oder großes Zickzack, oder noch schlimmer - eine Gerade zum Punkt des letzten ausschalten über lange Distanz) zu entfernen. On 13.12.2011 18:07, Manuel Reimer wrote: Hallo, ich logge generell einen Punkt pro Sekunde. Bisher lade ich das Resultat auch so bei OSM hoch. Gerade habe ich gesehen, dass gpsbabel auch Tracks vereinfachen kann. Sollte man Tracks vor dem Hochladen so bearbeiten oder werden unveränderte Tracks lieber gesehen? Ist es sogar sinnvoll die Tracks zu vereinfachen, um Speicherplatz zu sparen? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Lagegenauigkeit an Berghängen/Felswänden
On 17.10.2011 22:18, Friedrich Volkmann wrote: On 10/17/11 20:57, Robert Kaiser wrote: Auf unter 10m würde ich einem GPS nicht trauen, in Städten bzw. wenn der Horizont durch irgendwelche Hindernisse nicht direkt sichtbar ist, würde ich die Fehler höher einschätzen. Im Normalfall. Ich hab aber auch schon erlebt, dass mein Garmin in Wien am Südtirolerplatz 3m Genauigkeit angezeigt hat. Und am Track war zu sehen, dass er wirklich so genau war. Dadurch wurde mir klar, wie falsch die Yahoo-Bilder waren. Bis dahin hatten viele von Yahoo abgezeichnet, ich auch. Ich hatte sogar fremde Objekte korrigiert, d.h. nach Yahoo ausgerichtet. Jetzt haben wir das gleiche mit Geoimage. Alle zeichnen unkritisch von geoimage.at ab und nehmen es als Grundlage für hemmungslose Lagekorrekturen. Doch vielleicht sind da und dort die guten alten GPS-Tracks doch genauer, und die vermeintlichen Lagekorrekturen sind in Wahrheit Lageverfälschungen. Achtung, die 3m Genauigkeit bedeuten dass OHNE Reflexionen, in 95% aller Fälle die Genauigkeit 3m oder besser ist. Je nach GPS Firmware wird die prozentuale Häufung anders genommen. Früher war 99% die Norm, bei Professionellen GPS sind es eher 99.5% oder besser, aber da Konsumenten eben meinen Boah ist ja 3m genau wird dann halt nur noch eine Wahrscheinlichkeit von 95% als ausreichend betrachtet. Tendenziell ist bei Garmin GPS Genauigkeiten unter 5m (laut Anzeige) aber ziemlich zu trauen, aber wenn mal 10-20m angezeigt werden, dann ist es häufig in Wirklichkeit schon 50-60m, und dem Wert sollte nicht mehr vertraut werden. Dazu muss man natürlich noch die Reflexionen einbeziehen welche das Ergebniss innerstädtisch/Felswände arg verschlechtern (statt 3m kann man dann eher von 6m mit 95% Wahrscheinlichkeit rechnen). Der Grund für die bei modernen GPS eher größeren Aussetzer wie früher liegt übrigens daran, dass der gemeine User lieber schlechten Empfang hat, wie gar keinen, weswegen die Elevationswinkel bis zu denen Satelliten gelocked werden, deutlich gesenkt wurden - dies führt aber wiederrum zu größeren Positionsfehlern. Alte GPS Chipsätze wie etwa Phasetrack oder SIRF II waren deutlich genauer wie die modernen MTK oder u-blox - aber sie hatten halt viele viele Aussetzer und kompletten Fixverlust. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] How to start to remove non-CT compliant data..
On 01.09.2011 08:19, Michael Kugelmann wrote: On 31.08.2011 10:44, Nick Whitelegg wrote: I would go so far as to say, don't delete *anything* until legally you absolutely have to. I would like to somehow modyfy this statement: we should replace the data not delete it! So please remap the information that needs to be removed. Well that is deleting. Everything else would be copying. Especially on less common tags that are rather specific or subjective you will not be able to replace them. E.g. tracktype, smoothness, mtb:scale, sac_scale and so on, would definitely need local knowledge to be redone. So if you don't want to have any trouble, best delete any object WITHOUT looking at the tags, else someone who purposely mistagged will quickly find out. Also things like name:en and other languages, simply redoing every tag shouldn't be done at all. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] mkgmap und der --delete-tags-file Parameter
On 07.08.2011 22:30, Joerg Fischer wrote: Chris66 wrote: ich mach das so, dass ich die Option --link-pois-to-ways nutze und im polygon-file shop=* auf Gebäude umsetze: shop=* [0x13 resolution 24] Und das funktioniert _wenn Du vorher die Gebäude via --delete-tags-file gelöscht hast_? Das versteh ich gerade nicht... Tschaui, Jörg AFAIK ist delete-tags-file kaputt, und funktioniert nicht! Man müsste es allerdings mal überprüfen (etwa highway tag löschen, und schauen ob trotzdem highways in der Karte auftauchen) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Topo Pirineos - or lots of new material to trace/import in the Pyrenees
On 11.07.2011 13:48, M∡rtin Koppenhoefer wrote: 2011/7/9 Felix Hartmannextremecar...@gmail.com: As we're still under CCBYSA 2.0, people can use it to trace rivers and trails to OSM :-) while the data is still distributed under cc-by-ca you cannot enter data any more in cc-by-sa only. All current contributions most also be compatible with odbl and the ct. Of course you can. I.e. on fosm.org. or might we have another case of OSM data piracy (I'ld support the later, as there is no real data sources given for the rest of the data, and from my opinion clearly a pirated Garmin MPC has been used to create the map). do you have more details why you think that this is pirated data besides missing source-tags? No, as I don't have much clue at all where the data is from. I do think for Spain it's from IGN and thus okay for personal use only. For France I have no clue at all. However as I could not find (don't speak catalan, so only used google translate), a list of sources (and there seems to be quite a melange), I have no clue. Clearly OSM data is pirated as the map is not published CCBYSA 2.0! cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Topo Pirineos - or lots of new material to trace/import in the Pyrenees
http://www.topopirineos.blogspot.com/ This map is using Openstreetmap Data for main roads, but lots of other stuff too. Attribution is not really given correctly, but somehow a bit. As we're still under CCBYSA 2.0, people can use it to trace rivers and trails to OSM :-) or might we have another case of OSM data piracy (I'ld support the later, as there is no real data sources given for the rest of the data, and from my opinion clearly a pirated Garmin MPC has been used to create the map). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-at] Fahrradrouten von Alltagsradlern - Commuteing Cycle Network?
Aus genau den Gründen, ist class:bicycle einfach besser. Das kannst ja genauso als Netzwerk aufbauen, noch dazu als intelligentes Netwerk, dass sich ergibt... On 28.05.2011 21:05, Friedrich Volkmann wrote: On 05/28/11 18:10, Markus Straub wrote: ich würde gerne wissen was ihr vom Taggen von Alltagsradwegen in Form eines Netzwerks haltet. Gar nichts, weil die Vorlieben individuell verschieden sind. Der eine fährt lieber am Radweg, der andere lieber auf der Fahrbahn. Der eine lieber den schnelleren, der andere lieber den ruhigeren Weg. Wir mappen das, was existiert, und brauchen uns keine Routen ausdenken. Das ist Sache der Anwendungen (Router) und ihrer Parameter. Ausgangspunkt: Hier in Wien gibt es ein sehr zerstückeltes offizielles Radwegenetz, das nur teilweise die tatsächlich gefahrenen Routen (vor allem vom Alltagsradverkehr -- 'commuter') wiedergibt. Dieses Radwegenetz ist nur ein Propagandainstument der Stadtpolitiiker. Nach dem Motto: Wir sind so gut, denn wir fördern den Radverkehr. Wir fördern ihn, indem wir das Radwegenetz um soundsoviel verlängern. Dazu werden z.B. grüne Schilder aufgestellt und schwupps kann man die Straßenlänge schon dazurechnen. Aber immer noch besser als wirkliche Radwege, denn die sind erwiesenermaßen gefährlich (Abbieger, Fußgänger, Hunde, Dreck...). Für Alltagsradler sind Radwege nur dort von Nutzen, wo für Pkw ein Fahrverbot ist, z.B. durch den Prater. Aber sogar dort hab ich schon erlebt, dass ich einer ausgeschilderten Radroute gefolgt bin und plötzlich mitten auf einer Großbaustelle war... In anderen Städten (z.B. Linz) gibt es innerhalb der Stadt überhaupt keine beschilderten Radwege. Blaue Lollis aber schon? Würde mich sonst wundern. In der Realität existiert aber ein solches Netz und ich würde in es in Wien gerne mit Hilfe der lokalen Fahrradlobby/vereinigung einzeichnen. www.argus.or.at, die selbsternannte Radlerlobby. Mit etwas Glück sagen sie dir das gleiche wie ich. Meine Recherche zum passenden Taggingschema hat mich zu nichts existierendem geführt, ich könnte mir aber vorstellen einen neuen Typ von Cycle Routes[1] einzuführen: network=ccn (commuting cycle network) Konsequenterweise müsste man dann auch ein network=cpcn (commuting passenger car network) und ein cln (cummuting lorry network) usw. einführen. Eh gut. Dann haben Anfänger wenigstens die Chance, zuerst unwichtige Relationen hinzumachen. :-) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Bahnstrecke vs. Gleis
On 25.05.2011 12:07, Garry wrote: Am 24.05.2011 17:40, schrieb Torsten Leistikow: Garry schrieb am 24.05.2011 17:09: In die eine Richtung ist es eine Detailverbesserung, in die andere würde sicher nicht nur ich es als Vandalismus ansehen... In beiden Richtungen wird Information zerstoert, die von unterschiedlichen Auswertungen genutzt werden. Letztendlich werden die meisten Kartenansichten durch das detailliertere Mapping schlechter und nicht besser, so dass die Sichtweise des Vandalismus alles andere als eindeutig ist. Da wir nicht für den Renderer taggen können wir auch keinen Vandalismus an den Kartenansichten tätigen ;-) Du hast da katastrophal was falsch verstanden. Der Satz wir taggen nicht für die Renderer bedeutet. Wir taggen nicht so, dass Fehler vom Renderer verschleiert werden, bzw wir taggen nicht für spezielle Renderer. Wir sollten aber sehr wohl so taggen, dass man mit für den Renderer zumutbarem Aufwand eine korrekte Karte rendern kann. Daher braucht es eben Lösungen, um für Zoomstufen mit weniger Details, auch noch korrekte Daten aus OSM herausfiltern zu können. OSM ist kein Gemälde in Weltgrößesondern noch immer primär eine Datenbank (und wenn eine Datenbank nicht logisch aufgebaut ist, dann ist sie Schrott, ganz einfach) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
On 24.05.2011 10:07, Wolfgang wrote: Hallo, Am Montag 23 Mai 2011 19:16:16 schrieb Bjørn Bäuchle: Oder soll man die Trasse taggen? Dafür könnte man dann vlt landuse=railway_corridor benutzen. Fang gerne an damit, und wenn sich das durchsetzt, spricht ja nichts dagegen, dass die Renderer bei Zoomlevels 13 (oder was auch immer) eben railway_corridor benutzen statt railway=*. landuse=railway gibt es schon länger im Wiki und wird bereits benutzt und gerendert. Gruß, Wolfgang Das wird aber als Fläche und nicht als Linie eingezeichnet, und ist daher erst recht für niedrige Zoomstufen untauglich. Evtl wäre railway=railway_corridor als Mittellinie nicht schlecht. Und da gehören dann auch Relationen dran, sowie die Bedeutung der Strecke. (weil usage ja Bullshit ist, gelinde gesagt, für eine allgemeine Karten) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
On 23.05.2011 12:43, M∡rtin Koppenhoefer wrote: Am 23. Mai 2011 02:26 schrieb Felix Hartmannextremecar...@gmail.com: Ich bin mir sicher, dass es einfacher wäre, die abstrakteren Level up-to-date zu halten. Fakt ist derzeit kann man aus OSM Daten keine vernünftige Weltkarte rendern. Auf Rasterbasis mag das noch irgendwie gehen, aber als Vektorkarte ganz sicher nicht. stelle ich mir ziemlich einfach vor: einzelne Layer als Raster rechnen und danach in Vektoren umwandeln und zusammensetzen. Gruß Martin Viel Spaß mit dem Schrott der dabei entsteht. Das Problem ist dass Matching von ähnlichen Sachen halt nie 100% korrekt funktionieren kann. Dafür gibt es ja auch Relationen. Sprich man bräuchte eine Relation die alle Gleise zusammenfasst. Dann könnte man es vernünftig rendern. Ein Rasterkartenrenderer wird übrigens auch viel Zeit verschenken, nur wenn halt 5 Gleise übereinander liegen, sieht man nur eins, somit ist für den Betrachter egal. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
On 22.05.2011 22:47, Bjørn Bäuchle wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Thorsten, Am 22.05.2011 19:01, schrieb Torsten Leistikow: Ich habe ja auch nichts gegen die Detail-Erfassung, aber warum konnte dafuer nicht ein neues Tag genommen werden? Ein Gleis ist nun mal was anderes als eine komplette Bahnstrecke. Beim Detailmapping von Wohngebieten benutzt man ja auch building=* fuer die Gebauede und traegt nicht einfache viele kleine landuse=residential ein. ich bin in Frankfurt eifrig dabeigewesen, Eisenbahnen gleisgenau zu mappen. Wenn ich dich richtig verstehe, hast du da auch nichts dagegen, richtig? Aber dann mach doch einen Vorschlag, wie man sonst die Einzelgleise taggen soll, wenn railway=* für dich nicht akzeptabel ist!? Ich hielt das für sinnvoll, denn getrennte Fahrstreifen auf der Straße sind ja auch beide highway=*, dabei sind - um dein Argument zu nehmen - Fahrspuren was anderes als eine komplette Autobahn. Als ich damit angefangen habe, das zu mappen, habe ich auch nirgendwo gelesen, dass es damit ein Problem geben könnte. Also, wie ist dein Proposal? Das Ganze ist bei Autobahnen ja auch schon ein Fehler. Bei Billigrendereren die aus Vektordaten Rasterkarten (etwa png) erzeugen wie Mapnik, ist das ganze egal. Aber alle Renderer die Vektordateien benutzen um diese möglichst real-time darzustellen, ist es einfach nicht vernünftig. Egal ob jetzt Fahrspuren, separate Bürgersteige, etc. Die professionelle Variante wäre, die Mitte zu kennzeichnen, und auf die Mitte alle für Autorouting relevanten Infos einzutragen. Separate Spuren, Gleise, etc. sollten nur für die Darstellung in niedrigen Zoomstufen benutzt werden. Ein Mittelweg, wäre etwa ein Mittelgleis zu definieren, welches separat getagged wird damit es klar ist, dass dies für Routing/Rendering in hohen Zoomstufen benutzt wird. Warum sind Einzelgleise auch wirklich falsch? -- Weil etwa eine Zugverbindung nicht alle Gleise benutzt, sondern wie genereller Verkehr, nur bestimmte Gleise der Bahnstrecke (Bahnstrecke gleich die Zusammenfassung aller Einzelgleise). Sprich nur weil man Sachen einzeln mappt, wird es nicht korrekter. Karten sind Abstrakte der Wirklichkeit. Eine Karte ist kein Foto. Also ist eine einzelne Bahnspur genauso inkorrekt wie alle Gleise separat. Im Idealfall sollte man beides haben. Und usage=main hat nichts mit der Bedeutung zu tun, das wurde nur häufig falsch beschrieben (und darüber hab ich mich im Wiki auch schon ordentlich geärgert). Usage ist nur was für Eisenbahnfreaks, für alle anderen, bräuchte es ein Tag um Hauptverbindungen von Nebenverbindungen zu unterscheiden, weil dies in Ansicht der Bahnfreaks, nichts mit Haupt und Nebenstrecken zu tun hat. usage=main, kannst auch an die nicht elektrifizierte Bimmelbahn nach Hintertupfing anhängen. Man kann aber trotzdem sagen, dass die Bahnfreaks hier recht haben, weil usage sich ihrer Meinung eben auf das Gleis und nicht die Bahnstrecke bezieht. Die Bedeutung müsste man im Prinzip in der Relation angeben, und das nicht per usage, sondern mit einem neuen Tag. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstrecke vs. Gleis
-- Weil etwa eine Zugverbindung nicht alle Gleise benutzt, sondern wie genereller Verkehr, nur bestimmte Gleise der Bahnstrecke (Bahnstrecke gleich die Zusammenfassung aller Einzelgleise). Sprich nur weil man Sachen einzeln mappt, wird es nicht korrekter. Karten sind Abstrakte der Wirklichkeit. Voellig richtig, und wenn wir hier eine Karte im Illustrator malen wuerden, waere das was anderes. Aber die Abstraktion soll bitte der Renderer vornehmen und nicht der Mapper. Ich moechte naemlich irgendwann schon gern ein Draisinen-Routing haben, bei dem mir der Router genau sagt, ob ich das linke oder rechte Gleis fahren soll ;) Das Problem des Masstabs haben wir uebrigens bei Bahnhoefen auch schon; wenn ich jetzt die Kursbuchstrecke Basel-Hamburg als Relation eintrage, bin ich gezwungen, die an ein ganz bestimmtes Gleis zu haften und an einen ganz bestimmten Bahnsteig in jedem Bahnhof, obwohl das natuerlich meistens eine operative Entscheidung ist und nicht in Stein gemeisselt. Es muesste also tatsaechlich die Moeglichkeit geben, eine Trasse und einen Bahnhof auf einem abstrakteren Niveau anzusprechen als ein konkretes Gleis. Manchmal denke ich, wir sollten solche Relationen erst dann einfuehren, wenn mindestens zwei verbreitete Editoren damit auch gut umgehen koennen. Wir haben im Moment eine Situation, wo sehr viele, meist auch logisch irgendwie sinnvolle, Relationen angelegt werden, aber ich fuerchte, immer weniger Leute blicken da durch. Ich bin mir sicher, dass es einfacher wäre, die abstrakteren Level up-to-date zu halten. Fakt ist derzeit kann man aus OSM Daten keine vernünftige Weltkarte rendern. Auf Rasterbasis mag das noch irgendwie gehen, aber als Vektorkarte ganz sicher nicht. Dabei könnte man so eine Weltkarte, als Einzelperson, wohl locker innerhalb von 2-3 Wochen von Yahoo Bildern / OSM Grundlayer erstellen. Dazu noch 1-2 Zwischenlayer, und es würde die ganze Sache viel einfacher machen. Auch weil es bestimmte Konflikte über Detailgenauigkeit lösen würde (wer jeden Baum einzeln taggen möchte, der könnte das dann ohne Schaden machen, wo die absolute Genauigkeit da bleibt, ist dann halt fraglich). Und es würde viele der Relationen deutlich vereinfachen. Man könnte sogar überlegen, ob es nicht Sinn macht, die Datenbank viel stärker aufzubröseln. Damit man sich nur noch die Sachen holt die man braucht. Das ein Topf wo ich alles reinschmeiße Modell, funktioniert einfach immer schlechter. Etwa je genauer Straßen gemapped werde, in desto mehr Einzelteile werden sie zerlegt, aber fast immer ohne eine Straßenrelation zu erstellen (ist ja irgendwie auch dumm, dass es sowas braucht). Und desto mehr Einzelteile, die man maximal in 90% der Fälle korrekt logisch verbinden kann, desto schlechter wird das Routing. Und es gibt derzeit keinen Editor, der wirklich gut mit Relationen umgehen kann (sprich, der halbwegs intelligen erkennt, wenn jemand eine Relation doppelt einträgt, oder der intelligent die Relation anzeigt, so dass der User sieht dass sie schon existiert). Solange man nicht bei klicken auf Fahrradroute, alle Fahrradrouten im Editorausschnitt hervorgehen sieht (aber restliche Relationen unsichtbar bleiben), wird es auch nicht klappen. Damit unser derzeitiges immer detaillierter werdendes Mapping irgendwie funktioniert, bräuchte es viel mehr Userbasierte Presets. Sprich das komplette Kartenrendering und Editorpresetlayout verändert sich, wenn ich anklicke taggen als Wanderer oder taggen als Autofahrer. Das ist zwar umsetzbar, aber richtig viel Arbeit. Und solange die Editoren in ihren Vektordarstellungen nicht 1-2 Generationen besser werden (bezogen auf Presets für die Darstellung wie auch technische Möglichkeiten der Darstellung, wird es auch nicht Userfreundlich. OSM ist so groß geworden, dass es einfach eine Fragmentierung braucht (klar braucht das viel Input/Zeit um eine Interoperabilität der Fragmente zu gewährleisten). Wenn dies nicht passiert, wird OSM einfach an Bedeutung verlieren, weil Spezialgruppen ihre Interessen nicht mehr umsetzen können (und das ist das was OSM wirklich ausmacht, weil nur freie Kartendaten gibt es eh mehr und mehr) ohne andere Gruppen vor den Kopf zu stoßen. Highway:area=* wäre etwa ein Fall, der ganz einfach in eine separaten Datenbankteil gehört. Wenn hier nichts passiert, werden andere Userbasierte Kartendatenbanken interessanter werden und es würde sich alles zersplittern (womit aber die größte Stärke von OSM, die Verkreuzung verschiedenster sonst so nicht registrierter Daten, abhanden käme). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Open Government Data Portal of the City of Vienna, Austria launched
Naja, die Daten stehen unter CCBY 3.0. Sprich mit der neuen odbl Lizenz samt Terms nicht vereinbar. Wer sich entscheidet denen eh nicht zuzustimmen, der kann sie natürlich benutzen On 17.05.2011 13:49, Andreas Trawoeger wrote: Auf zum gemeinsamen Datenschmökern :-) cu andreas -- Forwarded message -- From: Martin Kaltenböckm.kaltenbo...@semantic-web.at Date: 2011/5/17 Subject: [euopendata] Open Government Data Portal of the City of Vienna, Austria launched To: euopendataeuopend...@lists.okfn.org Hi everyone, I am happy to announce the 1st (official) Open Government Data Portal in Austria - the City of Vienna has launched a 1st version here: http://data.wien.gv.at/ Regards - Martin -- | Martin Kaltenböck, CMC | Managing Director - Semantic Web Company (SWC) | Lerchenfelder Guertel 43, A - 1160 Vienna, Austria | Tel +43.1.402 12 35 - 25 | Fax +43.1.402 12 35 - 22 ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Schön wäre es wohl, schnell eine Lösung für das Multilane-Problem zu finden und in den Editors Relationen noch benutzerfreundlicher (Newbies) zu machen. Nebenbei könnten wir ja noch das Area-Problem lösen.;) Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und dann alle Lanes (egal ob jetzt Bordstein oder Fahrradweg) mit relativer Entfernung dazu. Bei Kreuzungen dann angeben, welche Lane zu welcher Lane der kreuzenden Straße eine Verbindungsmöglichkeit hat. Dann könnte man auch easy pro Lane die Breite angeben, bzw Zustand und hätte keine Probleme beim herauszoomen (sprich beim rauszoomen, kann ich sehr schnell ausrechnen, ab wann Linien überlagert werden, und brauche sie nicht doppelt zu zeichnen - sprich enorme Performancesteigerung etwa beim rendern von Straßen am GPS oder anderen Systemen die Vektorkarten benutzen). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
On 05.05.2011 16:54, M∡rtin Koppenhoefer wrote: Am 5. Mai 2011 16:29 schrieb Felix Hartmannextremecar...@gmail.com: Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und dann alle Lanes (egal ob jetzt Bordstein oder Fahrradweg) mit relativer Entfernung dazu. Bei Kreuzungen dann angeben, welche Lane zu welcher Lane der kreuzenden Straße eine Verbindungsmöglichkeit hat. Das reicht für vieles nicht aus, wir wollen ja nicht nur routen mit den Daten... Gruß Martin Wofür soll es denn nicht ausreichen??? Beispiele benötigt. Im Katasterplan von Wien, werden Straßen so eingezeichnet (AFAIK) seitdem er vektorisiert wurde, bzw dort wo er vektorisiert erfasst wurde. Das es vom Modell her nicht unbedingt einfach ist, ist klar, aber darum können sich Editorenpresets kümmern. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
On 05.05.2011 18:29, M∡rtin Koppenhoefer wrote: Am 5. Mai 2011 18:20 schrieb Felix Hartmannextremecar...@gmail.com: On 05.05.2011 16:54, M∡rtin Koppenhoefer wrote: Am 5. Mai 2011 16:29 schrieb Felix Hartmannextremecar...@gmail.com: Naja, die GIS Lösung wäre halt NUR die Mittelllinie zu erfassen, und dann alle Lanes (egal ob jetzt Bordstein oder Fahrradweg) mit relativer Entfernung dazu. Bei Kreuzungen dann angeben, welche Lane zu welcher Lane der kreuzenden Straße eine Verbindungsmöglichkeit hat. Das reicht für vieles nicht aus, wir wollen ja nicht nur routen mit den Daten... Wofür soll es denn nicht ausreichen??? Beispiele benötigt. Beispiele braucht man da keine: es reicht nicht, um die Form abzubilden, ist wohl klar, oder? Doch es reicht um die Form abzubilden. Es braucht nur die enstprechenden Tags dafür. Straßen, Krezungen, und Bordsteine haben es an sich vom Menschen am Reißbrett geplant zu sein, und daher mit Vektoren leicht beschreibbar zu sein. Das ganze funktioniert natürlich nicht vernünftig in der Natur, wo man wohl wirklich auf Wege als Flächen für eine sinnvolle genaue Abdeckung der Lage ausweichen müsste (macht zum Glück keiner, weil es keinen sinnvollen Nutzen hat). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
On 05.05.2011 20:00, M∡rtin Koppenhoefer wrote: Am 5. Mai 2011 19:05 schrieb Felix Hartmannextremecar...@gmail.com: Doch es reicht um die Form abzubilden. Es braucht nur die enstprechenden Tags dafür. Straßen, Krezungen, und Bordsteine haben es an sich vom Menschen am Reißbrett geplant zu sein, und daher mit Vektoren leicht beschreibbar zu sein. wenn Du aber mehrere Vektoren in einem zusammenfasst ist es klar, dass nicht alle Informationen enthalten sein können. Du brauchst nicht mehrere Vektoren in einem zusammenfassen. Es reicht aus die relative Lage zu bestimmen. Ausserdem reicht es normalerweise aus, anzugeben, Spur X verläuft mit Breite von x Metern im Abstand von Y Metern zur Mittellinie. Bei Krezungen gibt man dann genau an, welche Spur, auf welche Spur der kreuzenden Straße trift. So kann man das leidige Problem lösen, dass man mit alle Möglichkeiten separat einzeichnen hat (das funktioniert bei komplizierten Krezungen nicht, haben wir etwa schon beim Wiener OSM Treffen durchgesprochen, sprich die Spuren dort wo sie sind einzeichnen, ist NICHT ausreichend um komplexe Krezungen korrekt abzubilden). Klar braucht es dafür ein sehr spezialisiertes Taggingsystem, und Editoren die es umsetzen. Das wird locker ein paar Monate Entwicklungszeit brauchen, damit es einfacher und besser ist, wie das derzeitige Chaos. Etwa diese Krezung hier: http://www.openstreetmap.org/?lat=48.248268lon=16.388447zoom=18layers=M Ist derzeit einfach nicht auch nur halbwegs korrekt eintragbar, mit unserem derzeitigen Datenmodell (weder ist das Autorouting korrekt, noch die Anzeige). Dabei ist die noch gar nicht so komplex (und Fuß und Radwege sind gar nicht eingetragen). Wobei erschwerend natürlich noch dazu kommt, dass es sich hier um eine Krezung auf einer Brücke handelt. (und das falscheste ist, es gibt hier nicht zwei separate Brücken, sondern nur eine auf der beide Fahrtrichtungen verlaufen - aber die Brücke ist nicht als Relation eingetragen - was sie eigentlich müsse, aber fast nirgends korrekt ausgewertet wird). Dafür bräuchte es einfach ein Fahrspurensystem in OSM. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] New Logo in the Wiki
Why not setup a Wave server, using google Wave software. It's open source, and really efficient for real time as well as non real time communication. Alternative a google server could be used, but then it is just like other proprietary tools (though based on opensource software). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Cycleways - oftmals falsch getaggt
Unterscheidung, von daher ist ein in Deutschland nicht angebracht. Sie unterscheiden sich durch die An- bzw. Abwesenheit der Straße. Mit dem Argument unterscheiden sich Wanderwege mit immer wieder lockerem Sandboden und geteerte Wanderwege durch den Belag und sollten dann nicht beide mit dem gleichen highway-Wert getagged werden; der Unterschied für Radfahrer ist sicherlich größer als der zwischen Bürgersteig und Fußweg für (erwachsene) Fußgänger - überzeugt mich irgendwie nicht besonders. ich glaube, wir verstehen unterschiedliche Dinge unter Typologie. Für mich ist ein Wanderweg ein Typ (Feinunterteilungen lasse ich hier mal aussen vor, sind alles Beispiele). Eine Straße auch. Eine mehrspurige Straße mit baulich getrennten Richtungsfahrbahnen auch. Ein Gehweg/Trottoir/Bürgersteig ist für mich Teil der Straße, im Gegensatz zu einem eigenständigen Fußweg. Das meinte ich. Da bist du Architekt und ich Fußgänger ;) Ein Gehweg ist Teil des Gesamtbauwerks Straße, aber spätestens bei einer stark befahrenen Straße hab ich davon nichts gewonnen: Durch die praktische Einschränkung, dass ich die Straßenseite nicht ohne Gefahr für Leib und Leben wechseln kann, wird der Bürgersteig effektiv zu einem eigenständigen Weg. Und du verlierst durch den eigenständigen Weg, die Information, dass der Weg entlang einer stark befahrenen Straße geht, außer du legst nun für jeden Bordstein, eine Relation zur Straße. Troittors wie auch Fahrbanspuren, sind nichts eigentständiges, sondern gehören zur Straße. Um die relative Lagegenauigkeit vernünftig zu mappen, fehlt derzeit einfach noch ein Konzept. Die aber separat zu mappen, bringt nur Probleme (auch für das von dir erwähnte Fußgänger-Navi. Das wird sich denken, toll hier ist ein Trottoir, der geht lange geradeaus schön zum Ziel, aber weiß nicht, dass der Bürgersteig voll in den Abgasen hängt, und bei jeder Querstraße Ampeln sind, die die Geschwindigkeit mindern (bzw fehlen uns halt Möglichkeiten, Grüne Wellen zu taggen - im Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für Fußgänger, Radler, usw, nicht machbar, da sich die Geschwindigkeiten relativ viel stärker unterscheiden wie bei Autofahrern). Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
On 04.05.2011 14:24, Georg Feddern wrote: Moin, Felix Hartmann schrieb: Und du verlierst durch den eigenständigen Weg, die Information, dass der Weg entlang einer stark befahrenen Straße geht, außer du legst nun für jeden Bordstein, eine Relation zur Straße. nun, diese Eigenschaft ließe sich an dem getrennt gemappten Weg einfacher per Tag signaliseren (sic! sidewalk=yes) als alle anderen Eigenschaften des Trottoirs am Subtag der Straße. sidewalk:primary=yes so würde es ansatzweise gehen, aber mir fehlen noch viel mehr Infos, siehe weiter unten. Die aber separat zu mappen, bringt nur Probleme (auch für das von dir erwähnte Fußgänger-Navi. Das wird sich denken, toll hier ist ein Trottoir, der geht lange geradeaus schön zum Ziel, aber weiß nicht, dass der Bürgersteig voll in den Abgasen hängt, siehe oben und bei jeder Querstraße Ampeln sind, die die Geschwindigkeit mindern (bzw fehlen uns halt Möglichkeiten, Grüne Wellen zu taggen - im Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für Fußgänger, Radler, usw, nicht machbar, da sich die Geschwindigkeiten relativ viel stärker unterscheiden wie bei Autofahrern). Ein eigenständig gemapptes Trottoir enthält genauso viele Querstraßen bzw. Ampeln (Crossing-Informationen) wie die Straße, die das Subtag tragen würde - vorausgesetzt, das Subtag der Straße enthält überhaupt die Seiten-Information, sonst gaukelt es ggf. zuviele Querstraßen vor - nämlich die, die auf der anderen Seite einseitig sind. falsch, die Fallen rauß, es gibt ja Turn Restrictions. Die sind leicht auszuwerten. Dazu fehlen alle Daten über die Straße selber (was für eine Straße, speed limit der Straße, und und und). Das Grüne-Welle-Problem ist eh grundsätzlich schon ein Daten-Problem, aber ansonsten unabhängig vom Mapping-Stil. Es wird hierdurch noch schlimmer. Weil ich anhand der Straßendaten berechnen kann, wie es sich für einen Fahrradfahrer ausgeht (etwa maxspeed=30, da schaffe ich es als sportlicher Radler easy im Verkehr mitzuschwimmen, bzw sogar schneller zu sein. Ist der Fahrradweg getrennt, so fehlen mir hier die relevanten Informationen über die Straße selber (und noch komplizierter, über Relationen welche auf der Straße liegen). Das separate Mappen von Fahrradwegen am Trottoir, macht derzeit genausoviel Sinn wie das separate mappen von Fahrspuren. Nächmlich gar keinen Sinn. Uns fehlt hierfür ganz einfach ein vernünftiges Datenmodell. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Cycleways - oftmals falsch getaggt
On 04.05.2011 16:01, Peter Wendorff wrote: Am 04.05.2011 12:58, schrieb Felix Hartmann: Unterscheidung, von daher ist ein in Deutschland nicht angebracht. Sie unterscheiden sich durch die An- bzw. Abwesenheit der Straße. Mit dem Argument unterscheiden sich Wanderwege mit immer wieder lockerem Sandboden und geteerte Wanderwege durch den Belag und sollten dann nicht beide mit dem gleichen highway-Wert getagged werden; der Unterschied für Radfahrer ist sicherlich größer als der zwischen Bürgersteig und Fußweg für (erwachsene) Fußgänger - überzeugt mich irgendwie nicht besonders. ich glaube, wir verstehen unterschiedliche Dinge unter Typologie. Für mich ist ein Wanderweg ein Typ (Feinunterteilungen lasse ich hier mal aussen vor, sind alles Beispiele). Eine Straße auch. Eine mehrspurige Straße mit baulich getrennten Richtungsfahrbahnen auch. Ein Gehweg/Trottoir/Bürgersteig ist für mich Teil der Straße, im Gegensatz zu einem eigenständigen Fußweg. Das meinte ich. Da bist du Architekt und ich Fußgänger ;) Ein Gehweg ist Teil des Gesamtbauwerks Straße, aber spätestens bei einer stark befahrenen Straße hab ich davon nichts gewonnen: Durch die praktische Einschränkung, dass ich die Straßenseite nicht ohne Gefahr für Leib und Leben wechseln kann, wird der Bürgersteig effektiv zu einem eigenständigen Weg. Und du verlierst durch den eigenständigen Weg, die Information, dass der Weg entlang einer stark befahrenen Straße geht, außer du legst nun für jeden Bordstein, eine Relation zur Straße. Die Information, an welcher Straße der Weg liegt, verliere ich direkt, ja. Durch doppelte Benennung mit dem gleichen Namen ist die Zuordnung aber relativ einfach. (Dass das kein besonders gutes Gegenargument zu deinem Argument ist, ist mir klar) Troittors wie auch Fahrbanspuren, sind nichts eigentständiges, sondern gehören zur Straße. Warum werden dann Fahrbahnspuren, sobald es Abbiegespuren sind, immer wieder als eigenständige osm-ways gemapped? http://osm.org/go/0GlK5rDBy-- http://osm.org/go/0GlK4ZbIK-- http://osm.org/go/0I@V9Lu@u-- hier ist die ganze Straße als zwei Wege eingetragen, aber nur durch doppelte durchgezogene Linie voneinander getrennt. Ja sobald es abbiegespuren sind, aber das ist für Autorouting noch deutlich zu wenig. Eine virtuelle Kreuzungsansicht die korrekt ist, kannst so nicht erstellen. Das ist halt auch nur ein provisorischer Workaround zu echtem Fahrspurmapping (etwa inkl. Breite jeder Fahrspur, Gewichtslimits, verschiedenen maxspeeds / Richtgeschwindigkeiten, etc... Da fehlen 99% von dem was Navteq etwa auf vielbefahrenen Straßen an Infos hat. Weitere Beispiele lassen sich bestimmt finden. Das ist also durchaus jetzt schon gängig, um das Routing zu verbessern etc. Eine strikte Auslegung der Regeln, die in Bezug auf Bürgersteige aufgestellt werden, würde dies aber generell verbieten; etwas, das ich nirgendwo dokumentiert sehe bisher, und wo auch niemand bisher jemals drauf eingegangen ist. Dummerweise bin ich ja gar nicht gegen das explizite Eintragen von Bürgersteigen, also sehe ich auch keinen Grund, die Praxis bei Auto-Fahrspuren zu kritisieren. Um die relative Lagegenauigkeit vernünftig zu mappen, fehlt derzeit einfach noch ein Konzept. ...wenn man nicht das separate Mapping benutzt. Das ist kein Konezpt, dass ist einfach nur eine schrottige Alternative. Die aber separat zu mappen, bringt nur Probleme (auch für das von dir erwähnte Fußgänger-Navi. Mal sehen, was du da so für Probleme siehst: Das wird sich denken, toll hier ist ein Trottoir, der geht lange geradeaus schön zum Ziel, richtig. aber weiß nicht, dass der Bürgersteig voll in den Abgasen hängt, Für eine diesbezügliche Beurteilung muss die Umgebung sowieso mit interpretiert werden. Was hilft es, Abgase ausschließen zu können, wenn die Mülldeponie stattdessen stinkt? Solange du das also nicht auch noch an den Fußweg pappen willst (Achtung, Mülldeponie in der Nähe!), hast du damit nichts zusätzlich verloren. Wenn die Umgebung analysiert wird, dann wird die Straße genauso gefunden wie alles andere auch. Umgebung analysieren funktioniert nicht. Da gibt es genug Beispiele hier in der mailingliste. Umgebung wird erst dann analysierbar, wenn sie durch Relationen einen Bezug bekommt (aber dass würde das Relationssystem sprengen, wenn man alles was bezug hat, überall dranpappt. Außerdem sagt sidewalk=yes ja genau das: da ist eine Straße nebenan. Aber nicht was für eine Straße. und bei jeder Querstraße Ampeln sind, ...die als highway=crossing eingetragen sein sollten. Wie erkennst du denn die Ampeln an Querstraßen, wenn du nur sidewalk=yes am Fußweg setzt? Ampeln erkenne ich so auch nicht. Hier wurde nur halbgedacht. Damit Ampeln wirklich korrekt sind, bräuchte es Standort und Relationen zu den Spuren für die sie gelten. Das ist hier aber nicht. Ich denke, hier geht deine Argumentation etwas durcheinander. die die Geschwindigkeit mindern (bzw fehlen uns halt Möglichkeiten, Grüne
Re: [Talk-de] Cycleways - oftmals falsch getaggt
On 04.05.2011 16:20, Peter Wendorff wrote: Am 04.05.2011 15:45, schrieb Felix Hartmann: und bei jeder Querstraße Ampeln sind, die die Geschwindigkeit mindern (bzw fehlen uns halt Möglichkeiten, Grüne Wellen zu taggen - im Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für Fußgänger, Radler, usw, nicht machbar, da sich die Geschwindigkeiten relativ viel stärker unterscheiden wie bei Autofahrern). Ein eigenständig gemapptes Trottoir enthält genauso viele Querstraßen bzw. Ampeln (Crossing-Informationen) wie die Straße, die das Subtag tragen würde - vorausgesetzt, das Subtag der Straße enthält überhaupt die Seiten-Information, sonst gaukelt es ggf. zuviele Querstraßen vor - nämlich die, die auf der anderen Seite einseitig sind. falsch, die Fallen rauß, es gibt ja Turn Restrictions. Die sind leicht auszuwerten. Dazu fehlen alle Daten über die Straße selber (was für eine Straße, speed limit der Straße, und und und). Was haben jetzt Turn-Restrictions mit Fußgängerrouting zu tun? Die Daten der Straße wären für die Einschätzung des Bürgersteigs halbwegs sinnvoll, ja; aber nicht besonders dringend, solange nicht gequert wird. Das sehe ich anders. Ich finde diese Daten 10mal wichtiger wie kerb=yes oder die relative Lage (absolut bringen wird dadurch ja meist eine Verschlechterung der Genauigkeit) Klar laufe ich lieber an einer Straße in der 30er-Zone entlang als an einer Stadtautobahn bei Höchstgeschwindigkeit 70 - aber notwendig ist diese Info nicht unbedingt. finde ich schon. Das Grüne-Welle-Problem ist eh grundsätzlich schon ein Daten-Problem, aber ansonsten unabhängig vom Mapping-Stil. Es wird hierdurch noch schlimmer. Weil ich anhand der Straßendaten berechnen kann, wie es sich für einen Fahrradfahrer ausgeht (etwa maxspeed=30, da schaffe ich es als sportlicher Radler easy im Verkehr mitzuschwimmen, bzw sogar schneller zu sein. Das kannst du auch weiterhin. Ist der Fahrradweg getrennt, so fehlen mir hier die relevanten Informationen über die Straße selber (und noch komplizierter, über Relationen welche auf der Straße liegen). Ist der Fahrradweg getrennt, so sollte er entsprechend auch eine Höchstgeschwindigkeit tragen, wenn diese hier zur Anwendung kommt. Abgesehen davon ist es auch weiterhin Sache der Routing-Konfiguration, ob Straßen mit Höchstgeschwindigkeit 30 fürs Radrouting mit berücksichtigt werden sollen oder nicht. Die Informationen, die auf den Radweg zutreffen, sollen natürlich am Radweg getagged werden. Ob das aber zutrifft oder nicht, ist damit erstmals explizit tagbar, während bisher die Unterscheidung eben nicht möglich ist, außer vielleicht über maxspeed:bicycle=* Wenn Du aber über den Verlust von Informationen redest, dann bring ich jetzt den Rennradfahrer, der den doofen gepflasterten Radweg nicht mag und deshalb die Straße lieber ganz meidet, sobald der Radweg mit StVO-Z 237, 240 oder 241 gekennzeichnet ist, weil er dann den Radweg benutzen MUSS. Grade als Rennradfahrer, ist es mir wichtig die Abhängigkeit von der Straße möglichst exakt zu wissen. Aber in AT brauch ich am Rennradel eh nicht den beschissenen Radweg am Randstein benutzen. Die hier WICHTIGE Information über unterschiedliche Beläge von Radweg und Fahrbahn gehen aber üblicherweise verloren (oder willst du jetzt solche Tag-Monster wie sidewalk:left:surface. aufbauen?). wüsste nicht was an sidewalk:left:surface=blablabla auszusetzen ist, genauso wenig wie an sidewalk:left:width= usw. Tagging Monster sind es nur, solange die Editoren es nicht vernünftig unterstützen. Das separate Mappen von Fahrradwegen am Trottoir, macht derzeit genausoviel Sinn wie das separate mappen von Fahrspuren. Nächmlich gar keinen Sinn. Uns fehlt hierfür ganz einfach ein vernünftiges Datenmodell. Dass das Datenmodell dafür nicht ideal ist, dem stimme ich zu. Wann aber ändert sich ein Datenmodell? Wenn der Bedarf da und der Druck groß genug ist. Mir ist bisher kein sinnvolles Datenmodell eingefallen, das mehrspurige Straßenprofile sowie Querungen unterstützen könnte, dabei aber für den Mapper handhabbar bleibt. Das Mapping imer wieder totzudiskutieren, weil kein Datenmodell genau passt, ist aber der falsche Weg. Das sehe ich anders, lieber gar nicht als falsch. Und genau der Weg wird mit dem separaten Mapping gepushed. Es braucht einfach eine klare Separation von visueller Gestaltung, und zugrundeliegenden Daten. Auch das Datenmodell an sich, muss halt verbessert werden, aber wenn wir dauernd lieber informationen halbrichtig eintragen, wird da kein Druck entstehen, Editoren vernünftig aufzubauen, um Fahrspuren gut eintragbar zu machen, ohne Informationen zu verlieren. Dazu kann man dann ja noch separat rein für die Anzeige ein visual:highway:sidewalk:cycleway einzeichnen, für jene die meinen das zu brauchen (Verdrängung - macht es nicht grade einfach). Vorschläge sind immer willkommen. Wenn sie Änderungen an der OSM-Datenbank erfordern, dann ist das eben so. Vernünftige
Re: [Talk-de] Cycleways - oftmals falsch getaggt
On 04.05.2011 16:33, Peter Wendorff wrote: Am 04.05.2011 16:13, schrieb Felix Hartmann: Was hilft es, Abgase ausschließen zu können, wenn die Mülldeponie stattdessen stinkt? Solange du das also nicht auch noch an den Fußweg pappen willst (Achtung, Mülldeponie in der Nähe!), hast du damit nichts zusätzlich verloren. Wenn die Umgebung analysiert wird, dann wird die Straße genauso gefunden wie alles andere auch. Für eine diesbezügliche Beurteilung muss die Umgebung sowieso mit interpretiert werden. Umgebung analysieren funktioniert nicht. Glaub ich nicht ;) Da gibt es genug Beispiele hier in der mailingliste. Welche? Ich will ja lernen ;) Hab jetzt keine Lust zu suchen, aber das notorisch in nur 90% aller Fälle korrekte Nominatim, ist doch die beste Begründung. Es funktioniert nicht zuverlässig. Umgebung wird erst dann analysierbar, wenn sie durch Relationen einen Bezug bekommt (aber dass würde das Relationssystem sprengen, wenn man alles was bezug hat, überall dranpappt. Ich gebe zu, dass Nominatim da recht viel Rechenzeit reinsteckt, aber die Zuordnung von Häusern zu Straßen funktioniert - und das ist eine reine Umgebungsanalyse in den allermeisten Fällen. Ich sehe keinen Grund, warum das in anderen Fällen nicht gehen sollte. Außerdem sagt sidewalk=yes ja genau das: da ist eine Straße nebenan. Aber nicht was für eine Straße. Ja und? Wie viele Straßen sind denn üblicherweise nebenan? Nimm großzügig kalkuliert eine Straßenbreite von 14 Metern an (das reicht für eine zweispurige innerorts-Bundesstraße einschließlich Randstreifen), dann reicht ein Puffer zur Seite von 9 Metern aus, um die richtige Straße zu finden. Innerhalb dieses Puffers zwei Straßen zu finden, und dann die falsche zu treffen, wenn man tatsächlich mehrere findet und die nächste davon auswählt, halte ich für ein seltenes Phänomen. Dann müsste man Bäume, Mauern, Haushöhen, usw mit reinrechnen, das ist nur ein Kampf, der nie korrekt sein wird. und bei jeder Querstraße Ampeln sind, ...die als highway=crossing eingetragen sein sollten. Wie erkennst du denn die Ampeln an Querstraßen, wenn du nur sidewalk=yes am Fußweg setzt? Ampeln erkenne ich so auch nicht. Hier wurde nur halbgedacht. Damit Ampeln wirklich korrekt sind, bräuchte es Standort und Relationen zu den Spuren für die sie gelten. Das ist hier aber nicht. Wieso das? Wir sind bei Fußgängerrouting und Querungen. Die sind per highway=crossing eingetragen, und zwar nicht auf dem Kreuzungspunkt der beiden Straßen, sondern abseits davon da, wo die Fußgängerampel steht (meist ca 3-5 meter vom Straßenrand(!) entfernt). Aus einer Kfz-Ampel eine Fußgängerampel zu schließen geht sowieso oft schief. Das Ampel-Tagging für Autos ist nicht perfekt, da gebe ich dir recht; es hat mich allerdings bisher auch nur am Rande interessiert. Dass die für nur einige Spuren gelten üblicherweise ist richtig, aber irrelevant, solange die Spuren nicht eingetragen sind. Jip, und genau daher sollten wir es auch bei Wegen am Gehsteig genauso handlen, nicht separat eintragen. Ich denke, hier geht deine Argumentation etwas durcheinander. die die Geschwindigkeit mindern (bzw fehlen uns halt Möglichkeiten, Grüne Wellen zu taggen - im Bezug zur Fortbewegungsgeschwindigkeit (ohne ist es für Fußgänger, Radler, usw, nicht machbar, da sich die Geschwindigkeiten relativ viel stärker unterscheiden wie bei Autofahrern). Aber ist das ein Problem, das man löst, indem man Bürgersteige als Tags an der Straße mapped? Nein, nicht vollständig, aber schon besser wie wenn die Sachen separat gemapped sind. Wieso? Schließt du aus der grünen Welle der Autos auf eine grüne Welle für Fußgänger und Radfahrer? Sorry, aber das ist unrealistisch. Nein, das geht sogar ganz gut - solange Grüne Wellen nur geschätzt werden. Klar ist man langsamer, aber halbwegs einschätzen kann es eine Routingengine trotzdem - und wenn die Ampelschaltungen mal korrekt eingetragen sind, dann würde es sogar hervorragend gehen, basierend auf momentaner Geschwindigkeit. Gruß Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] Plan.at Statistik
On 04.05.2011 11:14, m5st wrote: Hallo! Ich habe jetzt eine Auswertung gemacht um die plan.at-Mapper etwas anzuspornen. Ausgewertet werden folgende tags: *note=imported from plan.at *fixme=check import *at:maxspeed Ausgwertet wird das Geofabrik-Extrakt. Die derzeitige Statstik: Datum: 'note=imported from plan.at' 'fixme=check import' 'at:maxspeed' 18.04.2011: 113049 120852 54433 01.05.2011: 112713 119708 52020 04.05.2011: 112850 119649 50612 Ui, das wird aber noch lange brauchen. Also 16 Tage um 1200 Straßen zu fixen. Da brauchen wir ja noch gute 1600 Tage - oder über 4 Jahre bis die plan.at Sachen korrigiert sind (und das unter der Annahme, die Geschwindigkeit wird nicht langsamer, was aber passieren wird, je weniger plan.at Schrott noch übrig ist). Weiß jemand wieviele Wege insgesamt importiert wurden? (bzw wieviele Wege vor 1 Jahr übrig waren - da ja Teils in Gegenden einfach alles gelöscht wurde). Warum da 'note=imported from plan.at' steigt ist mir rätselhaft. lg, m5st ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [OSM-talk] Skip geographical (redundant) address tags
On 03.05.2011 10:09, Thomas Davie wrote: On 3 May 2011, at 08:57, Jaak Laineste wrote: Hello, It looks like trivial suggestion, but could not find any past discussions with quick search. Is there good reason to add addr:country, addr:county, addr:city and other regional tags to all the address tags, if OSM database already has administrative regions for given area? These admin areas already create implicit relation, which can be used in any application to add city,country,district,state and other regions. So buildings would have only addr:street, addr:housenumber (and possibly house:housename and addr:full tags). Depending on country, addr:postcode could be geographical also. Searching a database for a way that surrounds a potentially enormous area (certainly enormous in the case of country) when you want to find out what city/country/... is this in is *far* less efficient than simply looking at the tags. Plus, Addresses are not always as straightforward as you make out, it's not possible to tell which administrative areas should be included in an address by simply looking at which ones happen to encompass the building. Bob ___ +1 Look at all current implementations. If the address is not tagged completly (country, state, city, street) then programs are lost, and boundaries are too often wrong or incomplete or if someone deletes them accidentally (or renames them slightly) all data inside the boundary wouldn't have an address anymore. Plus it takes a lot of computation time, to put boundary information onto objects inside. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] When advertising is good
The biggest problem we have is that were not important enough and too cluttered to attract in map adverts yet. I think in the long run, it's not about adverts around the map, but ads in the map (of course the database should be advert free). Als our maps are still mainly for looking at, maximum autorouting, but few to noone uses them to search for specific stuff, so there is less incentive to promote your business by buying a logo for it (smallest thing to start with). Google has to pay for map data, and still makes enough money with in map adverts to more than cover costs, but we miss a system for map producers, that is as simple as google adsense for websites, to place in map adverts. I often think about how and where would be a good start to get it going! On 03.05.2011 21:25, Nic Roets wrote: One or two people on the list said that they avoid advertising where ever they can. I know advertising can be annoying when the same add appears 10 times in a row, but I just want to explain a few things. Let's look at the example of a restaurant that is working below capacity. It can be because they recently opened. It can be because they are not located on a busy corner. So they have waiters and chefs not working at peak productivity. They have freshly prepared food going to waste. This is a problem that on demand location based advertising can solve, provided people are willing to accept it in their lives: The restaurant gets more patrons. Those patrons no longer go to other restaurants. The other restaurants are now able to serve the remaining patrons faster. And the same argument does for most retail and service business. The great thing about OSM is that we are driving the cost of maps to $0. If media corporation have annoying ads, people will simply switch. The media corporation and the advertiser (the restaurant) will now need to work together to give you the maps at a cost below 0. My guess is that it will be in the form of coupons or other specials. If you order the OSM special, you get a free softdrink with your burger. So next time you want to embed maknik in website, consider the advantages of embedding MapQuest instead. (And no, I do not have affiliation with MapQuest or any media company). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] [mkgmap-dev] continue statement and order of drawn ways?
On 04.05.2011 00:05, Henning Scholland wrote: Am 03.05.2011 23:37, schrieb Felix Hartmann: On 03.05.2011 23:27, Minko wrote: Yes, that is also a good alternative, 0x01 as a transparent line and on top either 0x10f01 or 0x10f02 you cannot make a line transparent by omitting it from the typfile, but go ahead and do your tries. Yes, but you can use a transparent png-file ;) Henning And then you have streetnames shown, but no street If you remove the streetnames on 0x01, you remove streetnames on the broken Oregon, edge 800, gpsmaps 62 series, for all maps (until hard reset) ___ 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
Genau das sage ich ja. Daher will ich keine odbl. Ausserdem gehts wie gesagt gar nicht um Garmin, sondern um Vektorkarten im allgemeinen. Und hier versagt die odbl kläglich, weil nicht klar ist was eine Datenbank ist, bzw was Vektorkarten sind. Ich hab doch aber gerade auf ca. 100 Zeilen dargestellt, dass es eigentlich gar keine Rolle spielt? Naja, ich finde es keine Lösung, wenn die Lizenz zu ihrem größten Unterscheidungspunkt, derivated database oder produced work, keine klaren Regeln hat, was was ist. Und die Regel der Ersteller bestimmt es selber, hat für mich mit Datenfreiheit nichts zu tun. Da ist die Freiheit einfach den Bach runtergeflossen... ___ 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
On 30.04.2011 10:48, Simon Poole wrote: Die Regel ist eigentlich klar: Produced Work ausser es wurde zum Zwecke gemacht die Bestimmungen in der ODbL zur Datenbank zu umgehen. Da das bei einer Garminkarte eigentlich nicht so ist (sprich Geometrie hat man, den Rest eigentlich nur grob, insofern es sich überhaupt auf Garmin Werte abbilden lässt) - Produced Work. Das ist aber keine glückliche Definition und lässt Unmengen an Spielraum zu. Etwa ich exportiere Key X aus OSM Datenbank, um ihn für meine Anwendung zu benutzen. Dann ist das der Auffassung nach eindeutig Produced Work. Da ich aber für eine Garmin Karte nicht nur Key X exporiere, sondern sallop gesagt A-F, aber ohne D., habe ich schon eine recht umfangreiche Datenbank. Ausserdem erstelle ich ja etwa für die Addresssuche auch eine wirkliche neue Datenbank aus OSM Daten. -- Aber du sagst eindeutig Produced Work. Gut dann ist eh alles Produced Work, wenn der Zweck den ich festlege (kann ja sein dass die User einen ganz anderen Zweck sehen wollen) keine Umgehung der Datenbank ist. Ohne fixe Regeln die keinen Spielraum lassen, ist dass doch Schwachsinn von hinten bis vorne. ___ 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
On 30.04.2011 15:51, Henning Scholland wrote: Am 30.04.2011 14:11, schrieb M∡rtin Koppenhoefer: Am 30. April 2011 13:41 schrieb Henning Schollando...@aighes.de: WIe bereits in der anderen Mail angedeutet kann man mit etwas Bilderkennung und Rechenpower auch aus einem jpg die Daten wieder auslesen. ach echt? Hast Du ein Programm dafuer oder eine Referenz? Ich bin bisher immer davon ausgegangen, dass das nicht moeglich sei. Habe mich selbst im Studium schon mit Vektorisierungsversuchen von Raster-Katasterplaenen rumgeschlagen (600 dpi s/w, 1:5000) und kann Dir berichten, dass da nie was brauchbares rauskam. Nie. Ich glaube das nicht, dass das geht, will es aber auch nicht komplett ausschliessen. Gleich gut kann es aber natuerlich nicht werden, da die meisten Attribute (bozogen auf die Anzahl verschiedener Attribute) und tags im Rendering ja gar nicht drin sind. Es gab im Zuge der Bing-Bildbereitstellung erste Ansätze, aus den Satbildern Straßenverläufen zu folgen. Umgesetzt als josm-Plugin. Wie der derzeitige Stand ist, weiß ich nicht. Aber ganz unbrauchbar war das damals gezeigte Ergebnis nicht. Eine Online-Demo gibts hier http://maps.qualitystreetmap.org/bingtracing/ Wenn das mit Sat-Bildern schon so gut funktioniert, dann dürfte es mit einem einfach gehaltenen Style durchaus möglich sein, zumindest Straßen zu extrahieren. Henning Topo Hispania -- eine Garminvektorkarte erstellt aus den amtlichen (NCBY) veröffentlichten Rasterkarten. Es geht also sehr wohl. Auch wenn es natürlich besser ist, die zugrunde liegenden Daten zu haben. Die Sache mit Datenbank vs Produced Work, hinkt einfach von hinten bis vorne. ___ 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
On 30.04.2011 15:59, Henning Scholland wrote: Am 30.04.2011 14:52, schrieb Frederik Ramm: Das ist von der Logik her nicht ganz leicht zu begreifen, weil man immer denkt: Wenn die DVD erstmal ihr Share-Alike verloren hat, dann kann das ja nicht wieder zurueckkommen. Kann es aber doch. Das ist so aehnlich, wie wenn ich Dir ein Rezept fuer Milcheis aufschreibe und versichere, dass mein Text PD ist, und dann stellt sich heraus, dass jemand anders - moeglicherweise komplett ohne mein Wissen - ein Patent auf diese Art der Milcheis-Herstellung hat. Dann kannst Du auch nicht darauf pochen, dass Du doch hier einen 100% PD-Zettel hast, auf dem das draufsteht. Vollkommen richtig. Der Patentinhaber wird Ulf auf Schadensersatz verklagen und Ulf, sagt, wieso soll ich das zahlen. Der Frederik hat mir doch das Ding als PD verkauft und verklagt dich auf Schadensersatz. Also bist du der dumme. Vorallem, wenn man bedenkt, dass es hier nicht um Milchreis geht, sondern um OSM-Daten und dass man als Autor sich schon mit der Lizenz auseinander gesetzt haben muss, wenn man die Daten nicht unter ODbL stellt, ergo sich nicht rausreden kann und sagen kann, man hätte davon nichts gewusst. Henning Was dann einfach im Grunde so ausschaut. Entweder odbl oder unfrei. Aber von einer freien Karte aus freien Daten ist man halt weit weg. Schöne neue odbl Welt ___ 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
On 30.04.2011 16:57, Bodo Meissner wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am 30.04.2011 01:22, schrieb Felix Hartmann: Das würde mit CCBYSA und dem DRM verbot durchs Share Alike halt anders aussehen. Glaube ich nicht. Ich könnte das übersehen haben, weil die vollständigen Lizenztexte ziemlich unübersichtlich sind. Wo genau steht bei CCBYSA das DRM-Verbot? Wenn ich dem Käufer erlaube, die Karte unter CCBYSA weiterzugeben, die Daten aber nur auf einem bestimmten Gerät nutzbar sind, habe ich dann formal die Lizenz eingehalten? Soweit ich weiß, steht in der CCBYSA 3.0 (auf die man ja ohne Userbefragung wechseln könnte) drinne, das Maßnahmen die die weitergabe Einschränken nicht zulässig sind. Daher ist DRM nicht erlaubt. ___ 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
On 29.04.2011 12:32, Ulf Lamping wrote: Am 21.04.2011 09:59, schrieb Frederik Ramm: Hallo Kai, On 04/21/11 04:23, Kai Krueger wrote: Mit ODbL muss ich nun mir ueberlegen ist es ein Produced Work oder nicht? Wenn es eine Datenbank ist, ist es eine Datenbank, und ansonsten ist es ein Produced Work. Es gibt in der Tat ein paar Dinge, bei denen das nicht so klar ist (z.B. Garmin-Vektorkarte), aber in den allermeisten Faellen ist es klar. Gerade die allermeisten OSM Anwendungsfälle sind aktuell Garminkarten, der Satz beinhaltet dadurch eine gewisse Komik ;-) Das wichtige ist doch, dass Künstler nun die Daten nehmen können wie sie wollen. Weil die mussten bisher ja ihre Kunstwerke und CCBYSA 2.0 stellen, also quasi Kommunismus. :-P Da dürfen solche kleinen Spezialfälle wie ob eine Vektorkarte aus OSM Daten nun ein produced Work ist oder eine database nicht im Weg stehen. :-D Ausserdem wird von Befürwortern ja derzeit schon angenommen, CCBYSA existiere nicht mehr: /Die Reit- und Wanderkarte ist als Onlinekarte gedacht. Der direkte Download von Kacheln ist nur begrenzt möglich, um den Onlinebetrieb nicht auszubremsen. Für alle, die gerne größere Bereiche herunterladen wollen, z.B. um sie auf ein Smartphone zu übertragen, gibt es die Möglichkeit, die Karte zu abonnieren. / /Abonnenten erhalten Zugang zu einer speziellen Download-URL, die eine Anmeldung erfordert. Dieser Zugang ist so ausgelegt daß er den Onlinebetrieb möglichst wenig stört. Die Kartenkacheln für das Abonnement werden mindestens alle 2 Wochen aktualisiert. *Sie dürfen aus lizenzrechtlichen Gründen nur für den Eigengebrauch verwendet und nicht weiter veröffentlicht werden*. Abonnenten können beliebige Bereiche in der Karte bis zum Zoomlevel 16 (ca. 1:5000) und bis zu 2 Millionen Kacheln im Monat herunterladen. Von der Größenordnung her sollte das reichen um ganz Deutschland monatlich abholen zu können. / Quelle:http://www.wanderreitkarte.de/shop_abo_de.php Also auf, damit dass kein Einzelfall bleiben muss, sondern Regel wird, helft alle kräftig mit und spammt die odbl Ablehner zu. An die CCBYSA 2.0 halten sich die odbler ja eh schon länger nicht mehr.:-* ___ 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
On 29.04.2011 19:32, Frederik Ramm wrote: Hallo, Felix Hartmann wrote: Also auf, damit dass kein Einzelfall bleiben muss, sondern Regel wird, helft alle kräftig mit und spammt die odbl Ablehner zu. An die CCBYSA 2.0 halten sich die odbler ja eh schon länger nicht mehr.:-* Ich hatte Dich immer so verstanden, als ob es Dir eigentlich sogar lieb waere, wenn Du deine eigenen aus OSM abgeleiteten Werke unter einer Noncommercial-Lizenz vertreiben koenntest, und dass Du nur mit einem Zaehneknirschen hingenommen hast, dass das nicht moeglich war. Da muesstest Du die ODbL doch eigentlich begruessen? Falsch, ich hab nur meine ganzen Skripte unter NC, damit sie genauf für sowas nicht hergenommen werden dürfen. Im Prinzip sind meine Skripte/Files eh nicht legal benutzbar, da NC inkompatibel mit CCBYSA ohne NC. Ich bin dafür, dass Datenbank UND Endprodukte Share Alike sein müssen. Dann würde man sich auch die komplette Debatte Datenbank vs Produkt sparen, weil es irrelevant wäre. Für mich ist es auch illegal, einen Server anzubieten, wie oben geschrieben, wo man OSM verbreitet, aber Usern sagt Share Alike nicht erlaubt. Aber ich würde das so interpretieren, wie dass da eben Share Alike Vorrang hat, sprich der Seiteninhaben ist halt der der die Probleme hat, weil die CCBYSA 2.0 halt aussagt, dass wenn man Sachen vermischt, das Endprodukt auch Share Alike ist, und damit Nop's Text ungültig und jeder kann machen was er will mit den Daten - solange er sich an CCBYSA 2.0 hält. Das geht aber eigentlich schon bei der Onlinekarte los, wenn der User keine Möglichkeit hat, die Höhenlinien auszublenden per ermessbarem Aufwand (das heißt sicherlich nicht irgendwas umzuprogrammieren um den Layer zu löschen), dann ist der Hinweis auf eine andere Lizenz des Layers eh hinfällig, und das ganze ein CCBYSA 2.0 Produkt. ___ 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
On 29.04.2011 20:42, Frederik Ramm wrote: Hi, Henning Scholland wrote: Kann man es denn irgendwo Schwarz auf Weiß lesen, dass eine Garmin-Karte keine Datenbank im Sinne der Lizenz ist? Nein - weder, dass sie keine ist, noch dass sie eine ist. Ich hatte ja gesagt, dass das noch so ein etwas unklarer Punkt ist. Das Problem mit einer Garminkarte ist, dass sie von der Technik her nach saemtlichen Regeln der Kunst eben gerade eine Datenbank ist (waere es ein offenes Format, so wuerden Garminkarten z.B. als sqlite-Files ausgeliefert werden oder sowas). Andererseits ist sie in der Anwendung - das legt schon der Name Karte nahe - eben keine Datenbank. Die OSMF will da gemeinsam mit der Community Regeln festlegen. Im Augenblick sieht die Regel so aus: http://wiki.openstreetmap.org/wiki/Open_Data_License/Produced_Work_-_Guideline If it was intended for the extraction of the original data, then it is a database and not a Produced Work. Otherwise it is a Produced Work. Das ist leider nicht besonders hilfreich. Ich denke, der Fall Garmin-Karte muss da noch genauer diskutiert werden. Ich neige eigentlich eher zu der Interpretation, das eine Garmin-Karte keine Datenbank im Sinne der ODbL ist. Es geht hier aber um viel mehr, als nur Garmin Karten. Wenn es keine Datenbank ist, bedeutet dass, auf allen GPS/Smartphones etc. können kostenpflichtige, und nicht weiterbreitbare Vektorkarten angeboten werden. Sprich für die User wird es großteils (Ausnahme Garmin - weil hier ja das Format geknackt ist) - keine kostenlosen Karten geben. Es geht um ALLE Anwendungen wo offline eine Karte aus Vektordaten gespeichert ist. (und in Zukunft, wird es sicherlich auch kommen, dass die Karten nicht mehr von Mapnik, sondern zu großen Teilen lokal am Computer gerendert werden, womit auch die Anzeige von Karten am PC nicht geregelt sein wird -- OSM ist eine Vektorkarte, und das zu einer Rasterkarte zu verwursten, ist IMHO einfach nur ein Beschränkung und liegt an mangelnder Software) Wenn es aber eine Datenbank ist, bedeutet dies, Anbieter die ein Share Alike der Karten verhindern wollen, dürfen dies auch (bisher ist etwa DRM dazu verboten, weil es das Share Alike verhindert, es geht derzeit schon durch die Hintertür, wie Karten kann man offen verbreiten, aber die Software ließt sie nur wenn ein proprietärer Schlüssel dies erlaubt). Damit sagt die ODBL zum Großteil aller Anwendugnsfällte, derzeit einfach gar nichts aus. ___ 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
On 29.04.2011 22:34, Simon Poole wrote: Am 29.04.2011 21:57, schrieb Felix Hartmann: Es geht hier aber um viel mehr, als nur Garmin Karten. Wenn es keine Datenbank ist, bedeutet dass, auf allen GPS/Smartphones etc. können kostenpflichtige, und nicht weiterbreitbare Vektorkarten angeboten werden. Sprich für die User wird es großteils (Ausnahme Garmin - weil hier ja das Format geknackt ist) - keine kostenlosen Karten geben. Deine Logik scheint mir nicht ganz schlüssig. Wenn das Format geknackt ist, dann kann jeder mit den entsprechenden Tools Karten für das entsprechende Gerät produzieren (siehe Garmin). Ist das Format nicht geknackt gibt es, mit oder ohne OSM, mit ODbL oder CC-by-SA, so oder so keine vom Hersteller unabhängigen Karten. Ich sehe für OSM keinen Vorteil darin den Benutzern solcher Geräte künstlich den Zugang zu OSM-Daten zu erschweren, ausser man verfolgt was, schlussendlich, ideologische Ziele ohne Bezug zum Projekt sind. Simon Das sehe ich anders. Mit CCBYSA gibt es für die Hersteller eine Motivation ein offenes Format für die Karten zu ermöglichen/implementieren. Man kann ja nicht davon ausgehen, dass ein geschlossenes Format reverse engineered wird (gut das Garmin Format ist nicht geschlossen, sondern einfach nicht dokumentiert, es ist durch keinerlei DRM oder Encryption geschützt - daher kann man auch nur bedingt von geschlossen reden). Es muss ja nicht jeder Hersteller so bekloppt sein wie die Asiaten (Name kann sich eh jeder denken), welche ihr GPS mit einer Mapnik Karten in Zoomstufe 15 rausgeben, und alles andere als 15 ist nicht möglich (oder wars 16??). Ein Outdoorfähiges PNA mit offener Software zu moderatem Preis wird so schnell nicht kommen. Bei odbl, (siehe nächsten Post von Frederik) kann es sich der Hersteller einfach machen. Er bietet eine odbl Datenbank zum kostenpflichtigen Download an (offen - wird eh niemanden interessieren), und daneben halt seine Karten kostenpflichtig. Genau das würde aber mit CCBYSA 2.0 nicht gehen! (zumindest nicht ohne große Umwege wie Karten kostenlos und offen, aber zur Benutzung kostenpflichtige Schlüssel). ___ 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
On 29.04.2011 23:31, Frederik Ramm wrote: Hallo, Felix Hartmann wrote: Das ist leider nicht besonders hilfreich. Ich denke, der Fall Garmin-Karte muss da noch genauer diskutiert werden. Ich neige eigentlich eher zu der Interpretation, das eine Garmin-Karte keine Datenbank im Sinne der ODbL ist. Es geht hier aber um viel mehr, als nur Garmin Karten. Wenn es keine Datenbank ist, bedeutet dass, auf allen GPS/Smartphones etc. können kostenpflichtige, und nicht weiterbreitbare Vektorkarten angeboten werden. Hm, das ist aber nach meiner Interpretation nicht davon abhaengig, ob es sich um eine Datenbank handelt oder nicht. Denn selbst wenn es eine Datenbank ist, dann erlaubt die ODbL dennoch, dass der Hersteller diese Datenbank in einer speziellen, technisch geschuetzten Version vertreibt (z.B. ein verschluesseltes Kartenformat fuer mobile Geraete), wenn er parallel die Daten auch in einem frei lesbaren Format anbietet (siehe Abschnitt 4.7.b der ODbL). Das bedeutet, dass die ODbL nicht als Hebel taugt, um den Hersteller zu zwingen, sein Datenformat offenzulegen oder seine compilierten Karten jedem zur freien Nutzung zu ueberlassen; der Hersteller muss lediglich die zugrundeliegenden *Daten* freigeben (genauso wie auch bei einem Produced Work). Richtig, unter odbl kann jeder machen was er will, außer halt die Daten zu vermischen ohne Veröffentlichung. Unter CCBYSA geht das nicht! Auch hier wieder die Motivation: OSM ist ein Datenprojekt; wir haben uns nicht auf die Fahnen geschrieben, die Welt von der Geissel proprietaerer Hardware/Software zu befreien. Wenn sich ein Nutzer aus freien Stuecken fuer ein GPS-Geraet entscheidet, dessen Hersteller das Kartenformat geheimhaelt und womoeglich sogar kryptographisch abgesicherte OSM-Datenupdates fuer 99,90 Euro verkauft, dann ist das zwar keine Entscheidung, die *ich* treffen wuerde, aber moeglich ist es. (Wenn der Hersteller damit wuerbe, dass seine OSM-Daten verbessert seien, dann koennte man von ihm diese verbesserten Daten unter ODbL fordern - aber nicht notwendigerweise in einem auf das Geraet spielbaren Format!) Das würde mit CCBYSA und dem DRM verbot durchs Share Alike halt anders aussehen. Aber gut, du scheinst halt gerne als Geisel zu leben. Sprich für die User wird es großteils (Ausnahme Garmin - weil hier ja das Format geknackt ist) - keine kostenlosen Karten geben. Es geht um ALLE Anwendungen wo offline eine Karte aus Vektordaten gespeichert ist. Ehrlich gesagt, habe ich wenig Mitgefuehl mit freiwilligen Nutzern geschlossener Plattformen. Es ist ja nun nicht so schwer, sich ein Geraet zu kaufen, auf dem man z.B. MoNav installieren kann oder so. Wenn es denn bezahlbare und gute Geräte gäbe. Aber unter 600€ ist derzeit nichts zu bekommen (etwa Maggelan Mobile Mapper 6 - und Windows Mobile ist ja auch nicht gerade dass Allheilmittel) Damit sagt die ODBL zum Großteil aller Anwendugnsfällte, derzeit einfach gar nichts aus. Es stimmt zwar, dass derzeit unklar ist, ob eine Garminkarte eine Datenbank sein soll oder ein abgeleitetes Werk; allerdings ist es fuer Deine Argumentation nicht relevant, da die Folgen gleich sind: Falls Garminkarte = Produced Work: * Werk selbst kann unter nahezu beliebiger Lizenz stehen, z.B. kostet 50 Euro, kopieren verboten * zugrundeliegende Datenbank muss aber auf Anfrage rausgegeben werden unter ODbL Falls Garminkarte = Derived Database: * Datenbank selbst muss unter ODbL rausgegeben werden, darf aber in einem speziellen Format codiert/compiliert/verschluesselt sein, wenn * man die Datenbank zugleich in einem lesbaren Format verfuegbar macht Beide Faelle ermoeglichen es also einem auf ein geschlossenes System bedachten Hersteller, OSM-Karten fuer seine Geraete herauszugeben, die man nicht kopieren darf/kann. Genau das sage ich ja. Daher will ich keine odbl. Ausserdem gehts wie gesagt gar nicht um Garmin, sondern um Vektorkarten im allgemeinen. Und hier versagt die odbl kläglich, weil nicht klar ist was eine Datenbank ist, bzw was Vektorkarten sind. Und dass ist einfach für mich nur lächerlich, und ein klarer Grund warum odbl nicht akezptierbar ist (neben dem fehlenden Share Alike der Produced Works). ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
On 18.04.2011 13:54, Heiko Jacobs wrote: 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: Gibt es dazu irgendwelche Docs? 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 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). 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. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
On 18.04.2011 17:56, M∡rtin Koppenhoefer wrote: Am 18. April 2011 17:35 schrieb Felix Hartmannextremecar...@gmail.com: 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). So könnte man am besten die Karten für niedrige Zoomstufen aufbereiten. m.E. sollte man idealerweise jeweils das ans jeweilige Gleis taggen, was es ist. D.h. wenn eine Hochgeschwindigkeitsstrecke 2-gleisig ausgebaut ist, und beide Gleise gemappt sind, würde ich auch an beiden Gleisen die Info haben wollen. Was einfacher auszuwerten ist bzw. bei bestimmten Renderregeln und Rohdaten als Eingang am besten aussieht sollte dabei sekundär sein. Das sehe ich anders. Dann bräuchte es eben halt auch die Information, dass man ein Gleis wegschmeißen kann. Das Problem von Fahrspuren, usw ist dass Verdrängung nur bei Rasterkarten, aber nicht bei Vektorkarten funktioniert. Und OSM ist nunmal eine Vektorkarte. 2Gleise gehen ja noch, Aber bei 20 Gleisen im Bahnhof, wo pappst da die Relation drann An jedem Gleis ist genauso falsch wie an einem Gleis. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
On 18.04.2011 18:00, Heiko Jacobs wrote: 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 ;-) Geht genauso bei zweigleisig und tracks=2. Das ganze ist aber ein prinzipielles OSM Problem. Im Grunde müsste man beides separat in der Datenbank aufnehmen (und so ist es auch in professionellen Datenbanken, bzw hängen da die Infos sonst so drann, dass man weiß was man wegschmeißen kann). Alles andere ist bei Vektorkarten einfach unoptimal. Oder wir hätten in einer forward Relation die auf einem Gleis liegt, gleich die Info dass noch eine backward relation auf einem anderen Gleis liegt, aber die backward keine grundsätzlich unterschiedlichen Streckenverläufe hat, und somit fallengelassen werden kann. 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
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. Hier auf deutsch: http://www.transportrecht.de/transportrecht_content/1271941086.pdf On 18.04.2011 13:54, Heiko Jacobs wrote: 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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
On 18.04.2011 18:36, M∡rtin Koppenhoefer wrote: Am 18. April 2011 18:18 schrieb Felix Hartmannextremecar...@gmail.com: Das sehe ich anders. Dann bräuchte es eben halt auch die Information, dass man ein Gleis wegschmeißen kann. Das Problem von Fahrspuren, usw ist dass Verdrängung nur bei Rasterkarten, aber nicht bei Vektorkarten funktioniert. Und OSM ist nunmal eine Vektorkarte. OSM ist eine Datenbank. 2Gleise gehen ja noch, Aber bei 20 Gleisen im Bahnhof, wo pappst da die Relation drann An jedem Gleis ist genauso falsch wie an einem Gleis. wenn es so ist, dass der Zug wirklich je nach aktueller Situation auf verschiedenen Gleisen fährt, muss man sich was ausdenken bzw. etwas weniger genau mappen, klar. Gleise wegschmeissen kommt für die Datenbank aber nicht in Frage, das kannst Du schön bei Dir lokal machen... Es geht nicht drum, dass die Gleise weggeschmissen werden. Sondern das in den Daten steht, was man weglassen kann weil es ab einer bestimmten Auflösung nicht mehr unterscheidbar ist / gewollt ist dies zu unterscheiden. Und das funktioniert nunmal nicht automatisch. (wer was anderes Behauptet soll es beweisen und vorzeigen). Dasselbe Problem wird kommen, wenn wir in OSM irgendwann flächendeckend Fahrspuren mappen. Dann brauchen wir trotzdem eine einfache Straße als Grundlage, und nicht nur nur Fahrspuren. Sprich eine einfache Strecke, und Detailgleisinformationen. Man kann aber weder aus der einfachen Strecke noch aus den Detailgleisinformationen automatisch das andere errechnen. Derzeit ist es aber so, dass man eigentlich aus OSM eine Vektorkarte nicht für Mapnik Zoomlevel 13 bauen kann, ohne in das Problem unlösbarer Detailselektion zu kommen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
On 18.04.2011 20:25, M∡rtin Koppenhoefer wrote: Am 18. April 2011 18:44 schrieb Felix Hartmannextremecar...@gmail.com: Es geht nicht drum, dass die Gleise weggeschmissen werden. Sondern das in den Daten steht, was man weglassen kann weil es ab einer bestimmten Auflösung nicht mehr unterscheidbar ist / gewollt ist dies zu unterscheiden. Und das funktioniert nunmal nicht automatisch. (wer was anderes Behauptet soll es beweisen und vorzeigen). puffer um das Gleis legen und analysieren, ob andere Gleise darin vorkommen. Nah her mit dem Code. Bisher hat kein einziges Programm was OSM daten anylisiert dies umgesetzt AFAIK. Es würde evtl ja sogar halbwegs gehen, aber vernünftiger und korrekter ist es korrekt zu erfassen (ob das jetzt separat oder als zusatz tag ist, ist im Grunde egal). Dasselbe Problem wird kommen, wenn wir in OSM irgendwann flächendeckend Fahrspuren mappen. Dann brauchen wir trotzdem eine einfache Straße als Grundlage, und nicht nur nur Fahrspuren. glaube ich nicht. Einfacher wäre es aber wohl, daher wird man es wohl so machen. Sprich eine einfache Strecke, und Detailgleisinformationen. Man kann aber weder aus der einfachen Strecke noch aus den Detailgleisinformationen automatisch das andere errechnen. doch, Detail reduzieren geht immer, automatisch hinzufügen halte ich aber auch für extrem extrem extrem schwierig ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
Der Grund, warum man (ich) das bisher nicht braucht, ist dass sich das beim Rendern von lowzoom sowieso von selbst löst (Überlagerung durch die Überhöhung). Klar, man rendert auch viel, was man eigentlich nicht sieht (könnte Rechenzeit und Strom sparen). Je nachdem, wie lange Du den Datensatz behalten willst, um so umständlicheres Prozessing kannst Du Dir erlauben (und um so eher spart man auch wirklich unterm Strich). Das ist eindeutig Falsch. Nur bei Rasterkarten ist es derzeit egal. Aber alle Karten die real-time gerendert werden (und irgendwann wird man auch bei Mapnik und anderen Renderern draufkommen, dass es zumindest im Nahbereich praktischer ist, wenn realtime am PC des Kartenbetrachters gerendert wird) dann ist es extrem blöd, wenn man 10 Gleise rendern muss, die sich eh überlappen. Das vorher auszufiltern ist aber mehr oder weniger unmöglich ohne Fehler zu bekommen. Wenn OSM keine reine Amateur und Zweitlösung sein will, muss man den Lowzoombereich radikal umbauen. Das geht im Prinzip über tags, praktischer in einer eigenen, bzw per Tags getrennten, Datenbank. Dass es derzeit schrott ist, sieht man ja bei allen Renderern aus OSM Daten. Will ich einen Überblick haben, benutze ich zu 100% nicht OSM, weil es einfach nichtmal mit Rasterkarten möglich ist, was gscheites aus der Datenbank für etwa eine Deutschland A3 Karte rausextrahierbar ist. Dabei wäre die Datenerfassung dafür trivial, hätte man ein vernünftiges Taggingsystem. Weshalb ich meinen Einwand vorgebracht habe: die Abwägung Detaillierung zu einfacherer Auswertbarkeit sollte in gewissem Rahmen zu Gunsten der Detaillierung getroffen werden, und hier ist es m,E. eindeutig (das ist doch einer der Hauptgründe, überhaupt parallele Gleise zu mappen). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] railway=* usage
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 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] railway=* usage
On 16.04.2011 17:44, Heiko Jacobs wrote: 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 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.. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-at] plan.at die X-te
On 26.03.2011 18:01, Stefan Hirschmann wrote: wolfbert wrote: Hallo Boris, finde ich gut (Treffen), persönlich kommt man da besser voran, finde ich. Eigentlich reduziert sich das Ganze auf zwei Fragen: 1. Wollen wir eine solche Initiative jetzt starten? Bitte eine Sache beachten: Alle Wege, die bisher noch nie bearbeitet worden sind haben als Tagger den plan.at Upload User drinnen. Das ist ein super Filterkriterium. ZB Bezirk Imst / Tirol können jetzt alle Wege gelöscht werden, die noch plan.at als Autor haben, da ich alle sinnvollen schon portiert habe und damit der Autor plan.at ein 100% Schrottkriterium ist (sofern ich nichts übersehen habe). Ein Problem hast du nicht bedacht. Evtl sind andere Wege an den unveränderten Import verbunden worden. Also automatisch alle raushauen ist evtl auch wieder nicht optimal. Aber wenn nun jemand die at:maxspeed raus löscht, dann steht sein User als neuer Autor drinnen und das tolle Filterkriterium ist unbrauchbar geworden. Bitte dies zu beachten, bevor irgendwelche Aktionen gemacht werden. Lg Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-de] Status Fahrradwege-Tags
Also ich sehe auch absolut keinen Bedarf für einen bicycle:trekking oder was auch immer Tag. Der Grund warum es mtb:scale sowie mtb:scale:uphill gibt, ist das Mtbiken einfach keiner anderen Fortbewegungsart direkt entspricht, und es eben Wege gibt, wo ein Wanderer nur auf allen 4en runterkommt, ein technsich versierter Mtbiker aber einfach ein paar Sachen obispringt. Andersrum gibts genug Fälle wo man egal mit welcher Technik am MTB nicht weiterkommt, der Fußgänger aber kein Problem hat. Ich bin allerdings auch schon mit einem Trekkingbike Wege mit mtb:scale=1 gefahren und würde für fast alle ausgeschilderten MTB-Strecken behaupten, dass man da mit einem Trekkingbike besser bedient ist wie mit einem MTB. Eine normale Steintreppe fahre ich auch mit einem Trekkingbike runter - obwohl da ein Großteil der Leute die ein MTB haben, absteigen. Daher bin ich immer froh wenn incline=up/down angegeben ist. Surface als Key sagt in Wirklichkeit so gut wie gar nichts aus. Eine Straße mit riesigen Schlaglöchern, Wurzeln, oder Steinbrocken im Weg weil sie wegen Steinschlag nicht mehr benutzt wird, wäre für mich noch immer surface=asphalt, weil ja 80-90% der Oberfläche noch aus Asphalt bestehen. Surface=wood kann irgendwas bedeuten (von guter Holzbrücke hin zu ein paar Planken die über eine morastige Landschaft geworfen sind). Surface=gravel kann vom normalen Schotterweg hin zu einem kaum mehr begehbaren Trail in den Alpen gehen, da dort Schotter gestreut wurde, damit der Boden nicht weiter erodiert. Für mich macht surface daher nur in Verbindung mit smoothness - oder zur Not mit tracktype Sinn. Surface=paved kann ich sowieso nichts mit anfangen. Ein Klettersteig ist doch auch surface=paved, weil er ganz eindeutig befestigt ist. Tracktype ist für Rennradfahrer oder Inlineskater nicht differenziert genug. Auf Inlinern brauche ich aber keinen eigenen Tag, smothness ist hier perfekt ausreichend da tracktype=grade1 eben mal besser, mal schlechter zum entlangrollen ist. Als klassischer Trekkingradler oder Donauradwegradfahrer reichen mir smoothness und tracktype allemal. Viel größere Probleme bereitet mir hier Verkehr, Ampeln, Stopschilder, parkende Autos, depperte Hunde, spielende Kinder, uneinsichtige Kurven, usw. --- da ich am Trekking oder Rennrad halt gerne 25-35km/h ohne abbremsen und evtl auch am schnellsten Weg fahren möchte. Diese ganzen Gefahrenfaktoren für mich als Radler der nicht bremsen will, wird man kaum objektiv beschreiben können, dafür gibt es zum Glück aber noch class:bicycle womit ich ausdrücken kann wie gut sich ein Weg zum radfahren oder rennradfahren eignet. *Class:bicycle welches überraschenderweise stark benutzt wird, obwohl es kaum erwähnt wird. Dass könnte deine Bedingungen erfüllen.* Bicycle=yes sehe ich generell nur bei highway=pedestrian oder highway=trunk Sinnvoll an. Da ich annehme dass ich hier generell nicht fahren darf. Highway=footway bicycle=yes ist dagegen eh der Normalfall, da footway einfach per se nicht bedeutet, dass nur Fußgänger erlaubt sind. Bicycle=no highway=footway / highway=path ist dagegen leider häufig eben falsch verwendet, weil Leute annehmen hier können keine Fahrradfahrer fahren, anstelle von hier ist explizit ausgeschildert dass Fahrradfahrer nicht lang dürfen. Wo dagegen wirklich noch eine Lücke klafft, sind Einradfahrer. Und damit meine ich jene Einradfahrer die das ganze auch im deutschen Sprachraum als Unicycle bezeichnen, und harte Alpentrails damit befahren. Im Grundsatz reicht für die auch die mtb:scale. Allerdings gibt es halt Stellen wo die mtb:scale für einen Unicyclist die Schwierigkeit übertreibt, da am Unicycle eine Spitzkehre kein Problem ist. Andererseits teils falsch, weil ja ein einfacher Sprung von 5-10m Länge mit einem Unicycle nicht machbar ist, da die Geschwindigkeit die ein Mtbiker hat, nicht aufgebaut werden kann. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
