Trusting the Crowd in a Geospatial Crowdsourcing Application
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 188 | |
| Autor | ||
| Lizenz | CC-Namensnennung 3.0 Deutschland: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/31650 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache | ||
| Produzent | ||
| Produktionsjahr | 2014 | |
| Produktionsort | Portland, Oregon, United States of America |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
FOSS4G 2014 Portland119 / 188
7
10
14
15
16
23
24
25
28
29
33
37
39
40
43
45
46
48
50
56
64
65
69
72
74
82
89
91
98
102
107
111
114
118
128
131
132
135
138
141
143
147
149
150
157
158
161
164
165
166
173
174
175
179
185
00:00
DatenbankInformationMaschinenspracheMathematikRückkopplungValiditätSoftware EngineeringMAPBildschirmfensterPhasenumwandlungKonfiguration <Informatik>BitFunktionalGrundraumInverser LimesKoordinatenLastMaschinencodePrinzip der gleichmäßigen BeschränktheitProjektive EbeneTabelleZählenZahlenbereichZeitzoneFastringQuick-SortVersionsverwaltungEinflussgrößeAbstandGraphische BenutzeroberflächeNummernsystemSchnittmengeEin-AusgabeInformationsspeicherungKartesische KoordinatenService providerBitrateSichtenkonzeptEndliche ModelltheorieSchlüsselverwaltungSystemplattformMultiplikationsoperatorURLMapping <Computergraphik>Demo <Programm>BenutzerbeteiligungHumanoider RoboterEinsKoroutineBildgebendes VerfahrenOrdnung <Mathematik>PerspektiveSpieltheorieMittelwertSynchronisierungAggregatzustandStützpunkt <Mathematik>SystemaufrufInternetworkingBasis <Mathematik>DruckverlaufNachbarschaft <Mathematik>Lesen <Datenverarbeitung>Array <Informatik>Mailing-ListeSummengleichungVerkehrsinformationElektronische PublikationWhiteboardWeb SiteSchreib-Lese-KopfDifferenteMUDIdentifizierbarkeitKontextbezogenes SystemDienst <Informatik>Softwareentwickler
09:14
DatenbankMathematikRückkopplungSoftwareValiditätProfil <Aerodynamik>MAPBildschirmfensterProgrammverifikationTemporale LogikBildschirmmaskeBitEinfach zusammenhängender RaumInverser LimesKomplex <Algebra>MultiplikationPhysikalisches SystemSkalarproduktVerschlingungQuick-SortBasis <Mathematik>AbstandProzess <Informatik>Coxeter-GruppeInstantiierungPunktWeb-SeiteRichtungVerkehrsinformationGoogolVorzeichen <Mathematik>BitrateWeb SiteEndliche ModelltheorieDifferenteFitnessfunktionEindringerkennungMultiplikationsoperatorRegistrierung <Bildverarbeitung>Rechter WinkelGeoinformatikOrdnung <Mathematik>Bus <Informatik>MittelwertAggregatzustandGruppenoperationStützpunkt <Mathematik>FlächeninhaltVersionsverwaltungGüte der AnpassungRuhmasseCASE <Informatik>TemplateDruckspannungUmwandlungsenthalpieSchwellwertverfahrenKontextbezogenes SystemComputeranimation
18:28
Vorlesung/Konferenz
Transkript: Englisch(automatisch erzeugt)
00:00
My name is Femke and this is Shravan and I'm from the University of Canterbury in New Zealand and Shravan is from CEPT University in India and we're going to talk about a project that we've undertaken while Shravan was an intern at my university earlier this year. So we're talking about implementing a trust model in a crowdsourcing application. So I'll start and then Shravan will pick up about halfway through.
00:23
So just to introduce it, so an application was developed called Rate It, a crowdsourcing application which rates the busyness of establishments, establishments like pubs, bars, restaurants and this rating also includes a trust rating, a trust rating of the rater,
00:41
of the person who provides a rating to give us some sense or some metric of how trustworthy that rating is. And to give you a bit of context, so Christchurch had a very big earthquake and many, about 10,000 more about three and a half years ago and so the landscape, the social landscape of Christchurch has changed dramatically.
01:04
So 70% of our inner city is gone and we're just beginning the rebuild phase so it's quite dramatic for a city of 400,000. And so the idea behind the application was to think about how we could support people finding the new places that are developing and popping up
01:23
around the city because that's changing quite dramatically over time where the traditional established places for people to go to have a party or the best club or the happening place or the cool place, all these places are changing quite dramatically. So we developed this application to allow people to rate how busy certain establishments were, existing establishments
01:43
or identify or highlight or notify us of new establishments. So thinking about the trust aspect of this, so we're all well familiar with OpenStreetMap as one of the main sort of crowdsourcing geospatial applications out there and the two key ways that OpenStreetMap
02:04
thinks about sort of trust or in a sense trust is one, they have some automated routines for checking the validity of sort of spatial features that are put up or two where you can have, you'll have neighbourhood wardens or people that are monitoring the new editions of data
02:21
or for a particular spatial region. So we are looking at trust from a slightly different perspective, thinking about how can we automatically assign a value of trust to an individual who's producing some spatial data with virtually no knowledge of that individual because all we have is maybe a user name and a little bit of information about their location
02:43
from the GPS of their phone. So just an overview of how it works, Sharone will go through in the technical details of how we've stitched together all the bits and pieces but just to give you the bigger picture. So a happening place, a pub or a bar or something and an individual is given the option of rating that place. You can rate it from busy with
03:03
a graduated colour scheme from busy to quiet and that when someone provides a trust or provides some geospatial data, all we have is information about the user name and a little bit of information about their location and so what we've done is we've built into the application a little bit of a trust model which looks at two key characteristics,
03:26
one's spatial, so when an individual creates a rating, their location, how far there they are from the location of the place that they're rating, the distance between that gives us a measure of trust. So for example if I was in Christchurch and if I was at
03:45
the busy establishment noted and I created a rating, that would be a trustworthy rating. If I am rating it from here in Portland, given the location that we can get from the GPS and the cellphone, that would be a very poor and untrustworthy rating. The other aspect of the trust model includes the temporal characteristics, so if we have,
04:07
we're looking at trust ratings over time and if we have someone rating an establishment as very busy at 9pm and at 9.01pm they rate it as very quiet, the time difference between
04:21
the dramatic changes in ratings gives us a notion of trust as well. So just again we use just a simple graduated scheme, just quiet, average, busy, that individuals can use to rate the data. So we just tested out the application in Christchurch itself, just using some data that we have through coordinates, coordinates.com,
04:44
and we just grabbed a number of data sets including data sets of existing establishments with the view that we can also expand that as people find new establishments. So the data was derived from a provider called Zenmoo, and that is on Coordinate's website.
05:07
That was converted into MySQL database, so the table was then imported into MySQL database. The base maps load up from Google Maps and OSM. OSM I'm using MapQuest because
05:24
there's problem with the limited map loads thing, and the whole application is written in HTML5, so it's an Android application with iOS under development, but the application is not
05:41
a native application. So after, I'll go through a demo after this slide, but the PHP coding is done so it connects it to the database, and then the whole JavaScript thing and HTML5, all things are pushed onto Android platform, the web platform, and the iOS platform.
06:04
And these are some of the tools I used. This shows the database which has mainly three tables. The one which is the info table stores the places data, so it has places around 4,500 places
06:21
all around New Zealand. The other one which is the people data has my three, sorry, yeah,
06:40
the people stores my trust model which runs inside database itself. The trust model has three main things, distance, time, and the user count, so we count the number of users based on ratings. So once a user rates, the count is counted, and it's in the database which then goes
07:00
into the user table, and there's another table which is the people table which also which does the function of, so the trust rating is in the people table, and here's how we store the data. So we get lat and long from the user's GPS or Wi-Fi
07:28
or the mobile data, so that is how we know the location. Here I'll go to a demo. So yeah, first a user has to just download the application from the app, the Google Play Store.
07:44
Once it's installed, the user has to click in on the application, and there's a simple GUI which tells you what, so explains you how the application works. Then there's this rating button which when pressed, it takes you to the new WebView technology which is, which I used,
08:04
and this is how, and it automatically zooms into the application, to the place as well. So if the user is at say Pizza Hut near Christchurch, so the application will zoom into that. Here are some ratings, and you have to zoom out if you want to see other places.
08:25
There's a feedback button which I'll go through again after some time. This shows the three things, the average, quiet, and the busy, which is, and it's based on real-time ratings, so once if someone rates it as busy, it converts into busy.
08:48
If it's quiet, it's quiet, and if it's average, average. So I've used the same, so this is a Google Maps API version 3, so it has this info window which shows my place name,
09:06
place type, the trust level which goes up or down. There's this time of last rating which is also compared with the database, and the current rating, and the user has to select one of
09:21
these three ratings. Yeah, so the trust rating changes from 0 to 100 percent based on the three things, and the time is displayed from the database. We have this feedback button which also
09:41
I've included Google forms into it, so once a user clicks on the feedback button, the page is redirected to a feedback form. A user can update, delete, or add a place. Once this shows the update thing, the user can now fill in the form and then submit it.
10:08
We'll get the data and we can update it in a day or two, so this is how it works. Add a new place, the same thing. Yeah, there are some validations which I put on Google
10:27
forms as well, and this is to delete a place, so we'll get to know the place's name and we can delete it from the database. So we have a small website which has a link to the play store,
10:49
so one can download the application from that. These are the points which are around 4,500 points shown on the Google map from the database. We tested it at the University of Canterbury and
11:09
the feedback system was found useful because we have this Google form which then goes into sheets and we can always copy and paste from that.
11:23
I would like to include some features as well, like searching places, direction to the places they want to go to. We are going to include that. We are also going to update the database because we need to add new places as they come up.
11:46
The limitations are, one has to have a mobile network which is like having a working data connection. The dots do not change the size, as in there's a problem with the Google Maps API,
12:06
so I'm working on that as well. And the person's rating can depend upon his or her perception because one can rate the place as busy if he or she finds it busy or
12:22
he or she made it rated as average or something. Yeah, thank you. I just completed my Masters in Geomatics from India. Any questions or anything? Yeah. You said that updates take a couple of days
12:49
to show up. Why that long? Because right now we are using a manual system, which is like when we get data on Google Sheets, then we update it on the database. So that is why it takes a long time. Not a long time, but two days or so.
13:05
So we manually update it. So for that, with the updates, have you thought about implementing, especially like for delete, so if say 10 people within
13:21
two days said this place isn't here, go ahead and trigger it for some kind of threshold? Uh, sorry, I did not get your question. So you said, you're saying that if someone, some 10 people said delete this place. So yeah, would that be something that you could look at to help automate so you don't have to do all the manual updates?
13:40
Yeah, we can do that. So you started with mentioning that this research would come out with trust levels, right? Right. I missed that a bit in the end. So does it say anything about
14:01
trust level of individuals? Yeah, it is trust level of individuals. So of the individual as they produce data, as they contribute data, we give a trust rating to the data itself that they've contributed. It's not attached to the individual, rather to
14:22
the instance of data that they contribute. Because if you can trace or track people who do more of these ratings, then you could also create a profile, but you're not doing that? No, that's something that would be great to extend it to identify. I suppose you end up
14:43
giving a rating of expertise or ability to an individual, but that would be another really nice way. One of the reasons we didn't consider that was because we wanted to make it fairly lightweight and easy. We didn't want a complex registration process or anything like that, so people could download it just with a little username. I suppose you could trace
15:06
those usernames over time and give them better ratings if they're contributing good data. That might be a way to get a longer-term record of that, yeah. But we didn't want a complex registration process where you'd have to put in a whole lot of details that would
15:22
be the basis of the sign trust, maybe based on other things like LinkedIn profiles or other things. And we have specific IDs for the restaurants and bars and everything, so yeah, we can trace the users as well from that, once we assign the user IDs, yeah.
15:48
Thank you, very good. Sorry, congratulations on your degree, enjoyed the presentation. I understand, I understood the geographic distance between the reporter and what they're reporting
16:02
on, but I didn't quite understand the temporal verification of that and how that fit into your trust model. Yeah, so if you look at temporal distance, I suppose the time between ratings, and consider the changes in those ratings as well. So I'll go through that example again. If someone had a rating that was really busy at 9 p.m. and at 1 p.m. a short time later,
16:28
you had a sudden dramatic change in rating that would indicate that that may not be so trustworthy, or conversely, if you had a big temporal gap, there's sort of different connotations.
16:44
I'm pretty loud. I think I just answered my own question as soon as I started to say it, based off what you said, because it's not the actual, between multiple reports from an individual user, but it's between users, sequentially, correct? And do you have like a time window that you use, or is it just compared to the last one? Okay, so okay, then that's what
17:05
I was going to say. Well, who gets a ding, but it's not the user. It's just, okay, it used to be busy now, so we don't trust that one as much. So we take the time from the database and the last time used, last time rated, and that is how we compare that. But probably in some of these cases, people,
17:27
or maybe in most of the cases, people just report once they are at home, when they have a facility to do the reporting, or do you, and then there's a timeline, right? So then they report about, okay, one hour ago it was very busy in that particular facility?
17:45
Or do you assume that they report right away on their mobile? Yeah, that's the assumption, yep. That they could be incorporated in the future, they could, you know, backdate that time. But the idea is that it should be fairly timely, because, you know, the busyness of a place changes quite dramatically,
18:02
potentially over time, and you don't actually want an hour old time, an hour old rating, because it may be completely different to what it is now, so you want sort of ratings as they are happening. Okay, thank you.