Discussion:
Datenbankbereinigung
(too old to reply)
Tobias Wendorff
2008-08-07 16:48:11 UTC
Permalink
Hallo Leute,

ich schreibe derzeit eine Lösung für das Rendering von Straßennamen
(ja ... in PHP, steinigt mich!).

Mir ist aufgefallen, dass es mittlerweile mind. drei Schreibweisen
für "oneway" gibt: true, 1, yes

Wird es generell irgendwann mal eine Datenbankbereinigung geben,
damit es einen einheitlichen Standard gibt?

Oder kann man JOSM zukünftig beibringen, beim Speichern immer nur
TRUE oder 1 zu exportieren? Schließlich wurde ein Standard
festgelegt.

Grüße
Tobias
Mario Salvini
2008-08-07 16:55:26 UTC
Permalink
Post by Tobias Wendorff
Hallo Leute,
ich schreibe derzeit eine Lösung für das Rendering von Straßennamen
(ja ... in PHP, steinigt mich!).
Mir ist aufgefallen, dass es mittlerweile mind. drei Schreibweisen
für "oneway" gibt: true, 1, yes
Wird es generell irgendwann mal eine Datenbankbereinigung geben,
damit es einen einheitlichen Standard gibt?
Oder kann man JOSM zukünftig beibringen, beim Speichern immer nur
TRUE oder 1 zu exportieren? Schließlich wurde ein Standard
festgelegt.
Grüße
Tobias
ich dachte der Standard sei oneway=yes?

irritierte Grüße
Mario
Tobias Wendorff
2008-08-07 16:59:42 UTC
Permalink
Post by Mario Salvini
ich dachte der Standard sei oneway=yes?
Ja ja ... *rotwert und rausred* ich meinte nur generell:
Wir haben einen Standard, wieso die Editoren dann nicht dazu zwingen.
Bernd Wurst
2008-08-07 16:56:34 UTC
Permalink
Hallo.
Post by Tobias Wendorff
ich schreibe derzeit eine Lösung für das Rendering von Straßennamen
(ja ... in PHP, steinigt mich!).
Es ist gleichzeitig witzig und befremdlich, welchen obskuren Zoo von
Programmiersprachen wir bei OSM haben. Eine ungeeigneter als die andere für
das was man damit (umfangsmäßig) einmal machen will... ;-)

Aber ja, wer etwas in einer Programmiersprache macht, die er schon kann, macht
es dafür hoffentlich in sich ordentlich.
Post by Tobias Wendorff
Mir ist aufgefallen, dass es mittlerweile mind. drei Schreibweisen
für "oneway" gibt: true, 1, yes
Korrekt, plus beinahe sämtliche groß-kleinschriebungs-Variationen.
Und zudem halt noch -1 für die Gegenrichtung.
Post by Tobias Wendorff
Wird es generell irgendwann mal eine Datenbankbereinigung geben,
damit es einen einheitlichen Standard gibt?
Vermutlich nicht. Jeder, der die Daten irgendwo weiter verarbeitet sollte für
solche Fälle einfach den Konverter so schreiben, das diese Unterschiede alle
zu einem für ihn passenden Wert konvertiert werden.

Wenn du jetzt alles änderst, musst du das in 2 Monaten wieder tun weil jemand
es so einträgt wie er es gewohnt ist. Lieber mehrere Daten für dasselbe
erlauben und beim Exportieren bzw. Konvertieren dann vereinheitlichen.
Post by Tobias Wendorff
Oder kann man JOSM zukünftig beibringen, beim Speichern immer nur
TRUE oder 1 zu exportieren? Schließlich wurde ein Standard
festgelegt.
Wurd *festgelegt*? Wie bitte? Ich verwende oneway=yes weil das schön zu lesen
ist und zumindest als ich das letzte Mal in den Map-Features geschaut hab
stand das dort drin.
Jetzt immer noch. :)

Gruß, Bernd
--
Die Philosophie ist eine Art Rache an der Wirklichkeit. - Friedrich
Nietzsche
Tobias Wendorff
2008-08-07 17:09:59 UTC
Permalink
Hallo,
Post by Bernd Wurst
Es ist gleichzeitig witzig und befremdlich, welchen obskuren Zoo von
Programmiersprachen wir bei OSM haben. Eine ungeeigneter als die andere für
das was man damit (umfangsmäßig) einmal machen will... ;-)
PHP = keine Programmiersprache (bin stolz drauf ... nur 70%iger Nerd)
Post by Bernd Wurst
Post by Tobias Wendorff
Mir ist aufgefallen, dass es mittlerweile mind. drei Schreibweisen
für "oneway" gibt: true, 1, yes
Korrekt, plus beinahe sämtliche groß-kleinschriebungs-Variationen.
Und zudem halt noch -1 für die Gegenrichtung.
Wie, Standard ist "yes" und es gibt trotzdem "-1"? Super!
Post by Bernd Wurst
Post by Tobias Wendorff
Wird es generell irgendwann mal eine Datenbankbereinigung geben,
damit es einen einheitlichen Standard gibt?
Vermutlich nicht. Jeder, der die Daten irgendwo weiter verarbeitet sollte für
solche Fälle einfach den Konverter so schreiben, das diese Unterschiede alle
zu einem für ihn passenden Wert konvertiert werden.
Also Tagwatch beobachten und ein Script dafür schreiben?
Post by Bernd Wurst
Wenn du jetzt alles änderst, musst du das in 2 Monaten wieder tun weil jemand
es so einträgt wie er es gewohnt ist. Lieber mehrere Daten für dasselbe
erlauben und beim Exportieren bzw. Konvertieren dann vereinheitlichen.
Nein, Editoren strict machen, wie bei HTML & Co.
Post by Bernd Wurst
Post by Tobias Wendorff
Oder kann man JOSM zukünftig beibringen, beim Speichern immer nur
TRUE oder 1 zu exportieren? Schließlich wurde ein Standard
festgelegt.
Wurd *festgelegt*? Wie bitte? Ich verwende oneway=yes weil das schön zu lesen
ist und zumindest als ich das letzte Mal in den Map-Features geschaut hab
stand das dort drin.
Jetzt immer noch. :)
Nun, wenn man schon "OSM" als Format schafft, sollte man auch Regeln
festlegen, sonst hätte man es nicht einführen müssen. Du kannst doch
weiterhin "oneway=yes" schreiben, aber intern könnte JOSM das doch
auf "oneway=1" ändern. Würde keinen stören.

Grüße
Tobias
Frederik Ramm
2008-08-07 17:25:28 UTC
Permalink
Hallo,
Post by Tobias Wendorff
Nun, wenn man schon "OSM" als Format schafft, sollte man auch Regeln
festlegen, sonst hätte man es nicht einführen müssen.
Niemand hatte je den Anspruch, ein Format zu schaffen. Die
Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne
dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess
zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt
die Dynamik nehmen, die es zum Leben braucht.

Mir ist schon klar, dass es fuer die Nutzer der Daten etwas
komplizierter ist, aber die vernuenftige Loesung waere, sich einen
normierenden Zwischenlayer auszudenken, der die Daten in das wandelt,
was man gerne haette, und NICHT, die Mapper normieren zu wollen.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00'09" E008°23'33"
Dimitri Junker
2008-08-07 23:34:38 UTC
Permalink
Hallo,
Die Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne
dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess
zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt
die Dynamik nehmen, die es zum Leben braucht.
So nach dem Motto, ich hab was eigenes kreiert, ich schreibe oneway=true
statt yes? Warum dann nicht auch noch ja, oui, natürlich und "wag es nicht
da rein zu fahren"

Die OSM-Datenbank ist doch keine Prosa, wir wollen damit keinen
Literaturnobelpreis gewinnen. Es ist eine primär maschinenlesbare Datenbank,
und da muß man sich schon an gewisse Formate halten damit es klappt. Es ist
kein evolutionärer Prozess einfach ein Synonym zu benutzen. Herausfinden
welche Methode am besten/einfachsten ist um Abbiegeverbote einzutragen o.ä.
da kann es sinnvoll sein verschiedene Wege zu probieren. Ich gebe keine
Daten bei OSM ein, damit ich sie mir dann ausdrucken und an die Wand hängen
kann um zu sagen, das habe ich geleistet. Ich möchte, daß sie für möglichst
viele Leute nützlich sind. Und wenn ich da true statt yes eingebe sind die
Daten erstmal nutzlos, es sei denn irgendein Programierer von Renderern,
Routern o.ä. fügt true in die Einleseroutine ein. Nur könnte der statt
dessen etwas sinnvolleres machen was den Nutzen von OSM wirklich erhöht.
Stellt Euch vor, die OSM-Programierer würden mit so einer Logik
programieren, dann würde kein einziges Programm laufen. Da können die Mapper
doch etwas solidarisch mit ihnen sein und ihnen das Leben leichter machen.

Gruß
Dimitri
Bernd Wurst
2008-08-08 09:08:17 UTC
Permalink
Hallo.
Post by Dimitri Junker
So nach dem Motto, ich hab was eigenes kreiert, ich schreibe oneway=true
statt yes? Warum dann nicht auch noch ja, oui, natürlich und "wag es nicht
da rein zu fahren"
Nein, nach dem Motto: Wenn es noch nichts gibt was genau das darstellt was ich
will, dann nehm ich was ähnliches oder was ganz anderes.

Im Fall von oneway (bzw. allen Ja-Nein-Angaben) gab es irgendwann mal, vor
längerer Zeit keine Definition im Wiki wie man das machen könnte.
Dann kamen die einen, vielleicht Programmierer, die sagten "true"/"false"
nehmen wir dafür, das ist die intuitive Darstellung von boolschen Werten.
Dann kamen die anderen, vermutlich keine Programmierer, die sagen: nee, das
kann ich mir nicht merken, "yes"/"no" ist doch viel intuitiver und das
versteht dann jeder.

Und dann kommt der Schlaumeier, der meint wenn man mehrere richtungsgebundene
Dinge an einer Straße hat, brauchen wir auch ein
Gegenrichtungs-Einbahnstraßen-Tag. Da wurde dann "-1" eingeführt. Vielleicht
benutzen auch manche Leute intuitiv "opposite", ich weiß es nicht.

Jedenfalls wurde dann irgendwann mal beschlossen, wir dokumentieren einfach
diese drei Dinge: "yes"/"no", "true"/"false" und "-1". Dann muss man an den
eingegebenen Daten keine unnötigen Änderungen machen und sowohl der
Programmierer als auch der 08/15-Mapper sollte jeweils für sich eine diese
Varianten als intuitiv ansehen.


Ich kann mich nicht dran erinnern, dass jemals irgendjemand eines deiner
polemischen anderen Beispiele ernsthaft als "das wäre sehr viel praktischer"
kommuniziert hat. Bei den von mir genannten (und auch in Gebrauch
befindlichen) kann ich mir das wie oben geschrieben sehr gut vorstellen.

Bei allen obskuren Beispielen bedenke: Dass wir Tag-Inhalte oft auf englisch
formulieren ist hoffentlich jedem bekannt und daher sind deutsche oder
französische Texte sowieso am internationalen Charakter vorbei gewählt.
Und innerhalb des englischen gibt es halt das technische "true"/"false" und
das umgangssprachliche "yes"/"no". Keins ist falsch und daher sind einfach
beide dokumentiert und keiner wird gezwungen was für ihn unintuitives zu
benutzen.
Post by Dimitri Junker
Die OSM-Datenbank ist doch keine Prosa, wir wollen damit keinen
Literaturnobelpreis gewinnen.
Schade, hatte mir grade Hoffnungen gemacht... ;-)
Post by Dimitri Junker
Es ist eine primär maschinenlesbare
Datenbank, und da muß man sich schon an gewisse Formate halten damit es
klappt.
Tun wir doch.
Post by Dimitri Junker
Es ist kein evolutionärer Prozess einfach ein Synonym zu benutzen.
Nicht?

Die Welt braucht auch keinen zweiten, äquivalenten Text-Dokument-Standard. Wir
brauchen auch keine mehreren Methodn wie man Zeilenenden in einer Textdatei
speichert. Wir brauchen eigentlich keine unterschiedlichen Papierformate
weltweit. Trotzdem haben wir es. Und jeder, der ernsthaft mit den
entsprechend unterschiedlichen Dingen zu tun hat, versteht es einfach, alles
zu lesen und es funktioniert.
Post by Dimitri Junker
Und wenn ich da true statt yes
eingebe sind die Daten erstmal nutzlos, es sei denn irgendein Programierer
von Renderern, Routern o.ä. fügt true in die Einleseroutine ein.
Das haben bisher alle getan, die unsere Daten nutzen. "true" ist als
äquivalent von "yes" schon so lange im Wiki dokumentiert, dass das von je her
alle Daten-Konsumenten einfach so eingebaut haben.
Post by Dimitri Junker
Nur könnte der statt dessen etwas sinnvolleres machen was den Nutzen von OSM
wirklich erhöht.
In den 2 Minuten die er für eine solche ODER-Abfrage braucht, könnte der auch
auf's Klo gehen. Ich denke nicht, dass irgendjemand ernsthaft aus diesem
Zustand ein reales Problem bekommt.
Post by Dimitri Junker
Stellt Euch vor, die OSM-Programierer würden mit so einer
Logik programieren, dann würde kein einziges Programm laufen.
Die OSM-affinen Projekte machen das seit je her. Jedes oneway=true wird in
Mapnik und Osmarender eingezeichnet, genauso wie sich openrouteservice daran
hält.

Ich versteh dein Problem nicht.

Nochmal: Wir es ist nicht so beschlossen bzw. dokumentiert, dass JEDER WERT
eine maschinenlesbare Aussage hat, sondern dass 3 (DREI) verschiedene
Bezeichnungen für dasselbe existieren. Das sind nur drei Stück, das ist echt
abzählbar und überschaubar. Es sind NUR DREI.
Kein "yo", "jau", "jawoll", "oui" oder "so ist es" wird von einem
Datenkonsument verstanden. Das muss es auch nicht, weil das NIEMAND EINTRÄGT.
Auch wenn es technisch geht und geeignet wäre, hier Stimmung zu machen.
Post by Dimitri Junker
Da können die
Mapper doch etwas solidarisch mit ihnen sein und ihnen das Leben leichter
machen.
Da ich in meiner Freizeit mappe, möchte ich eigentlich erstmal dass mir das
Leben nicht schwer gemacht wird.

Gruß, Bernd
--
Es vergeht kein Tag an dem ich nicht alles wieder infrage stelle.
- André Gide (frz. Schriftsteller)
Dirk Stöcker
2008-08-08 09:32:13 UTC
Permalink
Post by Bernd Wurst
Und dann kommt der Schlaumeier, der meint wenn man mehrere richtungsgebundene
Dinge an einer Straße hat, brauchen wir auch ein
Gegenrichtungs-Einbahnstraßen-Tag. Da wurde dann "-1" eingeführt. Vielleicht
benutzen auch manche Leute intuitiv "opposite", ich weiß es nicht.
Jedenfalls wurde dann irgendwann mal beschlossen, wir dokumentieren einfach
diese drei Dinge: "yes"/"no", "true"/"false" und "-1". Dann muss man an den
eingegebenen Daten keine unnötigen Änderungen machen und sowohl der
Programmierer als auch der 08/15-Mapper sollte jeweils für sich eine diese
Varianten als intuitiv ansehen.
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Stefan Schwan
2008-08-08 09:36:22 UTC
Permalink
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Einbahnstraße entgegen der Richtung des Ways...
Dirk Stöcker
2008-08-08 09:43:50 UTC
Permalink
Post by Stefan Schwan
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Einbahnstraße entgegen der Richtung des Ways...
Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen?

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Stefan Schwan
2008-08-08 09:56:47 UTC
Permalink
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Einbahnstraße entgegen der Richtung des Ways...
Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen?
Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen
"left" oder "right"...
Dirk Stöcker
2008-08-08 10:16:32 UTC
Permalink
Post by Stefan Schwan
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Einbahnstraße entgegen der Richtung des Ways...
Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen?
Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen
"left" oder "right"...
Left/right geht auch andersrum. Ist kein also Argument.

Die Richtung bergaufwärts auch nicht:
a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die
Richtung z.B. so ein, wie ich gefahren bin.
b) kann man sowas Höhendaten herausbekommen.
c) könnte man das mit elevation-Daten oder Tags eintragen, wenn es denn
unbedingt in den Daten sein soll (verschneiden mit Höhenmodell kommt
mir allerdings sinnvoller vor).

Andere Argumente?

Das -1 wird ja sowieso kaum genutzt. Die einzige Anwendung, die ich
gesehen habe waren parallele Autobahnen und dort kann man ohne weiteres
die zweite Spur umdrehen.

Es gibt 1336 Wege mit oneway=-1 in der Datenbank (gegenüber 400000
true/yes).

http://tagwatch.stoecker.eu/Europe/En/tagstats_oneway_-1.html

7 oneway=-1 liegen auf Knoten, sind also sehr wahrscheinlich Unfug.

Ich wette, dass man alle diese 1336 Wege einfach umdrehen kann. Dann kann
man diese dämliche "-1"-Regel abschaffen. Aus meiner Sicht ist diese
nämlich eine unsinnige Ausnahme, die die Software nur unnötig verkompliziert.
Diese Regel hat auch keine Entsprechung in irgendwelchen anderen
OSM-Regeln.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Stefan Neufeind
2008-08-08 11:06:23 UTC
Permalink
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Einbahnstraße entgegen der Richtung des Ways...
Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen?
Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen
"left" oder "right"...
Left/right geht auch andersrum. Ist kein also Argument.
a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die
Richtung z.B. so ein, wie ich gefahren bin.
b) kann man sowas Höhendaten herausbekommen.
c) könnte man das mit elevation-Daten oder Tags eintragen, wenn es denn
unbedingt in den Daten sein soll (verschneiden mit Höhenmodell kommt
mir allerdings sinnvoller vor).
Andere Argumente?
Das -1 wird ja sowieso kaum genutzt. Die einzige Anwendung, die ich
gesehen habe waren parallele Autobahnen und dort kann man ohne weiteres
die zweite Spur umdrehen.
Es gibt 1336 Wege mit oneway=-1 in der Datenbank (gegenüber 400000
true/yes).
http://tagwatch.stoecker.eu/Europe/En/tagstats_oneway_-1.html
7 oneway=-1 liegen auf Knoten, sind also sehr wahrscheinlich Unfug.
Ich wette, dass man alle diese 1336 Wege einfach umdrehen kann. Dann
kann man diese dämliche "-1"-Regel abschaffen. Aus meiner Sicht ist
diese nämlich eine unsinnige Ausnahme, die die Software nur unnötig
verkompliziert.
Diese Regel hat auch keine Entsprechung in irgendwelchen anderen
OSM-Regeln.
Das sollte dennoch jeweils vorbehaltlich einer händischen Prüfung sein.
Vielleicht stehen andere Infos ala right/left drin die erst bei einer
händischen Prüfung/Änderung auffallen würden und die du bei einem
Skriptlauf schlichtweg nicht beachten (somit "verfälschen" würdest).

Regards,
Stefan
Dirk Stöcker
2008-08-08 11:11:58 UTC
Permalink
Post by Stefan Neufeind
Post by Dirk Stöcker
Ich wette, dass man alle diese 1336 Wege einfach umdrehen kann. Dann
kann man diese dämliche "-1"-Regel abschaffen. Aus meiner Sicht ist
diese nämlich eine unsinnige Ausnahme, die die Software nur unnötig
verkompliziert.
Diese Regel hat auch keine Entsprechung in irgendwelchen anderen
OSM-Regeln.
Das sollte dennoch jeweils vorbehaltlich einer händischen Prüfung sein.
Vielleicht stehen andere Infos ala right/left drin die erst bei einer
händischen Prüfung/Änderung auffallen würden und die du bei einem
Skriptlauf schlichtweg nicht beachten (somit "verfälschen" würdest).
Yup. Das versteht sich von selbst.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Bernd Wurst
2008-08-08 11:40:00 UTC
Permalink
Hallo.
Post by Dirk Stöcker
Dann kann
man diese dÀmliche "-1"-Regel abschaffen.
Kann man nicht diese Leute abschaffen, die alles abschaffen wollen?
Ach nee, kann man nicht, weil wir ja Freiheit als oberstes Ziel auf unsere
Aktionen kleben. Und unter Freiheit verstehe ich, dass nichts "abgeschafft"
oder "verboten" wird.

Es wird definitiv irgenwo irgendwelche richtungsbezogenen Tags geben, die
parallel zum oneway existieren können und nicht notwendigerweise in die selbe
Richtung zeigen. Ob es das jetzt aktuell schon gibt tut ÃŒberhaupt nichts zur
Sache. Seien wir einfach froh, dass wir eine Möglichkeit haben, "boolean
rÌckwÀrts" irgendwie darzustellen. Eine Konvention schon vor dem Einsatz zu
haben, schafft uns in diesem Bereich eine Möglichkeit, gar nichts anderes als
verstehbaren Wert in das Wiki aufzunehmen.

Freu dich doch darÃŒber.

Gruß, Bernd
--
Gewinn anderer wird fast wie Verlust empfunden. - Wilhelm Busch
Dirk Stöcker
2008-08-08 11:55:26 UTC
Permalink
Post by Bernd Wurst
Post by Dirk Stöcker
Dann kann
man diese dÀmliche "-1"-Regel abschaffen.
Kann man nicht diese Leute abschaffen, die alles abschaffen wollen?
Ach nee, kann man nicht, weil wir ja Freiheit als oberstes Ziel auf unsere
Aktionen kleben. Und unter Freiheit verstehe ich, dass nichts "abgeschafft"
oder "verboten" wird.
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Post by Bernd Wurst
Es wird definitiv irgenwo irgendwelche richtungsbezogenen Tags geben, die
parallel zum oneway existieren können und nicht notwendigerweise in die selbe
Richtung zeigen. Ob es das jetzt aktuell schon gibt tut ÃŒberhaupt nichts zur
Sache. Seien wir einfach froh, dass wir eine Möglichkeit haben, "boolean
rÌckwÀrts" irgendwie darzustellen. Eine Konvention schon vor dem Einsatz zu
haben, schafft uns in diesem Bereich eine Möglichkeit, gar nichts anderes als
verstehbaren Wert in das Wiki aufzunehmen.
Freu dich doch darÃŒber.
Wenn es eine vernÌnftige anwendbare Regel wÀre, gern, aber
a) Das ist nicht automatisch erkennbar
b) Gilt nur fÃŒr oneway, kann nicht auf andere Tags ÃŒbertragen werden
c) Wird kaum angewendet
d) Macht die Software unnötig kompliziert

Ich habe nichts gegen Auslegungsfragen. Jeder nach seinem Belieben. Nur
diese RichtungsabhÀngig ist leider nun mal ein Grundkonzept, was in OSM
momentan vollkommen ungeklÀrt ist (und deshalb wohl auch nur bei oneway
funktioniert, weil es hier in jeder Software direkt abgebildet wird). Eine
generelle Lösung fehlt.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Frederik Ramm
2008-08-08 12:41:40 UTC
Permalink
Hallo,
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?

Bye
Frederik
Dirk Stöcker
2008-08-08 12:57:53 UTC
Permalink
Post by Frederik Ramm
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?
Deswegen:

a) Alle momentanen -1 anschauen (knapp 1300)
b) Wenn drehbar dann durch oneway=yes ersetzen.
c) Wenn -1 nachher weg ist, dann wars Unfug.

Ist doch einfach :-)

Alternativ - Bessere allgemeingültige Lösung finden und Datenbestand
konvertieren.

Ich hatte ja mal folgende Idee:

Jedes Tag kann zu "xxx:+", "xxx:-" (oder "+:xxx", "-:xxx") werden.
+ bedeutet dabei in Richtung Weg.
- entgegengesetzt des Weges.

Das wäre allgemeingültig (ist dafür nicht unbedingt sehr intuitiv). Passt
auch gut mit der ":left"-, ":right"-Variante zusammen.

oneway=yes wäre dann korrekt oneway:+=yes,
oneway=-1 wäre dann korrektr oneway:-=yes

Als Legacy-Lösung könnte man "oneway" in der bisherigen Form weiter
unterstützen (statt mit einem Schlag 400000 Einträge zu ändern).

Egal wie es wird, wir brauchen einen Standard dafür, sonst haben wir
lauter verschiedene Lösungen, die man softwaretechnisch dann gar nicht
mehr in den Griff bekommt.

Allgemeingültig --> Klappt auch für maxspeed, access, was-weiß-ich-alles.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Andreas Jacob
2008-08-08 13:34:57 UTC
Permalink
Hallo Dirk
Post by Dirk Stöcker
Jedes Tag kann zu "xxx:+", "xxx:-" (oder "+:xxx", "-:xxx") werden.
+ bedeutet dabei in Richtung Weg.
- entgegengesetzt des Weges.
Das wäre allgemeingültig (ist dafür nicht unbedingt sehr intuitiv). Passt
auch gut mit der ":left"-, ":right"-Variante zusammen.
Bzgl. der Intuitivität muss ich dir leider zustimmen. Das wäre wohl zu
gebrauchen, wenn die Editoren das kapseln würden.
Post by Dirk Stöcker
oneway=yes wäre dann korrekt oneway:+=yes,
oneway=-1 wäre dann korrektr oneway:-=yes
Als Legacy-Lösung könnte man "oneway" in der bisherigen Form weiter
unterstützen (statt mit einem Schlag 400000 Einträge zu ändern).
Egal wie es wird, wir brauchen einen Standard dafür, sonst haben wir
lauter verschiedene Lösungen, die man softwaretechnisch dann gar nicht
mehr in den Griff bekommt.
Allgemeingültig --> Klappt auch für maxspeed, access, was-weiß-ich-alles.
Das ist insofern allgemeingültig, so lange du für die Richtungsfahrbahnen
identische Beschilderungen hast, was bei einer Spur pro Richtung zwangsweise
gegeben ist, sieht bei mehreren Fahrspuren pro Richtung schon wieder ganz
anders aus. Ich sinne auch schon einige Zeit über ein konsistentes,
umfassendes und trotzdem einfaches Schema bzgl. Richungsrelevantem Taggen
nach. Eingefallen ist mir da schon vieles, allerdings habe ich es immer wieder
als unpraktikabel verwerfen müssen. Vielleicht lässt sich so etwas wirklich
nur durch optische Unterstützung der Editoren einfach halten.

Gruss Andreas
Christian Malolepszy
2008-08-08 13:35:21 UTC
Permalink
Post by Dirk Stöcker
Post by Frederik Ramm
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?
a) Alle momentanen -1 anschauen (knapp 1300)
b) Wenn drehbar dann durch oneway=yes ersetzen.
c) Wenn -1 nachher weg ist, dann wars Unfug.
Ist doch einfach :-)
bei den meisten Wegen wird es so sein wie hier in den drei
folgenden Beispielen.
es spricht eigentlich nichts dagegen sie zu drehen, auch in den
Nodes sind keine Tags außer <tag k="created_by" v="JOSM"/>.
Der Erfasser hat sie von links nach rechts gezeichnet,
die Einbahnstraße verläuft aber andersherum und da es -1 gibt
macht man sich die "Arbeit" mit dem drehen der Wege nicht.

Da bei dem Projekt jeder die Daten ändern kann, so wie er meint,
daß es richtig ist ....
$ ./oneway_aufraeumen.sh
;-))))
Keine Panik, das script gibt es noch nicht.

PS: wer sagt mir, daß ich die Namen von links nach rechts
schreiben soll und nicht umgekehrt?
-> "Irrgarten" => "netragrrI"
Oder wie wärs mit highway=false für Wälder?
Irgendeiner baut es schon irgendwann in den Render ein ;-)
was interessieren mich die Probleme anderer, wenn ich es so
erfassen will, dann mache ich es auch!

In dem Sinne:
Wir sind eine Community, die miteinander lebt. Man kann sich
auf Normen und Vorgehensweisen verständigen. Strenge Prüfungen
und Verbote an der API nützen genausowenig wie Leute die alles
anders machen. Hauptsache sie haben ihr -1!

Gruß
Christian

<way id="4274375" timestamp="2008-03-22T08:21:35Z" user="">
<nd ref="25161088"/>
<nd ref="25600127"/>
<tag k="highway" v="unclassified"/>
<tag k="created_by" v="JOSM"/>
<tag k="maxspeed" v="50"/>
<tag k="name" v="Irrgarten"/>
<tag k="oneway" v="-1"/>
</way>

<way id="7979268" timestamp="2007-11-01T10:12:31Z" user="">
<nd ref="59598831"/>
<nd ref="59598833"/>
<nd ref="59598834"/>
<nd ref="59598826"/>
<tag k="created_by" v="JOSM"/>
<tag k="name" v="Goldener Winkel"/>
<tag k="highway" v="residential"/>
<tag k="oneway" v="-1"/>
</way>
<way id="7995375" timestamp="2008-06-12T15:01:39Z" user="">
<nd ref="34042690"/>
<nd ref="25761178"/>
<tag k="postal_code" v="30159"/>
<tag k="name" v="Ebhardtstraße"/>
<tag k="created_by" v="Potlatch 0.9c"/>
<tag k="highway" v="residential"/>
<tag k="oneway" v="-1"/>
</way>
Andreas Jacob
2008-08-08 13:14:00 UTC
Permalink
Post by Tobias Wendorff
Hallo,
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?
Nun ja, aus dieser Argumentation könnte man auch ableiten, dass jede Änderung
an von anderen eingepflegten Daten einer ausführlichen Diskussion zwischen den
Beteiligten zur Voraussetzung hat. Und ich glaube, dass dies niemand hier
wirklich befürworten würde. Keine Frage, Kommunikation muss sein, aber nicht
vor dem Ändern jeglicher Bestandsdaten.

Mir ist es aktuell egal, ob eine Einbahnstrasse nur mit einem Tag oder mit
mehreren beschrieben werden kann. Aber auch nur, da ich aktuell "nur" Mapper
bin, und keine Anwendung schreibe. Ich glaube allerdings, dass viele Mapper
nicht verärgert wären, wenn man ihre Definition einer Einbahnstrasse ändern
würde. Mir ist es jetzt schon mehrfach passiert, dass mich Neulinge, welche
ich anschrieb, um evtl. Hilfe beim Einstieg in OSM anzubieten, mich fragten,
"Was denn nun die richtige Variante des Taggens ist, und ob es Vor- oder
Nachteile zwischen den Varianten geben würde?" Daraus leite ich ab, dass die
entstandene Vielfalt auch verwirrend wirken kann.

Bei der ganzen Diskussion könnte ich mir sehr gut vorstellen, dass daraus
durchaus ein Edit-War entwickeln könnte. Vielleicht wäre ein Tag clever,
welches man anbringen könnte, um den Wunsch mitzuteilen, dass dieser oder
jener key nicht von Skripten bearbeitet werden soll. So in etwa für das
Einbahnstrassen-"Problem" "noscript;oneway". Ich persönlich würde von soetwas
nicht Gebrauch machen wollen, aber vielleicht kann es ja die eine oder andere
Diskussion nach Skriptläufen erübrigen. ;-)

Gruss Andreas
Frederik Ramm
2008-08-08 13:40:43 UTC
Permalink
Hallo,
Post by Andreas Jacob
Nun ja, aus dieser Argumentation könnte man auch ableiten, dass jede Änderung
an von anderen eingepflegten Daten einer ausführlichen Diskussion zwischen den
Beteiligten zur Voraussetzung hat. Und ich glaube, dass dies niemand hier
wirklich befürworten würde. Keine Frage, Kommunikation muss sein, aber nicht
vor dem Ändern jeglicher Bestandsdaten.
Das Aendern von Bestandsdaten ist eine Sache. Zumeist geht es ja aber
einher mit dem Verlangen: "Jetzt wo ich erstmal alle X-Tags aufgeraeumt
hab, soll bitte niemand mehr ein falsches X-Tag anlegen duerfen". Und da
sehe ich das Problem - das wird nicht gehen, weder technisch (weil die
Regeln alle in die API kodiert werden muessten) noch politisch (wegen
der "wer entscheidet was erlaubt ist"-Frage).

Wen man aber ohnehin immer davon ausgehen muss, dass sich im
Datenbestand eine Anzahl von "unaufgeraeumten" Tags befinden, die seit
dem letzten "Aufraeumen" entstanden sind - wozu dann noch aufraeumen?
Ein Renderer, der mit oneway=true und oneway=yes umgehen kann, dem ist
es doch egal, ob er 999 mal true und 1 mal yes hat oder 500 mal das eine
und 500 mal das andre.

Bye
Frederik
Dirk Stöcker
2008-08-08 19:43:03 UTC
Permalink
Post by Frederik Ramm
Wen man aber ohnehin immer davon ausgehen muss, dass sich im
Datenbestand eine Anzahl von "unaufgeraeumten" Tags befinden, die seit
dem letzten "Aufraeumen" entstanden sind - wozu dann noch aufraeumen?
Ein Renderer, der mit oneway=true und oneway=yes umgehen kann, dem ist
es doch egal, ob er 999 mal true und 1 mal yes hat oder 500 mal das eine
und 500 mal das andre.
Ja. Gegen die Booleans sage ich ja gar nichts. Finde ich zwar nichts
schön, aber sei es drum. Das ist technisch einfach zu lösen. Mich stört
nur die fehlende Allgemeingültigkeit des Richtungsbezuges. Da werden
nämlich in Zukunft noch mehr Sachen kommen, die darauf aufbauen und jeder
Mapper wird wieder und wieder schimpfen, wenn irgendwo ein Weg gedreht
oder verbunden wird, weil keine Software die Richtungsbezüge korrigiert
(oder aufgrund von mannigfaltigen Regeln überhaupt könnte).

Schau mal im TagWatch nach left, right, opposite, other und sag
mir, wie dass algorithmisch handhabbar sein soll. Bei vielen Sachen
sehe ich ja nicht mal als Mensch durch, was gemeint ist, wie soll das ein
Programm klarkommen.

P.S. Um noch mal zum alten Thema zurückzuschweifen - Du kannst die
Booleans auch technisch in den Griff bekommen. Wenn der Server beim Upload
einfach bekannte Konvertierungen vornimmt hast Du auch einen konsistenten
Datenbestand ;-)

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Christian Malolepszy
2008-08-08 20:07:46 UTC
Permalink
Post by Dirk Stöcker
Post by Frederik Ramm
Wen man aber ohnehin immer davon ausgehen muss, dass sich im
Datenbestand eine Anzahl von "unaufgeraeumten" Tags befinden, die seit
dem letzten "Aufraeumen" entstanden sind - wozu dann noch aufraeumen?
Ein Renderer, der mit oneway=true und oneway=yes umgehen kann, dem ist
es doch egal, ob er 999 mal true und 1 mal yes hat oder 500 mal das eine
und 500 mal das andre.
Ja. Gegen die Booleans sage ich ja gar nichts. Finde ich zwar nichts
schön, aber sei es drum. Das ist technisch einfach zu lösen. Mich stört
nur die fehlende Allgemeingültigkeit des Richtungsbezuges. Da werden
nämlich in Zukunft noch mehr Sachen kommen, die darauf aufbauen und jeder
Mapper wird wieder und wieder schimpfen, wenn irgendwo ein Weg gedreht oder
verbunden wird, weil keine Software die Richtungsbezüge korrigiert (oder
aufgrund von mannigfaltigen Regeln überhaupt könnte).
man sollte vielleicht die richtung der wege abschaffen und wir
sollten uns ein konstrukt überlegen das uns mehr bringt als pfeile bzw die
ordnung der nodes innerhalb eines wegs

bei oneway könnte man zum beispiel die tags auf die endnodes
setzen oneway=begin & oneway=end
oder ein einfahrt verbotenschild am ende und ein einbahnstrassen
schild am anfang
Post by Dirk Stöcker
Schau mal im TagWatch nach left, right, opposite, other und sag mir, wie
dass algorithmisch handhabbar sein soll. Bei vielen Sachen sehe ich ja
nicht mal als Mensch durch, was gemeint ist, wie soll das ein Programm
klarkommen.
P.S. Um noch mal zum alten Thema zurückzuschweifen - Du kannst die
Booleans auch technisch in den Griff bekommen. Wenn der Server beim Upload
einfach bekannte Konvertierungen vornimmt hast Du auch einen konsistenten
Datenbestand ;-)
das ist ja auch mein tip.... aber na ja man ändert die daten des
mappers und das könnte ih verärgern
Post by Dirk Stöcker
Ciao
--
http://www.dstoecker.eu/ (PGP key available)
_______________________________________________
Talk-de mailing list
http://lists.openstreetmap.org/listinfo/talk-de
fred
2008-08-08 22:18:09 UTC
Permalink
Hi,
Post by Dirk Stöcker
Ja. Gegen die Booleans sage ich ja gar nichts. Finde ich zwar nichts
schön, aber sei es drum. Das ist technisch einfach zu lösen. Mich stört
nur die fehlende Allgemeingültigkeit des Richtungsbezuges. Da werden
nämlich in Zukunft noch mehr Sachen kommen, die darauf aufbauen und jeder
Seit Jahr und Tag predige ich jedes Mal, wenn wieder jemand mit einem
tollen Proposal kommt, das irgendwie "left" und "right" enthaelt: Lasst es,
Leute, das gibt nur Stress. (Oftmals handelt es sich dabei auch um den
ausufernden Versuch, mehrere Objekte als eines zu konstruieren, so nach dem
Motto: Eine Strasse hat cycleway_left=track, dann will man diesen Track
aber noch oneway machen und mit einer Oberflaeche versehen, also
cycleway_left_surface=paved und cycleway_left_oneway=true... usw. usw.) Ich
bin inhaltlich also ganz auf Deiner Linie.

Allerdings muss ich mich selber auch der von mir postulierten
Mapper-Freundlichkeit beugen, und mir ist bislang noch kein wirklich gutes
Konzept eingefallen, wie man das besser und trotzdem noch menschenlesbar
machen kann. Man kann halt nicht sagen "wir kapseln die Komplexitaet im
Editor", denn wer kann/will schon ALLE Editoren fixen.
Post by Dirk Stöcker
P.S. Um noch mal zum alten Thema zurückzuschweifen - Du kannst die
Booleans auch technisch in den Griff bekommen. Wenn der Server beim Upload
einfach bekannte Konvertierungen vornimmt hast Du auch einen konsistenten
Datenbestand ;-)
Das ist mir schon klar. Aber ich habe gerade per E-Mail mit jemandem
kommuniziert, der mich fragte, wie man denn per XML formulieren kann, dass
fuer bestimmte Arten von Seezeichen (Bojen usw.) in Abhaengigkeit von ihrer
Farbe nur bestimmte "Topzeichen" zulaessig seien, und wie man ferner
ausdruecken kann, dass diese Regeln in den USA leicht unterschiedlich von
denen in Deutschland sind.

Meine Antwort war natuerlich, dass wir so ein Regelsystem gar nicht haben
und man das allenfalls in den Validator packen koennte.

Aber angenommen, wir *haetten* so ein Regelsystem, so wuerde es mit
Sicherheit in kurzer Zeit sehr komplex werden, und es gaebe aehnlich viele
Maintainer dafuer wie fuer unsere Renderer-Styles (2 oder 3). Es wuerde
sicherlich Bugs enthalten. Und es waere voellig unklar, wer denn jetzt die
Autoritaet darueber hat, was erlaubt ist und was nicht. Meine Meinung ist,
dass man mit so einer Vorkehrung (Datenkorrektur beim Upload) eine
veritable Buechse der Pandora oeffnen wuerde. Klar, ist nur gut gemeint,
man wollte ja "nur" die Booleans fixen. Aber am Ende geht hier alles den
Bach runter.

Bye
Frederik
Michael Bergbauer
2008-08-08 14:14:15 UTC
Permalink
Post by Tobias Wendorff
Hallo,
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?
Lasst uns doch bitte mal einen Schritt zuruecktreten. Es geht naemlich
nicht darum, ob nun TRUE, true, YES, yes oder 1 in der Datenbank steht,
es geht auch nicht darum, dass die Freiheit eingeschraenkt werden soll
und sich irgendjemand anmasst, allgemeinverbindlich etwas als Unfug zu
deklarieren.

Wir wollen mit Openstreetmap etwas erreichen, naemlich Kartendaten in
einer Art und Weise zur Verfuegung stellen, dass sie von der
Allgemeinheit ohne grosse Einschraenkungen benutzt werden koennen.

Benutzt werden koennen setzt aber voraus, dass die Daten benutzbar sind,
insbesondere eben, dass die Daten in einem definierten Format abrufbar
sind, parseable sind.

Warum taggen die meisten Leute Wege mit einem 'highway'-Tag und einigen
bestimmten Werten? Weil sie ihre erfassten Daten gerne gerendert sehen
wollen und sich so einschraenken. Das Tagging-Schema, das im Wiki
beschrieben ist und weiterentwickelt ist, fasse ich persoenlich als
'Best (current) practise' auf, und es schraenkt auch nicht ein. Jeder
kann jederzeit andere Tags und Werte benutzen - und er bekommt sie auch
gerendert, wenn er sich selbst nen Renderer dafuer anpasst.

Ob aber nun "yes", "no" oder "true", "false", "0", "1" und "-1" fuer
booleans verwendet werden - irgendwie finde ich es laecherlich. Haben
wir nichts besseres zu tun, als darueber zu streiten? In der Zeit, die
hier mit diskutieren verbracht worden ist haette man sicherlich einiges
an Code schreiben koennen, der mit diesem "Problem" umgehen kann.
--
Michael Bergbauer <michael-nrBG30I701Hw/***@public.gmane.org>
Munich, Germany
Tobias Wendorff
2008-08-08 14:36:12 UTC
Permalink
Post by Michael Bergbauer
Ob aber nun "yes", "no" oder "true", "false", "0", "1" und "-1" fuer
booleans verwendet werden - irgendwie finde ich es laecherlich. Haben
wir nichts besseres zu tun, als darueber zu streiten? In der Zeit, die
hier mit diskutieren verbracht worden ist haette man sicherlich einiges
an Code schreiben koennen, der mit diesem "Problem" umgehen kann.
[x] habe ich (für meine Scripts) gemacht:

Sobald in einem Datensatz Dinge auftauchen, die nicht
"ja / nein / 1 / 0 / true / false / -1" entsprechen, werde ich gefragt,
wie die Sonderfälle gehandhabt werden sollen.
FreeWorld
2008-08-08 13:24:10 UTC
Permalink
Post by Bernd Wurst
Hallo.
Post by Dirk Stöcker
Dann kann
man diese dämliche "-1"-Regel abschaffen.
Kann man nicht diese Leute abschaffen, die alles abschaffen wollen?
Ach nee, kann man nicht, weil wir ja Freiheit als oberstes Ziel auf unsere
Aktionen kleben. Und unter Freiheit verstehe ich, dass nichts "abgeschafft"
oder "verboten" wird.
Es wird definitiv irgenwo irgendwelche richtungsbezogenen Tags geben, die
parallel zum oneway existieren können und nicht notwendigerweise in die selbe
Richtung zeigen. Ob es das jetzt aktuell schon gibt tut überhaupt nichts zur
Sache. Seien wir einfach froh, dass wir eine Möglichkeit haben, "boolean
rückwärts" irgendwie darzustellen. Eine Konvention schon vor dem Einsatz zu
haben, schafft uns in diesem Bereich eine Möglichkeit, gar nichts anderes als
verstehbaren Wert in das Wiki aufzunehmen.
Freu dich doch darüber.
Gruß, Bernd
Was ist denn ein boolean rückwärts? Ist dann tunnel=-1 ne Brücke?
Oder building=-1 ne Grube? Ich denke tatsächlich diesen -1 Wert braucht
man in dem Zusammenhang eines boolean nicht. Nennt mir bitte nur ein
Einziges, wegen mir frei konstruiertes Szenario, wo dieser -1 Wert
irgendetwas verbessert.

Grüße
Bernd Wurst
2008-08-08 14:40:05 UTC
Permalink
Hallo.

Mit "boolean rÌckwÀrts" meine ich, ein bool'scher Wert, der zwar "ja" sagt,
aber sich auf die gegenlÀufige Richtung bezieht.
Post by FreeWorld
wegen mir frei konstruiertes Szenario, wo dieser -1 Wert
irgendetwas verbessert.
Es gibt mehrere Tags, deren Bedeutung sich auf die Richtung bezieht.

Z.B. incline, Steigung. Es gab den Vorschlag, incline=xx% an einen Weg zu
hÀngen. Damit man weiß, in welche Richtung die Steigung geht, ist die
Richtung des Wegs immer berg-aufwÀrts.

Jetzt ist das aber eine Einbahnstraße mit starkem GefÀlle.

ergo:
incline=10%
oneway=-1

Gruß, Bernd
--
Die Nase ist die Bohrinsel des kleinen Mannes.
Mario Salvini
2008-08-08 16:54:39 UTC
Permalink
Post by Bernd Wurst
Hallo.
Mit "boolean rückwärts" meine ich, ein bool'scher Wert, der zwar "ja" sagt,
aber sich auf die gegenläufige Richtung bezieht.
Post by FreeWorld
wegen mir frei konstruiertes Szenario, wo dieser -1 Wert
irgendetwas verbessert.
Es gibt mehrere Tags, deren Bedeutung sich auf die Richtung bezieht.
Z.B. incline, Steigung. Es gab den Vorschlag, incline=xx% an einen Weg zu
hängen. Damit man weiß, in welche Richtung die Steigung geht, ist die
Richtung des Wegs immer berg-aufwärts.
Jetzt ist das aber eine Einbahnstraße mit starkem Gefälle.
incline=10%
oneway=-1
wieso nicht andersrum taggen?

incline= -10%
oneway=1 (und dann antürkllich den weg in die richtige richtung umkehren)
Bernd Wurst
2008-08-08 17:11:59 UTC
Permalink
Hallo.
Post by Mario Salvini
wieso nicht andersrum taggen?
incline= -10%
oneway=1 (und dann antürkllich den weg in die richtige richtung umkehren)
Weil dann wieder jemand schreit, dass das ja unintuitiv sei, plötzlich die
Steigung negativ zu machen und man doch lieber die Einbahnstraße andersrum
machen soll. Schließlich wurde bei Steigung festgelegt, der Weg zeige nach
oben. Mit -10% nach oben zeigen ist auch unschön.
Es ist ein konstruiertes Beispiel, ja.


Ich klink mich jetzt aus dem Thread aus, es gibt hier ne Brigade von Leuten
die der felsenfesten Überzeugung sind, für oneway kann es nur einzig und
allein eine Art geben, wie man das taggen kann.

Mir ist es echt scheissegal wie das getagged wird, ich seh nur noch immer
keinen Grund, warum es für irgendeinen mittelmäßig begabten Programmierer
einen Vorteil bringen soll wenn er bei einem von hunderten Keys plötzlich nur
noch einen Wert statt drei fest definierter Werte vorfindet.

Ein Daten-Verwender muss mit Ähnlichkeitssuche Straßennamen angleichen um
Tippfehler zu eliminieren, er muss 'str.', 'strasse' und 'straße' gleich
behandeln, er muss Wege die sich in unterschiedlichen Nodes mit der selben
Koordinate treffen als verbunden behandeln.

Da wird es ihm sicherlich enorm weiter helfen, wenn er die Abfrage
if (key=='oneway' and value.lower() in ['yes','true','1'])
durch
if (key=='oneway' and value.lower() == 'yes')
ersetzen kann. Er wird euch auf Händen tragen für die gesparten 10 Sekunden
Arbeit.


Over and out, hab echt kein Bock mehr.

Gruß, Bernd
--
Ich möchte nichts mit Naturkost zu tun haben.
In meinem Alter braucht man alle Konservierungsstoffe, die man bekommen kann.
Stefan Schwan
2008-08-08 12:02:59 UTC
Permalink
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Einbahnstraße entgegen der Richtung des Ways...
Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen?
Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen
"left" oder "right"...
Left/right geht auch andersrum. Ist kein also Argument.
Wenn man den weg dreht ist das was vorher links war, rechts. Je
nachdem wieviele left/right geschichten am weg hängen ist es deutlich
einfacher einmal yes/true/1 in -1 zu ändern.
Post by Dirk Stöcker
a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die
Richtung z.B. so ein, wie ich gefahren bin.
Wenn du den "Standard" aus deinem eigenen Verhalten definieren willst
- bitte schön...

Es könnte eventuell helfen, wenn du eine neue Killer-Applikation
programmierst die nur auf oneway=yes reagiert - möglicherweise ändern
andere dann ihr Verhalten beim Taggen von Oneways, möglicherweise sind
ihnen aber dein Programm und deine Probleme eine Disjunktion über 3
Alternativen zu implementieren aber auch sch*** egal.
Dirk Stöcker
2008-08-08 12:48:26 UTC
Permalink
Post by Stefan Schwan
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Post by Stefan Schwan
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Einbahnstraße entgegen der Richtung des Ways...
Ja und. Das erklärt nichts. Warum kann man den Weg nicht einfach umdrehen?
Manche Mapper setzen zB die Richtung berg-aufwärts, andere benutzen
"left" oder "right"...
Left/right geht auch andersrum. Ist kein also Argument.
Wenn man den weg dreht ist das was vorher links war, rechts. Je
nachdem wieviele left/right geschichten am weg hängen ist es deutlich
einfacher einmal yes/true/1 in -1 zu ändern.
Das macht z.B. JOSM mittlerweile automatisch. Nur eben mehr durch Raten.
Ein vernünftiger einheitlicher Standard würde hier helfen. Und darum geht
es eben. Nicht um -1 oder nicht, sondern darum, dass dies eben nur mit
oneway klappt und nicht allgemein.
Post by Stefan Schwan
Post by Dirk Stöcker
a) Erstens ist das kein Standard, also eh nichtssagend. Ich trage die
Richtung z.B. so ein, wie ich gefahren bin.
Wenn du den "Standard" aus deinem eigenen Verhalten definieren willst
- bitte schön...
a) Nicht dokumentiert
b) "Manche Mapper..."
c) Nicht an den Daten zu erkennen
--> Kein Standard. Was hat das mit meinem Verhalten zu tun?
Post by Stefan Schwan
Es könnte eventuell helfen, wenn du eine neue Killer-Applikation
programmierst die nur auf oneway=yes reagiert - möglicherweise ändern
andere dann ihr Verhalten beim Taggen von Oneways, möglicherweise sind
ihnen aber dein Programm und deine Probleme eine Disjunktion über 3
Alternativen zu implementieren aber auch sch*** egal.
Kann es sein, daß Du bewußt versuchst alles falsch zu verstehen, damit Du
andere Meinungen als blöd darstellen kannst? In diesem Fall war das meine
letzte Antwort auf Deine Posts.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Stefan Schwan
2008-08-08 14:03:51 UTC
Permalink
Das macht z.B. JOSM mittlerweile automatisch. Nur eben mehr durch Raten. Ein
vernünftiger einheitlicher Standard würde hier helfen. Und darum geht es
eben. Nicht um -1 oder nicht, sondern darum, dass dies eben nur mit oneway
klappt und nicht allgemein.
Außer Flüssen fällt mir keine andere Situation ein, wo die Richtung
überhaupt eine Rolle spielt..
a) Nicht dokumentiert
b) "Manche Mapper..."
c) Nicht an den Daten zu erkennen
--> Kein Standard. Was hat das mit meinem Verhalten zu tun?
Das es eben keinen Standards gibt, sondern nur Konventionen. Nur weil
du etwas als vermeintlichen Standard annimmst, heißt das noch lange
nicht, das sich andere Mapper danach richten müssten, oder das es
automatisierte "Berichtigungen" geben sollte - insbesondere, wenn es
defacto nicht falsch ist.
Kann es sein, daß Du bewußt versuchst alles falsch zu verstehen, damit Du
andere Meinungen als blöd darstellen kannst? In diesem Fall war das meine
letzte Antwort auf Deine Posts.
Keineswegs - ich wundere mich nur darüber, das du sämtliche Vorschläge
wie man mit sowas umgeht gekonnt ignorierst und weiterhin darauf
beharrst, das es hier ein Problem gibt wo keins ist:
Es ist nämlich "softwaremäßig" überhaupt kein Problem eine ODER
Anweisung aufzunehmen. Wir reden ja nicht von hunderten sondern
überschaubaren 3 oder 4 Möglichkeiten.

Gruß
Stefan
Florian Lohoff
2008-08-09 08:27:55 UTC
Permalink
Post by Stefan Schwan
Keineswegs - ich wundere mich nur darüber, das du sämtliche Vorschläge
wie man mit sowas umgeht gekonnt ignorierst und weiterhin darauf
Es ist nämlich "softwaremäßig" überhaupt kein Problem eine ODER
Anweisung aufzunehmen. Wir reden ja nicht von hunderten sondern
überschaubaren 3 oder 4 Möglichkeiten.
oneway=abends hin und morgens zurueck

Das mit den 3-4 Moeglichkeiten ist schoenrederei ... Im falle von
booleans mit yes/true/1/no/false/0 gehts ja noch - das ist nen
kinderteller.

Aber um die daten die in der Datenbank stehen wirklich zu interpretieren
wie der author das gemeint hat (und nur das ist wirklich was zaehlt)
muesste man jeweils den Author fragen da die tags die derjenige
verwendet auch von ihm semantisch erfunden wurden.

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Bernd Wurst
2008-08-08 10:00:36 UTC
Permalink
Hallo.
Post by Dirk Stöcker
Ich frage mich immer noch, wozu -1 da sein soll. Ich kann mir keinen Fall
vorstellen, wo man es gebrauchen kann.
Oneway ist abhÀngig von der Richtung des Weges. Es gibt aber auch andere Tags,
die AbhÀngig von der Richtung sind. So z.B. das eigentlich obsolete incline,
aber auch unabhÀngig von nem konkreten Beispiel, es wird irgendwelche Dinge
geben und daher sind wir froh, dass es möglichkeiten gibt, sowas auch "falsch
herum" eintragen zu können.

Außerdem können die Pedanten unter uns ja den Weg absichtlich falsch rum
setzen und dann mit oneway=-1 auszeichnen um sich nicht
zwischen "true", "yes" oder "1" entscheiden zu mÃŒssen. ;-)

Gruß, Bernd
--
Wir stehen gesellschaftlich auf Stufe 3!
Da werden wir zwar verprÃŒgelt, aber es gibt einen Grund dafÃŒr!
- Milhouse, Die Simpsons
Dirk Stöcker
2008-08-08 10:31:15 UTC
Permalink
Post by Bernd Wurst
Oneway ist abhÀngig von der Richtung des Weges. Es gibt aber auch andere Tags,
die AbhÀngig von der Richtung sind. So z.B. das eigentlich obsolete incline,
aber auch unabhÀngig von nem konkreten Beispiel, es wird irgendwelche Dinge
geben und daher sind wir froh, dass es möglichkeiten gibt, sowas auch "falsch
herum" eintragen zu können.
Auch wenn ich ansosnten Frederik recht gebe, dass man alles taggen soll
wie man will, wÀre ich bei oneway=-1 der Meinung die 1336 Wege in der
Datenbank mal alle durchzugehen und durch "drehen+yes" zu ersetzen wenn
möglich. Bleibt dann noch ein Grund fÌr -1 Ìbrig, dann soll meinetwegen
bleiben.

Allerdings sollte mal ein Standard fÃŒr richtungsbezogene Sachen gefunden
werden, damit man es in den Editoren automatisch handhaben kann. Der
jetzige Zustand ist leider zu chaotisch und fÃŒhrt deshalb zu Fehlern.

Fragen:
a) wie sollten richtungsbezogene Tags aussehen:
z.B. left:xxx, right:xxx oder xxx:left, xxx:right
b) wie sollten richtungsbezogene Values aussehen:
z.B. direction_reverseway, direction_way
(-1 ist schlecht, weil das vieles bedeuten kann, opposite ist auch
nicht ideal, da es sich auf vielen beziehen kann)

Hier ist ausnahmsweise mal Standardisierung angesagt, um es automatisieren
zu können.

Oneway wird wohl leider eine Ausnahme bleiben. Statt oneway=yes
wÀre nÀmlich z.B. "oneway=direction_way" eine bessere Wahl. Dann könnte
man es nÀmlich automatisch erkennen.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Michael Buege
2008-08-08 11:31:22 UTC
Permalink
Post by Dirk Stöcker
Oneway wird wohl leider eine Ausnahme bleiben. Statt oneway=yes
wäre nämlich z.B. "oneway=direction_way" eine bessere Wahl. Dann könnte
man es nämlich automatisch erkennen.
Was mich zu einer Frage fuehrt, die ich schon immer mal stellen wollte.
Keine Ahnung, ob das schon mal Diskussionsgegenstand war:
<http://www.sierichstrasse.de/>
<quote>
Die Sierichstrasse ist z.Zt. die einzige Strasse in Europa, die
Tageszeitabhängig ihre Richtung wechselt. Von 4 bis 12 Uhr kann man auf der
zweispurigen Straße stadteinwärts fahren, von 12 bis 4 Uhr stadtauswärts.
</quote>
Getaggt ist das momentan "oneway=morning to south, evening to North"
Hat irgendjemand einen besseren Vorschlag?
--
Michael
paul-2b/HCGXS5xi6ogTlOYt/ (Paul Lenz)
2008-08-08 12:06:08 UTC
Permalink
Post by Michael Buege
Die Sierichstrasse ist z.Zt. die einzige Strasse in
Europa, die Tageszeitabh?ngig ihre Richtung wechselt.
Würde ich nicht so sagen :)


Da wäre zumindest der Messeschnellweg (A37) in Hannover,
der während der CeBIT und der Industriemesse morgens
und abends jeweils für ein paar Stunden zu einer
4-spurigen Einbahnstraße in die jeweils benötigte
Richtung wird. Alles durch fernbediente Schranken und
Lichtzeichenanlagen geregelt.


Ich denke, so etwas ist weder zu taggen noch dem
schlauesten Routingprogramm zu vermitteln.




Paul
Frederik Granna
2008-08-08 12:13:58 UTC
Permalink
Was ist eigentlich mit Straßen die abhÀngig von der Urhzeit bestimmte
"Parameter" aufweisen?
Es gibt AutobahnteilstÃŒcke da ist von 7-16 Uhr Tempo 120KMh vorgegeben.

Ist ja so zimelich das selbe Problem
Post by Michael Buege
Post by Dirk Stöcker
Oneway wird wohl leider eine Ausnahme bleiben. Statt oneway=yes
wÀre nÀmlich z.B. "oneway=direction_way" eine bessere Wahl. Dann könnte
man es nÀmlich automatisch erkennen.
Was mich zu einer Frage fuehrt, die ich schon immer mal stellen wollte.
<http://www.sierichstrasse.de/>
<quote>
Die Sierichstrasse ist z.Zt. die einzige Strasse in Europa, die
TageszeitabhÀngig ihre Richtung wechselt. Von 4 bis 12 Uhr kann man auf der
zweispurigen Straße stadteinwÀrts fahren, von 12 bis 4 Uhr stadtauswÀrts.
</quote>
Getaggt ist das momentan "oneway=morning to south, evening to North"
Hat irgendjemand einen besseren Vorschlag?
Peter Herison
2008-08-08 17:39:38 UTC
Permalink
Was ist eigentlich mit Straßen die abhängig von der Urhzeit bestimmte
"Parameter" aufweisen?
Es gibt Autobahnteilstücke da ist von 7-16 Uhr Tempo 120KMh vorgegeben.
Ich haette da in Bad Homburg eine Strasse, die von 22-6 eine Sackgasse
ist...
Holger Issle
2008-08-08 17:55:11 UTC
Permalink
Post by Peter Herison
Ich haette da in Bad Homburg eine Strasse, die von 22-6 eine Sackgasse
ist...
Und diese ist in der Tat ein großer Murks, vor allem wenn man in dem
Hotel an der Ecke untergebracht ist... und das Navi den Murks nicht
kennt.
--
Ciao,
Holger (GUS-KOTAL, GUS#1100, GRR#51)

90-92 Honda CB400 10 Mm | 93-95 Yamaha TDM 850 26 Mm
95-97 KTM 620 LC4 13 Mm | seit 97 BMW R1100GS 69 Mm (Die Renndrecksau!)

cu @ http://www.issle.de
Frederik Granna
2008-08-09 09:51:48 UTC
Permalink
Es scheint da so einiges in die Richtung zu geben.
Hab im Wiki dazu nix gefunden
Post by Peter Herison
Was ist eigentlich mit Straßen die abhängig von der Urhzeit bestimmte
"Parameter" aufweisen?
Es gibt Autobahnteilstücke da ist von 7-16 Uhr Tempo 120KMh vorgegeben.
Ich haette da in Bad Homburg eine Strasse, die von 22-6 eine Sackgasse
ist...
_______________________________________________
Talk-de mailing list
http://lists.openstreetmap.org/listinfo/talk-de
Andreas Pothe
2008-08-08 18:48:19 UTC
Permalink
Post by Michael Buege
Die Sierichstrasse ist z.Zt. die einzige Strasse in Europa, die
Tageszeitabhängig ihre Richtung wechselt. Von 4 bis 12 Uhr kann man auf der
zweispurigen Straße stadteinwärts fahren, von 12 bis 4 Uhr stadtauswärts.
Aha. Kitzbühel liegt also nach Hamburger Meinung nicht in Europa.

CU
Andreas
FreeWorld
2008-08-08 10:16:12 UTC
Permalink
Ich verstehe auch nicht, warum es problematisch ist sich auf ein
einheitliches Schema zu einigen.
Bisher habe ich oneway=true benutzt, weil ich dachte das wäre am
verbreitetsten. Ist es wohl nicht. Wenn jetzt einer ein Skript durch die
Datenbank jagt und alles von true nach yes konvertiert und irgendwo
abgemacht wird, dass wir yes statt true benutzen, dann hätte ich da als
Mapper wirklich überhaupt kein Problem damit. Da fühle ich mich echt in
meiner Freiheit nicht eingeschränkt. Das würde mir auch irgendwie
Sicherheit geben, wenn überall yes steht, dass dann zumindest das
korrekt ist.
Das klingt ja hier manchmal so, als wäre es den Mappern unzumutbar einen
standartisierten Wahrheitswert zu verwenden.
Und wenn man nach 2 Wochen nochmal die Datenbank aufräumt diesbezüglich,
finde ich das auch nicht schlimm.

Ich weiß schon, dass einige denken, dass es eigentlich auch egal ist, da
ja eben alle 3 Varianten gerendert werden und es ja nur 3 sind usw. und
das stimmt auch. Es macht das Leben aber oft einfacher, wenn man nur
eine hat. Auch für die Mapper.

Also wie gesagt, von mir aus gerne vereinheitlichen. Ich stell mich
gerne um.

Grüße
Stefan Neufeind
2008-08-08 11:03:44 UTC
Permalink
Post by FreeWorld
Ich verstehe auch nicht, warum es problematisch ist sich auf ein
einheitliches Schema zu einigen.
Bisher habe ich oneway=true benutzt, weil ich dachte das wäre am
verbreitetsten. Ist es wohl nicht. Wenn jetzt einer ein Skript durch die
Datenbank jagt und alles von true nach yes konvertiert und irgendwo
abgemacht wird, dass wir yes statt true benutzen, dann hätte ich da als
Mapper wirklich überhaupt kein Problem damit. Da fühle ich mich echt in
meiner Freiheit nicht eingeschränkt. Das würde mir auch irgendwie
Sicherheit geben, wenn überall yes steht, dass dann zumindest das
korrekt ist.
Das klingt ja hier manchmal so, als wäre es den Mappern unzumutbar einen
standartisierten Wahrheitswert zu verwenden.
Und wenn man nach 2 Wochen nochmal die Datenbank aufräumt diesbezüglich,
finde ich das auch nicht schlimm.
Ich weiß schon, dass einige denken, dass es eigentlich auch egal ist, da
ja eben alle 3 Varianten gerendert werden und es ja nur 3 sind usw. und
das stimmt auch. Es macht das Leben aber oft einfacher, wenn man nur
eine hat. Auch für die Mapper.
Also wie gesagt, von mir aus gerne vereinheitlichen. Ich stell mich
gerne um.
Grundsätzlich teile ich deine Meinung in diesen speziellen Fällen.

Für Infos abseits davon muss jedoch trotzdem noch Platz/Freiheit bleiben.
Dimitri Junker
2008-08-08 13:44:04 UTC
Permalink
Hallo,
Post by Bernd Wurst
Nein, nach dem Motto: Wenn es noch nichts gibt was genau das darstellt
was ich will, dann nehm ich was ähnliches oder was ganz anderes.
Da sind wir uns ja einig, aber es ging darum ob man statt yes auch true
Post by Bernd Wurst
tumben Datentypisten
Tun wir doch.
Die Mail die ich zitierte war ja auch nicht von Dir
Post by Bernd Wurst
Ich versteh dein Problem nicht.
Es ging nur darum, daß ich die große Angst vor Regeln die Frederik so
Post by Bernd Wurst
weil feste Regeln den Evolutionsprozess zerstoeren, den Mapper zum
tumben Datentypisten machen und dem Projekt die Dynamik nehmen, die es
zum Leben braucht.
nicht nachvollziehen kann.
Post by Bernd Wurst
Da ich in meiner Freizeit mappe, möchte ich eigentlich erstmal dass mir
das Leben nicht schwer gemacht wird.
Das gleiche gilt aber auch für die Programmierer.

Wir solten eine Methode finden wie es für alle einfacher wird. Derzeit
benutzt man entweder Presets oder tippt einfach ein, ist man sich nicht
sicher schaut man ins Wiki, eher aufwendig. Warum kann man die Map-Features-
Seite nicht in eine maschinenlesbare Form bringen, so daß alle Editoren sie
lesen können. Sie könnten dann einfach anzeigen ob die Eingabe richtig oder
falsch (besser unbekannt) ist. Genau so wie eine Textverarbeitung ihr
unbekannte Wörter unterstreicht. Bei Josm gibt es ja schon die
Autovervollständigung, die benutzt aber wenn ich es richtig sehe alles was
gerade geladen ist als Vorlage. Gibt es also in dem Gebiet noch kein
cycleway=opposite hilft mir JOSM da nicht zu wissen ob es mit einem oder 2 p
geschrieben wird. Hier könnte es z.B. alles was in der Map-Features-Seite
steht mit einem grünen Kreis und alles was irgendwo im geladenen Bereich ist
mit einem gelben Kreis markieren.

Gruß
Dimitri
Stefan Schwan
2008-08-08 09:13:42 UTC
Permalink
Post by Dimitri Junker
So nach dem Motto, ich hab was eigenes kreiert, ich schreibe oneway=true
statt yes? Warum dann nicht auch noch ja, oui, natürlich und "wag es nicht
da rein zu fahren"
[...]
Ich möchte, daß sie für möglichst
viele Leute nützlich sind.
genau - schon deshalb wirst du auch von vornherein davon Abstand
nehmen etwas anderes als true, yes oder 1 dafür zu nehmen....
Post by Dimitri Junker
Und wenn ich da true statt yes eingebe sind die
Daten erstmal nutzlos, es sei denn irgendein Programierer von Renderern,
Routern o.ä. fügt true in die Einleseroutine ein.
Was ja nicht zuviel verlangt ist, wenn man bedenkt was alternative
Daten kosten - der Aufwand für "yes or true or 1" ist gegenüber
Tausender € trivial.
Post by Dimitri Junker
Stellt Euch vor, die OSM-Programierer würden mit so einer Logik
programieren, dann würde kein einziges Programm laufen.
Da können die Mapper
doch etwas solidarisch mit ihnen sein und ihnen das Leben leichter machen.
Die Mapper haben das Interesse, das ihre Daten benutzt werden, die
Programmierer wollen das ihre Programme funktionieren...
Da können die Programmierer ruhig etwas solidarisch sein und mit der
Vielfalt von 3(!) Varianten umgehen lernen.

Stefan
Garry
2008-08-09 08:18:42 UTC
Permalink
Post by Dimitri Junker
So nach dem Motto, ich hab was eigenes kreiert, ich schreibe oneway=true
statt yes? Warum dann nicht auch noch ja, oui, natürlich und "wag es nicht
da rein zu fahren"
Die OSM-Datenbank ist doch keine Prosa, wir wollen damit keinen
Literaturnobelpreis gewinnen. Es ist eine primär maschinenlesbare Datenbank,
und da muß man sich schon an gewisse Formate halten damit es klappt. Es ist
kein evolutionärer Prozess einfach ein Synonym zu benutzen. Herausfinden
Das mit den Synonymen wird in den Quelltexten *) wohl der meisten
Programmiersprachen auch
so gemacht damit sie besser lesbar werden. Ein "oneway=yes" ist nun mal
eindeutiger beim lesen zu interpretieren
als ein oneway=1 wohinter man z.B. auch eine Richtungsangabe vermuten
könnte.

*) Die OSM-Datenbank sehe ich ehr als einen Quellttext als ein
effizientes "binary" - muss also so oder so erst
für die entsprechende Anwendung geeignet konvertierter werden.

Garry
Florian Lohoff
2008-08-09 08:24:28 UTC
Permalink
Post by Garry
*) Die OSM-Datenbank sehe ich ehr als einen Quellttext als ein
effizientes "binary" - muss also so oder so erst
für die entsprechende Anwendung geeignet konvertierter werden.
Das problem ist das es keinen compiler gibt der den source in ein binary
ueberfuehren kann da jeder den syntax und semantik der sprache selber
interpretiert und definiert.

osmlint bitte mal

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Garry
2008-08-09 10:30:50 UTC
Permalink
Post by Florian Lohoff
Post by Garry
*) Die OSM-Datenbank sehe ich ehr als einen Quellttext als ein
effizientes "binary" - muss also so oder so erst
für die entsprechende Anwendung geeignet konvertierter werden.
Das problem ist das es keinen compiler gibt der den source in ein binary
ueberfuehren kann da jeder den syntax und semantik der sprache selber
interpretiert und definiert.
Das könnte man ja mit einer "Rechtschreibkorrektur" beheben wie es auch
die Compiler anmeckern.
Man kann sich ja durchaus überlegen sowas im Hintergrund von josm
laufen zu lassen wo dann noch
mal nachhakt wenn ein unüblicher Tag verwendet wird - mit Erkennung wenn
wirklich was neues eingetragen
werden soll damit es nicht nervt...

Garry
Dimitri Junker
2008-08-09 11:04:06 UTC
Permalink
Hallo
Post by Garry
Das könnte man ja mit einer "Rechtschreibkorrektur" beheben wie es auch
die Compiler anmeckern.
Wobei die aktuelle Liste nicht im Editor drin sein sollte, sondern für alle
Editoren downloadbar.

Dimitri
Christian Malolepszy
2008-08-08 10:50:54 UTC
Permalink
Hallo,
Post by Frederik Ramm
Niemand hatte je den Anspruch, ein Format zu schaffen. Die
Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne
dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess
zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt
die Dynamik nehmen, die es zum Leben braucht.
Mir ist schon klar, dass es fuer die Nutzer der Daten etwas
komplizierter ist, aber die vernuenftige Loesung waere, sich einen
normierenden Zwischenlayer auszudenken, der die Daten in das wandelt,
was man gerne haette, und NICHT, die Mapper normieren zu wollen.
zwingen etwas "normiert" zu machen wäre ein falscher ansatz.

zwischenschicht ist der richtige ansatz, nur sollte man meiner
meinung nach die zwischenschicht, nicht beim herauslesen der
daten ansetzen, sondern für bekannte sachen beim hineinscheiben
in die datenbank oder in periodischen jobs, denn:
- beim lesen der daten (zum beispiel: das api ersetzt die werte)
würde es bedeuten, daß es immer wieder gemacht werden muß
was performance kostet.
- wenn jede anwendung eine zwischenschicht implementiert und
für die interpretation der werte zuständig ist, bedeutet das
eine fehleranfälligkeit und pflegeaufwand.

beispiel:
für boolean werte (z.B. oneway) kann folgendes in der db stehen:
oneway=true
oneway=TRUE
oneway=trUE
oneway=yes
oneway=YES
oneway=1
usw.

jede anwendung muss nun um dieses eine feld zu unterstützen ein
regelwerk und normierung der werte durchführen.
dies bedeutet aufwand und fehleranfälligkeit für jede anwendung.
und wenn dann einer hinkommt und
oneway=ja
oder
oneway=si
hinschreibt muß jede anwendung angepasst werden.


beim hineinschreiben passiert es nur ein
einziges mal und alle die da drauf zugreifen können sich da
drauf verlassen, daß die daten "sauber" sind
und eben bei boolen werten wie oneway da z.B. immer true
zurückkommt.

gruss
christian
Stefan Neufeind
2008-08-08 11:11:09 UTC
Permalink
Post by Tobias Wendorff
Hallo,
Post by Frederik Ramm
Niemand hatte je den Anspruch, ein Format zu schaffen. Die
Herausforderung bei OSM ist, aus den Daten was gutes zu machen, ohne
dass es feste Regeln gibt, weil feste Regeln den Evolutionsprozess
zerstoeren, den Mapper zum tumben Datentypisten machen und dem Projekt
die Dynamik nehmen, die es zum Leben braucht.
Mir ist schon klar, dass es fuer die Nutzer der Daten etwas
komplizierter ist, aber die vernuenftige Loesung waere, sich einen
normierenden Zwischenlayer auszudenken, der die Daten in das wandelt,
was man gerne haette, und NICHT, die Mapper normieren zu wollen.
zwingen etwas "normiert" zu machen wäre ein falscher ansatz.
zwischenschicht ist der richtige ansatz, nur sollte man meiner
meinung nach die zwischenschicht, nicht beim herauslesen der
daten ansetzen, sondern für bekannte sachen beim hineinscheiben
- beim lesen der daten (zum beispiel: das api ersetzt die werte)
würde es bedeuten, daß es immer wieder gemacht werden muß
was performance kostet.
- wenn jede anwendung eine zwischenschicht implementiert und
für die interpretation der werte zuständig ist, bedeutet das
eine fehleranfälligkeit und pflegeaufwand.
oneway=true
oneway=TRUE
oneway=trUE
oneway=yes
oneway=YES
oneway=1
usw.
jede anwendung muss nun um dieses eine feld zu unterstützen ein
regelwerk und normierung der werte durchführen.
dies bedeutet aufwand und fehleranfälligkeit für jede anwendung.
und wenn dann einer hinkommt und
oneway=ja
oder
oneway=si
hinschreibt muß jede anwendung angepasst werden.
beim hineinschreiben passiert es nur ein
einziges mal und alle die da drauf zugreifen können sich da
drauf verlassen, daß die daten "sauber" sind
und eben bei boolen werten wie oneway da z.B. immer true
zurückkommt.
Mir sind übrigens auch ein paar Tags aufgefallen, die vorne/hinten ein
Leerzeichen hatten o.ä. Das wirkt sich in der Praxis dahingehend aus,
daß ein "name " (vielleicht copy-n-paste-error?) nicht gerendert wird
und "name" tadellos funktioniert. Auch hier könnte vielleicht ein
"trimmen" (Leerzeichen, Zeilenumbrüche - unter PHP quasi die Funktion
trim()) für keys und ggf. auch values durchaus gute Dienste leisten ohne
Daten zu "verfälschen". Das macht im übrigen auch der JOSM-Validator,
wenn man ihm für jene Fehler nach dem validieren sagt "fix".

Stefan
Florian Lohoff
2008-08-07 19:10:02 UTC
Permalink
Post by Bernd Wurst
Vermutlich nicht. Jeder, der die Daten irgendwo weiter verarbeitet sollte für
solche Fälle einfach den Konverter so schreiben, das diese Unterschiede alle
zu einem für ihn passenden Wert konvertiert werden.
Wenn du jetzt alles änderst, musst du das in 2 Monaten wieder tun weil jemand
es so einträgt wie er es gewohnt ist. Lieber mehrere Daten für dasselbe
erlauben und beim Exportieren bzw. Konvertieren dann vereinheitlichen.
Ich glaube schon das es sinnvoll waere eher die editoren anzupassen das
jeweilig richtige in die Datenbank zu schreiben. Es wird tendentiell
immer mehr nutzer der daten als editoren geben. Und jeder muss dann den
ganzen rattenschwanz an altlasten implementieren. Alternativ auch die
API so anpassen das sie strikt filtert.

Ich habe keinen stress das jeder tags nutzt wie er will aber syntaktisch
sollte das so strickt wie moeglich machen damit nicht jedes blode script
was irgendwas mit den OSM daten macht angepasst werden muss wenn wieder
jemand bullshit da reinschreibt.

Ich bin gespannt was alles auf die fresse geht wenn jemand
onway=`hostname` oder oneway='<\>' da reinschreibt oder irgendwelche
SQL injection geschichten.

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Bernd Wurst
2008-08-07 19:46:45 UTC
Permalink
Hallo.
Post by Florian Lohoff
Ich habe keinen stress das jeder tags nutzt wie er will aber syntaktisch
sollte das so strickt wie moeglich machen damit nicht jedes blode script
was irgendwas mit den OSM daten macht angepasst werden muss wenn wieder
jemand bullshit da reinschreibt.
Es gibt 3 Varianten fÃŒr "boolean"-Typen, die laut Map-Features "richtig" sind
und die drei Varianten muss das Script eben verstehen.
Ist doch kein Problem.

Es gibt in beinahe jeder Programmiersprache mehrere Dinge fÃŒr das selbe
Ergebnis. In PHP kannst du auch "1", "true" oder "TRUE" schreiben. Kein
Editor wird das "vereinheitlichen" oder "korrigieren" wollen.
Post by Florian Lohoff
Ich bin gespannt was alles auf die fresse geht wenn jemand
onway=`hostname` oder oneway='<\>' da reinschreibt oder irgendwelche
SQL injection geschichten.
Au ja, das klingt sehr geil! ;-)

Einen kleinen Beitrag dazu leisten, dass die Leute die zu doof sind ihre
Strings zu escapen *krÀftig* auf die Nase fallen. Ich muss gleich mal ein
paar solche Tags irgendwo verstecken gehen. ;-))

Gruß, Bernd
--
Skeptiker sind jene Menschen, die einfach nicht an die
friedliche Nutzung der Atombombe glauben wollen.
- Werner Mitsch (dt. Aphoristiker)
Dirk Stöcker
2008-08-08 06:38:41 UTC
Permalink
Post by Florian Lohoff
Ich habe keinen stress das jeder tags nutzt wie er will aber syntaktisch
sollte das so strickt wie moeglich machen damit nicht jedes blode script
was irgendwas mit den OSM daten macht angepasst werden muss wenn wieder
jemand bullshit da reinschreibt.
Ich bin gespannt was alles auf die fresse geht wenn jemand
onway=`hostname` oder oneway='<\>' da reinschreibt oder irgendwelche
SQL injection geschichten.
Wieso. Alles was der Render, Nutzer, Konverter nicht kennt wird ignoriert.
Ist doch einfach. Und das tagwatch-Interface kann man nutzen, um
offensichtliche Fehler zu korrigieren (falls Du es nicht bemerkt hast,
wenn man die Einträge anklickt, bekommt man eine OSM-Datei geliefert,
welche man z.B. in JOSM korrigieren kann).

z.B. Für Routingkarten wird jeder Gerätehersteller irgendwann ein
OSM-->eigenes Format Konverter haben, der Darstellungen vereinheitlicht,
bekannte Fehler korrigiert und das Datenformat für die Zielanwendung
optimiert. Idealerweise schickt er die beim Fehlerkorrigieren angefallenen
Änderungen dann wieder in die Datenbank.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Florian Lohoff
2008-08-08 08:35:29 UTC
Permalink
Post by Dirk Stöcker
Wieso. Alles was der Render, Nutzer, Konverter nicht kennt wird ignoriert.
Ist doch einfach. Und das tagwatch-Interface kann man nutzen, um
offensichtliche Fehler zu korrigieren (falls Du es nicht bemerkt hast,
wenn man die Einträge anklickt, bekommt man eine OSM-Datei geliefert,
welche man z.B. in JOSM korrigieren kann).
Der punkt ist das man z.b. beliebig zeugs da reinpacken koennte um das
XML zu zerstoeren was als export da rauskommt. Damit ist das ganze file
"unbrauchbar" ...

Im XML file:

<tag k="created_by" v="JOSM"/>

Jetzt setze ich ein tag

created_by="/>

Damit wuerde da stehen

<tag k="created_by" v=""/>"/>

Koennte mir dem parsen von XML eng werden.
Alternativ koennen da auch tags eingeschmuggelt werden:

created_by=JOSM"/><tag k="hidden_tag" v="test

damit kaeme da raus:

<tag k="created_by" v="JOSM"/><tag k="hidden_tag" v="test"/>

Und mit genuegend krimineller energie laesst sich das bestimmt
fortpflanzen d.h. statt einfacher OSM XML Tags einfach ein paar SVG
elemente einbauen. Dank XSLT und nen bischen handcraft landet das in der
karte. D.h. jemand schreibt texte auf die Karte die in den rohdaten so
nicht drin sind.
Post by Dirk Stöcker
z.B. Für Routingkarten wird jeder Gerätehersteller irgendwann ein
OSM-->eigenes Format Konverter haben, der Darstellungen vereinheitlicht,
bekannte Fehler korrigiert und das Datenformat für die Zielanwendung
optimiert. Idealerweise schickt er die beim Fehlerkorrigieren angefallenen
Änderungen dann wieder in die Datenbank.
Es geht nicht um semantische sondern um syntaktische fehler.

Wenn jeder seinen eigenen konverter baut ist eben der inhalt
interpretationssache und ich denke das das nicht in unserem sinne
ist. Ich bin ja dafuer das jeder erfasst und tagged was er moechte,
aber am liebsten so das es mit gaengigen nutzungsformen der karte
nicht kollidiert. Wie man das im einzelnen macht ist mir auch nicht
so klar, aber wenn man sich RFC822/RFC2822 ansieht gibts halt pflicht
und kuer. D.h. ich habe Tags/Elemente die sind definiert in ihrem
syntaktischen aufbau und es gibt eben freie felder die applikations oder
interpretationsabhaengig sind. Diese fangen im Mailheader typischerweise
mit X-<tag>: value an.

Ob das besser ist als die herrschende Anarchie die uns ja schon weit
gebracht hat weiss ich nicht. Nur so als denkanstoss.

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Florian Lohoff
2008-08-08 10:28:49 UTC
Permalink
Post by Florian Lohoff
Der punkt ist das man z.b. beliebig zeugs da reinpacken koennte um das
XML zu zerstoeren was als export da rauskommt. Damit ist das ganze file
"unbrauchbar" ...
<tag k="created_by" v="JOSM"/>
Jetzt setze ich ein tag
created_by="/>
Damit wuerde da stehen
Bei einem korrekten Umgang mit den Benutzereingaben, käme eher sowas im
<tag k='created_by"/>' v=""/>
oder
<tag k="created_by&quot;/>" v=""/>
Ich bin mir jetzt nicht sicher, ob in reinem XML auch &quot; verwendet wird.
Man braucht die Benutzereingaben dafür aber nicht irgendwie einzuschränken.
Du hoffst das jeder der was mit den daten macht das escapen von daten
beherrscht. Genau das ist ja mein punkt. Ich wuerde gleich strikte
regeln fuer daten in der datenbank erlassen so das sich nicht jeder um
die boshaftigkeit der jeweiligen "Datentypisten" kuemmern muss.

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Bernd Wurst
2008-08-08 11:45:09 UTC
Permalink
Hallo.
Post by Florian Lohoff
Du hoffst das jeder der was mit den daten macht das escapen von daten
beherrscht.
Davon muss man ausgehen, ja.

Man macht ja auch keine Löcher hinten in die Hosen nur weil evtl. manche Leute
zu blöd sind die vor dem Kacken auszuziehen.

Gruß, Bernd
--
<Alanna> Saying that Java is nice because it works on all OS's is like
saying that anal sex is nice because it works on all genders.
Florian Lohoff
2008-08-08 13:27:51 UTC
Permalink
Post by Bernd Wurst
Hallo.
Post by Florian Lohoff
Du hoffst das jeder der was mit den daten macht das escapen von daten
beherrscht.
Davon muss man ausgehen, ja.
Man macht ja auch keine Löcher hinten in die Hosen nur weil evtl. manche Leute
zu blöd sind die vor dem Kacken auszuziehen.
Ne - Aber Gurtwarner weil die leute vergessen sie anzulegen.

Nicht alles was hinkt ist ein vergleich ...

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Claudius Henrichs
2008-08-07 17:01:08 UTC
Permalink
Post by Tobias Wendorff
Hallo Leute,
ich schreibe derzeit eine Lösung für das Rendering von Straßennamen
(ja ... in PHP, steinigt mich!).
Mir ist aufgefallen, dass es mittlerweile mind. drei Schreibweisen
für "oneway" gibt: true, 1, yes
Wird es generell irgendwann mal eine Datenbankbereinigung geben,
damit es einen einheitlichen Standard gibt?
Oder kann man JOSM zukünftig beibringen, beim Speichern immer nur
TRUE oder 1 zu exportieren? Schließlich wurde ein Standard
festgelegt.
Grüße
Tobias
Ein bisschen Pluralismus schadet doch nicht. Die überwiegende Mehrheit
nutzt doch "yes" und für den Rest bauste halte noch ein par && in die
if-Abfrage. Oder du lässt es weg und übst so sanften Druck aus: Wenn die
Einbahnstraße in deinem Rendering nicht sichtbar ist, weil jemand
"oneway=ja" getaggt hast wird er es spätestens dann ändern.

Von "Reinigungen" und Trimmung auf Standard halte ich wenig, weil es mit
Kanonen auf Spatzen geschossen ist. Der Druck durch die Renderer reicht
meines Erachtens.
Tobias Wendorff
2008-08-07 17:07:38 UTC
Permalink
Post by Claudius Henrichs
Ein bisschen Pluralismus schadet doch nicht. Die überwiegende Mehrheit
nutzt doch "yes" und für den Rest bauste halte noch ein par && in die
if-Abfrage. Oder du lässt es weg und übst so sanften Druck aus: Wenn die
Einbahnstraße in deinem Rendering nicht sichtbar ist, weil jemand
"oneway=ja" getaggt hast wird er es spätestens dann ändern.
Der Pluralismus endet hier im Chaos. Ich muss jetzt vergleichen, ob
es: ja, yes, yo, 1, true, yepp und dann noch die Gegenteile vergleichen.
Zusätzlich noch ein Abfrage, ob das Feld vielleicht leer ist.
Post by Claudius Henrichs
Von "Reinigungen" und Trimmung auf Standard halte ich wenig, weil es mit
Kanonen auf Spatzen geschossen ist. Der Druck durch die Renderer reicht
meines Erachtens.
Wieso? Einmal bereinigen und dann die Editoren auf einen Standard
verdonnern. HTML funktioniert nicht anders.

Nicht nur die Renderer verarbeiten die Daten ... alles muss per Hand
korrigiert oder angepasst werden. Es nervt einfach.
Frederik Ramm
2008-08-07 17:13:37 UTC
Permalink
Hallo,
Post by Tobias Wendorff
Post by Claudius Henrichs
Von "Reinigungen" und Trimmung auf Standard halte ich wenig, weil es mit
Kanonen auf Spatzen geschossen ist. Der Druck durch die Renderer reicht
meines Erachtens.
Wieso? Einmal bereinigen und dann die Editoren auf einen Standard
verdonnern. HTML funktioniert nicht anders.
Niemand kann bei OSM irgendwen zu irgendwas verdonnern. Und HTML ist
eine ganz andere Baustelle.

Damit sowas wirklich funktioniert, muesste in der API hinterlegt sein,
welche Tags welche Werte haben duerfen, und genau so etwas wollen wir
explizit *nicht*, weil es dazu fuehren wuerde, dass jemand, der mit
gutem Grund vom Etablierten abweichen will, dies erst dem Datenbank-
Steuerungs-Kommittee erklaeren muesste.
Post by Tobias Wendorff
Nicht nur die Renderer verarbeiten die Daten ... alles muss per Hand
korrigiert oder angepasst werden. Es nervt einfach.
Besser, die Nutzer sind genervt, als die Mapper. Die Nutzer kommen schon
von ganz allein zu uns, und wenn die ab und zu mal ueber eine kleine
Huerde springen muessen, ist das wurscht. Schnueren wir aber den Mappern
ein zu enges Korsett, dann machen die lieber was anderes, und das waere
doof.

Auch in anderen Bereichen waehlt OSM ziemlich konsequent immer die
Loesung, die fuer den Mapper einfacher ist und nicht die, die fuer den
Auswerter (Router, Renderer, ...) einfacher ist.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00'09" E008°23'33"
Tobias Wendorff
2008-08-07 17:22:30 UTC
Permalink
Hallo,
Post by Frederik Ramm
Niemand kann bei OSM irgendwen zu irgendwas verdonnern. Und HTML ist
eine ganz andere Baustelle.
Wieso verwendet man dann nicht KML oder GPX, sondern führt OSM ein?
KML ist der neue Standard für GIS-Daten.
Post by Frederik Ramm
Damit sowas wirklich funktioniert, muesste in der API hinterlegt sein,
welche Tags welche Werte haben duerfen, und genau so etwas wollen wir
explizit *nicht*, weil es dazu fuehren wuerde, dass jemand, der mit
gutem Grund vom Etablierten abweichen will, dies erst dem Datenbank-
Steuerungs-Kommittee erklaeren muesste.
Also die würden sich sicher freuen, wenn sie "(int)1" statt "jawoll"
bekommen würden.
Post by Frederik Ramm
Post by Tobias Wendorff
Nicht nur die Renderer verarbeiten die Daten ... alles muss per Hand
korrigiert oder angepasst werden. Es nervt einfach.
Besser, die Nutzer sind genervt, als die Mapper. Die Nutzer kommen schon
von ganz allein zu uns, und wenn die ab und zu mal ueber eine kleine
Huerde springen muessen, ist das wurscht. Schnueren wir aber den Mappern
ein zu enges Korsett, dann machen die lieber was anderes, und das waere
doof.
Die Mapper würden es ja gar nicht mitbekommen, weil der Editor es
intern erstellt.
Post by Frederik Ramm
Auch in anderen Bereichen waehlt OSM ziemlich konsequent immer die
Loesung, die fuer den Mapper einfacher ist und nicht die, die fuer den
Auswerter (Router, Renderer, ...) einfacher ist.
Also Mappen wir nur zu Mappen oder wie? :-)

Grüße
Tobias
Sven Geggus
2008-08-07 17:51:02 UTC
Permalink
Post by Tobias Wendorff
Wieso verwendet man dann nicht KML oder GPX, sondern führt OSM ein?
KML ist der neue Standard für GIS-Daten.
Make ist simple - stupid!

Ach ja und wo wir grade dabei sind osm2kml dürfte recht einfach in
xslt zu machen sein.

Sven
--
The main thing to note is that when you choose open source you don't
get a Windows operating system.
(from http://www.dell.com/ubuntu)
/me is ***@ircnet, http://sven.gegg.us/ on the Web
Tobias Wendorff
2008-08-07 17:54:39 UTC
Permalink
Post by Sven Geggus
Ach ja und wo wir grade dabei sind osm2kml dürfte recht einfach in
xslt zu machen sein.
XSLT gefällt mir nicht, da die Rechenoperationen echt gruselig sind.
Bernd Wurst
2008-08-07 17:54:58 UTC
Permalink
Hallo.
Post by Tobias Wendorff
Post by Frederik Ramm
Niemand kann bei OSM irgendwen zu irgendwas verdonnern. Und HTML ist
eine ganz andere Baustelle.
Wieso verwendet man dann nicht KML oder GPX, sondern führt OSM ein?
KML ist der neue Standard für GIS-Daten.
Das ist Käse.
KML ist ein Format eines Programms das das erste unter vielen Normalnutzern
verbreitete Programm seiner Art ist.


Aber deine Aussage ist schon auf anderer Ebene "Thema verfehlt":
OSM ist ein XML-Datenformat, das ganz wenige Sachen festlegt. Es legt fest,
dass es Nodes, Ways und Relations gibt, dass diese jeweils beliebig viele
Key-Value-Paar haben können und noch ein paar andere Kleinigkeiten.

Was in den Freitext-Feldern "Key" und "Value" dann letztlich drin stehen soll,
darüber sagt das OSM-Datenformat überhaupt gar nichts aus.
Das entscheidet ganz alleine derjnige, der da Daten beiträgt.
Post by Tobias Wendorff
Also die würden sich sicher freuen, wenn sie "(int)1" statt "jawoll"
bekommen würden.
Du steigerst dich da in was rein. Es gibt kein "yo" und auch kein "jawoll" in
den Daten sondern (soweit ich auf die Schnelle sehe) "yes", "true", "1"
und "-1" plus ein paar Groß-Kleinschreibungs-Variationen. Und genau diese
Varianten sind auf der Map-Features-Seite alle aufgelistet und daher nicht
durch Tagwatch herauszufinden sondern vorab bekannt.


Kein ernst gemeintes Programm wird direkt auf den OSM-XML-Daten arbeiten
wollen das geht schon aufgrund der Datenmenge nicht.

Jeder "Verbraucher" soll sich seine Datenmenge aus dem Bestand herausziehen.
Wenn du Straßen willst, lass die Eisenbahnen und Flüsse weg. Wenn du nur
Deutschland willst, lass alles andere Weg. Wenn du nur Staßennamen
willst, ...

Zudem ist XML das denkbar ungünstigste Format für eine direkte Verarbeitung
großer Datenmengen. Flexibel verarbeitbar für unterschiedlichste Anwendungen,
aber nicht für direkte Operationen auf dem Datenbestand geeignet.

Du musst die Daten also in eine Datenbank oder ein passendes Spezial-Format
konvertieren, damit du was damit anfangen kannst.

Diese Konversion muss dann sowieso
<tag k="oneway" v="yes" />
in etwas anderes übersetzen. Und ob man dann nur diese Variante oder gleich
noch die andern Tag-Möglichkeiten in eben dieses Ziel-Format konvertiert, ist
vom Aufwand her echt minimal.


Natürlich wäre es dem Daten-Konsument lieber, wir hätten ein festes Schema, am
besten mit genau so vielen highway-Klassen wie er selbst hat. Aber was haben
wir davon? Nur Einschränkungen.
Wir sind ein freies Projekt und unser oberstes Ziel ist die Erfassung der
Daten. Es gibt momentan schon Verbraucher, die schaffen es, mit den Daten
etwas anzufangen. Es kann also nicht so schwer sein.

Um es mal weiter zu spinnen: Es ist nicht unser Problem, dass alle
Navi-Hersteller unterschiedliche proprietäre Datenformate nutzen. Gäbe es nur
eins das offen dokumentiert ist, glaube mir es gäbe ruck-zuck einen freien
und funktionierenden konverter von OSM-Daten in dieses Format.
Post by Tobias Wendorff
Die Mapper würden es ja gar nicht mitbekommen, weil der Editor es
intern erstellt.
Hab ich was verpasst? Gibt es denn "den Editor" (»to rule them all«)?

Nein, es gibt JOSM, der sich redlich Mühe gibt, mit Vorlagen dem Benutzer ein
Werkzeug zu geben, dass er bestimmte Dinge vielleicht gleich macht wie es
andere tun.
Es gibt den Validator, der versucht, algorithmisch findbare Fehler zu
erkennen.
Aber trotzdem gibt es die Tags als Freitext. Ich trage da ein was ich für
geeignet halte. Natürlich orientiere ich mich am Wiki und den dort
zusammengefassten Konventionen. Aber ich will nicht, dass mich ein Werkzeug
zu irgendwas zwingt.

Dein HTML-Vergleich: Mein Kate wird sich strikt hüten, mir vorzuschreiben wie
ich mein HTML zu schreiben habe. Nur weil auch ein paar WYSIWYG-Editoren
mittlerweile gelernt haben, dass man durch Einhaltung einer Konvention
vielleicht einfach besser ankommt, hat das keine Auswirkung auf HTML.
Zudem, wie Frederik schon schreibt: der Vergleich hinkt gewaltig, weil bei
HTML eben alles festgelegt ist was es an Auszeichnungen gibt. Wenn jemand
<h7> schreibt, dann ist das schlicht falsch. Bei OSM ist das alles nicht
festgelegt, es ist nur festgelegt, wie Key-Value-Paare gespeichert werden,
nicht was drin steht.
Post by Tobias Wendorff
Post by Frederik Ramm
Auch in anderen Bereichen waehlt OSM ziemlich konsequent immer die
Loesung, die fuer den Mapper einfacher ist und nicht die, die fuer den
Auswerter (Router, Renderer, ...) einfacher ist.
Also Mappen wir nur zu Mappen oder wie? :-)
Nein, wir mappen für den Datenbestand. Es gibt schon einige Verbraucher die
Daten von OSM nutzen und die schaffen das. Bisher sogar ganz gut ohne
Zwangsreglementierungen der Mapper.

Jemand, der hier ankommt, das Prinzip weder verstanden hat noch unterstützt
und einfach nur schnell und billig Daten haben will, der kann sich ganz
schnell die Finger verbrennen. Wir *liefern* keine Daten, wir *sammeln* die
Daten. Man kann sie sich holen, aber wir liefern nicht fertig konfektioniert
in der richtigen Farbe nach Hause.

Gruß, Bernd
--
Gegen Liebe auf den ersten Blick hilft nur der zweite
Tobias Wendorff
2008-08-07 18:04:00 UTC
Permalink
Post by Bernd Wurst
Das ist Käse.
KML ist ein Format eines Programms das das erste unter vielen Normalnutzern
verbreitete Programm seiner Art ist.
Seit 14. April 2008 ist KML ein Standard des Open Geospatial Consortium.
Post by Bernd Wurst
Du steigerst dich da in was rein. Es gibt kein "yo" und auch kein "jawoll" in
den Daten sondern (soweit ich auf die Schnelle sehe) "yes", "true", "1"
und "-1" plus ein paar Groß-Kleinschreibungs-Variationen. Und genau diese
Varianten sind auf der Map-Features-Seite alle aufgelistet und daher nicht
durch Tagwatch herauszufinden sondern vorab bekannt.
Kann man durch Tagwatch alle Typen für einen Tag erhalten?
Wenn ja: Bitte erklären.

[Rest lese ich im Zug]
Bernd Wurst
2008-08-07 18:17:21 UTC
Permalink
Hallo.
Post by Tobias Wendorff
Seit 14. April 2008 ist KML ein Standard des Open Geospatial Consortium.
Okay, das hab ich wohl mangels Interesse nicht mitbekommen.
Aber sei's drum. Wenn es alles zufriedenstellend abbilden könnte was ein
relevanter Teil der OSM-community braucht, dann würde es einen Konverter
geben.

Entweder es gibt diesen Konverter bereits oder es interessiert niemanden oder
KML kann nicht alles abbilden was man von OSM an Daten will.
Dass es einfach noch keiner *geschafft* hat, einen solchen Konverter zu
schreiben, glaube ich nicht.
Post by Tobias Wendorff
Kann man durch Tagwatch alle Typen für einen Tag erhalten?
Wenn ja: Bitte erklären.
Beispiel:

http://tagwatch.stoecker.eu/Germany/En/tags.html

Oh Mann, ich seh grade, da gibt es einige Unfälle bei diesem Tag. ;-)

Gruß, Bernd
--
"Ich hab mich immer gefragt, ob es einen Gott gibt.
Jetzt weiß ich es. Es gibt einen. Und das bin ich!"
- Homer S. in "Homer the Great"/"Homer der Auserwählte" (2F09)
Tobias Wendorff
2008-08-07 18:24:03 UTC
Permalink
Post by Bernd Wurst
Entweder es gibt diesen Konverter bereits oder es interessiert niemanden oder
KML kann nicht alles abbilden was man von OSM an Daten will.
Dass es einfach noch keiner *geschafft* hat, einen solchen Konverter zu
schreiben, glaube ich nicht.
Es gibt genug Konverter, habe auch nie das Gegenteil behauptet. Mich
nervt es nur, hunderte Formate zu haben, die im Endeffekt alle das
gleiche können.
Post by Bernd Wurst
Post by Tobias Wendorff
Kann man durch Tagwatch alle Typen für einen Tag erhalten?
Wenn ja: Bitte erklären.
http://tagwatch.stoecker.eu/Germany/En/tags.html
"morning to south, evening to North" finde ich sehr cool.
Torsten Leistikow
2008-08-07 18:40:44 UTC
Permalink
Post by Frederik Ramm
Besser, die Nutzer sind genervt, als die Mapper. Die Nutzer kommen
schon von ganz allein zu uns, und wenn die ab und zu mal ueber eine
kleine Huerde springen muessen, ist das wurscht. Schnueren wir aber
den Mappern ein zu enges Korsett, dann machen die lieber was anderes,
und das waere doof.
Wir schrecken aber auch genug Leute ab, weil OSM heute doch ziemlich
unuebersichtlich ist. An vielen Stellen laesst sich das sicherlich nicht
vermeiden, weil einfach noch nicht geklaert ist, wie das am Besten zu
handhaben ist. Aber wenn man sich auf einen einheitlichen Weg einigen
kann, dann sollte man den auch konsequent verfolgen und nicht die
unterschiedlichen Varianten pflegen, weil das nun mal so eine tolle,
lebende OSM-Kultur ist.

Da es bei uns ja mit klaren Beschreibungen nicht so weit her ist, wird
ein Grossteil der OSM-Daten sicherlich so eingetragen, dass der Mapper
sich umschaut, wie entsprechende Sachen anderswo abgebildet wurden. An
dieser Stelle wuerde es dem Mapper dann auch leichter fallen, wenn man
den Datenbestand soweit sinnvoll zwangsbereinigt.

Gruss
Torsten

PS: Es waere mal interessant zu wissen, wieviele Leute bei OSM um des
Mappens-Willen mitmachen, und wieviele staerker am Ergebniss bzw. Nutzen
interessiert sind. Hier in den Diskussionen prallen doch immer wieder
beide Sichtweisen aufeinander.
Bernd Wurst
2008-08-07 19:49:29 UTC
Permalink
Hallo.
Post by Torsten Leistikow
Wir schrecken aber auch genug Leute ab, weil OSM heute doch ziemlich
unuebersichtlich ist.
Beweise? Ich denke die Leute, die sich davon abschrecken lassen, erwarten
vollständige Daten auf dem Silbertablett serviert.
Post by Torsten Leistikow
PS: Es waere mal interessant zu wissen, wieviele Leute bei OSM um des
Mappens-Willen mitmachen, und wieviele staerker am Ergebniss bzw. Nutzen
interessiert sind. Hier in den Diskussionen prallen doch immer wieder
beide Sichtweisen aufeinander.
Ich denke der größte Teil derer die hier diese "Ergebnis"-Sichtweise vertreten
sind Leute, die versuchen, sich in die Lage derer zu versetzen die eventuell
etwas mit unseren Daten machen wollen.

Die, die wirklich was mit den Daten machen wollen, tun das jetzt schon.

Gruß, Bernd
--
Nehmen wir einmal an, es gäbe keine hypothetischen Situationen...
Michael Buege
2008-08-07 20:44:06 UTC
Permalink
Post by Torsten Leistikow
Post by Frederik Ramm
Besser, die Nutzer sind genervt, als die Mapper. Die Nutzer kommen
schon von ganz allein zu uns, und wenn die ab und zu mal ueber eine
kleine Huerde springen muessen, ist das wurscht. Schnueren wir aber
den Mappern ein zu enges Korsett, dann machen die lieber was
anderes, und das waere doof.
Wir schrecken aber auch genug Leute ab, weil OSM heute doch ziemlich
unuebersichtlich ist.
Woher hast Du diese Informationen? Kennst Du Leute, die sich haben
abschreckenlassen und wie haben sie das konkret begruendet? Wie viele
Leute waren das bei Dir bis jetzt?
Post by Torsten Leistikow
An vielen Stellen laesst sich das sicherlich
nicht vermeiden, weil einfach noch nicht geklaert ist, wie das am
Besten zu handhaben ist.
Was ist "das Beste"? Wer bestimmt, was "das Beste" ist und was sind
die Massstaebe? Wie kann man das festlegen, welche Prozedere sind
notwendig und wer bestimmt wiederum, welches der richtige Weg ist, um
solche Festlegungen zu treffen? Und welches sind die
Qualifikationsbedingungen fuer Leute, die das machen?
Post by Torsten Leistikow
Aber wenn man sich auf einen einheitlichen
Weg einigen kann, dann sollte man den auch konsequent verfolgen und
nicht die unterschiedlichen Varianten pflegen, weil das nun mal so
eine tolle, lebende OSM-Kultur ist.
Wie hast Du dir das mit der Einigung denn vorgestellt? Und, nur fuer
den Fall, irgend jemand einigt sich auf irgend etwas, was, wenn
jemand mit diesen Regeln nichts anfangen kann, wenn sie ihn hindern,
seine Ideen zu verwirklichen? Wird er dann ausgeschlossen? Wovon?
Post by Torsten Leistikow
Da es bei uns ja mit klaren Beschreibungen nicht so weit her ist,
wird ein Grossteil der OSM-Daten sicherlich so eingetragen, dass der
Mapper sich umschaut, wie entsprechende Sachen anderswo abgebildet
wurden. An dieser Stelle wuerde es dem Mapper dann auch leichter
fallen, wenn man den Datenbestand soweit sinnvoll zwangsbereinigt.
Zwangbereinigung? Wir reden doch immer noch ueber _Open_ streetmap,
oder?
Post by Torsten Leistikow
PS: Es waere mal interessant zu wissen, wieviele Leute bei OSM um
des Mappens-Willen mitmachen, und wieviele staerker am Ergebniss
bzw. Nutzen interessiert sind.
Was ist mit Mischformen?
Post by Torsten Leistikow
Hier in den Diskussionen prallen doch
immer wieder beide Sichtweisen aufeinander.
Findest Du das nicht normal?
--
Michael
Frederik Ramm
2008-08-08 01:11:11 UTC
Permalink
Hallo,
Post by Michael Buege
Was ist "das Beste"? Wer bestimmt, was "das Beste" ist und was sind
die Massstaebe? Wie kann man das festlegen, welche Prozedere sind
notwendig und wer bestimmt wiederum, welches der richtige Weg ist, um
solche Festlegungen zu treffen? Und welches sind die
Qualifikationsbedingungen fuer Leute, die das machen?
Da muss ich mal ein dickes "me too" drunter schreiben. Was Michael da
schreibt, mag fuer viele albern klingen, aber es drueckt genau das aus,
worum es geht: OpenStreetMap geht, wo immer es moeglich ist, der
Gleichschaltung aus dem Weg, weil die Gleichschaltung einen enormen
Abstimmungsaufwand plus Gremien, Methoden, Mechanismen, Kommittees,
Beschwerdeprozesse und so weiter bedeutet.

Wenn z.B. der Hersteller eines Navigeraets unsere Daten auslesen will
und in dem Moment fuer sich die Entscheidung trifft, dass er eine
Information wie "oneway=morgens in Nordrichtung, abends in Suedrichtung"
ignorieren will - schoen fuer ihn, betrifft uns nicht, er entscheidet
fuer seinen Anwendungsbereich, was er machen will, und hat da die volle
Autoritaet.

Wenn der gleiche Typ aber zu uns kommt sagt, er will nicht, dass wir
solche Tag-Werte ueberhaupt erfassen, dann kommen die Fragen: Wer
entscheidet, was wir tun und was nicht, und wie? Dann geht die
Streiterei los - und das ganze voellig unnoetig.

Bei OpenStreetMap wird an der Ausgabeseite gefiltert, nicht an der
Eingabeseite. Das ist ein (noch) recht unuebliches Konzept, aber man
kann m.E. damit gut arbeiten und erfolgreich sein, wenn man sich darauf
einlaesst, denn es hat auch sehr viele Staerken gegenueber einem System,
das an der Eingabeseite filtert.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00'09" E008°23'33"
Florian Lohoff
2008-08-08 08:45:10 UTC
Permalink
Post by Frederik Ramm
Bei OpenStreetMap wird an der Ausgabeseite gefiltert, nicht an der
Eingabeseite. Das ist ein (noch) recht unuebliches Konzept, aber man
kann m.E. damit gut arbeiten und erfolgreich sein, wenn man sich darauf
einlaesst, denn es hat auch sehr viele Staerken gegenueber einem System,
das an der Eingabeseite filtert.
So habe ich es noch nicht gesehen - aber interessante sichtweise die ich
erstmal spannend finde.

Ich hoffe das die entsprechenden feedback prozesse nach vorne finden
denn ich denke diese sind essentiell um einen Datenbestand zu bekommen
der so konsistent ist das das was vorne eingegeben wird auch hinten die
richtige wirkweise erzeugt.

Das beispiel mit dem Oneway wird sicherlich so nicht funktionieren
sondern ignoriert werden daher ist es fragwuerdig ob der mapper/author
der daten nicht vielleicht ein strikteres datenmodell bevorzugt haette
in dem er sicher gehen kann das das erwuenschte ergebniss raus kommt.

Wie ja des haeufigeren zu beobachten wird ja schon fuer die renderer
getagged und erfasst und an den tags rumgeschraubt bis es auf der Karte
"schoen" aussieht. Sicherlich ist das nicht das gewuenschte vorgehen
aber doch halt sehr menschlich. Ich habe arbeit geleistet und die
motivation wird aus dem ergebniss geschoepft. Bei einem renderer (z.b.
osmarender) habe ich ja ein feedback innerhalb von 30 minuten im
optimalfall. Bei einem distributor der die karten durchnudelt ggfs nach
6 monaten wenn der den datenbestand abgleicht und die feedback schleife
funktioniert.

Vielleicht ist des raetsels loesung auf ein validator der zusaetzlich zu
den syntaktischen auch auf semantische fehler achtet und gleich sich
meldet wenn eingaben vermutlich in der ausgabe ignoriert werden.

Vielleicht baut uns das ja auch der Distributor der Daten ;)

Ich denke aber das fuer "gute" daten im sinne von konsistent und
syntaktisch wie semantisch zu parsen und interpretieren essentiell von
der latenz des feedbacks abhaengen.

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Dirk Stöcker
2008-08-08 08:59:34 UTC
Permalink
Post by Florian Lohoff
Vielleicht ist des raetsels loesung auf ein validator der zusaetzlich zu
den syntaktischen auch auf semantische fehler achtet und gleich sich
meldet wenn eingaben vermutlich in der ausgabe ignoriert werden.
Ich baue gerade ein entsprechendes Modell in den JOSM-Validator ein,
welches komplexe Prüf-Regeln zuläßt.

Dauert aber noch ein Weilchen.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Torsten Leistikow
2008-08-08 14:50:07 UTC
Permalink
Post by Michael Buege
Post by Torsten Leistikow
Wir schrecken aber auch genug Leute ab, weil OSM heute doch
ziemlich unuebersichtlich ist.
Woher hast Du diese Informationen? Kennst Du Leute, die sich haben
abschreckenlassen und wie haben sie das konkret begruendet? Wie viele
Leute waren das bei Dir bis jetzt?
100% der Leute, die ich zur Mitarbeit motivieren konnte, haben sich
darueber beschwert, wie durcheinander bei OSM alles ist und das man
nirgendwo eindeutige Antworten oder Vorgehensweisen bekommt. N = 1.
Post by Michael Buege
Was ist "das Beste"? Wer bestimmt, was "das Beste" ist und was sind
die Massstaebe? Wie kann man das festlegen, welche Prozedere sind
notwendig und wer bestimmt wiederum, welches der richtige Weg ist, um
solche Festlegungen zu treffen? Und welches sind die
Qualifikationsbedingungen fuer Leute, die das machen?
Wie waere es mit einer guten alten Abstimmungsprozedur. Es gibt ja auch
schon einen Weg, wie neue Features eigentlich eingefuehrt werden sollten.
Bei irgendwelchen Normierungsgremien gibt es ja genug vorbild, wie so
etwas laufen sollte (und auch das eine oder andere gegenbeispiel).
Post by Michael Buege
Zwangbereinigung? Wir reden doch immer noch ueber _Open_ streetmap,
oder?
Ich habe Open immer im Sinne von "Frei" zur Nutzung verstanden. Voellig
unreglementiert ist eine ander Sache. Bei Open-Source-Software oder
-Hardware erwarte ich ja auch, dass sie sich an die verschiedenen Normen
und Standards haelt.
Post by Michael Buege
Post by Torsten Leistikow
PS: Es waere mal interessant zu wissen, wieviele Leute bei OSM um
des Mappens-Willen mitmachen, und wieviele staerker am Ergebniss
bzw. Nutzen interessiert sind.
Was ist mit Mischformen?
Da ich den Komparativ verwendet habe, ist theoretisch nur eine einzige
Mischform denkbar: Diejenigen, denen beide Sichtweisen voellig gleich
sind :-)
Post by Michael Buege
Post by Torsten Leistikow
Hier in den Diskussionen prallen doch immer wieder beide
Sichtweisen aufeinander.
Findest Du das nicht normal?
Normal schon, aber nicht unbedingt foerderlich.

Bei dem Hinweis auf Open ist mir aber was ganz anderes eingefallen:
Wenn ich, oder jemand anderes eine automatische Bereinigung haben will,
so kann er das ja einfach machen. Die Lizenz gestattet es ja gerade,
dass man die Daten nach seinen Wuenschen veraendern kann.

Es steht natuerlich auch jedem frei, einen Bot anzuschmeissen, der die
Werte nach Belieben (oder auch zufaellig) wieder vertauscht. Ist die
OSM-Welt ohne Regeln nicht etwas Wunderbares?

Gruss
Torsten
Christian Malolepszy
2008-08-08 15:09:20 UTC
Permalink
Post by Torsten Leistikow
Es steht natuerlich auch jedem frei, einen Bot anzuschmeissen, der die
Werte nach Belieben (oder auch zufaellig) wieder vertauscht. Ist die
OSM-Welt ohne Regeln nicht etwas Wunderbares?
:-) meine Meinung
..... und weil jeder so darf wie er will und keiner niemanden
dran hindert, werden ab morgen alle namen rückwärts geschrieben
*lol*
das ist auch der grund wieso mittlerweile bei wikipedia nicht
alles von jedem bearbeitet werden kann

schönen abend noch
christian
Stefan Neufeind
2008-08-08 15:38:52 UTC
Permalink
Post by Christian Malolepszy
Post by Torsten Leistikow
Es steht natuerlich auch jedem frei, einen Bot anzuschmeissen, der die
Werte nach Belieben (oder auch zufaellig) wieder vertauscht. Ist die
OSM-Welt ohne Regeln nicht etwas Wunderbares?
:-) meine Meinung
..... und weil jeder so darf wie er will und keiner niemanden
dran hindert, werden ab morgen alle namen rückwärts geschrieben
*lol*
Aber dann auch brav mit name:lefttoright=... oder name:reverse oder
name:andersherum taggen :-)
Post by Christian Malolepszy
das ist auch der grund wieso mittlerweile bei wikipedia nicht
alles von jedem bearbeitet werden kann
Grüße,
Stefan
Christian Malolepszy
2008-08-08 19:39:14 UTC
Permalink
Post by Stefan Neufeind
Post by Christian Malolepszy
:-) meine Meinung
..... und weil jeder so darf wie er will und keiner niemanden
dran hindert, werden ab morgen alle namen rückwärts geschrieben
*lol*
Aber dann auch brav mit name:lefttoright=... oder name:reverse oder
name:andersherum taggen :-)
nööö, entweder schreibe ich ein - davor, oder aber shit egal und
warte, bis es einer in den renderer implementiert

gruß
christian
Florian Lohoff
2008-08-09 08:20:43 UTC
Permalink
Post by Torsten Leistikow
100% der Leute, die ich zur Mitarbeit motivieren konnte, haben sich
darueber beschwert, wie durcheinander bei OSM alles ist und das man
nirgendwo eindeutige Antworten oder Vorgehensweisen bekommt. N = 1.
Ohne mal von hoerensagen zu reden. Als ich angefangen habe habe ich
erstmal irgendwie angefangen ein paar straßen zu taggen. Ich denke das
ich in den ersten Wochen echt viel Bullshit eingetragen habe denn
einfach mangels richtiger, vollstaendiger oder verstaendlicher doku
ueber die "Best Current Practices" kommt da nunmal mist bei raus.

Wie ich ja hier auch schonmal schrieb sind ja nichtmal cycleway oder
footway eindeutig definiert bzw abgegrenzt. D.h. ich habe immer alles
schoen mit footway gemacht. Nach ein paar Monaten, einem angefixtem
kollegen der viel im Wiki gestoebert hat haben wir dann alles
umgetagged (soweit es noch klar war).

Ich wuerde mir tendentiell auch eher strikte tags und regeln fuer den
gaengigen tags wuenschen d.h. die "Pflicht" ist strikt definiert. Was dann
jeder in der Kuer macht ist mir dann ja latte. Wuerde es vermutlich auch
einfacher machen irgendwann den Datenbestand von einer definition in die
naechste zu ueberfuehren a la cycleway/footway -> path + cycle/foot=yes.

Zum beispiel die ewige diskussion mit richtungsabhaengigen elementen auf
den pfaden. Hier wuerde ich mir wuenschen das alles was
richtungsabhaengig eindeutig ist. D.h. der editor der den pfad umkehrt
brauch die tags nicht zu verstehen. Wenn ich tags mit "left:" oder
"right:" prepende ist das umzukehren beim richtungswechsel. Jetzt noch
entsprechende tags fuer mit oder gegen die richtung und dann das
"oneway=yes" beerdigen. Sonderbedeutung der wegrichtung auf
ein tag ist halt doof.

Wenn da jeder macht was er will wirds halt um so schwieriger da
automatisiert etwas zu bearbeiten/konvertieren/interpretieren.

Und aus meinen mittlerweile 12 Jahren IT erfahrung kann ich sagen das
nur Daten die eine technische abhaengigkeit haben auch gepflegt werden.
Hier: Ist es im renderer nicht zu sehen wird es nicht gepflegt.

Ich denke das wird uns als erstes mit den "maxspeed" dingern auf die
Fuesse fallen. Ist zwar schoen und gut gemeint (habe ich auch reichlich
gemacht) aber es wird nicht korrigiert, ergaenzt oder sonstwie gepflegt.
Und noch viel schlimmer wird das je komplexer die daten sind sprich
Relations a la Turn Restrictions etc ...

Vielleicht sollte man kleine maxspeed schilder auf die Straßen rendern
*duck*

Flo
--
Florian Lohoff flo-BCn6idZOOBwdnm+***@public.gmane.org +49-171-2280134
Those who would give up a little freedom to get a little
security shall soon have neither - Benjamin Franklin
Bernd Wurst
2008-08-09 08:55:43 UTC
Permalink
Hallo.
Post by Florian Lohoff
Ich denke das wird uns als erstes mit den "maxspeed" dingern auf die
Fuesse fallen. Ist zwar schoen und gut gemeint (habe ich auch reichlich
gemacht) aber es wird nicht korrigiert, ergaenzt oder sonstwie gepflegt.
Und noch viel schlimmer wird das je komplexer die daten sind sprich
Relations a la Turn Restrictions etc ...
Das wird dann "gerendert", wenn es die ersten Navis gibt, die auf OSM-Daten
aufbauen. Speelimits sind in den kommerziellen Karten (soweit ich das bei
meinem Navi sehe) echte Mangelwaren, dort unvollstÀndige Daten zu haben wird
also niemanden davon abhalten, OSM zu benutzen.

LÀuft dann OSM auf nem Navi, dann fÀllt es auf wenn ein speedlimit fehlt und
man kann es nachtragen.

Gruß, Bernd
--
Zwei Monologe, die sich gegenseitig immer und immer wieder störend
unterbrechen,
nennt man eine Diskussion.
Garry
2008-08-09 10:35:51 UTC
Permalink
Post by Bernd Wurst
Hallo.
Post by Florian Lohoff
Ich denke das wird uns als erstes mit den "maxspeed" dingern auf die
Fuesse fallen. Ist zwar schoen und gut gemeint (habe ich auch reichlich
gemacht) aber es wird nicht korrigiert, ergaenzt oder sonstwie gepflegt.
Und noch viel schlimmer wird das je komplexer die daten sind sprich
Relations a la Turn Restrictions etc ...
Das wird dann "gerendert", wenn es die ersten Navis gibt, die auf OSM-Daten
aufbauen. Speelimits sind in den kommerziellen Karten (soweit ich das bei
NaviPowm zeigt die Speedlimits bereits seit einiger Zeit an - OK, ist im
Moment noch ehr eine Moving Map
als eine Navi, aber das mit den Sppedlimits funktioniert.

Ausserdem gibt es ein
*OSM-Overlay mit maxspeed*
http://forum.pocketnavigation.de/tid1111943-sid.htm

Vielleicht schafft es ja auch bald jemand dass auf dem Garmin die
OSM-Limits angzeigt werden
Bernd Wurst
2008-08-09 10:45:15 UTC
Permalink
Hallo.
Post by Garry
NaviPowm zeigt die Speedlimits bereits seit einiger Zeit an - OK, ist im
Moment noch ehr eine Moving Map
als eine Navi, aber das mit den Sppedlimits funktioniert.
Von dem Programm hatte ich bisher noch gar nichts gelesen.
Leider findet Google als Website dafÃŒr nur ein sourceforge-Projekt, das
als "ÃŒngÃŒltig" behandelt wird.

Gibt es irgendwo noch Infos dazu, die nicht auf sourceforge verborgen sind?

Gruß, Bernd
--
Was ist die ökologischste Verpackung fÌr Milch?
Das ist eine Kuh! Warum?
Weil man die Verpackung mitessen kann!
- Dieter Nuhr (dt. Comedian)
Garry
2008-08-09 11:30:48 UTC
Permalink
Post by Bernd Wurst
Hallo.
Post by Garry
NaviPowm zeigt die Speedlimits bereits seit einiger Zeit an - OK, ist im
Moment noch ehr eine Moving Map
als eine Navi, aber das mit den Sppedlimits funktioniert.
Von dem Programm hatte ich bisher noch gar nichts gelesen.
Leider findet Google als Website dafür nur ein sourceforge-Projekt, das
als "üngültig" behandelt wird.
Gibt es irgendwo noch Infos dazu, die nicht auf sourceforge verborgen sind?
Gruß, Bernd
Mhm - Merkwürdig...

Der Author liess hier gelegentlich mit, vielleicht meldet er sich ja
diesbezüglich hier oder auf www.pocketnavigation.de
Gegebenfalls kann ich Dir das Programm mailen...

Gruss
Garry
Doru Julian Bugariu
2008-08-09 19:56:50 UTC
Permalink
Hi,
Post by Bernd Wurst
Post by Garry
NaviPowm zeigt die Speedlimits bereits seit einiger Zeit an - OK, ist im
Moment noch ehr eine Moving Map
als eine Navi, aber das mit den Sppedlimits funktioniert.
Von dem Programm hatte ich bisher noch gar nichts gelesen.
Leider findet Google als Website dafÃŒr nur ein sourceforge-Projekt, das
als "ÃŒngÃŒltig" behandelt wird.
Das liegt an SourceForge, die gerade ihr Rechenzentrum umziehen. Manche
Sachen funktionieren seit einer Weile nicht, oder nur eingeschraenkt.

Zur Zeit geht es gerade wieder. Einfach immer wieder mal mal probieren.

;-)

Gruesse,
Julian
Garry
2008-08-09 10:27:41 UTC
Permalink
Post by Florian Lohoff
Ich denke das wird uns als erstes mit den "maxspeed" dingern auf die
Fuesse fallen. Ist zwar schoen und gut gemeint (habe ich auch reichlich
gemacht) aber es wird nicht korrigiert, ergaenzt oder sonstwie gepflegt.
Und noch viel schlimmer wird das je komplexer die daten sind sprich
Relations a la Turn Restrictions etc ...
Bei Maxspeed sind es ehr die Anwendungen die es bringen.
Kaum einer weiss aus der Erinnerung wo welche Schiler mit welchen Limits
(genau) stehen.
Fahre ich aber mit dem Navi lang und sehe einen falschen Wert so pass
ich den zumindest auf den regelmässig befahrenen
Strecken an.

P.S. Ich verwende hierfür NaviPowm

Garry
Sven Geggus
2008-08-07 17:49:05 UTC
Permalink
Post by Tobias Wendorff
Der Pluralismus endet hier im Chaos. Ich muss jetzt vergleichen, ob
es: ja, yes, yo, 1, true, yepp und dann noch die Gegenteile vergleichen.
Zusätzlich noch ein Abfrage, ob das Feld vielleicht leer ist.
Heul doch! Wenn man die Daten in Postgis drin hat ist das grade mal
ein _einziger_ update Befehl um das zu bereinigen:

osm=> update planet_osm_line set oneway='yes' where (oneway='true' or oneway='1');
UPDATE 2937

Ein bissl Statistik für Baden-Württemberg (mehr ist in meiner Postgis
derzeit nicht drin):

oneway='1': 5
oneway='true': 652
oneway='yes': 2051
oneway='yo': 0
oneway='yepp': 0
oneway='ja': 0

Die Abfragen sind natürlich älter als der update :)

Wo wirs vorghin grade von ungeeigneten Tools hatten, psotgis ist
definitiv eines der geeigneteren.

Gruss

Sven
--
.. this message has been created using an outdated OS (UNIX-like) with an
outdated mail- or newsreader (text-only) :-P

/me is ***@ircnet, http://sven.gegg.us/ on the Web
Tobias Wendorff
2008-08-07 17:53:45 UTC
Permalink
Post by Sven Geggus
Heul doch!
^^^^^^^^^^^^
Das war unnötig!
Sven Geggus
2008-08-07 20:11:01 UTC
Permalink
Post by Tobias Wendorff
Post by Sven Geggus
Heul doch!
^^^^^^^^^^^^
Das war unnötig!
Aus der Tatsache, dass Du den durchaus konstruktiven Teil meines
Postings unkommentiert läßt mag sich der geneigte Leser selbst seine
Meinung bilden.

Gruss

Sven
--
This APT has Super Cow Powers.
(apt-get --help on debian woody)

/me is ***@ircnet, http://sven.gegg.us/ on the Web
Dirk Stöcker
2008-08-08 07:14:45 UTC
Permalink
Post by Sven Geggus
Post by Tobias Wendorff
Post by Sven Geggus
Heul doch!
^^^^^^^^^^^^
Das war unnötig!
Aus der Tatsache, dass Du den durchaus konstruktiven Teil meines
Postings unkommentiert läßt mag sich der geneigte Leser selbst seine
Meinung bilden.
Ich ignoriere Positings mit persönlichen Angriffen generell, egal ob sie
sonst noch sinnvolle Argumente enthalten oder nicht. Das muss Tobias noch
lernen. Ansonsten hat er vollkommen recht.

Ciao
--
http://www.dstoecker.eu/ (PGP key available)
Sven Sommerkamp
2008-08-10 06:24:11 UTC
Permalink
Post by Dirk Stöcker
Das macht z.B. JOSM mittlerweile automatisch. Nur eben mehr durch Raten.
Ein vern?nftiger einheitlicher Standard w?rde hier helfen. Und darum geht
es eben. Nicht um -1 oder nicht, sondern darum, dass dies eben nur mit
oneway klappt und nicht allgemein.
Au?er Fl?ssen f?llt mir keine andere Situation ein, wo die Richtung
?berhaupt eine Rolle spielt..
Post by Dirk Stöcker
a) Nicht dokumentiert
b) "Manche Mapper..."
c) Nicht an den Daten zu erkennen
--> Kein Standard. Was hat das mit meinem Verhalten zu tun?
Das es eben keinen Standards gibt, sondern nur Konventionen. Nur weil
du etwas als vermeintlichen Standard annimmst, hei?t das noch lange
nicht, das sich andere Mapper danach richten m?ssten, oder das es
automatisierte "Berichtigungen" geben sollte - insbesondere, wenn es
defacto nicht falsch ist.
Post by Dirk Stöcker
Kann es sein, da? Du bewu?t versuchst alles falsch zu verstehen, damit Du
andere Meinungen als bl?d darstellen kannst? In diesem Fall war das meine
letzte Antwort auf Deine Posts.
Keineswegs - ich wundere mich nur dar?ber, das du s?mtliche Vorschl?ge
wie man mit sowas umgeht gekonnt ignorierst und weiterhin darauf
Es ist n?mlich "softwarem??ig" ?berhaupt kein Problem eine ODER
Anweisung aufzunehmen. Wir reden ja nicht von hunderten sondern
?berschaubaren 3 oder 4 M?glichkeiten.
Aber dieser Fall mit oneway ist nicht der einzige Fall wo etwas unklar
geregelt oder mit Konventionen vershen ist.
Da gibt es viel andere.
Es geht auch darum, nicht ein Wirr Warr zu schaffen, durch das keiner mehr
durchsieht.
Ihm geht es um klare Linien wie etwas gemacht wird und zu denen müssen wir
auch kommen.
Dann müssen Dinge halt abgestimmt werden und was heraus kommt ist dann
Standard.
Das ist demokratisch und widerspricht sicher nicht unserem keiner ist Chef
Grundsatz.
Gru?
Stefan
Gruß Sven
Sven Sommerkamp
2008-08-10 06:11:30 UTC
Permalink
Post by Tobias Wendorff
Hallo,
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?
Dann müssen wir wohl auch mal Dinge auf irgendeine Art zusammen festlegen.
Denn es ist wahr, es gibt Grenzen was noch als sinnvoll zu erachten ist.
Ich habe z.B. schon paar Mal nach einem Tag für mein Goldfischglas in meinem
Keller auf dem Schreibtisch gefragt und nie wußte jemand eine Antwort,
dann werde ich jetzt selbst ein paar Tags entwickeln und die Datenbank
zumüllen mit Dingen die nur ich gebrauchen kann?

Wir brauchen Regeln!
Ohne die geht es nicht.
Und die müssen, da hat der Autor recht, möglichst einheitlich sein.
Wir wollen nicht alles unnötig verkomplizieren, denn dazu hat OSM auch eine
Affinität.
Post by Tobias Wendorff
Bye
Frederik
Gruß Sven S.
Frederik Ramm
2008-08-10 08:09:23 UTC
Permalink
Hallo,
Post by Sven Sommerkamp
Post by Frederik Ramm
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug korrigieren
und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?
Dann müssen wir wohl auch mal Dinge auf irgendeine Art zusammen festlegen.
Muessen wir?
Post by Sven Sommerkamp
Denn es ist wahr, es gibt Grenzen was noch als sinnvoll zu erachten ist.
Die gibt es sicherlich, die Frage ist, "von wem" als sinnvoll zu erachten.
Post by Sven Sommerkamp
Ich habe z.B. schon paar Mal nach einem Tag für mein Goldfischglas in meinem
Keller auf dem Schreibtisch gefragt und nie wußte jemand eine Antwort,
dann werde ich jetzt selbst ein paar Tags entwickeln und die Datenbank
zumüllen mit Dingen die nur ich gebrauchen kann?
Wir brauchen Regeln!
Ohne die geht es nicht.
Bislang sind wir gut damit gefahren, dass es eine "Tendenz" gibt; man
kann zu irgendwas ne Meinung einholen und bekommt manchmal ein
ueberwiegendes "Schrott" oder ein ueberwiegendes "ja klasse, mach". Es
gibt allerdings keine wirklich festgelegten Regeln, und das soll auch so
bleiben.

Wir muessen nicht daran arbeiten, Dir zu verbieten, dass Du Dein
Goldfischglas taggst (und einen Kontrollapparat aufzubauen, der
sicherstellt, dass Du es auch wirklich nicht machst). Wir muessen
vielmehr daran arbeiten, dass Dein Goldfischglas nur diejenigen zu sehen
bekommen, die sich fuer Goldfischglaeser interessieren! Das waere fuer
alle die beste Loesung. Beim Rendern funktioniert das schon
einigermassen; beim Editieren wird es noch kommen.

Das ist wie mit dem Internet: Du kannst ein Foto von Deinem
Goldfischglas reinstellen, niemand verbietet Dir das. Ob es jemand
anguckt, ist eine andere Frage.

Bye
Frederik
--
Frederik Ramm ## eMail frederik-VkTBmBTYYDUdnm+***@public.gmane.org ## N49°00'09" E008°23'33"
Sven Sommerkamp
2008-08-10 06:34:53 UTC
Permalink
Post by Torsten Leistikow
Post by Michael Buege
Post by Torsten Leistikow
Wir schrecken aber auch genug Leute ab, weil OSM heute doch
ziemlich unuebersichtlich ist.
Woher hast Du diese Informationen? Kennst Du Leute, die sich haben
abschreckenlassen und wie haben sie das konkret begruendet? Wie viele
 Leute waren das bei Dir bis jetzt?
100% der Leute, die ich zur Mitarbeit motivieren konnte, haben sich
darueber beschwert, wie durcheinander bei OSM alles ist und das man
nirgendwo eindeutige Antworten oder Vorgehensweisen bekommt. N = 1.
Post by Michael Buege
Was ist "das Beste"? Wer bestimmt, was "das Beste" ist und was sind
die Massstaebe? Wie kann man das festlegen, welche Prozedere sind
notwendig und wer bestimmt wiederum, welches der richtige Weg ist, um
 solche Festlegungen zu treffen? Und welches sind die
Qualifikationsbedingungen fuer Leute, die das machen?
Wie waere es mit einer guten alten Abstimmungsprozedur. Es gibt ja auch
schon einen Weg, wie neue Features eigentlich eingefuehrt werden sollten.
Bei irgendwelchen Normierungsgremien gibt es ja genug vorbild, wie so
etwas laufen sollte (und auch das eine oder andere gegenbeispiel).
Post by Michael Buege
Zwangbereinigung? Wir reden doch immer noch ueber _Open_ streetmap,
oder?
Ich habe Open immer im Sinne von "Frei" zur Nutzung verstanden. Voellig
unreglementiert ist eine ander Sache. Bei Open-Source-Software oder
-Hardware erwarte ich ja auch, dass sie sich an die verschiedenen Normen
und Standards haelt.
Sonst müßten wir ja jedesmal bei Null beginnen.
Z.B.wie wird Einbahnstraße geschrieben?
Post by Torsten Leistikow
Post by Michael Buege
Post by Torsten Leistikow
PS: Es waere mal interessant zu wissen, wieviele Leute bei OSM um
des Mappens-Willen mitmachen, und wieviele staerker am Ergebniss
bzw. Nutzen interessiert sind.
Das gehört zusammen, man macht etwas für ein Ergebnis.
Ich arbeite auch um Geld zu verdienen, aber auch um meinem Leben Sinn und
Richtung und Herausforderung zu geben.
Post by Torsten Leistikow
Post by Michael Buege
Was ist mit Mischformen?
Da ich den Komparativ verwendet habe, ist theoretisch nur eine einzige
Mischform denkbar: Diejenigen, denen beide Sichtweisen voellig gleich
sind :-)
Post by Michael Buege
Post by Torsten Leistikow
Hier in den Diskussionen prallen doch immer wieder beide
Sichtweisen aufeinander.
Findest Du das nicht normal?
Normal schon, aber nicht unbedingt foerderlich.
Wenn ich, oder jemand anderes eine automatische Bereinigung haben will,
so kann er das ja einfach machen. Die Lizenz gestattet es ja gerade,
dass man die Daten nach seinen Wuenschen veraendern kann.
Es steht natuerlich auch jedem frei, einen Bot anzuschmeissen, der die
Werte nach Belieben (oder auch zufaellig) wieder vertauscht. Ist die
OSM-Welt ohne Regeln nicht etwas Wunderbares?
Also müssen eben doch Regeln her und Open bedeutet für mich das wir die
demokratisch festlegen und dann einhalten.
Solange bist wir demokratisch festlegen das es aus irgendwelchen Gründen
Quatsch ist es so zu machen.
Post by Torsten Leistikow
Gruss
Torsten
Sven Sommerkamp
2008-08-10 08:42:12 UTC
Permalink
Post by Tobias Wendorff
Hallo,
Post by Sven Sommerkamp
Post by Frederik Ramm
Post by Dirk Stöcker
Unter Freiheit verstehe ich dass nichts verboten wird. Unfug
korrigieren und abschaffen widerspricht dem nun wirklich nicht.
Das Problem ist: Wer entscheidet, was Unfug ist. Dass diese Entscheidung
nicht leicht ist, weisst Du als regelmaessiger talk-de-Leser: Sind
Strassenlaternen Unfug? Parkbaenke? Flugrouten?
Dann müssen wir wohl auch mal Dinge auf irgendeine Art zusammen
festlegen.
Muessen wir?
Wenn nicht gewisse Dinge in bestimmten Bereichen festgelegt wären könnten wir
diese Diskussion gar nicht führen!
Post by Tobias Wendorff
Post by Sven Sommerkamp
Denn es ist wahr, es gibt Grenzen was noch als sinnvoll zu erachten ist.
Die gibt es sicherlich, die Frage ist, "von wem" als sinnvoll zu erachten.
Von der Gemeinschaft in einer demokratischen Abstimmung.
Post by Tobias Wendorff
Post by Sven Sommerkamp
Ich habe z.B. schon paar Mal nach einem Tag für mein Goldfischglas in
meinem Keller auf dem Schreibtisch gefragt und nie wußte jemand eine
Antwort, dann werde ich jetzt selbst ein paar Tags entwickeln und die
Datenbank zumüllen mit Dingen die nur ich gebrauchen kann?
Wir brauchen Regeln!
Ohne die geht es nicht.
Bislang sind wir gut damit gefahren, dass es eine "Tendenz" gibt; man
kann zu irgendwas ne Meinung einholen und bekommt manchmal ein
ueberwiegendes "Schrott" oder ein ueberwiegendes "ja klasse, mach".
Auch das ist noch nicht einmal immer klar abzuschätzen, sollen Fluglinien nun
ins System oder nicht?
Post by Tobias Wendorff
Es
gibt allerdings keine wirklich festgelegten Regeln, und das soll auch so
bleiben.
Sind wir damit gut gefahren?
Oder war es ein Anfang?
Post by Tobias Wendorff
Wir muessen nicht daran arbeiten, Dir zu verbieten, dass Du Dein
Goldfischglas taggst (und einen Kontrollapparat aufzubauen, der
sicherstellt, dass Du es auch wirklich nicht machst). Wir muessen
vielmehr daran arbeiten, dass Dein Goldfischglas nur diejenigen zu sehen
bekommen, die sich fuer Goldfischglaeser interessieren!
Nur wen sollte das interessieren?
Und wenn es niemanden sonst interessiert, dann kostet es nur Geld, Zeit und
Speicherkapazität.
Es bremst das ganze System aus und macht es für alle anstrengender damit zu
arbeiten oder umzugehen.
Post by Tobias Wendorff
Post by Sven Sommerkamp
Das waere fuer  
alle die beste Loesung.
Das ist deine Meinung!
Post by Tobias Wendorff
Post by Sven Sommerkamp
Beim Rendern funktioniert das schon  
einigermassen; beim Editieren wird es noch kommen.
Mein Goldfischglas, selbst wenn es denn nirgends auftauchen würde,
bläht die Datenbank zusätzlich ohne Nutzen auf.
Das kostet Geld Zeit und Nerven für mich und andere.
-Speicherplatz muß vorgehalten werden.
-Die Daten müssen zum runterladen vom Server zusammengestellt und  
heruntergeladen werden was Zeit und Rechenkapazität kostet.
-Umso mehr Dinge die nichts nutzen geladen werden umso mehr werden auch die
Sachen verzögert die wirklich viel Nutzen für eine große Gemeinschaft
bringen.
Post by Tobias Wendorff
Das ist wie mit dem Internet: Du kannst ein Foto von Deinem
Goldfischglas reinstellen, niemand verbietet Dir das. Ob es jemand
anguckt, ist eine andere Frage.
Das kann ich aber nur solange wie ich das irgendwie finanzieren kann.
(Speicherplatz und Internetanbindung)
Und es ist schon deswegen etwas anderes, weil ein Foto irgendwo auf einem
Server für sich steht.
Die Daten die wir erzeugen, hängen quasi zusammen.
Wenn ich einen Bereich herunterlade um z.B. einen Straßennamen hinzuzufügen,
dann lade ich auch die Goldfischgläser Kühlschränke und dergl. herunter.
Diese Daten vom Openstreetmapserver bereitzustellen kostet Rechenzeit (in
dieser können andere Anfragen nicht bearbeitet werden) Geld, denn auch heute
kostet Speicherplatz noch Geld.
Post by Tobias Wendorff
Bye
Frederik
GrußSven S.
Christoph Eckert
2008-08-10 09:23:42 UTC
Permalink
Moin,
Post by Sven Sommerkamp
Post by Frederik Ramm
Die gibt es sicherlich, die Frage ist, "von wem" als sinnvoll zu erachten.
Von der Gemeinschaft in einer demokratischen Abstimmung.
das führte zur Diskriminierung von Minderheiten mit Spezialinteressen.
Interessante Entwicklungen wie
http://www.openpistemap.org/
oder
http://www.gravitystorm.co.uk/osm/
würde es künftig sehr viel seltener oder gar nicht mehr geben. Zudem
riskiertest Du dass sich eine Menge Leute zurück- oder aber ein eigenes
Projekt hochziehen.

OSM ist eine gewaltige Geodatenbank mit Infrastruktur außenrum, die man
einfach in Anspruch nehmen kann, wenn man eine coole Idee umsetzen möchte.

Wenn Archäologen unsere Datenbank für sich entdecken finde ich das cool.

Wenn die europäischen Goldfischzüchter alle Goldfischgläser dieses Planeten in
die Datenbank hauen wollten, sollten sie das dürfen. Es ist Sache der API
und/oder der Editoren dafür zu sorgen dass andere durch die Goldfischgläser
nicht mehr als unbedingt nötig belästigt werden.

Wenn die Radfahrer im Projekt anfangen Radrouten zu erfassen, sollten wir das
dann verbieten weil die Radfahrer nur 10% der Projektmitglieder stellen und
die Routen die Datenbank zumüllen? Sollen wir sie wirklich mittels einer
demokratischen Abstimmung 'rausschmeißen und ein eigenes Projekt aufmachen
lassen?

Und jetzt sag nicht mein Beispiel sei überspitzt ;-) .

Gruß,

ce
Frederik Ramm
2008-08-10 10:27:38 UTC
Permalink
Hallo,
Post by Sven Sommerkamp
Post by Frederik Ramm
Post by Sven Sommerkamp
Denn es ist wahr, es gibt Grenzen was noch als sinnvoll zu erachten ist.
Die gibt es sicherlich, die Frage ist, "von wem" als sinnvoll zu erachten.
Von der Gemeinschaft in einer demokratischen Abstimmung.
[...]
Post by Sven Sommerkamp
Post by Frederik Ramm
Wir muessen nicht daran arbeiten, Dir zu verbieten, dass Du Dein
Goldfischglas taggst (und einen Kontrollapparat aufzubauen, der
sicherstellt, dass Du es auch wirklich nicht machst). Wir muessen
vielmehr daran arbeiten, dass Dein Goldfischglas nur diejenigen zu sehen
bekommen, die sich fuer Goldfischglaeser interessieren!
Nur wen sollte das interessieren?
Und wenn es niemanden sonst interessiert, dann kostet es nur Geld, Zeit und
Speicherkapazität.
Ich denke, da sind wir am springenden Punkt. Wenn es uns gelingt, mit
der Information so umzugehen, dass jeder das sieht, was ihn
interessiert, dann sind die einzigen unnoetigen "Kosten", die entstehen,
die des Serverbetreibers. Wenn also irgendjemand was zu sagen haette,
dann ja wohl der Serverbetreiber, und nicht "die Gemeinschaft in einer
demokratischen Abstimmung". Und ich bin recht froh, dass der
Serverbetreiber sich nicht einmischt.
Post by Sven Sommerkamp
Es bremst das ganze System aus und macht es für alle anstrengender damit zu
arbeiten oder umzugehen.
Nicht, wenn wir damit vernuenftig umgehen.
Post by Sven Sommerkamp
Mein Goldfischglas, selbst wenn es denn nirgends auftauchen würde,
bläht die Datenbank zusätzlich ohne Nutzen auf.
Angenommen, Du bist ein guter Mapper, dann bin ich gern bereit, Dein
Goldfischglas zu akzeptieren, wenn wir Dich dadurch bei der Stange
halten koennen. - Oder allgemeiner: Dadurch, dass auch Leute mit einem
Nicht-"Mainstream"-Hobby sich bei OSM engagieren koennen, gewinnen
letzten Endes alle. Wer ausser ein paar Spiessern will schon bei einem
gleichgeschalteten, auf Effizienz getrimmten Strassenerfassungsprojekt
mitmachen? Wuerden wir damit das Presse-Echo bekommen, das wir derzeit
haben?
Post by Sven Sommerkamp
Das kostet Geld Zeit und Nerven für mich und andere.
-Speicherplatz muß vorgehalten werden.
Lass das mal die Sorge derer sein, die den Speicherplatz vorhalten.
Post by Sven Sommerkamp
-Die Daten müssen zum runterladen vom Server zusammengestellt und
heruntergeladen werden was Zeit und Rechenkapazität kostet.
Lass das mal die Sorge derer sein, die den Server betreiben. Die paar
Goldfischglaeser oder deren Aequivalent sind ein Nichts im Vergleich zu,
zum Beispiel, den TIGER-Daten - die fuer Dich als Europaer vermutlich
genauso "nutzlos" sind. Und Du kannst Dich drauf verlassen, dass ein
flaechendeckender Import von deutschen Goldfischglaesern, der die
Datenmenge in Deutschalnd verdoppelt, vorher gruendlich diskutiert
wuerde, genauso wie das z.B. auch mit dem TIGER-Import passiert ist.
Post by Sven Sommerkamp
-Umso mehr Dinge die nichts nutzen geladen werden umso mehr werden auch die
Sachen verzögert die wirklich viel Nutzen für eine große Gemeinschaft
bringen.
Wenn wir unsere Engergie statt in das Bekaempfen der Freiheit anderer da
hinein stecken wuerden, mit den Daten schlauer umzugehen - so dass man
im Editor beispielsweise nur laedt und sieht, was man auch bearbeiten
moechte - dann waeren alle Deine Sorgen unbegruendet UND wir haetten ein
offenes Projekt, bei dem sich viele Leute gemaess ihrer Neigung
einbringen koennten.

Was Du willst, ist ein totdiskutiertes Demokratieprojekt, in dem jeder
nur machen darf, was die Mehrheit gut findet.
Post by Sven Sommerkamp
Post by Frederik Ramm
Das ist wie mit dem Internet: Du kannst ein Foto von Deinem
Goldfischglas reinstellen, niemand verbietet Dir das. Ob es jemand
anguckt, ist eine andere Frage.
Wenn ich einen Bereich herunterlade um z.B. einen Straßennamen hinzuzufügen,
dann lade ich auch die Goldfischgläser Kühlschränke und dergl. herunter.
Dann frag Dich doch mal, ob das so sein muss! Anstatt anderen Leuten zu
verbieten, ihre Goldfischglaeser zu taggen, denke doch darueber nach,
Deinen eigenen Edititierprozess effizienter zu gestalten, indem Du halt
diese Goldfischglaeser NICHT mit runterlaedst. Ich weiss, dass das heute
noch nicht geht, aber in diese Richtung sollten wir entwickeln -
maximale Offenheit, und jeder bekommt das raus, was er braucht. Anstatt
dass wir uns immer mehr mit Regeln und Vorschriften einmauern, weil wir
zu bloed sind, unsere Daten gescheit zu verarbeiten.
Post by Sven Sommerkamp
Diese Daten vom Openstreetmapserver bereitzustellen kostet Rechenzeit (in
dieser können andere Anfragen nicht bearbeitet werden) Geld, denn auch heute
kostet Speicherplatz noch Geld.
Dafuer, dass Du kein Geld in das Projekt investierst, kam in Deinem
Posting erstaunlich oft das Wort "Geld" vor. Ich bin nicht der Ansicht,
dass das relevant ist, besonders deswegen, weil - mein TIGER-Beispiel
oben - auf absehbare Zeit die Datenmenge, die Du als "legitim"
anerkennen muesstest, ein Vielfaches dessen ausmachen wird, was durch
die paar Goldfischglaeser, Lampenpfaehle usw. verbraucht wird, bei denen
Du Dir vielleicht ein "Verbot" wuenschen wuerdest. Das Geld brauchen wir
also so oder so.

Du sprichst davon, wie die Deiner Ansicht nach "unnuetzen" Daten die
Zeit aller verschwenden. Meiner Ansicht nach wird jeder Prozess, der
festlegen soll, welche Daten unnuetz sind und welche nicht, ein
Mehrfaches dieser Zeit verschwenden. Denk doch selbst mal ein bisschen
nach; oben sprichst Du von "Demokratie". Wer soll denn abstimmen? Wie
soll der sich legitimieren? Muss der dazu irgendwo Mitglied sein? Wo?
Kostet ihn das was? Welche Einspruchsverfahren gibt es? Wie kann
Missbrauch verhindert werden? Und selbst wenn Du auf alle diese Fragen
eine Antwort aus der Huefte schiessen kannst: Wie viele Monate wird
darueber diskutiert werden?

Unser Projekt ist nicht demokratisch, und das ist sehr gut so;
unterhalte Dich dazu mal mit ein paar Leuten, die schon laenger dabei sind.

Wenn Dir das nicht passt, dann setze einen eigenen Server auf, den Du
oder eine von Dir aufgebaute Community selber bezahlst. Dann kannst Du
da auch Regeln machen ("weil Speicherplatz Geld kostet"). Uebernimm die
aktuellen OpenStreetMap-Daten und sag den Leuten, sie sollen ab jetzt
bei Dir mitmachen, weil dort nur bestimmte Tags erlaubt sind und daher
alles schneller geht.

Bye
Frederik

Continue reading on narkive:
Loading...