In the field of physics, a trajectory is defined as the path that an object in motion follows through space. In process mining, trajectories are also studied, however, mostly in a control-flow sense. In this work, we are interested in understanding process trajectories in a physical sense, i.e., considering not only the control-flow but also the actual (physical) path that instances followed. To this aim, we present a tool which can visualize directly-follows graphs (DFGs) in a 3-dimensional space, where the placement of the DFG nodes in the space reflects the actual locations of the underlying activities in the real world (e.g., based on geo-location data from the event log). This can be useful for understanding the true movement of process instances in a geospatial manner, for example, where exactly employees are moving within the company building. We describe our browser-based tool and provide pointers for its maturity.
A central objective in process discovery is to understand the trajectories of process instances
within organizations. For example, in [
When speaking of such trajectories, these are often referred to in a control-flow sense. However, there might well be use-cases where one needs to find out not only how the instances move, but also where the instances are moving (physically). For example, in a hospital process, one may need to check whether wheelchair patients are forced to cover long distances or inaccessible stairways, or whether there are certain locations in the hospital that can become too overcrowded. This is referred to as geospatial information.
In this work, we present a tool that can visualize activities in a 3-dimensional space under a consideration of activity-location data (e.g., stemming from event logs). In this way, the , , positions of activities within the visualization reflect the actual positions of the underlying activities in the real world. Intuitively, we say that such a form of visualization is geo-aware.
An example of such a geo-aware visualization taken from our tool is shown in Figure 1.
The use-cases for such geospatial analytics capabilities are many, for example, understanding
process movements within companies or hospitals [
In the following, we introduce our approach and tool. We will begin with a small background on 3D visualizations, geo-awareness, and our contributions w.r.t. related works.
2.1. 3D Visualizations, Geo-Awareness
The Oxford dictionary defines 3D as “having, or appearing to have, length, width and depth" [
A prominent example of 3D visualization technology is WebGL [
In the scope of 3D process visualizations, we add the constraint that the object placement in the 3-dimensional space should be based on the real-life locations on the objects, leading to, what we call, geo-aware visualizations. We define geo-awareness as follows: Consider a directly follows graph = (, ); where is the set of activities, and ⊆ × . Assuming every underlying activity can be pin-pointed to a geographic location in the real world, we assign this location to an activity ∈ via the real-world latitude, longitude and height above sea-level, denoted .lat , .lon and .h. Furthermore, for any representation of (in 3-dimensional space), every node ∈ has an , and position in this space, denoted ., . and .. We now say that the representation of is geo-aware, if it satisfies the following property: Geo-Awareness. Let = (, ) be a directed graph and be a representation of . Then, for all pairs of nodes , ′ ∈ : • if .lat > ′.lat then .x > ′.x • if .lon > ′.lon then .z > ′.z • if .h > ′.h then .y > ′.y In other words, a representation is geo-aware if the placement of nodes reflects the location of the activities in the real world (and their locations relative to each other). Figure 2 (a) shows a DFG produced by the PM4PY library. Clearly, such a representation is not geo-aware. For this work (b), novel graph drawing techniques are presented to transform geo-locations into x,y,z coordinates. The novelty w.r.t. other “3D" tools is also cl(aa) rObijfieecdt-CeinntricFBPiMgNumroedel 2sho(wcin)g,alwl6 hich shows the Celonis Process Sphere. The Process Sphere is “3D", buotbtojenscetolteyctptesgsubaensedotsal-olf1ao6wbajcetcaitvsirttieyepse,asnadantsdheatcinthitveietrifeascpe lac e(bm)Obejenct-tCeontrfic BtPhMeN model after nodA.eBersti, S. ivansZelstsandtDi.Slchlusterbased on control-flow and doesSoftwanreImopactts17 r(20e23)fle100c556t the(cronetinagle-ncwytaobler)lodn thae cleftt-ihvanidtsyidelocatsieolecntinsga.pthprlieceatoiobnjesc,tatnydpoesffe(arps)plicants, (a) Im(aa) Dgireectly-Fol ows Graph (DFG) (cf. line 20 of Code ListiGng1): Not (b) Process Tree (cf. line 21 of CooderLkistin:g 13)D and ge(co)A-naalyzinag rthee time(bce)tween an applicant applying forbayvacancy and actually being hired. In total of a simple DF (b) This w w Process Sphere Celonis: 3D, geo-aware (node placement (node positions are ba8s9eapdpliocannts werebheirtewbde(euonftaapntpoltoyainltogfga2ne8d8oaacp-cpeapliwctianngatsarnaepopffl(yenirnwgoa9sd168e4tidmpaeylssa). Tchee-average time based on control-flow). the geographical poFsigiutrieo9.nEsxa)m.ple results pmrodeuncetd ubsainsgeCedlonoisnProccoessnStprheorel-[9flo]. wTh)e.screenshots are not intended to be readable but illustrate the capabilities of Process Sphere. The different colors correspond Figure 2: Clarificatio(cn)Accepting Petri net (cf. line w22of Code Listning e1) ss (images (a) and t(octh)e tsiaxokbejecnttyfpreso. m PM4PY, and Celonis, resp.). of geo-a are 5.3. Example Using OC-PM and Process Sphere
To illustrate the techniques just described, we use a small example and show discov2.2. Related Wor(d) kBPMN aDiangram d(cf. line M23of Coode tListiing v1) ation tehiraoenvdse,ps1ri3xo5coeobsffsjeermcst,ot1dy4pe0lesvsainchaabnvociitnehsg,O2th0Ce-rPefcoMrluloiatwnerdisn,Cgaennldoun6mismbPaernrosacgoeefsrsso.bSTpjehhceetrsre:ea.2r8Ien81tah6pipaslcistcmiavnaittlisle,ds9a(1it.6ae.as,peetpv,leiwcnaeto ti types): open vacancy, submit application, assign recruiter, first screening, check references, assign To better show t hFig. e1. Viscualizationnsof tthrepriocbess muodels discoovernedinsCode oListifng 1.our work, we dvaecafinncye, sesnodrmejecetionp,crloosepvaecarntcyi efosrneiwnaptphlicaetionfso,clhlaongwemiannagge.r, consult manager, Fdmiirfeasrnf(cF2ppocteoe.eo1frsrrr.ys.f,aPi3oFnlniMm.rnispmgts4oVteat.dPaair“ntsfne1hynucolc(cear2aeoef,mla)oi,fizs)cfra,paefmDtn.strehppiscacFoeretlnioirdAgssdpcupi."mwevoam3sett-stt.vre(ersiCcrdtesafrnouo.eo(snavceFlshiipsii2snigazrdua(.ereeactd3vrlpfkDi.(ecvzuFbnaiFsi)stgtii)ruhing.doa[g.fa1n4loit1s6Pzaos(]aMh.bfftaooaMi)4or)lwcoPa,onoiycprnawe:r(ucgoonrcdcthvcfivoe.reepaessrvFrtacs,diiieitsnodgleumygue.a-csrsifl3nPiossdy(ielianaiotfod)grfna)iweewrtotanseaerreecnnrtgtoteidtrsfnsataepeipc((trmcchthonsffes--.,.a3glDifvFp3nosail.girnrec.Iiopaomo3vtruia(odpovsctcan)iseo)csesngg,tcesiGstlPo,cousMvorcaeesemin4durhdPpavsaoyrtidvee’eseeashw.r-peudivnoseleesatcMeiddioisnniittwotzoi,anaoilinlnofasdiactstlcauhotvsthopdaarttisrnsiittbm.gauoSeihnizuledardcathnidluoetiivphnvioc.esnsanlurrsaaePel.iMfzy(oOaa4trtrP3iogoeypan.ntsd2iDIidmnzaaritzte-ieiiorni)mmmdnwgssppaooaitcrfttriomaeaohnnpsstt-raektnsaswrioeonaraklslwoseigntehsoes-.oaSmwoeawrfeoer(dmGeAfinoef).laaBy2ueDtr-osv.feTcrhosiueosrnese, of GvFiisgu.Aa1li(zca)t)i,o(nansG,dvaBrPioMuNs omthoedrevlsisu(cafl.izFait)gio.n,1s(adr)e).imBepsliedmeselnptoerodciegnssPMm4oPduyel.s tTohis section Aexplorwesthe impact oof uPM4tPy, its role in academeicnsion). Second, the work at hand takes a layers are however mostly a3gnostic of each other. As a result, edges drawn on one layer cannot consider the map semantics on a lower background layer, which leads to problems such that edges go “through walls". We argue that—in order to truly understand trajectories— edges should also reflect the actual geographic paths in the real-world. Therefore, our tool works in a single (3D) environment, which allows to apply path-finding algorithms in the 3D world for drawing edges. This results in edges correctly following the maps semantics, e.g., edges going around corners instead of “through" walls. We refer to this property as path-finding ( PF).
Based on the identified properties, the work at hand compares to other related works for geospatial process visualizations as shown in Table 1. As can be seen, this work is the first to satisfy 3D geo-awarness and path finding. 1 We continue to present our approach.
Our browser-based tool allows to create geo-aware process visualizations. It was built using
Three.js. The tool and a screencast can be found at http://gapm.process-science.uni-koblenz.de.
1We acknowledge that [
Tool
Tiramisù [
GA x
GA(2D) x x x x
PF n/a n/a x
The architecture of the tool is shown in Figure 3. The tool takes as input a DFG file (directly follows graph), a mapping file (mapping activities to geo-locations), and (optionally) a 3D map (e.g., created in Blender). The tool is equipped with an interactive editor to create the mapping ifle in a user-friendly manner. An interactive 3D visualization will then be created based on the input files, by extracting node/edge information from the DFG, and drawing the corresponding graph infused by the provided location data of the nodes. The tool can be run in two modes, depending on whether a 3D map was provided. In the following, we demonstrate both modes.
Mode 1 (with 3D map). For mode 1, a 3D model of the process environment has to be provided. This can e.g. be a map of a building, but also a geographic map of countries. Many open-source tools like Blender exist to create such models. For mode 1, the mapping file assigns to every activity an , , coordinate on the 3D model, and the visualization will place the DFG nodes accordingly. As discussed, an important feature is the integration of path-finding algorithms, which ensures that the edges correctly follow actual paths in the 3D map, and don’t go “through walls". An overview of how inputs are combined in mode 1 is shown in Figure 4.
Activity A Activity B 0>1 1>2 … + +
Activity A:{ x: 1, y:2, z:-5 },… =
3D Map
Mode 2 (without 3D map, positions loaded from geo-data). For mode 2 (without 3D
map), the mapping file assigns to every activity a real-life longitude , latitude , and a height
above sea-level ℎ. A remark here is that lat/lon coordinates model positions in a non-euclidean
space (i.e., a sphere), however, for our tool, visualizations are presented on a “flat" surface which
is a euclidean space. To transform spherical coordinates to cartesian coordinates, we apply the
mercator projection. Specifically, for the earth’s radius , we
apply the projection (, , ℎ ) = ( * rad( ), * ln(tan( 4 + rad( ) )), ℎ)
2
[
The tool can be used with any DFG in the .dfg format. Some considerations are as follows. First, regarding 3D process visualizations, there is a lack of research on quality criteria. For example, crossing lines may need to be assessed diferently in 3D spaces. Future works should therefore investigate cognitive aspects of 3D process visualizations to identify quality metrics. Second, as stated, the considered lat/lon coordinates are spherical, but the visualizations are transformed to a euclidean space. For most use-cases, e.g., processes in a building, this will frankly not be of interest to the user, but for larger distances, it should be kept in mind that this will cause distortion, e.g., showing countries on opposites side of the "globe" on one plane. Last, we currently assume a 1:1 mapping between activities and geographic positions, i.e., even across diferent instances. We argue this is applicable to many real-life settings, e.g., sensory-data from IoT sensors, or machine/warehouse activities. In future works, we aim to integrate support for activities with multiple locations over diferent instances.
In general, the form of 3D visualizations as introduced in this work can give rise to many future forms of process intelligence, e.g., conformance checking with geospatial reasoning.