Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Nop wrote: Die 3 Aussagen stehen einfach im Widerspruch: - designated = exclusive (path Proposal) - footway = mainly (Map Features) - footway == path + foot=designated (Map Features) Im Path-Proposal steht: access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. Dem kann ich nicht entnehmen (und auch keiner anderen Stelle im Proposal), dass designated irgendeine Art von exklusiver Nutzung durch die damit versehene Verkehrsteilnehmergruppe meint. Das Wort exclusive kommt im ganzen Proposal nicht vor. Woher kommt also diese Interpretation? Gruß, Hatto ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
2009/1/23 Frederik Ramm frede...@remote.org Hallo, Guenther Meyer wrote: wenn in deutschland das klassische blaue radweg-schild steht, bedeutet das, dass sich auf diesem weg nur radfahrer bewegen duerfen, da hat kein anderer was zu suchen. das ist eindeutig, und sollte auch so festgehalten werden. Das waere fuer mich ein bicycle=designated. Wenn der Weg so ein horizontal geteilted blaues Fussgaenger/Fahrradfahrer-Schild hat, waere das fuer mich bicycle=designated *und* foot=designated. Man kann also aus bicycle=designated nicht ablesen, dass Fussgaenger nichts darauf zu suchen haben, sondern nur aus bicycle=designated in Kombination mit der Abwesenheit von foot=designated. Die Kombination bicycle=designated und foot=yes kommt glaub ich nicht vor, aber foot=designated und bicycle=yes entspraeche wohl einem weissen Zusatzschild Radfahrer frei. so macht das sinn, ja. :-) ist das auch irgendwo so dokumentiert und auffindbar? Ich dachte immer, das wäre klar ;-) Bye Frederik auffindbar weiss ich nicht (steht das nicht so bei path in der Definition?), aber es ist schon des oefteren auch genau so hier auf der Liste besprochen worden und steht ja auch so im Wiki. Nur weil die Leute die Definitionen nicht genau lesen heisst das noch nicht, dass diese so schlecht sind wie oft behauptet. Gerade durch die Sitte, nochmal und nochmal ne weitere Seite im Wiki mit Auslegungen und Definitonen (auf Deutsch, Italienisch, etc.) zu machen fuehrt im Endeffekt dazu, dass Widersprueche auftreten und das Wiki asynchron aktualisiert wird - man findet einfach nicht alle Stellen, wo evtl. noch was zu einem Thema steht. So gut gemeint solche Seiten wie Taggen in Deutschland, Strassen in Deutschland, das deutsche Strassensystem und sein tagging in OSM, die Verkehrsschilder und ihre Bedeutung korrektes Tagging von Wegen (Namen frei erfunden) im einzelnen sein moegen. Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Guenther Meyer wrote: wenn in deutschland das klassische blaue radweg-schild steht, bedeutet das, dass sich auf diesem weg nur radfahrer bewegen duerfen, da hat kein anderer was zu suchen. das ist eindeutig, und sollte auch so festgehalten werden. Das waere fuer mich ein bicycle=designated. Wenn der Weg so ein horizontal geteilted blaues Fussgaenger/Fahrradfahrer-Schild hat, waere das fuer mich bicycle=designated *und* foot=designated. Man kann also aus bicycle=designated nicht ablesen, dass Fussgaenger nichts darauf zu suchen haben, sondern nur aus bicycle=designated in Kombination mit der Abwesenheit von foot=designated. Die Kombination bicycle=designated und foot=yes kommt glaub ich nicht vor, aber foot=designated und bicycle=yes entspraeche wohl einem weissen Zusatzschild Radfahrer frei. so macht das sinn, ja. :-) ist das auch irgendwo so dokumentiert und auffindbar? Ich dachte immer, das wäre klar ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am 23.01.2009 um 11:32 schrieb Martin Koppenhoefer: Gerade durch die Sitte, nochmal und nochmal ne weitere Seite im Wiki mit Auslegungen und Definitonen (auf Deutsch, Italienisch, etc.) zu machen fuehrt im Endeffekt dazu, dass Widersprueche auftreten und das Wiki asynchron aktualisiert wird - man findet einfach nicht alle Stellen, wo evtl. noch was zu einem Thema steht. Wie löscht man eigentlich Seiten bzw. markiert sie zum Löschen? Eine Konsolidierung ist echt überfällig. Das demonstriert sehr gut die Kategorienliste: http://wiki.openstreetmap.org/wiki/Category: Proposed_features_under_way. Das Straßenverzeichnis einer Nekropolis. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo! Martin Koppenhoefer schrieb: auffindbar weiss ich nicht (steht das nicht so bei path in der Definition?), aber es ist schon des oefteren auch genau so hier auf der Liste besprochen worden und steht ja auch so im Wiki. Nur weil die Leute die Definitionen nicht genau lesen heisst das noch nicht, dass diese so schlecht sind wie oft behauptet. Da muß ich doch widersprechen. Erst mal vorweg: Ich bin exakt Eurer Meinung, daß designated genau so verwendet werden sollte. Allerdings findest Du unter footway und cycleway in den Map Features den Text mainly/exclusively for * und die Definition shortcut for *=designated. Daraus kann ich folgern, designated heißt auch nur mainly. Und damit wird alles wieder verwässert. Leider ist dieser Text auf der Map Features auf top-level verlinkt und das dürfte das sein, was die meisten Neueinsteiger zuerst finden. Die Version im path-proposal habe ich trotz längerer Wikistöbereien nie gefunden. Es wäre mir nie in den Sinn gekommen, daß man längst erledigte Proposals durchforsten muß, weil die Top-Level Hauptreferenzseite falsch ist. Von daher machen es also genau die Leute falsch, _die_ nachlesen. Das Wiki ist schlichtweg widersprüchlich. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Bernd Wurst: Hallo. Am Donnerstag, 22. Januar 2009 schrieb Guenther Meyer: klar, aus der notwendigkeit entsteht irgendwann dann die aktion. dumm halt, dass diese notwendigkeit auf entwicklerseite schon lange vorher bekannt ist, man sich aber zu dem zeitpunkt echt schwer tut, die masse davon zu ueberzeugen. zumindest geht's mir so... Gibt es schon einen Entwickler einer beliebigen Routing-Engine, der ein Statement veröffentlicht hat, welche Abbiegeverbote er in seinem Programm auswerten wird? keine ahnung. routing ist nicht direkt mein thema. ich denke, die meisten versuchen, aus dem vorhandenen erst mal das beste zu machen. ich kann mich aber durchaus erinnern, dass es schonmal vorschlaege von entwicklerseite zum thema highway-tagging gab, was aber nicht wirklich was gebracht hat... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Bernd Wurst: Hallo. Am Donnerstag, 22. Januar 2009 schrieb Guenther Meyer: ich sehe halt durchaus die moeglichkeit folgender situation: es kommt mehrfach vor, dass fussgaenger auf reinen radwegen rumlaufen (oder umgekehrt), und damit die jeweils dort sich legal bewegenden behindern, oder sogar unfaelle provozieren. wenn dann wiederholt als antwort der verursacher sowas kommt wie ...aber mein osm-navi hat mich da hin geschickt..., wird ganz schnell die aussage entstehen dieser osm-sch... osm taugt nicht zum routen Das halte ich für Mumpitz. ist nur ein beispiel das durchaus so passieren koennte... Wenn das so ist, dass ein OSM-Navi einen da lang schicken will und das ist falsch, dann wird sich jemand finden, der ein foot=no da dran pappt. Unabhängig von jeder designated-Diskussion kann man mit foot=no nämlich genau das sagen. naja, ein kennzeichnen als radweg sollte das eigentlich implizieren... Dazu bemerkt finde ich dass wir im falschen Jahrzehnt sind um uns über sowas Gedanken zu machen. Wann kommt denn die Situation, dass innerhalb einer Woche auf einer bestimmten Straße mehr als 2 Leute mit einem (selbstständig routenden) Fahrrad-Navi entlang fahren? wer sagt, dass das nicht passieren kann? man macht keine radikale aenderung, sondern man bietet eine (wahrscheinlich) bessere moeglichkeit an, und hofft, dass sie verwendet wird. so funktioniert das doch bei osm? oder hab ich da schon wieder was falsch verstanden? Man sollte halt irgendwelche Schritte unternehmen (z.B. besonders cooles Rendering, Auswertung in einem Navi) um einen großen Teil der Mapper davon zu überzeugen dass mit dem neueren Tag besser gemappt werden kann. leider hat nicht jeder, der ideen hat, die moeglichkeit, das an den entsprechenden orten zu aendern... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Zitat Guenther Meyer: [...] ich sehe halt durchaus die moeglichkeit folgender situation: es kommt mehrfach vor, dass fussgaenger auf reinen radwegen rumlaufen (oder umgekehrt), und damit die jeweils dort sich legal bewegenden behindern, oder sogar unfaelle provozieren. wenn dann wiederholt als antwort der verursacher sowas kommt wie ...aber mein osm-navi hat mich da hin geschickt..., wird ganz schnell die aussage entstehen dieser osm-sch... osm taugt nicht zum routen natuerlich kann osm nicht verantwortlich fuer das verkehrswidrige verhalten seiner nutzer gemacht werden, aber fuer das image ist das trotzdem nicht gut... Fuer wessen Image? Fuer OSM oder fuer all die anderen Karten, die Anwender jetzt schon immer mal wieder in die Wallachei schicken? Und bei wem? Bei Leuten, die regelmaessig Brain1.0 ausschalten, sobald sie ein Navi einschalten? Geschenkt, ich habe kein Mitleid mit Leuten, die in die Elbe fahren, weil ihr Navi faelschlicherweise dort eine Bruecke anzeigt. Und ganz bestimmt verschwende ich kein Gran Energie daran, idiotensichere Loesungen mit zu gestalten. Denn es steht geschrieben, mache etwas idiotensicher und die Natur wird einen noch groesseren Idioten hervor bringen. [...] -- Michael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Donnerstag, 22. Januar 2009 schrieb Guenther Meyer: keine ahnung. routing ist nicht direkt mein thema. ich denke, die meisten versuchen, aus dem vorhandenen erst mal das beste zu machen. ich kann mich aber durchaus erinnern, dass es schonmal vorschlaege von entwicklerseite zum thema highway-tagging gab, was aber nicht wirklich was gebracht hat... Ich kann mich an jemanden erinnern, der meinte wenn wir nicht hieb- und stichfeste Regeln haben was z.B. ein secondary ist und wie schnell man darauf fahren kann, dann wird kein routing möglich sein. Solche Aussagen, siehe Frederiks Mail, sind selbstdisqualifizierend weil es eben doch geht. Abbiegeverbote sind aber z.B. etwas wo sich erstaunlich viele Leute noch gar nicht mit dem Proposal (no_right_turn) anfreunden können und was daher gar nicht so üppig genutzt wird. Es ist also fraglich, ob man das wirklich schon als existent ansehen will. Wenn jetzt Pascal Neis etwas der Art sagt: Ich möchte Abbiegeverbote in openrouteservice unterstützen, dazu habe ich folgende Tagging-Konvention überlegt: ... Ab sofort kann werden Abbiegeregeln nach obigem Schema beachtet, für eine Kreuzung habe ich das schonmal beispielhaft eingearbeitet, sehr hier ... dass das funktioniert. Dann glaube ich, dass es *sehr* schnell gehen wird bis in D alle bisherigen Abbiegeverbte auf das vorgeschlagene Schema umgestellt werden. Ohne bot sondern jeweils von den lokalen Mappern. Gruß, Bernd -- The hardness of the butter is proportional to the softness of the bread. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Donnerstag, 22. Januar 2009 schrieb Guenther Meyer: Wenn das so ist, dass ein OSM-Navi einen da lang schicken will und das ist falsch, dann wird sich jemand finden, der ein foot=no da dran pappt. Unabhängig von jeder designated-Diskussion kann man mit foot=no nämlich genau das sagen. naja, ein kennzeichnen als radweg sollte das eigentlich implizieren... Wenn es das aber in einem verbreiteten Navi nicht tut (weil es wohl doch nicht so eindeutig ist) dann ist die Definition dass es das impliziert eben die Arbeit eines Schreibtischtäters und scheinbar nicht praxistauglich. Dazu bemerkt finde ich dass wir im falschen Jahrzehnt sind um uns über sowas Gedanken zu machen. Wann kommt denn die Situation, dass innerhalb einer Woche auf einer bestimmten Straße mehr als 2 Leute mit einem (selbstständig routenden) Fahrrad-Navi entlang fahren? wer sagt, dass das nicht passieren kann? Ich meine nicht, dass das nicht passieren kann. Aber es passiert einfach selten weil selbst-routende Fahrradnavis momentan nicht wirklich verbreitet sind. Liegt vielleicht daran, dass die meisten Fahrradfahrer entweder sich auf ihrer Strecke auskennen (zur Schule/Arbeit fahren) und Touren-Radler sich die Strecke zu Hause in Ruhe anhand von nicht-algorithmischen Rahmenbedingungen aussuchen (Landschaft, Freunde besuchen, ...) und dann als route in ihr GPS laden. Ich halte Fahrradnavigation mit den aktuellen technischen Möglichkeiten für völlig überschätzt. Es sollte langfristig irgendwie funktionieren, keine Frage! Aber dann muss es ja nicht jedes Detail kennen sondern soll mich einfach nur z.b. zu nem gegebenen Hotel führen und dabei Schnellstraßen meiden und Fahrradwege durch den Park bitte benutzen. Zudem: Es gibt bisher nicht viele (selbst-routende) Navis, die Akku-mäßig ne lange Radtour durchhalten und Speisung per Dynamo ist auch nicht im Sinne der Radler. ;-) Wenn z.B. hier jemand sagt, dass er Straßen mit benutzungspflichtigen Radwegen meiden will weil ein Fahrradfahrer in Normalgeschwindigkeit dort mehr Gefahren ausgesetzt ist, dann glaube ich kaum, dass er bei solchen Fahrten ein Navi bräuchte. leider hat nicht jeder, der ideen hat, die moeglichkeit, das an den entsprechenden orten zu aendern... Versteh ich jetzt nicht. Entweder man will genauere Tags, hat sich überlegt wofür man die jetzt braucht und wann das bisherige Schema nicht klappt, dann kann man zumindest versuchen an der Stelle an der es mit dem alten Schema Probleme gibt, die Umsetzung des neuen Schemas zu erreichen (aktiv oder durch Kommunikation mit dem Entwickler) oder man ist Theoretiker, überlegt sich ganz viel Krams, den (aktuell) keiner braucht und schmollt wenn es keinen interessiert was man da vorschlägt. Gruß, Bernd -- Mit einem kurzen Schweifwedeln kann ein Hund mehr Gefühl ausdrücken als mancher Mensch mit stundenlangem Gerede - Louis Armstrong (am. Musiker) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Bernd Wurst: Hallo. Am Donnerstag, 22. Januar 2009 schrieb Guenther Meyer: Wenn das so ist, dass ein OSM-Navi einen da lang schicken will und das ist falsch, dann wird sich jemand finden, der ein foot=no da dran pappt. Unabhängig von jeder designated-Diskussion kann man mit foot=no nämlich genau das sagen. naja, ein kennzeichnen als radweg sollte das eigentlich implizieren... Wenn es das aber in einem verbreiteten Navi nicht tut (weil es wohl doch nicht so eindeutig ist) dann ist die Definition dass es das impliziert eben die Arbeit eines Schreibtischtäters und scheinbar nicht praxistauglich. sowas scheint aber in osm desoefteren vorzukommen... im endeffekt laueft es immer wieder auf das grundlegende problem zurueck: viele tags sind sind zu ende gedacht, d.h. nicht exakt definiert. man sie auf auf verschiedene arten verwenden und auswerten. wenn nun ein tag von einem router auf andere weise ausgelegt wird, als es sich der jeweilige mapper beim eintragen gedacht hat (einfach weil es die definiton erlaubt), dann ensteht ein fehler. Ich meine nicht, dass das nicht passieren kann. Aber es passiert einfach selten weil selbst-routende Fahrradnavis momentan nicht wirklich verbreitet sind. das kann und wird sich aendern. ich gehe nicht davon aus, dass osm nicht mehr existiert, wenn es mal soweit ist. Ich halte Fahrradnavigation mit den aktuellen technischen Möglichkeiten für völlig überschätzt. Es sollte langfristig irgendwie funktionieren, keine Frage! Aber dann muss es ja nicht jedes Detail kennen sondern soll mich einfach nur z.b. zu nem gegebenen Hotel führen und dabei Schnellstraßen meiden und Fahrradwege durch den Park bitte benutzen. nicht jedes detail. aber das was verzeichnet ist, sollte einigermassen eindeutig auswertbar sein, und nicht (wie bei dieser designated-sache) auf zwei total unterschiedliche arten interpretiert werden koennen. sowas sagt mir, dass die definiton nicht eindeutig geschrieben wurde. leider hat nicht jeder, der ideen hat, die moeglichkeit, das an den entsprechenden orten zu aendern... Versteh ich jetzt nicht. Entweder man will genauere Tags, hat sich überlegt wofür man die jetzt braucht und wann das bisherige Schema nicht klappt, dann kann man zumindest versuchen an der Stelle an der es mit dem alten Schema Probleme gibt, die Umsetzung des neuen Schemas zu erreichen (aktiv oder durch Kommunikation mit dem Entwickler) oder man ist Theoretiker, überlegt sich ganz viel Krams, den (aktuell) keiner braucht und schmollt wenn es keinen interessiert was man da vorschlägt. manche leute koennen anderen jeden schrott andrehen und leute davon ueberzeugen, ihnen zu helfen, andere haben durchdachte loesungen, koennen diese aber nicht an den mann bringen. leider gehoere ich meist zu letzteren... darum waere der andere weg, das ganze zu demonstrieren. dies nur an einer ecke zu tun, hat nicht viel effekt; wenn, dann muss es richtig gemacht werden. das wuerde in meinem fall heissen, mein poi-schema durchgaengig zu integrieren, und zwar in osmarender, mapnik, josm (siehe vision), potlatch, usw. technisch durchaus machbar, zeitlich leider nicht. drum bleib ich in meiner ecke, wo ich eindeutig sehe, dass es funktioniert, und verschwende die zeit mit kovertierungsroutinen... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Michael Buege: Zitat Guenther Meyer: [...] ich sehe halt durchaus die moeglichkeit folgender situation: es kommt mehrfach vor, dass fussgaenger auf reinen radwegen rumlaufen (oder umgekehrt), und damit die jeweils dort sich legal bewegenden behindern, oder sogar unfaelle provozieren. wenn dann wiederholt als antwort der verursacher sowas kommt wie ...aber mein osm-navi hat mich da hin geschickt..., wird ganz schnell die aussage entstehen dieser osm-sch... osm taugt nicht zum routen natuerlich kann osm nicht verantwortlich fuer das verkehrswidrige verhalten seiner nutzer gemacht werden, aber fuer das image ist das trotzdem nicht gut... Fuer wessen Image? Fuer OSM oder fuer all die anderen Karten, die Anwender jetzt schon immer mal wieder in die Wallachei schicken? osm. es wird immer als hobbyprojekt sog. professionellen produkten gegenueber stehen. da sollte es doch besser sein, negative kritiken (die die anderen natuerlich auch ernten), schon im vorfeld zu vermeiden. Und bei wem? Bei Leuten, die regelmaessig Brain1.0 ausschalten, sobald sie ein Navi einschalten? von denen es in der generation doof immer mehr gibt... Geschenkt, ich habe kein Mitleid mit Leuten, die in die Elbe fahren, weil ihr Navi faelschlicherweise dort eine Bruecke anzeigt. Und ganz bestimmt verschwende ich kein Gran Energie daran, idiotensichere Loesungen mit zu gestalten. Denn es steht geschrieben, mache etwas idiotensicher und die Natur wird einen noch groesseren Idioten hervor bringen. ganz klar. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Das Hauptproblem dabei war, dass die Proponenten dieses ganzen Proposals sich anmassen wollten, aufgrund der paar Stimmen, die da so zusammenkommen, die ganze Datenbank weltweit zu aendern und ueber den Haufen zu werfen, woran sich haufenweise Leute gewoehnt hatten. Da ist meiner Meinung nach einfach politisch sehr unklug vorgegangen worden - da waren vielleicht auch Leute dabei, die dachten, vote ist vote und wer sich nicht beteiligt der hat halt auch kein Mitspracherecht oder so. Am Ende kam es zu einer Abstimmung mit recht hoher Beteiligung fuer OSM-Verhaeltnisse, in der das path-Proposal grundsaetzlich angenommen, die Abloesung von cycleway/footway aber abgelehnt wurde: Einen Tag aufgrund eines Abstimmungsergebnisses komplett durch ein anderes zu ersetzen, halte ich auch nicht für sinnvoll. Das kann jeder Mapper so annehmen oder nicht wie er will. Solche Sprueche gehen bei mir zu einem Ohr rein und zum andern wieder raus. Das kommt hier auf der Liste einmal im Monat: Wenn sich dies und das nicht aendert, wird dies und jenes nie moeglich sein. - Meist geht es dann eben doch irgendwie, zwar nur mit einer 80%-Loesung, aber dafuer ohne gleich eine Revolution anzuzetteln. Ich kann natürlich nicht für andere sprechen, aber ich möchte keine Revolution anzetteln, sondern es schrittchenweise verbessern. Mein Vorschlag in der ersten Mail mit den Proposals spiegelt eigentlich auch das wider, was zur Zeit schon Praxis ist (Proposal zum disktuieren und Vorschläge erarbeiten). Nur mit dem Unterschied, wie man entscheidet was in die Map Features kommt. Das was du geschrieben hast, dass es reicht einen guten Grund zu haben, das ist ja schon eine Regel. Ich bin auch erst mal auf den scheinbare definierten Prozeß reingefallen, und hab ein aufwändiges Proposal ausgearbeitet. Erschien mir auch sinnvoll, um die Sache möglichst deutlich darzulegen. Jetzt hör' ich daß ein Proposal mit erfolgreicher Diskussion und Vote auch nix bringt. Das ist m.E. so ein typischer Anfaengerfehler: 1. Du stellst fest, dass Du gern etwas ausdruecken moechtest, wofuer es aber kein etabliertes Schema gibt. 2. Du nimmst an, dass es vielen anderen genauso geht, und dass lediglich keiner von denen bislang die Musse oder den Eifer oder die Intelligenz besass, ein Schema aufzustellen und zu etablieren. 3. Du machst Dir die Muehe und wunderst Dich, dass es relativ wenige Leute interessiert. Es ist ja nicht so, dass es nichts bringt. Aber zu dem Konzept gehoeren eben auch die Leute, denen es ein Anliegen ist, diese Information zu erfassen. Und gaebe es derer viele, so haette sich auch schon eine Methode etabliert. Die Annahme, dass die Welt nur auf das Proposal gewartet hat, ist also oft nicht gerechtfertigt. Man geht eben mit Begeisterung an etwas ran und will es besser machen. Daran ist ja nichts falsch. Der Anfängerfehler liegt aber auch in der durch die Dokumentation im Wiki begründete weit verbreiteten Annahme, dass ein Proposal etwas 'formales' ist und der einzige Weg etwas vorzuschlagen. Vielleicht ist es für alte Hasen die schon ewig dabei sind anders, aber als Anfänger muss man sich eben auf das verlassen was im Wiki steht oder was andere einem sagen. Grundsaetzlich ist ein Proposal der Art ich tagge auf diese und jene Weise, und damit habe ich gute Erfahrungen gemacht und nun kann ich diese coole Applikation hier nutzen viel ueberzeugender als ein aeh, also, ich koennte mir vorstellen dass es cool waere wenn wir alle in Zukunft auf diese und jene Weise taggen würden, dann könnte irgendjemand bestimmt auch mal eine coole Applikation schreiben Leichter gesagt als getan, wenn man als Nicht-Programmierer etwas beitragen will. Dann kann man eben nur sagen Ich tagge auf diese und jene Weise und damit habe ich gute Erfahrungen gemacht.. Ist ist man kein Macher wenn man gewissenhaft Vorschläge ausarbeitet, disktutiert und vorstellt? Man handelt doch, statt nur zu sagen Ich fände es besser wenn das anders wäre, ändert da mal was.. Wenn man nur als Programmierer ein Macher sein kann, dann ist das natürlich schade. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Dirk Stöcker schrieb: Der andere Weg ist, dass Nummer zwei ein tolles FeatureX-Proposal schreibt und darin darlegt, wie er 100 Elemente eingetragen hat, dass außerdem Du und noch 10 andere jeweils 100 Elemente haben und das man das doch zusammenlegen kann. Dann werden die meisten der Betroffenen versuchen einige Einigung zu erzielen, welche ein Kompromiss ist. Ich hab ja auch geschrieben Ich tagge auf diese und jene Weise und damit habe ich gute Erfahrungen gemacht.. Das setzt ja vorraus, dass man es auch in der Praxis ausprobiert hat. Trotzdem ist es schon so, dass meistens gleich Code gefordert wird, wenn man einen Vorschlag macht. Und unnötigerweise werden Vorschläge auch gerne als Forderung angesehen, auch wenn sie nicht so gemeint sind. Wenn keiner den Vorschlag aufnimmt da er keine Lust hat das umzusetzen, hat man eben Pech gehabt. Aber diese Reflexreaktion wo ist der Code? oder dann setz eben einen eigenen Renderer auf führt doch auch nur zu Missmut. Das bezieht sich natürlich nicht auf dich sondern ist allgemein gemeint. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Wie bekommst du heraus was sich am Ende durchsetzt? Die Bedeutung eines Tags kann man nicht in den Daten ablesen. Abstimmungen sind nicht repräsentativ, das Meinungsbild hier in der Liste oder im Forum repräsentiert auch nicht alle Mapper. natuerlich geht das. man schaut einfach in der datenbank nach, was fuer einen bestimmten fall amn meisten benutzt wird. Dann musst du aber für jeden Fall hingehen und schauen wie es in der Realität aussieht. ach so, du meintest bedeutung im sinne von definition, und nicht die wichtigkeit. hab das jetzt in dem kontext anders verstanden... Achso. Da sieht man mal, dass auch unsere normale Sprache oft missverständlich sein kann.. ;) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
You are not allowed to post to this mailing list, and your message has been automatically rejected. If you think that your messages are being rejected in error, contact the mailing list owner at talk-de-ow...@openstreetmap.org. Betreff: Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess Von: Klaus Gaßner k_gass...@web.de Datum: Thu, 22 Jan 2009 10:10:49 +0100 An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Hallo! Frederik Ramm schrieb: Ekkehart wrote: (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) Nur so aus Neugierde: Welche Stelle zitierst Du da? Die habe ich glaub ich bisher noch nicht gefunden. Die ist aus dem Path-Proposal, dessen URL ich weiter oben genannt hatte: Dann war das wohl bei path so gedacht, wie ich das auch verstehe, kam aber durch die Verquickung mit footway und cycleway nicht das raus, was gmeint war. Die 3 Aussagen stehen einfach im Widerspruch: - designated = exclusive (path Proposal) - footway = mainly (Map Features) - footway == path + foot=designated (Map Features) Und nachdem die unterschiedlichen Meinungen so heftig vertreten werden, dürfte eine Korrektur des Wikis einen Aufstand auslösen, da es die traditionellen Tags footway und cycleway umdefiniert. http://wiki.openstreetmap.org/wiki/Approved_features/Path Dann laß es mich anders formulieren: Kannst Du Dir eine technische Lösung vorstellen, wie man eine Routenführung auf dieses Tagging stützt, wenn designated in 50% der Fälle bedeutet: verpflichtend für die einen, verboten für die anderen und in den anderen 50%: für die einen vorgesehen, aber vielleicht genausogut für andere benutzbar und man keine Möglichkeit hat, den Unterschied festzustellen? Ich wuerde das dem User der Software ueberlassen. Der soll ankreuzen, was er will. Gerade Fahrrad- und Fussgaengerrouting wird kaum jemand von Berlin nach Muenchen betreiben wollen - das ist eine lokale Sache, und ich gehe davon aus, dass lokal - wo die Leute sich auch mal bei Stammtischen treffen usw. - eher Einigkeit herrscht als national oder gar international. Es kommt dann halt dazu, dass man in Muenchen eventuell ein andres Haekchen setzen muss als in Berlin. Aber auch das ist weniger wild und zumindest fuer eine Uebergangszeit tolerierbar, finde ich. Wie gesagt: Bei meiner Auswertung hatte ich die Regeln frei die ich anwende. Bei exakter Lesart kommt aber nur Murks raus, weil 75% der Wege, die dann als verboten gelten (weil jemand anders gewidmet) in der Realität nicht mit einem gesetzlichen Kennzeichen versehen sind. Meine Erkenntnis ist: Egal wie Du Deine Einstellung wählst, Du wirst feststellen daß Dich Dein Router verarscht. Es handelt sich auch nicht um eine lokale Spezialiät, die Uneinigikeit herrschte am lokalen Stammtisch genauso wie auf der bundesweiten Mailingliste. Ich bin ueberdies der Ansicht, dass das mit dem verpflichtend und verboten total ueberbewertet wird. Ich hab' mich da meinen Lebtag noch nicht drum gekuemmert - ich fahre und laufe da, wo es mir geeignet erscheint... ja, klar, es gibt Anwedungsfaelle. Aber es ist keinesfalls so, dass jeder, der ein Fahrrad benutzt, sich dafuer interessieren muss, wo jetzt eine Radwegbenutzungspflicht ist. Ich bin froh, wenn ein Router mich nicht ueber eine Autobahn schickt und mir gute Schleichwege aufzeigt, auf die ich sonst nicht gekommen waere. Es ist klar, daß es jedem selber überlassen ist, was er draus macht, aber deshalb sollte die Karte doch trotzdem korrekt sein. Ich meine, ich fahre auch regelmäßig zu schnell mit dem Auto und wenn nachts kein anderes Auto da ist, kann es auch sein, daß ich mal abbiege wo es nicht erlaubt ist. Trotzdem werde ich die Höchstgeschwindkeit und die Abbiegeverbote nach den Schildern taggen, nicht nach dem was ich an dieser Stelle fahre. Mir ist noch immer nicht ganz klar, um welche konkrete Kontroverse es hier eigentlich geht. Die ausführliche Version ist im Proposal nachzulesen [1] Ach so, ich dachte, es haette was mit dem Proposal von Sebastian zu tun. Kernidee ist die: - Es gibt eine Fraktion, für die designated bedeutet: Gesetzlich gewidmet - Es gibt eine Fraktion, für die designated bedeutet: In irgendeiner Form dafür vorgesehen oder vermutlich dafür vorgesehen Ich sehe den Unterschied nicht so ganz. Wer sonst ausser dem Erbauer kann einen Weg denn fuer etwas vorsehen, und an was ausser dem Gesetz wird sich der Erbauer dabei halten? Und das mit dem vermutlich ist was, was Du ueberall hast - fast alles, was in OSM getaggt wird, hat irgendwo diese vermutlich-Einschraenkung. Wir sind ja nicht
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo! Frederik Ramm schrieb: (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) Nur so aus Neugierde: Welche Stelle zitierst Du da? Die habe ich glaub ich bisher noch nicht gefunden. Die ist aus dem Path-Proposal, dessen URL ich weiter oben genannt hatte: Dann war das wohl bei path so gedacht, wie ich das auch verstehe, kam aber durch die Verquickung mit footway und cycleway nicht das raus, was gmeint war. Die 3 Aussagen stehen einfach im Widerspruch: - designated = exclusive (path Proposal) - footway = mainly (Map Features) - footway == path + foot=designated (Map Features) Und nachdem die unterschiedlichen Meinungen so heftig vertreten werden, dürfte eine Korrektur des Wikis einen Aufstand auslösen, da es die traditionellen Tags footway und cycleway umdefiniert. http://wiki.openstreetmap.org/wiki/Approved_features/Path Dann laß es mich anders formulieren: Kannst Du Dir eine technische Lösung vorstellen, wie man eine Routenführung auf dieses Tagging stützt, wenn designated in 50% der Fälle bedeutet: verpflichtend für die einen, verboten für die anderen und in den anderen 50%: für die einen vorgesehen, aber vielleicht genausogut für andere benutzbar und man keine Möglichkeit hat, den Unterschied festzustellen? Ich wuerde das dem User der Software ueberlassen. Der soll ankreuzen, was er will. Gerade Fahrrad- und Fussgaengerrouting wird kaum jemand von Berlin nach Muenchen betreiben wollen - das ist eine lokale Sache, und ich gehe davon aus, dass lokal - wo die Leute sich auch mal bei Stammtischen treffen usw. - eher Einigkeit herrscht als national oder gar international. Es kommt dann halt dazu, dass man in Muenchen eventuell ein andres Haekchen setzen muss als in Berlin. Aber auch das ist weniger wild und zumindest fuer eine Uebergangszeit tolerierbar, finde ich. Wie gesagt: Bei meiner Auswertung hatte ich die Regeln frei die ich anwende. Bei exakter Lesart kommt aber nur Murks raus, weil 75% der Wege, die dann als verboten gelten (weil jemand anders gewidmet) in der Realität nicht mit einem gesetzlichen Kennzeichen versehen sind. Meine Erkenntnis ist: Egal wie Du Deine Einstellung wählst, Du wirst feststellen daß Dich Dein Router verarscht. Es handelt sich auch nicht um eine lokale Spezialiät, die Uneinigikeit herrschte am lokalen Stammtisch genauso wie auf der bundesweiten Mailingliste. Ich bin ueberdies der Ansicht, dass das mit dem verpflichtend und verboten total ueberbewertet wird. Ich hab' mich da meinen Lebtag noch nicht drum gekuemmert - ich fahre und laufe da, wo es mir geeignet erscheint... ja, klar, es gibt Anwedungsfaelle. Aber es ist keinesfalls so, dass jeder, der ein Fahrrad benutzt, sich dafuer interessieren muss, wo jetzt eine Radwegbenutzungspflicht ist. Ich bin froh, wenn ein Router mich nicht ueber eine Autobahn schickt und mir gute Schleichwege aufzeigt, auf die ich sonst nicht gekommen waere. Es ist klar, daß es jedem selber überlassen ist, was er draus macht, aber deshalb sollte die Karte doch trotzdem korrekt sein. Ich meine, ich fahre auch regelmäßig zu schnell mit dem Auto und wenn nachts kein anderes Auto da ist, kann es auch sein, daß ich mal abbiege wo es nicht erlaubt ist. Trotzdem werde ich die Höchstgeschwindkeit und die Abbiegeverbote nach den Schildern taggen, nicht nach dem was ich an dieser Stelle fahre. Mir ist noch immer nicht ganz klar, um welche konkrete Kontroverse es hier eigentlich geht. Die ausführliche Version ist im Proposal nachzulesen [1] Ach so, ich dachte, es haette was mit dem Proposal von Sebastian zu tun. Kernidee ist die: - Es gibt eine Fraktion, für die designated bedeutet: Gesetzlich gewidmet - Es gibt eine Fraktion, für die designated bedeutet: In irgendeiner Form dafür vorgesehen oder vermutlich dafür vorgesehen Ich sehe den Unterschied nicht so ganz. Wer sonst ausser dem Erbauer kann einen Weg denn fuer etwas vorsehen, und an was ausser dem Gesetz wird sich der Erbauer dabei halten? Und das mit dem vermutlich ist was, was Du ueberall hast - fast alles, was in OSM getaggt wird, hat irgendwo diese vermutlich-Einschraenkung. Wir sind ja nicht die Wikipedia, wo ploetzlich an jedem highway=secondary ein * citation needed dransteht und man erst auf die entsprechende amtliche Publikation verweisen muss ;-) Genau da liegt das Problem. Du gehörst zur exakten Fraktion und kannst nicht verstehen, wie man das anders interpretieren kann. Ist ja völlig logisch und war auch so im path proposal gemeint. Genau so ging es mir anfangs auch. Aber in den ganzen Diskussionen habe ich die gegensätzliche
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Bernd Wurst schrieb: Man kann mit OSM-Daten momentan (wirklich, real, gibt es schon, ist nicht nur ein Hirngespinst): * allgemeine Karten malen * Spezialkarten malen (Fahrradkarten, Wanderkarten, ...) * Routen finden * ein richtiges Auto-Navi füttern * Orte finden * POIs (Parkplätze, Museen, ...) finden und bestimmt noch viel, viel mehr was ich selbst gar nicht mitbekommen habe. Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Nein. Die meisten derzeitigen Anwendungen werten nur einfache Dinge aus, bei denen man mit ungefähren Infos zurechtkommt. Gerade bei Verkehrsregeln (- Routing) geht das aber schwerer. Bei mir in der Gegend wechselte zumindest vor kurzem noch die Interpretation, ob ein motorway_link oneway=yes impliziert oder nicht, von Autobahnausfahrt zu Autobahnausfahrt, und ich glaube nicht, dass das ein lokal begrenztes Problem ist. Und zweitens wurde fast alles, was derzeit mit OSM-Daten arbeitet, von Insidern geschrieben. Wir haben keinerlei Dokumentation, die es irgendeinem Navihersteller, externen Softwareentwickler o.ä. erlauben würde, zuverlässige Anwendungen zu erstellen. Wer etwa glaubt, dass die Daten sich ans Wiki halten, wird einen grandiosen Reinfall erleben. Da setzen selbst JOSM-Presets undokumentierte Tags (aktuell -- aber seit r666: farmland statt farm), es wird im Wiki an einer Stelle empfohlen, Fahrzeugverbote mit access=no zu kennzeichnen, anderswo im Wiki wird dafür vehicle statt access genannt, weil access schließlich auch Fußgänger, Pferde usw. einschließt. Ob motorcar nun =PKW ist oder für alle motorisierten Fahrzeuge steht (wofür aber auch motorized_vehicle erwähnt wird) ist auch nicht so klar... Tagging nach Gefühl mag ok sein für die vielen Dinge, die in der Realität auch nicht so scharf zu fassen sind. Ein Verkehrsschild gehört da m.E. aber nicht dazu. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Moin, Hier in Karlsruhe hatten wir anfangs, also ganz zu Anfang, die Situation, dass selbst vollwertige Strassen z.T. als Cycleway getaggt waren - weil der, der sie erfasst hat (hallo Christoph ;-)) halt mit dem Rad da langfuhr und manchmal am Ende eines Tags auch nicht mehr 100% sicher war - das einzige, was er wusste, war: Ich bin mit dem Rad da lang, als war es *mindestens* ein Cycleway. Als dann mehr Autofahrer dazu kamen, hat sich das aber langsam aufgeloest. wenn man wie ich seinerzeit das Glück hat, in völlig unbeackertem Gebiet unterwegs sein zu können, ist das eine dufte Sache. Mir war die Information hier kann man zumindest mit dem Rad lang wichtiger als ich muss hier alles gleich von Anfang an richtig machen, inklusive der Kanaldeckel, oder es ganz bleiben lassen. Ich war 'grad in Polen unterwegs (ja ja, man muss inzwischen schon ziemlich weit fahren, um in Ruhe mappen zu können ;-), wo es noch recht mau aussieht. Dort kommt man noch heute an Mappings vorbei, wo halt jemand langgekommen ist und einfach mal irgendeinen Weg angelegt hat. Ist doch super, ich füge meinen Teil hinzu und verbessere das Existierende. Cheers, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Tobias Knerr: Bernd Wurst schrieb: Man kann mit OSM-Daten momentan (wirklich, real, gibt es schon, ist nicht nur ein Hirngespinst): * allgemeine Karten malen * Spezialkarten malen (Fahrradkarten, Wanderkarten, ...) * Routen finden * ein richtiges Auto-Navi füttern * Orte finden * POIs (Parkplätze, Museen, ...) finden und bestimmt noch viel, viel mehr was ich selbst gar nicht mitbekommen habe. Ist das nicht Beweis genug dass es doch irgendwie funktioniert? du schreibst es ja selbst: irgendwie. natuerlich geht das irgendwie. ist auch toll, dass schon mal was geht. aber ohne genaue definition, was denn die daten nun eigentlich bedeuten, wird man frueher oder spaeter an grenzen stossen. wenn dann naemlich mal der punkt kommt, dass eine kritische masse dies bemerkt, dann haben wir eine datenbank voll mit schwammigen elementen. dann heisst es, auf basis eines besseren modells neu zu mappen, was ein ganzer haufen arbeit ist, den man sich sparen koennte, wuerde man gleich was richtiges entwickeln. ich behaupte ja nicht, dass das dann der weisheit letzter schluss sein muss, aber definierte tags sind mir dann doch lieber als solche, die auf drei total unterschiedliche arten ausgelegt werden koennen... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Frederik Ramm: Jetzt stehen wir da und haben das designated, das in Zusammenhang mit cycleway/footway wenig Sinn macht und hauptsaechlich Verwirrung stiftet und irgendwie doch nicht genau das ist, was die Leute wollen. (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) was ist daran eindeutig? it may... wenn in deutschland das klassische blaue radweg-schild steht, bedeutet das, dass sich auf diesem weg nur radfahrer bewegen duerfen, da hat kein anderer was zu suchen. das ist eindeutig, und sollte auch so festgehalten werden. aber ein tag das sagt, ja mei, des is zwar fuer die radler gedacht, aber was genaueres wissen wir aa net..., macht nixht wirklich viel sinn... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hi, Guenther Meyer wrote: (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) was ist daran eindeutig? it may... Da steht: Die genaue Bedeutung von access=designated ist von Land zu Land unterschiedlich. Es kann zum Beispiel ... bedeuten. Da steht nicht: Innerhalb des gleichen Landens kann access=designated mal dies und mal jenes bedeuten. wenn in deutschland das klassische blaue radweg-schild steht, bedeutet das, dass sich auf diesem weg nur radfahrer bewegen duerfen, da hat kein anderer was zu suchen. das ist eindeutig, und sollte auch so festgehalten werden. Das waere fuer mich ein bicycle=designated. Wenn der Weg so ein horizontal geteilted blaues Fussgaenger/Fahrradfahrer-Schild hat, waere das fuer mich bicycle=designated *und* foot=designated. Man kann also aus bicycle=designated nicht ablesen, dass Fussgaenger nichts darauf zu suchen haben, sondern nur aus bicycle=designated in Kombination mit der Abwesenheit von foot=designated. Die Kombination bicycle=designated und foot=yes kommt glaub ich nicht vor, aber foot=designated und bicycle=yes entspraeche wohl einem weissen Zusatzschild Radfahrer frei. Naja, aber dass *fuer mich* alles klar ist, hilft Dir vermutlich wenig. Wer moechte denn meiner o.g. Darstellung widersprechen? Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Freitag 23 Januar 2009 schrieb Frederik Ramm: Hi, Guenther Meyer wrote: (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) was ist daran eindeutig? it may... Da steht: Die genaue Bedeutung von access=designated ist von Land zu Land unterschiedlich. Es kann zum Beispiel ... bedeuten. Da steht nicht: Innerhalb des gleichen Landens kann access=designated mal dies und mal jenes bedeuten. ok. gut. dann sollte aber die jeweilige bedeutung fuer das entsprechende land auch irgendwo festgehalten werden, um den interpretationsspielraum zu minimieren. wenn in deutschland das klassische blaue radweg-schild steht, bedeutet das, dass sich auf diesem weg nur radfahrer bewegen duerfen, da hat kein anderer was zu suchen. das ist eindeutig, und sollte auch so festgehalten werden. Das waere fuer mich ein bicycle=designated. Wenn der Weg so ein horizontal geteilted blaues Fussgaenger/Fahrradfahrer-Schild hat, waere das fuer mich bicycle=designated *und* foot=designated. Man kann also aus bicycle=designated nicht ablesen, dass Fussgaenger nichts darauf zu suchen haben, sondern nur aus bicycle=designated in Kombination mit der Abwesenheit von foot=designated. Die Kombination bicycle=designated und foot=yes kommt glaub ich nicht vor, aber foot=designated und bicycle=yes entspraeche wohl einem weissen Zusatzschild Radfahrer frei. so macht das sinn, ja. :-) ist das auch irgendwo so dokumentiert und auffindbar? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. Die Admins und Programmierer treffen natürlich Entscheidungen bezüglich der Websites, der API (wie läuft das eigentlich?) oder der Anwendungen rund um OSM. Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Im Moment scheint es mir eher so, dass es für alles einen eher schwammigen Konsens gibt, aber weniger klare (dokumentierte) Regeln. ja, leider. ein altes thema, das immer wieder mal aufgewaermt wird. ich bin ja auch der meinung, dass genaue definitionen und richtlinien viele dinge einfacher machen wuerden und auch einen ganzen haufen unnoetiger arbeit ersparen koennten. eine erweiterbarkeit muss sowas dennoch nicht ausschliessen. du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sven Anders: Der/Die Entwickler von GPSDrive haben sowas auch mal gemacht, da fangen die tags mit poi an (weiß nicht ob das noch aktuell ist). das ist immer noch aktuell, ja ;-) ich bin grad dabei, das ganze fuer unser kommendes release zu ueberarbeiten. vielleicht schaff ich's dann auch irgendwann mal, ein proposal zu schreiben, in der hoffnung, dass die vorteile mal verstaendlich rueberkommen... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Als theorielastiger Universitätsinformatiker wünsche ich mir auch häufiger stärkere Eindeutigkeit und verstehe Sebastians Ansinnen. Ich glaube aber der einzig richtige Weg geht hier nicht über Regeln, sondern über gute Beispiele, weswegen Frederiks Vorschlag hier ganz viele erhält: Am 21.01.2009 08:32, Frederik Ramm: Wenn eine Definition so vage ist, dass sie Auslegungsspielraum hat, dann lege sie so aus, wie Du es fuer richtig haeltst. Dazu musst Du sie nicht aendern. Wenn Du das gesamte Konzept fuer unsinnig haeltst, dann denke Dir was eigenes brauchbares aus und verwende das; dokumentiere es ggf. auf einer eigenen Wikiseite (vielleicht zunaechst im User-Namensraum, wenn es sehr esoterisch ist). In allen freien (i.S.v. regelarmen/regellosen) Communities, die ich bisher erlebt habe ergibt sich eine Richtung, indem einer oder eine Gruppe voranschwimmt und für diese Richtung Werbung macht. Sammle deine Empfehlungen mit Begründungen auf einer Wiki-Seite. Mache Werbung auf talk und talk-de und wenn's gut läuft werden wir in einem Jahr nur noch auf Sebastians Liste als deFacto-Standard verweisen. Gruß, Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. Ich hab jetzt schon keine Lust mehr. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Es gibt schon einige, aber anscheinend nicht genug. Oder sie sind sich der Unterschiede nicht bewusst. Aber die meisten der von dir aufgelisteten Dinge hat mit den von mir bemängelten Dingen nicht allzuviel zu tun. Die Karten sehen so und so gut aus, egal ob die Daten stimmen oder nicht. Routing funktioniert auch. Fragt sich halt bloss welche Ansprüche man daran stellt. Ob man als z.B. zwischen Feinheiten wie (Reise)Bus-Routing und PKW-Routing unterscheiden will. Ich glaube gerne, dass routing für LKW und Reisebusse bald irgendwo mal mit diesen Daten gemacht wird. Ob Anlieger frei für Fahrräder gilt oder nicht, ist dafür irrelevant. Es geht ja auch nicht um Anlieger frei für Fahrräder wenns um LKW Routing geht. Sondern um z.B. korrekte LKW-relevante Tags. Zum Beispiel den Unterschied zwischen Gewicht und zulässigem Gewicht wird oder verwässert. Aber vielleicht ist das auch egal. Wenn LKW-Fahrer sich massenweise dafür anfangen zu interessieren, können die das ja regeln. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Womit es letztlich festgelegt ist. Da es technisch sowieso nicht möglich ist jemanden zu etwas zu zwingen, ist es wenn die große Zahl mitzieht, quasi festgelegt. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. Um aber im Wiki etwas zu erreichen, braucht es einfach klare Regeln. Nein. Da sind wir dann unterschiedlicher Meinung. Oder man schafft das Accepted/Rejected Proposal gleich ab und schreibt nur das Ergebnis der Abstimmung als Stimmungsbarometer der Interessierten hin. Bleibt trotzdem noch die Frage was in die Map Features kommt. Wenn es nicht nach dem Voting geht, nach was dann? Das ist ein konkretes Problem, das nunmal so oder so entschieden werden muss. Langsam habe ich keine große Lust mehr, mich im Wiki zu engagieren. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Halde klingt eher nach Abfall. Es ist kein Gesetzbuch oder irgend etwas was ein Mapper *braucht*. Seit es Presets gibt, braucht man noch nichtmal die Map-Features-Seite unbedingt wenn man mit OSM anfängt. Wenn du dich nicht im Wiki engagieren möchtest, lass es. Wenn du etwas verbessern willst: Mach es. Wenn du viel verbessern willst und keine Leute verprellen möchtest, leg jeweils eine neue Seite an und verweise auf der Diskussions-Seite der alten Variante auf deinen Neuvorschlag. Gut. Seit der Einfühung von highway=path mit der Brechstange sollte jedem klar sein, wie viel Bedeutung das Wiki hat und wie ernst zu nehmen das ist. Man kann aber auch ganz prima mappen ohne das Wiki zu benutzen. Welche Brechstange? Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Wenn es nicht gelingt, die Menschen im Projekt von Deiner Idee zu ueberzeugen, dann nuetzt Dir jede formale Prozedur nichts. Umgekehrt verbietet Dir auch niemand, Deine Idee umzusetzen... Wenn mir also im Wiki eine Definition nicht gefällt, soll ich sie einfach ändern? Wenn eine Definition so vage ist, dass sie Auslegungsspielraum hat, dann lege sie so aus, wie Du es fuer richtig haeltst. Dazu musst Du sie nicht aendern. Wenn Du das gesamte Konzept fuer unsinnig haeltst, dann denke Dir was eigenes brauchbares aus und verwende das; dokumentiere es ggf. auf einer eigenen Wikiseite (vielleicht zunaechst im User-Namensraum, wenn es sehr esoterisch ist). All diese Moeglichkeiten stehen Dir offen, ohne dass Du andere nach Deiner Pfeife tanzen lassen musst. Ich will auf keinen nach meiner Pfeife tanzen lassen, ich besitze nichtmal eine. Ich denke, bei sowas wie bicycle=yes und motorcar=no gibt es relativ wenig Deutungs-Unterschiede. [...] Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. Das ist halt sowas, wo die Programmierer sich etwas mehr auf den Charakter von OSM einlassen muessen. Ist es realistisch, eine Strasse zu haben, die fuer PKW gesperrt, fuer LKW aber frei ist? Sollte der Router in so einem Fall eventuell lieber auf der Seite der Vorsicht irren? (Ist uebrigens hgv nicht identisch mit goods?) Gut, also raten. Mir geht es weniger darum irgendjemand dazu zu zwingen es genauso zu machen, wie es im Wiki steht, sondern eher darum, dass die Mapper meist garkeine Möglichkeit haben, sich an etwas zu orientieren. Ich mappe ja selbst wie ich es am logischsten finde. Man müsste sich aber weniger selbst zusammenraten, wenn Manches im Wiki klarer definiert wäre. Wem die Definition nicht gefällt, mappt natürlich trotzdem wie er es für besser hält. Dann brauchen wir aber keinen Prozess, sondern einfach eine einzige Person, die einfach gut ist, oder von mir aus ein Team von Leuten, die sich im Rahmen der allgemein akzeptieren vagen Regeln konkrete Tagging-Howtos ausdenken (und das passiert ja auch schon vielerorts im Wiki, z.B. dort wo jemand angefangen hat, zu jedem Verkehrsschild aufzuschreiben, wie man das seiner Ansicht nach taggen sollte). Diese Leute koennen dann ja eine stimmige Interpretation/Empfehlung aufschreiben, und jeder, der das gut findet, kanns uebernehmen. Wenn es in einem anderen Land andere solche Leute gibt, die sich etwas anders entscheiden - was solls. Gut. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Sven Anders schrieb: Am Mittwoch, 21. Januar 2009 03:34 schrieb Sebastian Hohmann: Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Es geht doch darum es für die Mapper einfacher zu machen. Anstatt in den JOSM Presets 'vorzuschreiben' was benutzt wird, würde ich es eben auch gerne im Wiki machen. Was dann letztlich benutzt wird, ist dann Sache der Mapper. Es steht dir frei ein eigenes Schema zu entwerfen und dafür auch eine Entscheidungsstruktur aufzubauen. Ich will kein eigenes Schema, ich will nur das vorhandene verbessern. Vielleicht sollte man gleich auf die Anfänger-Seite schreiben, dass man nicht allzuviel Genauigkeit erwarten sollte, wenn man nicht vorhat eine konkrete Anwendung zu programmieren, die diese speziellen Daten braucht (eigentlich dachte ich ja OSM sammelt Daten auch erstmal unabhängig davon ob sie schon irgendwo dargestellt werden). Ja, ich denke das sollte doch eigentlich klar sein. Von der Wikipedia erwarte ich ja auch nicht, das jeder Artikel 100% stimmt. Auf der anderen Seite kann man ja auch als Anwendungsbenutzer den lokalen Mappern sagen: Schaut mal auf meiner Landkarte stimmt was nicht. Ich denke schon, das dann versucht wird, das genauer zu erfassen. Ebene. Dinge die von irgendeinem Programm dargestellt werden. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Mir geht es weniger darum irgendjemand dazu zu zwingen es genauso zu machen, wie es im Wiki steht, sondern eher darum, dass die Mapper meist garkeine Möglichkeit haben, sich an etwas zu orientieren. Ich mappe ja selbst wie ich es am logischsten finde. Man müsste sich aber weniger selbst zusammenraten, wenn Manches im Wiki klarer definiert wäre. Wem die Definition nicht gefällt, mappt natürlich trotzdem wie er es für besser hält. Dann brauchen wir aber keinen Prozess, sondern einfach eine einzige Person, die einfach gut ist, oder von mir aus ein Team von Leuten, die sich im Rahmen der allgemein akzeptieren vagen Regeln konkrete Tagging-Howtos ausdenken (und das passiert ja auch schon vielerorts im Wiki, z.B. dort wo jemand angefangen hat, zu jedem Verkehrsschild aufzuschreiben, wie man das seiner Ansicht nach taggen sollte). Diese Leute koennen dann ja eine stimmige Interpretation/Empfehlung aufschreiben, und jeder, der das gut findet, kanns uebernehmen. Wenn es in einem anderen Land andere solche Leute gibt, die sich etwas anders entscheiden - was solls. Mal ganz konkret die Frage: Wie wird entschieden, was in die Map Features kommt und eine eigene Key/Tag-Seite bekommt? Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Sebastian Hohmann wrote: Ist es realistisch, eine Strasse zu haben, die fuer PKW gesperrt, fuer LKW aber frei ist? Sollte der Router in so einem Fall eventuell lieber auf der Seite der Vorsicht irren? (Ist uebrigens hgv nicht identisch mit goods?) Gut, also raten. Sagen wir: Vernuenftige Annahmen treffen. - Am Wort raten gefaellt mir nicht, dass es sich so anhoert, als koenne bestenfalls eine Trefferwahrscheinlichkeit von 50% erzielen ;-) Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. Ich hab jetzt schon keine Lust mehr. du gibst aber schnell auf ;-) leider sind manche dinge bei osm nicht so einfach, wie sie sein koennten... es gibt sehr viele dinge, die sich verbessern liessen, und verschiedene leute haben verschiedene konzepte. es waere schade, wenn neue ideen nicht genannt werden, weil sie nicht angenommen werden koennten. am besten ist es wohl, neue konzepte gut zu dokumentieren und mit beispielen zu demonstrieren, damit die leute verstehen koennen, was denn besser ist. mit kleinen schritten wird man im allgemeinen auch weiter kommen, als mit radikalen aenderungen. wenn man nun noch ein integration in die ganze kette vom editor ueber die datenbank bis zum renderer/router anbieten kann, stehen die chancen wahrscheinlich noch besser. aber eines sollte man sich immer bewusst sein: so gut ein konzept auch sein mag, man kann es nur anbieten, und hoffen, dass es angenommen wird. die alternative waere - wie schon vorgeschlagen - das ganze parallel zu osm aufzuziehen, und zu hoffen, dass genug leute mitmachen... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Sebastian Hohmann wrote: Mal ganz konkret die Frage: Wie wird entschieden, was in die Map Features kommt und eine eigene Key/Tag-Seite bekommt? Die Frage ist falsch gestellt. Grundsaetzlich kann jeder das Wiki aendern. Das heisst, ich kann auch meinen Fantasie-Tag in die Map Features schreiben. Jemand anders kann ihn dann wieder löschen. Und so weiter. Und wir haben keinen Obermufti, der entscheidet, wer im Recht ist. Den klaren Entscheidungsprozess, nach dem Du fragst, den gibt es also gar nicht. In der Praxis ist es eine Art Akklamations-System. Wenn Du an den Map Features was aenderst und die Leute auf der Talk-Liste das gut finden oder zumindest niemand gross protestiert, dann ist die Aenderung drin. Wenn Du einfach so was eintraegst, was Dir grad einfaellt, ohne dass es dazu was auf der Liste oder wenigstens eine Diskussion im Wiki gab oder so, wird jemand anders es vermutlich wieder rauswerfen. Ich wuerde mal so formulieren: Um die Map Features-Seite zu aendern, brauchst Du einen guten Grund und musst willens und in der Lage sein, diesen Grund auf Nachfrage zu erlaeutern oder dies gleich ohne Nachfrage prohpylaktisch tun. Ulf Lamping zum Beispiel fuegt seit Monaten ab und zu neue shop-Werte auf die Map-Features-Seite hinzu, ohne jede Abstimmung (Skandal!), nur mit einer lapidaren Mail an talk: shop=computer wird derzeit 115mal benutzt, ich hab das mal hinzugefügt. Wenn ein Tag 115mal benutzt wird, ist das in der Regel ein guter Grund, ausser in Streitfällen wird niemand protestieren. Es ist allgemein anerkannt, das Map Features dokumentieren soll, was benutzt wird. Es kann aber auch andere gute Gründe geben, z.B. ein erfolgreich abgestimmtes Proposal. (Auch hier gilt, dass es in Streitfällen Widerstand geben kann, aber in den allermeisten Fällen wird niemand was einzuwenden haben.) Meine letzten beiden Änderungen an den Map Features waren z.B. eine Klarstellung bei highway=track - da stand, dass tracks generell nicht asphaltiert seien, was ja mittlerweile durch die Nutzung in Kombination mit tracktype=grade1 nicht mehr stimmt. Irgendjemand hatte auf der Liste geschrieben ätschibätsch, grade1 ist Quatsch, hier steht doch dass tracks nie asphaltiert sind, ich habe das daraufhin geändert und kurzerhand geantwortet: danke für den Hinweis, Wiki ist korrigiert - einer oder zwei fühlten sich durch diesen respektlosen Umgang mit dem Wiki auf den Schlips getreten, aber es war unbestreitbar, dass ich in diesem Punkt recht hatte, und so ist die Änderung auch heute noch drin. Oder ich habe bei amenity=hospital ergänzt, dass oft ein emergency=yes/no dazu gesetzt wird, weil ich es für bescheuert hielt, dass das Proposal für das emergency-Tag von irgendjemand als abandoned klassifiziert worden war. Auch das habe ich kurz auf talk dargestellt, und niemand hat sich beschwert... Eine eigene Key/Tag-Seite kann man m.E. für alles anlegen, was nicht gerade komplett erfunden ist. Die meisten machen erst ein Proposal usw., aber man muss nicht. Bye Frederik ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ich glaube gerne, dass routing für LKW und Reisebusse bald irgendwo mal mit diesen Daten gemacht wird. Ob Anlieger frei für Fahrräder gilt oder nicht, ist dafür irrelevant. Es geht ja auch nicht um Anlieger frei für Fahrräder wenns um LKW Routing geht. Sondern um z.B. korrekte LKW-relevante Tags. Zum Beispiel den Unterschied zwischen Gewicht und zulässigem Gewicht wird oder verwässert. Aber vielleicht ist das auch egal. Wenn LKW-Fahrer sich massenweise dafür anfangen zu interessieren, können die das ja regeln. Soweit ich weiß gibt es momentan noch kein Massenmarkt-taugliches Navi für Reisebusse und LKW. Die meisten der Fahrer haben ein Auto-Navi dabei. Das liegt vermutlich daran, dass die LKW-spezifischen Dinge in den Daten der kommerziellen Hersteller auch noch gar nicht enthalten sind. Ein einfacher Mapper wird gar nicht wissen, auf was er alles achten muss. Wenn aber in Zukunft mal die Information die Runde macht, dass jetzt das erste Massenmarkt-taugliche LKW-Navi auf Basis von OSM-Daten existiert und OpenStreetBugs in dem Gerät voll integriert ist, dann prophezeihe ich dir, dass die Daten *sehr* schnell nachgetragen werden. Von Mappern und Anwendern. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... Ich mach das auch soweit ich die Beschränkungen erkenne. Man hat halt nen anderen Blick, mit welchem Verkehrsmittel man grade unterwegs ist. mit dem Fahrrad achtet man nicht auf enge Durchfahrten und Größenbeschränkungen, da geht einem schonmal was durch. Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. Naja, aber was ist wenn einer sagt, access=destination ist per se Quark und der nächste sagt, das reicht mir für meine Ansprüche? Oder tracktype: Es gibt viele die das aktuelle Schema grausam finden, alle Eigenschaften in einen Wertebereich von 1 bis 5 zu zwängen. Ich war auch skeptisch. Aber hey, es funktioniert. Man kann damit keine Statistiken machen wie viele Schlaglöcher ein Weg hat, aber man weiß ob man ihn im matschigen Herbst als Wanderweg nutzen will oder nicht. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Halde klingt eher nach Abfall. Bei manchen Artikeln im Wiki ist der Begriff auch im Rahmen der möglichen Bezeichnungen. :) Seit der Einfühung von highway=path mit der Brechstange sollte jedem klar sein, wie viel Bedeutung das Wiki hat und wie ernst zu nehmen das ist. Man kann aber auch ganz prima mappen ohne das Wiki zu benutzen. Welche Brechstange? highway=path wurde etwas vage vorgeschlagen als einen Weg den man zu Fuß oder mit einem Fahrrad benutzen kann. Weitere Tags wurden vorgeschlagen um das dann genauer zu spezifizieren. Manche haben darunter einen Trampelpfad und manche einen Wanderweg verstanden, andere dagegen sehen das als Ersatz für alle Fuß- und Radwege die momentan eingetragen sind. Ein Voting brachte zwar eine Mehrheit für das neue Tag highway=path aber eine deutliche Ablehnung bzgl. des Ersetzens von footway und cycleway. In der Folge haben die eifrigen Mapper aber nach und nach alle Beschreibungen im Wiki so geändert, dass dort wo vorher z.B. highway=footway stand, nachher das path-Konstrukt stand. Auch in den Diskussionen der Mailingliste und bei tagwatch kann man deutlich sehen, dass der gemeine Mapper sich nicht umgestellt hat und die meisten weiterhin Fußwege als Fußwege eintragen. Es wurde viel Arbeit in die Umstellung des Wikis investiert, Dokumentationen und Beispiele wurden geschrieben aber die Masse hat das Tag nicht wirklich übernommen. Bis heute gibt es unterschiedliche Auffassungen was das Tag eigentlich bedeutet, denn das war schon zum Zeitpunkt der Abstimmung unklar. Es gibt weiterhin eine große Zahl an Mappern die das Tag nicht nutzen und prima ohne das auskommen. Gruß, Bernd -- Ein Pessimist ist jemand, der vorzeitig die Wahrheit erzählt. - Cyrano de Bergerac (frz. Schriftsteller 1619-1655) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Es gibt schon einige, aber anscheinend nicht genug. Oder sie sind sich der Unterschiede nicht bewusst. sinnvollerweise sollten solche dinge so getaggt, wie es die stvo fuer das jeweilige schild beschreibt, das ist zumindest in diesem fall recht eindeutig. leider ist aber die wahrscheinlichkeit, dass ein autofahrender mapper nur aus seinem blickwinkel mappt, sehr hoch. viele dinge fallen einem erst auf, wenn man selber betroffen ist. entpsrechende presets in den editoren koennten diese situation sicherlich verbessern... Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... gruendlichkeit ist sehr gut! leider wird es trotzdem wohl nie eine garantie geben, dass alle vorhandenen hoehen- und gewichtsbeschraenkungen auch in die datenbank eingetragen wurden. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Womit es letztlich festgelegt ist. Da es technisch sowieso nicht möglich ist jemanden zu etwas zu zwingen, ist es wenn die große Zahl mitzieht, quasi festgelegt. man kann sich dann zumindest darauf verlassen, dass etwas in einem gewissen rahmen funktioniert, auch wenn es nicht die optimale loesung darstellt. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. eindeutig ist besser, da stimme ich dir zu. auf welche art das realisiert wird, ist da zweitrangig. das problem ist aber einerseits, dass eindeutig nicht zwangslaeufig einfacher bedeutet (was sich aber auf userseite durchaus realisieren liesse), und dass dafuer altbekannte mechanismen und pfade, die ja funktionieren, zugunsten neuer verlassen werden muessen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Hallo, Sebastian Hohmann wrote: Mal ganz konkret die Frage: Wie wird entschieden, was in die Map Features kommt und eine eigene Key/Tag-Seite bekommt? Die Frage ist falsch gestellt. Grundsaetzlich kann jeder das Wiki aendern. Das heisst, ich kann auch meinen Fantasie-Tag in die Map Features schreiben. Jemand anders kann ihn dann wieder löschen. Und so weiter. Und wir haben keinen Obermufti, der entscheidet, wer im Recht ist. Den klaren Entscheidungsprozess, nach dem Du fragst, den gibt es also gar nicht. In der Praxis ist es eine Art Akklamations-System. Wenn Du an den Map Features was aenderst und die Leute auf der Talk-Liste das gut finden oder zumindest niemand gross protestiert, dann ist die Aenderung drin. Wenn Du einfach so was eintraegst, was Dir grad einfaellt, ohne dass es dazu was auf der Liste oder wenigstens eine Diskussion im Wiki gab oder so, wird jemand anders es vermutlich wieder rauswerfen. Ich wuerde mal so formulieren: Um die Map Features-Seite zu aendern, brauchst Du einen guten Grund und musst willens und in der Lage sein, diesen Grund auf Nachfrage zu erlaeutern oder dies gleich ohne Nachfrage prohpylaktisch tun. Ulf Lamping zum Beispiel fuegt seit Monaten ab und zu neue shop-Werte auf die Map-Features-Seite hinzu, ohne jede Abstimmung (Skandal!), nur mit einer lapidaren Mail an talk: shop=computer wird derzeit 115mal benutzt, ich hab das mal hinzugefügt. Wenn ein Tag 115mal benutzt wird, ist das in der Regel ein guter Grund, ausser in Streitfällen wird niemand protestieren. Es ist allgemein anerkannt, das Map Features dokumentieren soll, was benutzt wird. Es kann aber auch andere gute Gründe geben, z.B. ein erfolgreich abgestimmtes Proposal. (Auch hier gilt, dass es in Streitfällen Widerstand geben kann, aber in den allermeisten Fällen wird niemand was einzuwenden haben.) Meine letzten beiden Änderungen an den Map Features waren z.B. eine Klarstellung bei highway=track - da stand, dass tracks generell nicht asphaltiert seien, was ja mittlerweile durch die Nutzung in Kombination mit tracktype=grade1 nicht mehr stimmt. Irgendjemand hatte auf der Liste geschrieben ätschibätsch, grade1 ist Quatsch, hier steht doch dass tracks nie asphaltiert sind, ich habe das daraufhin geändert und kurzerhand geantwortet: danke für den Hinweis, Wiki ist korrigiert - einer oder zwei fühlten sich durch diesen respektlosen Umgang mit dem Wiki auf den Schlips getreten, aber es war unbestreitbar, dass ich in diesem Punkt recht hatte, und so ist die Änderung auch heute noch drin. Oder ich habe bei amenity=hospital ergänzt, dass oft ein emergency=yes/no dazu gesetzt wird, weil ich es für bescheuert hielt, dass das Proposal für das emergency-Tag von irgendjemand als abandoned klassifiziert worden war. Auch das habe ich kurz auf talk dargestellt, und niemand hat sich beschwert... Eine eigene Key/Tag-Seite kann man m.E. für alles anlegen, was nicht gerade komplett erfunden ist. Die meisten machen erst ein Proposal usw., aber man muss nicht. Danke für die Erläuterung. Wenn es dir recht ist werde ich das teilweise auch ins Wiki übernehmen. Ich will schließlich nur klare Regeln. Wenn diese Regeln das besagen was du gerade erklärt hast, dann ist das eindeutiger, als ein Proposal-Prozess von dem erwartet wird, dass das Ergebnis in die Map Features aufgenommen werden MUSS, wenn dem garnicht so ist, sondern nur ein guter Grund vorhanden sein muss. Deshalb finde ich, muss die Vorgehensweise (die du gerade erläutert hast) dokumentiert werden, sonst muss bloss wieder geraten werden, wie man es denn machen muss/darf. Obwohl in Einzelfällen ein Obermufti (aka Admin) nützlich wäre, um mal die Seite zu sperren, wenn es nur hin- und hergeht. Aber das kommt wohl zugegeben selten vor. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Bernd Wurst schrieb: Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. Naja, aber was ist wenn einer sagt, access=destination ist per se Quark und der nächste sagt, das reicht mir für meine Ansprüche? Persönliche Vorlieben eben. Damit muss man sich wohl abfinden und weit verbreitete die persönlichen Vorlieben dokumentieren, damit nicht nur die eigenen Interpretationen berücksichtigt werden. Da es access=destination eigentlich in Deutschland garnicht geben dürfte, ist in dem Fall eigentlich eine Benutzung auch nicht schlimm. Auch wenn ich es 'Quark' finde. Aber trotzdem ist es doch besser, wenn die Daten eindeutig sind, oder nicht? Sonst kann man eben nur raten. Oder sagen wir so, damit man besser versteht was ich meine: Eindeutig genug, um mit recht hoher Wahrscheinlichkeit die vom Mapper angedachte Bedeutung herausfinden zu können. Oder tracktype: Es gibt viele die das aktuelle Schema grausam finden, alle Eigenschaften in einen Wertebereich von 1 bis 5 zu zwängen. Ich war auch skeptisch. Aber hey, es funktioniert. Man kann damit keine Statistiken machen wie viele Schlaglöcher ein Weg hat, aber man weiß ob man ihn im matschigen Herbst als Wanderweg nutzen will oder nicht. Ja. Tracktype funktioniert nicht so schlecht, wie es vielleicht aussah. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Halde klingt eher nach Abfall. Bei manchen Artikeln im Wiki ist der Begriff auch im Rahmen der möglichen Bezeichnungen. :) Schade eigentlich. Gerade Anfänger orientieren sich doch am Wiki. Nicht jeder hat einen persönlichen Mentor. Es wurde viel Arbeit in die Umstellung des Wikis investiert, Dokumentationen und Beispiele wurden geschrieben aber die Masse hat das Tag nicht wirklich übernommen. Bis heute gibt es unterschiedliche Auffassungen was das Tag eigentlich bedeutet, denn das war schon zum Zeitpunkt der Abstimmung unklar. Genauso wie es unterschiedliche Auffassungen gibt was footway oder cycleway bedeutet. Findest du das gut? Es gibt weiterhin eine große Zahl an Mappern die das Tag nicht nutzen und prima ohne das auskommen. Fürchterlich wenig sind 40k paths aber auch nicht. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Es gibt schon einige, aber anscheinend nicht genug. Oder sie sind sich der Unterschiede nicht bewusst. sinnvollerweise sollten solche dinge so getaggt, wie es die stvo fuer das jeweilige schild beschreibt, das ist zumindest in diesem fall recht eindeutig. leider ist aber die wahrscheinlichkeit, dass ein autofahrender mapper nur aus seinem blickwinkel mappt, sehr hoch. viele dinge fallen einem erst auf, wenn man selber betroffen ist. entpsrechende presets in den editoren koennten diese situation sicherlich verbessern... Presets sind ja letztlich wie Dokumentation im Wiki: Vorschläge wie man etwas Taggen kann. Ich habe auch versucht diese Vorschläge an der STVO auszurichten. Denn auch wenn es eindeutig ist, denkt (wie du richtig sagst) nicht jeder Mapper an die gleichen Dinge. Insofern ist es von Vorteil wenn man da Vorschläge macht, damit nicht jeder wieder neu die Bedeutung der Verkehrszeichen nachschlagen muss. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Ich mach das. Vielleicht hat es dann wenigstens ETWAS Gutes, wenn ich so gründlich sein will... gruendlichkeit ist sehr gut! leider wird es trotzdem wohl nie eine garantie geben, dass alle vorhandenen hoehen- und gewichtsbeschraenkungen auch in die datenbank eingetragen wurden. Darum geht es mir auch nicht, die Garantie kann wohl keiner geben. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Womit es letztlich festgelegt ist. Da es technisch sowieso nicht möglich ist jemanden zu etwas zu zwingen, ist es wenn die große Zahl mitzieht, quasi festgelegt. man kann sich dann zumindest darauf verlassen, dass etwas in einem gewissen rahmen funktioniert, auch wenn es nicht die optimale loesung darstellt. Genau. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Besser im Sinne von eindeutiger. Ich denke dagegen kann doch keiner was haben? Das Problem ist welches Tagging-Schema besser ist. Das lässt sich natürlich nicht sagen, weil da jeder persönliche Vorlieben hat. eindeutig ist besser, da stimme ich dir zu. auf welche art das realisiert wird, ist da zweitrangig. das problem ist aber einerseits, dass eindeutig nicht zwangslaeufig einfacher bedeutet (was sich aber auf userseite durchaus realisieren liesse), und dass dafuer altbekannte mechanismen und pfade, die ja funktionieren, zugunsten neuer verlassen werden muessen. Das kann ich so stehen lassen. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. Ich hab jetzt schon keine Lust mehr. du gibst aber schnell auf ;-) leider sind manche dinge bei osm nicht so einfach, wie sie sein koennten... es gibt sehr viele dinge, die sich verbessern liessen, und verschiedene leute haben verschiedene konzepte. es waere schade, wenn neue ideen nicht genannt werden, weil sie nicht angenommen werden koennten. Naja, wenn man sowas hier vorschlägt schlägt einem eben gleich eine Welle von Mails entgegen, die nicht gerade motivierend sind. die alternative waere - wie schon vorgeschlagen - das ganze parallel zu osm aufzuziehen, und zu hoffen, dass genug leute mitmachen... Da habe ich nun garkeine Ambitionen. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: sinnvollerweise sollten solche dinge so getaggt, wie es die stvo fuer das jeweilige schild beschreibt, das ist zumindest in diesem fall recht eindeutig. leider ist aber die wahrscheinlichkeit, dass ein autofahrender mapper nur aus seinem blickwinkel mappt, sehr hoch. viele dinge fallen einem erst auf, wenn man selber betroffen ist. entpsrechende presets in den editoren koennten diese situation sicherlich verbessern... Presets sind ja letztlich wie Dokumentation im Wiki: Vorschläge wie man etwas Taggen kann. Ich habe auch versucht diese Vorschläge an der STVO auszurichten. Denn auch wenn es eindeutig ist, denkt (wie du richtig sagst) nicht jeder Mapper an die gleichen Dinge. Insofern ist es von Vorteil wenn man da Vorschläge macht, damit nicht jeder wieder neu die Bedeutung der Verkehrszeichen nachschlagen muss. mein vision bzgl. der presets ist die folgende: der mapper will ein schild eintragen, und klickt dazu im editor auf ein bildchen desselben, fuegt evtl. durch klicken auf deren fotos noch zusatzschilder hinzu (haeufig benutzte kombinationen kann man vielleicht auch speichern), so dass er letztendlich im editor genau dasselbe sieht, wie auch in der freien wildbahn. mit einem klick auf ok generiert der editor eindeutige tags, die genau diese situation beschreiben, ohne dass sich der user jemals gedanken darueber machen musste, wie er denn sowas jetzt realisiert... eindeutig ist besser, da stimme ich dir zu. auf welche art das realisiert wird, ist da zweitrangig. das problem ist aber einerseits, dass eindeutig nicht zwangslaeufig einfacher bedeutet (was sich aber auf userseite durchaus realisieren liesse), und dass dafuer altbekannte mechanismen und pfade, die ja funktionieren, zugunsten neuer verlassen werden muessen. Das kann ich so stehen lassen. endlich mal jemand der mir zustimmt... ;-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo Bernd, Ein einfacher Mapper wird gar nicht wissen, auf was er alles achten muss. Die meisten Neuen sind begeistert von der OSM-Idee und hoch motiviert. Wenn wir ihnen sagen, wie das Mappen funktioniert und worauf sie achten müssen, dann werden sie sich freudig bemühen, das möglichst genau so zu machen - und sich Mitte der Woche über die schönen Ergebnisse freuen. Dazu ist es erforderlich, dass wir: - im Wiki möglichst verständliche Anleitungen schreiben - klare verständliche Tagging-Regeln formulieren - im Editor eine regelkonforme Benutzerführung gestalten - die gemappten Daten möglichst schnell und vollständig anzeigen (dabei geht es NICHT um Einschränkung der Freiheit, sondern nur um Verbesserung von OSM, der Daten und der möglichen Anwendungen. Freiheit ist die Grundlage von Innovation) Wenn aber in Zukunft mal die Information die Runde macht, dass jetzt das erste Massenmarkt-taugliche LKW-Navi auf Basis von OSM-Daten existiert und OpenStreetBugs in dem Gerät voll integriert ist, dann prophezeihe ich dir, dass die Daten *sehr* schnell nachgetragen werden. Dazu ist bereits ein Programm in Entwicklung, das Onroad-Tagging für Anfänger erlaubt... Man hat halt nen anderen Blick, mit welchem Verkehrsmittel man grade Ja - und diesen Blick kann man durch gute Information - beispielsweise im Wiki - erweitern, schärfen, vertiefen. Damit man/frau zunehmend die Belange auch anderer Anwender mit einbeziehen lernt. Besser im Sinne von eindeutiger. Das wäre ein Kriterium. Andere wären: - verständlicher - schneller erfassbar (Tagging) - besser erkennbar (Karte lesen, Routing) - umfassender (LKW, Fahhrad, Pferd) - ... aber was ist wenn einer sagt, ist Quark und der nächste sagt, das reicht mir für meine Ansprüche? Dann versucht man aus beiden Bedürfnissen das für alle denkbaren Anwendungsfälle Optimale zu bilden. Das Wiki ist eine Daten-Halde die aber nur Sinn macht, wenn die Daten - schnell auffindbar (Links, Gliederung, Kategorien) - verständlich formuliert - eindeutig - umfassend - schnell erfassbar sind wurde etwas vage vorgeschlagen und jeder versteht etwas anderes darunter... Bis heute gibt es unterschiedliche Auffassungen was das Tag eigentlich bedeutet, denn das war schon zum Zeitpunkt der Abstimmung unklar. Eben. Und dann macht halt jeder irgendetwas... In der Programmierung nannte man das Spaghetti-Programm. Diese waren ganauso wenig dokumentiert. Es gibt weiterhin eine große Zahl an Mappern die das Tag nicht nutzen und prima ohne das auskommen. Aber halt nicht daran denken, dass eine Geo-DB eben nur mit einer funktionierenden Anwendung Sinn macht, also /nicht/ ohne diese zu berücksichtigen auskommt. Die Lösung heisst: *Best Practice* dokumentieren, bekannt machen, für Umsetzung sorgen. Also Qualität generieren schon beim Erfassen und Speichern der Daten, immer im Hinblick auf mögliche Anwendungen. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo Guenther, Deine Vision ist auch meine: vision bzgl. der presets: der mapper will ein schild eintragen, und klickt dazu im editor auf ein bildchen desselben, fuegt evtl. durch klicken auf deren fotos noch zusatzschilder hinzu (haeufig benutzte kombinationen kann man vielleicht auch speichern), so dass er letztendlich im editor genau dasselbe sieht, wie auch in der freien wildbahn. mit einem klick auf ok generiert der editor eindeutige tags, die genau diese situation beschreiben, ohne dass sich der user jemals gedanken darueber machen musste, wie er denn sowas jetzt realisiert... Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hi Sebastian! Sebastian Hohmann schrieb: Also ich sehe in der Interpretation von Tags teils erhebliche Unterschiede. Aber vielleicht gehen da auch unsere Erwartungen an die Genauigkeit der Daten auseinander. Das ist das eher kleinere Übel. Früher oder später werden sämtliche Querschläger korregiert sein. Wenn jemand meint, er müsse unbedingt abweichend vom Konsens als strasse=fahrradweg taggen, dann soll er das. Ich werde so frei sein und es ohne seine Einverständnis abändern. Verpflichtende Reglementierungen halte ich für kontraproduktiv. Erstens will ich persönlich niemanden bevormunden und außerdem ist es gar nicht nötig. Auf vielen Wiki-Seiten stehen z.B. widersprüchliche Dinge (seit Jahren!), die eigentlich ausgeräumt sein müssten, wenn die Community tatsächlich so gut darüber wacht. Ich stimme dir zu, dass hier teilweise sehr schwammig formulierte Beschreibungen zu finden sind. Man sollte klar und unmissverständlich schreiben, für was welcher Tag steht und für was nicht. Und vor allen Dingen sollte die Beschreibung *ein Mal* zu finden sein und nicht zig mal mit komplett anderem Wortlaut oder gar widersprüchlichem Inhalt. Dann frage ich dich hiermit, was genau das über 10.000 mal benutzte access=destination bedeutet und welcher Deutschen Zugangsbeschränkung das entsprechen soll (falls du aus Deutschland kommst). http://wiki.openstreetmap.org/wiki/DE:Key:access Da steht eindeutig, dass es dem deutschen Anlieger frei bzw. ausgenommen Anrainer entspricht. Man kann es aber auch für keine öffentlichen Durchgänge verwenden. Rein vom Prinzip her bedeutet es, dass man den Weg nur dann betreten darf, wenn sich das Ziel nur unmittelbar durch diesen Weg betreten lässt, also wenn z.B. ein Haus in einer Anlieger frei-Straße steht. Bei dem Beispiel ist es wieder eine Frage der Erwartungshaltung. Soll die Realität nur 'in etwa' abgebildet werden oder so genau wie möglich. Vielleicht bin ich da auch zu anspruchsvoll, mag sein. So genau wie möglich, jedoch so umfangreich wie maximal nötig. Es bringt nichts, bei der aktuellen Rechengeschwindigkeit und der geringen GPS-Auflösung Fahrbahnen als Flächen zu taggen. Es bringt auch nichts, wenn du einen GPS-Track hast mit Punkten im 500-Meter-Abstand und dann zwischen den Punkten manuell etwas rein erfindest. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
André Reichelt schrieb: Hi Sebastian! Sebastian Hohmann schrieb: Also ich sehe in der Interpretation von Tags teils erhebliche Unterschiede. Aber vielleicht gehen da auch unsere Erwartungen an die Genauigkeit der Daten auseinander. Das ist das eher kleinere Übel. Früher oder später werden sämtliche Querschläger korregiert sein. Wenn jemand meint, er müsse unbedingt abweichend vom Konsens als strasse=fahrradweg taggen, dann soll er das. Ich werde so frei sein und es ohne seine Einverständnis abändern. Verpflichtende Reglementierungen halte ich für kontraproduktiv. Erstens will ich persönlich niemanden bevormunden und außerdem ist es gar nicht nötig. Dann sind wir uns ja prinzipiell einig. Ich sehe das Problem nur da, wo es keinen eindeutigen Konsens gibt. Aber hoffentlich ändert sich das mit der Zeit, wenn manche Anwendungen (z.B. Routing) noch wichtiger werden. Auf vielen Wiki-Seiten stehen z.B. widersprüchliche Dinge (seit Jahren!), die eigentlich ausgeräumt sein müssten, wenn die Community tatsächlich so gut darüber wacht. Ich stimme dir zu, dass hier teilweise sehr schwammig formulierte Beschreibungen zu finden sind. Man sollte klar und unmissverständlich schreiben, für was welcher Tag steht und für was nicht. Und vor allen Dingen sollte die Beschreibung *ein Mal* zu finden sein und nicht zig mal mit komplett anderem Wortlaut oder gar widersprüchlichem Inhalt. Genau. Leider ist das häufig nicht der Fall. Entweder weils einach veraltete Seiten sind oder weil man sich nicht einig wird. Und was klar und unmissverständlich ist, da scheinen die Meinungen auch auseinanderzugehen. Widersprüchlichen Formulierungen wird mit Templates usw. ja teilweise schon entgegengearbeitet. Dann frage ich dich hiermit, was genau das über 10.000 mal benutzte access=destination bedeutet und welcher Deutschen Zugangsbeschränkung das entsprechen soll (falls du aus Deutschland kommst). http://wiki.openstreetmap.org/wiki/DE:Key:access Da steht eindeutig, dass es dem deutschen Anlieger frei bzw. ausgenommen Anrainer entspricht. Man kann es aber auch für keine öffentlichen Durchgänge verwenden. Rein vom Prinzip her bedeutet es, dass man den Weg nur dann betreten darf, wenn sich das Ziel nur unmittelbar durch diesen Weg betreten lässt, also wenn z.B. ein Haus in einer Anlieger frei-Straße steht. Mir ging es eher darum, dass das Anlieger frei eigentlich nur für Fahrzeuge (in Kombination mit Zeichen 250) oder sogar nur für motorisierte Fahrzeuge (Zeichen 260) gilt. access=destination gilt aber (eigentlich, der Logik entsprechend) für alle Verkehrsteilnehmer. Aber letztlich auch egal. Wenn alle wissen dass es für Fußgänger und Reiter in der Regel nicht gilt, kann man ja immerhin ETWAS damit anfangen. Bei dem Beispiel ist es wieder eine Frage der Erwartungshaltung. Soll die Realität nur 'in etwa' abgebildet werden oder so genau wie möglich. Vielleicht bin ich da auch zu anspruchsvoll, mag sein. So genau wie möglich, jedoch so umfangreich wie maximal nötig. Es bringt nichts, bei der aktuellen Rechengeschwindigkeit und der geringen GPS-Auflösung Fahrbahnen als Flächen zu taggen. Es bringt auch nichts, wenn du einen GPS-Track hast mit Punkten im 500-Meter-Abstand und dann zwischen den Punkten manuell etwas rein erfindest. Eine Diskussion bezüglich der GPS-Genauigkeit wollte ich eigentlich auch nicht anfangen, ich denke da kennen wir alle die Abweichungen. Es geht mir eher um die Meta-Daten. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Sebastian Hohmann m...@s-hohmann.de wrote: Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. Die Admins und Programmierer treffen natürlich Entscheidungen bezüglich der Websites, der API (wie läuft das eigentlich?) oder der Anwendungen rund um OSM. Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Vielleicht solltest Du mal diverse papers über crowdsourcing etc. lesen um bevor Du hier solchen Unfug forderst. Ohne das freie Tagging wäre OSM nicht das geworden was es heute ist, da bin ich fest davon überzeugt. Du bist nicht zufällig der selbe Mensch wie dieser roadrunner66 im Heiseforum, der ganz Ähnliches Zeug schreibt? Der Cathedral Style funktioniert im Umfeld freier Software und freiem Content einfach nicht besonders gut. Das inzwischen berühmte the cathedral and the bazaar kennst Du aber schon oder? Sven -- /* * Wirzenius wrote this portably, Torvalds fucked it up :-) */(taken from /usr/src/linux/lib/vsprintf.c) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: ich bin ja auch der meinung, dass genaue definitionen und richtlinien viele dinge einfacher machen wuerden und auch einen ganzen haufen unnoetiger arbeit ersparen koennten. eine erweiterbarkeit muss sowas dennoch nicht ausschliessen. du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. So sieht auch meine Meinung aus. OSM ist (z.T. leider) sehr frei aufgezogen, und das wird man auch nicht umschmeissen koennen. Also arbeitet man am Besten nicht gegen das System sondern mit dem System: Der Ansatz ist ja, dass sich am Ende die Loesung durchsetzen wird, die am meisten benutzt wird (Das ist nicht unbedingt die Beste). Je klarer da eine Mehrheit ausfaellt, um so fester gilt das dann auch als Regel. Also hilf man mit bei der Mehrheitsbildung, in dem man nicht unnoetig neue Elemente oder Bedeutungen definiert, sondern sich so strikt wie moeglich an das bereits etabliert haelt. Fuer mich ist das die englischsprachige Mapfeatures-Liste, da dort die Community-Kontrolle am staerksten ausgepraegt sein duerfte. Ich trage also nichts ein, was nicht auch in dieser Liste steht, und versuche auch allgemein eine Ausrichtung an dieser Liste zu unterstuetzen (z.B. durch das Schreiben dieses Textes). Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: mein vision bzgl. der presets ist die folgende: der mapper will ein schild eintragen, und klickt dazu im editor auf ein bildchen desselben, fuegt evtl. durch klicken auf deren fotos noch zusatzschilder hinzu (haeufig benutzte kombinationen kann man vielleicht auch speichern), so dass er letztendlich im editor genau dasselbe sieht, wie auch in der freien wildbahn. mit einem klick auf ok generiert der editor eindeutige tags, die genau diese situation beschreiben, ohne dass sich der user jemals gedanken darueber machen musste, wie er denn sowas jetzt realisiert... Das klingt toll. schon. muesste nur noch realisiert werden. freiwillige vor! ;-) eindeutig ist besser, da stimme ich dir zu. auf welche art das realisiert wird, ist da zweitrangig. das problem ist aber einerseits, dass eindeutig nicht zwangslaeufig einfacher bedeutet (was sich aber auf userseite durchaus realisieren liesse), und dass dafuer altbekannte mechanismen und pfade, die ja funktionieren, zugunsten neuer verlassen werden muessen. Das kann ich so stehen lassen. endlich mal jemand der mir zustimmt... ;-) Du stimmst mir ja quasi auch zu, zumindest habe ich das auch so gemeint. Lass uns jetzt streiten wer wem zuerst zugestimmt hat.. :P ich natuerlich, wer denn sonst :-D signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Torsten Leistikow schrieb: Guenther Meyer schrieb: ich bin ja auch der meinung, dass genaue definitionen und richtlinien viele dinge einfacher machen wuerden und auch einen ganzen haufen unnoetiger arbeit ersparen koennten. eine erweiterbarkeit muss sowas dennoch nicht ausschliessen. du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. So sieht auch meine Meinung aus. OSM ist (z.T. leider) sehr frei aufgezogen, und das wird man auch nicht umschmeissen koennen. Also arbeitet man am Besten nicht gegen das System sondern mit dem System: Der Ansatz ist ja, dass sich am Ende die Loesung durchsetzen wird, die am meisten benutzt wird (Das ist nicht unbedingt die Beste). Je klarer da eine Mehrheit ausfaellt, um so fester gilt das dann auch als Regel. Wie bekommst du heraus was sich am Ende durchsetzt? Die Bedeutung eines Tags kann man nicht in den Daten ablesen. Abstimmungen sind nicht repräsentativ, das Meinungsbild hier in der Liste oder im Forum repräsentiert auch nicht alle Mapper. Also hilf man mit bei der Mehrheitsbildung, in dem man nicht unnoetig neue Elemente oder Bedeutungen definiert, sondern sich so strikt wie moeglich an das bereits etabliert haelt. Fuer mich ist das die englischsprachige Mapfeatures-Liste, da dort die Community-Kontrolle am staerksten ausgepraegt sein duerfte. Ich trage also nichts ein, was nicht auch in dieser Liste steht, und versuche auch allgemein eine Ausrichtung an dieser Liste zu unterstuetzen (z.B. durch das Schreiben dieses Textes). Unnötige Tags will sicher keiner definieren. Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Sven Geggus schrieb: Sebastian Hohmann m...@s-hohmann.de wrote: Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. Die Admins und Programmierer treffen natürlich Entscheidungen bezüglich der Websites, der API (wie läuft das eigentlich?) oder der Anwendungen rund um OSM. Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Vielleicht solltest Du mal diverse papers über crowdsourcing etc. lesen um bevor Du hier solchen Unfug forderst. Ohne das freie Tagging wäre OSM nicht das geworden was es heute ist, da bin ich fest davon überzeugt. Ich fordere garnichts, ich mache Vorschläge. Wenn die Schwachsinn sind oder falsch verstanden werden, dann kann man das auch freundlicher formulieren. Nicht jeder hat was-auch-immer studiert um darüber Bescheid zu wissen oder die Begriffe genau einsetzen zu können. Wenn man als Mapper irritiert über sowas ist, dann sollte man vielleicht lieber im Wiki oder sonstwo aufklären. Du bist nicht zufällig der selbe Mensch wie dieser roadrunner66 im Heiseforum, der ganz Ähnliches Zeug schreibt? Nein. Der Cathedral Style funktioniert im Umfeld freier Software und freiem Content einfach nicht besonders gut. Das inzwischen berühmte the cathedral and the bazaar kennst Du aber schon oder? Nein, bisher nicht. Einen Chef der hier alles überwacht wünsche ich mir auch garnicht. Es wäre naiv zu glauben, dass das in so einer Community funktioniert. Ich will nur ein bisschen in Richtung eindeutigere Dokumentation arbeiten. Da gibt es vielleicht unterschiedliche Ansichten und Möglichkeiten, wie sowas zu erreichen ist. Aber ich will weder einen Bot durchlaufen lassen, der 'inoffizielle' Tags löscht noch sonst irgendwas vorschreiben, wie hier teilweise der Anschein erweckt wird. Ich wollte nur mal ganz offen darüber reden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Wie bekommst du heraus was sich am Ende durchsetzt? Die Bedeutung eines Tags kann man nicht in den Daten ablesen. Abstimmungen sind nicht repräsentativ, das Meinungsbild hier in der Liste oder im Forum repräsentiert auch nicht alle Mapper. natuerlich geht das. man schaut einfach in der datenbank nach, was fuer einen bestimmten fall amn meisten benutzt wird. Unnötige Tags will sicher keiner definieren. jeder der was neues einbringt, hat sich sicher was dabei gedacht. das muss nicht unbedingt gleich perfekt sein, deutet aber oft auf eine luecke hin und regt diskussionen an. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo Sven, crowdsourcing Gibt es darüber Texte in deutscher Sprache? Dann wäre es sinnvoll das etwas zu verbreiten. Ohne das freie Tagging wäre OSM nicht das geworden was es heute ist Das denke ich auch. Gleichzeitig denke ich, dass Projekte einen bestimmten Reifegrad nur überschreiten, wenn sie auch andere Methoden integrieren. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Sebastian Hohmann schrieb: Mir ging es eher darum, dass das Anlieger frei eigentlich nur für Fahrzeuge (in Kombination mit Zeichen 250) oder sogar nur für motorisierte Fahrzeuge (Zeichen 260) gilt. access=destination gilt aber (eigentlich, der Logik entsprechend) für alle Verkehrsteilnehmer. Das ist ein generelles Problem von OSM. Man müsste einen Weg finden, dass man die Tags nur bestimmten Gruppen zuordnet. Im einfachsten Fall würde es z.B. mit access:car=destination oder ähnlichem gehen. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Das entspricht auch genau meiner Vorstellung. Aber ich denke, man sollte das in einem separaten Thema genauer betrachten. Dieses hier wird sonst zu sehr überfrachtet. André signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Wie bekommst du heraus was sich am Ende durchsetzt? Die Bedeutung eines Tags kann man nicht in den Daten ablesen. Abstimmungen sind nicht repräsentativ, das Meinungsbild hier in der Liste oder im Forum repräsentiert auch nicht alle Mapper. natuerlich geht das. man schaut einfach in der datenbank nach, was fuer einen bestimmten fall amn meisten benutzt wird. Dann musst du aber für jeden Fall hingehen und schauen wie es in der Realität aussieht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hi! Frederik Ramm schrieb: In der Praxis ist es eine Art Akklamations-System. Wenn Du an den Map Features was aenderst und die Leute auf der Talk-Liste das gut finden oder zumindest niemand gross protestiert, dann ist die Aenderung drin. Wenn Du einfach so was eintraegst, was Dir grad einfaellt, ohne dass es dazu was auf der Liste oder wenigstens eine Diskussion im Wiki gab oder so, wird jemand anders es vermutlich wieder rauswerfen. Ok, ich kann mir vorstellen wie das für Zusatztags funktioniert - die defaultmäßig ignoriert werden - oder wie man sagt: Viel benutzt muß wohl was bedeuten. Aber wie sieht es bei den kniffligeren Themen aus? Ich versuch' ja grade den Knoten um das Tag access=designated aufzulösen. Es wird massenhaft benutzt, aber leider nach mindestens zwei gegensätzlichen Prinzipien. Wenn wir auf Basis der Daten jemals sinnvoll routen wollen, müssen wir das Problem in den Griff kriegen. Ich bin auch erst mal auf den scheinbare definierten Prozeß reingefallen, und hab ein aufwändiges Proposal ausgearbeitet. Erschien mir auch sinnvoll, um die Sache möglichst deutlich darzulegen. Jetzt hör' ich daß ein Proposal mit erfolgreicher Diskussion und Vote auch nix bringt. Wie will man solche Kontroversen dann auflösen? Diskussion auf der Mailingliste hatten wir schon mehrfach. War gut, um die gegensätzlichen Meinungen zu umreißen, aber keine Spur einer Einigung. Ist nach meiner Analyse auch gar nicht möglich, da uns schlichtweg noch ein Tag fehlt um beide Hauptmeinungen zufriedenzustellen. Einfach loslegen und wild die eigene Meinung in die DB schreiben dürfte bei so vehement vertretenen Meinungen auch nur einen fürchterlichen Editwar auslösen. Wenn also ein Proposal nix wert ist, wie dann? bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo! Sebastian Hohmann schrieb: Guenther Meyer schrieb: du machst viele schoene vorschlaege, aber glaube kaum, dass sich das umsetzen laesst. aber lass dich nicht davon abbringen, vielleicht hast du ja mehr erfolg als andere. Ich hab jetzt schon keine Lust mehr. Laß Dich nicht so schnell entmutigen. Mir gings genauso, zuerst begeistert und nach den ersten Versuchen, etwas zu verbessern, reichlich frustriert. Die Mühlen mahlen langsam und chaotisch, aber es gibt auch eine erhebliche Menge von Leute, die wie Du die Dinge gerne verbessern und vorantreiben wollen. Und möglichst konkrete, zuverlässige Ergebnisse erarbeiten. Wenn sich ein paar davon zusammenfinden, geht auch was vorwärts. Nur die optimistische Annahme, daß alle Leute das wollen, davon mußt Du Dich leider verabschieden. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Aber wie sieht es bei den kniffligeren Themen aus? Ich versuch' ja grade den Knoten um das Tag access=designated aufzulösen. Es wird massenhaft benutzt, aber leider nach mindestens zwei gegensätzlichen Prinzipien. Die Geschichte war ungefaehr so: Es gab highway=footway und highway=cycleway. Die waren sehr weit verbreitet, und im Grunde war allen klar, worum es ging: Ein Fussweg ist tendenziell nicht zum Fahrradfahren da, aber man kann schon mal durch, wenn man nicht grad Leute umfaehrt. Ein Fahrradweg ist hauptsaechlich fuer Fahrraeder, aber man kann auch zu Fuss. So richtig klar waren diese was man auch kann-Defaults nie, und es wurde immer empfohlen, im Zweifel ein foot=yes/no an den Radweg und/oder ein bicycle=yes/no an den Fussweg dranzuschreiben, um es ganz klar zu machen. Einige waren damit aber nicht zufrieden und wollten das alles irgendwie aufraeumen. Was ist mit Benutzungspflicht, was ist mit gleichberechtigten Rad/Fusswegen... viele kamen damit nicht klar, dass highway=cycleway foot=yes genau das gleiche sein sollte wie highway=footway bicycle=yes (das muss doch einheitlich... usw.) Also gab es das grosse highway=path-Proposal. Da wollte ein paar Leute mal so richtig aufraeumen und alles gleich richtig(tm) machen. highway=footway und highway=cycleway sollten komplett abgeschafft werden und ersetzt werden durch 2er oder 3er-Kombinationen; highway=cycleway sollte z.B. zu highway=path+bicycle=designated+foot=yes. Die Idee dabei war, dass man mit designated dasjenige auszeichnet, was es eben lt. Strassenverkehrsordnung oder der jeweils zutreffenden ist. designated also im Sinne von gewidmet oder so. Das Hauptproblem dabei war, dass die Proponenten dieses ganzen Proposals sich anmassen wollten, aufgrund der paar Stimmen, die da so zusammenkommen, die ganze Datenbank weltweit zu aendern und ueber den Haufen zu werfen, woran sich haufenweise Leute gewoehnt hatten. Da ist meiner Meinung nach einfach politisch sehr unklug vorgegangen worden - da waren vielleicht auch Leute dabei, die dachten, vote ist vote und wer sich nicht beteiligt der hat halt auch kein Mitspracherecht oder so. Am Ende kam es zu einer Abstimmung mit recht hoher Beteiligung fuer OSM-Verhaeltnisse, in der das path-Proposal grundsaetzlich angenommen, die Abloesung von cycleway/footway aber abgelehnt wurde: http://wiki.openstreetmap.org/wiki/Approved_features/Path Jetzt stehen wir da und haben das designated, das in Zusammenhang mit cycleway/footway wenig Sinn macht und hauptsaechlich Verwirrung stiftet und irgendwie doch nicht genau das ist, was die Leute wollen. (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) Wenn wir auf Basis der Daten jemals sinnvoll routen wollen, müssen wir das Problem in den Griff kriegen. Solche Sprueche gehen bei mir zu einem Ohr rein und zum andern wieder raus. Das kommt hier auf der Liste einmal im Monat: Wenn sich dies und das nicht aendert, wird dies und jenes nie moeglich sein. - Meist geht es dann eben doch irgendwie, zwar nur mit einer 80%-Loesung, aber dafuer ohne gleich eine Revolution anzuzetteln. Ich bin auch erst mal auf den scheinbare definierten Prozeß reingefallen, und hab ein aufwändiges Proposal ausgearbeitet. Erschien mir auch sinnvoll, um die Sache möglichst deutlich darzulegen. Jetzt hör' ich daß ein Proposal mit erfolgreicher Diskussion und Vote auch nix bringt. Das ist m.E. so ein typischer Anfaengerfehler: 1. Du stellst fest, dass Du gern etwas ausdruecken moechtest, wofuer es aber kein etabliertes Schema gibt. 2. Du nimmst an, dass es vielen anderen genauso geht, und dass lediglich keiner von denen bislang die Musse oder den Eifer oder die Intelligenz besass, ein Schema aufzustellen und zu etablieren. 3. Du machst Dir die Muehe und wunderst Dich, dass es relativ wenige Leute interessiert. Es ist ja nicht so, dass es nichts bringt. Aber zu dem Konzept gehoeren eben auch die Leute, denen es ein Anliegen ist, diese Information zu erfassen. Und gaebe es derer viele, so haette sich auch schon eine Methode etabliert. Die Annahme, dass die Welt nur auf das Proposal gewartet hat, ist also oft nicht gerechtfertigt. Wie will man solche Kontroversen dann auflösen? Diskussion auf der Mailingliste hatten wir schon mehrfach. War gut, um die gegensätzlichen Meinungen zu umreißen, aber keine Spur einer Einigung. Ist nach meiner Analyse auch gar nicht möglich, da uns schlichtweg noch ein Tag fehlt um beide Hauptmeinungen zufriedenzustellen. Einfach loslegen und wild die eigene Meinung in die DB schreiben dürfte bei so vehement vertretenen
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: [Snip] Das Hauptproblem dabei war, dass die Proponenten dieses ganzen Proposals sich anmassen wollten, aufgrund der paar Stimmen, die da so zusammenkommen, die ganze Datenbank weltweit zu aendern und ueber den Haufen zu werfen, woran sich haufenweise Leute gewoehnt hatten. Da ist meiner Meinung nach einfach politisch sehr unklug vorgegangen worden - da waren vielleicht auch Leute dabei, die dachten, vote ist vote und wer sich nicht beteiligt der hat halt auch kein Mitspracherecht oder so. Am Ende kam es zu einer Abstimmung mit recht hoher Beteiligung fuer OSM-Verhaeltnisse, in der das path-Proposal grundsaetzlich angenommen, die Abloesung von cycleway/footway aber abgelehnt wurde: http://wiki.openstreetmap.org/wiki/Approved_features/Path Jetzt stehen wir da und haben das designated, das in Zusammenhang mit cycleway/footway wenig Sinn macht und hauptsaechlich Verwirrung stiftet und irgendwie doch nicht genau das ist, was die Leute wollen. Ich war ja jahrelang ein Verfechter für die Proposals und das Voting. Aber hier kann ich dir nur zustimmen. Aus meiner persönlichen Sicht war Voting immer ein Mechanismus um bei Proposals für *neue* Tags möglichst schnell einen Konsens zu finden wie es wohl am besten zu machen ist (damit diese nicht Ewigkeiten in der Luft hängen). Wenn sich dann später ein Problem rausstellt ändert man es halt. ABER - man wirft mit einem Proposal nicht alles über den Haufen was es bisher gab und geht davon aus das sich dann alle dran halten! Da war ich wohl zu naiv. Dieses Beispiel zeigt mir, daß Voting zwar einige Probleme lösen wird, aber andere neue schafft ... :-( Wenn wir auf Basis der Daten jemals sinnvoll routen wollen, müssen wir das Problem in den Griff kriegen. Solche Sprueche gehen bei mir zu einem Ohr rein und zum andern wieder raus. Das kommt hier auf der Liste einmal im Monat: Wenn sich dies und das nicht aendert, wird dies und jenes nie moeglich sein. - Meist geht es dann eben doch irgendwie, zwar nur mit einer 80%-Loesung, aber dafuer ohne gleich eine Revolution anzuzetteln. Die Frage ist, wie wir von der 80% Lösung weiter voran kommen. Aber da muß man garnicht so skeptisch sein. Neulich auf dem Stand vom 25C3 kam häufiger die Frage wie sieht es aus mit Routing?. Wenn ich mir die aktuellen Lösungen bei OpenRouteService und Konsorten anschaue sieht es doch schon gut aus. Die Spezialitäten wie hier dürfen Sie nicht links abbiegen sind natürlich wichtig, aber im Vergleich der OSM Datenmenge so wenige, das die bei OSM *sehr schnell* enthalten sein werden! Spätestens wenn die ersten OSM Navis wirklich verwendet werden ist das in D aus meiner Sicht eine Sache von Wochen. Ich bin auch erst mal auf den scheinbare definierten Prozeß reingefallen, und hab ein aufwändiges Proposal ausgearbeitet. Erschien mir auch sinnvoll, um die Sache möglichst deutlich darzulegen. Jetzt hör' ich daß ein Proposal mit erfolgreicher Diskussion und Vote auch nix bringt. Das ist m.E. so ein typischer Anfaengerfehler: 1. Du stellst fest, dass Du gern etwas ausdruecken moechtest, wofuer es aber kein etabliertes Schema gibt. 2. Du nimmst an, dass es vielen anderen genauso geht, und dass lediglich keiner von denen bislang die Musse oder den Eifer oder die Intelligenz besass, ein Schema aufzustellen und zu etablieren. 3. Du machst Dir die Muehe und wunderst Dich, dass es relativ wenige Leute interessiert. Es ist ja nicht so, dass es nichts bringt. Aber zu dem Konzept gehoeren eben auch die Leute, denen es ein Anliegen ist, diese Information zu erfassen. Und gaebe es derer viele, so haette sich auch schon eine Methode etabliert. Die Annahme, dass die Welt nur auf das Proposal gewartet hat, ist also oft nicht gerechtfertigt. Wie will man solche Kontroversen dann auflösen? Diskussion auf der Mailingliste hatten wir schon mehrfach. War gut, um die gegensätzlichen Meinungen zu umreißen, aber keine Spur einer Einigung. Ist nach meiner Analyse auch gar nicht möglich, da uns schlichtweg noch ein Tag fehlt um beide Hauptmeinungen zufriedenzustellen. Einfach loslegen und wild die eigene Meinung in die DB schreiben dürfte bei so vehement vertretenen Meinungen auch nur einen fürchterlichen Editwar auslösen. Mir ist noch immer nicht ganz klar, um welche konkrete Kontroverse es hier eigentlich geht. Im allgemeinen ist OSM ein extrem pragmatisches Projekt, und Resultate zaehlen in der projekt-oeffentlichen Meinung sehr viel. Das heisst, die Leute wollen weniger Sprueche wie: Wir muessen dies und jenes machen, sonst geht alles den Bach runter hoeren oder Wenn wir jetzt alles dies und jenes tun, dann koennen wir in einem Jahr so-und-so erreichen, sondern: Schaut mal, ich hab dies hier gemacht, und jetzt geht das und das ganz toll - macht es doch auch so wie ich! Eine sehr schoene Illustration davon ist die Sache mit den route-Relationen fuer Fahrradrouten. Als
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hi! Frederik Ramm schrieb: Jetzt stehen wir da und haben das designated, das in Zusammenhang mit cycleway/footway wenig Sinn macht und hauptsaechlich Verwirrung stiftet und irgendwie doch nicht genau das ist, was die Leute wollen. (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) Nur so aus Neugierde: Welche Stelle zitierst Du da? Die habe ich glaub ich bisher noch nicht gefunden. Ich bin ziemlich exakt Deiner Meinung, daß es völlig klar ist, was es bedeutet. Aber eben halt leider nur für uns. Leider hat jemand auf der Map Features Seite verewigt: For designated cycleways; i.e., mainly/exclusively for bicycles Und so gibt es zahlreiche Leute die das anders verstehen. Argumentation ist häufig entweder daß man sich auf das mainly bezieht oder darauf, daß man das schon früher so gehandhabt hat. Für diese Lesart heißt designated nur irgendwie vorgesehen. Wenn wir auf Basis der Daten jemals sinnvoll routen wollen, müssen wir das Problem in den Griff kriegen. Solche Sprueche gehen bei mir zu einem Ohr rein und zum andern wieder raus. Das kommt hier auf der Liste einmal im Monat: Wenn sich dies und das nicht aendert, wird dies und jenes nie moeglich sein. - Meist geht es dann eben doch irgendwie, zwar nur mit einer 80%-Loesung, aber dafuer ohne gleich eine Revolution anzuzetteln. Dann laß es mich anders formulieren: Kannst Du Dir eine technische Lösung vorstellen, wie man eine Routenführung auf dieses Tagging stützt, wenn designated in 50% der Fälle bedeutet: verpflichtend für die einen, verboten für die anderen und in den anderen 50%: für die einen vorgesehen, aber vielleicht genausogut für andere benutzbar und man keine Möglichkeit hat, den Unterschied festzustellen? Und mein Vorschlag ist gezielt so formuliert, daß er eine Ergänzung darstellt, keine Revolution. Ich bin auch erst mal auf den scheinbare definierten Prozeß reingefallen, und hab ein aufwändiges Proposal ausgearbeitet. Erschien mir auch sinnvoll, um die Sache möglichst deutlich darzulegen. Jetzt hör' ich daß ein Proposal mit erfolgreicher Diskussion und Vote auch nix bringt. Das ist m.E. so ein typischer Anfaengerfehler: 1. Du stellst fest, dass Du gern etwas ausdruecken moechtest, wofuer es aber kein etabliertes Schema gibt. 2. Du nimmst an, dass es vielen anderen genauso geht, und dass lediglich keiner von denen bislang die Musse oder den Eifer oder die Intelligenz besass, ein Schema aufzustellen und zu etablieren. 3. Du machst Dir die Muehe und wunderst Dich, dass es relativ wenige Leute interessiert. Im Prinzip ja. Nur daß es das Schema schon gibt und es mir auch gefällt, aber es leider nicht funktioniert, weil die Leute unvereinbare Interpretationen haben und mit viel Eifer vergeblich versuchen, das gegensätzliche Lager davon zu überzeugen, daß ihre Meinung ganz offensichtlich die einzig richtige Interpretation ist. Es ist ja nicht so, dass es nichts bringt. Aber zu dem Konzept gehoeren eben auch die Leute, denen es ein Anliegen ist, diese Information zu erfassen. Und gaebe es derer viele, so haette sich auch schon eine Methode etabliert. Die Annahme, dass die Welt nur auf das Proposal gewartet hat, ist also oft nicht gerechtfertigt. Na, ich denke die Leute sind da. Jedesmal wenn jemand hier auf der Liste eine scheinbar harmlose Tagging-Frage dazu stellt, explodiert die Diskussion ja förmlich. Ich hatte den Eindruck daß schon eine Menge Leute die gesetzliche Lage exakt wiedergeben wollen, aber hauptsächlich im Streit mit den anderen liegen, die die Bedeutung lockerer sehen. Darum kann ich mir eigentlich ganz gut vorstellen, daß diese Leute Interesse an einer Nachbesserung haben - in dem Fall ein Tag was eindeutig die offizielle Widmung beschreibt, die sie die ganze Zeit ausdrücken wollen, und sonst nix. Bloß wie soll man diese Leute am besten ansprechen und für eine Lösung begeistern? Mir ist noch immer nicht ganz klar, um welche konkrete Kontroverse es hier eigentlich geht. Die ausführliche Version ist im Proposal nachzulesen [1] Kernidee ist die: - Es gibt eine Fraktion, für die designated bedeutet: Gesetzlich gewidmet - Es gibt eine Fraktion, für die designated bedeutet: In irgendeiner Form dafür vorgesehen oder vermutlich dafür vorgesehen - Die Leute, die die Gesetzeslage exakt darstellen wollen, brauchen ein Tag dafür. Das einzige was dafür in Frage kommt, ist designated. - Darum gibt es Streit um die Bedeutung und Verwendung von designated Lösungsvorschlag: - Nachdem für designated kein Konsens besteht, soll ein weiteres Tag official für die offizielle,
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Ekkehart wrote: (Fuer mich ist allerdings ziemlich eindeutig, was mit designated gemeint ist. Was genau ist an access=designated indicates that a route has been specially designated (typically by a government) for use by a particular mode (or modes) of transport. The specific meaning varies according to jurisdiction. It may imply extra usage rights for the given mode of transport, or may be just a suggested route. nicht klar?) Nur so aus Neugierde: Welche Stelle zitierst Du da? Die habe ich glaub ich bisher noch nicht gefunden. Die ist aus dem Path-Proposal, dessen URL ich weiter oben genannt hatte: http://wiki.openstreetmap.org/wiki/Approved_features/Path Dann laß es mich anders formulieren: Kannst Du Dir eine technische Lösung vorstellen, wie man eine Routenführung auf dieses Tagging stützt, wenn designated in 50% der Fälle bedeutet: verpflichtend für die einen, verboten für die anderen und in den anderen 50%: für die einen vorgesehen, aber vielleicht genausogut für andere benutzbar und man keine Möglichkeit hat, den Unterschied festzustellen? Ich wuerde das dem User der Software ueberlassen. Der soll ankreuzen, was er will. Gerade Fahrrad- und Fussgaengerrouting wird kaum jemand von Berlin nach Muenchen betreiben wollen - das ist eine lokale Sache, und ich gehe davon aus, dass lokal - wo die Leute sich auch mal bei Stammtischen treffen usw. - eher Einigkeit herrscht als national oder gar international. Es kommt dann halt dazu, dass man in Muenchen eventuell ein andres Haekchen setzen muss als in Berlin. Aber auch das ist weniger wild und zumindest fuer eine Uebergangszeit tolerierbar, finde ich. Ich bin ueberdies der Ansicht, dass das mit dem verpflichtend und verboten total ueberbewertet wird. Ich hab' mich da meinen Lebtag noch nicht drum gekuemmert - ich fahre und laufe da, wo es mir geeignet erscheint... ja, klar, es gibt Anwedungsfaelle. Aber es ist keinesfalls so, dass jeder, der ein Fahrrad benutzt, sich dafuer interessieren muss, wo jetzt eine Radwegbenutzungspflicht ist. Ich bin froh, wenn ein Router mich nicht ueber eine Autobahn schickt und mir gute Schleichwege aufzeigt, auf die ich sonst nicht gekommen waere. Mir ist noch immer nicht ganz klar, um welche konkrete Kontroverse es hier eigentlich geht. Die ausführliche Version ist im Proposal nachzulesen [1] Ach so, ich dachte, es haette was mit dem Proposal von Sebastian zu tun. Kernidee ist die: - Es gibt eine Fraktion, für die designated bedeutet: Gesetzlich gewidmet - Es gibt eine Fraktion, für die designated bedeutet: In irgendeiner Form dafür vorgesehen oder vermutlich dafür vorgesehen Ich sehe den Unterschied nicht so ganz. Wer sonst ausser dem Erbauer kann einen Weg denn fuer etwas vorsehen, und an was ausser dem Gesetz wird sich der Erbauer dabei halten? Und das mit dem vermutlich ist was, was Du ueberall hast - fast alles, was in OSM getaggt wird, hat irgendwo diese vermutlich-Einschraenkung. Wir sind ja nicht die Wikipedia, wo ploetzlich an jedem highway=secondary ein * citation needed dransteht und man erst auf die entsprechende amtliche Publikation verweisen muss ;-) - Nachdem für designated kein Konsens besteht, soll ein weiteres Tag official für die offizielle, gesetzliche Widmung eingeführt werden. - Designated bleibt dann weiter in der unpräzisen Form im Einsatz - wer traditionell arbeiten will taggt mit designated wie er es interpretiert - wer präzise taggen will, kann das neue Tag official benutzen und weiß, daß er damit seine Aussage eindeutig rüberbringt - Renderer und Router können sich auf das zuverlässigere Tag stützen Und das findest Du wirklich gut? Klingt fuer mich halt sehr nach die Farbe von dem Haus ist nicht mehr so schoen, bauen wir doch nebendran ein neues und lassen das andre verrotten. Wenn ich Dich recht verstehe, heißt das: Mein akutes Problem ist, daß ich für meine Reit- und Wanderkarte verlässliche Informationen brauche, welche Wege ich als Reiter benutzen darf und welche nicht. Ich habe versucht, designated auszuwerten, mit dem Ergebnis daß mit dem jetzigen Gebrauch keine Aussage von diesem Tag abgeleitet werden kann Moeglicherweise haengt das auch mit dem Fokus auf Reiten zusammen. Ich koennte mir vorstellen, dass es da bei vielen einfach keine ausreichende Sensibilisierung gibt. (Ich habe in meinem Leben vielleicht 5 mal einen Weg gesehen, der ein horse=designated bekommen haette.) mal dieses und mal jenes bedeutet. Ganz praktisch waren ein großer Teil der getaggten footways und cycleways (=verboten) in der Realität einfach nur unbeschilderte tracks (=erlaubt). Tracks oder paths? Ein Track ist ja immer breit genug fuer ein vierraedriges Fahrzeug. Hier in Karlsruhe hatten wir anfangs, also ganz zu Anfang, die Situation, dass selbst vollwertige Strassen z.T. als Cycleway getaggt waren - weil der, der sie erfasst hat (hallo Christoph ;-)) halt mit dem Rad da langfuhr und manchmal am
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb André Reichelt: Sebastian Hohmann schrieb: Mir ging es eher darum, dass das Anlieger frei eigentlich nur für Fahrzeuge (in Kombination mit Zeichen 250) oder sogar nur für motorisierte Fahrzeuge (Zeichen 260) gilt. access=destination gilt aber (eigentlich, der Logik entsprechend) für alle Verkehrsteilnehmer. Das ist ein generelles Problem von OSM. Man müsste einen Weg finden, dass man die Tags nur bestimmten Gruppen zuordnet. Im einfachsten Fall würde es z.B. mit access:car=destination oder ähnlichem gehen. André zu dem thema gabs schonmal eine diskussion mit eigentlich ganz sinnvollen ansaetzen. leider hat da keiner ein proposal daraus gemacht, bzw. das sonst irgendwie ins wiki geschoben... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Frederik Ramm: Wenn wir auf Basis der Daten jemals sinnvoll routen wollen, müssen wir das Problem in den Griff kriegen. Solche Sprueche gehen bei mir zu einem Ohr rein und zum andern wieder raus. Das kommt hier auf der Liste einmal im Monat: Wenn sich dies und das nicht aendert, wird dies und jenes nie moeglich sein. - Meist geht es dann eben doch irgendwie, zwar nur mit einer 80%-Loesung, aber dafuer ohne gleich eine Revolution anzuzetteln. das hier nimmt jetzt wahrscheinlich genau denselben weg bei dir ;-) nie moeglich ist nicht richtig, da muss ich dir zustimmen. eine 80%-loesung ist sicher besser als gar keine, aber selbst fuer diese muss man oft einen aufwand betreiben, der wertvolle zeit kostet, die man besser einsetzen koennte, waeren die daten schon in der basis eindeutiger. und die restlichen 20% zu erreichen wird dann aeusserst komplex oder wirklich nicht realisierbar. 1. Du stellst fest, dass Du gern etwas ausdruecken moechtest, wofuer es aber kein etabliertes Schema gibt. 2. Du nimmst an, dass es vielen anderen genauso geht, und dass lediglich keiner von denen bislang die Musse oder den Eifer oder die Intelligenz besass, ein Schema aufzustellen und zu etablieren. 3. Du machst Dir die Muehe und wunderst Dich, dass es relativ wenige Leute interessiert. Es ist ja nicht so, dass es nichts bringt. Aber zu dem Konzept gehoeren eben auch die Leute, denen es ein Anliegen ist, diese Information zu erfassen. Und gaebe es derer viele, so haette sich auch schon eine Methode etabliert. Die Annahme, dass die Welt nur auf das Proposal gewartet hat, ist also oft nicht gerechtfertigt. naja, so einfach laesst sich das jetzt auch nicht sagen. die einen benutzen tags, die vorhanden sind, weil es taugt ja, oder ist nicht optimal, aber tut's irgendwie, und andere machen sich gedanken (auf die die masse nie kommen wuerde, einfach weil sie sich als reine anwender nicht damit beschaeftigen), weil sie eine konkrete auswertung der daten im hinterkopf haben, und die nutzbarkeit des ganzen erhoehen moechten. dass das oft kaum jemanden interessiert, einfach weil viele nicht den zugang dazu haben, ist dann auch klar. Wie will man solche Kontroversen dann auflösen? Diskussion auf der Mailingliste hatten wir schon mehrfach. War gut, um die gegensätzlichen Meinungen zu umreißen, aber keine Spur einer Einigung. Ist nach meiner Analyse auch gar nicht möglich, da uns schlichtweg noch ein Tag fehlt um beide Hauptmeinungen zufriedenzustellen. Einfach loslegen und wild die eigene Meinung in die DB schreiben dürfte bei so vehement vertretenen Meinungen auch nur einen fürchterlichen Editwar auslösen. Mir ist noch immer nicht ganz klar, um welche konkrete Kontroverse es hier eigentlich geht. Im allgemeinen ist OSM ein extrem pragmatisches Projekt, und Resultate zaehlen in der projekt-oeffentlichen Meinung sehr viel. Das heisst, die Leute wollen weniger Sprueche wie: Wir muessen dies und jenes machen, sonst geht alles den Bach runter hoeren oder Wenn wir jetzt alles dies und jenes tun, dann koennen wir in einem Jahr so-und-so erreichen, sondern: Schaut mal, ich hab dies hier gemacht, und jetzt geht das und das ganz toll - macht es doch auch so wie ich! Eine sehr schoene Illustration davon ist die Sache mit den route-Relationen fuer Fahrradrouten. Als Andy Allan seine Fahrradkarte gemacht hat, hat er keinesfalls erst ein Proposal aufgestellt und gehofft, dass die Leute das alle toll finden, sondern er hat sich fuer seine Gegend lokal ueberlegt, wie er die Radwege vernuenftig taggt, und dann diese Karte vorgezeigt, und in Nullkommanix wollte jeder wissen, wie er seinen Radweg taggen muss, damit der auch so schoen auf die Karte kommt. Im Fall Deines Proposals mit den Fahrrad- und Fusswegen auf verschiedenen Strassenseiten und so weiter fehlt halt die success story, die die Leute sagen laesst: Geil, das will ich in meiner Stadt auch! Wenn Du Dein Proposal einfach mal fuer eine Gegend durchziehen wuerdest und eine Routingsoftware schreibst, die - und sei es nur prototypisch fuer eine Stadt, das ist ja vom Algorithmus her nicht der Rede wert - dann aufgrund der detaillieren Informationen Instruktionen generiert wie wechseln Sie an der Ampel die Strassenseite oder die sonst eben grossartige Moeglichkeiten bietet, die ueber etablierte Routingsysteme hinausgehen, dann waere es sicherlich viel leichter, die Leute fuer solche Details zu sensibilisieren. Grundsaetzlich ist ein Proposal der Art ich tagge auf diese und jene Weise, und damit habe ich gute Erfahrungen gemacht und nun kann ich diese coole Applikation hier nutzen viel ueberzeugender als ein aeh, also, ich koennte mir vorstellen dass es cool waere wenn wir alle in Zukunft auf diese und jene Weise taggen würden, dann könnte irgendjemand bestimmt auch mal eine coole Applikation schreiben Es wird manchmal gesagt, OpenStreetMap sei eine Doocracy, also ein
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Ulf Lamping: Die Frage ist, wie wir von der 80% Lösung weiter voran kommen. Aber da muß man garnicht so skeptisch sein. Neulich auf dem Stand vom 25C3 kam häufiger die Frage wie sieht es aus mit Routing?. Wenn ich mir die aktuellen Lösungen bei OpenRouteService und Konsorten anschaue sieht es doch schon gut aus. Die Spezialitäten wie hier dürfen Sie nicht links abbiegen sind natürlich wichtig, aber im Vergleich der OSM Datenmenge so wenige, das die bei OSM *sehr schnell* enthalten sein werden! Spätestens wenn die ersten OSM Navis wirklich verwendet werden ist das in D aus meiner Sicht eine Sache von Wochen. klar, aus der notwendigkeit entsteht irgendwann dann die aktion. dumm halt, dass diese notwendigkeit auf entwicklerseite schon lange vorher bekannt ist, man sich aber zu dem zeitpunkt echt schwer tut, die masse davon zu ueberzeugen. zumindest geht's mir so... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Donnerstag 22 Januar 2009 schrieb Frederik Ramm: Kernidee ist die: - Es gibt eine Fraktion, für die designated bedeutet: Gesetzlich gewidmet - Es gibt eine Fraktion, für die designated bedeutet: In irgendeiner Form dafür vorgesehen oder vermutlich dafür vorgesehen Ich sehe den Unterschied nicht so ganz. Wer sonst ausser dem Erbauer kann einen Weg denn fuer etwas vorsehen, und an was ausser dem Gesetz wird sich der Erbauer dabei halten? Und das mit dem vermutlich ist was, was Du ueberall hast - fast alles, was in OSM getaggt wird, hat irgendwo diese vermutlich-Einschraenkung. Wir sind ja nicht die Wikipedia, wo ploetzlich an jedem highway=secondary ein * citation needed dransteht und man erst auf die entsprechende amtliche Publikation verweisen muss ;-) naja, wenn der gesetzgeber ein bestimmtes schild hinstellt, wird er sich schon was dabei gedacht haben (wie sinnvoll das ist, steht sowieso auf einem ganz anderen blatt...). verkehrsrechtlich ist das aber bindend. ein beschilderter radweg erlaubt darauf nunmal keine fussgaenger, auch wenn es moeglich ist. ich sehe halt durchaus die moeglichkeit folgender situation: es kommt mehrfach vor, dass fussgaenger auf reinen radwegen rumlaufen (oder umgekehrt), und damit die jeweils dort sich legal bewegenden behindern, oder sogar unfaelle provozieren. wenn dann wiederholt als antwort der verursacher sowas kommt wie ...aber mein osm-navi hat mich da hin geschickt..., wird ganz schnell die aussage entstehen dieser osm-sch... osm taugt nicht zum routen natuerlich kann osm nicht verantwortlich fuer das verkehrswidrige verhalten seiner nutzer gemacht werden, aber fuer das image ist das trotzdem nicht gut... - Nachdem für designated kein Konsens besteht, soll ein weiteres Tag official für die offizielle, gesetzliche Widmung eingeführt werden. - Designated bleibt dann weiter in der unpräzisen Form im Einsatz - wer traditionell arbeiten will taggt mit designated wie er es interpretiert - wer präzise taggen will, kann das neue Tag official benutzen und weiß, daß er damit seine Aussage eindeutig rüberbringt - Renderer und Router können sich auf das zuverlässigere Tag stützen Und das findest Du wirklich gut? Klingt fuer mich halt sehr nach die Farbe von dem Haus ist nicht mehr so schoen, bauen wir doch nebendran ein neues und lassen das andre verrotten. man macht keine radikale aenderung, sondern man bietet eine (wahrscheinlich) bessere moeglichkeit an, und hofft, dass sie verwendet wird. so funktioniert das doch bei osm? oder hab ich da schon wieder was falsch verstanden? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Guenther Meyer schrieb: Am Mittwoch 21 Januar 2009 schrieb Sebastian Hohmann: Wie bekommst du heraus was sich am Ende durchsetzt? Die Bedeutung eines Tags kann man nicht in den Daten ablesen. Abstimmungen sind nicht repräsentativ, das Meinungsbild hier in der Liste oder im Forum repräsentiert auch nicht alle Mapper. natuerlich geht das. man schaut einfach in der datenbank nach, was fuer einen bestimmten fall amn meisten benutzt wird. Dann musst du aber für jeden Fall hingehen und schauen wie es in der Realität aussieht. ach so, du meintest bedeutung im sinne von definition, und nicht die wichtigkeit. hab das jetzt in dem kontext anders verstanden... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Donnerstag, 22. Januar 2009 schrieb Guenther Meyer: klar, aus der notwendigkeit entsteht irgendwann dann die aktion. dumm halt, dass diese notwendigkeit auf entwicklerseite schon lange vorher bekannt ist, man sich aber zu dem zeitpunkt echt schwer tut, die masse davon zu ueberzeugen. zumindest geht's mir so... Gibt es schon einen Entwickler einer beliebigen Routing-Engine, der ein Statement veröffentlicht hat, welche Abbiegeverbote er in seinem Programm auswerten wird? Gruß, Bernd -- In Binärzahlen zu zählen geht genauso wie in Dezimalzahlen zählen, nur daß man dafür nur die Daumen braucht. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Donnerstag, 22. Januar 2009 schrieb Guenther Meyer: ich sehe halt durchaus die moeglichkeit folgender situation: es kommt mehrfach vor, dass fussgaenger auf reinen radwegen rumlaufen (oder umgekehrt), und damit die jeweils dort sich legal bewegenden behindern, oder sogar unfaelle provozieren. wenn dann wiederholt als antwort der verursacher sowas kommt wie ...aber mein osm-navi hat mich da hin geschickt..., wird ganz schnell die aussage entstehen dieser osm-sch... osm taugt nicht zum routen Das halte ich für Mumpitz. Wenn das so ist, dass ein OSM-Navi einen da lang schicken will und das ist falsch, dann wird sich jemand finden, der ein foot=no da dran pappt. Unabhängig von jeder designated-Diskussion kann man mit foot=no nämlich genau das sagen. Genau so bei benutzungspflichtigen Radwegen: Wenn das Navi meint, man könnte auch auf der Straße fahren = Ein bicycle=no an die Straße und gut. Dazu bemerkt finde ich dass wir im falschen Jahrzehnt sind um uns über sowas Gedanken zu machen. Wann kommt denn die Situation, dass innerhalb einer Woche auf einer bestimmten Straße mehr als 2 Leute mit einem (selbstständig routenden) Fahrrad-Navi entlang fahren? man macht keine radikale aenderung, sondern man bietet eine (wahrscheinlich) bessere moeglichkeit an, und hofft, dass sie verwendet wird. so funktioniert das doch bei osm? oder hab ich da schon wieder was falsch verstanden? Man sollte halt irgendwelche Schritte unternehmen (z.B. besonders cooles Rendering, Auswertung in einem Navi) um einen großen Teil der Mapper davon zu überzeugen dass mit dem neueren Tag besser gemappt werden kann. Wenn ich mir für mich überlege ob ich alles mit yes/no ausdrücken will oder ob ich einen desigirgendwas-Zungenbrecher tippen will, dann ist mir klar was ich mache. Weil mir noch keiner wirklich begreiflich machen kann wofür man jetzt und heute wirklich was anderes braucht. Gruß, Bernd -- Ein Optimist lacht, um zu vergessen. Ein Pessimist vergißt zu lachen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Am 21. Januar 2009 00:17 schrieb Sebastian Hohmann m...@s-hohmann.de: Hallo, Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. ... Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Du hast Dir viel Mühe gegeben, mal wieder einen Vorstoß in Richtung ordentlich demokratisch zu wagen, das wurde schon des öfteren von verschiedenen Leuten angeregt, wird aber aller Voraussicht nach auch in Zukunft nicht kommen, und ich muss sagen, nachdem ich anfangs noch etwas skeptisch war, freue ich mich mittlerweile, dass das aktuelle System erstaunlich gut funktioniert. Im Moment scheint es mir eher so, dass es für alles einen eher schwammigen Konsens gibt, aber weniger klare (dokumentierte) Regeln. Was allerdings genau dieser Konsens ist und wieviele sich daran halten, ist nicht bekannt. die allermeisten halten sich dran, was der Konsens ist, siehst Du, wenn Du die Karten mit der Realität abgleichst, also wie bisher gemappt wurde (und da siehst Du auch, dass es an manchen Stellen noch keinen Konsens gibt (s. straßenbegleitende Radwege, Spuren, etc.)) Im Wiki ist zwar einiges dokumentiert, aber wirklich 'offiziell anerkannt' sind die Seiten dort auch nicht (nicht zuletzt weil jeder reinschreiben kann was er will). das stimmt nicht ganz. Die Community wacht darüber, was dort auf längere Sicht steht. Aber es kann ja irgendwie nicht sein, dass man bei Tags die sehr weit verbreitet sind, nicht genau weiß was sie bedeuten. das ist in der Regel auch nicht so, tags, die weit verbreitet sind, sind auch im Wiki dokumentiert. Falls Fragen offen bleiben: am besten die anderen fragen (hier in der Liste). Das Wiki-Prinzip mag ja funktionieren, aber auch dafür braucht es klare Regeln. Denn es kann niemand etwas korrigieren, von dem er nicht weiß wie man es 'richtig' macht. naja, das kannst Du Dir vorstellen wie Kinder erziehen: da weiss auch niemand, wie man es richtig macht, im Grunde macht man es so gut man kann und meist schöpft man aus der familiären Erfahrung (d.h. so, wie man selbst erzogen wurde oder denkt, dass man hätte erzogen werden sollen ;-) ). , wie oft z.B. ein highway=cycleway mit der Bedeutung 'benutzungspflichtiger Radweg' und wie oft mit der Bedeutung 'irgendein Weg auf der hauptsächlich zum Radfahren benutzt wird' vorkommt. wenn ich mit dem Fahrrad unterwegs bin, und das bin ich fast ausschließlich, dann ist das für mich praktisch egal, hauptsache ich kann mit dem Fahrrad dort fahren (gut, fairerweise muss ich dazusagen, dass Verkehrsregeln an meinem Wohnort deutlich freier ausgelegt werden als in Deutschland, und man sich mit dem Fahrrad überhaupt nicht dran halten muss). Das ist alles schön und gut, aber es gibt folgende Probleme: - Es machen zuwenig bei Abstimmungen mit um wenigstens etwas repräsentativ zu sein. tja, ich mache dort mit, aber eigentlich zeigt das ja, dass Dein Ansatz der formalen Demokratie aufgrund von Politikverdrossenheit zum Scheitern verurteilt ist. Die meisten der 70.000 Freizeitmapper haben offensichtlich keine Lust, das Gros ihrer Mapping-Zeit mit Regelverwaltung zu verbringen. - Es ist nicht klar definiert, wann ein Proposal angenommen ist (und was das bedeutet, siehe vorheriger Punkt). soweit ich weiss, gibt es da Regeln: mehr als 15 Beteiligungen (oder warens ja-stimmen) und mehr ja als nein-Stimmen. Gleichzeitig müssten Accepted Proposals auch für 'normale Mapper' leichter zugänglich sein. Also als 'gleichwertige' Tags gelten, die bloss aufgrund von geringer Verbreitung oder Wichtigkeit nicht zu den 'Haupttags' (Map Features) gehören. Beide, Map Features und Accepted Proposals sollten aber gleichermaßen eindeutig definiert sein, damit sie anständig benutzbar sind. das wäre m.E. noch unübersichtlicher, wenn man die features sozusagen noch auf 2 Seiten verteilt: wichtige und unwichtige. Lieber eine features-Liste. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Martin Koppenhoefer schrieb: Am 21. Januar 2009 00:17 schrieb Sebastian Hohmann m...@s-hohmann.de: Hallo, Mir ist in letzter Zeit immer wieder aufgefallen, dass es in OSM keine Möglichkeit gibt, richtige Entscheidungen zu treffen. ... Aber inbesondere das Mapping, die Tags, also letztlich der Bereich der OSM am Laufen hält, ist kaum reglementiert. Du hast Dir viel Mühe gegeben, mal wieder einen Vorstoß in Richtung ordentlich demokratisch zu wagen, das wurde schon des öfteren von verschiedenen Leuten angeregt, wird aber aller Voraussicht nach auch in Zukunft nicht kommen, und ich muss sagen, nachdem ich anfangs noch etwas skeptisch war, freue ich mich mittlerweile, dass das aktuelle System erstaunlich gut funktioniert. Den Eindruck dass es ausnahmslos funktioniert habe ich nicht, lasse mich aber gerne vom Gegenteil überzeugen. Im Moment scheint es mir eher so, dass es für alles einen eher schwammigen Konsens gibt, aber weniger klare (dokumentierte) Regeln. Was allerdings genau dieser Konsens ist und wieviele sich daran halten, ist nicht bekannt. die allermeisten halten sich dran, was der Konsens ist, siehst Du, wenn Du die Karten mit der Realität abgleichst, also wie bisher gemappt wurde (und da siehst Du auch, dass es an manchen Stellen noch keinen Konsens gibt (s. straßenbegleitende Radwege, Spuren, etc.)) Also ich sehe in der Interpretation von Tags teils erhebliche Unterschiede. Aber vielleicht gehen da auch unsere Erwartungen an die Genauigkeit der Daten auseinander. Im Wiki ist zwar einiges dokumentiert, aber wirklich 'offiziell anerkannt' sind die Seiten dort auch nicht (nicht zuletzt weil jeder reinschreiben kann was er will). das stimmt nicht ganz. Die Community wacht darüber, was dort auf längere Sicht steht. Auch den Eindruck habe ich nicht unbedingt. Auf vielen Wiki-Seiten stehen z.B. widersprüchliche Dinge (seit Jahren!), die eigentlich ausgeräumt sein müssten, wenn die Community tatsächlich so gut darüber wacht. Ebenso stehen (oder standen) dort Dinge, die z.B. hier in der Liste als falsch angesehen wurden über lange Zeit. Aber es kann ja irgendwie nicht sein, dass man bei Tags die sehr weit verbreitet sind, nicht genau weiß was sie bedeuten. das ist in der Regel auch nicht so, tags, die weit verbreitet sind, sind auch im Wiki dokumentiert. Falls Fragen offen bleiben: am besten die anderen fragen (hier in der Liste). Dann frage ich dich hiermit, was genau das über 10.000 mal benutzte access=destination bedeutet und welcher Deutschen Zugangsbeschränkung das entsprechen soll (falls du aus Deutschland kommst). Vielleicht bin ich hier ja auch zu kleinlich, aber als ich vor einiger Zeit mal hier auf der Liste nach sowas gefragt habe, kamen schätzungsweise von vielleicht 5 Leuten 4 verschiedene Antworten. Wenn man dabei die gleichen Antworten bekommen würden, wäre es ja kein Problem. Das Witzige dabei ist, dass access=* eigentlich für die 'allgemeine Zugangsbeschränkung' steht (also vermutlich für alle Verkehrsteilnehmer, vermutlich weil das im Wiki nicht klar steht). access=destination für alle Verkehrsteilnehmer (also inklusive Fußgänger, Radfahrer und Pferde) gibt es in Deutschland meines Wissens nach aber garnicht. Zudem noch zwischen Zeichen 250 (für alle Fahrzeuge) und Zeichen 260 (für alle Motorfahrzeuge, also Fahrräder erlaubt) unterschieden werden müsste. Gerade weil auch Fahrradrouting und andere 'exotischere' Dinge wie Pferderouting eigentlich mit OSM möglich sein sollten, müsste sowas eigentlich etwas genauer eingetragen werden. Das Wiki-Prinzip mag ja funktionieren, aber auch dafür braucht es klare Regeln. Denn es kann niemand etwas korrigieren, von dem er nicht weiß wie man es 'richtig' macht. naja, das kannst Du Dir vorstellen wie Kinder erziehen: da weiss auch niemand, wie man es richtig macht, im Grunde macht man es so gut man kann und meist schöpft man aus der familiären Erfahrung (d.h. so, wie man selbst erzogen wurde oder denkt, dass man hätte erzogen werden sollen ;-) ). Hmm.. Kinder sind aber auch keine Daten, die mit klar definierten Algorithmen verarbeitet werden sollen. , wie oft z.B. ein highway=cycleway mit der Bedeutung 'benutzungspflichtiger Radweg' und wie oft mit der Bedeutung 'irgendein Weg auf der hauptsächlich zum Radfahren benutzt wird' vorkommt. wenn ich mit dem Fahrrad unterwegs bin, und das bin ich fast ausschließlich, dann ist das für mich praktisch egal, hauptsache ich kann mit dem Fahrrad dort fahren (gut, fairerweise muss ich dazusagen, dass Verkehrsregeln an meinem Wohnort deutlich freier ausgelegt werden als in Deutschland, und man sich mit dem Fahrrad überhaupt nicht dran halten muss). Bei dem Beispiel ist es wieder eine Frage der Erwartungshaltung. Soll die Realität nur 'in etwa' abgebildet werden oder so genau wie möglich. Vielleicht bin ich da auch zu anspruchsvoll, mag sein. Das ist alles schön und gut, aber es
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm schrieb: Hallo, Sebastian Hohmann wrote: Aber es kann ja irgendwie nicht sein, dass man bei Tags die sehr weit verbreitet sind, nicht genau weiß was sie bedeuten. Das ist keinesfalls so selbstverständlich, wie Du mit dem es kann ja irgendwie nicht sein ausdrückst. Wenn Du mal ganz banale Dinge Deines alltäglichen Lebens betrachtest, dann weisst Du das wenigste genau; in den allermeisten Fällen hilft auch, etwas vage zu wissen oder einfach zu sagen: Hab ich bisher immer so gemacht, hat gut funktioniert, mach ich weiter so. - Wird Dir zum Beispiel auch bei Sprache so gehen, die ist ja doch nun recht weit verbreitet, und dennoch koennen viele Leute selbst Worte aus ihrem aktiven Wortschatz nicht richtig präzise definieren. Bricht deshalb die menschliche Kommunikation zusammen? Nein. Eine Programmiersprache würde so sicherlich nicht funktionieren. Aber anscheinend gibt es unterschiedliche Ansichten, wie OSM aussehen soll. befindlichen Tags so zu definieren und zu dokumentieren, dass man sie nachträglich auch eindeutig automatisiert interpretieren kann. Es ist sicherlich wünschenswert, Tags eindeutig automatisch interepretieren zu können. Aber dieses Ziel ist nicht absolut und hat nicht die höchste Priorität; man muss immer fragen, welcher Preis dafür zu zahlen ist und ob das Projekt sich diesen Preis leisten kann und will. Es ist keineswegs so, dass Tags, die sich nicht eindeutig, sondern nur mit hoher Wahrscheinlichkeit und Heuristik automatisch interpretieren lassen, wertlos sind - lediglich der Aufwand ist höher. Man muss sich allerdings auch fragen, ob es nicht sinnvoll wäre zumindest etwas in Richtung Eindeutigkeit zu arbeiten. Fragt sich auch wie man dann herausfinden soll, welche Interpretation die Richtige ist (oh, schon wieder das böse 'R'-Wort). Sagen wir eben die 'am ehesten der Realität entsprechende'. Man kann also nicht daraus ablesen, wie oft z.B. ein highway=cycleway mit der Bedeutung 'benutzungspflichtiger Radweg' und wie oft mit der Bedeutung 'irgendein Weg auf der hauptsächlich zum Radfahren benutzt wird' vorkommt. Ich weiss, dass sich daran viele Gemüter erhitzen, aber in the grand scheme of things, wie der Engländer sagen würde, ist es kein Thema von überragender Wichtigkeit. Sicherlich nicht, war auch nur ein Beispiel. Vielleicht könnten sich aber auch weniger Gemüter daran erhitzen und die Energie mehr in produktivere Dinge stecken, wenn man eine Lösung dafür finden würde. Die Diskussionen zeigen ja, dass prinzipiell Bedarf dafür besteht (zumindest hierzulande). Ein weiteres Problem, das aber auch mit Entscheidungen zu tun hat, ist die Frage nach 'offiziellen' oder 'empfohlenen' Tags, also letztlich den Map Features. Auch hier gibt es Unklarheiten, wie diese ausgewählt werden oder wer letztlich zu entscheiden hat was in die Map Features kommt. Das ist genauso wie wer letztlich zu entscheiden hat, was auf der OpenStreetMap-Seite in der Wikipedia steht. Gibt es in der Wikipedia nicht Admins, die zumindest in Streitfällen dann schlichten und die Seite erstmal sperren, wenn es in Edit-Wars ausartet? - Es ist nicht klar definiert, wann ein Proposal angenommen ist (und was das bedeutet, siehe vorheriger Punkt). Eben weil der Proposal-Prozess keine formelle Bedeutung hat, ist es auch nicht schlimm, dass das nicht klar definiert ist. Gerade das bemängel ich ja. Wenn der Proposal-Prozess keine formelle Bedeutung hat, dann soll das wenigstens auch auf der Wiki-Seite so stehen. Was da steht erweckt den Eindruck, dass ein erfolgreicher Vote etwas bedeutet. Bleibt noch die Frage wie schon existierende Features verändert werden können. Angenommen man wollte einen Tag genauer oder etwas anders definieren (nachträglich natürlich nur im Notfall, um Unklarheiten auszuräumen). Wie soll man das machen? Der Kern der Sache ist doch, dass man niemandem vorschreiben kann, bei einer Änderung mitzuziehen. So gern Du das vielleicht willst, Du kannst die Mapper in Grossbritannien nicht zwingen, mitzumachen. Also ist das ganze Beharren auf Formalia doch witzlos (aber ich bin im RECHT, so wie ich es mache ist es RICHTIG, ich habe mich an alle REGELN gehalten, mein PROPOSAL wurde angenommen, und nun musst DU auch mitmachen - nö, muss ich nicht). Stimmt, man kann niemand dazu zwingen, einen Tag zu benutzen. Allerdings bringt es doch auch nichts, wenn jeder anders taggt. Wozu gibt es dann überhaupt das Wiki, wenn nicht dazu es für die so 'formell' wie möglich zu dokumentieren, die sich daran orientieren MÖCHTEN. Wenn es nicht gelingt, die Menschen im Projekt von Deiner Idee zu ueberzeugen, dann nuetzt Dir jede formale Prozedur nichts. Umgekehrt verbietet Dir auch niemand, Deine Idee umzusetzen... Wenn mir also im Wiki eine Definition nicht gefällt, soll ich sie einfach ändern? Und was ist wenn die Diskussion zur Ausarbeitung eines neuen Vorschlags oder
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. naja, jetzt übertreibst Du. Natürlich ist es mit hgv und goods, (wenn da nicht dransteht LKW frei oder so, also hgv=yes), psv hat oft sowieso Sonderregelungen, aber wenn da nicht explizit psv=yes getaggt ist (und es nicht vergessen wurde), dann gilt das auch für psv (wenn dieser nicht z.B. eine Fahrrad-rikscha ist). Übrigens darf ein LKW da trotzdem nicht durch, auch wenn die OSM-Daten ihm dazu raten, und wenn der Router so schlecht ist, dass er es einem LKW trotzdem empfehlen würde, dann wird er auch nicht lange benutzt werden. Du hast ja selbst schon erkannt, dass mit motorcar eigentlich Kfz gemeint sind ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Martin Koppenhoefer schrieb: Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. naja, jetzt übertreibst Du. Natürlich ist es mit hgv und goods, (wenn da nicht dransteht LKW frei oder so, also hgv=yes), psv hat oft sowieso Sonderregelungen, aber wenn da nicht explizit psv=yes getaggt ist (und es nicht vergessen wurde), dann gilt das auch für psv (wenn dieser nicht z.B. eine Fahrrad-rikscha ist). Übrigens darf ein LKW da trotzdem nicht durch, auch wenn die OSM-Daten ihm dazu raten, und wenn der Router so schlecht ist, dass er es einem LKW trotzdem empfehlen würde, dann wird er auch nicht lange benutzt werden. Du hast ja selbst schon erkannt, dass mit motorcar eigentlich Kfz gemeint sind ;-) Eigentlich ja, aber erstaunlicherweise habe ich schon einige Male gelesen, dass statt lediglich motorcar=no auch noch hgv und goods gesetzt werden sollen. Ich denke nicht dass es bei sowas um persönliche Präferenzen geht, die man sowieso nicht verändern kann, sondern eher um eine der möglichen Interpretation der Tags. Das ließe sich durch besseres Erklären im Wiki lösen. Ich weiß aber leider nicht, wie man solche Änderungen anbringen soll. Soll man das einfach ändern und warten ob sich jemand beschwert (so wie ich es teilweise auch schon gemacht habe)? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Es ist keineswegs so, dass Tags, die sich nicht eindeutig, sondern nur mit hoher Wahrscheinlichkeit und Heuristik automatisch interpretieren lassen, wertlos sind - lediglich der Aufwand ist höher. Man muss sich allerdings auch fragen, ob es nicht sinnvoll wäre zumindest etwas in Richtung Eindeutigkeit zu arbeiten. Fragt sich auch wie man dann herausfinden soll, welche Interpretation die Richtige ist (oh, schon wieder das böse 'R'-Wort). Sagen wir eben die 'am ehesten der Realität entsprechende'. Man kann mit OSM-Daten momentan (wirklich, real, gibt es schon, ist nicht nur ein Hirngespinst): * allgemeine Karten malen * Spezialkarten malen (Fahrradkarten, Wanderkarten, ...) * Routen finden * ein richtiges Auto-Navi füttern * Orte finden * POIs (Parkplätze, Museen, ...) finden und bestimmt noch viel, viel mehr was ich selbst gar nicht mitbekommen habe. Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Der Wunsch nach Standardisierung und Reglementierung kommt hier mindestens alle 3 Monate in der Ausführlichkeit wie du es schreibst. Frederik reagiert darauf mit immer wieder der gleichen Antwort. *Diese* Ruhe ist beneidenswert, nicht das Vertrauen auf die Selbstregulierung der OSM-Daten. Bei OSM entscheiden momentan in erster Linie die verwendeten Tools, was benutzt wird. Seit es den OSM-Inspector gibt, setzt jeder ein addr:postcode an jede einzelne seiner Adressen obwohl es noch nicht lange her ist, dass man das für unnötige Daten hielt. Seit es JOSM-Presets gibt, orientieren sich viele Leute daran. Seit es OpenRouteService bzw. Yournavigation gibt, kann man richtig praktisch sehen, wo Wege noch nicht verbunden sind obwohl es in der gemalten Karte so aussieht. Seit es Garys Checks gibt, gilt seine Interpretation mancher Dinge eben für einen großen Teil der Leute als Richtwert. So lange es diese Programme schaffen, mit OSM-Daten sinnvolle Dinge zu machen, sehe ich echt kein Problem. Klar wird es immer eine Möglichkeit geben, Daten noch genauer oder noch besser, vielleicht sogar richtiger einzutragen. Sobald diese weitere Genauigkeit oder diese richtigeren Tags jemand braucht, wird er eine Anwendung schreiben und dann werden viele Leute sehen, dass man wirklich was damit anfangen kann und ihre Arbeit auf genau das umstellen was dieses Programm auslesen will. Ach ja: Was noch niemand bei all diesen Konsolidierungsvorschlägen genauer sagen konnte: Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wird ein Gremium gewählt? Ist es auch okay, wenn da kein einziger aus Deutschland dabei ist und die Engländer uns ihre lokalen Gepflogenheiten aufs Auge drücken? Ich glaube zwar nicht, dass jeder der so etwas vorschlägt am liebsten selbst das Gremium wäre, aber ich glaube dass bei Missfallen der Entscheidungen man sich einfach nicht dran hält bzw. vermutlich sofort das Projekt wieder verlässt. Dann hat man wieder nichts gewonnen. Gruß, Bernd -- Columbus hatte in Wirklichkeit vier Schiffe - das vierte segelte über die Kante signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Bernd Wurst schrieb: Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Es ist keineswegs so, dass Tags, die sich nicht eindeutig, sondern nur mit hoher Wahrscheinlichkeit und Heuristik automatisch interpretieren lassen, wertlos sind - lediglich der Aufwand ist höher. Man muss sich allerdings auch fragen, ob es nicht sinnvoll wäre zumindest etwas in Richtung Eindeutigkeit zu arbeiten. Fragt sich auch wie man dann herausfinden soll, welche Interpretation die Richtige ist (oh, schon wieder das böse 'R'-Wort). Sagen wir eben die 'am ehesten der Realität entsprechende'. Man kann mit OSM-Daten momentan (wirklich, real, gibt es schon, ist nicht nur ein Hirngespinst): * allgemeine Karten malen * Spezialkarten malen (Fahrradkarten, Wanderkarten, ...) * Routen finden * ein richtiges Auto-Navi füttern * Orte finden * POIs (Parkplätze, Museen, ...) finden und bestimmt noch viel, viel mehr was ich selbst gar nicht mitbekommen habe. Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Aber die meisten der von dir aufgelisteten Dinge hat mit den von mir bemängelten Dingen nicht allzuviel zu tun. Die Karten sehen so und so gut aus, egal ob die Daten stimmen oder nicht. Routing funktioniert auch. Fragt sich halt bloss welche Ansprüche man daran stellt. Ob man als z.B. zwischen Feinheiten wie (Reise)Bus-Routing und PKW-Routing unterscheiden will. Der Wunsch nach Standardisierung und Reglementierung kommt hier mindestens alle 3 Monate in der Ausführlichkeit wie du es schreibst. Frederik reagiert darauf mit immer wieder der gleichen Antwort. *Diese* Ruhe ist beneidenswert, nicht das Vertrauen auf die Selbstregulierung der OSM-Daten. Also ich lese nicht alle 3 Monate etwas davon. Übrigens muss Frederik darauf auch nicht antworten, wenn es ihm etwas ausmacht. Bei OSM entscheiden momentan in erster Linie die verwendeten Tools, was benutzt wird. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Es geht doch darum es für die Mapper einfacher zu machen. Anstatt in den JOSM Presets 'vorzuschreiben' was benutzt wird, würde ich es eben auch gerne im Wiki machen. Was dann letztlich benutzt wird, ist dann Sache der Mapper. Um aber im Wiki etwas zu erreichen, braucht es einfach klare Regeln. Oder man schafft das Accepted/Rejected Proposal gleich ab und schreibt nur das Ergebnis der Abstimmung als Stimmungsbarometer der Interessierten hin. Bleibt trotzdem noch die Frage was in die Map Features kommt. Wenn es nicht nach dem Voting geht, nach was dann? Das ist ein konkretes Problem, das nunmal so oder so entschieden werden muss. Langsam habe ich keine große Lust mehr, mich im Wiki zu engagieren. Übrigens haben auch schon Leute aufgrund der Uneindeutigkeit der Daten OSM den Rücken gekehrt. Vielleicht sollte man gleich auf die Anfänger-Seite schreiben, dass man nicht allzuviel Genauigkeit erwarten sollte, wenn man nicht vorhat eine konkrete Anwendung zu programmieren, die diese speziellen Daten braucht (eigentlich dachte ich ja OSM sammelt Daten auch erstmal unabhängig davon ob sie schon irgendwo dargestellt werden). Gruß ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Frederik Ramm frede...@remote.org writes: Ich denke, bei sowas wie bicycle=yes und motorcar=no gibt es relativ wenig Deutungs-Unterschiede. Relativ wenig kann aber eine ganze menge sein. Das yes kann von physikalisch möglich bis rechtlich erlaubt stehen. Wenn man dann noch bedenkt, dass bicycle von rennrad bis mountainbike reicht, dann kann physikalisch möglich auch schon wieder vieles bedeuten. Du hast aber recht, dass die deutung sicherer wird, wenn weitere angaben wie physikalische beschaffenheit und verkehrszeichen hinzukommen. Es ist nur mühsam, das alles auszuwerten. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo. Am Mittwoch, 21. Januar 2009 schrieb Sebastian Hohmann: Ist das nicht Beweis genug dass es doch irgendwie funktioniert? Kommt wohl auf die Ansprüche an. Wenn es einem nicht wichtig ist, ob ein Weg mit Anlieger frei für Fahrräder freigeben ist oder nicht, weil man sowieso durchfährt, dann reichen die Daten selbstverständlich. Und wenn man auch sonst keine allzu hohe Ansprüche hat. Bisher hat scheinbar niemand genau diese Ansprüche, die du hast. Aber die meisten der von dir aufgelisteten Dinge hat mit den von mir bemängelten Dingen nicht allzuviel zu tun. Die Karten sehen so und so gut aus, egal ob die Daten stimmen oder nicht. Routing funktioniert auch. Fragt sich halt bloss welche Ansprüche man daran stellt. Ob man als z.B. zwischen Feinheiten wie (Reise)Bus-Routing und PKW-Routing unterscheiden will. Ich glaube gerne, dass routing für LKW und Reisebusse bald irgendwo mal mit diesen Daten gemacht wird. Ob Anlieger frei für Fahrräder gilt oder nicht, ist dafür irrelevant. Sobald das jemand macht, wird klar werden, dass maxweight=* und maxheight=* sowie ein paar ähnliche Tags nicht wirklich flächendeckend eingetragen wurden. Anliegerstraßen sind in der großen Masse aller Straßen ein verschwindend geringer Anteil. Und auch wenn unser Anspruch die Perfektion ist, so sind wir doch schonmal froh, diese Straßen überhaupt drin zu haben. Die kommerziellen Alternativen haben die oft überhaupt nicht drin. Wer ist denn der man, der alles festlegt? Wer ist denn dafür zuständig, dass das was da festgelegt wird, auch richtig ist? Wer das aktuell ist hast du ja selbst geschrieben. Nein. Es legt bisher niemand etwas fest sondern mit funktionierenden Anwendungen kann man eine große Zahl an Mitstreitern motivieren, freiwillig am gleichen Strang zu ziehen. Aber warum wird sich hier denn so dagegen gewehrt, die OSM Daten etwas besser zu machen? Du hast es immer noch nicht verstanden: Weil das besser nicht so konkret definierbar ist! Um aber im Wiki etwas zu erreichen, braucht es einfach klare Regeln. Nein. Oder man schafft das Accepted/Rejected Proposal gleich ab und schreibt nur das Ergebnis der Abstimmung als Stimmungsbarometer der Interessierten hin. Bleibt trotzdem noch die Frage was in die Map Features kommt. Wenn es nicht nach dem Voting geht, nach was dann? Das ist ein konkretes Problem, das nunmal so oder so entschieden werden muss. Langsam habe ich keine große Lust mehr, mich im Wiki zu engagieren. Das Wiki ist eine Daten-Halde, in dem man suchen kann wenn man Tags für irgendwas braucht und in das man eintragen kann, was man selbst so benutzt. Außerdem ist es eine rudimentäre Anleitung für Einsteiger und Dokumentation für unzählige Programme aus dem OSM-Umfeld. Es ist kein Gesetzbuch oder irgend etwas was ein Mapper *braucht*. Seit es Presets gibt, braucht man noch nichtmal die Map-Features-Seite unbedingt wenn man mit OSM anfängt. Wenn du dich nicht im Wiki engagieren möchtest, lass es. Wenn du etwas verbessern willst: Mach es. Wenn du viel verbessern willst und keine Leute verprellen möchtest, leg jeweils eine neue Seite an und verweise auf der Diskussions-Seite der alten Variante auf deinen Neuvorschlag. Seit der Einfühung von highway=path mit der Brechstange sollte jedem klar sein, wie viel Bedeutung das Wiki hat und wie ernst zu nehmen das ist. Man kann aber auch ganz prima mappen ohne das Wiki zu benutzen. Gruß, Bernd -- Mit Hacken ist das wie mit dem Blues. Wer fragen muß, was Hacken ist, wird es nie verstehen. - Felix von Leitner signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess
Hallo, Sebastian Hohmann wrote: Gibt es in der Wikipedia nicht Admins, die zumindest in Streitfällen dann schlichten und die Seite erstmal sperren, wenn es in Edit-Wars ausartet? Die schlichten, soweit ich weiss, allenfalls den Prozess, also so nach dem Motto jetzt einigt Euch halt, aber die entscheiden nicht, was richtig ist. Wenn es nicht gelingt, die Menschen im Projekt von Deiner Idee zu ueberzeugen, dann nuetzt Dir jede formale Prozedur nichts. Umgekehrt verbietet Dir auch niemand, Deine Idee umzusetzen... Wenn mir also im Wiki eine Definition nicht gefällt, soll ich sie einfach ändern? Wenn eine Definition so vage ist, dass sie Auslegungsspielraum hat, dann lege sie so aus, wie Du es fuer richtig haeltst. Dazu musst Du sie nicht aendern. Wenn Du das gesamte Konzept fuer unsinnig haeltst, dann denke Dir was eigenes brauchbares aus und verwende das; dokumentiere es ggf. auf einer eigenen Wikiseite (vielleicht zunaechst im User-Namensraum, wenn es sehr esoterisch ist). All diese Moeglichkeiten stehen Dir offen, ohne dass Du andere nach Deiner Pfeife tanzen lassen musst. Ich denke, bei sowas wie bicycle=yes und motorcar=no gibt es relativ wenig Deutungs-Unterschiede. [...] Oh doch. Ist motorcar inklusive hgv, goods, psv? Je nachdem wie derjenige der die Daten auswertet das sieht, darf ein LKW plötzlich überall durch wo Kraftfahrzeuge gesperrt sind oder auch nicht. Das ist halt sowas, wo die Programmierer sich etwas mehr auf den Charakter von OSM einlassen muessen. Ist es realistisch, eine Strasse zu haben, die fuer PKW gesperrt, fuer LKW aber frei ist? Sollte der Router in so einem Fall eventuell lieber auf der Seite der Vorsicht irren? (Ist uebrigens hgv nicht identisch mit goods?) Mir geht es weniger darum irgendjemand dazu zu zwingen es genauso zu machen, wie es im Wiki steht, sondern eher darum, dass die Mapper meist garkeine Möglichkeit haben, sich an etwas zu orientieren. Ich mappe ja selbst wie ich es am logischsten finde. Man müsste sich aber weniger selbst zusammenraten, wenn Manches im Wiki klarer definiert wäre. Wem die Definition nicht gefällt, mappt natürlich trotzdem wie er es für besser hält. Dann brauchen wir aber keinen Prozess, sondern einfach eine einzige Person, die einfach gut ist, oder von mir aus ein Team von Leuten, die sich im Rahmen der allgemein akzeptieren vagen Regeln konkrete Tagging-Howtos ausdenken (und das passiert ja auch schon vielerorts im Wiki, z.B. dort wo jemand angefangen hat, zu jedem Verkehrsschild aufzuschreiben, wie man das seiner Ansicht nach taggen sollte). Diese Leute koennen dann ja eine stimmige Interpretation/Empfehlung aufschreiben, und jeder, der das gut findet, kanns uebernehmen. Wenn es in einem anderen Land andere solche Leute gibt, die sich etwas anders entscheiden - was solls. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
