migo315

Ich habe heute mal testweise ein wenig angebunden, um ein Gefühl zu bekommen. Und bin ehrlich gesagt bisher begeistert. Es fühlt sich "sauberer" an, weil man sich wirklich alles ziehen kann was man will ohne weiteren Belast. Bisher alles nur lokal. Aber ich denke das ich die nächste Tage die GraphQL Schnittstelle Online habe. Dann können wir ja einmal zusammen evaluieren, was zukünftig sinnvoller ist. Beide Schnittstellen (REST und GraphQL) will ich zwecks Wartung nicht behalten. Es wird sich dann Entscheiden müssen, auf welche wir setzen.

Ja, bitte ruhig was anderes nehmen. Coaster Cloud soll nur die Platform heißen. Alles andere sind eigenständige Produkte, die nur Daten daraus ziehen. Ich mache das selber auch nicht anders. Der Alexa Skill, den ich geschrieben habe, heißt deswegen "Park Guide": https://www.amazon.de/migo-Park-Guide/dp/B07WRGM736/ Vor 2 Wochen habe ich auch mal mit ner App rumgespielt. Das Projekt nannte ich "Themepark Companion". Wobei das wirklich nur zum "rumspielen" war. Ich hab gar nicht die Zeit neben Coaster Cloud noch irgendwelche andere Dinge zu entwickeln. Das überlasse ich dann euch ? Auch den Alexa Skill will ich eigentlich irgendwann mal abgegeben. Das nervt mich selber auch. Einmalig 99 $ wäre ich ja noch einverstanden. Aber jährlich finde ich da schon nervig. Zumindest für Anbieter for kostenlosen Apps könnte die da entgegegen kommen. Aber Apple eben ...

Habe leider kein Android mehr im Haus zum testen. Weißt du, wann ca die App komplett veröffentlichst? Ab dem Zeitpunkt darf ja defintiv kein Breaking Change mehr in der API vorkommen.

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.