We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

iGUESS – The Good, The Bad And The Ugly Of Developing A Distributed Modeling System For European Cities

00:00

Formal Metadata

Title
iGUESS – The Good, The Bad And The Ugly Of Developing A Distributed Modeling System For European Cities
Title of Series
Number of Parts
95
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Production PlaceNottingham

Content Metadata

Subject Area
Genre
Abstract
The integrated Geospatial Urban Energy decision Support System (iGUESS) was conceived as a way to help urban planners explore renewable energy and energy savings potentials to make cities more sustainable and self sufficient. Models that calculate solar, wind, and geothermal energy potential can be complex to build and run, so we felt we could simplify the process by creating a web-based tool that a planner could run from their browser. To maximize interoperability with existing models and data sources, we decided to build the system using existing OGC standards and protocols. iGUESS is a web-based system for connecting data, modeling, and visualisation services distributed across the Internet. Users can leverage data and processing services offered via standard OGC protocols such as WMS, WFS, WCS, CSW, and WPS. iGUESS helps users match data with models, launch model runs, monitor progress of execution, and visualize computed results. iGUESS does not store data or host computation services, but instead relies on data and modeling web services provided elsewhere in the project, by our partners, and by third parties. Developing iGUESS has given us a better understanding of the strengths and weaknesses of a distributed modeling system based on OGC services, and some of the inherent limits of these protocols. The interface allows users to interact with services in real-time, using minimal caching, so it always presents an accurate reflection of what data and modeling services are available. This design has presented us with interesting challenges related to intermittent and unpredictable availability of distributed data and process services that live beyond the bounds of the system. The primary advantages of this distributed modeling system is its modularity and flexibility. Users can run models using input datasets they (or others) may have published for different purposes. Models can be upgraded and improved by their publishers without requiring users to install new software. Finally, running models via WPS can be easier than configuring a local desktop model, and the processing is offloaded onto a computer presumably more suited to handling large, complex calculations. Many of the specific challenges we faced have been related to the limitations of the WPS protocol. It is difficult to precisely specify inputs or describe outputs, and there is no mechanism for prioritzing or terminating a running process. The lack of process control is particularly relevant to the sorts of large, processor intensive models that iGUESS was designed to run. Also, very little of the data our partners need to use is actually available online, and they have encountered a wide range of logistical and institutional barriers to providing it themselves. Lastly, we are still trying to cope with issues related to exposing computationally expensive processes to the Internet. This talk will present a technical overview of the iGUESS system, how it works, alternate approaches we considered (distributed architecture vs. traditional “desktop” approach), and the lessons we learned building it (managing complexity and the risks of oversimplification). It will also explore some of the “real world” hurdles mentioned above, and will offer some ideas and insights into the type of applications that are best suited for the WPS protocol.
Physical systemOpen setPresentation of a groupBitWeb 2.0NeuroinformatikMathematical modelProjective planeComputing platformWeb serviceComputer programmingSheaf (mathematics)Goodness of fitProduct (business)Musical ensemblePhysical systemLecture/Conference
Online helpComputing platformMathematical modelDecision support systemFood energyUnterstützungssystem <Informatik>Evolutionarily stable strategyComplex (psychology)Software frameworkAreaProduct (business)Mathematical modelCodeProcess (computing)Open sourceMusical ensembleConnectivity (graph theory)Food energyComputing platformWeb serviceProjective planeType theorySoftware frameworkOpen setVector potentialComplex (psychology)Decision support systemBitElectronic mailing listComputer animation
Server (computing)Mathematical modelWeb serviceDisintegrationFitness functionResultantWeb serviceView (database)InternetworkingMatching (graph theory)Server (computing)Mathematical modelSingle-precision floating-point formatDiagramCuboidConnectivity (graph theory)Process (computing)Different (Kate Ryan album)Right angleProcess (computing)Perspective (visual)Program flowchart
ArmMetropolitan area networkMenu (computing)Server (computing)Electronic mailing listMathematical modelOcean currentDifferent (Kate Ryan album)Physical systemEngineering physicsWeb serviceHypermediaComputer animation
Special unitary groupServer (computing)Descriptive statisticsString (computer science)Mathematical modelView (database)Electronic mailing listFunction (mathematics)Dependent and independent variablesGreatest elementoutputWordHypermediaComputer animation
ArmEmulationMetropolitan area networkConvex hullUniform resource nameMathematical modelCommunications protocolWeb browserCuboidSet (mathematics)Server (computing)Internetworkingoutput1 (number)String (computer science)Function (mathematics)Different (Kate Ryan album)Arithmetic progressionProcess (computing)View (database)File viewerPlastikkarteComputer configurationTouchscreenPrice indexUniform resource locatorLevel (video gaming)Dependent and independent variablesSubject indexingImage registrationInformationIdentifiabilityConfiguration spaceCASE <Informatik>Greatest elementWeb serviceDigitizingHypermediaPolar coordinate systemLine (geometry)Client (computing)Frame problemDescriptive statisticsComputer animation
Open setStandard deviationMathematical modelVariety (linguistics)Physical systemFigurate numberMathematical modelComputer architectureWeb serviceDifferent (Kate Ryan album)MathematicsChainData modelType theorySoftware developerResultantStandard deviationGame controllerField (computer science)Software bugSet (mathematics)Computer animationSource code
Information securityInformation privacyKontraktion <Mathematik>SoftwareWeb serviceDesign by contractRevision controlData management1 (number)Functional (mathematics)State observerInformationWeb 2.0Utility softwareInformation privacyWeb serviceGame controllerBlock (periodic table)Mathematical modelMathematicsInformation securityDiscrete element methodServer (computing)SoftwarePolar coordinate systemFirewall (computing)Set (mathematics)MereologyTheory of relativityIntegrated development environmentDemo (music)Level (video gaming)QuicksortElectronic program guideComputer animation
EmailSoftwareServer (computing)Level (video gaming)Ext functorGeometryOpen setPhysical systemRaster graphicsWeb serviceCodeBuildingLibrary (computing)Open setMobile appBritish Computer SocietyMultiplication signSource codeComputer animation
Process (computing)Computer fileControl flowSystem programmingAsynchronous Transfer ModePhysical systemSoftware testingError messageRevision controlDifferent (Kate Ryan album)SoftwareSet (mathematics)Server (computing)Office suiteMathematical modelDifferent (Kate Ryan album)Revision controlPhysical systemCommunications protocolError messageGame controllerIntegrated development environmentMathematical analysisWeb serviceComputing platformEngineering physicsPosition operatorCASE <Informatik>Computer animation
Communications protocolProcess (computing)Presentation of a groupProcess (computing)Process (computing)Gotcha <Informatik>Web serviceMultiplication signParticle systemServer (computing)Power (physics)Vertex (graph theory)Communications protocolMathematical modelComputer animation
Control flowMechanism designAugmented realityRule of inferenceRaster graphicsWeb browserWeb serviceClient (computing)Library (computing)NumberMathematical modelBookmark (World Wide Web)File formatOrder (biology)MetadataOpen setProcess (computing)Video gameSet (mathematics)Dependent and independent variablesBitUniform resource locatorWeb 2.0Vector spaceFeedbackCycle (graph theory)Descriptive statisticsServer (computing)Process (computing)Augmented realitySource codeGame controllerGoodness of fitHypermediaSoftware developerMessage passingFamilyHill differential equationGreedy algorithmCASE <Informatik>Disk read-and-write headInternet service providerInteractive kioskTablet computeroutputSystem callPolar coordinate systemComputer animation
Presentation of a groupMathematical modelSet (mathematics)Sound effectPhysical systemServer (computing)Library catalogMultiplication signWeb serviceImage registrationCASE <Informatik>Form (programming)Modul <Datentyp>Cellular automatonSoftwareRight angleExecution unitWordProcess (computing)Process (computing)Noise (electronics)NetzwerkdatenbanksystemComputer architectureFigurate numberCuboidOrder (biology)Graph coloringUniform resource locatorSelf-organizationGreatest elementGeneric programmingPointer (computer programming)Strategy gameNatural numberInterface (computing)Category of beingInternet service providerSatelliteConnected spaceBitOcean currentDataflowPoint (geometry)Source codeGroup actionInternetworkingLocal ringComputer animation
Transcript: English(auto-generated)
of the session and the missing chunks for delaying your lunch. I'll try to make this a good presentation. And thanks to Marco for letting me use his computer. So my name is Chris Eicamp. I work at the Anri Tutor Institute in Luxembourg.
I'm here today to talk about iGuess, which is our distributed modeling platform based on open web services. And I'm gonna talk to you a bit about what iGuess is, how it works, and then I'm gonna have a section on the lessons that I learned, or that we learned programming it, and then some ideas for advancing the web systems, web services ecosystem to make projects like
this a little easier. And of course there will be cowboys. So, music is a European project intended to help cities reduce their CO2 emissions primarily in the areas of energy production and energy consumption.
It's a partnership of five European cities and two research agencies. And iGuess is the modeling platform and decision support system that's a primary component of the music project. And the types of questions that iGuess is intended to answer are things like, how much solar potential do we have in the city?
Where can we install solar panels most effectively? Is there geothermal potential here? Mainly a lot of questions around the production of energy actually within the city. So we had a couple of primary design goals when we set out to work on iGuess.
So the first thing was interoperability between partners. We wanted partners to be able to provide data about their cities and perhaps other partners to provide models. And we needed to make sure that there was a way that the data and the models could work together. We wanted to simplify access to modeling tools. If any of you have done much modeling, you know sometimes models can be very complex
to configure and run. Some of that complexity is just inherent in modeling. It's a complex business, but we were looking for ways that we might be able to simplify the process a little bit. And we wanted to create a reusable framework. We wanted to use this code for other projects. We wanted our partners to be able to use it for other projects. And we wanted to have it be open source so anybody could use it.
And so the code base had to be distributable. So when we took all these things together, we decided that iGuess should be designed around open web services and that ecosystem. So this is just a very schematic view of how iGuess fits into the services that we use.
Over on the left, the right, this side, the far side of the diagram, you see these are the model servers. So these are WPS servers that can live anywhere on the internet. We have data servers over here on the right that are also data provided by people on
the internet. And iGuess is in the middle. iGuess doesn't host any processes. iGuess doesn't host any data. It just acts as a middle man, kind of a matchmaker to help match up data services with modeling. And then it will help serve out the results of the modeling process. So one thing I'd like to point out on this diagram is that there's a gray box around
these different services. And the reason that the box encompasses all the services together is because we see these data services as components of a really of a single aggregate composite data service. We don't think of WFS as different than WCS.
I mean, it is different, but what we really think of is these are data servers. So from the modeling perspective, we don't really differentiate between those two. So this is a screenshot of iGuess. And all this is showing here is just a list of the different models that have been registered with the system currently.
And it doesn't matter if these are all on one WPS server or on different WPS servers. The user doesn't care where they are. The user just has these registered models that they can use and run. So what I'm going to do now is open up one of these, expand one of these tabs, and show you what's on the inside. So here we have, there's a description of the model at the top. And we have a list of all the inputs that the model requires.
And down at the bottom is a list of outputs. All this is is just a formatted view of the WPS server's get capabilities string. It's a request you can make to the WPS server that will tell you what it can do. And also all this is just a view of that response.
But before we can run a model, we have to add data. So I'm going to show you how we get data into iGuess. So this is our data import screen, or it's more of a data registration screen, because we don't actually import data. All we're doing is registering where the data lives on the internet. So you put a URL in up at the top there.
And the web client will go off and make requests using WCS and WFS to find out what data is available at these URLs. It pulls back the responses it gets from all these things and creates a little, like,
I don't know, I think of it as an index card showing what the data is. You get a snapshot of the data. You can see if the data is available for mapping, if the WMS server has responded, or if the data is available as a model input. But probably the most important thing on the screen is the tagging.
So when you register a data set, you can assign tags to it. And these tags are drawn from the input identifiers of the different WPS processes. So when you start tagging data sets, when you import a data set and assign a tag, you're essentially associating that data set with the input to a model.
And we'll see how that works in just a minute. So this is the actual model configuration screen. This is essentially the same information here that we saw earlier. We've got the model description, the inputs, and the outputs. But in this case, we can actually start assigning data sets to each model input. So for example, on this top one, it's a digital surface model.
Any data set that we tag with DSM is available as an input in this drop-down box. So we can register a lot of data sets with IGAS. But if you've only tagged one or two of them as DSMs, those are the only ones you have to worry about deciding when you're configuring those. So you can go through, assign input data sets to all the model inputs.
If the model, in this case, there's a place where the model requires a string entry, you can type that in. Basically, you configure the model by specifying what all the inputs are. And then down at the bottom, you can say, what do you want the output data sets to be called?
So we get that all configured. Everything's happy. We've provided all the inputs that we need, and we have the option to run the model. So here, the model is running. It says running. That's how you know it's running. And it goes. WPS, the protocol says that you can, what we do here, we start polling the WPS server.
And if the WPS server is well-behaved, it will tell us its progress as it goes. So for example, in this case, the model is 25% completed, and we get that status indicator in the browser. So the model runs away, runs, runs, runs, and finally, hopefully, it finishes.
And then what we can do is we've created, in this case, two new data sets. We can view those data sets. We can use them as inputs into other processes or download them and analyze them further on the desktop. And so this is just a quick view of our map viewer, a data viewer. There's nothing particularly interesting here for people at this conference.
I'm sure you've seen plenty of map viewers. It doesn't do anything special. So what I want to talk to you now about is what we learned while we were developing this system. So first, we have the good things.
So the system, it's easy to deploy updates. If we fix a model, fix a bug on a model, a data set gets updated by any of the data owners. These changes are propagated immediately to all the users of the system. You don't need to install new software. You don't need to download new data. It just happens automatically.
Data owners retain control of their data. And that's important for some people. They don't want to give their data set away. They want to feel that they still retain ownership. So by using web services this way, we can use other people's data, but we don't have to take it from them. And we can use data in models that are developed by other people and perhaps put them together in ways that we hadn't anticipated.
Someone could register a new model with a system that we hadn't seen before and use it with data that we might not have seen before and come up with a result that we hadn't anticipated. So this type of system gives us flexibility to be creative and allow other people to be creative. And we find that to be an important thing.
It's based on open standards. There's no vendor lock-in. I come from a long history of using Esri. So this is a really new thing for me. I like it. And the system is flexible. By plugging in different models and different data sets, you can suddenly do entirely new things. So these are all great aspects of this architecture.
So not everything is great, though. So we have five partners, as I said earlier. And each of them had what, to me, was an interesting problem. So the first one I call the WFWTF problem. And this is basically an observation that we dealt with a lot of very
professional, very educated, talented GIS managers. And almost none of them had heard of web services. So if you're going to deploy a model with people in the real world who are maybe not the people at this conference, they're not necessarily going to know what web services are, how to set up a WTF server, and so on.
Now, another problem we had was that one city had, one of our partners had contracted all their IT functions to a private company. I'm not sure why they would do that, but that's what they did. Now, the company was very happy to set up web services for them, as long as it was itemized in the contract,
appropriate change fees were paid to change the contract, and it took over a year to get everything renegotiated, get the money sorted out, and get this all working, just to set up a server. Sometimes in-house IT can be a problem. One of our partners had an IT department that was not very
happy to open new ports on the firewall, to have servers that were not under their control running. Some IT places, and in some places, maybe you've worked in places like this, they want to control everything. And so if you're dealing with people who are in that
kind of environment, it's a difficult issue to overcome. Data security and privacy concerns are a big issue here. One of our partners had a DEM or DSM data set they purchased from a vendor. They couldn't put that service, or that data, on a public web service, because it violated the contract and
the copyright of the data. So that was an important issue. They also had utility data. It was aggregated, somewhat, to the block level, but then there were some blocks that only had one household on them. So even with aggregated data, you could still get information about individuals' utility consumption.
And there are some really legitimate concerns with publishing data that can be tied back to individuals. So that's another issue with putting data into this kind of ecosystem. And finally, some of our partner's software just has poor support for web services. For example, one of our partners is using an old version of MapGuide, which just doesn't support WCS data.
And that's a problem. So the conclusion from this was that sometimes the non-technical issues are bigger than the technical ones. And when you're dealing with partners who are not necessarily on the cutting edge, this is a real issue. So the ugly.
It gets better, right? This is primarily a comment on my feelings towards WCS. I think WCS is a service for providing raster data. And in itself, it's a fine thing. It's just that nobody supports it. And not too many people seem to be using it.
So there's a lot of library. We use OpenLayers and GeoAccident. We actually wrote WCS services for these. And I think sometime in the next week or two, for OpenLayers anyway, the WCS code will be rolled into the main release. QGIS is actually supporting. I just learned this yesterday.
We'll be supporting WCS maybe as of today if they release on schedule. But until today, they didn't support WCS. So if you're building a system that relies on WCS, as we did, this is a problem. It will get better over time. But right now, there's still a lot of packages that don't
support it. OK. Unstable. There's a lot that can go wrong in this ecosystem. There's a lot of ways things can fail. You're dealing with servers all over the network. You have network issues.
You have server issues. Servers go down. People take data sets away. Things happen that doesn't happen on the desktop. No one sneaks into your office in the middle of the night, probably, and steals your data sets. So there's a lot of things that can go wrong in this environment. Most of the systems are beyond your control. So you might be using, I guess, as your modeling
platform, but somebody has changed the version of a software somewhere, or these remote pieces may not support the same versions of the protocols you're hoping are supported. There's just a lot of stuff that can happen. And because there's so many different pieces of software
that people can plug into this ecosystem, it's very difficult to actually test and verify that your system works. And so what often will happen is you get an error somewhere. We do have some good ways of propagating the error back to the user, but oftentimes you get errors that look like this. You show this to a user who's using, I guess, trying to run a model on solar panels, and they're not
going to know what's wrong with it. I didn't know what was wrong with that. And that actually came from one of our servers. But this was a problem because the WCS server somewhere was misconfigured, and it caused the WPS server to fail. And it's difficult.
So the undead, the zombie cowboy. What presentation would be complete without a zombie? So actually there's two. This is primarily a comment on the fact that a WPS server is immortal.
Now what I mean by this is it's not actually immortal. They crash all the time. But what I mean by this is that once you start running a WPS process, you can't kill it, at least within the protocol. I mean, you can unplug the server. But there's no way within the WPS service protocol to kill this thing. Now we have our solar model.
If somebody uploads a reasonably large data set, this thing will run for two or three weeks. It's a huge process. It consumes a lot of resources, a lot of power. It's expensive to run this. Somebody starts running this and says, oh, man, I should have put a two in instead of a three. They stop running it.
Well, OK, I guess it's fine. The process is gone. It forgets about it. But the WPS process just keeps running. So if weeks go by while this thing is in the undead state, and meanwhile that person may have launched another one and then decided they didn't want that. So we can end up with a lot of processes going.
It's expensive. There's no way to kill them. And this is a real problem. So the future. These are my ideas for how the ecosystem could be improved in coming years, and I hope will be. So the first one is this idea of, I don't know if any of
you who worked in great detail with web services, but WFS and WCS, which are the vector and raster providing services, have a thing called get capabilities that describes what the server has. Now, currently, you have to make that request separately for WPS and WCS.
And this is soup to me. It's like web services soup. So I get them confused sometimes. But so you do a get capabilities for WFS and WCS, and then you have to maybe do a describe coverage or describe feature requests. And you get all these, make all these requests, and you get all this data back. And then you have to try and sort it all out and hope there's nothing conflicting, and hope everything looks
good, and it's a real pain. And it would be great if there was just a way to say, get me all the metadata for all the data on the server in just one request. So that would be my first idea is to simplify the process of getting metadata about the data that's on a server.
Second one is WPS. This is the model running service. Requests, you have to provide all this data to run a model. But the WPS process does not actually describe what it needs very well. You can get a style sheet that is fairly detailed, but
processing this and parsing this and understanding the style sheet is very, very complicated, and we haven't found any good tools for doing it. What would be great is if a model could say, here's the data that I need, and describe it in detail. And you could send that description off to a data service and say, hey, data service, what data do you
have that matches this description? And then the data service could say, well, OK, this data set looks like you could use this data set as an input. And if there's a way that WPS could cooperate better with the data providing services, it would make life a lot easier for everybody. WPS also should have some callbacks, I think.
Right now, when you start running a model, in this case, let's say our three-week solar zombie model, the model, it runs, and you have to ping it, start pinging the server and say, hey, are you done yet? How are you doing? Are you done yet? We do this every minute. Now, if this thing is running for weeks and we're calling it every minute, that seems to me to be a
little bit wasteful. I would really like to have, when the server is done running, it could call a URL and say, hey, I'm done now. And then we could carry on. And this also applies to a very, very short process. You have a process that runs in a second, but you're only checking on it once a minute. That means the user could have an almost instantaneous
feedback from running the model, but instead might have to wait a whole minute until your polling cycle goes through. So if the WPS server just had a way of announcing its status to somebody, that would be great. Number four is you want to kill the zombies using your favorite zombie control method. There just needs to be a way for WPS to be terminated.
And then the last one is it would be great to augment XML with JSON. What I mean by that is you get capabilities requests, the server tells you about itself, and it tells you about itself in XML format. Browsers don't understand XML. If you're doing something on the client side, get back XML, now you need to interpret that XML.
And that usually requires a fairly big library. And if you're running on a phone or a tablet, there's a lot of JavaScript you need to download in order to make this work. And if any of you have looked into the open layer source code, a lot of it is just XML parsing code.
If we could get a response in JSON, browsers can understand JSON natively. We could cut out a bunch of stuff from open layers, simplify it, make life easier for developers, make life easier for users, and I think make everything work a little bit better. So those are my ideas for how things can be improved. And we are now at the end of the presentation.
I thank you for your attention. Some tricky questions. We'll let some people get some lunch, I guess. Just let the guy in the back. Thank you very much.
So as I understand it, the orchestration service that goes between data and processing, so you get in a lot of category or catalog of data, where the data resides, and you send it to all the allowed data to be sent to NPS and all sorts, aside PS. Is that about right?
I think that's mostly right, but could you just repeat that again quickly? So you have a catalog of data from wherever your users are. OK, the catalog of data comes from the registration process, so the user enters a URL of a data service, and then builds the catalog on, I guess. Right. And then when you want to run the process, does the data
not have to be sent across to the processing machine? Ah, no. No. No. Well, OK. Well, of course the data, the processing service needs the data in order to run, of course. But it doesn't come through, I guess. What I guess does is sends the URL of that data to the
WPS server, and the WPS server will, on its own, download the data set from the data provider. Is that? That's actually fine, and that's well understood. But are there not problems with that? Yes. Yes, well, I mean, when it works, it's great. When it works, and it usually works, it's great. But if somebody has removed the data set since you last saw
it, or if the network is not working. I'm really just thinking about size. Are you going over, I guess, a public internet connection where if you want to be doing stuff to, say, aerial imagery or satellite imagery, you've got gigabytes to transfer, which seems to be, yeah? Yes, that's true.
Yeah. There's no real, I guess. It's unavoidable. If your processing service is different than the guy who has the data, there's no way to avoid that. But you could help the people who have the data to install a local processing service which they can connect to? We could. But by doing that, you reduce the
modularity of the system. People are now starting to install software. And we have enough problems just getting our customers or partners' data providing services up. If they had to also have now processing services that are going to be sitting there processing for weeks at a time, that's going to be too much.
But yes, I think your points are well stated. Really fascinating presentation. The architecture that you've outlined here is fairly generic in the sense that you have some process.
You have data coming in. You have data going out. You're defining data coming from different sources. The OGC has something called OpenMI, which is an attempt to standardize this kind of architecture. And I also came across the, it's a bit of a funny
organization, but it's the National Rural Electric Co-op Organization in the US, which has an R&D. And they're interested particularly in running electric network models. In other words, to be able to determine fairly detailed
stuff about voltages and current flows and whatever. But it's designed to be a generic model very similar to the architecture that you outlined here. So I think what you've done is this is going to be the general, I mean this seems to me, this is going to be the general architecture for how we do modeling in the
future. And there's always the details of how you deal with these problems, moving data around or whatever, and there'll be generic ways to do that kind of thing. But I think this really is the future of how we're going to do modeling exercise, whether it's electric power modeling or the kind of modeling you're doing. It's just a comment.
Yeah, I agree. Everyone should. And keep it on the WPCS group. You going to bring the microphone back?
And we'll probably make it a last question, because according to the program, there's supposed to be another session started already. OK. Well, we're using WPCS basically in its simplest form. We just grab everything and let the WPCS server figure
out what it needs to do with it. Because if you wanted to start adding bounding boxes and clipping and stuff like that, then the interface becomes much more complicated. So yeah, we're just using it in the most basic raw form.
OK. I'm going to call it a day, then, because I need lunch. No worries. Maybe we can have a screenshot of what you have. Sure. This is your architecture slide.
Sure. OK.