[Talk-de] Semikolon als Trenner (war Re: Paketannahmestellen)

Guenther Meyer d.s.e at sordidmusic.com
So Nov 1 17:58:53 UTC 2009


Am Freitag 30 Oktober 2009 09:14:05 schrieb Nop:
> Hi!
> 
> Guenther Meyer schrieb:
> > Am Donnerstag 29 Oktober 2009 23:50:21 schrieb Karl Eichwalder:
> >> Guenther Meyer <d.s.e at sordidmusic.com> writes:
> >>> dann muessen das die anwendungen eben lernen.
> >>
> >> Es ist nicht ganz trivial, wenn auf einmal listen in bestimmten feldern
> >> auftauchen.  Wenn man so etwas nicht vorab festlegt, sollte man als
> >> mapper nicht die alten daten kaputtmachen, sondern zumindest fuer eine
> >> uebergangszeit ein passendes tag verwenden, z.b.:
> >
> > wer macht denn was kaputt?
> > listen gabs in osm schon fast immer. ich kann mich auch nicht daran
> > erinnern, dass jemand mal festgelegt hat, dass es pro key nur einen wert
> > geben darf...
> 
> Listen wurden noch nie irgendwo ausgewertet - und das hat seinen Grund.
nur weil es nicht ausgewertet wird soll es nicht benutzt werden?!? unsinn.
es gibt nunmal listen in osm, das ist fakt!

ich weiss nicht, warum's andere programme nicht machen; zumindest bei gpsdrive 
ist es so, dass noch keiner die zeit dazu hatte, bzw. die prioritaeten im 
moment woanders liegen. geplant ist es aber...

> Wenn jemand anders einen Node sauber und funktionstüchtig eingetragen
> hat und Du kommst, machst eine Liste aus einigen Tags und sorgst dafür,
> daß der Node von keinem Tool und keinem Renderer mehr erkannt wird, so
> würde ich das durchaus auch als kaputtmachen bezeichen.
>
informationen hinzufuegen und dafuer eine bereits bestehende und oft genutzte 
methode benutzen nennst du kaputtmachen. ja ne, is klar...
 
> > relationen sind schoen und gut - fuer manche dinge.
> > bei anderen bringen sie nur unnoetige komplexitaet rein.
> > es ist EIN laden, also reicht ein node. einfacher geht's nicht.
> 
> Nein, reicht nicht, weil der logische Zusammenhang zwischen mehreren
> Tags verloren geht.
> 
was geht denn verloren?!?

> Das ist ein leidiges Problem, zu dem es mehrere unterschiedliche
> Lösungsansätze gibt, z.B. auch den Array-ähnliche Tagstrukturen
>  einzuführen.
> 
ja, die gibt es. zumindest ich bevorzuge die einfachste loesung, die mich zum 
ziel bringt. und das ist in diesem fall nicht die relation.

> Aber mehrere eindeutige Nodes zu setzen erscheint mir als die
> vielversprechendste. Dann sind die Daten eindeutig und schlimmstenfalls
> muß man beim Rendern Objekte zusammenfassen.
> 
> >>> technisch sehe ich da ueberhaupt keine probleme...
> >>
> >> "Seelig sind..."
> >
> > bitte programmier erst mal selber was, bevor du hier mit dummen spruechen
> > kommst!
> > einen string an einem trennzeichen aufsplitten ist sowas von trivial, die
> > resultierenden daten weiterzuverarbeiten ebenso...
> 
> Vielleicht solltest Du nicht beleidigend werden - vor allem weil er
> recht hat. :-)
> 
ich beleidigend? wer hat denn mit de bloed daherreden angefangen?

ausserdem, wenn er recht haben sollte, dann wil ich argumente hoeren und kein 
"seelig sind..."...


> Den String selber aufzsplitten, ist kein Thema. Aber damit ist die Sache
> noch lange nicht erledigt.
> - Du mußt jedes Objekt duplizieren, für jeden Eintrag in Deiner Liste
> einen. Das ist viel komplizierter als einfach eine Folge von Objekten zu
was ist daran kompliziert?

> verarbeiten, was heute alle Tools tun.
tun sie das wirklich?

> - Wenn die Kopien die gleiche ID behalten, funktioierne die meisten
> Mechanismen in Tools nicht mehr, da sich OSM auf eindeutige IDs geeinigt
> hat. Wenn sie eine unterschiedlcihe ID bekommen, funktionieren
> Referenzen nicht mehr
> - Es ist nicht klar, ob sich andere Tags dann auf alle Einträge in der
> Liste beziehen oder nur auf einen
ja und?
wenn ich eine anwendung schreibe, dann ist das absolut meine sache, wie ich 
das angehe, und wie ich bestimmte probleme loese.
bis jetzt scheint das konzept recht gut aufzugehen.

> Soweit mal die Spitze des Eisbergs. Wenn Du's tatsächlich probierst,
> dürftest Du noch auf einige interessante Detailproblem stoßen.
> 
jeder loesungsweg hat so seine probleme, es gibt keinen, der fuer alles 
perfekt waere. es haengt halt immer von der gewuenschten anwendung ab.

> > vor allem ist das semikolon als trenner schon lange in osm vorhanden, es
> > gibt sogar einen gewissen konsens dazu. das es bisher nicht so oft
> > benutzt wurde, mag vielleicht auch daran liegen, dass es vor api 0.6
> > nicht so die notwendigkeit gab.
> 
> Wenn es einen Konsens dazu gibt, dann den von allen Tools und allen
> Renderern, daß das keine gute Idee ist und nicht ausgewertet wird.
> Möglcherweise wissen die Entwickler ja, warum sie sich in dem Punkt
> ausnahmsweise alle einig sind. :-)
> 
im osm gibt es einige dinge die nicht ueberall implementiert sind.
zumindest was dieses thema angeht, koennte ich mich nicht dran erinnern, dass 
das diese schreibweise irgendwann mal von einem entwickler negativ bewertet 
wurde.





Mehr Informationen über die Mailingliste Talk-de