Skip to content

Instantly share code, notes, and snippets.

@t-book

t-book/Community Ressources.md

Last active September 28, 2019 16:21
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save t-book/2048ec0a523c8d017173d5f653bb13c9 to your computer and use it in GitHub Desktop.
Save t-book/2048ec0a523c8d017173d5f653bb13c9 to your computer and use it in GitHub Desktop.
Download ZIP
Geonode Wiki Old
Raw
Community Ressources.md
Raw
Contributing to GeoNode.md

Contributing to GeoNode

THIS IS A DRAFT PROPOSAL. IT HAS NOT YET BEEN VOTED INTO EFFECT BY THE PSC.

If you are interested in helping us to make GeoNode, there are many ways to do so.

Participate in the Discussion

GeoNode has a mailing list (geonode@librelist.org) where users can ask and answer questions about the software. There is also an IRC chat room on Freenode where users and developers can discuss GeoNode in real time. Sometimes users also post interesting tips for managing sites running GeoNode. If you want to help out with GeoNode, one easy way is to sign up for the mailing list and help answer questions.

Report Problems

While we do our best to keep GeoNode fast and bug-free, problems can and do arise. Informative bug reports are a key part of the bug fixing process, so if you do run into a problem with GeoNode, please don't hesitate to report it on our bug tracker, available online at [[http://dev.geonode.org/trac]]. Useful information for bug reports includes:

  • What were you doing when the bug occurred? Does the problem occur every time you do that, or only occasionally?
  • What were you expecting to happen? What happened instead?
  • What version of the software are you using? Please also note any changes from the default configuration.
  • If there is a data file involved in the bug (such as a Shapefile that doesn't render properly), please consider including it in the bug report. We do respect that not all data files are freely distributable.

Write Documentation

GeoNode's documentation can always use improvement - there are always more questions to be answered. For managing contributions to the manual, GeoNode uses a process similar to that used for managing the code itself. The documentation is generated from source files in the docs/ directory within the GeoNode source repository. See [[http://sphinx.pocoo.org/]] for more information on the documentation system we use.

Provide Translations

If GeoNode doesn't provide a user interface in your native language, consider contributing a new translation file. See [[https://docs.djangoproject.com/en/1.2/topics/i18n/]] for an overview of the internationalization system used in GeoNode.

Write Code

Of course since GeoNode is an open source project we do encourage contributions of source code as well. If you are interested in making small changes, you can find an open ticket on [[https://github.com/GeoNode/geonode/issues]], hack away, and get started on the [[Patch Review Process]].

Raw
Fall 2015 Code Sprint.md

Fall 2015 Code Sprint

Lets start organizing for a sprint in the Fall (October/November)

Potential Locations & (Potential) Participants

  • New Orleans (Boundless)
  • San Diego (Jeff)
  • Toronto (Tom)
  • Turin (Ithaca)
    • Paolo Pasquali, ITHACA
    • Simone Balbo, ITHACA
    • Alessio Fabiani, GeoSolutions
    • Emanuele Tajariol, GeoSolutions
    • Simone Giannecchini, GeoSolutions
    • Francesco Bartoli, Geobeyond
    • Simone Dalmasso, JRC
    • Ben Wyss, GEM
Raw
For-developers.md

Which branches should you use?

2.10.x

Current stable https://github.com/GeoNode/geonode/tree/2.10.x

  • Based on Django 1.11.23 and Celery 4.2.1
  • Compatible with Ubuntu 16.0.4, Ubuntu 18.0.4 and CentOS 7 (the only ones officially tested currently)

2.8.0

https://github.com/GeoNode/geonode/tree/2.8.0

  • Based on Django 1.8.19 and Celery 4.1.0
  • Compatible with Ubuntu 16.0.4 and CentOS 7 (the only ones officially tested currently)

NOTES: This branch is frozen and contains everything until latest stable GeoNode release 2.8.0. This branch won't be changed until the next release for the 2.8.0 train (2.8.1). At that point the source code of GeoNode 2.8.0 will be found only on 2.8 tag

https://github.com/GeoNode/geonode/releases/tag/2.8

2.7.x

https://github.com/GeoNode/geonode/tree/2.7.x

  • Based on Django 1.8.19 and Celery 4.1.0
  • Compatible with Ubuntu 16.0.4 and CentOS 7 (the only ones officially tested currently)

NOTES: This branch is the GeoNode 2.8.1 release candidate. Currently marked as 2.7.7 version, before the official release process you will be able to find 2.7.7+ deb packages on unstable ppa.

2.7.x train will remain based on Django 1.8 forever

2.10.x/master

https://github.com/GeoNode/geonode

  • Based on Django 1.11.16 and Celery 4.1.0
  • Still under testing. This is meant to be working with latest Ubuntu/CentOS releases
Raw
GeoNode Process.md

This document is deprecated. For the current GeoNode process, please see [[Community Bylaws]]

GeoNode Process

These pages contain advice, guidelines, and policies for participating in the GeoNode community.

If you are interested in contributing to GeoNode and don't know where to start, please check out [[Contributing to GeoNode]].

[[Patch Review Process]]

[[Improvement Proposals]]

[[Roadmap]]

Raw
GeoNode Projects.md

GeoNode Projects

This page is an attempt to collect information about downstream projects using GeoNode as a base. Please email the geonode@librelist.com list with your project description to be included.

UCDavis ICE

http://maps.ice.ucdavis.edu

Still in the early stages but will become the GIS repository for the university lab I work for (20+ people). That means it will be where we put all of our unique GIS data (at least 1 TB) for internal and external retrieval. To get and idea of what that could mean, you can see a list of projects we're working on right now on.

http://ice.ucdavis.edu

Our primary focus: Making it easy to create web services from any of our data. Including building groups that can be lumped together in separate WMS capabilites. GIS data distribution including a raw data link and WCS services. Metadata searching.

The only customization we've done so far is to change the upload to only be allowed from selected members of our site. Also of note several of our layers are fed from postgis outside of the geonode setup.

Harvard WorldMap

WorldMap is a GeoNode project being developed by the Center for Geographic Analysis (CGA) at Harvard University to lower barriers for those who wish to explore, visualize, edit, collaborate with, and publish geographically referenced information. WorldMap currently allows users to:

  • Create and edit point, line or polygon layers online and link map features to multimedia content

  • Search and display GeoRSS feeds from the Harvard Geospatial Library, YouTube, and Picasa.

  • Display layers from ArcGIS REST services.

  • View a list of saved edits made to a map and revert to previously saved versions of the map.

  • Search for layers by keywords and geographic extent directly from a map page.

  • Create custom URL's for maps

  • WorldMap: http://worldmap.harvard.edu

  • Github code: https://github.com/cga-harvard/cga-worldmap

Montagne Aperte2

Montagne Aperte2 is Luca Cassagrande's GeoNode application. Once it is done, It will be used by engineers to publish services, data and maps. Some minor changes from the default version:

  • Graphic
  • GPX format for download (Required for hikers)
  • Ushahidi integration (not yet defined)

http://www.montagneaperte.it

MetroBoston DataCommon

MetroBoston DataCommon is a customized GeoNode instance and serves as the main data dissemination platform for the Metropolitan Area Planning Council in the Metro Boston region.

In addition to GeoNode's core features,

  • it integrates an open source Flash-based data visualization software (Weave), similar to GeoNode's map composer, with GeoNode's permission architecture;
  • it adds a reporting application, called "Community Snapshots", to render pre-defined visual reports for a given set of regional units.
  • it includes CMS-like functionality for content-editors to create static pages on the plattform;

On the roadmap:

  • Comments and ratings - enable data and visualization conversations;
  • Data Stories - easy to use data walk-throughs to educate users how to read and work with data and indicators;
  • User groups - for organizations or topic related;
  • Social media integration - allow users to share their visualizations, data and maps on Facebook and Twitter.

http://metrobostondatacommon.org/
Github: https://github.com/mapc/mbdc

Raw
index.md

Welcome to the GeoNode Wiki.

[[Community Resources]]

[[GeoNode Links]]

[[Localization]]

[[GeoNode Development Process|GeoNode Process]]

[[Contributing to GeoNode]]

[[Patch-Review-Process]]

[[Review-criteria]]

[[Roadmap]]

[[Roadmap Items]]

[[GeoNode Improvement Proposals]]

[[Community Bylaws]]

[[For Developers]]

Raw
Localization.md

To enable a new language in GeoNode you have to do the following:

#. Install gettext::

sudo apt-get install gettext

#. Create a directory named locale in the root of your project::

mkdir locale

#. In the root of your project, run::

python manage.py makemessages -l fr

#. Navigate to the GeoNode dir and do::

cd src/GeoNodePy/geonode/maps; django-admin.py makemessages -l fr
cd src/GeoNodePy/geonode; django-admin.py makemessages -l fr

Optional steps:

#. Install django-rossetta::

http://code.google.com/p/django-rosetta/

#. Install django-modeltranslation

#. If you want to enable metadata in the other format too, make sure you have model translation installed and create a translations.py file like this::

from modeltranslation.translator import translator, TranslationOptions
from geonode.maps.models import Layer

class LayerTO(TranslationOptions):
    fields = (
             'title',
             'edition',
             'abstract',
             'purpose',
             'constraints_other',
             'distribution_description',
             'data_quality_statement',
             'supplemental_information',
             )

translator.register(FlatBlock, FlatBlockTO)
translator.register(Layer, LayerTO)
Raw
Review Criteria.md

Review Criteria

When a patch is rejected in the [[Patch Review Process]], it should be given a valid review.

This review should point out issues with the patch where it fails to meet one or more of the following criteria.

Major new features must be approved by the Improvement Process

GeoNode needs to be coherent software despite the diverse interests driving its development. Therefor, major new features need to first be approved according to the [[Improvement Process]].

If a patch fails by this criterion, then its developer is welcome to go through the improvement process to get approval. Otherwise, they can refactor their patch into a GeoNode extension.

Patches need sufficient documentation

We strive to keep GeoNode well-documented. If a patch contributes significant functionality to GeoNode that requires documentation to be understood, the patch review is an opportunity to hold the developer accountable for providing the adequate documentation.

New functionality needs to be internationalized

We strive to build GeoNode in a way that can be used in many different localities, by all languages. While there is no localization requirement for GeoNode besides providing default English text, new user-facing features need to be sufficiently internationalized so that others can write translations.

Design consistency

We strive to keep the default user interface for GeoNode appealing for new users and developer's approaching the project. If a patch significantly diminishes the user experience of the software, then a patch may be rejected with a review of how to improve it.

N.B.: Good design can sometimes be in the eye of the beholder. Developer's are encouraged to consult the community and/or a designer about the user interface design of their patches, and to be humble in their design criticisms of others.

Code should be covered by automated tests

To make development easier for others and guarantee software quality, we strive to have good automated test coverage in GeoNode. Patches may fail a review for having insufficient unit and/or integration tests.

Reviews saying that a patch has insufficient tests should offer actionable advice on how to improve those tests. This advice could be to improve code coverage. It may also be a list of possible cases that currently lack tests.

Patches should not have known bugs

A patch may be rejected for having a known bug, (e.g.) one discovered by reading the code or testing it at the time of review.

Patches should meet GeoNode's code style guidelines

New patches should meet GeoNode's code style guidelines. We follow different conventions per language:

  • In Java we use the GeoTools/GeoServer convention, essentially the conventions recommended by Oracle modified to make the recommended line length 100 columns instead of 80 to accommodate the long identifiers commonly used in GeoTools code. The GeoServer project provides an Eclipse configuration which helps to stick to this convention.
  • In Python we use the conventions enumerated in PEP8. Many editors have plugins available to assist with conformance to this convention.
  • In JavaScript we use the OpenLayers conventions, described on the OpenLayers wiki.
Raw
ROADMAP "Rock Solid" 1.1 Release.md

Work on the 1.1-beta release to shepherd it towards being "Rock Solid."

Emphasis on test coverage, documentation, stability under load, and error messages.

Scope

See this announcement for the target task list. Work will continue towards these tasks for as long as the budget allows.

Commitments

  • GFDRR: 115 hours
  • GEM: 75 hours
  • AIFDR: 50 hours
Raw
ROADMAP Add remote wms service to search.md

Allow administrators to add remote WMS layers and services to GeoNode.

This will give the service's layers Information Pages, make them visible through GeoNode's search interface, and provide them to the Map Composer.

This would demonstrate GeoNode's potential for aggregating data from other sources, including legacy WMS's and other GeoNodes. A prerequisite to GeoNode federation.

Interested

AIFDR, GEM, GFDRR, Harvard CGA, MapStory, SERVIR, UNEP, IW:LEARN

Phases

The first phase of this feature is to allow users to add single remote WMS layers.

The second phase is to allow administrators to add whole services.

Raw
ROADMAP Groups.md

Enable permission and ownership at the group level.

Interested

GFDRR, GEM

Discussion

See [[GNIP-8---Groups-and-Group-Permissions]]

Interested parties should review this design document for groups and provide feedback on whether it addresses their needs.

Raw
ROADMAP Improved layer search.md

Improved Layer Search

Interested

Raw
ROADMAP LDAP Authentication.md

Allow GeoNode to connect to an existing LDAP system for its user accounts.

Many organizations use LDAP infrastructure already to manage the online accounts of their users. This feature would let GeoNode users use their familiar user names and passwords rather than having to register new accounts.

Interested

AIFDR, GFDRR, SOPAC, GEM

Raw
ROADMAP Public api's and interfaces.md

Public API's and Interfaces

Currently, GeoNode has no public API except for the OGC services provided by GeoServer and GeoNetwork. However, developers extending GeoNode need to be able to work against a stable API.

This roadmap item is to improve, polish, and document API's for features around security, search, metadata editing, and the creation and upload of new layers and maps.

Interested

AIFDR, GEM, SOPAC, OpenGeo, SERVIR

Discussion

These API's should be REST interfaces or, when appropriate, adherent to an open standard. For example, OAuth and OpenID are possible standards to use for the security API.

Critical to these public API's will be providing the 'handshakes' necessary for the Esri ArcGIS plug-in, that should allow ArcGIS to work with GeoNode layers as it would any any other layer.

Raw
ROADMAP Time controls on map.md

GeoNode should allow users to scrub through datasets over time from embedded maps and within the map composer. To take advantage of these datasets that show changes in space over time.

Extend the map to include start, end, interval, and replay rate to allow users to define ranges of time for a map or filter features based on those values.

Interested

MapStory, Harvard CGA, SERVIR, AIFDR, GFDRR,

Raw
roadmap.md

======= Roadmap

Roadmap Process

The GeoNode Roadmap Process is designed to complement the more technical GeoNode [[Improvement Proposals]] and strives to make it easier for the various organizations invested in GeoNode to collaborate on features of common interest.

It is based on the roadmap items <https://spreadsheets.google.com/a/opengeo.org/spreadsheet/ccc?key=0AklXlBUnMqOrdDNackdvX3ZRS0Fha0xCeGhjSjZ1dEE>_ developed at the GeoNode Roadmapping Summit <http://geonode.org/2011/05/roadmapping-summit/>_ held in May 2011.

Overall, the process for adding items to the collective roadmap is as follows:

#. Organizational partner has an intent to add a feature to the roadmap #. Organizational partner communicates with the organizational partners list <https://groups.google.com/a/opengeo.org/group/geonode-org/>_ about the change to gauge interest and determine who else is committed to making it happen #. Organizational partner creates a feature specification on the wiki to further flesh out the idea #. Organizational partner finds a committer on the developer list <https://groups.google.com/a/opengeo.org/group/geonode-dev/>_ to shepherd the roadmap item through the GeoNode [[Improvements Process | Improvement Proposals]]

Each roadmap item will go through four stages:

#. Descriptive Stage (under discussion/"Active") #. Technical Stage #. Development Stage #. Released

After communicating on the organizational partners list <https://groups.google.com/a/opengeo.org/group/geonode-org/>_ the roadmap items enters the Descriptive Stage and must have a wiki page that lays out the description, user stories, and other interested parties. Optionally, the roadmap item will also include an idea of the difficulty and goals as well as any wireframes, technical diagrams, or prior art.

A roadmap item enters the Technical Stage once a committer has been found to shepherd the roadmap item through the [[GNIP | Improvement Proposals]] process, then the wiki page must contain a clear sense of the technical assumptions, requirements or dependencies, and suggested implementation. Some roadmap items may need to be divided into multiple independent GNIP proposals.

Once it passes through the [[GNIP | Improvement Proposals]] process, a roadmap item enters the Development Stage on its way to Release.

[[RoadMap-Items]]

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment