Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Frederik Ramm]

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.

> 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.

Die Annahme, dass es immer genau ein "richtig" geben müsse, ist meiner 
Ansicht nach Grund für sehr viel Elend auf der Welt.

> 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 
> 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.

> 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".

> 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.

Jede Art von "verbindlicher" Abstimmung ist in einem Projekt mit 
exponentiellem Nutzerwachstum völlig ungeeignet. Selbst wenn wir heute 
eine Abstimmung durchführen würden, an der sich 100% der Nutzer 
beteiligen, so wären diese 100% in einem Jahr schon deutlich in der 
Minderheit. Wir (die heutigen Nutzer) könnten maximal eine Autorität für 
uns selbst sein, aber nicht für die Nutzer von übermorgen.

> - 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.

> 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").

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...

> Und was ist wenn die Diskussion zur Ausarbeitung eines neuen Vorschlags 
> oder auch insbesondere nachträglicher Veränderung eines Tags zu keinem 
> Schluss kommt, weil die Leute vehement ihren jeweiligen Standpunkt 
> vertreten? Sollte es dann nicht jemanden geben, der einfach mal 
> entscheiden kann?

Nein, dann sollten einfach alle Varianten so lange nebeneinander leben, 
bis sich eine durchsetzt (oder bis in einem Jahr sowieso beide an die 
Vorgehensweise der Chinesen angepasst werden, die bis dahin die 
überwältigende Mehrheit der Mapper stellen ;-)

> Stolpersteine für die eindeutige Definition von Tags liegen häufig auch 
> in der Internationalität des Projekts. Selbst innerhalb von Deutschland 
> gibt es schon heftige Diskuss

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Martin Koppenhoefer]

Am 21. Januar 2009 00:17 schrieb Sebastian Hohmann :

> 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

[Sebastian Hohmann]

Martin Koppenhoefer schrieb:
> Am 21. Januar 2009 00:17 schrieb Sebastian Hohmann :
> 
>> 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 

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Sebastian Hohmann]

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

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Martin Koppenhoefer]

>
>
> 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

[Sebastian Hohmann]

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

[Bernd Wurst]

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

[Sebastian Hohmann]

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

[Karl Eichwalder]

Frederik Ramm  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

[Bernd Wurst]

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

[Frederik Ramm]

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

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Guenther Meyer]

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

[Sven Anders]

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. 

Du könntest z.B. sagen, ich mache eine eigene Webseite auf und Regel das alles 
ganz klar mit Abstimmungsystem und Login etc. Du kannst dort Modalitäten 
festlegen, das z.B. jemand der Abstimmt mindestens soundsoviele Nodes gesetzt 
haben muss etc.

Die Tags versiehst du mit einem Prefix, z.B. Sebastian: ,so das z.B. das 
Access Tags dann Sebastian:Acceess=bike heißen könnte.

Wenn es mapper gibt, die dein System gut finden, können Sie es nutzen, sie 
brauchen auch keine Tags aus der Map_Features zu verwenden.

Der/Die Entwickler von GPSDrive haben sowas auch mal gemacht, da fangen die 
tags mit poi an (weiß nicht ob das noch aktuell ist).


> Übrigens haben auch schon Leute aufgrund der Uneindeutigkeit der Daten
> OSM den Rücken gekehrt. 

Ich denke es wird immer Leute geben die OSM den Rücken kehren. Ich vermute 
aber das bei der Wikipedia auch viele den Rücken kehren, weil es dort zu 
viele Abstimmungen und Hierarchien gibt. 


> 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.

Gruß
Sven

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Guenther Meyer]

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

[Claudius Henrichs]

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

[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.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[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.

> 
>> 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

[Sebastian Hohmann]

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

[Sebastian Hohmann]

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

[Sebastian Hohmann]

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

[Frederik Ramm]

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

[Guenther Meyer]

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

[Frederik Ramm]

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

[Bernd Wurst]

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

[Guenther Meyer]

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

[Sebastian Hohmann]

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

[Sebastian Hohmann]

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

[Sebastian Hohmann]

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

[Sebastian Hohmann]

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

[Guenther Meyer]

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

[Markus]

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

[Markus]

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

[André Reichelt]

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).


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

[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.

>>> 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

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]

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).
> 
> 
> 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

[Sven Geggus]

Sebastian Hohmann  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

[Torsten Leistikow]

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

[Guenther Meyer]

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

[Sebastian Hohmann]

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

[Sebastian Hohmann]

Sven Geggus schrieb:
> Sebastian Hohmann  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

[Guenther Meyer]

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

[Markus]

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

[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é



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]

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

[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.

___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Nop]

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

[Nop]

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

[Frederik Ramm]

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

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Ulf Lamping]

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!"
> 

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Ekkehart]

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 bes

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Frederik Ramm]

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

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Guenther Meyer]

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

[Guenther Meyer]

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 e

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Guenther Meyer]

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

[Guenther Meyer]

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

[Guenther Meyer]

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

[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?

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

[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.
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

[Guenther Meyer]

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

[Guenther Meyer]

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

[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?
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

[Bernd Wurst]

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

[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.


> > 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

[Guenther Meyer]

Am Donnerstag 22 Januar 2009 schrieb Bernd Wurst:
> 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.
>
daran kann ich mich auch erinnern. :-)
das wurde damals wohl etwas drastisch ausgedrueckt...

es sollte aber nachvollziehbar sein, dass mit genaueren definitionen auf der 
datenebene letztendlich eine hoehere qualitaet im ergebnis erzielt werden 
koennte.

>
> 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.
>
naja, ors hat den vorteil, dass es ein grosser, sehr bekannter dienst ist, und 
deren stimme damit ein entsprechendes gewicht hat.
als kleiner entwickler von einem der zahlreichen softwareprojekte um osm, der 
nicht die entsprechenden ressourcen hat, hat man da einen etwas schwereren 
stand.





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

[Guenther Meyer]

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

[Guenther Meyer]

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

[Sebastian Hohmann]

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]

On Thu, 22 Jan 2009, Sebastian Hohmann wrote:


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.


Das stimmt zwar generell, funktioniert aber in allen OpenSource- oder 
OpenContent-Projekten die ich kenne nicht. Warum? Nun wenn Du z.B. 
OpenStreetMap Feature xxx einträgst und es kommt einer daher, der ein 
ganz tolles "FeatureX"-Proposol schreibt, dann wirst Du Dich eher nicht 
dran halten, weil er garantiert einige Kritikpunkte hat, die Dir nicht 
passen werden. Und mit jemanden, der sich nur theoretisch mit dem Thema 
auseinandergesetzt hat diskutiert man meist nicht (verlorene Liebesmüh :-).


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.


Tolle Ideen haben leider immer das Problem, dass Sie in der Praxis doch 
irgendwo nicht ganz passen. Deswegen setzt auch die Industrie immer mehr 
auf Werkstandards (z.B. der Großteil der Internet-Technologie). Diese 
haben nämlich den Praxistest schon hinter sich. Dafür sind sie nicht immer 
perfekt. Aber was ist schon Perfektion?


Bei freien Projekten ist aufgrund der Art der Arbeitsverteilung diese 
Werkstandard-Bevorzugung schon fast absolut.


Das nur Programmierer Einfluß haben stimmt nicht. Die Programmierer eines 
Programms können sich noch so sehr sträuben, wenn Du in der Datenbank 
größere Mengen eines Elements einträgst, dass auch andere unterstützt 
haben wollen, dann müssen die Programmierer nachziehen.


Ich z.B. habe (zusammen mit anderen) angefangen die Ortsschilder 
einzutragen. Als so um die 200 Schilder als note eingetragen hatte, wurde 
es mir zu bunt und ich habe traffic_sign=city_limit genutzt. Dann noch 
alle Alternativ-Varianten darauf umgestellt. Es kamen so um die 400 
Einträge dabei heraus. Und weil ich auch JOSM-Entwickler bin das ganze in 
JOSM eingeführt.


Für viele andere Sachen läuft es so, dass Ulf und Christoph im Tagwatch 
nachschauen, wie oft Sachen eingetragen sind und diese dann in JOSM 
übernehmen. Bei den Karten läuft es ähnlich - Erst kommen die Daten, dann 
der Rest.


P.S. Es gibt mittlerweile knapp 6000 Ortsschilder, also war meine Idee 
wohl gut genug :-) In den Karten werden diese trotzdem noch nicht 
dargestellt (denke ich).


Ciao
--
http://www.dstoecker.eu/ (PGP key available)___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Sebastian Hohmann]

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

[Sebastian Hohmann]

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

[Nop]

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 
Datum:
Thu, 22 Jan 2009 10:10:49 +0100
An:
Openstreetmap allgemeines in Deutsch 


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"

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[Nop]

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.
A

Re: [Talk-de] Entscheidungen treffen / Proposal-Prozess

[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?

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

[Christoph Eckert]

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

[Guenther Meyer]

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

[Guenther Meyer]

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

[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.

> 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

[Guenther Meyer]

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

[Martin Koppenhoefer]

2009/1/23 Frederik Ramm 

> 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

[Frederik Ramm]

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

[Johannes Hüsing]

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:  
. 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

[Nop]

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

[Hatto von Hatzfeld]

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