migo315

Die ganze Wartezeit Prognose Diskussion bringt mich auf eine Idee. Theoretisch würde ein Kalender, bei dem sämtliche Ferienzeiten und Feiertage relevanter Länder für die Öffnungstage der Parks ja schon viel helfen, um das Risiko eines vollen Parks abzuwägen. Oder gibt es sowas schon?

In meinen Fall vor 2 Wochen hatte ich selber die deutschen Ferienzeiten schon auf denn Schirm gehabt, aber nicht die unserer Nachbarländer.

Wenn jemand spontan noch eine coole Idee hat um den Reiz etwas zu pflegen zu erhöhen - nur her damit

Die Tage möchte ich noch den Ersteller und letzten Bearbeiter prominent am Park / Attraktion anzeigen.

Ansonsten könnte ich mir vorstellen, dass Nutzer die Sachen pflegen, die Möglichkeit erhalten ihr eigenes Projekt (zb. seinen Blog) auf coaster-platform.org vorzustellen. Gibt es Blogger oder Leute mit eigenen Projekten hier? Und wenn ja, wäre das ein Anreiz für euch?

Bisher waren wir mit dem Essen immer zufrieden. Letzte Woche Donnerstag allerdings gab dann doch nen Negativen Erlebnis. Zweimal Kindermenü mit Nuggets, einmal 10er Nuggest - und alle samt gefroren. Nicht Kalt oder Lauwarm - sondern wirklich steinhart gefroren. Wie dies passieren konnte, konnte sich keiner erklären.

Ich als Vater von zwei Paw Patrol verrückten Kindern kann nur sagen: Mega! Leider befürchte ich, dass Adventure Bay ab Eröffnung für den Rest dieses Jahr extrem voll sein wird.

Am 12.4.2019 um 07:25 schrieb Akasha:

Nun hab ich aber mal eine Frage - hat auch mit Wartezeiten zu tun-  an die Leute die an vollen Tagen auf dem Mystery Parkplatz parken. Wie lange ist die Schlange an den Parkticketsautomaten und wie lange braucht man dann wirklich um vom Parkplatz runter zu kommen bis zur Autobahn,. 

Das kann man auch vorher holen. Waren Donnerstag dort und haben es so gemacht

Hier mal ein paar News.

- Die "Detaillisten" für Attraktionen und Parks sehen mittlerweile recht gut (siehe Anhang). Man kann beliebig zwischen den Listentypen wechseln.

- "Spielplatz (innen)" und "Spielplatz (außen)" sind zusammengefügt worden (zu "Spielplatz"). Ob es Indoor / Outdoor ist kann man ja mittlerweile in den technischen Daten vermerken (das gabs zu Anfang noch nicht).

Und was größeres:

Bei Datumsangaben sind nun auch Formate ohne Tag und ohne Monat möglich. Also bei "Eröffnung" kann nun auch einfach ein Jahr oder ein Jahr und Monat angegeben werden. Es komplettes Datum ist nicht mehr notwendig. Allerdings ist das eine "massive" Änderung. Bei der Eingabe des Datums muss nun ein Format beachtet werden. Folgende Daten sind nun erlaubt "1989", "1989-05" oder "1989-05-31". Sowas wie "31.5.1989" geht zum Beispiel nicht. Auch Browser Hilfen zur Datumnsauswahl sind nicht deswegen nicht mehr vorhanden (die beruhen eben darauf, dass man ein komplettes Datum auswählt). Ich werde aber zeitnah Hilfen bereitstellen, damit dies einfacher ist. So sieht dies dann aus, wenn man nur ein Jahr angibt https://coaster-platform.org/parks/phantasialand/attractions/f-l-y  oder eben ein Jahr mit Monat https://coaster-platform.org/parks/movie-park-germany/attractions/bandit

Das hat leider auch ein Breaking Change in der API zur folge, weil die API immer ein kompletten Zeitstempel zurück gab. Aber da nun auch "unvollständige" Daten gepflegt werden können, kann kein Zeitstempel mehr zurück gegeben werden. Die Dokumenation zur API folgt noch im Lauf des Tages.

In der Attraktionsliste (sowohl die allgemeine als auch bei Parks) kann man nun den List Typen wählen. Dafür gibt es zwei Icons, die wahlweise das bisherige "Bilder-Grid" Anzeigen oder eine Liste ohne Bilder aber mit mehr Informationen.

Die neue Liste sieht noch nicht so fit aus - da werde ich noch was ändern und vermutlich auch noch mehr Informationen anzeigen. Aber die Grundidee, das man zwischen Listentypen wählen kann, wollte ich trotzdem schonmal veröffentlichen

Hier, falls man nicht sofort erkennt was ich meine:

Heute gibt dann doch mal mehr neues "zum zeigen":

- Ein Fehler bei der Ausgabe von "Ja / Nein" Feldern wurde behoben (es wurde immer nur das grünr Häkchen angezeigt)

- Folgende Elemente sind hinzugekommen: In-Line Twist, Sidewinder, Batwing, Cobra Roll, Double Down, Double Up, Non Inverting Loop, Wing Over Drop, Top Hat, Roll-Over, Pretzel Loop, Cable Lift

- Das Feld "Sitzart" heißt jetzt "Rückhaltesystem" und hat zwei weitere Auswählmöglichkeiten: "Westenbügel" und "keins"

- Bei Attraktionslisten kann man nun rechts nach dem Eröffnungsjahr filtern (wenn man zb. "2020" eingibt erscheint FLY, bei "2016" erscheint zb. Taron)

- Eine erste "Alpha"-Version einer Javascript Library zur Abfrage von Daten (für die Entwickler unter euch) liegt nun auf NPM: https://www.npmjs.com/package/coaster-platform.js

Vielen Dank nochmal an alle.

Über einen Monat habe ich mittlerweile nichts zum Projekt geschrieben - in den vergangenen 30 Tagen habe aber dennoch fleißig dran gearbeitet:

Auszug aus Github:

Zitat

Excluding merges, 1 author has pushed 49 commits to master and 49 commits to all branches. On master, 89 files have changed and there have been 3,133 additions and 2,565 deletions.

Also 89 Dateien bearbeitet und an ca. 5.000 Zeilen Code verändert. Und das Resultat ... seht ihr nicht. 

Sogut wie alles was ich gemacht habe, war rein technischer Natur. Das einzige Änderungen, die vll auffalen:

- "Commits" habe ich in "Logs" umbenannt, da dies für Verwirrung in Gesprächen gesorgt hat

- Der Playground für die API wurde ausgelagert

- Über die API können nun auch die Logs abgefragt werden

Stück für Stück soll es in den nächsten Wochen zu diesem Ziel kommen:

- Parks / Attraktionen können auch über die API aktualisiert und angelegt werden ( @Tommy ich glaub das hattest du auch mal angefragt?)

- Benutzerhandling geht komplett über die API

- Das komplette Frontend ist eine reine Javascript Anwendung welches zu 100% auf die API zurückgreift.

Ansonsten bin ich weiterhin für weitere Ideen / Vorschläge zum Projekt offen

Am 7.3.2019 um 21:59 schrieb ImagineerTim:

Ja die Krosse Krabbe wäre natürlich geil! Spongebob ist einfach die geilste Lizens die der Park hatte mit Ice Age.

Naa - Paw Patrol! Das sieht man schon an den Autogrammplätzen, wenn man die Schlangen vergleicht und spätestens noch dieses Jahr, wenn Adventure Bay fertig ist und jedes Kind aus ganz Deutschland dort hin will (meine Söhne inklusive). Mit Paw Patrol hat der MP eine Punktlandung gemacht.

Spongebob wird mehr von den älteren gesehen als von Kindern

(und ja, auch ich kenne wohl mehr Spongebob Folgen als meine Söhne zusammen :-D)

Am 26.4.2016 um 20:37 schrieb JayPeck:

Dann möchte ich euch auch ein Wallpaper schenken!

Dieses Foto habe ich während des Wintertraum 2015 / 2016 gemacht.

 

Mega geil! Wurde soeben mein neuer Wallpaper auf mein (Arbeits)-Laptop!

Heute mehrere kleinigkeiten zu vermelden:

- Die Felder "Themenbereich" und "Thema" waren bisher immer Textfelder. Ich hatte damals nicht dran gedacht, dass man mehrere Werte reinschreiben könnte. Diese Felder sind nun "Tags" Felder, wodurch die Werte getrennt gespeichert werden (siehe Bild section.png).

- Bei der Attraktionsliste innerhalb der Parks kann man nun nach dem Themenbereich filtern (siehe facet.png).

- Fehler im Javascript bei Park / Attraktionsbearbeitung behoben

- Die Coaster API erlaubt nun auch die Zugriff via Javascript von anderen Seiten

Sollten sich hier Javascript Entwickler befinden: Auf CodeSandbox habe ich ein jQuery Beispiel gebaut um Daten abzufragen. https://codesandbox.io/s/l91ypr26z

Die API wurde soeben aktualisiert.

Beim Punkt mit den Filtern muss ich ein wenig zurück rudern. Nachfolgend einmal nochmal die Möglichkeiten:

1. doppelt "filter="

/api/parks?filter=types.name:"themepark"&filter=types.name:"waterpark" 

Hier wird "filter" ersetzt, bevor ich überhaupt dran komme. Daher hat sich hier nichts geändert.

2. doppelt "filter[]="

/api/parks?filter[]=types.name:"themepark"&filter[]=types.name:"waterpark"

Das verarbeitet die API prinzipiell richtig. Nur wird dann eine "UND" Verknüpfung gemacht. Also werden nur Parks gefunden, die sowohl als Themepark und Waterpark gekennzeichnet sind. Ob man nun eine UND oder eine ODER Verknüpfung erwartet ist dann wohl Geschmackssache.

3. Search query

/api/parks?filter=types.name:"themepark" OR types.name:"waterpark"
/api/parks?filter[]=types.name:"themepark" OR types.name:"waterpark"

Beides war schon vorher möglich. Hier wird eine Query gebaut die 1:1 an die Such Engine geht. Da kann man dann eben "OR" oder "AND" nutzen.

4. any / all Methode

/api/parks?filter=any(types.name,themepark,waterpark)
/api/parks?filter=all(types.name,themepark,waterpark)

Die habe ich soeben neu gebaut und soll eine vereinfachung aus den Punkt 3 sein. Bei "any" muss nur eines der Begriffe aus types.name zutreffen (also eine OR Verknüpfung). Bei "all" müssen alle vorhanden sein (AND Verknüpfung).

Du kannst dein Filter Problem also mit der Search Query (Punkt 3) oder mit der neuen "any" Methode lösen. Des Weiteren werden bei Parks unter "attractions" nun die Anzahl der Attraktionen mitgegeben.

Ich werde übers Wochende die API Dokumentation mal stark zu verbessern. Hilft dir das denn soweit weiter?

vor 55 Minuten schrieb Tommy:

Wenn ich bei "Parks" auf beide Kategorien filtere, wird immer nur die letzte berücksichtigt, die mitgegeben wird. Wenn man beide Kategorien als Filter auswählt, sollten aber alle Ergebnisse logischerweise enthalten sein.

Ah guter Punkt. Ich vermute mal, du machst es so: ?filter=types.name:"themepark"&filter=types.name:"waterpark" oder ?filter[]=types.name:"themepark"&filter[]=types.name:"waterpark"

Dann ersetzt das letzte das vorherige. Ist ein Bug. Das passe ich an.

Folgende Syntax funktioniert schon out of the box: ?filter=types.name:"themepark" OR types.name:"waterpark" bzw. ?filter[]=types.name:"themepark" OR types.name:"waterpark"

vor einer Stunde schrieb Tommy:

Was noch schöne wäre: bei den Parks ein Integer-Feld mitgeben, dass die Anzahl der dem Park zugeordneten Attraktionen zurück gibt.

 Wird asap kommen. Gute Idee.

vor einer Stunde schrieb Tommy:

Und die API ist (bisher) auch wirklich sehr performant.

Noch ist ja kein Traffic drauf. Das Projekt ist ja quasi nur hier veröffentlicht. Aber ich versuche tatsächlich auch die API so performant wie möglich zu halten. Wird sich dann Zeigen je mehr Daten und Traffic reinkommen, wie sich das entwickelt. Die Filterung läuft extra über eine Search Engine anstatt über die Datenbank. Und durch Hosting bei heroku.com kann sehr schnell skaliert werden, wenn plötzlich mal die Performance einbricht.

Danke fürs Feedback!

Am 14.2.2019 um 08:48 schrieb flofen:

Hab mir das jetzt endlich mal eingerichtet. Und klappt sogar alles wie es soll

Danke sehr. 

Ahh, das ist selbstverständlich. Ich versuche ja was faires für alle rauszuholen. Soeben ging die Mail für die neuen Nutzungsbedingungen raus. Ab den 1. März ist diese dann "gültig".

Solltet euch da noch was auffalen gebt ruhig bescheid.

Ansonsten gebt es kaum berichtbares. Paar technische Themen wie eine Sitemap sind raus. In den nächsten Tagen werde ich wohl wieder mehr Richtung Bearbeitung und Anzeige von Parks / Attraktionen ein paar Optimierungen raushauen.

Als richtiger "Go Live" Termin peile ich den 18. März an.

@flofen

Neben Benutzername und Vor- und Nachname kann jetzt auch eine dritte Option ausgewählt werden: Domain

Dann wird deine Domain als Name angezeigt. Vielleicht für dich interessanter? Der Link zu deiner Domain wird ja sowieso schon gesetzt.

Soeben die neusten Änderungen hochgeladen. Sogut wie alles ist aber nur Code Optimierung. Sollte daher für euch alles so sein wie bisher. Sofern euch aber vor allem beim Hochladen, Voten, Anzeigen oder Löschen von Bildern ein Fehler auffält, gibt ruhig bescheid. Die ganzen Optimierungen wurden in den Bereich gemacht.

Eine kleine für euch relevante Änderung gibt es aber dennoch: Es können nur noch 6 Bilder pro Park / Attraktion hochgeladen werden. In Zukunft könnte die Zahl noch nach oben korrigiert werden aber aktuell setzen wir diese auf 6. Das hat mehrere Gründe: Zum einen nützt uns es nichts, wenn wir 20 Bilder von Taron haben und andere Attraktionen bleiben auf der Strecke. Zudem kosten gerade die Bilder recht viel "Traffic" - je mehr desto mehr Traffic und Speicherplatz. Für euch hat dies sogar Vorteile - zumindest für die, die die Platform zu Anfang unterstützen. Die, die jetzt anfangen Bilder reinzustellen, können dadurch sicher sein, dass die Bilder in Zukunft nicht untergehen.

Am 8.2.2019 um 10:21 schrieb flofen:

Guten Morgen,

 

Sry, diese Woche war mal wieder randvoll. Ich schaue mir das am Wochenende mal in Ruhe an. 

Mach dir keinen Stress. Es drängt nicht

In den Profil Einstellungen ("Mein Account" => "Bearbeiten") kann man nun zwei neue Werte setzen:

1. "Copyright Name": Hier kann man einstellen, ob der Name aus deinem Account oder dein Benutzername an den Bildern angezeigt werden sollen. Standard ist "Benutzername".

2. "Copyright Url": Hier kann man eine URL angeben, die beim Klick auf deinen Copyright Hinweis gesetzt wird. Wenn man keine URL angibt, wird die URL zu deinem Profil genommen (wie bisher). Wenn du eine URL angibst, wird stattdessen diese verwendet. Ideal um auf seinen eigenen Blog oder Instagramm Profil zu verweisen.

Die Einstellungen können jederzeit geändert werden. In der API wird bei jedem Bild ebenfalls der ausgewählte Name und die URL mitgegeben.

@flofen, möchtest du das einmal testen / sagen was du davon hälst?

Ah cool. Ich werde morgen Abend das mal entwickeln zwecks Testing.

Hey,

die letzten Tagen ist kaum was passiert, da ich mit meinen beiden Söhnen mehr unternommen habe.

Es gibt nun auf der Startseite eine "Suggest Box". Ein Suchfeld um einen Park oder Attraktion direkt zu suchen. Einfach tippen (zb. "Taron") und kurz warten.

Ansonsten gab es mehr technische Änderungen, die im Hintergrund nur relevant sind.

Eine Sache gibt es aber noch: Bilder

Dieses Thema habe ich die letzten Tagen sehr lange und immer wieder mit Kollegen diskutiert. Die letzte Idee war ja, dass der Author selbst entscheidet welche Lizenz er anwendet (keine oder CC). Vom Prinzip her kann ich eigentlich damit gut leben, aber wir befürchten, dass diese Lösung für die Authoren eher unpraktisch ist. Selbst wenn wir auf der Webseite und in der API Kennzeichnen, ob das Bild unter der CC liegt oder nicht, werden vermutlich andere das nicht verstehen oder übersehen und ggfs. dann Bilder verwenden, die nicht unter der CC stehen. Das ist dann für Authoren noch ärgerlicher. Daher kommt nun doch eher die Idee, alle Bilder unter die CC zu nehmen. Dann ist jedem Author sofort klar, worauf er sich einlässt. Entschieden ist dies aber noch nicht - mir fällt die Entscheidung echt schwer. Einerseits möchte ich eine einfache und klare Regulung für alle Daten - andererseits kann ich die Stellung von @flofen und vermutlich auch von dem ein oder anderen vollkommen verstehen! Vor allem wenn man noch eigene Projekte hat, wo man die Bilder verwendet.

Um jetzt keine Unruhe reinzubringen, hier aber nochmal kurz nen Q&A zwecks Bilder:

Unter welcher Lizenz stehen die Bilder aktuell?

Aktuell stehen die Bilder unter keiner Lizenz. Der Hochlader ist der Author und Urheber und hat Coaster-Platform lediglich das Recht eingräumt die Bilder anzuzeigen. Das beduetet, keiner darf die Bilder kopieren / verwenden.

Unter welcher Lizenz könnten die Bilder zukünftig stehen?

Alle Textdaten stehen unter der CC-BY-ND. Daher liegt es nahe, auch die Bilder unter dieser Lizenz zu stellen. Die CC-BY-ND erlaubt es jeden (zb. App oder Blogs), das hochgeladene Bild in einem eigenen Projekt zu verwenden, sofern am Bild der Author (also dein Name) + Link genannt wird. Es muss also immer dein Name am Bild als Urheber stehen - egal in welcher App oder Webseite (dafür steht das "BY").  Außerdem darf das Bild nicht bearbeitet werden -  zb. keine Person reineditieren (dafür steht das "ND"). Ihr bleibt selbstverständlich weiterhin Author und Urheber. Die CC Lizenzen wird zb. auch i.d.R. für Wikipedia Bilder verwendet. Im Klartext heißt es, dass jeder das Bild verwenden kann solang er das Bild nicht verändert und dich als Author benennt.

Darf man die Lizenz für die bereits hochgeladenen Bildern ändern?

Nein - nicht ohne eure Erlaubnis. Ich kann nicht die Bedingungen einfach so ändern, die ihr damals eingewillt habt. Selbst wenn ihr morgen oder die nächsten Tage Bilder hochlädt, sind diese wie bisher ohne Lizenz. Sobald eine Entscheidung über die Lizenz gefallen ist, werden die Bedingungen angepasst. Diese müsst ihr dann zustimmen, sofern ihr neue Daten hochladen wollt. Zudem könnt ihr dann mit einem Klick entscheiden, ob ihr eure bereits hochgeladenen Bilder unter die neuen Bedingungen stellt oder nicht. Bei letzteres würden dann ggfs. die Bilder aus der Platform entfernt werden.

Und wann passiert das alles?

Bisher ist nichts entschieden. Es wird nur "laut drüber nachgedacht". Sobald es feststeht, werden alle Benutzer per eMail informiert.

@flofen

Gibt es für dich ggfs. eine Möglichkeit, was sowas wie die CC attraktiver machen könnte? Ich denke da zum Beispiel an die Möglichkeit, dass jeder Benutzer für sich selbst den Copyright Hinweis anpassen kann. Also den Hinweis, der auf coaster-platform.org unter dem Bild stehen wird SOWIESO den Hinweis, den jeder einbinden muss wenn er eines deiner Bilder verwendet. Beispiel:

Statt sowas mit Username:

© by max_mustermann / coaster-platform.org

oder mit Namen

© by Max Mustermann / coaster-platform.org

kann jeder den Hinweis auch für seine Bilder ändern, dass es auf das eigene Projekt zeigt:

© by Max Mustermann / mustermann-blog.com

Dann wäre es zwar CC - aber dein eigenes Projekt / Instagramm o.ä. wird immer unter all deinen Bilder stehen. Wäre ja eine gute Werbung

Heute gabs Anpassungen an der API. Im Hintergrund wird auch für die "normale" Ansicht die API verwendet. Wenn euch daher Fehler auffalen, vorallem bei der Filterung für die Sicherheitsbestimmungen oder ähnliches, dann ruhig bitte melden.

Ansonsten habe ich ein paar neue Filter für Attraktionen eingefügt (FastPass, Single Rider, Standort, Barrierefrei) und den Filter für Elemente rausgenommen. Letzteres wird wieder kommen, aber dann auf einer Metrik Seite um dies noch genauer umsetzen zu können.

vor 1 Stunde schrieb Kleator:

Habe das direkt mal an "Pirates in Batavia" getestet. Hierbei ist mir aufgefallen, dass wenn man nachträglich andere Sachen an der Attracktion ändert der Status klamm und heimlich wieder auf "in Betrieb" gesetzt wird.

Kurz und knapp eben aus der Mittagspause: Habe ich soeben gefixed. Magst du nochmal schauen / testen?

vor 22 Minuten schrieb Tommy:

Das ist definitiv valides Json:

Sorry, hatte mich beim Beispiel oben von dir scheinbar verguckt. Ich bin davon ausgegangen, du möchtest die Array Syntax und dennoch mit Keys arbeiten. Ein Array mit Objekten ist natürlich valide und stimme dir zu, dass es sauberer aussieht.  Ich habs als Punkt bereits aufgenommen und wird die Tage angepasst.

vor 26 Minuten schrieb Tommy:

Wenn der Inhaber dagegen ist, soll er seine Bilder entfernen. Aber ohne Urls in den Bilddaten ist dieser Bereich sinnfrei. Daher angeben oder die Bilder bis zur Klärung komplett rausschmeißen - was noch weniger Sinn macht. 

Schwieriges Thema. Einerseits möchte ich natürlich, dass coole Bilder gepflegt werden. Andererseits kann eine CC Lizenz für den ein oder anderen ein Grund sein, keine Bilder zu pflegen. Ich versuch da kurzfristig mal eine Lösung zu finden.

Danke fürs Feedback zur API

// Update

Ab jetzt kann der Status einer Attraktion gepflegt werden. Alle bisher gepflegten Attraktionen erhalten den Status "In Betrieb". Zudem kann nach den Status gefiltert werden.

vor 11 Stunden schrieb flofen:

Wäre super, wenn das möglich wäre.

Ich werde mir mal eine Lösung überlegen.

vor 9 Stunden schrieb jen_f13:

Mir ist gerade noch aufgefallen, dass es vielleicht übersichtlicher wäre die Parkfläche in Hektar anzuzeigen statt in m². 

Argh, das hatte ich mir sogar mal vorgenommen. Aber scheinbar ging der Punkt unter. Habe ich jetzt als Punkt aufgeschrieben und wird definitv die Tage angegangen.

vor 23 Minuten schrieb Tommy:

Wenn man die Attraktionen abfragt, bekommt man auch das Attribut park zurück:

Interessanter Punkt, bei dem ich selbst schon in ein Konflikt kam. Eigentlich will ich in der Attraction Resource keine Park Sachen, weil das zuviel frisst. Wenn ich mir 96 Attraktionen ausgeben lassen ist das ein overhead für jede Attraktion nochmal den Park nachzuladen. Eine Zeitlang gab es sogar Attribut "park" auch nicht. Zum Filtern von Attraktionen nach Parks war dann zumindest die ID aber irgenwann notwendig. Und daraus entstand, dass ich zumindest ein paar wenige Daten zum Park ausgebe.

Ich hätte es lieber, dass einer explizit die Park Resource anfragt wenn er was vom Park wissen möchte. Damit es vielleicht ein wenig klarar Strukturiert ist, kann ich mir vorstellen den Park Attribut wirklich nur auf die ID und ggfs. ein Link zur Park Resource zu beschränken. Was meinst du?

vor 28 Minuten schrieb Tommy:

Des Weiteren gibst Du häufiger Werte als Objekte zurück (zum Beispiel attributes), die wenn sie leer sind, aber ein leeres Array zurückgeben. Diese Werte sollen besser generell ein Array sein:

Ich verstehe was du meinst. Allerdings kennt JSON kein Array mit Keys. Es gibt nur die array Syntax ["foo", "bar"] oder die objekt Syntax {"field1": "foo", "field2": "bar"}. Diese Syntax ist invalide: [field1: 'foo', field2: 'bar']. Man könnte die Keys aus den Attributen entfernen, was allerdings dazuführt, dass man durch alle Attribute iterieren muss um an ein gesuchtes Attribut zu kommen. Aber hier ein array anstatt ein objekt zurück zu geben hört sich dennoch richtiger an - trotz des Handicap. Werd das dann anpassen. Auch an diversen anderen Stelle. Danke für den Hinweis, wäre mir gar nicht aufgefallen

vor 52 Minuten schrieb Tommy:

Bilder sollten außerdem eine Url (oder ein Objekt aus mehreren Urls) zurückgeben:

Das ist aktuell tatsächlich by design. Weil die Bilder nicht unter der CC Lizenz stehen und somit von niemanden verwendet werden dürfen, wird keine konkrete URL ausgegeben. Das überhaupt ein paar Informationen zu den Bilder ausgegeben werden, liegt nur schlicht daran, weil wir uns selbst an die API bedienen und diese Information brauchen. Ggfs. kann aber bald jeder Benutzer für sich selbst entscheiden, ob er seine Bilder unter die CC Lizenz stellt (siehe letzte Beiträge hier) - dann wird auch eine URL ausgegeben.