Givet uttryckt intresse av ramverkt jag använt för att uttrycka visualisering från program-logiken berör jag det kort här inkl. ett par ramverk jag tittat på för att ev. komplettera befintlig lösning senare.
Schematisk representation av relationer mellan koncept
För att representera grafer finns en hel del med spontant högt elegant visuellt värde. När vi önskar uttrycka grafer med ett stort antal noder och en mängd relationer där former mer än detaljer är viktigt ger de vad som känns kraftfullt (jämför gärna med Riktad information - Navigation: Förstärkt i spatiell organisation).
Praktiskt användning för mig gör att jag hellre önskade stöd mycket nära hur vi ritar flödesdiagram och händelse-schema förhand på papper eller när vi gör det själva på dator. Genom att dator ska generera själv och med syftet att illustrera data där både detaljer och möjlighet att se detaljer man vill titta närmare på är enkelt bra utan risk att man försöker bli kreativ i stödet man ger mjukvaran.
Graph ML var det första jag hittade efter att tittat på några alternativ innan jag såg kunde fungera vettigt och passade aktuell plattform (WikiMedia) utan att heller även om en del förändring kan krävas lösa fast sig där (genererar PNG-bilder och skriver i Perl så viss perl-kod runt modul och kastande ut stödet för generering direkt mot WikiMedia och det fungear med annat: troligt finns något mer generellt för Perl) praktiskt men man ska vara klar över att många alternativ finns.
Exempel från tidigare:
Schematiskt eller foto-veklighet?
För komplex information är schematisk representation svårslagen för att illustrera data - under förutsättning att relationerna och nodernas existens är kritiskt. När formen av och motsvarande relativ förflyttning en nod är viktigt samtidigt som vi behöver ett sammanhang till det blir schematiska skisser inte lika självklart enkla: Att lösa visualisering av sådant schematiskt är vad hela legacy-"standarder" utvecklats för ex. UML-diagram och medan vi utan sådant lätt förstår - eller tycker oss förstå - mind maps och schematiska skisser kan de senare kräva en del inlärning av graf-systemets språk.
När vi går över till foto-lik representation av en situation från ex. motsvarande ett nyhetssammanhang gäller samma krav på mer av förståelse av språket. Särskilt gäller att vi sätter en bakgrund förvisso enkel men krävande en befintlig inlärning som förutsätts för inse hur den inverkar på skeendet och vad indikerat för noder (ex. personer) agerande mot den. Det mest självklara exemplet här är en geografisk karta som bakgrund men vi kan också illustrera med skillnaden i tolkning av händelser utspelande sig med fabrik resp. bondgård som bakgrund.
Praktiskt för mig kan jag se en brytpunkt i värde enkla konceptuella grafer att tolka när vi vill uttrycka discourse primärt och nästan det enda jag ser att det är värt besväret för entiteters förändring mot en bakgrund vi på en abstraktions nivå klarar att ha konstant genom detta.
Betänk ex. att vi rörande nyhetshändelse pågående under 2013 för Sydkinesiska havet önskar kunna visa hur olika fordon tillhörande diverse aktörer som upplever sig äga öar eller känner sig associerade till sådana aktörer rör sig.
Ska vi göra det med schematiska grafer krävs allra sämst en serie av schematiska grafer vilket blir svårare att tolka än endast en tabell över data tror jag. Arbetsamt att vandra över. Vi kan alternativt ändra grafer rörligt men troligtblir det nästan lika rörigt med fyrkanter eller motsvarande markerade flygplan, fregatt, spy drone, ubåt m.m. som rör sig runt. Ej utan betydelse här är ju på det att vi är vana att kunna förvänta att se denna form av information mot en vanliga karta som bakgrund.
En försvarlig mängd möjligheter för att arbeta just med kartor finns. Min erfarenhet av det området att ju större ambition vi har att kunna addera logik server-side fodrande stöd för att representera kartvärlden desto mer tid och problem bö budgeteras. Jag var fövisso mycket imponerad av det mesta jag mötte för wiki.openstreetmap.org men det är vekligen ett system minst sagt kostsamt i hårddisk och konfigurationen (om än mindre i programmerings logik eller oftast tror jag utveckling av själva kartorna i någnn mer avancerad mening). Medan ju mer man kan förutsätta befintligt stöd server-side (ex. användande någon av de många på nätet) desto mer direkt fungerande är det oavsett om vi använder OpenStreetMap, Bing Maps eller Google Maps.
Nackdelen i visualisering här är att dessa lösningar är att med mindre att vi arbetar i flygtornet på en flygplats eller är militärer och ju mer vi ska bygga vår representation från nyhetsanalys desto mindre nytta av kartans direkta xakthet har vi. Klassisk visualisering relaterat militär-konflikt eller stadier innan eller relaterat när entiteter försöker blåsa upp sig för att imponera är en schematisk representation av en enhet jfr pansarvagn, båt o.s.v. med kortare text och ett nummer inplacerat på kartan.
För att visualisera rörlig förändring här med utgångspunkt från det klassiska i stillbildens visualisering finns ju därför egentligen inget värde av någon direkt exakt karta i latitud och longitud. Vi kan ju för att bättre och mer förståligt förklara den förändring vi kan se lika gärna exempelvis tänka oss:
- En relativt kartans storlek onormalt stor båt i tre dimensioner som rör sig med en linje som skapas bakom den. Kanske ent av med ånga, svallvågar eller liknande för att roa kvinnorna, män och barn medan männen och kvinnorna kan meditera över den politiska dimensionen.
- Och vi kan släppa kravet på standardiserad karta och ex. sätta vinkel vettigt för att uttrycka något av rum eller fokusera på en mer relevant förändring.
Önskar vi göra 3D-rum i kart-bemärkelse vad som känns 1980 - 2000 filmer uttryckande scener med strategiska visualisering av kontinentala missiler som flyger eller verkligheter existerande i dataspel finns en flera färdiga grid-tydliga alternativ att utgå från i NASA's sedan flera år öppen källkod World Wind . En mängd exempel som java applets:
Och det mesta i övrigt:
Ett av de mindre visuella imponerande men väl planerings- / händelse-ordnings-relaterat är Search and Rescue:
<(å>
Men då är vi ändå låsta i exakthet och det hela fungerar föga om vi istället vill visualisera hur bongårdens djur rör sig timmen innan mjölkning. Applikation för mer ambitiösa anpassningar utnyttjande möjlighet ligger närmare ledningssystem med behov av direkt visualisering (men ESA ger ett ambitiöst exempel på hur det kan användas "affärsrelaterat" för att illustrera när objekt ska beställas EOLi “ESA’s Link to Earth Observation”).
Friare 3D-dimensionell visualisering
Min erfarenht av Javascript är både gediget grundläggande och praktiskt obefintlig. Jag kodade något i det redan när det kallades Livet Script och implementerade dom tidigare åren MD5, Gost och ett större antal algoritmer krpteringsrelaterade i Javascript. D.v.s. åren runt 1997 till 1998 ungefär (för integration i fakta-text kryptering). Därefter har jag gjort mycket mindre i det. Även om nu Javascript i praktiskt möjlighet ligger mycket längre ifrån applikationer mer intressanta i vad jag programmerar för närvande d.v.s. informationsanalys och prediktion från det i maskin intelligens har det när vi börjar tänka oss flexibla 3D-representationer av data vi tar från server-side styrkan av att lägga beräkningskostnad hos klienten.
Värdet av det bör vara tydligt särskilt för aktörer likt Google med en mängd användare som gör ganska olika saker krävande skapande visualiseringar resp. ganska små-aktörer med mer begränsade resurser att hantera variationer i besökare med. För affärssystem utvecklade anpassade för medelstora till stora företag kan man argumentera att det värdet är begränsat jämfört med ev. faktorer i övrigt inverkande utvecklings- resp. underhållskostnad.
När jag såg över alternativ att dynamiskt generera 3D-visualisering rimligt enkelt blev jag oavsett om vi tänker oss delvis klinet-baserade koncept med javascript eller inte mycket imponerad av . Förvånande snabbt jämfört med vad man är van vid.
Jag har inte mer än verifierat att det är funktionellt för att om eller när jag beslutar att införa detta stöd klara att kunna skapa acceptabla rum funktionella på den tid och med den inlärning och med aktuella plattformar skapa flexibla rums-representationer av situationer med en fri-uppsättning av schematiskt enkla, sillouetter eller närmare realistiska objekt med rörlig förändring. Det tycks för mig vara det bästa alternativ jag hittade när presentationen sker via webb och vi vill ha flexibilitt i anpassning till plattformen genererande kod men utan att ta licenskostnader.
Tråkigt nog men typiskt för hela domänen visualisera tenderar exempel vara konceptuellt närmare 1980-talts demokultur eller ett utkast till ett FPS-spel (varför man nu skulle göra dataspel i Javascript) snarare än en seriös applikation i visualisering av data eller resultat av affärslogik. Och i den mån de finns handlar det om att skapa visualisering med ramverket (av vad jag hittade). Det är väl också typiskt för mycket av den roll Javascript fick - det handlande mindre om att använda för att förklara teoretiska koncept i text genom möjlighet att pröva och experimentera och mer om presentationen utanför själva textens mening. En mängd sådana exempel nås direkt från sidan refererad innan.
Ett exempel jag upplever är praktiskt närmare vad vi kan tänka oss för att representera scener - kanske enkla objekt från en standarduppsättning på några tusen tillsammans med rörelser relativt varandra mot en konstant eller kontinuerligt förändrad bakgrund - nedan:
Nedan ett exempel mer ambitiöst för figurerna (många timmars arbete för att göra Obama, Markel, eller andra rörliga figurer med om nu inte bra fria verktyg för det finns för det också) med en robot från en Star wars film:
Minimal kod (lätt modifierat från ett intro-exempel) med tillhörande visualisering för att ge en känsla av att enskilda auto-genererade kod-stycken när vi tänker oss övrigt att anropa finns går att göra vettigt enkelt genom att placera ut saker (även om det givetvis blir mer kod när saker börjar flyttas runt eller kan flyttas och vridas av användaren). Även om trivialiteten i visuellt värde kan tyckas genererande kan det också ses som en god kontrast vara fokuserad på praktiskt värde verifiera att det klarar av att göra vad vi vill utan problem i känsliga domäner eller kännas för tids-dyrt att lära sig: en moraliserande kontrast till visuellt utstuderade saker jag mer ser ner på. Möjlighet att visualisera enligt detta paradigm är ev. önskvärt men vi önskar hålla det effektivt och absolut inte sitta och lära hela ramverket överdrivet.
var scene = new THREE.Scene();
var camera = new THREE.PerspectiveCamera(75, window.innerWidth/window.innerHeight, 0.1, 1000);
var renderer = new THREE.WebGLRenderer();
renderer.setSize(window.innerWidth, window.innerHeight);
document.body.appendChild(renderer.domElement);
var geometry = new THREE.CubeGeometry(1,0.5,1);
var material =
new THREE.MeshBasicMaterial(
{color: "darkcyan"});
var geometry = new THREE.CubeGeometry(3,1,-2);
var cube2 = new THREE.Mesh(geometry, material);
scene.add(cube2);
var geometry = new THREE.CubeGeometry(1,2,1);
var material =
new THREE.MeshBasicMaterial({color:
"darkcyan"});
var cube = new THREE.Mesh(geometry, material);
scene.add(cube);
camera.position.z = 5;
var lineGeometry = new THREE.Geometry();
lineGeometry.vertices.push
(
new THREE.Vector3(1,1,3),
new THREE.Vector3(1,1,7)
)
;
lineGeometry.computeLineDistances();
var lineMaterial =
new THREE.LineBasicMaterial( { color: "red" } );
var line = new THREE.Line( lineGeometry, lineMaterial );
scene.add(line);
Men en bild gjord av någon som kan ramverket bättre uttryckande vad det klarar kan vara lämpligt. Exemplet är från ett spel för webbläsaren - Kaiopua.
En god bit ovanför mitt exempel men också en bit nedanför det sista exemplet gäller att vi inte behöver se tidskostnad för användaren som väsentlig också när han växlar mellan sidor.
Program för att editera objekt vi önskar presentera finns några exempel på via Three.js - Wiki (under rubrik Tools) men tror jag (jag har inte använt det mer än att prövat det några gånger) mer ambitiösa Sketchup (instruktioner jag ej prövat här) kan också användas för att generera beskrivningar funktionella att stoppa in i vår scen och händelser.
När jag sökte information och exempel för three.js såg jag även några stycken tillsammans ofta refererade andra Javascript moduler för presentation kompletterande eller anpassade närmare andra områden (även om jag inte refererar dem här då jag inte prövade dem kan det därför vara värt att söka något närmare ett särskilt område ex. karter, grafer m.m.). För mer standardiserade applikationer finns ju också Google's färdiga koncept man ställer in i deras webbapplikationer eller skriver direkt i html:
Säkerhetsarkitektur: Kapsla in och skydda kod-genereringen från amoraliskt eller omoraliskt indata från klienten
Genererar vi bilder såväl som 3D-visualisering i Javascript från data som kan styras av användaren gäller oavsett vad diskuterat tidigare att indata måste kontrolleras. Bäst vad som endast kan påverka väldefinierade tillstånd där påverkan utanför dem inte är möjliga.
För bilder gäller ju att och inte minst för png aktuellt tidigare att det tillåter väldigt mycket. Bild presenterad på servern kan tänkas påverka där såväl som när den når klient.
Likartat problem gäller med genererad javascript även när vi utgår från att vi endast genererad väldefinierad javascript-kod som tänkt men då med ett potentiellt större fokus på klienten beroende av var och hur komponenter i visualisering skapas och lagras.
Särskilt för båda när vi skapar komponenter vi inkluderar och ev. representerar i bildfiler behöver rättigheter för webbserver ges någonstans d.v.s. i viss session och roll vara skrivbar. Kan bilden i den lokalisering refereras av klient såväl som att denne kan styra bildens innehåll hamnar vi lätt i problem genom att bilden vid den refereringen kan bygga vidare med annat den skapar upp i katalog och kanske rent av beroende på hur rättigheterna exakt ser ut köra igång dem utan annan åtgärd alls som process och därefter göra mer i andra kataloger eller med annan information.
Jag såg att detta var möjligt med ett flertal ramverk och stöd jag tittade på för att generera grafer, bilder m.m. från data. Och jag tror bättre än att hetsa upp sig över det för en eller flera där det är uppenbart utgår man från att det gäller allt och kapslar in detta rån användardata där endast vädefinierade tillstånd kan uttryckas vilka i sig ger data från hårdkodade regler till dessa moduler.
Den här typen av problem finns alltid och när de inte finns kommer de tillbaka mellan versioner i mer komplexa system. Vi kan jämföra med race onditions till filer där jag nyligen sparade Perl-kod i Windows och körde koden cirka fyra sekunder senare och gamla versionen kördes. Ge det några uppdateringar till oavsett korrigerat specifikt eller inte är det ett generiskt race condition som föga otroligt försvunnit av sig själv. När det har betydelse får man göra sällan mer än föga besvär och programmera defensivt: skapar vi från användar-data behöver vi filtrera och garantera endast väldefinierade tillstånd.
Dessutom även om indatat inte är moraliskt korrupt syftande till skada kan det ju vara amoraliskt. Fel utan mening eller syfte.
