GeoNode’s Documentation¶

At the top of the page there are two buttons titled Download Layer and Download Metadata. These buttons provide access to the ability to extract geospatial data and metadata from within GeoNode. In this way, GeoNode allows for two way data and metadata access; one can import as well as export data.

Data¶

1. Click the Download Layer button. You will see a list of options of the supported export formats.

Available export formats

1. Click the option for Zipped Shapefile.
2. GeoNode will process the request and bring up a Save As dialog. Save this file to your computer, and note how it is the same content as was uploaded.

Metadata¶

1. Click the Download Metadata button. You will see a list of options of the supported export formats.

Available metadata export formats

1. Click the option for DUBLIN CORE.
2. GeoNode will process the request and display XML metadata. Try clicking various metadata formats, and note how it is the same metadata content in various formats compatible with metadata and GIS packages.

1. Scroll down the page toward the bottom. Five tabs are available: Info, Attributes, Share, Ratings, and Comments. The info tab is already highlighted, and presents basic information about the layer, of the kind that was seen on the layer list page.

   

   Layer Info tab

2. Click the Attributes tab. This lists the attributes of the layer, including statistics (range, average, median and standard deviation). Layer attribute statistics are made available only for numeric attributes. As we can see, this layer’s attributes are not numeric, so no statistics are calculated.

   

   Attributes tab

3. Click the Ratings tab. This tab allows you (and others viewing this page) to rate this layer. Ratings can be based on quality, accuracy, or any other metric. Click on the appropriate star to rate this layer.

   

   Layer Ratings tab

4. Click the Comments tab. This tab allows you to leave a comment for other viewing this layer.

   

   Layer Comments tab

5. Click the Add Comment button and enter a comment.

   

   Adding a new comment

6. When finished, click Submit Comments

New comment posted

1. Go to the layer preview of the first layer uploaded, and copy the URL to that preview page.

   Note

   The URL should be something like: http://GEONODE/layers/geonode:san_andres_y_providencia_administrative

2. Now log out of GeoNode by clicking on your profile name and selecting Log out.

   

   Log out

3. When asked for confirmation, click the Log out button.

   

   Confirming log out

4. Now paste the URL copied about into your browser address bar and navigate to that location.

5. You will be redirected to the Log In form. This is because when this layer was first uploaded, we set the view properties to be any registered user. Once logged out, we are no longer a registered user and so are not able to see or interact with the layer, unless we log in GeoNode again.

   

   Unable to view this protected layer

6. To stop this process from happening, you need to ensure that your permissions are set so anyone can view the layer for others to see it on social networks.

1. This is done by selecting anyone in the layer permissions tab, be aware this now means your layer is public!

1. On the taskbar below your username and profile picture there are three links to social media services, Twitter, Google Plus and Facebook.

   

2. Upon clicking on these icons you will be taken through the application’s process for posting to the social network. Ensure the permissions are set so anyone can view the layer if you want unauthenticated to be able to access it.

1. Click the Maps link on the top toolbar. This will bring up the list of maps.

   

   Maps page

2. Currently, there aren’t any maps here, so let’s add one. Click the Create a New Map button.

3. A map composition interface will display.

   

   Create maps interface

   In this interface there is a toolbar, layer list, and map window. The map window contains the MapQuest OpenStreetMap layer by default. There are other service layers available here as well: Blue Marble, Bing Aerial With Labels, MapQuest, and OpenStreetMap.

4. Click on the New Layers button and select Add Layers.

   

   Add layers link

5. Select all of the San Andreas layers by clicking the top entry and Shift-clicking the bottom one. Click Add Layers to add them all to the map.

   

   Selecting layers

   Note

   This selection includes not only the two layers uploaded in the previous section, but also the layers that were already hosted on GeoNode at the beginning of the workshop.

6. The layers will be added to the map. Click Done (right next to Add Layers at the bottom) to return to the main layers list.

   

   Layers added to the map

1. Once again, click on the New Layers button and select Add Layers.

   

   Add layers link

2. From the top dropdown list, select Add a New Server...

   

   Add a New Server

3. Enter the URL of the server, and select the correct type of server from the dropdown (WMS, TMS, or ArcGIS). For example, enter http://e-atlas.org.au/geoserver/wms for the URL and select Web Map Service as the type. Then click the Add Server button.

   

   New Server URL and Type

4. Note - for security purposes, the URL you enter must be on a list of pre-approved external services set up by the GeoNode admininistrator. Otherwise you will receive a 403 error when trying to add the server.

5. A list of layers available from that server should appear momentarily. The layers must be available in the Web Mercator projection or they will not show up in the list. Select the layers you want to add to the map. Click Add Layers to add them all to the map.

   

   Add layers

6. The layers will be added to the map. Click Done (right next to Add Layers at the bottom) to return to the main layers list.

   

   Layers added to the map

1. While we still have some work to do on our map, let’s save it so that we can come back to it later. Click on the Map button in the toolbar, and select Save Map.

   

   Save map link

2. Enter a title and abstract for your map.

   

   Save map dialog

3. Click Save. Notice that the link on the top right of the page changed to reflect the map’s name.

   

   Saved map name

   This link contains a permalink to your map. If you open this link in a new window, your map will appear exactly as it was saved.

The Installation of Postgresql-9.2 on Ubuntu 12.04 includes two main steps (Generally, this installation should work for each version of Postgresql!).

1. Add repository to list

   Create an empty file called pgdg.list placed in /etc/apt/sources.list.d/, using these commands

   $ cd /etc/apt/sources.list.d/
   $ sudo touch pgdg.list
   

   Now the following line has to be included the pgdg.list file.

   deb http://apt.postgresql.org/pub/repos/apt/ codename-pgdg main
   

   Instead of codename write the name of your system. If you do not know this, type

   $ lsb_release -c
   

   This will return you the name of your system.

   Warning

   Make sure that you have changed codename to the name of your system before you copy the link in the next step!

   Now open the pgdg.list file using e.g.:

   $ gksu gedit pdgd.list
   

   and copy deb http://apt.postgresql.org/pub/repos/apt/ codename-pgdg main into it.

2. Import Repository key

   Use the following command to do so:

   $ wget --quiet -O - http://apt.postgresql.org/pub/repos/apt/ACCC4CF8.asc | sudo apt-key add -
   

   After that you have to update the package lists using

   $ sudo apt-get update
   

   and then you can install postgresql-9.2 and pgadmin3 (if needed)

   $ sudo apt-get install postgresql-9.2 pgadmin3
   

General

1. Change password

   First of all you have to set a new password for the superuser postgres. In order to do so, type the following command line into your terminal

   $ sudo -u postgres psql postgres
   

   Now you are in psql, the command interface for postgresql, and in the database postgres. In your terminal it looks like this at the moment

   $ postgres=#
   

   To change your password:

   $ \password postgres
   

   and type your new password when asked for it.

2. Create a database (for testing)

   If you want to create a db, posgresql has to know, which user you are. Therefore you have to type -u username in front of the command createdb. If you type the following, it means that you as the user postgres want to create a database wich is called mydb.

   $ sudo -u postgres createdb mydb
   

For geonode

If you do not need that (from the beginning) you can follow this instruction. You can even add the posgis extension later following the steps from the section Alternative. Anyway it is recommended to do the common version.

1. Create a new user (geonode)

   In order to use postgresql in geonode, you have to create a new user geonode, which is the owner of a new database, also called geonode. So first create a new user by typing

   $ sudo -u postgres createuser -P geonode
   

   This means, that you as the user postgres create a new user called geonode. -P indicates, that this user will have a password (geonode).

2. Create new database

   After creating the new user you can create the db geonode:

   $ sudo -u postgres createdb -O geonode geonode
   

Common way

The best way to install the postgis extension is by using templates. After downloading and installing postgresql and postgis you create a database called template_postigsxxx (xxx should be replaced by your version of postgis; in this case postgis 2.0.3 was used).

$ sudo -u postgres createdb template_postgis203

Before installing the extension you have to log in to the database

$ psql template_postgis203

and now you can create the extension

$ create extension postgis;

Now you can easily create a new database wich automatically has the postgis extension as well, e.g create a new database called geonode like this

$ sudo -u postgres createdb -T template_postgis203 geonode

Alternative

If you already created a db called geonode, then you can use this alternative to create the extension for postigs.

By typing

$ sudo su postgres

you log in as the user postgres.

By using the following command line

$ psql geonode

you log in to the database geonode.

To install the posgis extension type

$ create extension postgis;

Now you should have successfully installed the postgis extension in your geonode database.

Your first step will be to create a user. There are three options to do so, depending on which kind of user you want to create you may choose a different option. We will start with creating a superuser, because this user is the most important. A superuser has all the permissions without explicitly assigning them.

The easiest way to create a superuser (in linux) is to open your terminal and type:

$ geonode createsuperuser

If you installed geonode by source you have to take the following commands:

$ source .venvs/geonode/bin activate
$ django-admin.py createsuperuser --settings=geonode.settings

You will be asked a username (in this tutorial we will call the superuser you now create your_superuser), an email address and a password.

Now you’ve created a superuser you should become familiar with the Django Admin Interface. As a superuser you are having access to this interface, where you can manage users, layers, permission and more. To learn more detailed about this interface check this LINK. For now it will be enough to just follow the steps. To attend the Django Admin Interface, go to your geonode website and sign in with your_superuser. Once you’ve logged in, the name of your user will appear on the top right. Click on it and the following menu will show up:

Clicking on Admin causes the interface to show up.

Go to Auth -> Users and you will see all the users that exist at the moment. In your case it will only be your_superuser. Click on it, and you will see a section on Personal Info, one on Permissions and one on Important dates. For the moment, the section on Permissions is the most important.

As you can see, there are three boxes that can be checked and unchecked. Because you’ve created a superuser, all three boxes are checked as default. If only the box active would have been checked, the user would not be a superuser and would not be able to access the Django Admin Interface (which is only available for users with the staff status). Therefore keep the following two things in mind:

• a superuser is able to access the Django Admin Interface and he has all permissions on the data uploaded to GeoNode.
• an ordinary user (created from the GeoNode interface) only has active permissions by default. The user will not have the ability to access the Django Admin Interface and certain permissions have to be added for him.

Until now we’ve only created superusers. So how do you create an ordinary user? You have two options:

1. Django Admin Interface

   First we will create a user via the Django Admin Interface because we’ve still got it open. Therefore go back to Auth -> Users and you should find a button on the right that says Add user.

   

   Click on it and a form to fill out will appear. Name the new user test_user, choose a password and click save at the right bottom of the site.

   

   Now you should be directed to the site where you could change the permissions on the user test_user. As default only active is checked. If you want this user also to be able to attend this admin interface you could also check staff status. But for now we leave the settings as they are!

   To test whether the new user was successfully created, go back to the GeoNode web page and try to sign in.

2. GeoNode website

   To create an ordinary user you could also just use the GeoNode website. If you installed GeoNode using a release, you should

   see a Register button on the top, beside the Sign in button (you might have to log out before).

   

   Hit the button and again a form will appear for you to fill out. This user will be named geonode_user

   

   By hitting Sign up the user will be signed up, as default only with the status active.

As mentioned before, this status can be changed as well. To do so, sign in with your_superuser again and attend the admin interface. Go again to Auth -> Users, where now three users should appear:

We now want to change the permission of the geonode_user so that he will be able to attend the admin interface as well. Click on to geonode_user and you will automatically be moved to the site where you can change the permissions. Check the box staff status and hit save to store the changes.

To sum it up, we have now created three users with different kind of permissions.

• your_superuser: This user is allowed to attend the admin interface and has all available permissions on layers, maps etc.
• geonode_user: This user is permitted to attend the admin interface, but permissions on layers, maps etc. have to be assigned.
• test_user: This user is not able to attend the admin interface, permissions on layers, maps etc. have also to be assigned.

You should know have an overview over the different kinds of users and how to create and edit them. You’ve also learned about the permissions a certain user has and how to change them using the Django Admin Interface.

Now that we’ve already created some users, we will take a closer look on the security of layers, how you can protect your data not to be viewed or edited by unwanted users.

The permissions on a certain layer can already be set when uploading your files. When the upload form appears (Layers -> Upload Layer) you will see the permission section on the right side:

As it can be seen here, the access on your layer is split up into three groups:

• view and download data
• edit data
• manage and edit data

The difference between manage and edit layer and edit layer is that a user assigned to edit layer is not able to change the permissions on the layer whereas a user assigned to manage and edit layer can change the permissions. You can now choose whether you want your layer to be viewed and downloaded by

• anyone
• any registered user
• a certain user (or group)

We will now upload our test layer like shown HERE. If you want your layer only be viewed by certain users or a group, you have to choose Only users who can edit in the part Who can view and download this data. In the section Who can edit this data you write down the names of the users you want to have admission on this data. For this first layer we will choose the settings like shown in the following image:

If you now log out, your layer can still be seen, but the unregistered users won’t be able to edit your layer. Now sign in as geonode_user and click on the test layer. Above the layer you can see this:

The geonode_user is able to edit the test_layer. But before going deeper into this, we have to first take a look on another case. As an administrator you might also upload your layers to geoserver and then make them available on GeoNode using updatelayers. Or you even add the layers via the terminal using importlayers (LINK TUTORIAL). To set the permissions on this layer, click on the test layer (you’ve uploaded via updatelayers) and you will see the same menu as shown in the image above. Click Edit layer and the menu will appear.

Choose edit permissions and a window with the permission settings will appear. This window can also be opened by scrolling down the website. On the right-hand side of the page you should be able to see a button like this.

Click on it and you will see the same window as before.

Now set the permissions of this layer using the following settings:

When you assign a user to be able to edit your data, this user is allowed to execute all of the following actions:

• edit metadata
• edit styles
• manage styles
• replace layer
• remove layer

So be aware that each user assigned to edit this layer can even remove it! In our case, only the user test_user and your_superuser do have the rights to do so. Geonode_user is neither able to view nor to download or edit this layer.

Now you are logged in as the user test_user. Below the test_layer you can see the following:

By clicking Edit Layer and Edit Metadata on top of the layer, you can change this information. The test_user is able to change all the metadata of this layer. We now want to change to point of contact, therefore scroll down until you see this:

Change the point of contact from _who_ever_created_this to test_user. Save your changes and you will now be able to see the following:

To learn how you can edit metadata or change the styles go to this section LINK.

The permission on maps are basically the same as on layers, just that there are fewer options on how to edit the map. Let’s create a map (or already TUTORIAL?). Click on test_map and scroll down till you see this:

Here you can set the same permissions as known from the layer permissions! Set the permissions of this map as seen here:

Save your changes and then log out and log in as test_user. You should now be able to view the test_map and click on to Edit map.

As you may recognize, this user is not able to change the permissions on this map. If you log in as the user geonode_user you should be able to see the button change map permissions when you scroll down the page.

All the same is also valid for your uploaded documents.

OGR is used to manipulate vector data. In this example, we will use MapInfo .tab files and convert them to shapefiles with the ogr2ogr command. We will use sample MapInfo files from the website linked below.

http://services.land.vic.gov.au/landchannel/content/help?name=sampledata

You can download the Admin;(Postcode) layer by issuing the following command:

$ wget http://services.land.vic.gov.au/sampledata/mif/admin_postcode_vm.zip

You will need to unzip this dataset by issuing the following command:

$ unzip admin_postcode_vm.zip

This will leave you with the following files in the directory where you executed the above commands:

|-- ANZVI0803003025.htm
|-- DSE_Data_Access_Licence.pdf
|-- VMADMIN.POSTCODE_POLYGON.xml
|-- admin_postcode_vm.zip
--- vicgrid94
    --- mif
        --- lga_polygon
            --- macedon\ ranges
                |-- EXTRACT_POLYGON.mid
                |-- EXTRACT_POLYGON.mif
                --- VMADMIN
                    |-- POSTCODE_POLYGON.mid
                    --- POSTCODE_POLYGON.mif

First, lets inspect this file set using the following command:

$ ogrinfo -so vicgrid94/mif/lga_polygon/macedon\ ranges/VMADMIN/POSTCODE_POLYGON.mid POSTCODE_POLYGON

The output will look like the following:

Had to open data source read-only.
INFO: Open of `vicgrid94/mif/lga_polygon/macedon ranges/VMADMIN/POSTCODE_POLYGON.mid'
    using driver `MapInfo File' successful.

Layer name: POSTCODE_POLYGON
Geometry: 3D Unknown (any)
Feature Count: 26
Extent: (2413931.249367, 2400162.366186) - (2508952.174431, 2512183.046927)
Layer SRS WKT:
PROJCS["unnamed",
    GEOGCS["unnamed",
        DATUM["GDA94",
            SPHEROID["GRS 80",6378137,298.257222101],
            TOWGS84[0,0,0,-0,-0,-0,0]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",-36],
    PARAMETER["standard_parallel_2",-38],
    PARAMETER["latitude_of_origin",-37],
    PARAMETER["central_meridian",145],
    PARAMETER["false_easting",2500000],
    PARAMETER["false_northing",2500000],
    UNIT["Meter",1]]
PFI: String (10.0)
POSTCODE: String (4.0)
FEATURE_TYPE: String (6.0)
FEATURE_QUALITY_ID: String (20.0)
PFI_CREATED: Date (10.0)
UFI: Real (12.0)
UFI_CREATED: Date (10.0)
UFI_OLD: Real (12.0)

This gives you information about the number of features, the extent, the projection and the attributes of this layer.

Next, lets go ahead and convert this layer into a shapefile by issuing the following command:

$ ogr2ogr -t_srs EPSG:4326 postcode_polygon.shp vicgrid94/mif/lga_polygon/macedon\ ranges/VMADMIN/POSTCODE_POLYGON.mid POSTCODE_POLYGON

Note that we have also reprojected the layer to the WGS84 spatial reference system with the -t_srs ogr2ogr option.

The output of this command will look like the following:

Warning 6: Normalized/laundered field name: 'FEATURE_TYPE' to 'FEATURE_TY'
Warning 6: Normalized/laundered field name: 'FEATURE_QUALITY_ID' to 'FEATURE_QU'
Warning 6: Normalized/laundered field name: 'PFI_CREATED' to 'PFI_CREATE'
Warning 6: Normalized/laundered field name: 'UFI_CREATED' to 'UFI_CREATE'

This output indicates that some of the field names were truncated to fit into the constraint that attributes in shapefiles are only 10 characters long.

You will now have a set of files that make up the postcode_polygon.shp shapefile set. We can inspect them by issuing the following command:

$ ogrinfo -so postcode_polygon.shp postcode_polygon

The output will look similar to the output we saw above when we inspected the MapInfo file we converted from:

INFO: Open of `postcode_polygon.shp'
      using driver `ESRI Shapefile' successful.

Layer name: postcode_polygon
Geometry: Polygon
Feature Count: 26
Extent: (144.030296, -37.898156) - (145.101137, -36.888878)
Layer SRS WKT:
GEOGCS["GCS_WGS_1984",
    DATUM["WGS_1984",
        SPHEROID["WGS_84",6378137,298.257223563]],
    PRIMEM["Greenwich",0],
    UNIT["Degree",0.017453292519943295]]
PFI: String (10.0)
POSTCODE: String (4.0)
FEATURE_TY: String (6.0)
FEATURE_QU: String (20.0)
PFI_CREATE: Date (10.0)
UFI: Real (12.0)
UFI_CREATE: Date (10.0)
UFI_OLD: Real (12.0)

These files can now be loaded into your GeoNode instance via the normal uploader.

Visit the upload page in your GeoNode, drag and drop the files that composes the shapefile that you have generated using the GDAL ogr2ogr command (postcode_polygon.dbf, postcode_polygon.prj, postcode_polygon.shp, postcode_polygon.shx). Give the permissions as needed and then click the “Upload files” button.

As soon as the import process completes, you will have the possibility to go straight to the layer info page (“Layer Info” button), or to edit the metadata for that layer (“Edit Metadata” button), or to manage the styles for that layer (“Manage Styles”).

Now that we have seen how to convert vector layers into shapefiles using ogr2ogr, we will walk through the steps necessary to perform the same operation with Raster layers. For this example, we will work with Arc/Info Binary and ASCII Grid data and convert it into GeoTiff format for use in GeoNode.

First, you need to download the sample data to work with it. You can do this by executing the following command:

$ wget http://dev.opengeo.org/~jjohnson/sample_asc.tgz

You will need to uncompress this file by executing this command:

$ tar -xvzf sample_asc.tgz

You will be left with the following files on your filesystem:

|-- batemans_ele
|   |-- dblbnd.adf
|   |-- hdr.adf
|   |-- metadata.xml
|   |-- prj.adf
|   |-- sta.adf
|   |-- w001001.adf
|   |-- w001001x.adf
|-- batemans_elevation.asc

The file batemans_elevation.asc is an Arc/Info ASCII Grid file and the files in the batemans_ele directory are an Arc/Info Binary Grid file.

You can use the gdalinfo command to inspect both of these files by executing the following command:

$ gdalinfo batemans_elevation.asc

The output should look like the following:

Driver: AAIGrid/Arc/Info ASCII Grid
Files: batemans_elevation.asc
Size is 155, 142
Coordinate System is `'
Origin = (239681.000000000000000,6050551.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Corner Coordinates:
Upper Left  (  239681.000, 6050551.000)
Lower Left  (  239681.000, 6036351.000)
Upper Right (  255181.000, 6050551.000)
Lower Right (  255181.000, 6036351.000)
Center      (  247431.000, 6043451.000)
Band 1 Block=155x1 Type=Float32, ColorInterp=Undefined
    NoData Value=-9999

You can then inspect the batemans_ele files by executing the following command:

$ gdalinfo batemans_ele

And this should be the corresponding output:

Driver: AIG/Arc/Info Binary Grid
Files: batemans_ele
    batemans_ele/dblbnd.adf
    batemans_ele/hdr.adf
    batemans_ele/metadata.xml
    batemans_ele/prj.adf
    batemans_ele/sta.adf
    batemans_ele/w001001.adf
    batemans_ele/w001001x.adf
Size is 155, 142
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["GDA94",
        DATUM["Geocentric_Datum_of_Australia_1994",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6283"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4283"]],
    PROJECTION["Transverse_Mercator"],
    PARAMETER["latitude_of_origin",0],
    PARAMETER["central_meridian",153],
    PARAMETER["scale_factor",0.9996],
    PARAMETER["false_easting",500000],
    PARAMETER["false_northing",10000000],
    UNIT["METERS",1]]
Origin = (239681.000000000000000,6050551.000000000000000)
Pixel Size = (100.000000000000000,-100.000000000000000)
Corner Coordinates:
Upper Left  (  239681.000, 6050551.000) (150d 7'28.35"E, 35d39'16.56"S)
Lower Left  (  239681.000, 6036351.000) (150d 7'11.78"E, 35d46'56.89"S)
Upper Right (  255181.000, 6050551.000) (150d17'44.07"E, 35d39'30.83"S)
Lower Right (  255181.000, 6036351.000) (150d17'28.49"E, 35d47'11.23"S)
Center      (  247431.000, 6043451.000) (150d12'28.17"E, 35d43'13.99"S)
Band 1 Block=256x4 Type=Float32, ColorInterp=Undefined
    Min=-62.102 Max=142.917
NoData Value=-3.4028234663852886e+38

You will notice that the batemans_elevation.asc file does not contain projection information while the batemans_ele file does. Because of this, lets use the batemans_ele files for this exercise and convert them to a GeoTiff for use in GeoNode. We will also reproject this file into WGS84 in the process. This can be accomplished with the following command.

$ gdalwarp -t_srs EPSG:4326 batemans_ele batemans_ele.tif

The output will show you the progress of the conversion and when it is complete, you will be left with a batemans_ele.tif file that you can upload to your GeoNode.

You can inspect this file with the gdalinfo command:

$ gdalinfo batemans_ele.tif

Which will produce the following output:

Driver: GTiff/GeoTIFF
Files: batemans_ele.tif
Size is 174, 130
Coordinate System is:
GEOGCS["WGS 84",
    DATUM["WGS_1984",
        SPHEROID["WGS 84",6378137,298.257223563,
            AUTHORITY["EPSG","7030"]],
        AUTHORITY["EPSG","6326"]],
    PRIMEM["Greenwich",0],
    UNIT["degree",0.0174532925199433],
    AUTHORITY["EPSG","4326"]]
Origin = (150.119938943722502,-35.654598806259330)
Pixel Size = (0.001011114155919,-0.001011114155919)
Metadata:
    AREA_OR_POINT=Area
Image Structure Metadata:
    INTERLEAVE=BAND
Corner Coordinates:
Upper Left  ( 150.1199389, -35.6545988) (150d 7'11.78"E, 35d39'16.56"S)
Lower Left  ( 150.1199389, -35.7860436) (150d 7'11.78"E, 35d47' 9.76"S)
Upper Right ( 150.2958728, -35.6545988) (150d17'45.14"E, 35d39'16.56"S)
Lower Right ( 150.2958728, -35.7860436) (150d17'45.14"E, 35d47' 9.76"S)
Center      ( 150.2079059, -35.7203212) (150d12'28.46"E, 35d43'13.16"S)
Band 1 Block=174x11 Type=Float32, ColorInterp=Gray

You can then follow the same steps we used above to upload the GeoTiff file we created into the GeoNode, and you will see your layer displayed in the Layer Info page.

Now that you have seen how to convert layers with both OGR and GDAL, you can use these techniques to work with your own data and get it prepared for inclusion in your own GeoNode.

Now that we have osm data on our filesystem, we will need to convert it into a format suitable for uploading into your GeoNode. There are many ways to accomplish this, but for purposes of this example, we will use an OSM QGIS plugin that makes if fairly easy. Please consult the wiki page that explains how to install this plugin and make sure it is installed in your QGIS instance. Once its installed, you can use the Web Menu to load your file.

This will bring up a dialog box that you can use to find and convert the osm file we downloaded.

When the process has completed, you will see your layers in the Layer Tree in QGIS.

Since we are only interested in the polygons, we can turn the other 2 layers off in the Layer Tree.

The next step is to use QGIS to convert this layer into a Shapefile so we can upload it into GeoNode. To do this, select the layer in the Layer tree, right click and then select the Save As option.

This will bring up the Save Vector Layer as Dialog.

Specify where on disk you want your file saved, and hit Save then OK.

You now have a shapefile of the data you extracted from OSM that you can use to load into GeoNode. Use the GeoNode Layer Upload form to load the Shapefile parts into your GeoNode, and optionally edit the metadata and then you can view your layer in the Layer Info page in your geonode.

An alternative way to export the .osm file to a shapefile is to use ogr2ogr combined with the GDAL osm driver, available from GDAL version 1.10.

As a first step, inspect how the GDAL osm driver sees the .osm file using the ogrinfo command:

$ ogrinfo cite_soleil_buildings.osm
Had to open data source read-only.
INFO: Open of `cite_soleil_buildings.osm'
      using driver `OSM' successful.
1: points (Point)
2: lines (Line String)
3: multilinestrings (Multi Line String)
4: multipolygons (Multi Polygon)
5: other_relations (Geometry Collection)

ogrinfo has detected 5 different geometric layers inside the osm data source. As we are just interested in the buildings, you will just export to a new shapefile the multipolygons layer using the GDAL ogr2ogr command utility:

$ ogr2ogr cite_soleil_buildings cite_soleil_buildings.osm multipolygons

Now you can upload the shapefile to GeoNode using the GeoNode Upload form in the same manner as you did in the previous section.

manage.py is the main entry point for managing your project during development. It allows running all the management commands from each app in your project. When run with no arguments, it will list all of the management commands.

settings.py is the primary settings file for your project. It imports the settings from the system geonode and adds the local paths. It is quite common to put all sensible defaults here and keep deployment specific configuration in the local_settings.py file. All of the possible settings values and their meanings are detailed in the Django documentation.

A common paradigm for handing ‘local settings’ (and in other areas where some python module may not be available) is:

try:

from local_settings import *

except:

pass

This is not required and there are many other solutions to handling varying deployment configuration requirements.

urls.py is where your application specific URL routes go. Additionally, any overrides can be placed here, too.

This is a generated file to make deploying your project to a WSGI server easier. Unless there is very specific configuration you need, wsgi.py can be left alone.

There are several packaging options in python but a common approach is to place your project metadata (version, author, etc.) and dependencies in setup.py.

This is a large topic and not necessary to understand while getting started with GeoNode development but will be important for larger projects and to make development easier for other developers.

More: http://docs.python.org/2/distutils/setupscript.html

The static directory will contain your fixed resources: css, html, images, etc. Everything in this directory will be copied to the final media directory (along with the static resources from other apps in your project).

All of your projects templates go in the templates directory. While no organization is required for your project specific templates, when overriding or replacing a template from another app, the path must be the same as the template to be replaced.

GeoNode intentionally does not include a large number of graphics files in its interface. This keeps page loading time to a minimum and makes for a more responsive interface. That said, you are free to customize your GeoNode’s interface by simply changing the default logo, or by adding your own images and graphics to deliver a GeoNode experience the way you envision int.

Your GeoNode project has a directory already set up for storing your own images at <my_geonode>/static/img. You should place any image files that you intend to use for your project in this directory.

Let’s walk through an example of the steps necessary to change the default logo.

1. Change into the img directory:

   $ cd <my_geonode>/static/img
   

2. If you haven’t already, obtain your logo image. The URL below is just an example, so you will need to change this URL to match the location of your file or copy it to this location:

   $ wget http://www2.sta.uwi.edu/~anikov/UWI-logo.JPG
   $ cd ../../..
   

3. Override the CSS that displays the logo by editing <my_geonode>/static/css/site_base.css with your favorite editor and adding the following lines, making sure to update the width, height, and URL to match the specifications of your image.

   .nav-logo {
       width: 373px;
       height: 79px;
       background: url(../img/UWI-logo.JPG) no-repeat;
   }
   

4. Restart your GeoNode project and look at the page in your browser:

   $ python manage.py runserver
   

Visit your site at http://localhost:8000/ or the remote URL for your site.

Custom logo

You can see that the header has been expanded to fit your graphic. In the following sections you will learn how to customize this header to make it look and function the way you want.

In the last section you already learned how to override GeoNode’s default CSS rules to include your own logo. You are able to customize any aspect of GeoNode’s appearance this way. In the last screenshot, you saw that the main area in the homepage is covered up by the expanded header.

First, we’ll walk through the steps necessary to displace it downward so it is no longer hidden, then change the background color of the header to match the color in our logo graphic.

1. Reopen <my_geonode>/static/css/site_base.css in your editor and add the following rule after the one added in the previous step:

   .content-wrap {
       margin: 75px 75px;
   }
   

2. Add a rule to change the background color of the header to match the logo graphic we used:

   .navbar .navbar-inner {
       background: #0e60c3;
   }
   

3. Your project CSS file should now look like this:

   .nav-logo {
       width: 373px;
       height: 79px;
       background: url(../img/UWI-logo.JPG) no-repeat;
   }
   
   .content-wrap {
       margin: 75px 75px;
   }
   
   .navbar .navbar-inner {
       background: #0e60c3;
   }
   

4. Restart the development server and reload the page:

   $ python manage.py runserver
   

   

   CSS overrides

Note

You can continue adding rules to this file to override the styles that are in the GeoNode base CSS file which is built from base.less. You may find it helpful to use your browser’s development tools to inspect elements of your site that you want to override to determine which rules are already applied. See the screenshot below. Another section of this workshop covers this topic in much more detail.

Screenshot of using Chrome’s debugger to inspect the CSS overrides

Now that we have changed the default logo and adjusted our main content area to fit the expanded header, the next step is to update the content of the homepage itself. Your GeoNode project includes two basic templates that you will use to change the content of your pages.

The file site_base.html (in <my_geonode>/templates/) is the basic template that all other templates inherit from and you will use it to update things like the header, navbar, site-wide announcement, footer, and also to include your own JavaScript or other static content included in every page in your site. It’s worth taking a look at GeoNode’s base file on GitHub. You have several blocks available to you to for overriding, but since we will be revisiting this file in future sections of this workshop, let’s just look at it for now and leave it unmodified.

Open <my_geonode>/templates/site_base.html in your editor:

{% extends "base.html" %}
{% block extra_head %}
    <link href="{{ STATIC_URL }}css/site_base.css" rel="stylesheet"/>
{% endblock %}

You will see that it extends from base.html, which is the GeoNode template referenced above and it currently only overrides the extra_head block to include our project’s site_base.css which we modified in the previous section. You can see on line 14 of the GeoNode base.html template that this block is included in an empty state and is set up specifically for you to include extra CSS files as your project is already set up to do.

Now that we have looked at site_base.html, let’s actually override a different template.

The file site_index.html is the template used to define your GeoNode project’s homepage. It extends GeoNode’s default index.html template and gives you the option to override specific areas of the homepage like the hero area, but also allows you leave area like the “Latest Layers” and “Maps” and the “Contribute” section as they are. You are of course free to override these sections if you choose and this section shows you the steps necessary to do that below.

1. Open <my_geonode>/templates/site_index.html in your editor.

2. Edit the <h1> element on line 13 to say something other than “Welcome”:

   <h1>{% trans "UWI GeoNode" %}</h1>
   

3. Edit the introductory paragraph to include something specific about your GeoNode project:

   <p>
       {% blocktrans %}
       UWI's GeoNode is setup for students and faculty to collaboratively
       create and share maps for their class projects. It is maintained by the
       UWI Geographical Society.
       {% endblocktrans %}
   </p>
   

4. Change the Getting Started link to point to another website:

   <span>
       For more information about the UWI Geographical society,
       <a href="http://uwigsmona.weebly.com/">visit our website</a>
   </span>
   

5. Add a graphic to the hero area above the paragraph replaced in step 3:

   <img src = 'http://uwigsmona.weebly.com/uploads/1/3/2/4/13241997/1345164334.png'>
   

6. Your edited site_index.html file should now look like this:

   {% extends 'index.html' %}
   {% load i18n %}
   {% load maps_tags %}
   {% load layers_tags %}
   {% load pagination_tags %}
   {% load staticfiles %}
   {% load url from future %}
   {% comment %}
   This is where you can override the hero area block. You can simply modify the content below or replace it wholesale to meet your own needs.
   {% endcomment %}
   {% block hero %}
       <div class="hero-unit">
           <h1>{% trans "UWI GeoNode" %}</h1>
           <div class="hero-unit-content">
           <div class="intro">
               <img src = 'http://uwigsmona.weebly.com/uploads/1/3/2/4/13241997/1345164334.png'>
           <p>
               {% blocktrans %}
               UWI's GeoNode is setup for students and faculty to collaboratively
               create and share maps for their class projects. It is maintained by the
               UWI Geographical Society.
               {% endblocktrans %}
           </p>
           <span>
               For more information about the UWI Geographical society,
               <a href="http://uwigsmona.weebly.com/">visit our website</a>
           </span>
       </div>
       <div class="btns">
           <a class="btn btn-large" href="{% url "layer_browse" %}">
           {% trans "Explore Layers" %}
           </a>
           <a class="btn btn-large" href="{% url "maps_browse" %}">
           {% trans "Explore Maps" %}
           </a>
       </div>
   </div>
   {% endblock %}
   

7. Restart your GeoNode project and view the changes in your browser at http://localhost:8000/ or the remote URL for your site:

   $ python manage.py runserver
   

   

From here you can continue to customize your site_index.html template to suit your needs. This workshop will also cover how you can add new pages to your GeoNode project site.

You are able to change any specific piece of your GeoNode project’s style by adding CSS rules to site_base.css, but since GeoNode is based on Bootstrap, there are many pre-defined themes that you can simply drop into your project to get a whole new look. This is very similar to WordPress themes and is a powerful and easy way to change the look of your site without much effort.

Hint, if bash-completion is installed, try <TAB><TAB> to get completions.

1. start/stop services

   $ sudo service apache2
   $ sudo service apache2 reload
   $ sudo service tomcat7
   $ sudo service postgresql
   

2. basic psql interactions

   $ sudo su - postgres
   $ psql
   => help                 # get help
   => \?                   # psql specific commands
   => \l                   # list databases
   => \c geonode           # switch database
   => \ds                  # list tables
   => \dS layers_layer     # describe table
   

The GeoNode development process relies on several widely used python development tools in order to make things easier for developers and other users of the systems that GeoNode developers work on or where GeoNodes are deployed. They are considered best practices for modern python development, and you should become familiar with these basic tools and be comfortable using them on your own projects and systems.

GeoNode is built on top of the Django web framework, and as such, you will need to become generally familiar with Django itself in order to become a productive GeoNode developer. Django has excellent documentation, and you should familiarize yourself with Django by following the Django workshop and reading through its documentation as required.

geonode.layers is the most key GeoNode module. It is used to represent layers of data stored in a GeoNode’s paired GeoServer. The layer model class inherits fields from the ResourceBase class which provides all of the fields necessary for the metadata catalogue, and adds fields that map the object to its corresponding layer in GeoServer. When your users upload a layer via the user interface, the layer is imported to GeoServer and a record is added to GeoNode’s database to represent that GeoServer layer within GeoNode itself.

The Layer model class provides a set of helper methods that are used to perform operations on a Layer object, and also to return things such as the list of Download or Metadata links for that layer. Additional classes are used to model the layers Attributes, Styles, Contacts and Links. The Django signals framework is used to invoke specific functions to synchronize with GeoServer before and after the layer is saved.

The views in the layers app are used to perform functions such as uploading, replacing, removing or changing the points of contact for a layer, and views are also used to update layer styles, download layers in bulk or change a layers permissions.

The forms module in the layer app is used to drive the user interface forms necessary for performing the business logic that the views provide.

The Layers app also includes a set of templates that are paired with views and used to drive the user interface. A small set of layer template tags is also used to help drive the layer explore and search pages.

Some helper modules such as geonode.layers.metadata and geonode.layers.ows are used by the layer views to perform specific functions and help keep the main views module more concise and legible.

Additionally, the GeoNode specific management commands are a part of the geonode.layers app.

You should spend some time to review the layers app through GitHubs code browsing interface.

https://github.com/GeoNode/geonode/tree/master/geonode/layers

The geonode.maps app is used to group together GeoNodes multi layer map functionality. The Map and MapLayer objects are used to model and implement maps created with the GeoExplorer application. The Map object also extends from the ResourceBase class which provides the ability to manage a full set of metadata fields for a Map.

The views in the maps app perform many of the same functions as the views in the layers app such as adding, changing, replacing or removing a map and also provide the endpoints for returning the map configuration from the database that is used to initialize the GeoExplorer app.

The maps app also includes a set of forms, customization of the Django admin, some utility functions and a set of templates and template tags.

You can familiarize yourself with the maps app on GitHub.

https://github.com/GeoNode/geonode/tree/master/geonode/layers

The geonode.security app is used to provide object level permissions within the GeoNode Django application. It is a custom Django authentication backend and is used to assign Generic, User and Group Permissions to Layers, Maps and other objects in the GeoNode system. Generic permissions are used to enable public anonymous or authenticated viewing and/or editing of your data layers and maps, and User and Group specific permissions are used to allow specific users or groups to access and edit your layers.

The geonode.search module provides the search API that is used to drive the GeoNode search pages. It is configured to index layers, maps, documents and profiles, but is extensible to allow you to use it to index your own model classes. This module is currently based on the Django ORM and as such has a limited set of search features, but the GeoNode development team is actively working on making it possible to use this module with more feature-rich search engines.

The geonode.catalogue app provides a key set of metadata catalogue functions within GeoNode itself. GeoNode is configured to use an integrated version of the pycsw library to perform these functions, but can also be configured to use any OGC compliant CS-W implementation such as GeoNetwork or Deegree. The metadata app allows users to import and/or edit metadata for their layers, maps and documents, and it provides an OGC compliant search interface for use in federating with other systems.

The geonode.geoserver module is used to interact with GeoServer from within GeoNode’s python code. It relies heavily on the gsconfig library which addresses GeoServer’s REST configuration API. Additionally, the geonode.geoserver.uploader module is used to interact with GeoServers Importer API for uploading and configuring layers.

The geonode.people module is used to model and store information about both GeoNode users and people outside of the system who are listed as Points of Contact for particular layers. It is the foundational module for GeoNode’s social features. It provides a set of forms for users to edit and manage their own profiles as well as to view and interact with the profiles of other users.

GeoNode’s core GIS client functions are performed by GeoExplorer. The GeoExplorer app is in turn based on GeoExt, OpenLayers and ExtJS. It provides functionality for constructing maps, styling layers and connecting to remote services. GeoExplorer is the reference implementation of the OpenGeo Suite SDK which is based on GXP. GeoNode treats GeoExplorer as an external module that is used out of the box in GeoNode, but it is possible for you to create your own Suite SDK app and integrate it with GeoNode.

The front end of GeoNode is composed of a set of core templates, specific templates for each module, cascading style sheets to style those pages and a set of javascript modules that provide the interactive functionality in the site.

1. ssh into your virtual machine or other instance
2. sudo to modify the sshd_config settings to verify disabling of dns resolution (UseDNS=no)
3. install a command line helper

$ sudo apt-get install bash-completion

1. exercise command completion

$ apt-get install <TAB><TAB>

1. activate/deactivate the virtualenv on your instance

$ source /var/lib/geonode/bin/activate
$ deactivate

1. set the DJANGO_SETTINGS_MODULE env variable

$ export DJANGO_SETTINGS_MODULE=geonode.settings

1. install the httpie utility via pip

$ pip install httpie
$ http http://localhost/geoserver/rest
$ http -a admin http://localhost/geoserver/rest
<type in password - geoserver>

1. launch ipython and experiment

> x = "some text"
> x.<TAB><TAB>
> x.split.__doc__
> ?

1. execute a script with ipython and open the REPL

$ echo "twos = [ x*2 for x in range(5)]" > test.py
$ ipython -i test.py
> twos

GeoNode is an out-of-the-box, full-featured Spatial Data Infrastructure solution, but many GeoNode implementations require either customization of the default site or the use of additional modules, whether they be third-party Django Pluggables or modules developed by a GeoNode implementer.

There are quite a few existing Downstream GeoNode projects some of which follow the methodology described in this module. You should familiarize yourself with these projects and how and why they extend GeoNode. You should also carefully think about what customization and additional modules you need for your own GeoNode-based project and research the options that are available to you. The Django Packages site is a great place to start looking for existing modules that may meet your needs.

• Harvard Worldmap
• MapStory
• Risiko/SAFE

GeoNode follows the Django template projects paradigm introduced in Django 1.4. At a minimum, a Django project consists of a settings.py file and a urls.py file; Django apps are used to add specific pieces of functionality. The GeoNode development team has created a template project which contains these required files with all the GeoNode configuration you need to get up and running with your own GeoNode project. If you would like learn more about Django projects and apps, you should consult the Django Documentation

If you are working remotely, you should first connect to the machine that has your GeoNode installation. You will need to perform the following steps in a directory where you intend to keep your newly created project.

1. Activate GeoNode’s Virtual Environment

   $ workon geonode
   

2. Create your GeoNode project from the template

   $ django-admin.py startproject my_geonode --template=https://github.com/GeoNode/geonode-project/archive/master.zip -epy,rst
   $ cd my_geonode
   

3. Update your local_settings.py. You will need to check the local_settings.py that is included with the template project and be sure that it reflects your own local environment. You should pay particular attention to the Database settings especially if you intend to reuse the database that was set up with your base GeoNode installation.

4. Run the test server

   $ python manage.py runserver
   

5. Visit your new GeoNode site at http://localhost:8000.

It is recommended that you immediately put your new project under source code revision control. The GeoNode development team uses Git and GitHub and recommends that you do the same. If you do not already have a GitHub account, you can easily set one up. A full review of Git and distributed source code revision control systems is beyond the scope of this tutorial, but you may find the Git Book useful if you are not already familiar with these concepts.

1. Create a new repository in GitHub. You should use the GitHub user interface to create a new repository for your new project.

   

   Creating a new GitHub Repository From GitHub’s Homepage

   

   Specifying new GitHub Repository Parameters

   

   Your new Empty GitHub Repository

2. Initialize your own repository:

   $ git init
   

3. Add the remote repository reference to your local git configuration:

   $ git remote add
   

4. Add your project files to the repository:

   $ git add .
   

5. Commit your changes:

   $ git commit -am "Initial commit"
   

6. Push to the remote repository:

   $ git push origin master
   

Your GeoNode project will now be structured as depicted below:

|-- README.rst
|-- manage.py
|-- my_geonode
|   |-- __init__.py
|   |-- settings.py
|   |-- static
|   |   |-- README
|   |   |-- css
|   |   |   |-- site_base.css
|   |   |-- img
|   |   |   |-- README
|   |   |-- js
|   |       |-- README
|   |-- templates
|   |   |-- site_base.html
|   |   |-- site_index.html
|   |-- urls.py
|   |-- wsgi.py
|-- setup.py

You can also view your project on GitHub.

Viewing your project on GitHub

Each of the key files in your project are described below.

try:
    from local_settings import *
except:
    pass

If you want to stay in sync with the mainline GeoNode you have to execute the following commands. Your own project should not be adversely affected by these changes, but you will receive bug fixes and other improvements by staying in sync.

$ git fetch upstream master
$ git merge

GeoNode intentionally does not include a large number of graphics files in its interface. This keeps page loading time to a minimum and makes for a more responsive interface. That said, you are free to customize your GeoNode’s interface by simply changing the default logo, or by adding your own images and graphics to deliver a GeoNode experience the way you envision int.

Your GeoNode project has a directory already set up for storing your own images at <my_geonode>/static/img. You should place any image files that you intend to use for your project in this directory.

Let’s walk through an example of the steps necessary to change the default logo.

1. Change into the img directory:

   $ cd <my_geonode>/static/img
   

2. If you haven’t already, obtain your logo image. The URL below is just an example, so you will need to change this URL to match the location of your file or copy it to this location:

   $ wget http://www2.sta.uwi.edu/~anikov/UWI-logo.JPG
   $ cd ../../..
   

3. Override the CSS that displays the logo by editing <my_geonode>/static/css/site_base.css with your favorite editor and adding the following lines, making sure to update the width, height, and URL to match the specifications of your image.

   .nav-logo {
       width: 373px;
       height: 79px;
       background: url(../img/UWI-logo.JPG) no-repeat;
   }
   

4. Restart your GeoNode project and look at the page in your browser:

   $ python manage.py runserver
   

Visit your site at http://localhost:8000/ or the remote URL for your site.

Custom logo

You can see that the header has been expanded to fit your graphic. In the following sections you will learn how to customize this header to make it look and function the way you want.

In the last section you already learned how to override GeoNode’s default CSS rules to include your own logo. You are able to customize any aspect of GeoNode’s appearance this way. In the last screenshot, you saw that the main area in the homepage is covered up by the expanded header.

First, we’ll walk through the steps necessary to displace it downward so it is no longer hidden, then change the background color of the header to match the color in our logo graphic.

1. Reopen <my_geonode>/static/css/site_base.css in your editor and add the following rule after the one added in the previous step:

   .content-wrap {
       margin: 75px 75px;
   }
   

2. Add a rule to change the background color of the header to match the logo graphic we used:

   .navbar .navbar-inner {
       background: #0e60c3;
   }
   

3. Your project CSS file should now look like this:

   .nav-logo {
       width: 373px;
       height: 79px;
       background: url(../img/UWI-logo.JPG) no-repeat;
   }
   
   .content-wrap {
       margin: 75px 75px;
   }
   
   .navbar .navbar-inner {
       background: #0e60c3;
   }
   

4. Restart the development server and reload the page:

   $ python manage.py runserver
   

   

   CSS overrides

Note

You can continue adding rules to this file to override the styles that are in the GeoNode base CSS file which is built from base.less. You may find it helpful to use your browser’s development tools to inspect elements of your site that you want to override to determine which rules are already applied. See the screenshot below. Another section of this workshop covers this topic in much more detail.

Screenshot of using Chrome’s debugger to inspect the CSS overrides

Now that we have changed the default logo and adjusted our main content area to fit the expanded header, the next step is to update the content of the homepage itself. Your GeoNode project includes two basic templates that you will use to change the content of your pages.

The file site_base.html (in <my_geonode>/templates/) is the basic template that all other templates inherit from and you will use it to update things like the header, navbar, site-wide announcement, footer, and also to include your own JavaScript or other static content included in every page in your site. It’s worth taking a look at GeoNode’s base file on GitHub. You have several blocks available to you to for overriding, but since we will be revisiting this file in future sections of this workshop, let’s just look at it for now and leave it unmodified.

Open <my_geonode>/templates/site_base.html in your editor:

{% extends "base.html" %}
{% block extra_head %}
    <link href="{{ STATIC_URL }}css/site_base.css" rel="stylesheet"/>
{% endblock %}

You will see that it extends from base.html, which is the GeoNode template referenced above and it currently only overrides the extra_head block to include our project’s site_base.css which we modified in the previous section. You can see on line 14 of the GeoNode base.html template that this block is included in an empty state and is set up specifically for you to include extra CSS files as your project is already set up to do.

Now that we have looked at site_base.html, let’s actually override a different template.

The file site_index.html is the template used to define your GeoNode project’s homepage. It extends GeoNode’s default index.html template and gives you the option to override specific areas of the homepage like the hero area, but also allows you leave area like the “Latest Layers” and “Maps” and the “Contribute” section as they are. You are of course free to override these sections if you choose and this section shows you the steps necessary to do that below.

1. Open <my_geonode>/templates/site_index.html in your editor.

2. Edit the <h1> element on line 13 to say something other than “Welcome”:

   <h1>{% trans "UWI GeoNode" %}</h1>
   

3. Edit the introductory paragraph to include something specific about your GeoNode project:

   <p>
       {% blocktrans %}
       UWI's GeoNode is setup for students and faculty to collaboratively
       create and share maps for their class projects. It is maintained by the
       UWI Geographical Society.
       {% endblocktrans %}
   </p>
   

4. Change the Getting Started link to point to another website:

   <span>
       For more information about the UWI Geographical society,
       <a href="http://uwigsmona.weebly.com/">visit our website</a>
   </span>
   

5. Add a graphic to the hero area above the paragraph replaced in step 3:

   <img src = 'http://uwigsmona.weebly.com/uploads/1/3/2/4/13241997/1345164334.png'>
   

6. Your edited site_index.html file should now look like this:

   {% extends 'index.html' %}
   {% load i18n %}
   {% load maps_tags %}
   {% load layers_tags %}
   {% load pagination_tags %}
   {% load staticfiles %}
   {% load url from future %}
   {% comment %}
   This is where you can override the hero area block. You can simply modify the content below or replace it wholesale to meet your own needs.
   {% endcomment %}
   {% block hero %}
       <div class="hero-unit">
           <h1>{% trans "UWI GeoNode" %}</h1>
           <div class="hero-unit-content">
           <div class="intro">
               <img src = 'http://uwigsmona.weebly.com/uploads/1/3/2/4/13241997/1345164334.png'>
           <p>
               {% blocktrans %}
               UWI's GeoNode is setup for students and faculty to collaboratively
               create and share maps for their class projects. It is maintained by the
               UWI Geographical Society.
               {% endblocktrans %}
           </p>
           <span>
               For more information about the UWI Geographical society,
               <a href="http://uwigsmona.weebly.com/">visit our website</a>
           </span>
       </div>
       <div class="btns">
           <a class="btn btn-large" href="{% url "layer_browse" %}">
           {% trans "Explore Layers" %}
           </a>
           <a class="btn btn-large" href="{% url "maps_browse" %}">
           {% trans "Explore Maps" %}
           </a>
       </div>
   </div>
   {% endblock %}
   

7. Restart your GeoNode project and view the changes in your browser at http://localhost:8000/ or the remote URL for your site:

   $ python manage.py runserver
   

   

From here you can continue to customize your site_index.html template to suit your needs. This workshop will also cover how you can add new pages to your GeoNode project site.

You are able to change any specific piece of your GeoNode project’s style by adding CSS rules to site_base.css, but since GeoNode is based on Bootstrap, there are many pre-defined themes that you can simply drop into your project to get a whole new look. This is very similar to WordPress themes and is a powerful and easy way to change the look of your site without much effort.

The Django app ecosystem provides a large number of apps that can be added to your project. Many are mature and used in many existing projects and sites, while others are under active early-stage development. Websites such as Django Packages provide an interface for discovering and comparing all the apps that can plugged in to your Django project. You will find that some can be used with very little effort on your part, and some will take more effort to integrate.

Let’s walk through the an example of the steps necessary to create a very basic Django polling app to and add it to your GeoNode project. This section is an abridged version of the Django tutorial itself and it is strongly recommended that you go through this external tutorial along with this section as it provides much more background material and a signficantly higher level of detail. You should become familiar with all of the information in the Django tutorial as it is critical to your success as a GeoNode project developer.

Throughout this section, we will walk through the creation of a basic poll application. It will consist of two parts:

• A public site that lets people view polls and vote in them.
• An admin site that lets you add, change, and delete polls.

1. Create app structure

   Since we have already created our GeoNode project from a template project, we will start by creating our app structure and then adding models:

   $ python manage.py startapp polls
   

   That’ll create a directory polls, which is laid out like this:

   polls/
       __init__.py
       models.py
       tests.py
       views.py
   

   This directory structure will house the poll application.

2. Add models

   The next step in writing a database web app in Django is to define your models—essentially, your database layout with additional metadata.

   In our simple poll app, we’ll create two models: polls and choices. A poll has a question and a publication date. A choice has two fields: the text of the choice and a vote tally. Each choice is associated with a poll.

   These concepts are represented by simple Python classes.

   Edit the polls/models.py file so it looks like this:

   from django.db import models
   
   class Poll(models.Model):
       question = models.CharField(max_length=200)
       pub_date = models.DateTimeField('date published')
       def __unicode__(self):
           return self.question
   
   class Choice(models.Model):
       poll = models.ForeignKey(Poll)
       choice = models.CharField(max_length=200)
       votes = models.IntegerField()
       def __unicode__(self):
           return self.choice
   

   That small bit of model code gives Django a lot of information. With it, Django is able to:

   • Create a database schema (CREATE TABLE statements) for this app.
   • Create a Python database-access API for accessing Poll and Choice objects.

   But first we need to tell our project that the polls app is installed.

   Edit the <my_geonode>/settings.py file, and update the INSTALLED_APPS setting to include the string “polls”. So it will look like this:

   INSTALLED_APPS = (
   
       # Apps bundled with Django
       'django.contrib.auth',
       'django.contrib.contenttypes',
       'django.contrib.sessions',
       'django.contrib.sites',
       'django.contrib.admin',
       'django.contrib.sitemaps',
       'django.contrib.staticfiles',
       'django.contrib.messages',
       'django.contrib.humanize',
   
       #Third party apps
   
       # <snip>
   
       # GeoNode internal apps
       'geonode.maps',
       'geonode.upload',
       'geonode.layers',
       'geonode.people',
       'geonode.proxy',
       'geonode.security',
       'geonode.search',
       'geonode.catalogue',
       'geonode.documents',
   
       # My GeoNode apps
       'polls',
   )
   

   Now Django knows to include the polls app. Let’s run another command:

   $ python manage.py syncdb
   

   The syncdb command runs the SQL from sqlall on your database for all apps in INSTALLED_APPS that don’t already exist in your database. This creates all the tables, initial data, and indexes for any apps you’ve added to your project since the last time you ran syncdb. syncdb can be called as often as you like, and it will only ever create the tables that don’t exist.

   GeoNode uses south for migrations ...

3. Add Django Admin Configuration

   Next, let’s add the Django admin configuration for our polls app so that we can use the Django Admin to manage the records in our database. Create and edit a new file called polls/admin.py and make it look like the this:

   from polls.models import Poll
   from django.contrib import admin
   
   admin.site.register(Poll)
   

   Run the development server and explore the polls app in the Django Admin by pointing your browser to http://localhost:8000/admin/ and logging in with the credentials you specified when you first ran syncdb.

   

   You can see all of the other apps that are installed as part of your GeoNode project, but we are specifically interested in the Polls app for now.

   

   Next we will add a new poll via automatically generated admin form.

   

   You can enter any sort of question you want for initial testing and select today and now for the publication date.

   

4. Configure Choice model

   The next step is to configure the Choice model in the admin, but we will configure the choices to be editable in-line with the Poll objects they are attached to. Edit the same polls/admin.py so it now looks like the following:

   from polls.models import Poll, Choice
   from django.contrib import admin
   
   class ChoiceInline(admin.StackedInline):
       model = Choice
       extra = 3
   
   class PollAdmin(admin.ModelAdmin):
       fieldsets = [
           (None,               {'fields': ['question']}),
           ('Date information', {'fields': ['pub_date'], 'classes': ['collapse']}),
       ]
       inlines = [ChoiceInline]
   
   admin.site.register(Poll, PollAdmin)
   

   This tells Django that Choice objects are edited on the Poll admin page, and by default, provide enough fields for 3 choices.

5. Add/edit poll

   You can now return to the Poll admin and either add a new poll or edit the one you already created and see that you can now specify the poll choices inline with the poll itself.

   

6. Create views

   From here, we want to create views to display the polls inside our GeoNode project. A view is a “type” of Web page in your Django application that generally serves a specific function and has a specific template. In our poll application, there will be the following four views:

   • Poll “index” page—displays the latest few polls.
   • Poll “detail” page—displays a poll question, with no results but with a form to vote.
   • Poll “results” page—displays results for a particular poll.
   • Vote action—handles voting for a particular choice in a particular poll.

   The first step of writing views is to design your URL structure. You do this by creating a Python module called a URLconf. URLconfs are how Django associates a given URL with given Python code.

   Let’s start by adding our URL configuration directly to the urls.py that already exists in your project at <my_geonode>/urls.py. Edit this file and add the following lines after the rest of the existing imports around line 80:

   url(r'^polls/$', 'polls.views.index'),
   url(r'^polls/(?P<poll_id>\d+)/$', 'polls.views.detail'),
   url(r'^polls/(?P<poll_id>\d+)/results/$', 'polls.views.results'),
   url(r'^polls/(?P<poll_id>\d+)/vote/$', 'polls.views.vote'),
   

   Note

   Eventually we will want to move this set of URL configurations inside the URLs app itself, but for the sake of brevity in this workshop, we will put them in the main urls.py for now. You can consult the Django tutorial for more information on this topic.

   Next write the views to drive the URL patterns we configured above. Edit polls/views.py to that it looks like the following:

   from django.template import RequestContext, loader
   from polls.models import Poll
   from django.http import HttpResponse
   from django.http import Http404
   from django.shortcuts import render_to_response
   
   def index(request):
       latest_poll_list = Poll.objects.all().order_by('-pub_date')[:5]
       return render_to_response('polls/index.html',
           RequestContext(request, {'latest_poll_list': latest_poll_list}))
   
   def detail(request, poll_id):
       try:
           p = Poll.objects.get(pk=poll_id)
       except Poll.DoesNotExist:
           raise Http404
       return render_to_response('polls/detail.html', RequestContext(request, {'poll': p}))
   
   def results(request, poll_id):
       return HttpResponse("You're looking at the results of poll %s." % poll_id)
   
   def vote(request, poll_id):
       return HttpResponse("You're voting on poll %s." % poll_id)
   

   Note

   We have only stubbed in the views for the results and vote pages. They are not very useful as-is. We will revisit these later.

   Now we have views in place, but we are referencing templates that do not yet exist. Let’s add them by first creating a template directory in your polls app at polls/templates/polls and creating polls/templates/polls/index.html to look like the following:

   {% if latest_poll_list %}
       <ul>
       {% for poll in latest_poll_list %}
           <li><a href="/polls/{{ poll.id }}/">{{ poll.question }}</a></li>
       {% endfor %}
       </ul>
   {% else %}
       <p>No polls are available.</p>
   {% endif %}
   

   Next we need to create the template for the poll detail page. Create a new file at polls/templates/polls/detail.html to look like the following:

   <h1>{{ poll.question }}</h1>
   <ul>
   {% for choice in poll.choice_set.all %}
       <li>{{ choice.choice }}</li>
   {% endfor %}
   </ul>
   

   You can now visit http://localhost:8000/polls/ in your browser and you should see the the poll question you created in the admin presented like this.

   

7. Update templates

   We actually want our polls app to display as part of our GeoNode project with the same theme, so let’s update the two templates we created above to make them extend from the site_base.html template we looked at in the last section. You will need to add the following two lines to the top of each file:

   {% extends 'site_base.html' %}
   {% block body %}
   

   And close the block at the bottom of each file with:

   {% endblock %}
   

   This tells Django to extend from the site_base.html template so your polls app has the same style as the rest of your GeoNode, and it specifies that the content in these templates should be rendered to the body block defined in GeoNode’s base.html template that your site_base.html extends from.

   You can now visit the index page of your polls app and see that it is now wrapped in the same style as the rest of your GeoNode site.

   

   If you click on a question from the list you will be taken to the poll detail page.

   

   It looks like it is empty, but in fact the text is there, but styled to be white by the Bootswatch theme we added in the last section. If you highlight the area where the text is, you will see that it is there.

   

Now that you have walked through the basic steps to create a very minimal (though not very useful) Django app and integrated it with your GeoNode project, you should pick up the Django tutorial at part 4 and follow it to add the form for actually accepting responses to your poll questions.

We strongly recommend that you spend as much time as you need with the Django tutorial itself until you feel comfortable with all of the concepts. They are the essential building blocks you will need to extend your GeoNode project by adding your own apps.

Now that we have created our own app and added it to our GeoNode project, the next thing we will work through is adding a 3rd party blog app. There are a number of blog apps that you can use, but for purposes of this workshop, we will use a relatively simple, yet extensible app called Zinnia. You can find out more information about Zinnia on its website or on its GitHub project page or by following its documentation. This section will walk you through the minimal set of steps necessary to add Zinnia to your GeoNode project.

1. Install Zinnia

   The first thing to do is to install Zinnia into the virtualenv that you are working in. Make sure your virtualenv is activated and execute the following command:

   $ pip install django-blog-zinnia
   

   This will install Zinnia and all of the libraries that it depends on.

2. Add Zinnia to INSTALLED_APPS

   Next add Zinnia to the INSTALLED_APPS section of your GeoNode projects settings.py file by editing <my_geonode>/settings.py and adding ‘django.contrib.comments’ to the section labeled “Apps Bundled with Django” so that it looks like the following:

   # Apps bundled with Django
   'django.contrib.auth',
   'django.contrib.contenttypes',
   'django.contrib.sessions',
   'django.contrib.sites',
   'django.contrib.admin',
   'django.contrib.sitemaps',
   'django.contrib.staticfiles',
   'django.contrib.messages',
   'django.contrib.humanize',
   'django.contrib.comments',
   

   And then add the tagging, mptt and zinnia apps to the end of the INSTALLED_APPS where we previously added a section labeled “My GeoNode apps”. It should like like the following:

   # My GeoNode apps
   'polls',
   'tagging',
   'mptt',
   'zinnia',
   

3. Synchronize models

   Next you will need to run syncdb again to synchronize the models for the apps we have just added to our project’s database. This time we want to pass the --all flag to syncdb so it ignores the schema migrations. Schema migrations are discussed further in GeoNode’s documentation, but it is safe to ignore them here.

   $ python manage.py syncdb --all
   

   You can now restart the development server and visit the Admin interface and scroll to the very bottom of the list to find a section for Zinnia that allows you to manage database records for Categories and Blog Entries.

   

4. Configure project

   Next we need to configure our project to add Zinnia’s URL configurations. Add the following two URL configuration entries to the end of <my_geonode>/urls.py:

   url(r'^blog/', include('zinnia.urls')),
   url(r'^djcomments/', include('django.contrib.comments.urls')),
   

   If you visit the main blog page in your browser at http://localhost:8000/blog/ you will find that the blog displays with Zinnia’s default theme as shown below.

   Note

   If you are not able to visit the main blog page, you will have to set USE_TZ = True in settings.py. Restart the server and try again!

   

   This page includes some guidance for us on how to change the default theme.

5. Change default theme

   The first thing we need to do is to copy Zinnia’s base.html template into our own project so we can modify it. When you installed Zinnia, templates were installed to /var/lib/geonode/lib/python2.7/site-packages/zinnia/templates/zinnia/. You can copy the base template by executing the following commands:

   $ mkdir <my_geonode>/templates/zinnia
   $ cp /var/lib/geonode/lib/python2.7/site-packages/zinnia/templates/zinnia/base.html <my_geonode>/templates/zinnia/
   

   Then you need to edit this file and change the topmost line to read as below such that this template extends from our projects site_base.html rather than the zinnia skeleton.html:

   {% extends "site_base.html" %}
   

   Since Zinnia uses a different block naming scheme than GeoNode does, you need to add the following line to the bottom of your site_base.html file so that the content block gets rendered properly:

   {% block body %}{% block content %}{% endblock %}{% endblock %}
   

   

   You can see that there are currently no blog entries, so let’s add one. Scroll to the bottom of the interface and click the Post an Entry link to go to the form in the Admin interface that lets you create a blog post. Go ahead and fill out the form with some information for testing purposes. Make sure that you change the Status dropdown to “published” so the post shows up right away.

   

   You can explore all of the options available to you as you create your post, and when you are done, click the Save button. You will be taken to the page that shows the list of all your blog posts.

   

   You can then visit your blog post/entry at http://localhost:8000/blog/.

   

   And if you click on the blog post title, you will be taken to the page for the complete blog post. You and your users can leave comments on this post and various other blog features from this page.

   

6. Integrate app into your site

   The last thing we need to do to fully integrate this blog app (and our polls app) into our site is to add it to the options on the navbar. To do so, we need to add the following block override to our Projects site_base.html:

   {% block extra-nav %}
   <li id="nav_polls">
       <a href="/polls/">Polls</a>
   </li>
   <li id="nav_blog">
       <a href="{% url 'zinnia_entry_archive_index' %}">Blog</a>
   </li>
   {% endblock %}
   

   

At this point, you could explore options for tighter integration between your GeoNode project and Zinnia. Integrating blog posts from Zinnia into your overall search could be useful, as well as including the blog posts a user has written on their Profile Page. You could also explore the additional plugins that go with Zinnia.

Now that you have both written your own app and plugged in a 3rd party one, you can explore sites like Django Packages to look for other modules that you could plug into your GeoNode project to meet your needs and requirements. For many types of apps, there are several options and Django Packages is a nice way to compare them. You may find that some apps require significantly more work to integrate into your app than others, but reaching out to the app’s author and/or developers should help you get over any difficulties you may encounter.

Since GeoNode is built on GeoServer which is heavily based on OGC services, the main path for integration with external services is via OGC Standards. A large number of systems, applications and services support adding WMS layers to them, but only a few key ones are covered below. WFS and WCS are also supported in a wide variety of clients and platforms and give you access to the actual data for use in GeoProcessing or to manipulate it to meet your requirements. GeoServer also bundles GeoWebCache which produces map tiles that can be added as layers in many popular web mapping tools including Google Maps, Leaflet, OpenLayers and others. You should review the reference material included in the first chapter to learn more about OGC Services and when evaluating external systems make sure that they are also OGC Compliant in order to integrate as seamlessly as possible.

See Using GeoNode with other applications for examples with desktop applications. More examples will be shared for integration with existing databases, mapping server and sharing platform such as CKAN.

The net tab allows viewing all of the network traffic from the browser. The subtabs (like the selected “Images” tab) allow filtering by the type of traffic.

Firebug Net Tab

In this screen-shot, the mouse hover displays the image content and the full URL requested. One can right-click to copy-paste the URL or view in a separate tab. This is useful for obtaining test URLs. The grayed out entries show that the resource was cached via conditional-get (the 304 not modified). Other very useful advanced information includes the size of the response and the loading indicator graphics on the right. At the bottom, note the total size and timing information.

The DOM tab displays all of the top-level window objects. By drilling down, this can be a useful way to find out what’s going on in a page.

Firebug DOM Tab

In this example, the mouse is hovering over the app object. Note the high level view of objects and their fields. The console tab allows interacting with the objects.

The script tab allows viewing scripts and debugging.

The screen-shot displays a breakpoint set at line 3, the current code is stopped at line 8 and the mouse hover is displaying the value of the variable ‘class_list’. On the right, the ‘Watch’ tab displays the various variables and scopes and offers a drill down view similar to the DOM view. The stack tab displays the execution stack context outside the current frame.

The HTML tag allows viewing and drilling down into the DOM. This is an incredibly useful feature when doing CSS or HTML work.

The screen-shot displays a search result ‘article’ element highlighted with padding and margin in yellow and purple. The DOM structure is displayed on the left and the right panel displays the specific style rules while the computed tab displays the effective style rules. The layout tab displays rulers and property values while the DOM tab displays a debug/DOM-like view of the actual object’s properties.

References:

• http://docs.python.org/2/library/logging.html
• https://docs.djangoproject.com/en/1.4/topics/logging/

Logging is controlled by the contents of the logging data structure defined in the settings.py. The default settings distributed with GeoNode are configured to only log errors. During development, it’s a good idea to override the logging data structure with something a bit more verbose.

Reference:

• http://docs.python.org/2/library/pdb.html

For the adventurous, pdb allows for an interactive debugging session. This is only possible when running in a shell via manage.py runserver or paver runserver.

To set a breakpoint, insert the following code before the code to debug.

..code-block:: python

import pdb; pdb.set_strace()

When execution reaches this statement, the debugger will activate. The commands are noted in the link above. In addition to those debugger specific commands, general python statements are supported. For example, typing the name of a variable in scope will yield the value via string coersion. Typing “n” will execute the next line, “c” wil continue the execution of the program, “q” will quit.

GeoServer logging, while sometimes containing too much information, is the best way to start diagnosing an issue in GeoNode once the other. To create a proper error report for use in requesting support, providing any contextual logging information is critical.

When using a standard geoserver installation, the GeoServer logs are located at /usr/share/geoserver/data/logs/geoserver.log. The properties files that control the varying rules are also located here.

JVM diagnostics and advanced troubleshooting techniques are covered in the GeoServer documents linked to above. When providing information for a bug report, these can be helpful but in-depth Java knowledge is required to fully comprehend the output from some of these tools.

The gsconfig library provides a rich interface to interacting with GeoServer’s REST API. This allows high-level functions as well as viewing raw REST responses.

cat = Layer.objects.gs_catalog
cat.get_layers() # list of gsconfig layer objects
# OR, for a specific layer
lyr = Layer.objects.get(id=1)
lyr.resource # specfic gsconfig layer object
lyr.resource.fetch() # get the XML from REST
lyr.resource.dom # reference to the parsed XML
from xml.etree.ElementTree import tostring
tostring(lyr.resource.dom)

At its core, GeoNode provides a standards-based platform to enable integrated, programmatic access to your data via OGC Web Services, which are essential building blocks required to deploy an OGC-compliant spatial data infrastructure (SDI). These Web Services enable discovery, visualization and access your data, all without necessarily having to interact directly with your GeoNode website, look and feel/UI, etc.

OGC Web Services:

• operate over HTTP (GET, POST)
• provide a formalized, accepted API
• provide formalized, accepted formats

The OGC Web Services provided by GeoNode have a mature implementation base and provide an multi-application approach to integration. This means, as a developer, there are already numerous off-the-shelf GIS packages, tools and webapps (proprietary, free, open source) that natively support OGC Web Services.

There are numerous ways to leverage OGC Web Services from GeoNode:

• desktop GIS
• web-based application
• client libraries / toolkits
• custom development

Your GeoNode lists OGC Web Services and their URLs at http://localhost:8000/developer. You can use these APIs directly to interact with your GeoNode.

The following sections briefly describe the OGC Web Services provided by GeoNode.

WMS provides an API to retrieve map images (png, JPEG, etc.) of geospatial data. WMS is suitable for visualization and when access to raw data is not a requirement.

WFS provides provides an API to retrieve raw geospatial vector data directly. WFS is suitable for direct query and access to geographic features.

WCS provides provides an API to retrieve raw geospatial raster data directly. WCS is suitable for direct access to satellite imagery, DEMs, etc.

CSW provides an interface to publish and search metadata (data about data). CSW is suitable for cataloguing geospatial data and making it discoverable to enable visualization and access.

WMTS provides an API to retrive pre-rendered map tiles of geospatial data.

WMC provides a format to save and load map views and application state via XML. This allows, for example, a user to save their web mapping application in WMC and share it with others, viewing the same content.

Here’s a list of Pavement tasks maintained by the GeoNode development team.