Results of an Evaluation of Augmented Reality Mobile Development Frameworks For Addresses in Augmented Reality
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 | 183 | |
| Author | ||
| License | CC Attribution - NonCommercial - ShareAlike 3.0 Germany: 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/32009 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Producer | ||
| Production Year | 2015 | |
| Production Place | Seoul, South Korea |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
FOSS4G Seoul 201526 / 183
7
8
47
53
54
65
73
74
79
82
84
92
102
103
105
124
126
127
130
141
142
143
156
161
162
170
176
178
181
183
00:00
Goodness of fitFocus (optics)Augmented realityCASE <Informatik>Image resolutionView (database)Term (mathematics)MereologySoftware frameworkMobile appInformationForm (programming)DigitizingComputer animationXMLUML
00:46
Address spaceSoftware frameworkCartesian coordinate systemSpeicheradresseResultantAugmented realityInterpreter (computing)InternetworkingLatent heatEntire functionOpen sourceBlock (periodic table)Programming languageData qualityReliefUniform resource locatorStandard deviationOpen setBuildingJava appletoutputData structureComputing platformCalculationAndroid (robot)Software repositoryVulnerability (computing)Set (mathematics)DistanceImplementationFocus (optics)Pairwise comparisonForm (programming)FreewareDigitizingAreaRandom number generationField (computer science)Game theorySoftwareCASE <Informatik>Phase transitionDigital rights managementWeb browserNormal (geometry)NumberDatabaseComputer programmingUniqueness quantificationModule (mathematics)EnthalpyDependent and independent variablesConnected spaceOrder (biology)2 (number)InformationArchaeological field surveyDigital photographyVirtual realityEnumerated typeView (database)Inclined planeFamilyValidity (statistics)Error messageDuality (mathematics)Sign (mathematics)CognitionInterface (computing)InferenceSuite (music)WebsiteForcing (mathematics)Object (grammar)Computer configurationIdentifiabilityEndliche ModelltheorieComputer animation
08:12
Order (biology)Software testingExtension (kinesiology)Computer programmingElectronic visual displayOpen sourceSoftwareWeb 2.0Library (computing)Lebesgue integrationCross-platformComputer clusterComputer configurationData structureObject (grammar)Instance (computer science)Functional (mathematics)Software frameworkoutputOnlinecommunityCartesian coordinate systemData acquisitionDigital divideVulnerability (computing)Limit (category theory)Point (geometry)Source codeAndroid (robot)Address spacePrototypeAdditionProjective planeMachine codeSpeicheradresseWeb browserAugmented realityEvent horizonSet (mathematics)UsabilityOptical disc driveCASE <Informatik>TouchscreenComputer fontPhysicalismCalculationINTEGRALVisualization (computer graphics)KonturfindungDistanceImplementationRepresentation (politics)MereologyInternet service providerRadiusGeometry1 (number)Category of beingComputer fileMaxima and minimaDisplacement MappingGoodness of fitMetadataGraph (mathematics)Focus (optics)Observational studyField (computer science)Speech synthesisDialectLambda calculusShape (magazine)Uniqueness quantificationPhysical systemDifferent (Kate Ryan album)Operator (mathematics)AreaService (economics)MathematicsMarginal distributionMeasurementComputer animation
15:38
Augmented realitySoftware frameworkDependent and independent variablesComplex (psychology)Medical imagingComputer programmingDirection (geometry)Pattern recognitionNeuroinformatikCASE <Informatik>Bit rateMereologyEntropie <Informationstheorie>Integrated development environmentArmSocial classPairwise comparisonInformationParameter (computer programming)INTEGRALOpen sourceForm (programming)XMLComputer animation
17:47
Dependent and independent variablesCASE <Informatik>SoftwareMultiplication signStandard deviationMappingDirection (geometry)Observational studyLevel (video gaming)Real numberAugmented realityCalculationData structureIntegrated development environmentSemiconductor memoryEntire functionField (computer science)BuildingComputer clusterLattice (order)SpeicheradresseAddress spaceRight angleSocial classLimit (category theory)ArmFamilyLatent heatSoftware frameworkProjective planeInstance (computer science)Sound effectPlanningMereologyComputer animation
21:07
Computer animation
Transcript: English(auto-generated)
00:05
Okay, good morning everyone. I am Donny from the University of Victoria, as you know. I'm here to present our findings on the research we did on augmented reality, specifically for mobile devices. The focus of the paper was to identify and develop an augmented reality framework
00:22
that could be used to develop a mobile application to solve certain use cases. Now for those who aren't familiar with the term of augmented reality, here we refer to superimposing of digital information onto a real-time view of the user's surroundings. The research conducted here forms part of a greater research endeavor that we are doing
00:41
in geocoded addressing specifically to display an augmented reality. For our first use case, we look at disaster relief. In a situation such as this, emergency workers would need to get to a specific location. Now street names and street markers or house addresses would be destroyed in a situation like this.
01:01
Much more would most likely be destroyed. Entire blocks of buildings or street networks would be gone, making conventional methods of navigation obsolete. Now in order for an emergency worker to navigate toward a location, he would access an off-site data repository and use this information on an everyday mobile device. The AR application would then give him the digital view and allow him to navigate
01:24
toward a specific location without being familiar with the location. In our second use case, we looked at household surveys. Here we would aid in conducting household surveys specifically in rural or informal areas.
01:40
Now in a situation such as this, there is no address infrastructure, no official roads. The only official roads are those connecting one informal settlement to another. This is quite common in South Africa. As you can see here, we have Alaska Mamalodi, which is an informal settlement. You can see the houses are fairly scattered. There is no address marker and no official streets.
02:02
So an enumerator could use an augmented reality application such as this by assigning digital numbers or random numbers to an aerial photograph and uploading this data to the augmented reality application, giving you a sense of a virtual address network or a makeshift address network, if you will.
02:23
The third use case we looked at was data quality management. Now this would provide governmental bodies a unique method of validating their address data from, say, a database which had been recently upgraded or updated to physical markers in the real world. Now this is Alaska Mamalodi again, and as you can see, these are all valid addresses
02:41
from some official body or some addressing body. Now you'll also see that there is duplication, and this is actually the norm in this area. Most of the house numbers are just painted on, with duplication bringing in more errors. So the application would allow us to validate these addresses. A field worker could go out and specifically assign a unique house number or choose one
03:04
of the numbers to be displayed as the official number. From the three use cases, we identified four basic requirements that we selected our frameworks from. First of all, no internet access. In a disaster situation, the internet infrastructure would be damaged, or most likely be damaged.
03:20
Or in informal or rural areas, there would be no internet infrastructure, so the application would have to function without the connection. It had to be free of charge. In an emergency situation, emergency workers wouldn't or would be limited by licensing restrictions. It depends on rapid response. If they have to wait for licensing in a specific region, the application would not
03:41
be as effective as intended. The last two were high precision. The framework needs to be able to identify between a specific address and adjacent structures. Now these structures next to, or in a densely populated area, structures are very, I can say it, on top of each other, and the problem becomes that the application might
04:01
confuse the intended address with those next to it. The last requirement we looked at was the calculation of distance. A user using the application would most likely deploy it on foot, and having the ability to calculate the distance between the intended address and the user is quite a useful tool. An example of densely populated areas, these are favelas just outside of Copacabana.
04:23
As you can see, they're quite densely populated, and they go up an incline, making the ability to judge distance and selecting a specific address quite difficult. Now the application would have to discern between different buildings, and be able to calculate the distance based on elevation.
04:41
Our evaluation method for selecting the candidate frameworks was structured on a two-phased approach. In the first phase, we did a broad evaluation for the sensor availability and the activity of the frameworks that we selected. In the second phase, we did a detailed evaluation of each of the candidate sensors, and we looked
05:01
at the general functional and non-functional requirements of each to identify their strengths and weaknesses. So in the first phase, the first step was to select or to identify frameworks. To do this, we first looked at an online comparison tool called Social Compare. From this, we identified 66 possible candidates for phase one, guided by user comments on
05:25
this website. We selected two additional frameworks to be added, giving us 68 candidate frameworks for the rest of phase one. First of all, we evaluated the sensor capabilities. So from the 68 original candidates, we looked at GPS and IMU sensors, and eliminated those
05:47
that did not have the requirements, resulting in 12 potential viable options. Further review of the frameworks, we looked at the website, the activity of the website, and the purpose of the application or the frameworks. Now, in this situation, augmented reality has quite a wide field of application.
06:05
There are gaming applications, fashion applications, and then of course navigation. Now gaming and fashion obviously do not need the GPS, that is why we eliminated them based on their main focus. This left us with a final seven.
06:21
Now these seven moved on to phase two of our evaluation, which was the detailed or in-depth evaluation. First we got AR Lab. AR Lab comes in a modular structure, so we looked at the browser module specifically. AR Toolkit and Layar were the two frameworks included from the user-guided comments on Social Compare.
06:41
The remaining four were Droid AR, Metal, Panic AR, and Wikitude. So all these went on to phase two. Now I'm just going to discuss some of the results that we found in phase two of the evaluation. First we looked at the platform and the programming language, as these two were interconnected. From our results, we found that Android and iOS were the main two focuses of the platforms.
07:04
All of the frameworks were deployed in these two platforms, apart from Droid AR, which is only available on Android. Now the programming languages obviously follow suit, with Android being Java and iOS using Objective-C.
07:22
The next set of general criteria was the licensing and the implemented standards. Now for the licensing, we found that only two of the frameworks were open source, Air Toolkit for iOS specifically, and Droid AR were our two open source options, the rest were proprietary, offering various forms of freeware. Our implemented standards, I don't know how many of you are familiar with ARML 2.0,
07:44
it is a fairly new standard, and it is only implemented on three of the frameworks, Mataya, Wikitude, and Layar. The rest of the frameworks did not implement the standard AR, specifically the open source who were lagging behind in any standard implementations.
08:02
Offline availability, as I mentioned earlier, was one of our primary focuses. We looked at areas where we do not have an internet structure or damaged internet structure, and the ability to access the data offline. So here we saw that Air Toolkit and Droid AR, both being our open source options, had the ability to operate and access data offline.
08:21
The rest of the frameworks all had capability but required extensive programming in order to alter this, seeing as they were proprietary frameworks, altering their source code was not a viable option in many cases, but it was possible. So we looked at data sources after the offline availability. All of the frameworks applied web services, or used web services, as their method of
08:44
data acquisition. Now for Layar and Mataya, we found Layar, Mataya, and Wikitude all used proprietary methods of acquiring the data. The secondary way of acquiring the data was in the native code. Now again the problem came in with open source and proprietary frameworks.
09:01
Open source was quite easy to implement in this method, where altering the native code of the proprietary software was limited. Looking at the functional criteria, we looked at the data display, the object events, and the display radius of the markers. First of all, the data display.
09:21
We looked at the visual representation of how the address data would be displayed on the user's view. Here we saw that all of them could alter the display, changing the bubbles, changing the text. It was primarily text focused, therefore this was quite an important feature for us that it was simplified, yet still possible. Now as you can see, Mataya was one of the only ones we couldn't alter immediately.
09:43
The problem here was the styling is relatively branded, specifically with proprietary frameworks. They can be altered again, but there are problems. Object events refer to editing or selecting the data to expand and retrieve more data from a server or from a preloaded file.
10:00
If we look at a basic example, you can see that with the display radius we want something to alter the max distance of markers to be displayed. This is where this feature came in. If the user can change the amount of detail to be shown within a specific radius, they can apply it in various situations. The object events of the data display, we looked at the physical display markers on
10:22
the screen. For instance, can the text be changed, the basic font stylings, and things like that. The other one was selecting the markers to expand them. Instead of just displaying a house address, we wanted to display more, such as a street address or a city. The last of the functional criteria was the visual search functionality.
10:40
This part was not initially, or this criteria was not selected based on the three use cases. We do however think that it was useful in the applications, or it would be useful. Visual search refers to using point data or edge detection in order to measure a dwelling's geometric properties, and then identifying it based on these properties.
11:04
Here we found that three of the frameworks had the capability, the TIRE WikiChute and the AIRE Lab. However, AIRE Lab, we evaluated the browser, and AIRE Lab is a modular solution, so the visual search functionality was not possible in the browser module.
11:28
The final set of criteria was the non-functional. Here we looked at, first of all, the ease of integration with other GIS softwares. The idea behind this was to grab capabilities from external softwares, and use it directly
11:40
into the framework. For instance, data acquisition would have been greatly affected by this if we could use something like PostGIS as our primary source of data acquisition. Unfortunately none of the frameworks applied this, which was kind of odd as this functionality can be implemented, or hopefully it can be implemented.
12:00
Ease of extending the frameworks, we looked at the ability to add additional functionalities. For instance, the distance calculation. If the framework can be altered, the previous criteria would then be nullified, or the impact would be lessened. So ease of extending the frameworks, we found that only the two open source options provided this functionality. Usability, this was the basic installation and implementation of a general application.
12:23
All the frameworks were easy to use and easy to implement. And finally, the documentation and support functionality. Now here, another, how can I say, divide came in with the open source and the proprietary networks. So the open source was more focused on the user community and the proprietary was more
12:43
focused on the official documentation or had more of a supply. So the biggest divide that we found was between these two. In no way are we putting the two against each other, it's not a versus, this is simply to display that open source and proprietary had different strengths and weaknesses.
13:01
We found on the open source side, our toolkit for iOS used, which was our open source solution, and in the proprietary networks we looked at the other five options. So here we find that the open source options had active user communities and could be modified
13:23
in multiple ways. They also supplied the offline availability, which was a strong point in their favor. With the proprietary networks, we found that the official support was quite extensive, but the extreme cost to most of the applications here and the limitations to altering the source
13:41
code counted against the proprietary networks or the proprietary frameworks. So what happened is we took these frameworks, these two frameworks, specifically we looked at prototyping on the campus of the University of Pretoria. Two frameworks were selected, AR Toolkit, which was for our open source option, and
14:02
compared it against Metayo, which was deployed on Android. We assessed the functionality and actually developed the two applications to display augmented reality addresses successfully. During prototype testing we did, however, find additional problems again.
14:21
In the community-driven projects such as AR Toolkit, we found that there were deprecated features which required extensive programming to alter, and with Metayo it became apparent again that altering the method of display was quite an issue. Also the sensor limitations became apparent, which would require further testing in future works.
14:42
So for future works, what we actually needed was a new approach to the whole idea of the frameworks. First of all, we would ideally need something that can implement a shapefile or integrate with an external GIS software such as PostGIS or QGIS, and then alter the data.
15:03
Now if we have custom libraries and cross-platform availability, this option would be greatly increased, or the solution would be greatly increased. One of the most important functions that we looked at was the support structure. Now all of the frameworks, as you can see, there are many augmented reality frameworks,
15:20
but many of them have become outdated and deprecated. The developers have moved on to bigger things. Now the structured support system, something for instance from OSGO, would provide augmented reality for future development, a unique structure, legally and organizationally, to continue and grow. Thank you very much.
15:40
Any questions?
16:17
I wonder why you didn't consider just working with a GIS-centric framework, because most
16:25
of the augmented reality features that are in these toolkits you're not really using, because you're not doing targets or image recognition or computer vision, you're doing strictly GIS-based functions, so I just wonder why you didn't go that route.
16:40
So one of the reasons we looked at existing frameworks was because not everyone had a GIS background. We specifically looked at existing frameworks that, because there were so many, that's one of the main reasons. On that social compare site, you can find many solutions to this. Not requiring any GIS skills or solutions. No programming is, or very little programming is needed in most cases.
17:02
So this is one of the reasons that we didn't look at GIS as a solution directly. We looked at what is out there instead of creating a whole new approach to the solution of augmented reality.
17:31
Hi, I just wondered whether you could recap the advantages for an emergency responder on
17:42
the ground to use augmented reality over a 2D map, because it seems to me quite a complex environment, and I wondered if you'd spoken to any emergency responders and had that like, who else is doing this in the ground, or do you have any case studies of people doing it in the real world? Okay, we didn't speak to any emergency responders directly.
18:02
We did not ever just look at some of the simple features or some of the obstacles that we, or how can I say it, that we encountered in the field ourselves while taking address data and things like that. So one of the reasons for the business calculation was specifically because we struggled to navigate toward a specific structure in an organized environment, and we just worked
18:24
back to something that would be in foreign or an unorganized environment. The same with the high precision, these were just extrapolated from our general sense of what happened in the field, and we applied it to another field, such as the emergency workers.
18:49
Can I add something to that? So Danny doesn't know about the discussions that we had and why he did this project, so I just want to add to that. At the ISO meetings where we were developing the international addressing standard,
19:04
we are now looking at a standard for displaying addresses not only on 2D maps but also in 3D environments, and in actual fact the guys from New Zealand and Christchurch said that something like this would have been really useful in their case.
19:21
If I could just add also to that, one of the things that specifically in emergency situations, a 2D map that we looked at, conventional methods of navigation might be altered. For instance, terrain. This is where the augmented reality would also give strength to, or how can I say,
19:40
give a new solution to the emergency situation. If an entire network of streets and buildings have been shifted due to something like a tsunami, a conventional map would not necessarily provide the solution. Although it could still be used, and the user of the map could obviously use his own initiative to navigate towards the situation, this would just provide speed to the solution.
20:02
Okay, we have time just for one question. Do we have one question? So if there is nobody else with one question. Okay, he doesn't remember the question, so yes. So you need a bit of memory.
20:23
Yes, you remember now. Matayo is like one cautionary tale. I was going to say, Matayo is like definitely a cautionary tale, and not why we don't use proprietary software, right? Because they had all these developers, and then they got bought by Apple, they just shut it down, they don't offer any more support,
20:41
and everybody's screwed with using Matayo. At the start of our research, we started the research just before Matayo was enveloped by Apple, so yes, this was the case with one of the proprietary softwares. We did all of the research for this framework, we found that it was fairly useful, there were limitations obviously, and then halfway through our research,
21:01
before finishing the paper, it disappeared from the map.