Disconnected Geospatial Mobile & Open Source 5 Rules To Success?
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
Coulon, Pascal (SCISYS)
We present the challenges of building a disconnected geospatial mobile solution and devise five simple rules for the success of your app. This paper will look at the following key issues: Rule 1 Data Storage. Streaming GI data requires good bandwidth, by implementing a caching mechanism the end-user will always have access to the data for a given area. Rule 2 - Use Open Source. Free and Open Source software for GIS has evolved significantly in recent years and in some cases faster than commercial alternatives. The mobile field is a bit different and few experts are using free and open source mobile GIS, despite the good tools that exist. Rule 3 - Use Open Standards. In combination with the use of Open Source products, Open Standards can help future proof the solution. Rule 4 - Simplify User Interfaces. The time of the stylus is gone and users now expect to use their finger for driving the application. Specific attention must be paid to designing simple and clear user interfaces. Rule 5 - Implement Non native Solutions. Should separate solutions be developed for IPhone and Android? Could the answer be instead to actually develop non native solutions reducing development and maintenance costs. Armed with these rules we will look at the challenges on the road ahead to implementing your GI Mobile solution.
 Thanks very much, Yost. Well, thanks very much again for coming this afternoon. As you said, my name is Pascal Coulomb from Company Call Sizes. We are a British-based company, a system integrator, and really our drive is to integrate GI or geospatial solutions within the business or enterprise solutions. So really today, I'm going to try to take you through the various steps that at Sizes we follow to try to design and implement disconnected GI mobile on an open source platform, or actually probably more an open architecture. And really what I should start by addressing is what were the main drivers and considerations for us to try to move towards an open architecture. Well, the first aim really was like we all are over the last few years. We need to really reduce cost. But it's not just a question of reducing cost for the implementation of the solutions. It's also in terms of licensing, support, data, all these key elements of the solutions. As you probably know in Europe and particularly in the UK, we've got a strong emphasis from the governments to push us towards the use of open data, open source solutions. So that was a key driver for us. We also needed to look at the interoperability. But not just at the level of data. We needed to start considering interoperability at the level of the technology, the software, the hardware. What can we do to essentially feature proof the solutions and eventually try to reduce the risk to be even the locked? So I like to take a bit of an analogy when I talk about an open architecture. Yes, like Wikipedia will tell you, it's a set of computer software which is there to help you to quickly swap components. But when you consider that with LEGO, and I think it's reasonably good analogy, you end up being able to swap components. And from those little blocks, being able to build pretty much anything. Because essentially, it's a bit of an open format. You're able to change the component easily from a red block to a green block, to from a small to a large block. And the key thing is none of those blocks have got any business logic in it. And that's one of the key element that we had to really govern as we designed and implemented the solution is to remove any business logic from any of the client or data tier. The business logic should sit in the middle. And combining an open format with the coupled component, that's what drives the interoperability of your components. And ultimately, what will help you to reuse numbers of components across your solution and therefore drive the cost down as you implement your solutions. What I'll try to do today is over the next few slides, take you through five key points to try to increase the curve of your open architecture. And each time we'll go through one of these key government points, we'll get one star and so on, and see whether or not it is practical to put them in place, what are the pros and cons of implementing those values, government and rules. So the first one is open source. Yes, I'm sure we're all sold on the idea to use open source, particularly at force 4G. But we have to still sell open source to our clients. It's sometimes quite difficult. But I think in our case, it was quite obvious that open source was a strong contender. It's really well suited to deploy it on large numbers of device. We are in the GA industry, and the GA industry has benefited from open source product for a long time. And we are very good with open source to follow open standards. So that's, again, another element which glued together really give us a strong emphasis to future prove the solutions. But again, when it comes to open source, yes, we've got the ability to really understand the level of security, because we've got access to the source. And it is proven technologies reliable. Any major defect will be fixed very quickly by the community. And it goes without saying that as well, now across the UK and Europe more widely, there's more and more recommendations and direct recommendations from the government, like I mentioned here, where they actually directly tell us, well, now go for this type of open source product. But is that really, really just a clear answer? Maybe not. We need to be a bit mindful. And what I always use as an example when I'm saying, yes, open source is a very credible product. We've got two of the key mapping agencies across Europe, IGN in France and Ordnance Survey in the UK, who not only are actively using open source product, but are actually funding the development of those products to make it, for instance, inspire a compliant across Europe. So there is a clear evidence here that, yes, open source is the way forward and should strongly be considered. Interoperability, that's going to give you two stars. And this is all about how are you going to glue the various components. We've got all those Lego blocks, again, that are used as an analogy to start with. And this is very much what will help you to disseminate the data between the various components of your solutions. Because we're going to be using WMS, WMTS, we are fully able to actually swap between geo server, map server, open layer, leaflet. That's the beauty of it. We are not constrained to stay with one product, as one might actually disappear. Because open source doesn't mean that it's going to stay here forever. We can swap with a more up to date technology. Now, there's a lot of debate around, particularly, obviously, in the mobile industry. Should we go for native or non-native, or the like of HTML5 technology? In our instance, I think HTML5 gave us a strong headway, really, help us to implement solutions which could be easily deployed on multiple type of device. That means different type of obviously operating system, as well as different type of screen size with responsive design. Now, again, HTML5 brings us additional advantages, particularly in the GI industry. We've got the ability to do caching. The small amount of data can be cached. It can still be beneficial. We've got geolocation API. So all these elements combined brings us a lot of advantages. And it goes without saying as well, there's a number of JavaScript API. We've, I think, got a few presentation afterwards which highlight that fact, which are really well integrated with HTML5 and give you rapid development with big end user components, helping you to drive very nice design. Optimized storage, that has been one which caused us a lot of challenge. We had to be really mindful of obviously the fact that we were in a disconnected environment. Our end users, they're not working urban area. They're actually working mostly into remote area where there is very poor connectivity. I was looking around this morning for the sort of combined coverage, mobile coverage map in the UK, let alone. And actually, in most part of the UK, there is very limited or poor 3G coverage, even nowadays. And combined with the fact that we are looking at GI applications, those type of applications are hangry in bandwidth. So we really need to enable the end user with all the data on the device. And I'm including in that the like of what we call Westmaster map in the UK, this really fine detail mapping, which could take a large amount of data. And we only have a few gigabytes of space on our device. We also need to start thinking about the business data, which in our cases was over millions of recalls that needed to be displayed, like the client would really want with the right styling, but needed also full access to all the attributes to be able to be queried. So really, the key story here is you need to engage with your stakeholders very early, and you need to understand what are the priorities. Do you want to really display master map with the full color coding with the topographic area as we call it, or would just the topographic line be sufficient? Are you looking at generalizing the data? All those questions needs to be asked very early on with your end users. You want to make sure that you engage with your end users, so there is a high risk that they will not start using these applications as it comes live. You also need to look at interoperable data format, the like of ST geometry and so on. So that you've got the ability to swap again server, more course component for serving the data to the rest of the applications. Now, one of the key challenges we had was the provisions of the base mapping. We decided to use the like of TileCache. TileCache is great. It's an open format and very efficient, because actually you don't even need any sort of server layer to provide the data. You can access it directly through a web-accessible folder. Now, there is a bit of a downside to it. Yes, the smaller the tile is, the quicker it is to provide the data. But actually, the more space it takes on your hard disk, because at the end of the day, those little tiles, those little files, will go under the threshold of the block size on your hard disk. So you need to be very mindful of performance versus storage space. And we find out actually that particularly when trying to cache the like of master map data, especially in real-world area where there's very little informations, the best was 512 pixels by 512 to have the optimal performance, but also the best storage. Now, really, the next one is all about user interface. That is a key element, again, when designing a mobile applications. You need to be very mindful of where the user is going to have access to the applications. Are there more extreme environments? Are there other areas? So you need to make it simple, decluttered, large icons lots of user feedbacks. And indeed, again, that goes along with the idea of reducing the cost. You need to really embrace the concept of responsive design, which goes well with HTML5 indeed. So let's have a look at the solution building block. We were fortunate enough for the first device that we had our hands on is to go for a window 7 tablet. And those tablets actually are very powerful, dual CPUs, large amount of RAMs. So we decided actually to go for something which might sound a bit audacious, but we decided to start storing the data in Postgres with PostGIS, which gave us a strong way of managing the data, loading it in a convenient way. Serving the data was actually done by dual server, all loaded onto the local device. One thing to consider there are lots of people are thinking, wow, dual server really on a mobile? But yes, why not? You've only got one user. And those tablets are very powerful. And I can guarantee you that we're capable of serving several hundred thousands of features within sub seconds to the end users. So this is a credible solution. But again, we wanted to remain as open as possible so that dual server was not performing to the right level. We could actually consider alternative options. So any of the data would be served through WMS, WFS, WMTS. And again, the usual suspect really in terms of implementing the client applications, we're looking at the like of OpenAir, JavaScript, OpenAir, JavaScript, jQuery, mobile, very convenient type of product, allowing us to quickly implement the solution integrated into existing forms or even integrated with the local GPS on board of the device. But the key thing is, as I mentioned, is we've got the ability to actually swap Postgres with SQLite. There's no problem. You can do that. And that's still going to work. And you don't have to reengineer the whole solution. Maybe you would rather have leaflet rather than open layers in combinations with map server. Yes, you can do that as well. Now, as I suggested early on, yes, open source is great. But you need to be mindful, actually, that it's not always possible to go full open source in an organization. So you need to think about the touch point with other commercial product, which is actually one of the challenges we had here. We needed to enable touch point with the lack of a full on as re-entreprise architecture. But we also needed to make it simple to the end user to upgrade the base mapping as well as their business data. Just as a simple click, they needed to just have the data downloaded and dispatched. So that was actually enabled with the lack of tile cache, indeed, again, to generate the base mapping. And GDAL, OGR, has proven a really good, strong ally for us in terms of synchronizing the data with our central data store. But again, because we decoupled all components in the solutions, we have the ability to actually queue the values data captured on site and synchronize it at our convenience and using open components. So we've learned a lot of lessons. And the key one is around open source. It was new to our client to start using open source. You've understood. They were primarily using Esri. But yes, open source is a great way to reduce licensing. You don't have to pay anything when you deploy it across your mobile device. There is no maintenance cost as such as you get the patch whenever you want. You apply it in whenever you want. However, and there is a strong message. That's a very valuable one to actually demonstrate the power of open source. You don't have to be alone with open source. There is commercial solutions to support it. And that was a key enabler to demonstrate the power of open source. You've understood that the map cache was for us something that we had to work quite hard on it. And it's really about trading off performance versus storage size. But the use of a map cache should not just be considered for the base mapping. That's what we've discovered as we started to performance test the applications. Actually, for reasonably static business data, don't hesitate to cache it as well. That will obviously dramatically improve the performance of the applications. Particularly in the case where you've got end users, keep using the applications in the same location time after time. They might be surveying water meters into a street for days and days. And the data will be there for them. It will be fetched once and they're available for the duration of their service. So it's a great way to really improve the performance of the applications. And it goes without saying that because we use the OpenGI format, both at the level of storing the data and serving the data, we've really, really enabled openness in the architecture. And yes, HTML5, there's a lot of debates. We've seen the big player like Facebook, LinkedIn. They've all swapped to native platform. But we still believe that HTML5 was a key enabler for us to quickly implement the solutions for particularly on the client side, enabling us to deploy it on tablet PCs, Windows tablets, iPads, and so on. However, we're mindful that if we start needing more low level functionality, we would probably need to start considering a more native implementations. So thanks very much again for coming this afternoon. If you've got any questions, please do ask. Otherwise, you've got my contact details. And feel free to contact me at a later stage for any discussions or questions. OK. OK. Thank you very much, Pascal, reminding us the usefulness of open source and some of the issues with mobile development. And we have time for at least two questions, and this gentleman here. For an average performing current day phone, what kind of performance are you getting? Are you quite satisfied with it? Yeah, very much so. I mean, we're able to zoom from UK level all the way down to master map at the same performance as if you had Google map in front of you. Essentially, you pinch the screen, and you just zoom, zoom, zoom all the way down to master map. And even master map at the level of, let's say, Nottingham on a fairly high level scale, I'll get about two seconds, three seconds max to get the data. And we've got large numbers of point data, 170,000 thinking about it. And it takes us about 5, 10 seconds to get national coverage coming back in one go. So yeah, GeoServer was a bit of a scary thought at first, but actually, it does work for one user. Because those tablets are these days very powerful. So we should not discard it. And are you doing any feature editing or considering to like that? We do, yes. We've got the ability to scribble. But the key things, again, for us, we are not, even if it was connected at some point or synchronizing, we decoupling everything. So every single feature captured is stored as the like of GeoJSON. And then used by a service-oriented architecture on our central infrastructure enabling us to do long transactions or versioning and so on. So actually, we have some time for more questions. Just a gentleman over here. Yeah, a couple of questions. Have you actually got a tablet that you could show us? I mean, not now, but the sort of thing. Yes, I could show you something probably, yes, on an iPad later on. I could probably show you something. On an iPad, but I thought you said it was a Windows 8 tablet. Yes, but we've already ported the front end onto an iPad. Oh, OK. Because I was particularly interested in the combination of technology. Yeah, it was. I could come and talk to you later on, and I'll show you something. What was the deployment like? So I'd imagine that would be pretty complex, putting the whole stack on and rolling out the software. You're right. It could have been challenging, but we've got a very good build manager back to base who's done a fantastic job, and he's put everything into a simple executable. So the ICT guys are just doing a simple Windows installations, install JT, and then deploy Chrome automatically, because he works on Chrome primarily well. And the whole of GeoServer, Postgres, the data is already automatically. So it took a bit of effort, but it simplified, yes. Just one question or comment. You talked about the issue with the tiles and not using space efficiently. I wondered if you looked at the MB tiles format, which sort of gets over that to some degree. It's a slight performance overhead, but. Yes, I did look into this element, and I think at the time I might need a bit of discussions with you. I did not find the right way to serve it into the lack of open layers. I wanted to really bypass the lack of GeoServer and so on for serving my base mapping. I really wanted a direct access. Yeah, I think the tiles batch is something important. OK, that's useful. Nothing. I mean, one key thing to note is this was thought and designed around about a year ago. And one key observations I've had over the last three days with the AGI conference and now Force4G. There is a massive evolution of technology. We're now looking at querying data directly from HTML5 to backend database. So yeah, I think there's a leap forward. The whole architecture probably needs rethink, but there's some strong ideas here. Yeah, we go on with questions. The next session will start at 3. Hi, Pascal. I'm a running environment agency. You mentioned iPad port, which is of great interest. But what kind of software stack did you use to do things like feature data collection on an iPad? Because running the GeoServer and the iPad ain't going to work very well. No, we're looking at the front end, particularly, which is using the lack of open layers. And the key things for us, because we have the ability to connect to a backend infrastructure, for us everything is decoupled. So we are storing the data locally as open format, the lack of DOJ, CERNs, whatever really is convenient to open layers. And then that information is then queued back into our internal infrastructure and ultimately committed to the central database. Next. So we have time for one question. You were speaking for performance about size. And I was wondering about how do you deal with latency in mobile, because I know that you were speaking about the storage, but my main concern is about the latency you have on the network on mobile. How do you deal with this? Or how do you evaluate this use case? Well, the first thing is to note, you mentioned network. We are in a fully disconnected environment, so we don't have any latency on that front. And in terms of technology, in terms of storing the data, we've used solid state as it is with any modern tablets. And when you consider the millions of little files in the tile cache, for instance, this was of great benefit, obviously, to have a solid state. OK, thanks again, Pascal.
 Thanks very much, Yost.  Well, thanks very much again for coming this afternoon.  As you said, my name is Pascal Coulomb  from Company Call Sizes.  We are a British-based company, a system integrator,  and really our drive is to integrate GI  or geospatial solutions within the business  or enterprise solutions.  So really today, I'm going to try to take you  through the various steps that at Sizes  we follow to try to design and implement  disconnected GI mobile on an open source platform,  or actually probably more an open architecture.  And really what I should start by addressing  is what were the main drivers and considerations for us  to try to move towards an open architecture.  Well, the first aim really was like we  all are over the last few years.  We need to really reduce cost.  But it's not just a question of reducing cost  for the implementation of the solutions.  It's also in terms of licensing, support, data,  all these key elements of the solutions.  As you probably know in Europe and particularly in the UK,  we've got a strong emphasis from the governments  to push us towards the use of open data, open source solutions.  So that was a key driver for us.  We also needed to look at the interoperability.  But not just at the level of data.  We needed to start considering interoperability  at the level of the technology, the software, the hardware.  What can we do to essentially feature proof the solutions  and eventually try to reduce the risk  to be even the locked?  So I like to take a bit of an analogy when  I talk about an open architecture.  Yes, like Wikipedia will tell you,  it's a set of computer software which  is there to help you to quickly swap components.  But when you consider that with LEGO,  and I think it's reasonably good analogy,  you end up being able to swap components.  And from those little blocks, being  able to build pretty much anything.  Because essentially, it's a bit of an open format.  You're able to change the component  easily from a red block to a green block,  to from a small to a large block.  And the key thing is none of those blocks  have got any business logic in it.  And that's one of the key element  that we had to really govern as we designed and implemented  the solution is to remove any business logic from any  of the client or data tier.  The business logic should sit in the middle.  And combining an open format with the coupled component,  that's what drives the interoperability of your components.  And ultimately, what will help you  to reuse numbers of components across your solution  and therefore drive the cost down  as you implement your solutions.  What I'll try to do today is over the next few slides,  take you through five key points to try to increase  the curve of your open architecture.  And each time we'll go through one of these key government  points, we'll get one star and so on,  and see whether or not it is practical to put them in place,  what are the pros and cons of implementing  those values, government and rules.  So the first one is open source.  Yes, I'm sure we're all sold on the idea  to use open source, particularly at force 4G.  But we have to still sell open source to our clients.  It's sometimes quite difficult.  But I think in our case, it was quite obvious  that open source was a strong contender.  It's really well suited to deploy it  on large numbers of device.  We are in the GA industry, and the GA industry  has benefited from open source product for a long time.  And we are very good with open source  to follow open standards.  So that's, again, another element which  glued together really give us a strong emphasis  to future prove the solutions.  But again, when it comes to open source,  yes, we've got the ability to really understand  the level of security, because we've got access to the source.  And it is proven technologies reliable.  Any major defect will be fixed very quickly by the community.  And it goes without saying that as well,  now across the UK and Europe more widely,  there's more and more recommendations  and direct recommendations from the government,  like I mentioned here, where they actually directly tell us,  well, now go for this type of open source product.  But is that really, really just a clear answer?  Maybe not.  We need to be a bit mindful.  And what I always use as an example when I'm saying,  yes, open source is a very credible product.  We've got two of the key mapping agencies across Europe,  IGN in France and Ordnance Survey in the UK,  who not only are actively using open source product,  but are actually funding the development of those products  to make it, for instance, inspire a compliant across Europe.  So there is a clear evidence here that, yes, open source  is the way forward and should strongly be considered.  Interoperability, that's going to give you two stars.  And this is all about how are you going  to glue the various components.  We've got all those Lego blocks, again,  that are used as an analogy to start with.  And this is very much what will help you  to disseminate the data between the various components  of your solutions.  Because we're going to be using WMS, WMTS,  we are fully able to actually swap between geo server, map  server, open layer, leaflet.  That's the beauty of it.  We are not constrained to stay with one product,  as one might actually disappear.  Because open source doesn't mean that it's  going to stay here forever.  We can swap with a more up to date technology.  Now, there's a lot of debate around, particularly, obviously,  in the mobile industry.  Should we go for native or non-native,  or the like of HTML5 technology?  In our instance, I think HTML5 gave us a strong headway,  really, help us to implement solutions which  could be easily deployed on multiple type of device.  That means different type of obviously operating system,  as well as different type of screen size  with responsive design.  Now, again, HTML5 brings us additional advantages,  particularly in the GI industry.  We've got the ability to do caching.  The small amount of data can be cached.  It can still be beneficial.  We've got geolocation API.  So all these elements combined brings us a lot of advantages.  And it goes without saying as well,  there's a number of JavaScript API.  We've, I think, got a few presentation afterwards  which highlight that fact, which are really well integrated  with HTML5 and give you rapid development  with big end user components, helping you  to drive very nice design.  Optimized storage, that has been one which  caused us a lot of challenge.  We had to be really mindful of obviously the fact  that we were in a disconnected environment.  Our end users, they're not working urban area.  They're actually working mostly into remote area  where there is very poor connectivity.  I was looking around this morning for the sort of combined  coverage, mobile coverage map in the UK, let alone.  And actually, in most part of the UK,  there is very limited or poor 3G coverage, even nowadays.  And combined with the fact that we  are looking at GI applications, those type of applications  are hangry in bandwidth.  So we really need to enable the end user with all the data  on the device.  And I'm including in that the like of what we call  Westmaster map in the UK, this really fine detail mapping,  which could take a large amount of data.  And we only have a few gigabytes of space on our device.  We also need to start thinking about the business data, which  in our cases was over millions of recalls  that needed to be displayed, like the client would really  want with the right styling, but needed also full access  to all the attributes to be able to be queried.  So really, the key story here is you  need to engage with your stakeholders very early,  and you need to understand what are the priorities.  Do you want to really display master map  with the full color coding with the topographic area  as we call it, or would just the topographic line  be sufficient?  Are you looking at generalizing the data?  All those questions needs to be asked very early on  with your end users.  You want to make sure that you engage with your end users,  so there is a high risk that they will not  start using these applications as it comes live.  You also need to look at interoperable data  format, the like of ST geometry and so on.  So that you've got the ability to swap again  server, more course component for serving the data  to the rest of the applications.  Now, one of the key challenges we had  was the provisions of the base mapping.  We decided to use the like of TileCache.  TileCache is great.  It's an open format and very efficient,  because actually you don't even need any sort of server  layer to provide the data.  You can access it directly through a web-accessible folder.  Now, there is a bit of a downside to it.  Yes, the smaller the tile is, the quicker  it is to provide the data.  But actually, the more space it takes on your hard disk,  because at the end of the day, those little tiles,  those little files, will go under the threshold  of the block size on your hard disk.  So you need to be very mindful of performance  versus storage space.  And we find out actually that particularly when  trying to cache the like of master map data,  especially in real-world area where there's very little  informations, the best was 512 pixels by 512  to have the optimal performance, but also the best storage.  Now, really, the next one is all about user interface.  That is a key element, again, when  designing a mobile applications.  You need to be very mindful of where  the user is going to have access to the applications.  Are there more extreme environments?  Are there other areas?  So you need to make it simple, decluttered, large icons  lots of user feedbacks.  And indeed, again, that goes along  with the idea of reducing the cost.  You need to really embrace the concept of responsive design,  which goes well with HTML5 indeed.  So let's have a look at the solution building block.  We were fortunate enough for the first device  that we had our hands on is to go for a window  7 tablet.  And those tablets actually are very powerful, dual CPUs,  large amount of RAMs.  So we decided actually to go for something  which might sound a bit audacious,  but we decided to start storing the data in Postgres  with PostGIS, which gave us a strong way of managing the data,  loading it in a convenient way.  Serving the data was actually done by dual server,  all loaded onto the local device.  One thing to consider there are lots of people are thinking,  wow, dual server really on a mobile?  But yes, why not?  You've only got one user.  And those tablets are very powerful.  And I can guarantee you that we're  capable of serving several hundred thousands of features  within sub seconds to the end users.  So this is a credible solution.  But again, we wanted to remain as open as possible  so that dual server was not performing to the right level.  We could actually consider alternative options.  So any of the data would be served through WMS, WFS, WMTS.  And again, the usual suspect really  in terms of implementing the client applications,  we're looking at the like of OpenAir, JavaScript,  OpenAir, JavaScript, jQuery, mobile, very convenient type  of product, allowing us to quickly implement the solution  integrated into existing forms or even integrated  with the local GPS on board of the device.  But the key thing is, as I mentioned,  is we've got the ability to actually swap Postgres  with SQLite.  There's no problem.  You can do that.  And that's still going to work.  And you don't have to reengineer the whole solution.  Maybe you would rather have leaflet  rather than open layers in combinations with map server.  Yes, you can do that as well.  Now, as I suggested early on, yes, open source is great.  But you need to be mindful, actually,  that it's not always possible to go full open source  in an organization.  So you need to think about the touch point  with other commercial product, which is actually  one of the challenges we had here.  We needed to enable touch point with the lack of a full on  as re-entreprise architecture.  But we also needed to make it simple to the end user  to upgrade the base mapping as well as their business data.  Just as a simple click, they needed  to just have the data downloaded and dispatched.  So that was actually enabled with the lack of tile cache,  indeed, again, to generate the base mapping.  And GDAL, OGR, has proven a really good, strong ally for us  in terms of synchronizing the data with our central data  store.  But again, because we decoupled all components  in the solutions, we have the ability  to actually queue the values data captured on site  and synchronize it at our convenience  and using open components.  So we've learned a lot of lessons.  And the key one is around open source.  It was new to our client to start using open source.  You've understood.  They were primarily using Esri.  But yes, open source is a great way to reduce licensing.  You don't have to pay anything when you deploy it  across your mobile device.  There is no maintenance cost as such  as you get the patch whenever you want.  You apply it in whenever you want.  However, and there is a strong message.  That's a very valuable one to actually demonstrate  the power of open source.  You don't have to be alone with open source.  There is commercial solutions to support it.  And that was a key enabler to demonstrate  the power of open source.  You've understood that the map cache was for us  something that we had to work quite hard on it.  And it's really about trading off performance versus storage  size.  But the use of a map cache should not just  be considered for the base mapping.  That's what we've discovered as we started to performance  test the applications.  Actually, for reasonably static business data,  don't hesitate to cache it as well.  That will obviously dramatically improve  the performance of the applications.  Particularly in the case where you've got end users,  keep using the applications in the same location time  after time.  They might be surveying water meters  into a street for days and days.  And the data will be there for them.  It will be fetched once and they're  available for the duration of their service.  So it's a great way to really improve  the performance of the applications.  And it goes without saying that because we  use the OpenGI format, both at the level of storing the data  and serving the data, we've really, really  enabled openness in the architecture.  And yes, HTML5, there's a lot of debates.  We've seen the big player like Facebook, LinkedIn.  They've all swapped to native platform.  But we still believe that HTML5 was a key enabler for us  to quickly implement the solutions for particularly  on the client side, enabling us to deploy it on tablet PCs,  Windows tablets, iPads, and so on.  However, we're mindful that if we start needing more low level  functionality, we would probably need  to start considering a more native implementations.  So thanks very much again for coming this afternoon.  If you've got any questions, please do ask.  Otherwise, you've got my contact details.  And feel free to contact me at a later stage  for any discussions or questions.  OK.  OK.  Thank you very much, Pascal, reminding us  the usefulness of open source and some of the issues  with mobile development.  And we have time for at least two questions,  and this gentleman here.  For an average performing current day phone,  what kind of performance are you getting?  Are you quite satisfied with it?  Yeah, very much so.  I mean, we're able to zoom from UK level all the way down  to master map at the same performance  as if you had Google map in front of you.  Essentially, you pinch the screen,  and you just zoom, zoom, zoom all the way down to master map.  And even master map at the level of, let's say, Nottingham  on a fairly high level scale, I'll get about two seconds,  three seconds max to get the data.  And we've got large numbers of point data,  170,000 thinking about it.  And it takes us about 5, 10 seconds  to get national coverage coming back in one go.  So yeah, GeoServer was a bit of a scary thought at first,  but actually, it does work for one user.  Because those tablets are these days very powerful.  So we should not discard it.  And are you doing any feature editing or considering  to like that?  We do, yes.  We've got the ability to scribble.  But the key things, again, for us, we are not,  even if it was connected at some point or synchronizing,  we decoupling everything.  So every single feature captured is  stored as the like of GeoJSON.  And then used by a service-oriented architecture  on our central infrastructure enabling  us to do long transactions or versioning and so on.  So actually, we have some time for more questions.  Just a gentleman over here.  Yeah, a couple of questions.  Have you actually got a tablet that you could show us?  I mean, not now, but the sort of thing.  Yes, I could show you something probably, yes,  on an iPad later on.  I could probably show you something.  On an iPad, but I thought you said it was a Windows 8 tablet.  Yes, but we've already ported the front end onto an iPad.  Oh, OK.  Because I was particularly interested  in the combination of technology.  Yeah, it was.  I could come and talk to you later on,  and I'll show you something.  What was the deployment like?  So I'd imagine that would be pretty complex,  putting the whole stack on and rolling out the software.  You're right.  It could have been challenging, but we've  got a very good build manager back to base  who's done a fantastic job, and he's  put everything into a simple executable.  So the ICT guys are just doing a simple Windows  installations, install JT, and then deploy Chrome  automatically, because he works on Chrome primarily well.  And the whole of GeoServer, Postgres, the data  is already automatically.  So it took a bit of effort, but it simplified, yes.  Just one question or comment.  You talked about the issue with the tiles  and not using space efficiently.  I wondered if you looked at the MB tiles format, which  sort of gets over that to some degree.  It's a slight performance overhead, but.  Yes, I did look into this element,  and I think at the time I might need a bit of discussions  with you.  I did not find the right way to serve it  into the lack of open layers.  I wanted to really bypass the lack of GeoServer and so on  for serving my base mapping.  I really wanted a direct access.  Yeah, I think the tiles batch is something important.  OK, that's useful.  Nothing.  I mean, one key thing to note is this was  thought and designed around about a year ago.  And one key observations I've had over the last three days  with the AGI conference and now Force4G.  There is a massive evolution of technology.  We're now looking at querying data directly from HTML5  to backend database.  So yeah, I think there's a leap forward.  The whole architecture probably needs rethink,  but there's some strong ideas here.  Yeah, we go on with questions.  The next session will start at 3.  Hi, Pascal.  I'm a running environment agency.  You mentioned iPad port, which is of great interest.  But what kind of software stack did you  use to do things like feature data collection on an iPad?  Because running the GeoServer and the iPad  ain't going to work very well.  No, we're looking at the front end, particularly,  which is using the lack of open layers.  And the key things for us, because we  have the ability to connect to a backend infrastructure,  for us everything is decoupled.  So we are storing the data locally as open format,  the lack of DOJ, CERNs, whatever really  is convenient to open layers.  And then that information is then  queued back into our internal infrastructure  and ultimately committed to the central database.  Next.  So we have time for one question.  You were speaking for performance about size.  And I was wondering about how do you deal with latency  in mobile, because I know that you were speaking  about the storage, but my main concern  is about the latency you have on the network on mobile.  How do you deal with this?  Or how do you evaluate this use case?  Well, the first thing is to note, you mentioned network.  We are in a fully disconnected environment,  so we don't have any latency on that front.  And in terms of technology, in terms of storing the data,  we've used solid state as it is with any modern tablets.  And when you consider the millions of little files  in the tile cache, for instance, this  was of great benefit, obviously, to have a solid state.  OK, thanks again, Pascal.
Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__0_1127.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__1128_2159.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__2160_2435.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__2436_2927.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__2928_3467.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__3468_5015.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__5016_5675.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__5676_7319.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__7320_7979.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__7980_8843.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__8844_8987.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__8988_10115.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__10116_10499.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__10500_12215.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__12216_12431.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__12432_12479.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__12480_15995.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__15996_17747.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__17748_18827.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__18828_19031.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__19032_19487.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__19488_19571.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__19572_19619.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__19620_19667.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__19668_19715.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__19716_20483.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__20484_20915.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__20916_21335.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__21336_21683.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__21684_21731.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__21732_21983.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__21984_23159.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__23160_23615.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__23616_24071.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__24072_26747.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__26748_28103.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__28104_30851.png Disconnected_Geospatial_Mobile____Open_Source__5_Rules_To_Success___720p__30852_38444.png