Web-based Participatory GIS With Data Collection In The Field: A Prototype Architecture
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
Brovelli, Maria Antonia (Politecnico di Milano - DICA)
Minghini, Marco (Politecnico di Milano - DICA)
Zamboni, Giorgio (Politecnico di Milano - DICA)
Driven by the rise of Web 2.0 and the non-stop spread of mobile device sensors, the concept of PGIS (Participatory GIS) is knowing a new, revolutionary era. This research investigates the opportunity to build up a prototype of Participatory GIS, with completely FOSS architecture, in which data directly comes from field surveys carried out by users. As a result, the system should increase public active participation in data creation and sharing, besides enlarging the knowledge up to the local level. Open Data Kit suite allows users to collect geotagged multimedia information using mobile devices with on-board location sensors (e.g. a GPS receiver). Thanks to an authentication mechanism, on field-captured data is sent to a server and stored into a PostgreSQL database with PostGIS spatial extension. GeoServer is then responsible for data dissemination on the Web. On the client- side, different OpenLayers and Leaflet based solutions allow data visualization on both traditional computers and mobile platforms. The designed architecture provided support for FOSS usage in the process of gathering, uploading and WMS/WFS publishing information collected in situ. GIS user participation could thus be substantially increased, making this innovative bottom-up approach a key factor for fostering, speeding and improving decision-processes.
 Thank you, Yus, and good afternoon, everyone. Thank you for being here. So my name is Marco Minghini, and I work as a PhD student at Polytechnic Odimilano. And I will show you a work developed with Professor Braveli and Dr. Zamboni, which, as you can guess from the title, deals with the issue of participation within web-based GIS systems. But let's start from the beginning. So the context of the study is what we call geospatial web or geo-web. That can be defined as the set of tools, of services, of infrastructure related to the use of geospatial information over the web. But what do we have in this context? First of all, we have data. And you know, this data can come from different sources. We have users accessing data. And again, they can do it from a variety of possible instruments. We have data catalogs, and then we have data processing tools. Of course, the glue between all these elements is represented by the internet. But as you know, the rise of web 2.0 has dramatically overturned the paradigm of user interaction over the web. And this new model, which we can say is based on collaboration on sharing, online sharing of contents, has affected so much also the geo-web that the term geo-web 2.0 was coined. And actually, it was coined together with the series of other concepts like neo-geography. Neo-geography denotes the possibility also for non-expert users to build up their own apps using this new web mapping technologies. But for instance, also the concept of volunteer geographic information, which highlights the fact that geospatial information is no longer coming only from the top, as it was in the past, but also more and more from the bottom, so from the single users. And then, thanks to the incredible spread of mobile devices, the concept of PGIS, or participatory GIS, which actually was born in the mid-1990s, so much before web 2.0, this concept is acquiring more and more importance and is evolving towards some web-based and shared platforms where users can dynamically add and edit contents. But what are the requirements that such systems have to meet? First of all, as they embrace the entire community, they must provide interoperability in terms of both data formats and services. They also must be able to manage different users with, in principle, different privileges. And they must also allow these users to act on data, for instance, add data, save data, delay data, edit data, and so on, and also to create customized mesh apps. So this is the architecture, of course, an open source of this web-based participatory system that we developed. Now I would like to make just a very general overview, and then we go deeper into each part. But let's start from data collection on the field, which is achieved through this ODK, the Open Data Kit Suite, which is mainly composed of a server-side application called Aggregate, which is installed under Tomcat, and is connected to a PostgreSQL database, with, of course, a PostGIS special extension, and an Android application called ODKCollect, which is useful to feed our database with the user field register contents. These contents are then well-published, in this case, as WMS by GeoServer, and then they are accessible. They can be accessible, first of all, in two dimensions. We developed different viewers, for instance, for traditional computers using Open Layers, GeoX, the XJS, but also for mobile devices using, for instance, Leaflet, and again, Open Layers with JQuery Mobile. But we also developed a fully-publicitative 3D platform using the NASA WorldWind Virtual Globe. OK, let's start from data collection on the field, which, as I said, is accomplished by this Open Data Kit, the ODK Suite. I decided to make this sort of introduction about ODK, because I think it is the less known software among all those included in the architecture. So what to say, ODK is a toolkit, is free and open source, and it's currently used in hundreds of projects all around the world. It's composed of three different but complementary modules, which actually correspond to the three steps, if we want, of the data collection on the field. First of all, we have two alternative tools for creating the forms. The form are the questionnaires that users will then compile on the field. And they are ODK built in XLS form, I will show you in the following. Then we have this Android application called ODKCollect that allows users to fill the form and to send it to the server, or actually to the server side component, which is ODK Aggregate. It can run in the cloud, on a virtual machine, or, and this is our case, on a local server backed with a PostgreSQL database. This is a ODK build. It's an HTML5 web application, providing a very intuitive user interface, drag and drop user interface. And it supports a lot of fields. For instance, here you can see a date, the choice of one option within a list, a text field, but we can also register a position, using, for instance, the GPS of the device. And we can also upload multimedia contents. Here you see image, but also, audios and videos are supported. As I said, the alternative tool is called XLSForm. It allows to build more complex forms using just a spreadsheet. Anyway, in both cases, at the end of the process, the form is exported as an XML file at the end, and it is uploaded on the server. So once it is on the server, it is managed by ODK Aggregate component. And this application plays also the very important role of managing the different users that can have different privileges. For instance, users can have the right just to compile forms and send them to the server, or the right to also download forms, or to even create new forms, delete forms, and so on, to the administrator profile, which of course can also create and manage all the users. OK, once the form is on the server, using an Android device, we can download the ODK collect application, and we can start performing our survey. So this is the main page of the application. Of course, the first step is to connect to the server, and after the login is to choose the form we are interested in from the list of all the available forms. Here, for instance, we select this form called point of interest, which, as we will see later, will allow users to report some touristic and cultural points of interest. And then we can download the form. Then we start performing our survey. So we choose to fill a blank form. We access the point of interest form, and we arrive to the real questionnaire, which guides the user in the compilation of the different fields. For instance, the date of the survey, the type of point of interest, in this case, a historical monumental building, the, let's say, the nature of the subclassification of the point of interest. Here, a villa. The name of the point of interest, here it's Villa Homo. For those of you who are familiar with Lake Homo, it's a famous villa on Lake Homo. And then using the GPS, for instance, of the device, we can register the position. We provide us an image of the point of interest by taking a picture in real time, or by selecting a picture that is already available in the device archive, and finally, we save our form. So after filling the form, which, of course, does not require internet connection, we can choose if modifying the answers to the questionnaires, or if having this time an active internet connection to send the forms to the server. So here, I show you, again, the server side part of the architecture, just to let you understand how the ODK aggregate interacts with the other components. Actually, it's very easy, because when the forms come from ODK collect, which is the Android application, to the ODK aggregate server, they automatically fill the synchronized PostgreSQL database. And then it's very easy, because using PostGIS, GeoServer can read the data and can publish them as WMS, for instance. As I said, we developed some viewers, different viewers, according to the specifications and the requirements, the needs of the applications we were dealing with. For instance, this is a very simple, very traditional viewer, developed with open layers, GeoX and XJS, which simply represents our points of interest on top of a base map. If we click on a point of interest, WMS gets featured in for equities performed, and a pop-up shows the information that the user has originally collected on the field. This is a very similar application that we developed for a project involving some students of a secondary school who mapped the city center of Como, who mapped the architectural barriers of the city center of Como. So you should see different symbols, probably it's not so clear, but you should see different symbols for stairs, for ramps, and for pathways. And even if here we see just an image, they also determine for each of them if it was or not conformal to the current directive. This is just an example. Another example is this one, which is a client developed with the Leaflet JavaScript library. In the framework project, this time that we are starting with the Basin Authority of River Po, River Po is the longest river in Italy. Actually, they are starting to make some experiments on this participatory data correction in order to report damages or problems or environmental emergencies related to the river. As you can guess, this viewer is particularly suitable for large screen devices, so typically tablets. While this one is specifically thought for mobile devices and for small screen devices, typically smartphones. Here the flags that you see in the left figure are user reports of road pavement damages, which unfortunately has been a very serious problem in our city during the last winter. And what we did in this case is just to customize the SLD symbolization in geosurvers so that the flags are green, yellow, or red according to the entity, the dangerousness of the damage. And as you can see here, when the layer is clicked, the results of the query are represented in a separate page, which is much more suitable for these small screen devices. To summarize, in two dimensions, we have simply developed viewers. While in three dimensions, we developed a real participatory platform named Polycrowd. So Polycrowd, first of all, allows the three-dimensional visualization of our touristic points of interest using the NASA World Wing Virtual Globe. But this is not all because in Polycrowd, the users can also share their additional knowledge about points of interest and also the customized projects that they can create on top of the globe. Before entering the Polycrowd system, I would like to briefly introduce World Wing, which is the open source virtual globe developed by NASA. World Wing is actually available as an SDK. And so it's really customizable and provable. And then it's written in Java. So it's a multi-platform. Here you have just some of the possible features. Of course, if you want to know more, you can have a look at the website. We can just say that World Wing provides a pool of predefined, default layers, both satellite imagery and digital terrain models. But what really makes it suitable for scientific application is the fact that you can place on the globe, actually, whatever layer you want. And you can also customize the terrain information. For instance, if you have your own very high-resolution DTM, and if you need it for some three-dimensional analysis, you can use it in World Wing. OK, this is the Polycrowd architecture, again, divided in the server side and the client side. So the platform, which is available as a Java Web Start application, first of all, access is our layer of points of interest from your server, and it renders it on World Wing. Then, as I will show you in some minutes, the users can view, can edit, and can upload contents related to the points of interest using some webpages that are dynamically generated, both as JSP pages and server objects executed inside GlassFish. What is important is also this MySQL database, which allows to store additional information, like all the user profiles and the related privileges, but also the metadata related to the WMS layers that users can use inside the platform and all the projects that are saved within Polycrowd. Let's go step by step also here. So let's start from data visualization on World Wing. In this case, we actually created three different layers in GeoServer in order to represent our points of interest on the globe with three different symbolizations or levels of detail according to the altitude of the point of view over the globe. And in particular, for high altitudes, all the points are represented in the same way using place marks. By Siversa for medium altitudes, we use different icons according to the type of point of interest. And at small altitudes, we use other icons according to the nature of the point of interest. These are the same icons that are also available in the Android ODK collect application. But whatever is the altitude of the point of view, if we click on a point of interest, a balloon again appears showing all the field collected information and also the picture. If we look at the balloon, we see that the last word can be view or view slash edit according to the type of user. And in fact, one feature of Polycrowd is the possibility of registering to the platform, providing as usually a username and a password. And in fact, registered users can also add additional contents about point of interest while known registered users can just see what registered users have uploaded. This is an example of a web page of a point of interest for known registered users, while this is the corresponding one for registered users. You see that there is this button, which is the highlight, which allows registered users to add, for instance, an image, an audio file, a video file, or to enter a comment about the point of interest. Registered users can also create and save projects. And when I say save project, I mean save not just the list of all the available layers, but also all the contextual information, for instance, the position and the camera orientation of the point of view over the globe. All the saved projects are stored in a catalog. All the users can access this project, but of course, only the owner of a project can then modify it. And something else that only registered users can do is to connect to WMS servers and add layers in order to create customized mashups. Also in this case, all the layers that are added remains are stored in a catalog and remain available for the entire community. This is an example in which you see our point of interest, superimposed on a historical map and other WMS layers. I would like also to mention that this Polycrowd application was one of the winners of the first WorldWind Europe Challenge, which was a competition organized by NASA, and which was looking for, let's say, some WorldWind-based solutions for European community. I would like just to mention the other members of the team. So we were four students. Apart from me, Michele Bianchi, Roddy Jollac, and Andres Kignoneson, our mentor was Giorgio Zamboni. So thank you again to all of them. Conclusion. So we developed a free and open source architecture, allowing users to collect the georeferenced data on the field and to share them on the web. And in three dimensions, as I showed you, also really fully, let's say, a participative platform with also some other functionalities. We are thinking too many possible improvements, of course. But I would like just to mention one. That is an extension that we want to do to the Odyk collect Android application, because there can be a problem in the GPS positioning for mobile devices. Not just the problem related to the low accuracy in the positioning of the device itself, but also the problem related to the fact that the position where I perform the survey, which is, of course, my position, typically the position from which I take the picture, can, of course, be very different from the position of the point of interest that is being photographed. And for this reason, we are thinking to modify the Odyk collect in order to allow users to manually choose the position or to manually refine the GPS-estimated position using an interactive map. Of course, this would also allow positioning without using GPS or for devices without GPS. And then there is another point that is the synchronization of the user profiles on Odyk and Polycrowd so that the user can just register once and use both. Because up to now, it's not in this way. OK. I finished. So if you have questions, just ask. Thank you. Thank you very much, Marko. I think it was a crystal clear presentation. You led us to the requirements, the implementation, the results. And we're honest about everything here. But of course, there are still questions, I think. Are there questions? I know it was crystal clear. I'm curious about the 3D support. Any issues with navigation on a 2D device in a 3D world? Well, I forgot to mention, but this 3D navigation was just for computer. Because in WorldWind, they were developing also the Android version. But up to now, they stopped it. I mean, if you go to a website, probably you read that. The development is going on. But it's not true because they told us till the moment they stopped it. Of course, the performance are not the same as Google Earth. OK, of course, it's a quite new product. But I mean, it works. Let's say I have to say that our main goal was not to achieve great performance, but to provide an architecture that was working for our goal. Hi. I came across the open data kit for the first time last week, and it looked really nice. Do you know if there's plans to support anything other than Android, or do you have any idea how difficult that might be? Well, I know that it works only for Android. Then probably, you know, something more than me. No, I was just wondering if you knew. No, no, no, no, no, no. It works just for Android, up to now. Unfortunately, this is, let's say, the bad point. But Android devices should be more than all the other devices. I mean, from a statistics of last year. Hi. Have you had much participation as it been rolled out to the users? Are they using it successfully? Well, we did not publish this application, but we just proposed them to the people which could be interested. For instance, we published the application for reporting the road pavement damages to some administrations. And so we started some projects, possibly, for the future, because really, next year, we had these terrible problems about road damages in all the streets, and the municipalities had no money to intervene everywhere. But actually, all the applications you saw were restricted to a small group of applications, because we wanted to test, first of all, the architecture. OK, thanks. I still see questions. We have, well, like five minutes, I think. Yeah. So for clarification, did you say it sounds like you're running ODK on local database? This is on the mobile device, or you only did it on the web? No, no, no. It's not on the mobile device. OK, no, no, no. The database installed on a server, of course. Then you just connect. Of course, with your mobile device, you have to connect to the server just writing the URL and just getting from the server, and then sending forms to the server. Thanks. I want to see if it works in disconnected environment. Just curious. I can show you with my smartphone. We have one gentleman from here. Never mind. Thanks. Your architecture seems to have glassfish, as well as Tomcat. So haven't you got a bit of an overload of servlet? Well, it was just a choice related to the experience, also, of the students that had to work on that part. Because actually, we had to participate to that challenge. So we say, OK, we have to start also the use of my SQL instead of Postgres. Of course, it's something that could be done. I mean, it could be done, but there's no reason, actually, to use two different databases. So it was just a choice. OK, thanks. Well, probably, is there still questions? OK. Well, first of all, I want to thank the four speakers. Actually, we had four sessions.
 Thank you, Yus, and good afternoon, everyone.  Thank you for being here.  So my name is Marco Minghini, and I work as a PhD student  at Polytechnic Odimilano.  And I will show you a work developed  with Professor Braveli and Dr. Zamboni, which,  as you can guess from the title, deals  with the issue of participation within web-based GIS systems.  But let's start from the beginning.  So the context of the study is what  we call geospatial web or geo-web.  That can be defined as the set of tools, of services,  of infrastructure related to the use of geospatial information  over the web.  But what do we have in this context?  First of all, we have data.  And you know, this data can come from different sources.  We have users accessing data.  And again, they can do it from a variety of possible instruments.  We have data catalogs, and then we  have data processing tools.  Of course, the glue between all these elements  is represented by the internet.  But as you know, the rise of web 2.0  has dramatically overturned the paradigm of user interaction  over the web.  And this new model, which we can say  is based on collaboration on sharing, online sharing of contents,  has affected so much also the geo-web  that the term geo-web 2.0 was coined.  And actually, it was coined together  with the series of other concepts like neo-geography.  Neo-geography denotes the possibility also  for non-expert users to build up their own apps using  this new web mapping technologies.  But for instance, also the concept  of volunteer geographic information, which  highlights the fact that geospatial information is no  longer coming only from the top, as it was in the past,  but also more and more from the bottom,  so from the single users.  And then, thanks to the incredible spread of mobile devices,  the concept of PGIS, or participatory GIS,  which actually was born in the mid-1990s,  so much before web 2.0, this concept  is acquiring more and more importance  and is evolving towards some web-based and shared  platforms where users can dynamically add and edit  contents.  But what are the requirements that such systems have to meet?  First of all, as they embrace the entire community,  they must provide interoperability  in terms of both data formats and services.  They also must be able to manage different users  with, in principle, different privileges.  And they must also allow these users  to act on data, for instance, add data, save data,  delay data, edit data, and so on, and also  to create customized mesh apps.  So this is the architecture, of course,  an open source of this web-based participatory system  that we developed.  Now I would like to make just a very general overview,  and then we go deeper into each part.  But let's start from data collection on the field,  which is achieved through this ODK, the Open Data Kit Suite,  which is mainly composed of a server-side application called  Aggregate, which is installed under Tomcat,  and is connected to a PostgreSQL database, with, of course,  a PostGIS special extension, and an Android application  called ODKCollect, which is useful to feed our database  with the user field register contents.  These contents are then well-published, in this case,  as WMS by GeoServer, and then they are accessible.  They can be accessible, first of all, in two dimensions.  We developed different viewers, for instance,  for traditional computers using Open Layers, GeoX, the XJS,  but also for mobile devices using, for instance, Leaflet,  and again, Open Layers with JQuery Mobile.  But we also developed a fully-publicitative 3D platform  using the NASA WorldWind Virtual Globe.  OK, let's start from data collection on the field,  which, as I said, is accomplished by this Open Data Kit,  the ODK Suite.  I decided to make this sort of introduction about ODK,  because I think it is the less known software among all those  included in the architecture.  So what to say, ODK is a toolkit, is free and open source,  and it's currently used in hundreds of projects  all around the world.  It's composed of three different but complementary modules,  which actually correspond to the three steps,  if we want, of the data collection on the field.  First of all, we have two alternative tools  for creating the forms.  The form are the questionnaires that users will then  compile on the field.  And they are ODK built in XLS form,  I will show you in the following.  Then we have this Android application called  ODKCollect that allows users to fill the form  and to send it to the server, or actually to the server side  component, which is ODK Aggregate.  It can run in the cloud, on a virtual machine,  or, and this is our case, on a local server backed  with a PostgreSQL database.  This is a ODK build.  It's an HTML5 web application, providing a very intuitive user  interface, drag and drop user interface.  And it supports a lot of fields.  For instance, here you can see a date,  the choice of one option within a list, a text field,  but we can also register a position,  using, for instance, the GPS of the device.  And we can also upload multimedia contents.  Here you see image, but also, audios and videos are supported.  As I said, the alternative tool is called XLSForm.  It allows to build more complex forms using just a spreadsheet.  Anyway, in both cases, at the end of the process,  the form is exported as an XML file at the end,  and it is uploaded on the server.  So once it is on the server, it is managed by ODK Aggregate  component.  And this application plays also the very important role  of managing the different users that  can have different privileges.  For instance, users can have the right just to compile forms  and send them to the server, or the right to also download  forms, or to even create new forms,  delete forms, and so on, to the administrator profile, which  of course can also create and manage all the users.  OK, once the form is on the server, using an Android device,  we can download the ODK collect application,  and we can start performing our survey.  So this is the main page of the application.  Of course, the first step is to connect to the server,  and after the login is to choose the form we are interested  in from the list of all the available forms.  Here, for instance, we select this form called point of interest,  which, as we will see later, will allow users  to report some touristic and cultural points of interest.  And then we can download the form.  Then we start performing our survey.  So we choose to fill a blank form.  We access the point of interest form,  and we arrive to the real questionnaire, which  guides the user in the compilation of the different fields.  For instance, the date of the survey,  the type of point of interest, in this case,  a historical monumental building, the, let's say,  the nature of the subclassification  of the point of interest.  Here, a villa.  The name of the point of interest, here it's Villa Homo.  For those of you who are familiar with Lake Homo,  it's a famous villa on Lake Homo.  And then using the GPS, for instance, of the device,  we can register the position.  We provide us an image of the point of interest  by taking a picture in real time, or by selecting a picture that  is already available in the device archive,  and finally, we save our form.  So after filling the form, which, of course, does not  require internet connection, we can choose  if modifying the answers to the questionnaires,  or if having this time an active internet connection  to send the forms to the server.  So here, I show you, again, the server side part  of the architecture, just to let you understand  how the ODK aggregate interacts with the other components.  Actually, it's very easy, because when the forms come  from ODK collect, which is the Android application,  to the ODK aggregate server, they automatically  fill the synchronized PostgreSQL database.  And then it's very easy, because using PostGIS,  GeoServer can read the data and can publish them as WMS,  for instance.  As I said, we developed some viewers, different viewers,  according to the specifications and the requirements,  the needs of the applications we were dealing with.  For instance, this is a very simple, very traditional viewer,  developed with open layers, GeoX and XJS,  which simply represents our points of interest  on top of a base map.  If we click on a point of interest,  WMS gets featured in for equities performed,  and a pop-up shows the information  that the user has originally collected on the field.  This is a very similar application  that we developed for a project involving  some students of a secondary school who mapped the city  center of Como, who mapped the architectural barriers  of the city center of Como.  So you should see different symbols,  probably it's not so clear, but you  should see different symbols for stairs, for ramps,  and for pathways.  And even if here we see just an image,  they also determine for each of them  if it was or not conformal to the current directive.  This is just an example.  Another example is this one, which  is a client developed with the Leaflet JavaScript library.  In the framework project, this time  that we are starting with the Basin Authority of River  Po, River Po is the longest river in Italy.  Actually, they are starting to make some experiments  on this participatory data correction  in order to report damages or problems  or environmental emergencies related to the river.  As you can guess, this viewer is particularly  suitable for large screen devices, so typically tablets.  While this one is specifically thought  for mobile devices and for small screen devices,  typically smartphones.  Here the flags that you see in the left figure  are user reports of road pavement damages,  which unfortunately has been a very serious problem in our city  during the last winter.  And what we did in this case is just to customize the SLD  symbolization in geosurvers so that the flags are  green, yellow, or red according to the entity,  the dangerousness of the damage.  And as you can see here, when the layer is clicked,  the results of the query are represented  in a separate page, which is much more  suitable for these small screen devices.  To summarize, in two dimensions, we have simply  developed viewers.  While in three dimensions, we developed a real  participatory platform named Polycrowd.  So Polycrowd, first of all, allows  the three-dimensional visualization  of our touristic points of interest  using the NASA World Wing Virtual Globe.  But this is not all because in Polycrowd,  the users can also share their additional knowledge  about points of interest and also  the customized projects that they can  create on top of the globe.  Before entering the Polycrowd system,  I would like to briefly introduce  World Wing, which is the open source virtual globe  developed by NASA.  World Wing is actually available as an SDK.  And so it's really customizable and provable.  And then it's written in Java.  So it's a multi-platform.  Here you have just some of the possible features.  Of course, if you want to know more,  you can have a look at the website.  We can just say that World Wing provides  a pool of predefined, default layers,  both satellite imagery and digital terrain models.  But what really makes it suitable for scientific application  is the fact that you can place on the globe, actually,  whatever layer you want.  And you can also customize the terrain information.  For instance, if you have your own very high-resolution DTM,  and if you need it for some three-dimensional analysis,  you can use it in World Wing.  OK, this is the Polycrowd architecture,  again, divided in the server side and the client side.  So the platform, which is available as a Java Web  Start application, first of all, access  is our layer of points of interest from your server,  and it renders it on World Wing.  Then, as I will show you in some minutes,  the users can view, can edit, and can upload contents related  to the points of interest using some webpages that  are dynamically generated, both as JSP pages  and server objects executed inside GlassFish.  What is important is also this MySQL database, which  allows to store additional information,  like all the user profiles and the related privileges,  but also the metadata related to the WMS layers  that users can use inside the platform  and all the projects that are saved within Polycrowd.  Let's go step by step also here.  So let's start from data visualization on World Wing.  In this case, we actually created three different layers  in GeoServer in order to represent  our points of interest on the globe  with three different symbolizations or levels  of detail according to the altitude of the point  of view over the globe.  And in particular, for high altitudes,  all the points are represented in the same way  using place marks.  By Siversa for medium altitudes, we  use different icons according to the type of point of interest.  And at small altitudes, we use other icons  according to the nature of the point of interest.  These are the same icons that are also  available in the Android ODK collect application.  But whatever is the altitude of the point of view,  if we click on a point of interest,  a balloon again appears showing all the field  collected information and also the picture.  If we look at the balloon, we see that the last word can be  view or view slash edit according to the type of user.  And in fact, one feature of Polycrowd  is the possibility of registering to the platform,  providing as usually a username and a password.  And in fact, registered users can also  add additional contents about point of interest  while known registered users can just  see what registered users have uploaded.  This is an example of a web page of a point of interest  for known registered users, while this  is the corresponding one for registered users.  You see that there is this button, which  is the highlight, which allows registered users to add,  for instance, an image, an audio file, a video file,  or to enter a comment about the point of interest.  Registered users can also create and save projects.  And when I say save project, I mean  save not just the list of all the available layers,  but also all the contextual information,  for instance, the position and the camera orientation  of the point of view over the globe.  All the saved projects are stored in a catalog.  All the users can access this project,  but of course, only the owner of a project can then modify it.  And something else that only registered users can do  is to connect to WMS servers and add layers  in order to create customized mashups.  Also in this case, all the layers that are added  remains are stored in a catalog and remain  available for the entire community.  This is an example in which you see our point of interest,  superimposed on a historical map and other WMS layers.  I would like also to mention that this Polycrowd application  was one of the winners of the first WorldWind Europe  Challenge, which was a competition organized by NASA,  and which was looking for, let's say,  some WorldWind-based solutions for European community.  I would like just to mention the other members of the team.  So we were four students.  Apart from me, Michele Bianchi, Roddy Jollac,  and Andres Kignoneson, our mentor was Giorgio Zamboni.  So thank you again to all of them.  Conclusion.  So we developed a free and open source architecture,  allowing users to collect the georeferenced data on the field  and to share them on the web.  And in three dimensions, as I showed you, also really fully,  let's say, a participative platform with also  some other functionalities.  We are thinking too many possible improvements, of course.  But I would like just to mention one.  That is an extension that we want to do to the Odyk  collect Android application, because there  can be a problem in the GPS positioning  for mobile devices.  Not just the problem related to the low accuracy  in the positioning of the device itself,  but also the problem related to the fact  that the position where I perform the survey, which  is, of course, my position, typically the position from which  I take the picture, can, of course,  be very different from the position of the point of interest  that is being photographed.  And for this reason, we are thinking  to modify the Odyk collect in order  to allow users to manually choose the position  or to manually refine the GPS-estimated position  using an interactive map.  Of course, this would also allow positioning  without using GPS or for devices without GPS.  And then there is another point that  is the synchronization of the user profiles on Odyk  and Polycrowd so that the user can just  register once and use both.  Because up to now, it's not in this way.  OK.  I finished.  So if you have questions, just ask.  Thank you.  Thank you very much, Marko.  I think it was a crystal clear presentation.  You led us to the requirements, the implementation,  the results.  And we're honest about everything here.  But of course, there are still questions, I think.  Are there questions?  I know it was crystal clear.  I'm curious about the 3D support.  Any issues with navigation on a 2D device in a 3D world?  Well, I forgot to mention, but this 3D navigation  was just for computer.  Because in WorldWind, they were developing also  the Android version.  But up to now, they stopped it.  I mean, if you go to a website, probably you read that.  The development is going on.  But it's not true because they told us  till the moment they stopped it.  Of course, the performance are not the same as Google Earth.  OK, of course, it's a quite new product.  But I mean, it works.  Let's say I have to say that our main goal was not  to achieve great performance, but to provide an architecture  that was working for our goal.  Hi.  I came across the open data kit for the first time  last week, and it looked really nice.  Do you know if there's plans to support anything  other than Android, or do you have any idea how difficult  that might be?  Well, I know that it works only for Android.  Then probably, you know, something more than me.  No, I was just wondering if you knew.  No, no, no, no, no, no.  It works just for Android, up to now.  Unfortunately, this is, let's say, the bad point.  But Android devices should be more than all the other devices.  I mean, from a statistics of last year.  Hi.  Have you had much participation as it  been rolled out to the users?  Are they using it successfully?  Well, we did not publish this application,  but we just proposed them to the people which  could be interested.  For instance, we published the application  for reporting the road pavement damages  to some administrations.  And so we started some projects, possibly,  for the future, because really, next year,  we had these terrible problems about road damages  in all the streets, and the municipalities had no money  to intervene everywhere.  But actually, all the applications you saw  were restricted to a small group of applications,  because we wanted to test, first of all, the architecture.  OK, thanks.  I still see questions.  We have, well, like five minutes, I think.  Yeah.  So for clarification, did you say it  sounds like you're running ODK on local database?  This is on the mobile device, or you only did it on the web?  No, no, no.  It's not on the mobile device.  OK, no, no, no.  The database installed on a server, of course.  Then you just connect.  Of course, with your mobile device,  you have to connect to the server just writing the URL  and just getting from the server,  and then sending forms to the server.  Thanks.  I want to see if it works in disconnected environment.  Just curious.  I can show you with my smartphone.  We have one gentleman from here.  Never mind.  Thanks.  Your architecture seems to have glassfish,  as well as Tomcat.  So haven't you got a bit of an overload of servlet?  Well, it was just a choice related to the experience,  also, of the students that had to work on that part.  Because actually, we had to participate to that challenge.  So we say, OK, we have to start also the use of my SQL  instead of Postgres.  Of course, it's something that could be done.  I mean, it could be done, but there's no reason, actually,  to use two different databases.  So it was just a choice.  OK, thanks.  Well, probably, is there still questions?  OK.  Well, first of all, I want to thank the four speakers.  Actually, we had four sessions.
Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__0_527.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__528_1415.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__1416_3347.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__3348_4199.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__4200_6419.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__6420_6467.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__6468_8447.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__8448_8843.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__8844_11135.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__11136_12263.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__12264_13043.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__13044_13883.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__13884_14735.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__14736_15659.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__15660_16835.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__16836_17699.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__17700_19127.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__19128_20531.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__20532_21287.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__21288_21539.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__21540_21827.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__21828_22199.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__22200_22283.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__22284_22583.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__22584_22859.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__22860_23015.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__23016_23147.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__23148_23375.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__23376_24131.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__24132_24647.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__24648_24863.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__24864_25691.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__25692_31103.png Web-based_Participatory_GIS_With_Data_Collection_In_The_Field__A_Prototype_Architecture__720p__31104_35075.png