migo315

Oder bei den Übersetzungen machen wir nen mittel Ding. Ich hatte schon mal hier in diesem Thread über den Unterscheid der "statischen" und "dynamischen" Übersetzungen geredet. Statische Übersetzungen machen mit Abstand das meiste im Projekt aus. Jeder Text ist fast eine statische Übersetzung, die wieder verwendet wird und unter https://crowdin.com/project/coastercloud gepflegt werden kann. Statische Übersetzungen sind für mich per se OK. Ich übersetze etwas einmal und kann es immer wieder verwenden. Auch sogut wie alle Attribute sind statische Übersetzungen. Die dynamischen Übersetzungen sind wirklich "Freitexte". Also welche, die konkret individuell nur auf den Park / Attraktion geschrieben werden. Davon gibt es nicht viele. Und aktuell kann man diese auch nicht in verschiedenen Sprachen hinterlegen. Jeweils für Parks und Attraktionen sind es "nur" folgende Bereiche: - Beschreibung (die Kurzbeschreibung) - Thema (ein Feld in dem man das Thema beschreibt wie "Western Stadt") - Besonderheiten (die Sammlung der Besonderheiten wie "Ältester Coaster Deutschlands") - Historie (Bei speziellen Events wie "2015 abgebrannt") Ggfs. nehmen wir dann erstmal nur die dynamischen raus. Also komplett und beschränken die Pflege auf alles, was nicht lokalisiert werden muss oder über statische Übersetzungen funktioniert. Würde in diesem konkreten Fall bedeuten, dass die 4 Felder oben wegfallen würden. Wobei man Historie zumindest teilweise auch mit statischen Übersetzungen hinbekommt (sowas wie Eröffnet, Geschlossen etc). Bei allen was ich hier offen diskutiere stellt sich mir immer der Gedanke: Was bringt das Projekt weiter? Und aktuell habe ich das Gefühl, dass das Thema dynamische lokalisierung mich sehr ausbremst. Würde ein (temporär) wegfallen solcher Felder ggfs. den Fokus auf die restlichen Felder erhöhen? Oder nimmt es zuviel Attraktivität raus? Wäre es vll besser erstmal weniger Anzubieten aber dafür stärker auf die Pflege zu gehen? Das sind so Fragen, die ich mir aktuell Stelle.

Und noch eine zweite Interessante Diskussion: Das Projekt hat auf deutsch angefangen. Nun unterstützt es deutsch und englisch. Wobei es mehrere Felder gibt die noch nicht übersetzt werden können (zb. Beschreibung). Ich spiele immer mal wieder mit dem Gedanken nur auf englisch zu gehen. Also alle Seiten auf englisch, alle Daten auf englisch. Das würde das komplexe Thema der lokalisierung eliminieren. Deutsche Apps etc. müsste dann ggfs. selber übersetzen. Sofern die überhaupt Texte übernehmen. Den Daten wie Sicherheitbestimmungen, Wartezeiten und technische Daten wie Höhe oder Länge sind ja quasi ohne lokalisierung nutzbar. Ich kann nicht einschätzen, inwieweit dies potenzielle Entwickler abschreckt. Aber mir würde das zumindest die Arbeit erleichtern. Und es käme zu keinen inkonsistenten Daten (weil zb. auf deutsch mehr gepflegt ist als auf englisch). Was meint ihr?

Eine Doku würde ich natürlich machen. Quasi sowie in http://graphql.org/swapi-graphql (klick mal oben rechts auf "Docs", dann kann man sich durch klicken). Meinst du sowas? Jetzt nochmal über die API nachzudenken ist schon irgendwie doof. Aber andererseits empfinde ich es echt schwer eine API zu designen, die jeden hilft und auch noch in 2 Jahren keine "technischen Schulden" hinterlässt. Ich glaub ich werde die aktuelle API nochmal als "experimantal" deklarieren und festmachen, dass ab dem 11. November die API zu "Stable" überläuft. Dann können wir noch ein paar Wochen austesten und probieren, bevor wir uns festlegen. Jetzt, solang noch kaum jemand die API nutzt, können wir sowas ja noch machen. In nem Jahr wird dies wohl schwieriger.

@RooStar @Tommy In den letzten Tagen bin ich echt am Design der API noch am grübbeln. Eigentlich steht dies ja bereits fest. Aber ich merke selber oft, dass der Endpunkt nicht immer alle Informationen so zurück gibt, wie ich es manchmal brauche. Ergo: Ich muss zwei Calls machen. Seit Tagen mache ich mir dazu Gedanken, wie es ich verbessern möchte. Eigentlich möchte ich jede Ressource (Park, Attraktion) einen eigenen Endpunkt geben (so wie es jetzt ungefähr ist). Mehrere Calls zu machen wenn ich aber übergreifend Informationen benötige ich auch gerade optimal. Hinzukommt, dass man oft auch gar nicht alle Informationen aus der Response benötigt. Beispiel: Will ich nur die Park Namen für eine Liste, erhält man aktuell auch alle Eigenschaften, Historie etc von allen Parks, was die Response recht fett macht. Nun evaluiere ich GraphQL anstatt der REST API zu nutzen. Habt ihr damit schon Erfahrungen gemacht? Das ermöglicht den Entwickler, alle Informationen die er benötigt selber ausszusuchen. Der Entwickler erhält also alles was er will - ohne "Datenmüll". Hier ein cooles Beispiel für die Star Wars API: http://graphql.org/swapi-graphql Was meint ihr? Wenn ich zum Beispiel alle Star Wars Filme zurück erhalten möchte inkl. der Namen aller Planeten die in dem Film spielen, sehe die Request so aus: In der REST API wäre Planten und Filme jeweils ein eigener Endpunkt, was zu doppelt Calls und Datenmüll führen würde.

Darauf wollte ich ja hinaus. ? So eine App gibt es noch nicht, kann aber jetzt entwickelt werden danke der Daten von coaster.cloud.

Ideen habe ich immer viele. Ein Kollege von mir will die Wartezeitdaten nutzen und so analysieren, dass für die nächste Tage geschätzt wird wie voll es wird. Eine App die ich als Familienvater vermisse: Freizeitpark Planner. Eine App (oder Seite), wo ich die Größe und Alter der Familie eingeben und der Planner zeigt mir, welche Parks sich für meine Familie aktuell am meisten lohnt. Also quasi "Im Phantasialand können wir ingessamt als Familie 20 Attraktionen fahren, im Movie Park nur 10 weil der kleinste nur 80 cm groß ist".

Ich werde die nächsten Tage PortAventura, Movie World Madrid und Parque de Attraciones samt Attraktionen pflegen. Paar Kollegen haben von den Attraktionen Fotos gemacht, welche die dann hochladen. ? Tatsächlich ist der Markt übersättigt was Webseiten, Blogs und Apps für Freizeitparks angeht. Und das in einem Markt, der die meisten ja eben nicht interessiert. Klar, viele Leute gehen in den Freizeitparks aber viele greifen dabei nicht auf inoffizielle Seiten und Apps zurück. Eine Tatsache, mit der ich mich anfangs auch erst sehr schwer anfreunden konnte. coaster.cloud kennt bisher nur Attraktionen und Parks. In Planung sind noch "Point of Interest" welches quasi Shops, Läden und co abdeckt und auch die Hotels. Ehrlicherweise wird dies aber wohl noch ein paar Wochen oder im worst case auch Monate dauern. Btw vll für dich interessant: Navigation innerhalb des Parks. Du wählst eine Attraktion aus und die App zeigt dir den Weg wie du laufen musst um am Eingang zu kommen. Ich habe keine Ahnung, wieviele das nutzen würden. Ich selber würde es vermutlich nicht nutzen. Aber ich bekomm immer wieder mit, was manch einer überfordert ist Attraktion XYZ zu finden. Die nächsten Tage werden auf coaster.cloud eher unspektakulär. Bin viel am Hintergrund am optimieren. Das Resultat wird eine noch flexiblere API.

Schicke ich dir per PN ? Klar - würde mich freuen ? Anders bekommt man ja auch soviele Daten gar nicht aktualisiert. Man ist auf die Community angewiesen. Beim Phantasialand hast du noch mehr gepflegt als nur Attraktionen - oder? Sieht zumindest auf dem Bild so aus. Was pflegst du denn alles? Buden? Hotels? ..?

Wie von @to b erwähnt, steht eigentlich auf Seite 1 alles. Nur beachten, dass das Projekt von "coaster-platform.org" auf "coaster.cloud" umbenannt wurde. ? Hier nochmal in kurz: Jap. Entwicklung begonn frühjahr 2018. Dezember 2018 ging ich damit an diese Community ... quasi eine Art "Soft Opening" um Feedback zu erhalten. Dafür ist ja auch dieser Thread. Wäre sehr nice ? Aktuell kann die API nur Daten abfragen. Aber tatsächlich wird es demnächst (= ein paar Wochen) auch die Möglichkeit geben, Daten über die API einzupflegen.

Die Daten stehen unter der Creative Commons Lizenz - eine Lizenz die auch Wikipedia verwendet. Bedeutet: Du kannst die Daten kostenlos für beliebige Zwecke nutzen - auch kommerziell. Eine konkrete Gegenleistung wird nicht erwartet - außer eben die Lizenzbedingngen einzuhalten. Die sind aber leichte Kost. Für die Nutzung der API ist auch keine Registrierung notwendig. Du kannst diese anonym nutzen. Trotzdem freuen wir uns aber natürlich, wenn Leute Parks oder Attraktion pflegen. Das Ziel dahinter ist, dass alle was davon haben und jeder ne coole App / Blog o.ä. bauen kann ohne sich zum X-ten mal die Daten zusammen zu suchen. Das ist aber alles gerade Off topic. Wir sollten das wenn hier weiter diskutieren: https://www.phantafriends.de/topic/3530-coaster-platform/page/6/

Ich habe kein Android Handy oder Uhr. Nur iPhone bzw. Apple Watch. Sorry ? Meine letzten Arbeiten mit Android sind auch schon verdammt lang her. Vor dem iPhone hatte ich sogar noch Windows Phones. Bevor du dir jetzt deine eigene API baust: Nutze coaster.cloud. Genau dafür ist das Projekt da. Du kannst Park-, Attraktionsdaten sowie aktuelle Wartezeiten über die API einfach abfragen: https://api.coaster.cloud/

Vom Prinzip her schon ... ... muss hier aber RooStar zustimmen, dass das Tizen SDK jetzt echt uncool aussah. Zumindest auf dem ersten Blick. Ich schau mir das die Tage mal genauer an. Zwangsläufig muss ja auch nicht unbedingt alles von mir Entwickelt werden. Von Vorteil wäre, wenn derjenige der die App für ein System entwickelt diese auch selber testen kann (weil er / sie entsprechend so eine Uhr hat).

Naja, dass es Wege gibt an Daten zu kommen ist ja ein offenes geheimnis. Seiten wie https://www.looopings.nl/wachten/phantasialand machen es ja bereits seit langem vor. Auf Github gibt es sogar kostenlose Libraries / Programme dafür. Für diese Apple Watch App beziehe ich die Daten aus https://coaster.cloud. coaster.cloud holt sich nicht aktiv die Daten sondern erhält diese von dritten. Für alle Parks, bei denen man LIVE Daten bekommt. 100-200 Benutzer bekommt man sicherlich nach einer Zeit. Aber 100 - 200 Nutzer die nen Euro bezahlen - puhh. Da bin ich mir nicht sicher. Den großteil ist selbst ein Euro für eine App zu teuer (und das obwohl man sich eine >300 € Uhr leistet). Aber selbst wenn: Ich habe kein Interesse dafür im Shop Geld zu nehmen. Sobald ich dies mache, ist dies kommerziell. Und Kommerziell bedeutet mehr Aufwand und mehr Risiken. Daran habe ich kein Interesse. Btw: Auch Werbung ist keine Option. Ebenfalls kommerziell und bin auch kein großer Fan davon. ? Die Daten sind aktuell. Alles andere wäre ja auch Witzlos. Kannst du hier einfach nachprüfen: https://coaster.cloud/de/waiting-times Jap - deswegen fand ich die Idee mit der Watch ebenfalls mega! @all Ich werde mal nen MoneyPool bei PayPal bereitstellen. Vielleicht kommt ja etwas zusammen. Wenn ja cool - wenn nein, auch nicht schlimm. Solang kann ich ja dann an einer App für Android Uhren und Fitbit bauen. ?

Die Apple Produkte sind überteuert. Gebe ich dir vollkommen recht. Vom Geld abgesehen, bin ich aber mit dem Produkten recht zufrieden. Zur App: Auch für Android Wearables und Fitbit wäre dies machbar (und wurde schon bei mir angefragt). Selbst entwickelt. Die App checkt im welchen Park du bist (GPS) und zeigt dir (sofern vorhanden) die aktuelle Wartezeiten an. Idee ist nicht von mir - habs aber mal testweise umgesetzt. Plan wäre sowohl für Apple Watch, Android Wearables und Fitbit rauszubringen. Für Apple Watch ist die App quasi sogar fertig - aktuell streube ich mich aber noch die 99$ zu zahlen um die App zu veröffentlichen.

Gibt es hier eigentlich Apple Watch nutzer? ?

Jap - es wird nicht alles aufgelistet. Eine erste Version habe ich soeben veräffentlicht. Rechts bei der Filterung kann man sowohl bei Parks als auch bei Attraktionen nun nach bestimmten "Tags" filtern: "Technische Daten fehlen" wird angezeigt, wenn weniger als 2 Attribute gepflegt sind. "Adresse fehlt" wenn auch nur ein Teil der Adresse fehlt (bsp. Straße oder Land). "Koordinaten fehlen" wird angezeigt wenn eines der beiden Koordindaten fehlt (Breiten- / Längengrad). Bei Attraktionen gibt es noch "Sicherheitsbestimmungen fehlen" - das wird angezeigt wenn weder Alter noch Größe für "Ohne Begleitung" gepflegt ist. Eines von beides sollte ja prinzipiell immer gefüllt werden können. Rest sollte klar sein.

Hey, es gibt eine neue Freaky Funktion: Anmelden ?? Tatsächlich habe ich erst vorgestern gemerkt, dass seit der Einführung der englischen Sprache der Login nicht mehr funktioniert hat. Das ist mir leider nicht aufgefallen, weil ich mich selber zuletzt nicht angemeldet habe. Hätte ja ruhig mal einer melden können ? Jetzt funktioniert dies auf jeden Fall wieder! Mal von diesem fetten Bug abgesehen, ist nicht viel passiert. Ich habe weiter an den Übersetzungen gearbeitet (wer fit in englisch ist kann gerne unter https://crwd.in/coastercloud gegenlesen und korrigieren) und paar Bugs behoben. Die größten Änderung habe ich am Alexa Skill gemacht. Dieser kann nun auch die Sicherheitesbestimmungen nennen: "Alexa, frage Park Guide ab wann man Taron fahren darf". Mehr dazu auf https://www.amazon.de/migo-Park-Guide/dp/B07WRGM736 In den nächsten Tagen möchte ich die Funktionen zur Pflege weiter optimieren. Unter anderem möchte ich für Parks und Attraktionen einen Pflegestatus einführen. Dieser ermittelt dann automatisch wo noch was gepflegt werden muss. Anhand einer Liste kann man dann sich zb. Parks / Attraktionen anzeigen lassen, wo noch Bilder oder Sicherheitsbestimmungen fehlen.

Die beobachtung mach ich in anderen Parks auch. Obwohl ich eigentlich immer den Sonntag voller erwarte.

Falls hier jemand ist mit guten Englisch Kentnissen ... ich übersetze aktuell das Projekt. Fänd cool wenn sich der ein oder andere, der die Sprache ein wenig beherrscht, sich mal meine Übersetzungen ansehen und ggfs. Verbesserungsvorschläge nennen kann. ? Liegt alles offen auf CrowdIn: https://crwd.in/coastercloud

Meine Erfahrung ist auch, dass für viele "normalos" der Begriff Looping sehr dehnbar ist. Eine Kurve mit seitlicher Lage reicht da oft schon aus ? Bisher das beste was ich mitbekommen habe: Van Helsings Factory hat nen Looping.

Hey Leute, ein paar News: Mittlerweile gibt es immer mehr Leute die etwas mit der API probieren und etwas damit entwickeln. Bisher war die API ja immer in einem "Entwicklungsstatus" - bedeutet nach neuen Feedback von Entwickeln wie auch beispielsweise von @Tommy sowie meinen eigenen Erfahrungen mit der API, habe ich Änderungen vorgenommen die teilweise ein Breaking Change verursacht haben. Bei einem Breaking Change funktioniert die API nicht mehr wie vorher und der Entwickler muss seine APP / Blog / Webseite entsprechend anpassen. Das ist normal in der Anfangphase - aber wie erwähnt interessieren sich immer mehr Leute dafür, die API zu nutzen. Daher wurde gestern Abend nun die erste "stable" Version der API veröffentlich. Die nun dokumentierten Endpunkte der API werden zu keinen Breaking Change mehr führen. Auch die URL o.ä. wird sich nicht mehr ändern. Der Entwickler kann also sicher sein, dass die Aufrufe zur API auch noch in 5 Jahren funktionieren wie diese es jetzt tun. Die API findet sich nun unter https://api.coaster.cloud/ Die Dokumentation der API wurde ebenfalls nun stark verbessert. Ansonsten habe ich selber weiter mit der Pflege von Parks beschäftigt. Bobbejaanland, Europa Park, Walibi Belgien und Walibi Holland sind nun gepflegt. Letzten 4 auch mit aktuellen Wartezeiten. Lediglich Bilder, paar technische Daten und Sicherheitsbestimmungen fehlen. Letzteres werde ich die Tage nachholen. Bilder habe ich keine. Wer also für die Parks Bilder hat, wäre ich sehr denkbar wenn ein paar den Weg zur coaster.cloud finden würden ?

Jap - genau! Kenn das ja durch dich. Hab mich damit ein wenig beschäftigt und finde die Übersetzungen auch in Ordnung. Und da die mittlerweile ihre Preise angepasst haben, wäre der Zugriff per API auch nun bezahlbar. Jo danke! Ich selber habe mir auch vorgenommen mindestens ein Park pro Woche einzupflegen um den Datenbestand in den nächsten Wochen massiv zu erhöhen. Heute war der Bobbejaanland ( https://coaster.cloud/parks/bobbejaanland/attractions ) dran. Leider habe ich kaum Bilder in den Jahren gesammelt.

Dito - bei mir läufts auch schnell.

Ich brauch euch mal fürs Brainstorming. Eines meiner Ziele ist es, auch zeitnah in anderen Sprachen Live zu gehen. Primär natürlich in Englisch. Damit soll die Reichweite des Projekts stark vergrößert werden. Offen bleibt das Thema der Übersetzung. Dabei muss man zwischen statischen Texten und dynamischen Unterscheiden. Statische Texte pflegen ich in einer Sprachdatei. Diese zu übersetzen ist kein Problem - dies mach ich selber. Quasi fast alles im Projekt sind statische Texte. Von der Startseite über das Impressum als auch die Feldbezeichnungen und Drop Down Inhalten. Also alles wo man nur auswählt, klickt o.ä. sind statische Texte. Interessanter sind die dynamischen Texte. Das sind die Inhalte, die man nicht auswählen kann sondern der Benutzer aktiv schreibt. Davon gibt es nur wenige Felder: Kurzbeschreibung, Inhalt des Feldes "Thema", Inhalt in der Historie und Inhalt der "Features" Felder bei Parks und Attraktionen. Diese müssen ebenfalls übersetzt werden - dies wird aber der Benutzer wohl nicht für jede Sprache machen. Es muss also automatisch passieren. Ein Mix aus verschiedenen Sprache und hin und her übersetzen halte ich aber für nicht so gut. Daher meine noch recht junge und unverbindliche Idee: Die Pflege aller Daten passiert ausschließlich auf Englisch. Also wird die Beschreibung beispielweise immer in Englisch geschrieben. Und dank einer API wie DeepL (Dank an @Kleator für den Tipp nochmal) wird von Englisch in den verschiedenen Sprachen (Deutsch, Französisch, Niederländisch, Spanisch) übersetzt. Englisch eignet sich dafür, weil sich Englisch am sichersten in allen anderen Sprachen übersetzen lässt und Englisch de facto eh die Weltsprache ist. Was meint ihr dazu? Wäre es für euch vorstellbar? Ich mein auf anderen Plattformen wie rcdb pflegt man imho ja auch auf Englisch. Oder wäre es für euch ein großer Hindernis Daten zu pflegen? Es gibt wohl gemerkt nur um die Pflege. Der normale Besucher erhält dann alles schön übersetzt.

Mein letzter Beitrag ist schon über 2 Monate alt. Aber lasst euch nicht täuschen - während dessen habe ich immer wieder weiter dran gearbeitet. ? Hier mal die größten Änderungen seit meinem letzten Beitrag: 1. Umbenennung zu coaster.cloud Da im meinem Umfeld immer wieder Leute Probleme mit "coaster-platform.org" hatten und ich den Namen eh nie sexy fand, gab es nun eine Umbenennung. Das Projekt wird nun unter den Namen "coaster.cloud" geführt und hat die gleichnamige URL https://coaster.cloud. Um ein freshes Logo kümmer ich mich noch. 2. Wartezeiten hinzugekommen Hier gibt es direkt zwei neue API Schnittstellen: Einmal um Wartezeiten abzufragen und einmal um Wartezeiten einzutragen. Bedeutet, auf coaster.cloud kann man nun Wartezeiten abfragen. Die Zeiten selber sollen dabei wieder aus der Community kommen. Dafür gibt es nun den ersten "schreibenden" API Endpunkt um über die API Sachen zu speichern. Während das Abfragen wie üblich jeder kann, muss man für das Eintragen einen Account auf coaster.cloud haben. Dazu demnächst mehr Details. Hier, wer mal schauen möchte: https://coaster.cloud/queue-times 3. "Alexa, frage Park Guide wie schnell ist Taron? Eigentlich mehr Spielzeug als Sinnvoll: Der Alexa Skill "Park Guide". Dieser entstand aus der Idee einfach mal die API zu nutzen und zu zeigen, was alles möglich ist. Den der Skill nutzt nur die Informationen und die jeder dank coaster.cloud nutzen kann. Langfristig werde ich den Alexa Skill an jemanden, der Lust hat dies weiter zu pflegen, abgeben. Bis dahin werde ich ab und zu Alexa ein paar Freizeitpark Informationen beibringen ? Mehr Infos unter https://coaster.cloud/alexa 4. Pflichtfelder entfernt / schnellere Eintragung Wenn man Attraktionen erstellt hat wurden ein paar technische Details vorausgewählt. Dies entfällt nun. Der Sinn dahinter war, dass die simplen Ja / Nein Felder eigentlich jeder wissen müsste. Als ich selber aber zuletzt ein paar Attraktionen gepflegt habe, konnte ich diese nicht "beantworten". Ich musste also raten - das ist ja nicht der Sinn einer Datenbank. Daher gibt es keine Vorauswahl mehr bei Neuanlagen von Attraktionen. Außerdem wurde ein zweiter Speicher Button hinzugefügt, womit man nach dem Speichern direkt eine weitere Attraktion erstellen kann. 5. Neue Felder Es gibt zwei neue Felder. Eines um "Umgangssprachliche" Namen zu speichern. Beispiel: Man sagt ja meist nicht "Das verrückte Hotel Tartüff", was der offizielle Name ist sondern meist eher nur "Hotel Tartüff". Oder statt "Movie Park Germany" sagt man ja meist nur "Movie Park". Um solche Einträge geht es. Des Weiteren wurde ein Feld für das Handling von Rucksäcken hinzugeügt (darf Rucksack mitgenommen werden auf Attraktion oder muss es in einem Korb o.ä.). 6. Historie überarbeitet Das lag mir lange echt im Magen. Ich war mit der Historie und dem "Eröffnet" / "Geschlossen" Felder nicht zufrieden. Grund dafür ist zb. "Crazy Bats". Eröffnet wurde es 1988, aber jetzt quasi "Neueröffnet". Welches Datum speicher ich nun im "Eröffnet" Feld? 1988 wäre richtig, aber 2019 wäre wichtig um es bei Neuheiten zu sehen. Lange wusste ich nicht, wie ich es handeln soll. Nun ist aber eine Lösung gefunden: Die Felder für "Eröffnung" und "Geschlossen" gibt es nicht mehr. Sowas wird nun in der Historie gespeichert. Dafür kann man in der Historie nun den Typ auswählen. Das sorgt dann für eine saubere Historie und einen sauberen Datenstand (siehe Screenshot). Die Historie wird nun auch in einem eigenen Tab dargestellt, da diese je nach Park / Attraktion sehr groß sein kann. 7. Suchengine ausgetauscht Den austausch der Suchengine wird quasi niemanden interessieren. War aber der heftigste Punkt. Dafür habe ich gut zwei Wochen gebraucht. Das hat sich aber gelohnt, da wir nun viel bessere Abfragen durchführen können. Zudem ist das Sortieren nun möglich. Diese Anpassung passiert also eher im Hintergrund - ermöglicht aber viele neue Sachen. Das waren so die für euch relevantesten Punkte. Hier nochmal eine kleine Liste aller Anpassungen: