Your SlideShare is downloading. ×
Opensource gis development - part 5
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Opensource gis development - part 5


Published on

Fifth part of the Course "Java Open Source GIS Development - From the building blocks to extending an existing GIS application." held at the University of Potsdam in August 2011 …

Fifth part of the Course "Java Open Source GIS Development - From the building blocks to extending an existing GIS application." held at the University of Potsdam in August 2011

Published in: Education

  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide


  • 1. Java Open Source GIS DevelopmentFrom the building blocks to extending an existing GIS application. Geoinformation Research Group, Department of Geography University of Potsdam August 2011 Part 5: Integrating with uDig and OMS3 Tutor: Andrea Antonello ydroloGIS nvironmental ngineeringHydroloGIS S.r.l. - Via Siemens, 19 - 39100 Bolzano
  • 2. Integrating with uDig and OMS3We have learned to develop around raster and vector data, read and writeformats and deal with projections and geometries.We also viewed the maps we produced in a simple and very limited viewer.What possibilities do we have to integrate in a professional way ourknowledge up to this point into a real GIS environment?The solution we will see is the Spatial ToolBox for uDig. The toolboxgenerates, through proper description/annotation of the code, graphical userinterfaces for your module. Modules can be loaded at runtime.
  • 3. Introduction to OMS3The Object Modeling System (OMS3) is a pure Java, object-orientedlightweight modeling framework.OMS allows model construction and model application based oncomponents.It is a collaborative project active among the U.S. Department of Agricultureand partner agencies and organizations involved with agro-environmentalmodeling.The lightweight of the framework consists mainly in the use of annotations inthe code.
  • 4. The 3 steps in modelingBasically OMS3 supplies a set of annotations to put on the code to describeit and to mark fields and methods through them.As in most generic modeling frameworks, the three main steps are: • setting model resources and parameters • executing the model • freeing model resources if necessaryIn order to make the framework understand what has to be used asparameters and what as methods, we just need to annotate them. Theupside is that we can structure our code as we like, using our own way ofnaming of variables and names.
  • 5. The few important things that need to be kept in mind are: • input and output fields have to be set public and annotated with @In and @Out • the method that executes the model, has to have no return value, no parameter and be annotated with @ExecuteAnnotation example of input and output fields: @Description("The map of digital elevation model (DEM).") @In public GridCoverage2D inElev; @Description("The vector on which to calculate the profile.") @In public SimpleFeatureCollection inVector; @Description("The profile.") @Out public double[][] outProfile = null;
  • 6. Example module execution method: @Execute public void process(){ // execute your module here }Example for the resources freeing method: @Finalize public void free(){ // free resources before shutting module downw }
  • 7. Introduction to the uDigs Spatial ToolboxThe Spatial Toolbox is a frontend for GIS users, a graphical user interfacethat can load any OMS3 annotated module.Mouse clicks, region settings, raster resolution and all (most) needed GISnotions are supplied to the widgets automatically. Annotations give hints.The gui labels and documentations are responsability of the moduledeveloper/maintainer.
  • 8. User Interface built through the OMS3 annotations ClassNameThe Class name is not an annotation, but anyways important, since it resultsin the name of the module. Choose it carefully.
  • 9. @LabelThe Label is a class annotation that is interpreted as a category. It is usefulto group various module in categories and subcategories (separated byslash: / ).
  • 10. @In/@OutIn and Out are field annotations that are used to define whether a fieldshould be handled as input or output. In the gui this can result in separatetabs:
  • 11. @DescriptionThe Description annotation can be used for both classes and fields. In thecase of fields it is used as the text for the fields in the gui. In the case ofclasses, it is used in the documentation page.
  • 12. @Units and @RangeThe Units and Range annotations are field annotations that add descriptivetext to the gui.
  • 13. @DocumentationThe Documentation annotation contains a link to the file that holds all themodule documentation, which is placed in the gui as a description tab.
  • 14. @Status, @Name, @Author, @License, @KeywordsAdditional annotations, if available, are used in the gui as additionalinformation for the documentation.
  • 15. @UI, the annotation that makes the gui smarterThe UI annotation is a field/class annotation that aims to make the guismarter. Its content is not standardized, and can be interpreted by the guigenerators to make the widgets more interactive. @UI("infile")Identifies a field that will contain an input (has to exist) file. The textfieldshould present a button to browse the filesystem in open mode.
  • 16. @UI("outfile")Identifies a field that will contain an output (parent folder has to exist) file.The textfield should present a button to browse the filesystem in save mode. @UI("infolder")Identifies a field that will contain an input (has to exist) folder. The textfieldshould present a button to browse the filesystem in open mode.
  • 17. @UI("outfolder")Identifies a field that will contain an output (parent folder has to exist) folder.The textfield should present a button to browse the filesystem in save mode. @UI("crs")Identifies a fields that contains a CRS definition. The textfield should presenta button to browse available CRS definitions.
  • 18. @UI("process_XXXXX")A set of annotations that identify processing region fields. Gui applicationscan make use of these to autocompile the properties of a processing region.Available properties are: process_north, process_south, process_west,process_east, process_xres, process_yres, process_rows, process_cols
  • 19. @UI("multilineX")Identifies a textarea. The X value represents the lines to use. Ex "multiline5"should create a textarea with 5 lines.
  • 20. @UI("northing") and @UI("easting")Identifies a textfield that can autocompile an easting and northing position.Gui applications might be using this to listen to mouse click positions on amap. @UI("hide")Identifies a module that should not be presented in the gui. This might forexample be due to the fact that the module is more than experimental.
  • 21. How to write an OMS3 GIS module?Writing (or porting) an OMS3 module is quite easy. Every module has inputand output parameters and once those are set, it needs to be executed.When writing any module, it is a good manner to keep the handling ofinput and output out of the game. Think it as: another module will takecare of that and pass me the read data.This means that we can assume when writing the module that in most casesthe GIS data will be read and passed over by the Spatial Toolbox and we justneed to implement the algorithm.With that in mind, we will now create a very simple module, in order tounderstand the basics: the reprojection of a vector dataset.
  • 22. The Vector Data Reprojector Writing the moduleFirst thing we create a class named SimpleVectorReprojector.Then we add some descriptive metadata to the class to document it. Mindthat if you dont do documentation while you code, you probably wont beable to catch up with it. @Description("Module for vector reprojection.") @Author(name = "Andrea Antonello", contact = "") @Keywords("CRS, Reprojection, Vector") @Label("Potsdam/Raster") @Status(Status.EXPERIMENTAL) @Name("vectorreproject") @License("General Public License Version 3 (GPLv3)") public class SimpleVectorReprojector {
  • 23. Next we define the input and output variables. Our inputs will be the vectordata to reproject, which at that point we know to be a SimpleFeature-Collection: @Description("The vector that has to be reprojected.") @In public SimpleFeatureCollection inVector;and a code that will define the projection to apply to the data. For the code,which will be in the EPSG format, we can use a String: @Description("The code defining the target crs (ex. EPSG:4328).") @UI("crs") @In public String pCode;Note the @UI("crs") annotation, that will tell the gui generator that weneed a widget to choose coordinate reference systems from.
  • 24. The output will be the reprojected vector data, so again a Simple-FeatureCollection, simply annotated with the @Out annotation: @Description("The output reprojected vector.") @Out public SimpleFeatureCollection outVector = null;Once inputs and output are defined, we now need a method that performsthe processing. In the case of the vector reprojection, the GeoTools librarymakes things really easy: one line to create the CRS from the EPSG codeand one line to reproject and put the result in the output variable. @Execute public void process() throws Exception { CoordinateReferenceSystem targetCrs = CRS.decode(pCode); outVector = new ReprojectingFeatureCollection(inVector, targetCrs); }In this case we do not need to free any resources, so thats it.
  • 25. Building the library for the spatial toolboxThis is the moment in which we are going to be very happy about the factthat we use maven for the project.Building a library that can be loaded into the Spatial Toolbox is as easy asrunning from commandline (inside the project folder, were the pom.xml fileresides: mvn installMaven might download some updated jars and take a little while the firsttime, but then it should state something like: ... [INFO] [surefire:test] [INFO] No tests to run. [INFO] [jar:jar] [INFO] Building jar: /home/moovida/.../jgt-dev-example/target/jgt-dev-example-1.0-SNAPSHOT.jar [INFO] [install:install] [INFO] [install:install] ...
  • 26. The jgt-dev-example-1.0-SNAPSHOT.jar is the library that youwanted to build. It is the library you will load into the spatial toolbox. Youmight even want to rename it to something more in line with its content.By tweaking the pom file, it is also possible to make maven take care ofchanging name and version. This is left as an exercise.
  • 27. uDig and the Spatial Toolbox Installing uDigOnce the module library is packaged, the developer work is done and we canenjoy the user part.To proceed we have to make sure that uDig is installed on your computer.If that is not the case, you just need to go to uDigs download area and getthe installer (or archive) for your operating system. Depending on what youdownloaded you can follow the installers instruction or, in the case of the ziparchive, simply unzip it and run uDig.
  • 28. Loading libraries in the Spatial ToolboxThe next step is to load the library in the uDig Spatial Toolbox.To do so we fire up uDig:
  • 29. To open the Spatial Toolbox go under Window -> Show View -> Other:
  • 30. You will see all available views, from which you select the Spatial Toolbox:
  • 31. which will show up, empty:
  • 32. Push the settings button (the last button on the right):and open the settings dialog:The dialog allows you to load libraries through the plus button.
  • 33. We now can load the library containing the vector reprojector.Mind that uDig will need you to supply all the needed dependencies.Udig itself supplies all the GeoTools dependencies.Since we used also some JGrasstools methods, we will need to load alsothat library.
  • 34. Once the Ok button is pushed, uDig will browse the loaded libraries for OMSannotated modules. To be precise, it searches for modules that have the@Execute annotation and exatracts from them the information needed forthe toolbox. This leads, depending on the loaded libraries, to:
  • 35. If you did everything as explained before, you should have the categoryentries, but the module should not show up. This is due to the fact that wedefined the module as experimental, so the checkbox to activateexperimental support has to be checked:
  • 36. ConclusionsIn this last part we have seen how small yet powerful modules can be easilyintegrated into uDig with a nice graphical user interface without additionaleffort.To summarize the steps: • write a module based on GeoTools, JTS, Jaitools, JGrasstools • annotate the fields and class properly to help the gui generator • bundle the final version of the module in a jar library • load it into uDigs Spatial Toolbox
  • 37. Exercises The line of sightNeeded data • DEM (raster map) • points of interest (vector map) • viewers (vector map)Task Create a module that, finds out how many points of interest every viewer is able to see, if placed at the different heights from the ground: 1 meter, 10 meters, 100 meters. Create MultiLines for every viewer by bundling all the successful lines of sight to a point of interest.
  • 38. The evacuation planNeeded data • the road network (vector map) • the addresse along the roads (vector map) • an evacuation area (vector map)Task Create a module that, given an evacuation area, subdivides that area in circles/annuluses centered in the areas centroid. It then has to produce the list of addresses divided by distance section.
  • 39. Simple zonalstatsNeeded data • DEM (raster map) • basins (vector map)Task Create a module that extracts basics statistics (max, min, avg) from the DEM for each basin of the vector map.
  • 40. This work is released under Creative Commons Attribution ShareAlike (CC-BY-SA)Much of the knowledge needed to create this training material hasbeen produced by the sparkling knights of the GeoTools, JTS anduDig community. Another essential source has been the Wikipediacommunity effort.Particular thanks go to those friends that directly or indirectly helpedout in the creation and review of this developers handbook: JodyGarnett from the uDig/GeoTools community and the TANTO team.This tutorial was written with the support of the GeoinformationResearch Group of the University of Potsdam and HydroloGIS.