Christian Malolepszy wrote: > Hallo, > > On Thu, Aug 07, 2008 at 07:25:28PM +0200, Frederik Ramm wrote: >> 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.
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 _______________________________________________ Talk-de mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-de
