QGIS Plugin Development Is Not Scary: Lessons Learned from Literature Mapper
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.
Tobias, Michele
Mandel, Alex
This is the story of how one QGIS plugin came to be and the lessons we learned along the way. The Literature Mapper QGIS Plugin was created to fill a need: academic journal articles are often about a specific location (this is common in fields such as ecology, archaeology, and history), but there was no method for connecting location data to a citation manager. We built the tool we needed from the idea stage (a paper map hand annotated in pencil), to prototype, to freely available code in the QGIS Plugin repository, to a tool that is steadily gaining users. In this talk, we will describe our experience developing the Literature Mapper QGIS plugin – all the ups and downs – to explain the process and encourage more people to try making their own plugin. Michele Tobias and Alex Mandel both hold PhDs in Geography and have worked in the geospatial field for 20 years, mainly working with open source tools. Both are active members of OSGeo. This goal of this talk is not only to give people practical skills and advice, but also to offer encouragement to folks who just need a little boost to try something new. Authors and Affiliations – Tobias, Michele (1) Mandel, Alex (2) (1) University of California, Davis - UC Davis DataLab (2) Development Seed Requirements for the Attendees – Documentation: Repository: Academic Publication: Track – Software Topic – Data collection, data sharing, data science, open data, big data, data exploitation platforms Level – 2 - Basic. General basic knowledge is required.
 Okay, we'll get going with the next talk here. We've got Michelle Tobias and Alex Mandel. Michelle is a geospatial data specialist at University of California Davis and she's also a board member of OSGEO. Alex Mandel is a geospatial engineer at Development Seed and Michelle and Alex have collaborated on a QGIS plugin to add a geospatial dimension to research citations and they're going to share some lessons from their experience to help break down the barriers to creating your own QGIS plugin. So the talk is pre-recorded but Michelle and Alex are here today, they're here right now, it's 4.30 in the morning in California so show some mercy but anyway they're here to answer some questions after the talk so yeah please add your questions to the Vennilis platform. So I'll fire up the video here. Welcome everyone and thanks for coming to our talk which is entitled QGIS plugin development is not scary. We've learned from literature mapper. So who are we? My name is Michelle Tobias, I am the geospatial data specialist at the University of California Davis and State of Lab and I'm the mastermind behind literature mapper I guess you could say. Most of my coding for this project has been in the realm of the text parsing that needs to go on in making this plugin work and I just want to confess I'm really bad at Python, I don't use it on a daily basis so every time I come back to it it's like starting over so hopefully that's a little bit of an inspiration that you can do this to even if you're not great at a particular language but I am a frequent user of QGIS, R and SQL so I do have a programming background just Python isn't my daily jam so. So my co-presenter today is Alex Mandel, he is a geospatial engineer at development seed. For this project he advises on things like feasibility when I come up with grand ideas he helps me figure out how this is going to work. He did most of the coding for the interface functions and some of those kinds of things and he is much better at Python than I am so that makes us a good team for this. And I just want to have a quick disclaimer that literature mapper is not a product of UC Davis or development seed this is something we develop on our own time so it's not paid for by our respective companies. So what is literature mapper? It is an experimental plugin for QGIS, it's written in Python and it is currently available in the plugin repository. It is a tool that connects Zotero which is an open source citation manager with QGIS which you guys are all familiar with I'm sure. And it allows users to georeference citations through QGIS and it stores the location information alongside the Zotero database so it puts it actually inside Zotero and stores it along with all of your citation information like author and title of the text and publisher and year and things like that. And it keeps all of that spatial data together with the citation information so everything stays in sync and you don't have to worry about having two files, you know, your spatial data separate from your citation so the idea is it keeps everything together and we have a little screen shot of the tool itself in action. So you can see that, well maybe because it's really small but there's columns in there for all the things that you might want to have in a citation such as the title and things like that and then there's also a geometry column. So this is sort of the workflow for literature mapper how things work under the hood. Everything is stored in Zotero. We use the API from Zotero to generate a citation and then we use Python to parse that into a table for QGIS and then continue using Python to generate the locations which you digitize by hand but it's still better than you can't automate this process. It needs to be done by hand. So we use Python for that because that's what generates the interface and then once you've generated your locations we send it right back to Zotero with the API. So that's sort of the general workflow for this particular plugin. So a little bit of background on literature mapper is that academic journal articles are often about a specific location. So things like plants and animals, geology, social justice, history, all of these things happen in a location and that location actually matters. So you know I'm a biogeographer by training so things grow, plants grow in a certain place for a certain reason and that location can be really important to understanding any information that I generate with research about that particular species. Just for an example. So we might actually care about the spatial distributions of the studies that people are publishing. All of this academic literature, maybe it matters where the studies are generated. Maybe it matters where certain aspects of history are taking place and we actually want to see that on a map. But there's no way to do that. There's been no method to connect location data and your citation manager. And that became a problem for me personally when I was working on my dissertation. So our team here identified a need that had no available solution and that's really key to what we're going to be talking about today. So again we identified a need that didn't have a solution. So we're not solving something that already has a solution. You've got to come up with something that is new. So our building process in terms of creating this plugin is we started with an idea. The idea actually was this piece of paper which is a map, a really ugly map that I printed out on a printer many, many years ago and started marking locations of studies on it in pencil. I have to confess that I have kept tabs on this piece of paper until last year. And now all I have is the scan. I don't know where the actual piece of paper is. It's probably in my physical office that I haven't been to in almost ten years or two years, sorry. So anyway this started out as pencil annotations on a piece of paper. And we decided that we need to make this actually a tool, right? So we started prototyping it. We made a proof of concept of a plugin that kind of did what it needed to do and we kept iterating on that until we had code that was ready for the QJS plugin repository. And then we keep developing and we keep adding things to it. And now it's a tool that's actually gaining steady users even though it's still obviously could, you can always make stuff better, but people are actually using it for its intended purpose and that's kind of cool. So it's been through this whole stage from a piece of paper with pencil drawings on it into an actual valid research tool. So next up we're going to tell you about how to prepare for this, how to get going on making your own plugin. All right, so there are a few really important key things when you're thinking about making a new tool and a new plugin. And the first really big one is when you identify a need that you want to fill, you have to be very specific about what that need is and be very clear about what does not quite fit into that because you're going to come up with lots of ideas and they might be related to your core need, but if they're not really critical, you want to put them aside and make a list for later so that you can actually get your tool working. All right, so then the first thing you want to do is not even identifying a need, you want to look at what already exists that's similar or related and how closely does it solve or not solve your problem. And then if you do find some things that are similar, you really need to try them out and see do they really not work for what you're trying to do? Is there really a reason why your particular way of doing or solving a problem is uniquely different that it requires a whole new tool? Or is there an option to maybe just add a feature to an existing tool or enhance an existing tool to make it also meet your need in addition to whatever else it was already doing? Okay, and then once you've decided you're going to make your own tool or your own plugin, think about the branding for it a little bit because you want a name that's unique and you want a name that clearly aligns with what your tool does and you don't want that name to be similar to anything else, whether it's a related tool or not. You especially don't want it to be a name that's similar to an unrelated tool so when people are searching the internet, they find things that have nothing to do with what you're working on. But you also want to avoid, as in one problem we discovered, which is there's a very similar tool out there called Journal Map, which we came across a few years after we started, that does something similar but not quite the same. And the names are somewhat confusing and easy to mix up. And so now we have to work harder in order to differentiate our brand and our plugin to make it clear what our tool does versus what their tool does. And at least the good thing is now that we have communication with the other development team, we can jointly do some of that. All right, the next part of this is we're going to encourage you to make it happen. This is definitely something you can do. So some of the tools in my arsenal for getting going and developing a product that actually functions and does what I want it to do is I often will just draw things out. I actually have a notebook, you can see a screenshot or not a screenshot, but a scan of my notebook here in the corner. Draw out your workflow. What should it do? What pieces of information should move from one part of the code to the other? What should the interface look like? So in this picture you can see I've actually drawn out what I want my interface to look like before I actually started putting it together. And then you can see I've got some notes about what the button should do and what the code needs to look like under the hood. And then I've actually coded it and created the actual interface. And this is a screenshot of the functioning interface that does something very similar to what the notes in the notebook have. So I like to draw things out. And it can be a really helpful way to see like, is this really what I want it to do? I don't want to spend time building it until I know that it's what I want. And I'm on the right track. The other thing is this might be the scariest part. You probably are going to have to level up your skills. So there are a lot of free resources out there to help you learn what you need. For QGIS Python plug-in development, you're going to need to know Python. You're going to also need to know PyQGIS. That's the Python tool that works with QGIS. There's also information, a lot of good information in the documentation about the QGIS plug-in development workflow. So how you actually create a plug-in and what are all the bits and pieces that you actually need to make that go. And then also you'll need to learn how to use something like GitHub or some other version control system. And you really want that because that will help you. It's got great tools for not only versioning your code, but also tools for in GitHub's case in particular, there's things like the issues board where you can keep track of ideas and things that need fixing or you can use branches and things like that for development. It's just a really helpful tool to have. But use whatever version control system you like. I just highly encourage you to use one. And then specifically for literature mapper, we actually had to learn how to use the Zotero API. So they have an API that they use to work with various tools that are associated with Zotero. So we could take advantage of that. And we had to learn that system. And it's not super complicated, but it was something that it takes time to learn and you have to be open to learning these kinds of new skills in order to make your plug-in work. And whatever plug-in you have in mind, you'll probably have something similar, some domain knowledge that you'll need in order to make your plug-in work. And you can see my notes here. Again, a clip from my notebook of trying to learn the Zotero API and making notes about what I needed to do. And I just find that helpful to have it on paper. But use your own system, whatever works. And then the next piece of advice, while you need to level up your skills and all likelihood, don't get stuck in the preparation phase. Learn the basics and move on because you could spend forever thinking, oh, I'm not that good at Python. I need to learn more. I need to learn more. But the truth of the matter is you're going to learn a lot as you develop your plug-in. So learn the basics and get moving on making your plug-in. You definitely don't need to be good at Python to write useful code. It doesn't have to be pretty. It just has to work. So don't stress about that. There's always going to be someone that tells you your code doesn't look right or it's not structured right. Ignore them. Just write code that works and you'll be fine. The other thing is to start small and add incrementally. So don't try to do everything at once. Don't try to make all the code at once. You're going to make yourself crazy hunting down bugs that way. Start with something like a blank plug-in that doesn't do anything. It just adds it to the QGIS. Great. You've done something. Then maybe add a blank interface. And then once you get that working, add a button and then make the button do something and just keep adding piece by piece by piece until you get what you want. And then again, I've got a screenshot here of the plug-in itself and a clip for my notebook of outlining what this interface should look like just on paper and then making it happen. And then some notes about what are the variables that go into each of those boxes. So you can see that this is totally possible. It starts on a piece of paper and it eventually becomes code. So the next part of this is telling people. So when you're working on these plug-ins, it's all great and fine to do it for yourself. But the biggest benefit you can get is by sharing it with others. And this is just the underlying principle of open source community that if you share with others and they share with you collectively, we build all sorts of great things for each other all the time. And so one of those things is you have to let people into the process. You can't just hide your code and keep thinking, oh, I'll release it when it's ready because the one that's ready for you may never come. And so we encourage you to make an online repository. In this case, we use GitHub. And then we release the alpha versions of the plug-in to the QGIS plug-in repository. We're doing market experimental and just so people were aware that it wasn't a polished product. And we made a really straightforward one-page documentation website and put that up and put it out there. And that was one of the biggest first steps in making this something useful is that now there's an opportunity to get feedback and for more people to test and the more people test, the more chance you'll find bugs that need fixing and hopefully bring in other people to help with making it even better. So then there's some really good ways to make all of this public communication better. And the first key one is write some documentation because people need to know how to use your tool. If they don't know how to use your tool, it's not going to gain any traction because they know how to use it. And once you've got some documentation and it doesn't have to be a lot, just the basics, tell people about it. Put it on social media, write a blog post or make a little web page about it. Go to a conference like Phosphor Genie and tell people about it. And if you're an academic, write an article. So the last thing we want to leave you with is the encouragement that you can do this. This is something that I think most people could do with the right skills. So I just want to encourage you to give it a try. Make your own plug-in and see what you can do. And so with that, I guess we're ready for any questions and we're actually going to be live at Phosphor G to answer questions now. So thanks and I hope you do give this a try and let us know how it goes. We'd love to hear from you. Okay. Thanks a lot. That was really cool. And you're both on mute. Alex, there we go. That was cool. I loved the collaboration. You both had some really great advice there. Very encouraging too. So thanks for that. So yeah, let's jump into a few questions. So the first question here is in your plug-in, what does location mean? Is it author affiliation, study area, or editorial location? That's a really good question. And the answer is you get to decide. I would encourage you to make sure that you make that decision upfront and not mix your geometries so you know what they mean. You could probably even, in Zoteri, you can group things into like full-time. Folders or groups of citations. So you could decide for each one of those folders what location you're marking. But yeah, you could make it anything you wanted, actually. Okay. We've got a couple of people asking about tutorials. So do you have any suggestions for good tutorials for studying the basics for developing QGIS plugins or any links? Yeah, so we mostly use the documentation that's in QGIS itself as well as IQT documentation. And then with all QGIS plugins, there's a great plugin out there actually called Plugin Builder that creates the basic plugin for you that you just have to add stuff to. Use it. Don't make all the files from scratch yourself. Have it build the template out for you and then just start filling in things. Yeah, I just dropped the link in the chat, which is probably a little early, not synced up with the feed, but there's the link there for the QGIS Developer Cookbook, which we made a lot of use of. It's got good explanations. So yeah, I would check that out. I think that was useful. I know somebody mentioned that a lot of tutorials aren't free, but this one is. Right. Great. Okay, cool. So this one's asking about the built-in QGIS Python console editor feels extremely limiting compared to other IDEs such as VS Code. Do you have any tips for effectively developing the plugin within QGIS? I don't think that even existed when we started writing the plugin. So we use whatever code editor we want outside of QJS and then there's another plugin that automatically refreshes your code as you're working on it. So you can make edits to your code and then you can hit the refresh and use your plugin right away in QGIS. And then there's also profiles in QGIS now, which lets you switch between, so you can have the release version in one profile and the developer version in another profile and you can toggle between them to see if you broke a feature or what the difference is and how they behave. Very cool. Here's one. Do you envision having a mentally or is that mentally plugin someday? What made you go with Zotero over mentally? So the honest answer is because I use Zotero. So that's what we started with. Also Zotero is really well documented and it's open source as well. Alex, do you know if Mendeley is open source? Heshigan said no. That's what I thought. So Zotero is another open source tool. So that's the main driver and the reason why I was using it in the first place also because there was problems. I used to use N-Note, but there was problems with a change in version that was going to cause problems. So that's why I originally switched to Zotero. So again, Zotero is open source. The API is really well documented and the fact that you can add things to your account with the API was a big driving factor in what made this work. So that's why we chose that. However, if you go to our issue tracker, we do have an issue for developing this literature mapper tool with Mendeley and other tools. So if anybody has experience and thinks they can contribute to that, we'd be happy to have help solving that particular issue. But right now, I don't have the time to do that, but we'd be happy to have help trying to figure out how to do that if anybody has the time and skills. Okay. Here's changing gears a little bit. How do you get over possible this is not good enough? Feelings and thoughts? That's a really good question. I don't know that I've overcome it. I have complete imposter syndrome this morning. Sitting here possibly because it's just before 5 a.m. Pacific time, but also you never feel like it is. You just put it out there and see how people react to it. And you've got to be brave. Just do it. You'll never feel like it's right. You'll never feel like it's good enough. But just try, see what happens. I think you'll be surprised. People, especially in the open source, you know, Geo community are way more supportive than you might expect their general world to be. So, I just, it's okay. Do it. Super supportive community. Yeah. Here's a, probably this is a good one to finish up on. How did you end up working together on this plugin? That's a really good question. We actually have been, how do you say this? Essentially, we're married so that works really well. We are in the same house. We are always working on stuff together, like helping each other with things so that helps. Right. Okay. Well, that, is there anything else you want to share before we wrap up? I guess just encouragement. Like, if you're thinking about doing this, just jump in. Try it. You know, give it a go. Yeah. Okay. Well, cool. Thanks so much for that wonderful talk. Really appreciate it. And yeah, thanks again. Thanks everyone. Okay.
 Okay, we'll get going with the next talk here.  We've got Michelle Tobias and Alex Mandel.  Michelle is a geospatial data specialist at University of California Davis and she's  also a board member of OSGEO.  Alex Mandel is a geospatial engineer at Development Seed and Michelle and Alex have collaborated  on a QGIS plugin to add a geospatial dimension to research citations and they're going to  share some lessons from their experience to help break down the barriers to creating  your own QGIS plugin.  So the talk is pre-recorded but Michelle and Alex are here today, they're here right now,  it's 4.30 in the morning in California so show some mercy but anyway they're here to  answer some questions after the talk so yeah please add your questions to the Vennilis  platform.  So I'll fire up the video here.  Welcome everyone and thanks for coming to our talk which is entitled QGIS plugin development  is not scary.  We've learned from literature mapper.  So who are we?  My name is Michelle Tobias, I am the geospatial data specialist at the University of California  Davis and State of Lab and I'm the mastermind behind literature mapper I guess you could  say.  Most of my coding for this project has been in the realm of the text parsing that needs  to go on in making this plugin work and I just want to confess I'm really bad at Python,  I don't use it on a daily basis so every time I come back to it it's like starting over  so hopefully that's a little bit of an inspiration that you can do this to even if you're not  great at a particular language but I am a frequent user of QGIS, R and SQL so I do have  a programming background just Python isn't my daily jam so.  So my co-presenter today is Alex Mandel, he is a geospatial engineer at development  seed.  For this project he advises on things like feasibility when I come up with grand ideas  he helps me figure out how this is going to work.  He did most of the coding for the interface functions and some of those kinds of things  and he is much better at Python than I am so that makes us a good team for this.  And I just want to have a quick disclaimer that literature mapper is not a product of  UC Davis or development seed this is something we develop on our own time so it's not paid  for by our respective companies.  So what is literature mapper?  It is an experimental plugin for QGIS, it's written in Python and it is currently available  in the plugin repository.  It is a tool that connects Zotero which is an open source citation manager with QGIS  which you guys are all familiar with I'm sure.  And it allows users to georeference citations through QGIS and it stores the location information  alongside the Zotero database so it puts it actually inside Zotero and stores it along  with all of your citation information like author and title of the text and publisher  and year and things like that.  And it keeps all of that spatial data together with the citation information so everything  stays in sync and you don't have to worry about having two files, you know, your spatial  data separate from your citation so the idea is it keeps everything together and we have  a little screen shot of the tool itself in action.  So you can see that, well maybe because it's really small but there's columns in there  for all the things that you might want to have in a citation such as the title and things  like that and then there's also a geometry column.  So this is sort of the workflow for literature mapper how things work under the hood.  Everything is stored in Zotero.  We use the API from Zotero to generate a citation and then we use Python to parse that into  a table for QGIS and then continue using Python to generate the locations which you digitize  by hand but it's still better than you can't automate this process.  It needs to be done by hand.  So we use Python for that because that's what generates the interface and then once you've  generated your locations we send it right back to Zotero with the API.  So that's sort of the general workflow for this particular plugin.  So a little bit of background on literature mapper is that academic journal articles  are often about a specific location.  So things like plants and animals, geology, social justice, history, all of these things  happen in a location and that location actually matters.  So you know I'm a biogeographer by training so things grow, plants grow in a certain place  for a certain reason and that location can be really important to understanding any information  that I generate with research about that particular species.  Just for an example.  So we might actually care about the spatial distributions of the studies that people are  publishing.  All of this academic literature, maybe it matters where the studies are generated.  Maybe it matters where certain aspects of history are taking place and we actually want  to see that on a map.  But there's no way to do that.  There's been no method to connect location data and your citation manager.  And that became a problem for me personally when I was working on my dissertation.  So our team here identified a need that had no available solution and that's really key  to what we're going to be talking about today.  So again we identified a need that didn't have a solution.  So we're not solving something that already has a solution.  You've got to come up with something that is new.  So our building process in terms of creating this plugin is we started with an idea.  The idea actually was this piece of paper which is a map, a really ugly map that I printed  out on a printer many, many years ago and started marking locations of studies on it  in pencil.  I have to confess that I have kept tabs on this piece of paper until last year.  And now all I have is the scan.  I don't know where the actual piece of paper is.  It's probably in my physical office that I haven't been to in almost ten years or two  years, sorry.  So anyway this started out as pencil annotations on a piece of paper.  And we decided that we need to make this actually a tool, right?  So we started prototyping it.  We made a proof of concept of a plugin that kind of did what it needed to do and we kept  iterating on that until we had code that was ready for the QJS plugin repository.  And then we keep developing and we keep adding things to it.  And now it's a tool that's actually gaining steady users even though it's still obviously  could, you can always make stuff better, but people are actually using it for its intended  purpose and that's kind of cool.  So it's been through this whole stage from a piece of paper with pencil drawings on it  into an actual valid research tool.  So next up we're going to tell you about how to prepare for this, how to get going on making  your own plugin.  All right, so there are a few really important key things when you're thinking about making  a new tool and a new plugin.  And the first really big one is when you identify a need that you want to fill, you have to  be very specific about what that need is and be very clear about what does not quite fit  into that because you're going to come up with lots of ideas and they might be related  to your core need, but if they're not really critical, you want to put them aside and make  a list for later so that you can actually get your tool working.  All right, so then the first thing you want to do is not even identifying a need, you  want to look at what already exists that's similar or related and how closely does it  solve or not solve your problem.  And then if you do find some things that are similar, you really need to try them out and  see do they really not work for what you're trying to do?  Is there really a reason why your particular way of doing or solving a problem is uniquely  different that it requires a whole new tool?  Or is there an option to maybe just add a feature to an existing tool or enhance an existing  tool to make it also meet your need in addition to whatever else it was already doing?  Okay, and then once you've decided you're going to make your own tool or your own plugin,  think about the branding for it a little bit because you want a name that's unique and  you want a name that clearly aligns with what your tool does and you don't want that name  to be similar to anything else, whether it's a related tool or not.  You especially don't want it to be a name that's similar to an unrelated tool so when  people are searching the internet, they find things that have nothing to do with what you're  working on.  But you also want to avoid, as in one problem we discovered, which is there's a very similar  tool out there called Journal Map, which we came across a few years after we started,  that does something similar but not quite the same.  And the names are somewhat confusing and easy to mix up.  And so now we have to work harder in order to differentiate our brand and our plugin  to make it clear what our tool does versus what their tool does.  And at least the good thing is now that we have communication with the other development  team, we can jointly do some of that.  All right, the next part of this is we're going to encourage you to make it happen.  This is definitely something you can do.  So some of the tools in my arsenal for getting going and developing a product that actually  functions and does what I want it to do is I often will just draw things out.  I actually have a notebook, you can see a screenshot or not a screenshot, but a scan  of my notebook here in the corner.  Draw out your workflow.  What should it do?  What pieces of information should move from one part of the code to the other?  What should the interface look like?  So in this picture you can see I've actually drawn out what I want my interface to look  like before I actually started putting it together.  And then you can see I've got some notes about what the button should do and what the code  needs to look like under the hood.  And then I've actually coded it and created the actual interface.  And this is a screenshot of the functioning interface that does something very similar  to what the notes in the notebook have.  So I like to draw things out.  And it can be a really helpful way to see like, is this really what I want it to do?  I don't want to spend time building it until I know that it's what I want.  And I'm on the right track.  The other thing is this might be the scariest part.  You probably are going to have to level up your skills.  So there are a lot of free resources out there to help you learn what you need.  For QGIS Python plug-in development, you're going to need to know Python.  You're going to also need to know PyQGIS.  That's the Python tool that works with QGIS.  There's also information, a lot of good information in the documentation about the QGIS plug-in  development workflow.  So how you actually create a plug-in and what are all the bits and pieces that you actually  need to make that go.  And then also you'll need to learn how to use something like GitHub or some other version  control system.  And you really want that because that will help you.  It's got great tools for not only versioning your code, but also tools for in GitHub's  case in particular, there's things like the issues board where you can keep track of ideas  and things that need fixing or you can use branches and things like that for development.  It's just a really helpful tool to have.  But use whatever version control system you like.  I just highly encourage you to use one.  And then specifically for literature mapper, we actually had to learn how to use the Zotero  API.  So they have an API that they use to work with various tools that are associated with  Zotero.  So we could take advantage of that.  And we had to learn that system.  And it's not super complicated, but it was something that it takes time to learn and  you have to be open to learning these kinds of new skills in order to make your plug-in  work.  And whatever plug-in you have in mind, you'll probably have something similar, some domain  knowledge that you'll need in order to make your plug-in work.  And you can see my notes here.  Again, a clip from my notebook of trying to learn the Zotero API and making notes about  what I needed to do.  And I just find that helpful to have it on paper.  But use your own system, whatever works.  And then the next piece of advice, while you need to level up your skills and all likelihood,  don't get stuck in the preparation phase.  Learn the basics and move on because you could spend forever thinking, oh, I'm not that good  at Python.  I need to learn more.  I need to learn more.  But the truth of the matter is you're going to learn a lot as you develop your plug-in.  So learn the basics and get moving on making your plug-in.  You definitely don't need to be good at Python to write useful code.  It doesn't have to be pretty.  It just has to work.  So don't stress about that.  There's always going to be someone that tells you your code doesn't look right or it's not  structured right.  Ignore them.  Just write code that works and you'll be fine.  The other thing is to start small and add incrementally.  So don't try to do everything at once.  Don't try to make all the code at once.  You're going to make yourself crazy hunting down bugs that way.  Start with something like a blank plug-in that doesn't do anything.  It just adds it to the QGIS.  Great.  You've done something.  Then maybe add a blank interface.  And then once you get that working, add a button and then make the button do something  and just keep adding piece by piece by piece until you get what you want.  And then again, I've got a screenshot here of the plug-in itself and a clip for my notebook  of outlining what this interface should look like just on paper and then making it happen.  And then some notes about what are the variables that go into each of those boxes.  So you can see that this is totally possible.  It starts on a piece of paper and it eventually becomes code.  So the next part of this is telling people.  So when you're working on these plug-ins, it's all great and fine to do it for yourself.  But the biggest benefit you can get is by sharing it with others.  And this is just the underlying principle of open source community that if you share  with others and they share with you collectively, we build all sorts of great things for each  other all the time.  And so one of those things is you have to let people into the process.  You can't just hide your code and keep thinking, oh, I'll release it when it's ready because  the one that's ready for you may never come.  And so we encourage you to make an online repository.  In this case, we use GitHub.  And then we release the alpha versions of the plug-in to the QGIS plug-in repository.  We're doing market experimental and just so people were aware that it wasn't a polished  product.  And we made a really straightforward one-page documentation website and put that up and  put it out there.  And that was one of the biggest first steps in making this something useful is that now  there's an opportunity to get feedback and for more people to test and the more people  test, the more chance you'll find bugs that need fixing and hopefully bring in other people  to help with making it even better.  So then there's some really good ways to make all of this public communication better.  And the first key one is write some documentation because people need to know how to use your  tool.  If they don't know how to use your tool, it's not going to gain any traction because  they know how to use it.  And once you've got some documentation and it doesn't have to be a lot, just the basics,  tell people about it.  Put it on social media, write a blog post or make a little web page about it.  Go to a conference like Phosphor Genie and tell people about it.  And if you're an academic, write an article.  So the last thing we want to leave you with is the encouragement that you can do this.  This is something that I think most people could do with the right skills.  So I just want to encourage you to give it a try.  Make your own plug-in and see what you can do.  And so with that, I guess we're ready for any questions and we're actually going to be  live at Phosphor G to answer questions now.  So thanks and I hope you do give this a try and let us know how it goes.  We'd love to hear from you.  Okay.  Thanks a lot.  That was really cool.  And you're both on mute.  Alex, there we go.  That was cool.  I loved the collaboration.  You both had some really great advice there.  Very encouraging too.  So thanks for that.  So yeah, let's jump into a few questions.  So the first question here is in your plug-in, what does location mean?  Is it author affiliation, study area, or editorial location?  That's a really good question.  And the answer is you get to decide.  I would encourage you to make sure that you make that decision upfront and not mix your  geometries so you know what they mean.  You could probably even, in Zoteri, you can group things into like full-time.  Folders or groups of citations.  So you could decide for each one of those folders what location you're marking.  But yeah, you could make it anything you wanted, actually.  Okay.  We've got a couple of people asking about tutorials.  So do you have any suggestions for good tutorials for studying the basics for developing QGIS  plugins or any links?  Yeah, so we mostly use the documentation that's in QGIS itself as well as IQT documentation.  And then with all QGIS plugins, there's a great plugin out there actually called Plugin  Builder that creates the basic plugin for you that you just have to add stuff to.  Use it.  Don't make all the files from scratch yourself.  Have it build the template out for you and then just start filling in things.  Yeah, I just dropped the link in the chat, which is probably a little early, not synced  up with the feed, but there's the link there for the QGIS Developer Cookbook, which we made  a lot of use of.  It's got good explanations.  So yeah, I would check that out.  I think that was useful.  I know somebody mentioned that a lot of tutorials aren't free, but this one is.  Right.  Great.  Okay, cool.  So this one's asking about the built-in QGIS Python console editor feels extremely limiting  compared to other IDEs such as VS Code.  Do you have any tips for effectively developing the plugin within QGIS?  I don't think that even existed when we started writing the plugin.  So we use whatever code editor we want outside of QJS and then there's another plugin that  automatically refreshes your code as you're working on it.  So you can make edits to your code and then you can hit the refresh and use your plugin  right away in QGIS.  And then there's also profiles in QGIS now, which lets you switch between, so you can  have the release version in one profile and the developer version in another profile and  you can toggle between them to see if you broke a feature or what the difference is  and how they behave.  Very cool.  Here's one.  Do you envision having a mentally or is that mentally plugin someday?  What made you go with Zotero over mentally?  So the honest answer is because I use Zotero.  So that's what we started with.  Also Zotero is really well documented and it's open source as well.  Alex, do you know if Mendeley is open source?  Heshigan said no.  That's what I thought.  So Zotero is another open source tool.  So that's the main driver and the reason why I was using it in the first place also because  there was problems.  I used to use N-Note, but there was problems with a change in version that was going to  cause problems.  So that's why I originally switched to Zotero.  So again, Zotero is open source.  The API is really well documented and the fact that you can add things to your account  with the API was a big driving factor in what made this work.  So that's why we chose that.  However, if you go to our issue tracker, we do have an issue for developing this literature  mapper tool with Mendeley and other tools.  So if anybody has experience and thinks they can contribute to that, we'd be happy to have  help solving that particular issue.  But right now, I don't have the time to do that, but we'd be happy to have help trying  to figure out how to do that if anybody has the time and skills.  Okay.  Here's changing gears a little bit.  How do you get over possible this is not good enough?  Feelings and thoughts?  That's a really good question.  I don't know that I've overcome it.  I have complete imposter syndrome this morning.  Sitting here possibly because it's just before 5 a.m. Pacific time, but also you never feel  like it is.  You just put it out there and see how people react to it.  And you've got to be brave.  Just do it.  You'll never feel like it's right.  You'll never feel like it's good enough.  But just try, see what happens.  I think you'll be surprised.  People, especially in the open source, you know, Geo community are way more supportive than  you might expect their general world to be.  So, I just, it's okay.  Do it.  Super supportive community.  Yeah.  Here's a, probably this is a good one to finish up on.  How did you end up working together on this plugin?  That's a really good question.  We actually have been, how do you say this?  Essentially, we're married so that works really well.  We are in the same house.  We are always working on stuff together, like helping each other with things so that helps.  Right.  Okay.  Well, that, is there anything else you want to share before we wrap up?  I guess just encouragement.  Like, if you're thinking about doing this, just jump in.  Try it.  You know, give it a go.  Yeah.  Okay.  Well, cool.  Thanks so much for that wonderful talk.  Really appreciate it.  And yeah, thanks again.  Thanks everyone.  Okay.
FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_0_359.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_360_479.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_480_563.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_564_1007.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_1008_1127.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_1128_1211.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_1212_1355.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_1356_1679.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_1680_1739.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_1740_2183.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_2184_4415.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_4416_6311.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_6312_7403.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_7404_7451.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_7452_7559.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_7560_7607.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_7608_7739.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_7740_7871.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_7872_8003.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_8004_8363.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_8364_9707.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_9708_11927.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_11928_12251.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_12252_13487.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_13488_14759.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_14760_16667.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_16668_16847.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_16848_18683.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_18684_21839.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_21840_22871.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_22872_24275.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_24276_24419.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_24420_26651.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_26652_27707.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_27708_28487.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_28488_28535.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_28536_28583.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_28584_28631.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_28632_38267.png FOSS4G_2021_-_QGIS_Plugin_Development_Is_Not_Scary_VCfQoX5n4Eg_38268_38608.png