Building an open source imagery browser: UX and technical decisions to develop OpenAerialMap
Silva, Daniel da
Last summer the new OpenAerialMap launched. OpenAerialMap (OAM) is now providing access to open satellite, aerial, and UAV imagery around the world. Users can search through a web-based map browser, conduct geographic queries to an API, upload imagery to publish openly licensed imagery, and process imagery into tile map services. Searching through many sources of imagery in a usable way was one of the biggest challenges we saw when designing the system. We knew usability was going to be critical to the adoption and success of OAM so we created a new type of grid interaction to search and find imagery. This talk will present the design and technical build process for developing the new OAM map browser and the open source tools that power the system. We'll discuss our UX experiments and how they influenced the build process, and talk about how and why we used React JS to build a grid-based imagery browser. The OAM community of open source tools is growing over the next year. We'll also provide a recap of the roadmap for the next year and how anyone can get involved.
 Good morning everybody. My name is Manuel Grézonet. I'm from the French Space Agency. I'm working in Toulouse. And let's start the session. I think it's a nice way to continue after the keynote from the European Commission about the availability of lots of observation data. So let's start with OpenARL map. Hi everyone. My name is Daniela Silva. I work for Development Seed and I bring you OpenARL map, also known as Building an OpenSource Image Rebrowser, UX and Technical Decisions to Develop OpenARL Map. Yeah, I'm working on getting shorter titles for my talks because this is not going. Has anyone heard of OpenARL map before or the OEM project? Oh, wow. Okay. That's nice. Not expecting it. So I'm going to explain to everyone else what kind of problems we're trying to solve with this tool, why we decided to build it and then some considerations around decisions we had to make while developing it. So first things first, what kind of problems we're trying to solve? Why did we decide to build it? We noticed that there was a lack of imagery for disaster response and this kind of imagery usually needs to be as up to date and as available as possible. Users need to be able to find it pretty easily so to actually have an impact. So imagery from satellites and manned ARL vehicles and other types of aircraft become increasingly available after a disaster nowadays, especially because you have a lot of organizations and even individuals that just capture a lot of imagery that then share with the world. So what OpenARL map tries to do is to provide a simple way for users to search, find and then use this kind of image for humanitarian response and disaster preparedness. A good example of this, it's actually during the Ebola outbreak in Mamugini. You can see the progress of the OSM edits in the background happening and this was done using ARL footage. So 68 volunteers were able to map this big region in a very short time and this is very important for disaster preparedness because then the proper authorities can get to the different places, they can know what kind of facilities are available, where they are and this can actually make a significant change in people's lives and how help is got to a place. The OpenImage Network is actually the base upon which the OAM project is built. It's a network of openly licensed image using Creative Commons by 4.0. It's a distributed system, not in the usual IT sense of distributed systems but in a sense that any person or entity can actually host one of these OIN nodes and it's actually pretty easy to do so and to contribute with imagery to our system. Essentially we have two ways. First one is to host one of these nodes yourselves. You follow the instructions that are listed on the readme, you have to release the imagery under CC by 4.0 so it needs to be open and available for anyone and then once you add your information to the register you're done and it's available, it's out there for anyone to use. However, if you can't afford to host a node, if you don't want to do so, if you don't have the technical skills or the time to maintain one, you can still up us out. You can still contribute with imagery. You can use the uploader which is a form that we built and upload images to the hot OIN node. I'm going to get to the form a little bit further in the next slide. Okay, I've mentioned OAM, I mentioned Open Error Map but what is this? What am I talking about here? So OAM is actually a set of tools. So we have different little components and we use them to find and share the imagery that's available on the OIN. So the first component is the catalog. The catalog is responsible for indexing all the imagery in all the nodes in the OIN and then making it available through this powerful API. Supports filtering by different properties like a bounding box, the provider, acquisition date, basically any property that's available. However, this catalog, although can allow users to find all the imagery they're looking for, it's very geared towards power users. Not every user is able to understand an API response. Not every user is able to use an API. And so at this point we needed a way for the average Joe to be able to use it, to be able to query the system and get the information they wanted. So enters the browser as a solution. The OAM or the OAM browser provides or tries to provide a simple way for your common user to search, find and use this kind of imagery. Okay, let's see if we can get a little demo of this working. Okay, so I'm going to speak louder because I want to have a mic here. So this is actually the browser as it is right now. It provides a grid-based interaction so users can search for a specific location or they can just browse the world that will and find whatever place they're looking for. Each cell is shaded according to the number of images available and then you get a little number that tells you how many footprints are available in this specific cell. So let's look something up. So once you select something you get a preview of the footprint and then you can have a quick preview on the map. This image is a very low resolution one so it comes from Landsat 8 and for a satellite you get like a very, very big image. But I happen to know that we have very nice ones in the Philippines so let's go to those. Okay, so this is a nice one. As you can see it's long, a little spec because this image covers an incredibly small area. It's captured by a UAV but it's incredibly high resolution so 4 centimeters. This is very, very good for tracing purposes and so once a user has found what kind of image they're looking for they can either download it or they can use it directly in for example OSMID or Jawsome or just any software that supports TMSs. To be able to find images more easily and also to comply with the API we also support simple filtering like by time frame or by the resolution you're looking for or even if you want all images or just the ones with TMSs. So in brief this is what the browser does and how it looks like. And we're back. So the grid, the actual browser grid was the most difficult thing to do in the old project not just technically but also conceptually. We had to figure out a way to show a lot of imagery in a simple way but yet powerful. Some way that would not overwhelm the user. Our first try was to just place all the footprints on the map and see how this would work. So it didn't of course. It's a lot of noise. You can't really figure out where things end or where things start and you are not able to actually pick a specific footprint. We have different sensors, we have images covering different areas coming from satellites, UAVs, drones that then people stitch all the images together. So this kind of approach doesn't really work. And so drawing inspiration from the hex grid experiments of Torf.js and the battleship game actually we ended up playing a few rounds. We came up with this kind of core plot grid. Basically it's a cell grid that covers the whole earth and then each cell is colored according to the number of footprints that intersect it. So lighter colors, less footprints, darker color, more footprints. It's very easy for the user to understand. It's very easy to navigate because lighter areas less, darker areas more and it's simple. The user can just find the areas they're looking for and then you can zoom in and more granularly pick whatever you're looking for. So the idea was there. Now the building process. We ended up having three different iterations of this grid. So the first option that we started with was to draw a grid based on geographical coordinates. This seemed to work well but then we started moving away from the equator and we got rectangles instead of squares. And this was also a bit problematic for the user because for someone that doesn't keep in mind how the maps work and that you have like a projection and the earth is round, it's weird. It seemed that we were covering more area as we moved away from the equator although this is not true. The user would just get confused with this and then you get to the poles and the rectangles are so long it becomes difficult to use. And so we changed our approach to a kind of pixel perfect grid which we call the pixel perfect grid. It's drawn based on pixels of course by converting between coordinates and pixels every time. It's not as geographically accurate as the other one because once you get to near the poles, since the squares are all the same size, they take up a smaller area but from a navigation standpoint this is not a problem because the intersections will be still calculated correctly and so we won't be lying to the user. So this is how it would work. However this adds some problems of its own. It was not performant at all. So as you can see, okay, as I, sorry, this was just playing on the other screen. Interesting. Okay, let me get to the point I want. So here, so here we actually zoomed out of one level and as you can see the squares got smaller and the colors disappeared. Since we had like fixed size squares, as soon as we zoomed out one level, we needed to add more squares to the map and the browser just couldn't cope with this because the number of squares increased exponentially and the browser would just stop working. So we actually had to limit the zoom level and actually disable the coropleth at lower zoom levels. This was a big problem for the user because you would lose context. So at this level you wouldn't know where images were nor where to find them. You had to either zoom in and then pan. You couldn't have like a global view of the system which was also a problem. Okay, the solution for this was to use a zoom independent grid which is what's implemented right now and what we've seen on the browser. As you can see, the number of squares on screen is almost always the same and as you zoom in we have an increase on a ratio of 1 to 4. So each little square becomes four different squares once you zoom in. So you can see that one that says 26. When you zoom in, it will become four different squares. So this constant ratio makes so that the users don't lose context of what's happening and the area that they take up is always the same. So the square doesn't move and the imagery is not lost. This is way faster for the browser to render because the number of squares is lower. It's easy for the user and we can have the coroplet always visible which gives us a very nice world view like this. You can immediately see where imagery is and what's available. Okay, some text stack now. To build all of this, we used Mapbox for the map which will be giving fantastic talks as well, I heard. We have a lot of experience with working with Mapbox. It's a very powerful system. It supports powerful styling and it's very easily extensible. And then we decided to pair it with React. So when we started building this like one year ago or so, React showed a good promise and nice growth and evolution. It's open source, it has a good community and it's very simple to use. At development seed, we also often go and strive for cutting edge technologies and trying new approaches to things. In the past, we had actually tried to pair Mapbox and Angular but it turned out not to be as easy as with React. React's unidirectional data flow actually makes for a very nice integration between the two of them especially because of how it responds to the events and how it has the top to bottom rendering process which was also interesting. Besides all this, we use Travis to keep everything in check, to keep all the tests running and to keep everything deployed all in sync. So I've mentioned in the beginning some of the tools that make up OAM including the catalog and the browser which we've demoed actually. But we have some more, some other ones. So first one would be the uploader. So this is the tool you can use to upload images to the hot OIN node. It's also a form that we developed. It's not fully open to everyone. You need a token to be able to use it but it's super easy to get. You just have to state your intentions with kind of imagery you have and then you're assigned one and you're done. This is just so that we can try to reduce the number of spam images we get. We have like a documentation hub that basically gathers everything, every information about the project, why different tools were built, what they can do and actually also how to run your local copy. It's still, information is still being added to it. It's still in development. So if you browse it, you may find that coming soon message somewhere. And the last but not least, we have the design system. So design system here has enough material for a talk of its own. So I'm going to go over it very briefly. It's basically a set of styles, guidelines and other kinds of shareable code components that we use throughout OAM to ensure visual and behavioral consistency. If someone wants to start a new app or a new tool for OAM, they can just install this design system and they will have a bunch of pre-made tools and pre-made styles that they just use so that everything looks more or less part of the same branding. We have a nice blog post about design system. You can find it on tiny.cc slash design systems on why they're important and why we think they are a good approach to some types of projects. So what does the future look like for OAM? The first thing we want to do is to simplify the contribution process, how people can actually help us. Most of this will be done by simplifying the process of uploading imagery and contributing with imagery to the project. And we also are looking to get more organizations to have OAM nodes. So if any of you guys has images that they can share or they want to share or you can find them somewhere, please consider getting a node or if you can do that, just contribute through the uploader. That also always helps. Another way to get involved is with code. If you're a programmer, you can just contribute with code, help us out. Otherwise, just go over the tools we've built, give us opinions, give us ideas. Everything is open source, everything is available under the OTH OSM organization GitHub. So just check it out and let us know what you think. Okay. Thank you very much. We have some time for additional questions. If anyone wants to know anything about the... Just wondering, you probably have a lot of data in there which might be of interest for other people to ingest it automatically. Do you provide standardized interfaces of your data like CSW or is it like your own standard which is not ingestible by other catalogs automatically? At this moment, the only point of access we have, it's through the catalog, which is that JSON API where you can get information and metadata about all the images that we have. Is that something that you consider like providing the CSW interface because there probably was a community or a community or some people don't want to go to a different interface which is not a business night, but other people might prefer having it in their own catalog. That's interesting. It may be something we eventually consider. So CSW is an OGC standard, OGFACELS program standard, which defines like interface to query metadata from catalogs. For example, your network is one implementation of it and you have all the metadata in there and then you can have several nodes which can itself harvest from other catalogs and then they can be harvested for others because they didn't place loads well behind. By that you don't need to have like this interface there and then probably like an adapter for that interface there to have like that host. Yeah, definitely, definitely maybe something we will implement. Okay, thank you. Yeah, I have one question. The first place we get to get was like something about you have no community or community or community, so you have a person or a community or a community? Yeah, sure, definitely. It would be amazing actually. So I mean, yeah, if possible, would we have this person, the data, the digital license around it? Yeah, yeah, actually, yes. So as I said, you have the two ways to do it. You either host a node if you can and then you could be the owner, let's say, of the Belgium node or if you can't do that, you can just get the imagery and then upload it through the uploader form. But you have to make sure that you can do that and that the imagery can become available under CC by 4. But besides that, yes, it would be nice actually. You can have your own nodes because for example, yeah, that's already there. No, no, no, no. If you have the raw imagery, you can use the uploader, which is this one. Yeah, so this little form, it goes on, but basically you down here, you'd have fields for all the images and then you can just put the links of the images and upload them. And this uploads the hot OIN node, which is our node if you can't have your own. Yes, down there. Overlapping images on the browser. So the browser only allows for the preview of one image at a time. You get the side panel with all the images available for a specific cell and then you can just select whatever you want. There is some filtering allowed by like a time frame last year, last month, last week. But then once you have all the results, you just have to go like one by one, see the metadata and get whatever you want. If you're looking for a more powerful interaction, then the API would be the way to go. Yes, there. I'm not entirely sure. I think GeoTIFF is the best format you can upload the images in. Elevation data, we are not using it at the moment in the browser. We're not showing it, but it would be stored as a property in the database, maybe for future querying processes. Yes, yeah. Right now we are storing everything on Amazon S3 buckets. Sorry again. It's very easy to have an OAN node. You need to have a place which is accessible by everyone, like an S3 bucket or your own server, if you will. And then just follow the instructions on the readme, which is basically add the URLs to your node to the register, to OAN register, and that's it. Then we have a worker that runs, that indexes everything, and as long as your bucket is accessible, then it will find it, no problem. We have a question here. Right now it's English only. We don't have multilingual support for now, but it's something that we are considering for the future. Yeah, sure. All the code is open source. You can find us under hotOSM on GitHub. If you have the skills to do so, please. Anything else? No? Okay. Thank you very much again. You can find me under the... Or if you have more questions or want to talk in private, I'll be around. So just come and search for me. Thank you. Thank you.
 Good morning everybody.  My name is Manuel Grézonet.  I'm from the French Space Agency.  I'm working in Toulouse.  And let's start the session.  I think it's a nice way to continue after the keynote from the European Commission about  the availability of lots of observation data.  So let's start with OpenARL map.  Hi everyone.  My name is Daniela Silva.  I work for Development Seed and I bring you OpenARL map, also known as Building an OpenSource  Image Rebrowser, UX and Technical Decisions to Develop OpenARL Map.  Yeah, I'm working on getting shorter titles for my talks because this is not going.  Has anyone heard of OpenARL map before or the OEM project?  Oh, wow.  Okay.  That's nice.  Not expecting it.  So I'm going to explain to everyone else what kind of problems we're trying to solve with  this tool, why we decided to build it and then some considerations around decisions we  had to make while developing it.  So first things first, what kind of problems we're trying to solve?  Why did we decide to build it?  We noticed that there was a lack of imagery for disaster response and this kind of imagery  usually needs to be as up to date and as available as possible.  Users need to be able to find it pretty easily so to actually have an impact.  So imagery from satellites and manned ARL vehicles and other types of aircraft become  increasingly available after a disaster nowadays, especially because you have a lot of organizations  and even individuals that just capture a lot of imagery that then share with the world.  So what OpenARL map tries to do is to provide a simple way for users to search, find and  then use this kind of image for humanitarian response and disaster preparedness.  A good example of this, it's actually during the Ebola outbreak in Mamugini.  You can see the progress of the OSM edits in the background happening and this was done  using ARL footage.  So 68 volunteers were able to map this big region in a very short time and this is very  important for disaster preparedness because then the proper authorities can get to the  different places, they can know what kind of facilities are available, where they are  and this can actually make a significant change in people's lives and how help is got to a  place.  The OpenImage Network is actually the base upon which the OAM project is built.  It's a network of openly licensed image using Creative Commons by 4.0.  It's a distributed system, not in the usual IT sense of distributed systems but in a sense  that any person or entity can actually host one of these OIN nodes and it's actually pretty  easy to do so and to contribute with imagery to our system.  Essentially we have two ways.  First one is to host one of these nodes yourselves.  You follow the instructions that are listed on the readme, you have to release the imagery  under CC by 4.0 so it needs to be open and available for anyone and then once you add  your information to the register you're done and it's available, it's out there for anyone  to use.  However, if you can't afford to host a node, if you don't want to do so, if you don't have  the technical skills or the time to maintain one, you can still up us out.  You can still contribute with imagery.  You can use the uploader which is a form that we built and upload images to the hot OIN  node.  I'm going to get to the form a little bit further in the next slide.  Okay, I've mentioned OAM, I mentioned Open Error Map but what is this?  What am I talking about here?  So OAM is actually a set of tools.  So we have different little components and we use them to find and share the imagery  that's available on the OIN.  So the first component is the catalog.  The catalog is responsible for indexing all the imagery in all the nodes in the OIN and  then making it available through this powerful API.  Supports filtering by different properties like a bounding box, the provider, acquisition  date, basically any property that's available.  However, this catalog, although can allow users to find all the imagery they're looking  for, it's very geared towards power users.  Not every user is able to understand an API response.  Not every user is able to use an API.  And so at this point we needed a way for the average Joe to be able to use it, to be able  to query the system and get the information they wanted.  So enters the browser as a solution.  The OAM or the OAM browser provides or tries to provide a simple way for your common user  to search, find and use this kind of imagery.  Okay, let's see if we can get a little demo of this working.  Okay, so I'm going to speak louder because I want to have a mic here.  So this is actually the browser as it is right now.  It provides a grid-based interaction so users can search for a specific location or they  can just browse the world that will and find whatever place they're looking for.  Each cell is shaded according to the number of images available and then you get a little  number that tells you how many footprints are available in this specific cell.  So let's look something up.  So once you select something you get a preview of the footprint and then you can have a quick  preview on the map.  This image is a very low resolution one so it comes from Landsat 8 and for a satellite  you get like a very, very big image.  But I happen to know that we have very nice ones in the Philippines so let's go to those.  Okay, so this is a nice one.  As you can see it's long, a little spec because this image covers an incredibly small area.  It's captured by a UAV but it's incredibly high resolution so 4 centimeters.  This is very, very good for tracing purposes and so once a user has found what kind of  image they're looking for they can either download it or they can use it directly in  for example OSMID or Jawsome or just any software that supports TMSs.  To be able to find images more easily and also to comply with the API we also support  simple filtering like by time frame or by the resolution you're looking for or even  if you want all images or just the ones with TMSs.  So in brief this is what the browser does and how it looks like.  And we're back.  So the grid, the actual browser grid was the most difficult thing to do in the old project  not just technically but also conceptually.  We had to figure out a way to show a lot of imagery in a simple way but yet powerful.  Some way that would not overwhelm the user.  Our first try was to just place all the footprints on the map and see how this would work.  So it didn't of course.  It's a lot of noise.  You can't really figure out where things end or where things start and you are not able  to actually pick a specific footprint.  We have different sensors, we have images covering different areas coming from satellites,  UAVs, drones that then people stitch all the images together.  So this kind of approach doesn't really work.  And so drawing inspiration from the hex grid experiments of Torf.js and the battleship  game actually we ended up playing a few rounds.  We came up with this kind of core plot grid.  Basically it's a cell grid that covers the whole earth and then each cell is colored  according to the number of footprints that intersect it.  So lighter colors, less footprints, darker color, more footprints.  It's very easy for the user to understand.  It's very easy to navigate because lighter areas less, darker areas more and it's simple.  The user can just find the areas they're looking for and then you can zoom in and more granularly  pick whatever you're looking for.  So the idea was there.  Now the building process.  We ended up having three different iterations of this grid.  So the first option that we started with was to draw a grid based on geographical coordinates.  This seemed to work well but then we started moving away from the equator and we got rectangles  instead of squares.  And this was also a bit problematic for the user because for someone that doesn't keep  in mind how the maps work and that you have like a projection and the earth is round,  it's weird.  It seemed that we were covering more area as we moved away from the equator although this  is not true.  The user would just get confused with this and then you get to the poles and the rectangles  are so long it becomes difficult to use.  And so we changed our approach to a kind of pixel perfect grid which we call the pixel  perfect grid.  It's drawn based on pixels of course by converting between coordinates and pixels every time.  It's not as geographically accurate as the other one because once you get to near the  poles, since the squares are all the same size, they take up a smaller area but from  a navigation standpoint this is not a problem because the intersections will be still calculated  correctly and so we won't be lying to the user.  So this is how it would work.  However this adds some problems of its own.  It was not performant at all.  So as you can see, okay, as I, sorry, this was just playing on the other screen.  Interesting.  Okay, let me get to the point I want.  So here, so here we actually zoomed out of one level and as you can see the squares got  smaller and the colors disappeared.  Since we had like fixed size squares, as soon as we zoomed out one level, we needed to add  more squares to the map and the browser just couldn't cope with this because the number  of squares increased exponentially and the browser would just stop working.  So we actually had to limit the zoom level and actually disable the coropleth at lower  zoom levels.  This was a big problem for the user because you would lose context.  So at this level you wouldn't know where images were nor where to find them.  You had to either zoom in and then pan.  You couldn't have like a global view of the system which was also a problem.  Okay, the solution for this was to use a zoom independent grid which is what's implemented  right now and what we've seen on the browser.  As you can see, the number of squares on screen is almost always the same and as you zoom  in we have an increase on a ratio of 1 to 4.  So each little square becomes four different squares once you zoom in.  So you can see that one that says 26.  When you zoom in, it will become four different squares.  So this constant ratio makes so that the users don't lose context of what's happening and  the area that they take up is always the same.  So the square doesn't move and the imagery is not lost.  This is way faster for the browser to render because the number of squares is lower.  It's easy for the user and we can have the coroplet always visible which gives us a very  nice world view like this.  You can immediately see where imagery is and what's available.  Okay, some text stack now.  To build all of this, we used Mapbox for the map which will be giving fantastic talks as  well, I heard.  We have a lot of experience with working with Mapbox.  It's a very powerful system.  It supports powerful styling and it's very easily extensible.  And then we decided to pair it with React.  So when we started building this like one year ago or so, React showed a good promise  and nice growth and evolution.  It's open source, it has a good community and it's very simple to use.  At development seed, we also often go and strive for cutting edge technologies and trying  new approaches to things.  In the past, we had actually tried to pair Mapbox and Angular but it turned out not  to be as easy as with React.  React's unidirectional data flow actually makes for a very nice integration between  the two of them especially because of how it responds to the events and how it has the  top to bottom rendering process which was also interesting.  Besides all this, we use Travis to keep everything in check, to keep all the tests running and  to keep everything deployed all in sync.  So I've mentioned in the beginning some of the tools that make up OAM including the catalog  and the browser which we've demoed actually.  But we have some more, some other ones.  So first one would be the uploader.  So this is the tool you can use to upload images to the hot OIN node.  It's also a form that we developed.  It's not fully open to everyone.  You need a token to be able to use it but it's super easy to get.  You just have to state your intentions with kind of imagery you have and then you're assigned  one and you're done.  This is just so that we can try to reduce the number of spam images we get.  We have like a documentation hub that basically gathers everything, every information about  the project, why different tools were built, what they can do and actually also how to  run your local copy.  It's still, information is still being added to it.  It's still in development.  So if you browse it, you may find that coming soon message somewhere.  And the last but not least, we have the design system.  So design system here has enough material for a talk of its own.  So I'm going to go over it very briefly.  It's basically a set of styles, guidelines and other kinds of shareable code components  that we use throughout OAM to ensure visual and behavioral consistency.  If someone wants to start a new app or a new tool for OAM, they can just install this design  system and they will have a bunch of pre-made tools and pre-made styles that they just use  so that everything looks more or less part of the same branding.  We have a nice blog post about design system.  You can find it on tiny.cc slash design systems on why they're important and why we think  they are a good approach to some types of projects.  So what does the future look like for OAM?  The first thing we want to do is to simplify the contribution process, how people can actually  help us.  Most of this will be done by simplifying the process of uploading imagery and contributing  with imagery to the project.  And we also are looking to get more organizations to have OAM nodes.  So if any of you guys has images that they can share or they want to share or you can  find them somewhere, please consider getting a node or if you can do that, just contribute  through the uploader.  That also always helps.  Another way to get involved is with code.  If you're a programmer, you can just contribute with code, help us out.  Otherwise, just go over the tools we've built, give us opinions, give us ideas.  Everything is open source, everything is available under the OTH OSM organization  GitHub.  So just check it out and let us know what you think.  Okay.  Thank you very much.  We have some time for additional questions.  If anyone wants to know anything about the...  Just wondering, you probably have a lot of data in there which might be of interest for  other people to ingest it automatically.  Do you provide standardized interfaces of your data like CSW or is it like your own standard  which is not ingestible by other catalogs automatically?  At this moment, the only point of access we have, it's through the catalog, which is that  JSON API where you can get information and metadata about all the images that we have.  Is that something that you consider like providing the CSW interface because there probably was  a community or a community or some people don't want to go to a different interface  which is not a business night, but other people might prefer having it in their own catalog.  That's interesting.  It may be something we eventually consider.  So CSW is an OGC standard, OGFACELS program standard, which defines like interface to  query metadata from catalogs.  For example, your network is one implementation of it and you have all the metadata in there  and then you can have several nodes which can itself harvest from other catalogs and  then they can be harvested for others because they didn't place loads well behind.  By that you don't need to have like this interface there and then probably like an adapter for  that interface there to have like that host.  Yeah, definitely, definitely maybe something we will implement.  Okay, thank you.  Yeah, I have one question.  The first place we get to get was like something about you have no community or community  or community, so you have a person or a community or a community?  Yeah, sure, definitely.  It would be amazing actually.  So I mean, yeah, if possible, would we have this person, the data, the digital license  around it?  Yeah, yeah, actually, yes.  So as I said, you have the two ways to do it.  You either host a node if you can and then you could be the owner, let's say, of the  Belgium node or if you can't do that, you can just get the imagery and then upload it  through the uploader form.  But you have to make sure that you can do that and that the imagery can become available  under CC by 4.  But besides that, yes, it would be nice actually.  You can have your own nodes because for example, yeah, that's already there.  No, no, no, no.  If you have the raw imagery, you can use the uploader, which is this one.  Yeah, so this little form, it goes on, but basically you down here, you'd have fields  for all the images and then you can just put the links of the images and upload them.  And this uploads the hot OIN node, which is our node if you can't have your own.  Yes, down there.  Overlapping images on the browser.  So the browser only allows for the preview of one image at a time.  You get the side panel with all the images available for a specific cell and then you  can just select whatever you want.  There is some filtering allowed by like a time frame last year, last month, last week.  But then once you have all the results, you just have to go like one by one, see the metadata  and get whatever you want.  If you're looking for a more powerful interaction, then the API would be the way to go.  Yes, there.  I'm not entirely sure.  I think GeoTIFF is the best format you can upload the images in.  Elevation data, we are not using it at the moment in the browser.  We're not showing it, but it would be stored as a property in the database, maybe for future  querying processes.  Yes, yeah.  Right now we are storing everything on Amazon S3 buckets.  Sorry again.  It's very easy to have an OAN node.  You need to have a place which is accessible by everyone, like an S3 bucket or your own  server, if you will.  And then just follow the instructions on the readme, which is basically add the URLs to  your node to the register, to OAN register, and that's it.  Then we have a worker that runs, that indexes everything, and as long as your bucket is  accessible, then it will find it, no problem.  We have a question here.  Right now it's English only.  We don't have multilingual support for now, but it's something that we are considering  for the future.  Yeah, sure.  All the code is open source.  You can find us under hotOSM on GitHub.  If you have the skills to do so, please.  Anything else?  No?  Okay.  Thank you very much again.  You can find me under the...  Or if you have more questions or want to talk in private, I'll be around.  So just come and search for me.  Thank you.  Thank you.
foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_0_947.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_948_1091.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_1092_1187.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_1188_2171.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_2172_3335.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_3336_5099.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_5100_5171.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_5172_5243.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_5244_6143.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_6144_6563.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_6564_10583.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_10584_11507.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_11508_11639.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_11640_11915.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_11916_20411.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_20412_35879.png foss4g-2016-1304-building_an_open_source_imagery_browser_ux_and_technical_decisions_to_develop_opena_35880_36051.png
Good morning everybody. My name is Manuel Grézonet. I'm from the French Space Agency. I'm working in Toulouse. And let's start the session. I think it's a nice way to continue after the keynote from the European Commission about the availability of lots of observation data. So let's start with OpenARL map. Hi everyone. My name is Daniela Silva. I work for Development Seed and I bring you OpenARL map, also known as Building an OpenSource Image Rebrowser, UX and Technical Decisions to Develop OpenARL Map. Yeah, I'm working on getting shorter titles for my talks because this is not going. Has anyone heard of OpenARL map before or the OEM project? Oh, wow. Okay. That's nice. Not expecting it. So I'm going to explain to everyone else what kind of problems we're trying to solve with this tool, why we decided to build it and then some considerations around decisions we had to make while developing it. So first things first, what kind of problems we're trying to solve? Why did we decide to build it? We noticed that there was a lack of imagery for disaster response and this kind of imagery usually needs to be as up to date and as available as possible. Users need to be able to find it pretty easily so to actually have an impact. So imagery from satellites and manned ARL vehicles and other types of aircraft become increasingly available after a disaster nowadays, especially because you have a lot of organizations and even individuals that just capture a lot of imagery that then share with the world. So what OpenARL map tries to do is to provide a simple way for users to search, find and then use this kind of image for humanitarian response and disaster preparedness. A good example of this, it's actually during the Ebola outbreak in Mamugini. You can see the progress of the OSM edits in the background happening and this was done using ARL footage. So 68 volunteers were able to map this big region in a very short time and this is very important for disaster preparedness because then the proper authorities can get to the different places, they can know what kind of facilities are available, where they are and this can actually make a significant change in people's lives and how help is got to a place. The OpenImage Network is actually the base upon which the OAM project is built. It's a network of openly licensed image using Creative Commons by 4.0. It's a distributed system, not in the usual IT sense of distributed systems but in a sense that any person or entity can actually host one of these OIN nodes and it's actually pretty easy to do so and to contribute with imagery to our system. Essentially we have two ways. First one is to host one of these nodes yourselves. You follow the instructions that are listed on the readme, you have to release the imagery under CC by 4.0 so it needs to be open and available for anyone and then once you add your information to the register you're done and it's available, it's out there for anyone to use. However, if you can't afford to host a node, if you don't want to do so, if you don't have the technical skills or the time to maintain one, you can still up us out. You can still contribute with imagery. You can use the uploader which is a form that we built and upload images to the hot OIN node. I'm going to get to the form a little bit further in the next slide. Okay, I've mentioned OAM, I mentioned Open Error Map but what is this? What am I talking about here? So OAM is actually a set of tools. So we have different little components and we use them to find and share the imagery that's available on the OIN. So the first component is the catalog. The catalog is responsible for indexing all the imagery in all the nodes in the OIN and then making it available through this powerful API. Supports filtering by different properties like a bounding box, the provider, acquisition date, basically any property that's available. However, this catalog, although can allow users to find all the imagery they're looking for, it's very geared towards power users. Not every user is able to understand an API response. Not every user is able to use an API. And so at this point we needed a way for the average Joe to be able to use it, to be able to query the system and get the information they wanted. So enters the browser as a solution. The OAM or the OAM browser provides or tries to provide a simple way for your common user to search, find and use this kind of imagery. Okay, let's see if we can get a little demo of this working. Okay, so I'm going to speak louder because I want to have a mic here. So this is actually the browser as it is right now. It provides a grid-based interaction so users can search for a specific location or they can just browse the world that will and find whatever place they're looking for. Each cell is shaded according to the number of images available and then you get a little number that tells you how many footprints are available in this specific cell. So let's look something up. So once you select something you get a preview of the footprint and then you can have a quick preview on the map. This image is a very low resolution one so it comes from Landsat 8 and for a satellite you get like a very, very big image. But I happen to know that we have very nice ones in the Philippines so let's go to those. Okay, so this is a nice one. As you can see it's long, a little spec because this image covers an incredibly small area. It's captured by a UAV but it's incredibly high resolution so 4 centimeters. This is very, very good for tracing purposes and so once a user has found what kind of image they're looking for they can either download it or they can use it directly in for example OSMID or Jawsome or just any software that supports TMSs. To be able to find images more easily and also to comply with the API we also support simple filtering like by time frame or by the resolution you're looking for or even if you want all images or just the ones with TMSs. So in brief this is what the browser does and how it looks like. And we're back. So the grid, the actual browser grid was the most difficult thing to do in the old project not just technically but also conceptually. We had to figure out a way to show a lot of imagery in a simple way but yet powerful. Some way that would not overwhelm the user. Our first try was to just place all the footprints on the map and see how this would work. So it didn't of course. It's a lot of noise. You can't really figure out where things end or where things start and you are not able to actually pick a specific footprint. We have different sensors, we have images covering different areas coming from satellites, UAVs, drones that then people stitch all the images together. So this kind of approach doesn't really work. And so drawing inspiration from the hex grid experiments of Torf.js and the battleship game actually we ended up playing a few rounds. We came up with this kind of core plot grid. Basically it's a cell grid that covers the whole earth and then each cell is colored according to the number of footprints that intersect it. So lighter colors, less footprints, darker color, more footprints. It's very easy for the user to understand. It's very easy to navigate because lighter areas less, darker areas more and it's simple. The user can just find the areas they're looking for and then you can zoom in and more granularly pick whatever you're looking for. So the idea was there. Now the building process. We ended up having three different iterations of this grid. So the first option that we started with was to draw a grid based on geographical coordinates. This seemed to work well but then we started moving away from the equator and we got rectangles instead of squares. And this was also a bit problematic for the user because for someone that doesn't keep in mind how the maps work and that you have like a projection and the earth is round, it's weird. It seemed that we were covering more area as we moved away from the equator although this is not true. The user would just get confused with this and then you get to the poles and the rectangles are so long it becomes difficult to use. And so we changed our approach to a kind of pixel perfect grid which we call the pixel perfect grid. It's drawn based on pixels of course by converting between coordinates and pixels every time. It's not as geographically accurate as the other one because once you get to near the poles, since the squares are all the same size, they take up a smaller area but from a navigation standpoint this is not a problem because the intersections will be still calculated correctly and so we won't be lying to the user. So this is how it would work. However this adds some problems of its own. It was not performant at all. So as you can see, okay, as I, sorry, this was just playing on the other screen. Interesting. Okay, let me get to the point I want. So here, so here we actually zoomed out of one level and as you can see the squares got smaller and the colors disappeared. Since we had like fixed size squares, as soon as we zoomed out one level, we needed to add more squares to the map and the browser just couldn't cope with this because the number of squares increased exponentially and the browser would just stop working. So we actually had to limit the zoom level and actually disable the coropleth at lower zoom levels. This was a big problem for the user because you would lose context. So at this level you wouldn't know where images were nor where to find them. You had to either zoom in and then pan. You couldn't have like a global view of the system which was also a problem. Okay, the solution for this was to use a zoom independent grid which is what's implemented right now and what we've seen on the browser. As you can see, the number of squares on screen is almost always the same and as you zoom in we have an increase on a ratio of 1 to 4. So each little square becomes four different squares once you zoom in. So you can see that one that says 26. When you zoom in, it will become four different squares. So this constant ratio makes so that the users don't lose context of what's happening and the area that they take up is always the same. So the square doesn't move and the imagery is not lost. This is way faster for the browser to render because the number of squares is lower. It's easy for the user and we can have the coroplet always visible which gives us a very nice world view like this. You can immediately see where imagery is and what's available. Okay, some text stack now. To build all of this, we used Mapbox for the map which will be giving fantastic talks as well, I heard. We have a lot of experience with working with Mapbox. It's a very powerful system. It supports powerful styling and it's very easily extensible. And then we decided to pair it with React. So when we started building this like one year ago or so, React showed a good promise and nice growth and evolution. It's open source, it has a good community and it's very simple to use. At development seed, we also often go and strive for cutting edge technologies and trying new approaches to things. In the past, we had actually tried to pair Mapbox and Angular but it turned out not to be as easy as with React. React's unidirectional data flow actually makes for a very nice integration between the two of them especially because of how it responds to the events and how it has the top to bottom rendering process which was also interesting. Besides all this, we use Travis to keep everything in check, to keep all the tests running and to keep everything deployed all in sync. So I've mentioned in the beginning some of the tools that make up OAM including the catalog and the browser which we've demoed actually. But we have some more, some other ones. So first one would be the uploader. So this is the tool you can use to upload images to the hot OIN node. It's also a form that we developed. It's not fully open to everyone. You need a token to be able to use it but it's super easy to get. You just have to state your intentions with kind of imagery you have and then you're assigned one and you're done. This is just so that we can try to reduce the number of spam images we get. We have like a documentation hub that basically gathers everything, every information about the project, why different tools were built, what they can do and actually also how to run your local copy. It's still, information is still being added to it. It's still in development. So if you browse it, you may find that coming soon message somewhere. And the last but not least, we have the design system. So design system here has enough material for a talk of its own. So I'm going to go over it very briefly. It's basically a set of styles, guidelines and other kinds of shareable code components that we use throughout OAM to ensure visual and behavioral consistency. If someone wants to start a new app or a new tool for OAM, they can just install this design system and they will have a bunch of pre-made tools and pre-made styles that they just use so that everything looks more or less part of the same branding. We have a nice blog post about design system. You can find it on tiny.cc slash design systems on why they're important and why we think they are a good approach to some types of projects. So what does the future look like for OAM? The first thing we want to do is to simplify the contribution process, how people can actually help us. Most of this will be done by simplifying the process of uploading imagery and contributing with imagery to the project. And we also are looking to get more organizations to have OAM nodes. So if any of you guys has images that they can share or they want to share or you can find them somewhere, please consider getting a node or if you can do that, just contribute through the uploader. That also always helps. Another way to get involved is with code. If you're a programmer, you can just contribute with code, help us out. Otherwise, just go over the tools we've built, give us opinions, give us ideas. Everything is open source, everything is available under the OTH OSM organization GitHub. So just check it out and let us know what you think. Okay. Thank you very much. We have some time for additional questions. If anyone wants to know anything about the... Just wondering, you probably have a lot of data in there which might be of interest for other people to ingest it automatically. Do you provide standardized interfaces of your data like CSW or is it like your own standard which is not ingestible by other catalogs automatically? At this moment, the only point of access we have, it's through the catalog, which is that JSON API where you can get information and metadata about all the images that we have. Is that something that you consider like providing the CSW interface because there probably was a community or a community or some people don't want to go to a different interface which is not a business night, but other people might prefer having it in their own catalog. That's interesting. It may be something we eventually consider. So CSW is an OGC standard, OGFACELS program standard, which defines like interface to query metadata from catalogs. For example, your network is one implementation of it and you have all the metadata in there and then you can have several nodes which can itself harvest from other catalogs and then they can be harvested for others because they didn't place loads well behind. By that you don't need to have like this interface there and then probably like an adapter for that interface there to have like that host. Yeah, definitely, definitely maybe something we will implement. Okay, thank you. Yeah, I have one question. The first place we get to get was like something about you have no community or community or community, so you have a person or a community or a community? Yeah, sure, definitely. It would be amazing actually. So I mean, yeah, if possible, would we have this person, the data, the digital license around it? Yeah, yeah, actually, yes. So as I said, you have the two ways to do it. You either host a node if you can and then you could be the owner, let's say, of the Belgium node or if you can't do that, you can just get the imagery and then upload it through the uploader form. But you have to make sure that you can do that and that the imagery can become available under CC by 4. But besides that, yes, it would be nice actually. You can have your own nodes because for example, yeah, that's already there. No, no, no, no. If you have the raw imagery, you can use the uploader, which is this one. Yeah, so this little form, it goes on, but basically you down here, you'd have fields for all the images and then you can just put the links of the images and upload them. And this uploads the hot OIN node, which is our node if you can't have your own. Yes, down there. Overlapping images on the browser. So the browser only allows for the preview of one image at a time. You get the side panel with all the images available for a specific cell and then you can just select whatever you want. There is some filtering allowed by like a time frame last year, last month, last week. But then once you have all the results, you just have to go like one by one, see the metadata and get whatever you want. If you're looking for a more powerful interaction, then the API would be the way to go. Yes, there. I'm not entirely sure. I think GeoTIFF is the best format you can upload the images in. Elevation data, we are not using it at the moment in the browser. We're not showing it, but it would be stored as a property in the database, maybe for future querying processes. Yes, yeah. Right now we are storing everything on Amazon S3 buckets. Sorry again. It's very easy to have an OAN node. You need to have a place which is accessible by everyone, like an S3 bucket or your own server, if you will. And then just follow the instructions on the readme, which is basically add the URLs to your node to the register, to OAN register, and that's it. Then we have a worker that runs, that indexes everything, and as long as your bucket is accessible, then it will find it, no problem. We have a question here. Right now it's English only. We don't have multilingual support for now, but it's something that we are considering for the future. Yeah, sure. All the code is open source. You can find us under hotOSM on GitHub. If you have the skills to do so, please. Anything else? No? Okay. Thank you very much again. You can find me under the... Or if you have more questions or want to talk in private, I'll be around. So just come and search for me. Thank you. Thank you.
why we decided to build it and then some provide a simple way for users to search, find network of openly licensed image using Creative user is able to use an API. And so at this point use it, to be able to query the system and get browser as a solution. The OAM or the OAM browser right now. It provides a grid-based interaction they can just browse the world that will and find tells you how many footprints are available in show a lot of imagery in a simple way but yet grid experiments of Torf.js and the battleship the idea was there. Now the building process. We becomes difficult to use. And so we changed our now. To build all of this, we used Mapbox for the React. So when we started building this like one mentioned in the beginning some of the tools that the design system. So design system here has going to go over it very briefly. It's basically with imagery to the project. And we also are get involved is with code. If you're a Everything is open source, everything is only point of access we have, it's through the community or community or community, so you have you can just get the imagery and then upload it