Hallo. Am Donnerstag, 7. August 2008 schrieb Tobias Wendorff: > Frederik Ramm schrieb: > > 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. > 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. > 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. > > 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
