Bytecode Unification Of Geospatial Computable Models
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| 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 | 10.5446/15516 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Place | Nottingham |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS4G Nottingham 201316 / 95
17
25
29
31
32
34
48
50
56
58
68
69
70
82
89
91
00:00
ComputabilityMathematical modelBytecodeEndliche ModelltheorieObject (grammar)Type theoryCodeCartesian coordinate systemImplementationProcess (computing)Data structureNetwork topologyCategory of beingPresentation of a groupForm (programming)Object (grammar)Natural numberVirtual machineData managementKey (cryptography)Computer simulationOpen sourceFormal languageNeuroinformatikContext awarenessAlgorithmLatent heatState of matterVirtualizationPerfect groupJava appletSpacetimeBytecodeRight angleComputer animation
01:44
Fiber bundleWindowUniform boundedness principleView (database)AbstractionJava appletSerial portString (computer science)Menu (computing)OvalException handlingExecution unitGastropod shellLatent class modelConvex hullHydraulic jumpSystem callMach's principleMeta elementInclusion mapData typeWritingOnline helpBookmark (World Wide Web)Client (computing)StrutWechselseitige InformationPlanar graphMathematicsFermat's Last TheoremNormed vector spaceDuplex (telecommunications)Computer fileLevel (video gaming)Hill differential equationEmulationScalable Coherent InterfaceMaxima and minimaAreaChief information officerGamma functionComputer networkInformation securityInformation managementHost Identity ProtocolUser interfaceInstance (computer science)MassClient (computing)Programmer (hardware)Range (statistics)Java appletMultiplication signObject (grammar)Scaling (geometry)Dimensional analysisGastropod shellData typeVisualization (computer graphics)Parameter (computer programming)Domain nameProgramming languageSocial classData managementMereologyScripting languageBuildingDifferent (Kate Ryan album)Letterpress printingInformationDatabaseVirtual machineServer (computing)Food energyMiniDiscPosition operatorMaxima and minimaSpacetimeRepresentation (politics)Arithmetic meanDefault (computer science)FrequencyPerspective (visual)Point (geometry)Formal languageProcess (computing)Data storage deviceUniform resource locatorWeb 2.0WindowMessage passingConnectivity (graph theory)6 (number)Physical systemOpen setCategory of beingSoftware testingOnline helpSymbol tableIntegrated development environmentFunctional (mathematics)Level (video gaming)Interactive televisionService (economics)Metropolitan area networkOrder (biology)Line (geometry)Exception handlingSubject indexingSoftwareType theoryCodeTemporal logicDressing (medical)Web pageOperating systemWebsiteInternational Date LineTraffic reportingEllipsoidForm (programming)Right angleDemosceneContent (media)Computer programmingElectronic mailing listIP addressGraphical user interfaceBasis <Mathematik>Instance (computer science)AbstractionExecution unitBoolean algebraExistenceRotationPhysical lawBitInternetworkingCoordinate systemSource codeComputer animation
09:55
IRIS-TType theoryObject (grammar)Different (Kate Ryan album)Cycle (graph theory)Perspective (visual)View (database)SoftwareMessage passing
10:19
Ideal (ethics)Interior (topology)Chi-squared distributionBeta functionInclusion mapPosition operatorWindowBookmark (World Wide Web)View (database)Position operatorSoftwareObject (grammar)Mathematical modelWeb browserQuicksortSpacetimeProjective planeLibrary (computing)Classical physicsData managementWeb pageCycle (graph theory)Observational studyChannel capacityImplementationCartesian coordinate systemClient (computing)Service (economics)Complete metric spaceVariety (linguistics)Pole (complex analysis)Web 2.0Rule of inferenceUniform resource locatorServer (computing)Message passingMobile appDemosceneElectronic mailing listData storage deviceForm (programming)Address space
12:15
InternetworkingComputer networkWeb 2.0InternetworkingClient (computing)SoftwareVirtualizationObject (grammar)Interface (computing)Projective planeDifferent (Kate Ryan album)Cartesian coordinate systemMultiplicationVisualization (computer graphics)Metropolitan area networkPoint (geometry)Mathematical modelConnectivity (graph theory)ImplementationImage resolutionInteractive televisionSimilarity (geometry)Open sourceCivil engineeringComputer animation
12:58
Gastropod shellClient (computing)Type theorySingle-precision floating-point formatVisualization (computer graphics)Server (computing)ImplementationSimilarity (geometry)VirtualizationRepresentation (politics)Proof theoryTheory of relativityMathematical modelPoint (geometry)InternetworkingSynchronizationObject (grammar)Term (mathematics)SoftwareReal numberCodeNeuroinformatikEndliche ModelltheoriePoint cloudComputing platformInteractive televisionReal-time operating systemEntire functionLevel (video gaming)Web 2.0WeightDifferent (Kate Ryan album)Connectivity (graph theory)Near-ringLimit (category theory)Cartesian coordinate systemContent (media)Open sourceCivil engineeringComputer animation
Transcript: English(auto-generated)
00:01
This talk is about an original method for building geospatial applications of various types. The method is intended to help making any geospatial application we can possibly think of, that's the goal. It utilizes directly the bytecode of the hotspot virtual machine, which, as you might know, is an open source implementation of the Java virtual machine.
00:23
The presentation is related to an article with the title The Bytecode Unification of Geospatial Computable Models. This introduction, however, is based on examples of practical implementation, which is not addressed by the article, but which makes it more relevant to a broader audience.
00:41
The major engineering concept, also introduced in the paper, is called the Geospatial Managed Object. It is a concept with which we have been experimenting for more than six years. So, we start with showing how you can use these managed objects, and then we relate the most important things back to the theoretical paper.
01:01
That outlines the structure of the talk, first we show some things, some of which might not make a perfect sense right away, and then we try to make more sense out of it. A Geospatial Managed Object, or GMO, in short, is a piece of data and algorithms bundled together as a single entity, which is positioned in geographic space.
01:24
In this geographic context, the GMOs can represent something, or do certain computation. All GMOs are encoded in the form of the bytecode, as described by the Java Virtual Machine specification. Therefore, one natural possibility to define a GMO is using the Java language.
01:44
Here, we can see a minimalistic GMO definition. Every definition must inherit some key properties. In Java syntax this is expressed by this extends MO. If we have a look at this MO class, we can see six parameters here, along with their
02:01
default values. Every Geospatial Managed Object, even our empty definition, inherits these parameters, and also other properties from this MO class. The first three parameters are the XYZ coordinates in the three-dimensional Cartesian system with the origin at the center of the Earth. It is the same Cartesian system used by Global Positioning System.
02:24
The fourth parameter is a scale level, which is associated with the XYZ coordinates. For the last two parameters specify a start and end point of the time period in which the GMO exists. These six parameters are very important because they provide a geographic reference.
02:41
Without such reference, it would be impossible to talk about anything geographic or geospatial at all. These parameters are also used for a six-dimensional geospatial index that creates order for GMOs and allows for rapid access to them. The six dimensions in this representation of the geographic space are three spatial
03:01
dimensions, one spatial scale, one dimension for time, and one temporal scale dimension. The scale dimensions are a little bit less usual, but they help, in a sense, to mimic the first law of geography, which states that closer things are more related to each other than distant things. The scale dimensions facilitate accessing the GMOs not only through where they are in
03:24
space and time, but also within which range, in space and in time, are they relevant? Next I have a short program that can create a GMOs using our minimalistic definition. It creates one GMO here, sets its z-value to 6.3 thousand kilometers along the Earth
03:42
rotational axis, and the spatial scale to the level 38. Then a second GMO is created using the default values, and both are stored on the disk in an object database. Now I use this script to execute this example. The main message here is that every GMO represents at least a point, a point in the six-dimensional
04:04
representation of geographic space. Perhaps even bigger practical impact and the use of the six-dimensional geographic space is the fact that GMOs handle data and functionality on the same common basis.
04:21
We make another GMO definition to make clearer how functionality and data are managed together, how they both are truly atomic properties of any geospatial managed object. This definition uses Python language instead of Java language to demonstrate at the same time that GMOs are language agnostic, in principle we just need a language that is supported
04:42
by the virtual machine. The first three lines do exactly the same as the minimalistic Java definition. The difference is this method, called, quite symptomatically, manage. This method is actually also defined in the abstract MO class, meaning that every GMO definition has it, but by default it does nothing.
05:02
By implementing this method, it is possible to include arbitrary, computable features in your managed objects. I really mean arbitrary. Any that can be coded using the selected programming language. Here the functionality is trivial, it will just print out the geo-referencing information
05:21
about the managed object. Again, a program is needed to create an instance of this Python definition and to add it to the same database as the first objects. It might look like this. These examples are available on the website, so you can download them and try them for yourself. I just run the example with this script.
05:43
So, we had defined two types of GMOs, one that only contains the minimum geo-referencing data and one that also have functionality. We have created GMOs using these two types and stored them in an object server. Right now, the server is running and it is waiting for requests from any clients to serve
06:03
the GMOs over network. What matters from the end user's perspective is a GMO client, which is a piece of software that allows to use and consume the managed objects. Also because of that, we made a web start tool, which I will start right now from this
06:22
webpage, it is a shell-like program, which allows an interactive work with all aspects of this GMO technology. Meaning that the definitions, creation, and storage of objects, as well as accessing, viewing, and interactive handling of GMOs can be done from the shell. The nice thing about that is that everything from the definition to handling and analyzing
06:44
GMO content can be done from a single, uniform environment using Scala language. Here we have a Scala script for getting our test GMOs from the server. You need to specify a server address and port. And, you must also specify a standpoint in the geographic space from which you want
07:03
to access the GMO content. This is a simplified form of the request, which uses geographic latitude, longitude, and height above WGS-84 ellipsoid. The time is taken from the operating system and all spatial and all temporal scales are included automatically in the actual request.
07:23
I execute the script, and it reports that we have received three managed objects using two different definitions. Which is what we have created so far, so no surprise here. Except that it works. We can also see the list of the actual objects received from the server.
07:44
Now, I can tell the client to select the first GMO from the list, and if I do it, I get this report printed out. It might be familiar to you because it is exactly the message we coded in Python. The thing to realize here is that the printing is performed by that GMO itself.
08:03
If I select the second GMO, I will get nothing because in our Java definition we did not include the functional method. By modifying the previous script you could request objects from any GMO server on the internet. I know of one such server at Gryphonore.net.
08:24
Having GMOs around this place. Now I get this. 165 managed objects using eight different GMO definitions. Selecting the first GMO gives me some graphical user interface about monitoring GPS positions.
08:46
If I select, randomly, the 23rd object, I get another window about the energy consumption of the building. I just want to stress that GMOs are independent, computable units. It is necessary to realize that these graphical user interfaces are inseparable parts
09:04
of the GMOs, which are basically a content previously unknown to this client. So, in any software that supports GMOs you would get the same windows. Using graphical user interfaces and lists of objects for a given location might be useful
09:22
for location-based services, but GMOs also have a low-level visualization support through data types closely related to OpenGL. Additionally, the shell also contains a visualization component implemented by Runescuard from Norcart. So, we can proceed from this web page with another example and see the last list of
09:43
GMOs in a georeferenced three-dimensional scene. This example doesn't go directly to the target point. Instead, it changes perspective three times to demonstrate the visualization of the GMOs at different scales. First it takes a planetary perspective where we can see a textured globe.
10:04
Then we get closer to the target using a map, like view perspective. Then we get an oblique perspective on the city. All you can see here are the managed objects of different types. And finally we arrive at this predefined perspective where we got these light poles
10:22
and manholes. Now, we do not need to select the GMOs from the list. Here you can just click on these light poles or manholes to select them. The main message about these is that they are connected in the network of manholes and the network of light poles. So, when I move this light pole to east, the whole network gets updated which demonstrates
10:45
GMOs' capacity to model networks. Other step in showing how GMOs can have dependencies on each other is ability to detect clashes. If I turn on the clash detection, it highlights the manhole and light pole that are
11:00
in clash according to some modeled rule. If I select the manhole, I can see it is in clash with this light pole and I can resolve the clash too. Nearby to the side there is a small geospatial app that allows monitoring
11:20
positions in geographic space, for example using GPS. I start the monitor. Now, this GMO has a web API, so you can just enter a URL address in your browser to interact with this GMO, for example, like this. And see the marked position in the visual scene. Having a web API also allows to demonstrate that GMOs can have web page
11:44
user interface. This is a simple form that will set my position using the managed object. Here you can see the position that I have just reported through the web form. The implementation behind all these things is clearly more than a mere
12:01
library for GMO definitions. So far, we saw how this store objects, request objects, and serve GMOs over IP networks. Therefore, the implementation provides a complete network service for geospatial applications. It provides a geospatial reference interface for IP networks, or
12:20
internet networks, if you like, which also gives the name to the technology, it is called GRIFN. GRIFN facilitates creation of new GMO software, but it also allows to add GMO support to the existing software. In a project funded by Norwegian Research Council we made GMOs work
12:42
with three different software clients, including a classical GIS client. The clients needed to implement the GRIFN API to handle the managed objects. That's about 20 methods, which is not an overwhelming amount. We had Virtual Globe Client, which is a web start application
13:00
providing its own implementation of multi-resolution virtual globe. It is in many ways similar solution to Google Earth. The second application was Virtual Map. It is a proprietary application implemented using .NET technology. It is a 3D visualization component used by commercial software for civil engineering called NovaPoint.
13:23
And the last client was GV-SIC, an open source GIS software. This was an interesting client to have because it could demonstrate how GMOs can work in both 3D and 2D visualization clients. We ended up with a specialized interactive city model and three
13:42
different types of clients using a single GMO server. If we consider GRIFN Shell as a non-visual client, we have four software clients that have been working with the GMO technology. The clients constitute a platform, or if you want, an infrastructure, but the main point is of course the content, the GMO content
14:02
that can be used on top of it. Over years we have accumulated various types of GMO models, some being just a proof of concept, but some being more than that. There are GMOs dealing with, to weigh synchronization of models over the internet, with web interface, with clash detection,
14:20
with plane, GIS data, with representations of network features, with terrain data representation, with near real-time sensor data from vehicles, with point cloud representation of litter data, with animations, with entire city models, and so on, and so on. So, the diversity is big and growing. Which inevitably led us to ask ourselves a question,
14:43
what are the limitations of GMOs in terms of modeling? What can be, and what cannot be made in terms of geospatial managed objects? That brings us to the conceptual article The Bytecode Unification of Computable Geospatial Models