Handling GeoTIFFs in client-side code with GDAL and Loam
CC Attribution 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 purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Dohler, Derek
GDAL provides extensive capabilities for processing GeoTIFFs and other spatial data formats. However, until recently, the use of GDAL in web applications was limited to server-side code. This talk will describe how we use WebAssembly and a new wrapper library we developed, called Loam, to make GDAL's suite of tools accessible from client-side code. This strategy enables improved user experiences and can lower infrastructure costs for web applications handling GeoTIFFs and other spatial data. This talk will cover: - Description of WebAssembly and how it enables GDAL to be run within a web browser. - Description of the Loam wrapper library. - Example integration of Loam and GDAL into a simple React application. - Examples / demos of other ways to use GDAL within client-side applications to improve user experience and reduce infrastructure costs.
 Okay, I think we can start already. So welcome everyone to Wednesday in Fast 4G 2021. This is the Konka Watchroom. Following we will have the dollar presenting handling your tips in current site code with GDAAL and Loan. Well, I'll let you do the possible talk. Okay, thanks Jose. So hi everyone, my name is Derek Dohler. I am a software engineer at Azevia. We are a professional services firm based in Philadelphia with a focus on geospatial work. And I want to talk to you today about a library I've written called Loam that uses GDAAL to handle geotifs in client-side code, i.e. code that's running in a web browser. So I'm not going to go into what GDAAL and geotifs are because I assume that if you're interested in this talk, you probably know what those two things are already. If you do have questions about those two things, please put in a question and we can talk about it at the end. But so just some background. You need GDAAL or some other library that supports the geotif format, such as GeoTrails or geotif.js. There are other libraries to read geotifs. It's not a format that's supported by non-GIS software. So you need specialized GIS libraries or software in order to read a geotif. And so if you want to integrate geotifs and spatial data handling into your web application, you are going to need to use GDAAL most likely and you historically would need to run that on the server side. So GDAAL is a C++ library, so there wasn't really a way to run that on the client side. So you would need to integrate that into the server side component, the backend of your web application. But fairly recently, the WebAssembly standard has started to be supported within web browsers and there is a set of tools called MScripten which allows compiling C++ libraries into WebAssembly, which then allows running GDAAL inside of a browser. So it's now possible to run GDAAL in a browser, a client-side environment. So the next question becomes why would you want to do that? And so to answer that question, let's talk a little bit about some of the drawbacks and some of the challenges of using GDAAL on the server side because what running it on the client side would do is it's essentially going to be replacing server-side handling of geotifs. So let's look into that a little bit. Server-side handling of geotifs, this could also apply to other raster formats, but I'm focusing in on geotifs because they're fairly common and a lot of people know how to work with them. The first one you have is you have a drawback of infrastructure costs. So when you're running a server, you automatically are going to be paying higher costs in order to support those computing resources, whereas you can host a completely client-side static web app for free these days in any number of places. If you want to actually do dynamic processing, you need to have servers and so that's going to increase your costs. It's also going to, second point, increase your infrastructure complexity. So you need to set up deployment for these servers. However you choose to run them, you need to have a way to install GDAAL onto the servers. You need to hook them up to the front end of your application. So you've already increased the complexity and the maintenance costs of your web application by adding that backend component. And then there's also a challenge of user experience. When you're running on the server, it can sometimes force you to structure things in a certain way, and I'll get to that in a second with an example that may not provide the best user experience. But on the flip side, there is also a lot of flexibility that you get because you have usually a more powerful machine, you can architect things the way you want, so when you do your handling on the server, you tend to get a lot of flexibility from it. So here's an example of a feature that I've had to work with in web applications that I've worked on. I'm sure some of you have had to implement a similar feature. So let's say you've got a web application that needs to accept user-submitted geotifs. So users want to upload geotifs for some reason on this application. If you're handling those geotifs server side, the first thing is you need to validate them after uploading. So you have to upload in order for the geotifs to be processed or validated because they have to be on the server. Geotifs can often be quite large, so users can find themselves sitting for several minutes waiting for a large file to upload and they don't get any validation or feedback until that file has uploaded and you've had a chance to validate it. So that makes the user experience poorer. Similarly, it's hard to provide a preview if you're doing all of your processing on the server side because you have to wait again until the file has been entirely uploaded. And then once those files are uploaded, if they're large, you are likely going to need to set up some sort of asynchronous task handling in order to process those files because they may be too large to be processed within a request response cycle. So there are some significant limitations if you're working with geotifs or other large geospatial files on the server side. However, if you can do it on the client side, you can do certain types of validation very quickly in browser and you can provide immediate feedback because you've got the file available there instantly. You can do things like preview the footprint on a map immediately. You could potentially even reprocess the files in your browser and then upload the desired format if there's back-end processing that has to happen. You could have that happen on the front end and do the processing while it's uploading. So then by the time the data gets uploaded to the application back-end, it's actually already in the format that you need. So I'm going to provide a demo here. I hope that this may not have worked. Can we see this? Yes. No. Sorry, one second. Okay, great. So this is a little demo application that we put together to explain how this can work. And this is basically just going to show some information about a geotif that I upload. So I suspect you won't be able to see the file selection dialog, but I'm going to click Browse here. I'm going to select what is a Landsat geotif. It's a scene from Landsat. It is just a single band. It happens to be Band 8, and it's about 230 megabytes. So when I select this, there's not going to be any upload process. We're just going to see some information about this fairly large tif file, and you'll see that appear on the page. So I am going to click the button to submit it right now. And so you can see that that was a fairly instantaneous response, and we've been able to get out some useful information about this geotif that hasn't been uploaded anywhere. It's just sitting on my local computer. We've got the coordinate system. We've got the size. We've got the band count. We've got the footprint of the geotif here that is displayed on a map. So if you were a user uploading this to a web application somewhere and you accidentally clicked the wrong file, you would see that here, and you'd say, oh, this is the wrong file. It's in the wrong place. This isn't the one I meant to upload. So you could more quickly cancel that and restart it. If the band count was wrong, for example, you could see that, and you could deal with it. And we've also got the bounding box coordinates. So if you need to download those as GeoJSON or use them in some other way, we've got those available for you here. And so in addition to the fact that this is something that provides immediate feedback and it has a good user experience, it also is really easy to scale because it's an entirely static website. So this whole website is completely static. So if you all go to this website right now, I'm not going to be worried about scaling or the server getting overloaded or anything like that because it's just static files. So there's nothing really that needs to be scaled up or there's no resources that need to be changed if there's a lot of users all trying to use it at the same time. It'll just keep on running no matter what and you all will have a good experience even if there's lots and lots of people using it. Okay. So I am going to switch this back. Sorry one moment. Sorry one moment. Okay. All right. Well, technical difficulties. Sorry about that. Okay. Okay. I think that should be good. I'm just going to leave this in the regular mode. So what is Loam? Loam is a client-side GDAL wrapper. So you may have worked with other clients or other wrappers for GDAL. Loam is a client-side wrapper that's designed to run in a browser environment using GDAL that's been compiled to WebAssembly. So let's look at some codes. So to open a file, you know, with GDAL, you need to use GDAL Open to open it if you've ever used the GDAL API. And the same happens with Loam. You need to provide a file object like a user might select from their file system, or you can also provide it with a blob. So if you've got something that's getting downloaded as binary from somewhere, it may show up as a blob. You can also pass in a blob and you just do Loam.Open and then you give it the file. If you then want to do something with that file, you can use... You have a number of functions that you can call on your data set. So when you do Loam.Open, you get a promise that provides you with a data set. So that's this ds here. And then if you want to call width and height on that data set, you can call ds.width, ds.height, and then you can... Those both return promises. You can wait on both of those promises and then you can do something with that data. So everything in the API returns a promise. A little bit more of a complex example, GDAL Translate is available. So you can pass in all of the parameters that you would use on the command line for GDAL Translate. You can pass those into a function called inLom. So for example, we've got... It's called convert inLom and you can... This is an example of converting a GeoTIFF into a PNG file. It is using bands 1, 2, and 3 for RGB. It's setting the out format to PNG, resizing to 512, using nearest neighbor resampling and scaling the histogram. And one important thing to note about this is that altering data sets evaluate lazily. So if you do this, then the promise that's returned will actually evaluate immediately. But no processing is going to happen. So you can call convert again, you can warp, you can do other alterations on that data set that you've created, sort of like a VRT, if you're familiar with those. You can do things to it, but nothing is actually going to get processed until you try to access some data from that data set. So in this case, the example is getting the bytes of the data set in order to probably display it somewhere. Once you call bytes, then that whole lazily generated data set is evaluated at that point when you try to make the access. What else can you do with it? There's another quite a few other things that are supported right now. In theory, anything that could be supported by GDAL could be supported by Loam, but the wrappers have to be written, so not everything is there yet. But here are the things that are currently supported. There's support for using Proj4 to re-project arrays of points between projections defined by WKT. So that's one thing you can do. You've got access to GDAL translate, as I mentioned, so you can resize files, you can change the format, adjust the compression, adjust the band type, reorder the bands, and many other things. You've also got access to GDAL warp, so you can use that to warp an image between projections. You can also do some windowing to select subsets of a file. There's also GDAL dem available, so you can do hill shading, you can do color mapping, slope, and anything else that GDAL dem is capable of doing. And then there's also GDAL rasterize. So you can, if you have GeoJSON in your web map, in your mapping application somewhere, and you want to turn that into a raster image, you can use GDAL rasterize to create a rasterized version of that GeoJSON. So I hope at this point that you are thinking, wow, this sounds pretty amazing, but there have to be limitations for everything, so what are they? And there's a few. So the first limitation, I think the previous presenter touched on this a little bit, is that within a browser you have some constraints because you're running in a browser environment. So the first one that is notable here is memory constraints. If you're running on a large machine, you've got many gigabytes of memory available, you have an ability to write temporary data to the disk, so even if you run out of memory, you can process a large file. In a browser, the browser environment is very tightly constrained, so you can't dump large files to disk, you don't have really any swap space, or spare disk space available to access to the application, you just have to run within whatever the browser gives you. So if you're memory limited, that's pretty much all you've got. You've got the memory you can work with, and you can't get any more. So for very large files, you might have a difficult time working with large files in a browser, although GDAL is really quite good at running with limited memory, so you might be surprised at how far you can push it. There's also limits on HTTP requests, so I know a lot of people like to use VSI Curl within GDAL, and that's not currently available in a browser environment. I think there's a good path towards making that available, but it's not currently there yet. You can, however, make the requests yourself via JavaScript, and then pass the response from that request as a blob to GDAL, so that's still possible. A third limitation is bandwidth. So in order to make your website load quickly, you want assets to be as small as possible. GDAL is a fairly large library. The assets for GDAL are about 2.2 megabytes compressed, so there's a lot that needs to get downloaded. Luckily, you can download that lazily at some other point when the web page loads after the web page loads, so you don't need to load all of that on the initial page load. It's not going to slow down your initial page load all that much, but it does need to get loaded at some point, and if you've got a slow connection, that could be problematic. And then the fourth point is that WebAssembly and WebWorkers, which Loam also uses, are relatively on the newer side for technology, so people who are trying to use Loam and WebAssembly WebWorkers inside a standard web application that was built with React or Webpack or some other front-end framework or Bundler often struggle with getting the build tools to correctly deal with those assets and those files. And then, as I mentioned, not all of the GDAL methods are wrapped yet. We can't use auto-generated or existing JavaScript wrappers because it's executing in an entirely different execution environment because it's in a browser, so you can't just use the existing wrapper for Node.js that's in JavaScript. You can't just transfer that over to the browser and expect it to work. So if you're wondering how you can help, which I hope you are, there was a fellow just a few days ago who opened a PR to add functions for OGR, OGR. So if you want to add things to it, I am very welcoming of pull requests or issues if you need something, and that's basically it. If you want to learn how to install it, it's just npm install Loam. The repo is, the link is right there. And then GDAL.js is the WebAssembly port of GDAL or compilation of GDAL, and that's the link to that repository. And now I can open it up for questions. Thank you. Thank you for that amazing talk, Edek. And yeah, let's see the questions that I feel posted up. So let's start with this one. Is it possible to open other just partial file formats that GDAL supports? Yeah, it is. So the file formats that are currently supported are GeoTiff, JPEG, and PNG on the raster side, and then on the vector side, anything that's built in when you compile GDAL is supported, but not all of the wrappers are quite there yet. That will actually come when that pull request to add the OGR functions is finished. In theory, it's possible to support anything that GDAL supports, but in order to keep the bundle size low, you saw it was 2.2 megabytes compressed. If you add in other libraries, that's going to further increase the bundle size. So I've opted not to compile in support for any other file formats besides those ones that I just mentioned, but it would certainly be possible to compile your own version into WebAssembly using the repo for GDAL.js if you need to have, for example, NetCDF support. You could create your own compilation. You could include, compile in the library for NetCDF support. And then Lome doesn't really care about what GDAL can support, and so Lome would be able to use that just as if it was any other file, as long as the GDAL compilation, the compiled version of GDAL behind it, supported that. Alright, thanks. Next question. Is this one, Azavia is supporting the development of the period, currently? I'm sorry, is what supported? Azavia. Oh, Azavia, yeah. Sorry, no, it's okay. No one pronounces it correctly the first time. So I am working on this project. Azavia has a 10% time research program, so Azavia employees can use 10% of our time to work on research projects. So I've been using my 10% time to work on the project. I've had some collaboration from other Azavia employees, and there have been some folks outside of the company who have worked on it. But it's being indirectly supported by Azavia through that program, but it's sort of my initiative. Awesome. Okay, and I think we have time for another question. How does its performance compare with GOTFGS? Yeah, that's a great question. I haven't directly compared it to GOTFGS. I haven't tried to set up a benchmark, but I can talk about some of the differences between the two libraries. GOTFGS is written in pure JavaScript as far as I'm aware, and it just focuses on reading data from GOTFGS. So it's much, much smaller in terms of the dependencies that you're downloading. It's just a very small library that allows you to read GOTFGS. So you only have a few kilobytes of data that you're reading, that you're downloading, compared to GDAL, which is 2.2 megabytes compressed. So there's a big difference in terms of the size of the payload that you're downloading. So that's the first point. The second point is that GDAL includes all of GDAL. So with geotift.js, once you've got the data, it's sort of up to you what you want to do with it, if you want to render it in a certain way, convert it to another format, do something else with it. You have to sort of make that decision on your own and write that code on your own. And if you're using GDAL, you get access to a lot of the things that GDAL has built in already. So it's more, it's like a much more full-featured library. But again, with the drawback, that you pay for that, those extra features because of the larger size that you're downloading. And then the last point is that GDAL is compiled to WebAssembly. In theory, WebAssembly should be, in most cases, faster than a JavaScript library. But in some of the tests that I've done, I've seen that that's not always the case. So I think that the best thing to do if you wanted to compare the two would be to sort of attempt to implement the specific computation that you're interested in and to compare them side by side. Okay, thank you very much. And I think that we have to run out of time for questions. So I think that we will have to save hours right now. So thank you very much, Derek, for your talk and for coming to Fuzz4G. And we will be seeing you today, right? Yes, thank you very much. See you soon. Goodbye.
 Okay, I think we can start already.  So welcome everyone to Wednesday in Fast 4G 2021.  This is the Konka Watchroom.  Following we will have the dollar presenting handling your tips in current site code with  GDAAL and Loan.  Well, I'll let you do the possible talk.  Okay, thanks Jose.  So hi everyone, my name is Derek Dohler.  I am a software engineer at Azevia.  We are a professional services firm based in Philadelphia with a focus on geospatial  work.  And I want to talk to you today about a library I've written called Loam that uses GDAAL to  handle geotifs in client-side code, i.e. code that's running in a web browser.  So I'm not going to go into what GDAAL and geotifs are because I assume that if you're  interested in this talk, you probably know what those two things are already.  If you do have questions about those two things, please put in a question and we can talk about  it at the end.  But so just some background.  You need GDAAL or some other library that supports the geotif format, such as GeoTrails  or geotif.js.  There are other libraries to read geotifs.  It's not a format that's supported by non-GIS software.  So you need specialized GIS libraries or software in order to read a geotif.  And so if you want to integrate geotifs and spatial data handling into your web application,  you are going to need to use GDAAL most likely and you historically would need to run that  on the server side.  So GDAAL is a C++ library, so there wasn't really a way to run that on the client side.  So you would need to integrate that into the server side component, the backend of your  web application.  But fairly recently, the WebAssembly standard has started to be supported within web browsers  and there is a set of tools called MScripten which allows compiling C++ libraries into  WebAssembly, which then allows running GDAAL inside of a browser.  So it's now possible to run GDAAL in a browser, a client-side environment.  So the next question becomes why would you want to do that?  And so to answer that question, let's talk a little bit about some of the drawbacks  and some of the challenges of using GDAAL on the server side because what running it  on the client side would do is it's essentially going to be replacing server-side handling  of geotifs.  So let's look into that a little bit.  Server-side handling of geotifs, this could also apply to other raster formats, but I'm  focusing in on geotifs because they're fairly common and a lot of people know how to work  with them.  The first one you have is you have a drawback of infrastructure costs.  So when you're running a server, you automatically are going to be paying higher costs in order  to support those computing resources, whereas you can host a completely client-side static  web app for free these days in any number of places.  If you want to actually do dynamic processing, you need to have servers and so that's going  to increase your costs.  It's also going to, second point, increase your infrastructure complexity.  So you need to set up deployment for these servers.  However you choose to run them, you need to have a way to install GDAAL onto the servers.  You need to hook them up to the front end of your application.  So you've already increased the complexity and the maintenance costs of your web application  by adding that backend component.  And then there's also a challenge of user experience.  When you're running on the server, it can sometimes force you to structure things in  a certain way, and I'll get to that in a second with an example that may not provide the best  user experience.  But on the flip side, there is also a lot of flexibility that you get because you have  usually a more powerful machine, you can architect things the way you want, so when  you do your handling on the server, you tend to get a lot of flexibility from it.  So here's an example of a feature that I've had to work with in web applications that  I've worked on.  I'm sure some of you have had to implement a similar feature.  So let's say you've got a web application that needs to accept user-submitted geotifs.  So users want to upload geotifs for some reason on this application.  If you're handling those geotifs server side, the first thing is you need to validate them  after uploading.  So you have to upload in order for the geotifs to be processed or validated because they  have to be on the server.  Geotifs can often be quite large, so users can find themselves sitting for several minutes  waiting for a large file to upload and they don't get any validation or feedback until  that file has uploaded and you've had a chance to validate it.  So that makes the user experience poorer.  Similarly, it's hard to provide a preview if you're doing all of your processing on  the server side because you have to wait again until the file has been entirely uploaded.  And then once those files are uploaded, if they're large, you are likely going to need  to set up some sort of asynchronous task handling in order to process those files because they  may be too large to be processed within a request response cycle.  So there are some significant limitations if you're working with geotifs or other large  geospatial files on the server side.  However, if you can do it on the client side, you can do certain types of validation very  quickly in browser and you can provide immediate feedback because you've got the file available  there instantly.  You can do things like preview the footprint on a map immediately.  You could potentially even reprocess the files in your browser and then upload the desired  format if there's back-end processing that has to happen.  You could have that happen on the front end and do the processing while it's uploading.  So then by the time the data gets uploaded to the application back-end, it's actually  already in the format that you need.  So I'm going to provide a demo here.  I hope that this may not have worked.  Can we see this?  Yes.  No.  Sorry, one second.  Okay, great.  So this is a little demo application that we put together to explain how this can work.  And this is basically just going to show some information about a geotif that I upload.  So I suspect you won't be able to see the file selection dialog, but I'm going to click  Browse here.  I'm going to select what is a Landsat geotif.  It's a scene from Landsat.  It is just a single band.  It happens to be Band 8, and it's about 230 megabytes.  So when I select this, there's not going to be any upload process.  We're just going to see some information about this fairly large tif file, and you'll  see that appear on the page.  So I am going to click the button to submit it right now.  And so you can see that that was a fairly instantaneous response, and we've been able  to get out some useful information about this geotif that hasn't been uploaded anywhere.  It's just sitting on my local computer.  We've got the coordinate system.  We've got the size.  We've got the band count.  We've got the footprint of the geotif here that is displayed on a map.  So if you were a user uploading this to a web application somewhere and you accidentally  clicked the wrong file, you would see that here, and you'd say, oh, this is the wrong  file.  It's in the wrong place.  This isn't the one I meant to upload.  So you could more quickly cancel that and restart it.  If the band count was wrong, for example, you could see that, and you could deal with  it.  And we've also got the bounding box coordinates.  So if you need to download those as GeoJSON or use them in some other way, we've got those  available for you here.  And so in addition to the fact that this is something that provides immediate feedback  and it has a good user experience, it also is really easy to scale because it's an entirely  static website.  So this whole website is completely static.  So if you all go to this website right now, I'm not going to be worried about scaling  or the server getting overloaded or anything like that because it's just static files.  So there's nothing really that needs to be scaled up or there's no resources that need  to be changed if there's a lot of users all trying to use it at the same time.  It'll just keep on running no matter what and you all will have a good experience even  if there's lots and lots of people using it.  Okay.  So I am going to switch this back.  Sorry one moment.  Sorry one moment.  Okay.  All right.  Well, technical difficulties.  Sorry about that.  Okay.  Okay.  I think that should be good.  I'm just going to leave this in the regular mode.  So what is Loam?  Loam is a client-side GDAL wrapper.  So you may have worked with other clients or other wrappers for GDAL.  Loam is a client-side wrapper that's designed to run in a browser environment  using GDAL that's been compiled to WebAssembly.  So let's look at some codes.  So to open a file, you know, with GDAL, you need to use GDAL Open to open it  if you've ever used the GDAL API.  And the same happens with Loam.  You need to provide a file object like a user might select from their file system,  or you can also provide it with a blob.  So if you've got something that's getting downloaded as binary from somewhere,  it may show up as a blob.  You can also pass in a blob and you just do Loam.Open and then you give it the file.  If you then want to do something with that file, you can use...  You have a number of functions that you can call on your data set.  So when you do Loam.Open, you get a promise that provides you with a data set.  So that's this ds here.  And then if you want to call width and height on that data set,  you can call ds.width, ds.height, and then you can...  Those both return promises.  You can wait on both of those promises and then you can do something with that data.  So everything in the API returns a promise.  A little bit more of a complex example,  GDAL Translate is available.  So you can pass in all of the parameters that you would use on the command line for GDAL Translate.  You can pass those into a function called inLom.  So for example, we've got...  It's called convert inLom and you can...  This is an example of converting a GeoTIFF into a PNG file.  It is using bands 1, 2, and 3 for RGB.  It's setting the out format to PNG, resizing to 512,  using nearest neighbor resampling and scaling the histogram.  And one important thing to note about this is that altering data sets evaluate lazily.  So if you do this, then the promise that's returned will actually evaluate immediately.  But no processing is going to happen.  So you can call convert again, you can warp,  you can do other alterations on that data set that you've created,  sort of like a VRT, if you're familiar with those.  You can do things to it, but nothing is actually going to get processed  until you try to access some data from that data set.  So in this case, the example is getting the bytes of the data set  in order to probably display it somewhere.  Once you call bytes, then that whole lazily generated data set is evaluated  at that point when you try to make the access.  What else can you do with it?  There's another quite a few other things that are supported right now.  In theory, anything that could be supported by GDAL could be supported by Loam,  but the wrappers have to be written, so not everything is there yet.  But here are the things that are currently supported.  There's support for using Proj4 to re-project arrays of points  between projections defined by WKT.  So that's one thing you can do.  You've got access to GDAL translate, as I mentioned,  so you can resize files, you can change the format, adjust the compression,  adjust the band type, reorder the bands, and many other things.  You've also got access to GDAL warp, so you can use that to warp  an image between projections.  You can also do some windowing to select subsets of a file.  There's also GDAL dem available, so you can do hill shading,  you can do color mapping, slope, and anything else that GDAL dem is capable of doing.  And then there's also GDAL rasterize.  So you can, if you have GeoJSON in your web map,  in your mapping application somewhere, and you want to turn that into a raster image,  you can use GDAL rasterize to create a rasterized version of that GeoJSON.  So I hope at this point that you are thinking,  wow, this sounds pretty amazing, but there have to be limitations for everything,  so what are they?  And there's a few.  So the first limitation, I think the previous presenter touched on this a little bit,  is that within a browser you have some constraints because you're running in a browser environment.  So the first one that is notable here is memory constraints.  If you're running on a large machine, you've got many gigabytes of memory available,  you have an ability to write temporary data to the disk,  so even if you run out of memory, you can process a large file.  In a browser, the browser environment is very tightly constrained,  so you can't dump large files to disk, you don't have really any swap space,  or spare disk space available to access to the application,  you just have to run within whatever the browser gives you.  So if you're memory limited, that's pretty much all you've got.  You've got the memory you can work with, and you can't get any more.  So for very large files, you might have a difficult time working with large files in a browser,  although GDAL is really quite good at running with limited memory,  so you might be surprised at how far you can push it.  There's also limits on HTTP requests, so I know a lot of people like to use VSI Curl within GDAL,  and that's not currently available in a browser environment.  I think there's a good path towards making that available, but it's not currently there yet.  You can, however, make the requests yourself via JavaScript,  and then pass the response from that request as a blob to GDAL, so that's still possible.  A third limitation is bandwidth.  So in order to make your website load quickly, you want assets to be as small as possible.  GDAL is a fairly large library.  The assets for GDAL are about 2.2 megabytes compressed, so there's a lot that needs to get downloaded.  Luckily, you can download that lazily at some other point when the web page loads after the web page loads,  so you don't need to load all of that on the initial page load.  It's not going to slow down your initial page load all that much,  but it does need to get loaded at some point, and if you've got a slow connection, that could be problematic.  And then the fourth point is that WebAssembly and WebWorkers, which Loam also uses,  are relatively on the newer side for technology,  so people who are trying to use Loam and WebAssembly WebWorkers inside a standard web application  that was built with React or Webpack or some other front-end framework or Bundler  often struggle with getting the build tools to correctly deal with those assets and those files.  And then, as I mentioned, not all of the GDAL methods are wrapped yet.  We can't use auto-generated or existing JavaScript wrappers  because it's executing in an entirely different execution environment because it's in a browser,  so you can't just use the existing wrapper for Node.js that's in JavaScript.  You can't just transfer that over to the browser and expect it to work.  So if you're wondering how you can help, which I hope you are,  there was a fellow just a few days ago who opened a PR to add functions for OGR, OGR.  So if you want to add things to it, I am very welcoming of pull requests or issues if you need something,  and that's basically it.  If you want to learn how to install it, it's just npm install Loam.  The repo is, the link is right there.  And then GDAL.js is the WebAssembly port of GDAL or compilation of GDAL,  and that's the link to that repository.  And now I can open it up for questions. Thank you.  Thank you for that amazing talk, Edek.  And yeah, let's see the questions that I feel posted up.  So let's start with this one.  Is it possible to open other just partial file formats that GDAL supports?  Yeah, it is.  So the file formats that are currently supported are GeoTiff, JPEG, and PNG on the raster side,  and then on the vector side, anything that's built in when you compile GDAL is supported,  but not all of the wrappers are quite there yet.  That will actually come when that pull request to add the OGR functions is finished.  In theory, it's possible to support anything that GDAL supports,  but in order to keep the bundle size low, you saw it was 2.2 megabytes compressed.  If you add in other libraries, that's going to further increase the bundle size.  So I've opted not to compile in support for any other file formats besides those ones that I just mentioned,  but it would certainly be possible to compile your own version into WebAssembly using the repo for GDAL.js  if you need to have, for example, NetCDF support.  You could create your own compilation.  You could include, compile in the library for NetCDF support.  And then Lome doesn't really care about what GDAL can support,  and so Lome would be able to use that just as if it was any other file,  as long as the GDAL compilation, the compiled version of GDAL behind it, supported that.  Alright, thanks.  Next question.  Is this one, Azavia is supporting the development of the period, currently?  I'm sorry, is what supported?  Azavia.  Oh, Azavia, yeah.  Sorry, no, it's okay. No one pronounces it correctly the first time.  So I am working on this project. Azavia has a 10% time research program, so Azavia employees can use 10% of our time to work on research projects.  So I've been using my 10% time to work on the project.  I've had some collaboration from other Azavia employees,  and there have been some folks outside of the company who have worked on it.  But it's being indirectly supported by Azavia through that program, but it's sort of my initiative.  Awesome.  Okay, and I think we have time for another question.  How does its performance compare with GOTFGS?  Yeah, that's a great question.  I haven't directly compared it to GOTFGS.  I haven't tried to set up a benchmark, but I can talk about some of the differences between the two libraries.  GOTFGS is written in pure JavaScript as far as I'm aware, and it just focuses on reading data from GOTFGS.  So it's much, much smaller in terms of the dependencies that you're downloading. It's just a very small library that allows you to read GOTFGS.  So you only have a few kilobytes of data that you're reading, that you're downloading, compared to GDAL, which is 2.2 megabytes compressed.  So there's a big difference in terms of the size of the payload that you're downloading. So that's the first point.  The second point is that GDAL includes all of GDAL.  So with geotift.js, once you've got the data, it's sort of up to you what you want to do with it, if you want to render it in a certain way, convert it to another format, do something else with it.  You have to sort of make that decision on your own and write that code on your own.  And if you're using GDAL, you get access to a lot of the things that GDAL has built in already. So it's more, it's like a much more full-featured library.  But again, with the drawback, that you pay for that, those extra features because of the larger size that you're downloading.  And then the last point is that GDAL is compiled to WebAssembly. In theory, WebAssembly should be, in most cases, faster than a JavaScript library.  But in some of the tests that I've done, I've seen that that's not always the case.  So I think that the best thing to do if you wanted to compare the two would be to sort of attempt to implement the specific computation that you're interested in and to compare them side by side.  Okay, thank you very much. And I think that we have to run out of time for questions. So I think that we will have to save hours right now. So thank you very much, Derek, for your talk and for coming to Fuzz4G.  And we will be seeing you today, right?  Yes, thank you very much.  See you soon.  Goodbye.
FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_0_131.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_132_983.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_984_1031.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_1032_1823.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_1824_5111.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_5112_7835.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_7836_11231.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_11232_11747.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_11748_12155.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_12156_12719.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_12720_13667.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_13668_14099.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_14100_16451.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_16452_18011.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_18012_18215.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_18216_18635.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_18636_18995.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_18996_19055.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_19056_19103.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_19104_19151.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_19152_19631.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_19632_23735.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_23736_23807.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_23808_24443.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_24444_25271.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_25272_25715.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_25716_26003.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_26004_30755.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_30756_30935.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_30936_31931.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_31932_32699.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_32700_36095.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_36096_36191.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_36192_39083.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_39084_39251.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_39252_40799.png FOSS4G_-_Handling_GeoTIFFs_in_client-side_code_wit_WYQH7AWViCo_40800_40918.png