An Aperçu

Architecture

GeoNode Component Architecture

Architecture des composants de GeoNode

GeoNode est développé en utilisant le cadre web Django avec quelques dépendances nécessaires à la communication avec les serveurs géospatiales (par example GeoServer, pyCSW)

Sur le côté gauche vous pouvez voir la liste des Entities définies dans GeoNode et gérés par le framework Django ORM. Ces objets seront détaillées dans une section a venir.

Sur le côté droit de la liste des Services disponibles qu’on permet a GeoNode de communiquer avec le monde social

GeoNode est strictement relié au GeoServer (voir le bas de la figur ). Les données géospatial et les services de l’OGC sont mis en œuvre et gérés par GeoServer. GeoNode agit comme un courtier pour les couches géospatiales, ajoutant des informations et des outils qui rendent plus facile la gestion, le catalogage, la cartographie et la recherche des données geospatiales.

Grace au cadre ORM et aux bibliothèques Python auxiliaires, GeoNode est constamment aligné avec le catalogue de GeoServer. Un module de sécurité ad-hoc permet aux deux applications d’interagir et de partager strictement les règles de sécurité et les autorisations des comptes.

Dans les sections avancées de cette documentation, on va passer par GeoNode commandes que permet aux administrateurs de re-synchroniser les catalogues et les garder constamment aligné.

Django Architecture

GeoNode est basée sur Django qui est un cadre de développement web en Python de haut niveau qui encourage le développement rapide et la conception pragmatique propre. Django est basé sur le paradigme Modèle-Vue-Contrôleur (MVC) de l’architecture, donc les modèles des couches, des cartes et d’autres modules de GeoNode avec Django Model module et ces modèles sont utilisés par des ORM dans les vues qui contiennent la logique métier de l’application de GeoNode et sont utilisés pour conduire des modèles HTML pour afficher les pages Web au sein de l’application.

Django expliqué avec le modèle/view/contrôleur paradigme (MVC)

  • Le modèle représente les données d’application et fournit de riches fonctionnalités ORM.

  • Les vues sont une représentation d’un Modèle, plus souvent en utilisant le moteur de template de Django .

  • In Django, le contrôleur est le composant à travers lequel on peut interagir avec le modèle.

MVP/MVC

MVP

Modèle, Vue, Présentateur

Dans MVP, le Présentateur contient la logique de l’interface utilisateur (la ue). Toutes les invocations de la vue le délégue directement au Présentateur . Le Présentateur est également découplé directement à partir de Vue et parle à travers une interface. Un attribut commun de MVP est qu’il doit y avoir beaucoup d’échange d’informations dans les deux sens. Par exemple, quand quelqu’un clique sur le bouton Save, les délégués la gestion d’événement à la méthode de OnSave Présentateur. Une fois la sauvegarde terminée, le Présentateur rappelera la Vue grâce à son interface de sorte que la Vue puisse visualiser que la sauvegarde est terminée.

MVP est un paradigme très naturel pour la réalisation de la présentation séparée dans les formulaires Web.

Deux variations primaires ( Vous pouvez en savoir plus sur les deux variantes.)

Vue passive: La vue est la plus simple et contient près de zéro logique. Le présentateur est un middle man qui parle à la vue et au modèle. La vue et le modèle sont complètement à l’abri de l’autre. Le modèle peut déclencher des événements et le présentateur souscrit à eux pour mettre à jour la vue. Dans la vue passive, il n’y a pas pas de données directes, au lieu dexposer les propriétés setter laquelle le présentateur utilise pour définir les données. L’Etat est géré dans le Présentateur et pas dans la vue.

  • Pro: maximum testability surface; clean separation of the View and Model
  • Con: more work (for example all the setter properties) as you are doing all the data binding yourself.

Contrôleur surveillant: Le Présentateur gère les gestes de l’utilisateur. The View se lie au modèle directement à travers la liaison de données . Dans ce cas, il est le travail de l’animateur de faire passer le modèle à la vue de sorte qu’il peut se lier à elle . Le Présentateur contiendra également logique pour les gestes comme appuyant sur un bouton, la navigation, etc.

  • Pro: en tirant parti de liaison de données, la quantité de code est réduite .

  • Con: il y a moins de surface testables (en raison de la liaison de données ), et il y a moins d’encapsulation dans la vue car il parle directement au modèle .

MVC

Model, View, Controller

Dans le MVC, le contrôleur est chargé de déterminer quelle Vue est affichée en réponse à chaque action de l’application.

Cela diffère de MVP où les actions route à travers la vue sur le présentateur. Dans MVC, chaque action dans la Vue va générer un appel à un contrôleur avec une action. Chaque action implique un appel à une URL ou se trouve un contrôleur qui répond. Une fois que le contrôleur a terminé son travail, il va retourner la vue finale. La séquence va continuer de cette manière tout au long de la vie de l’application:

1
2
3
4
Action in the View
    -> Call to Controller
    -> Controller Logic
    -> Controller returns the View.

Une grande différence à propos de MVC est que la Vue n’interagir pas directement avec le modèle. La vue fait simplement le travail de afficher des informations et il n’a aucun d’etat. Donc avec le paradigme MVC la vue ne va pas avoir de la logique dans son interieur. Ceci est au contraire à MVP parce-que si la vue ne délègue pas au présentateur, il ne sera jamais appelé.

Modèle de Présentation

Une autre tendance à regarder est le paradigm Présentation Modèle. Dans ce modèle il n’y a pas Présentateur . Au lieu de la vue se lie directement un Modèle de Présentation. La présentation est un modèle créé spécifiquement pour la vue. Cela signifie que ce modèle peut exposer les propriétés que l’on aurait jamais mis sur un modèle de domaine, car il serait une violation de la separation-of-concerns. Dans ce cas, le modèle de présentation se lie au modèle de domaine, et peut souscrire à des événements provenant de ce modèle. The View souscrit alors à des événements à venir à partir du modèle et se met à jour en conséquence Présentation . Le modèle de présentation peut exposer le point de vue des commandes qui utilise pour invoquer actions. L’avantage de cette approche est que vous pouvez essentiellement supprimer le code -behind tout à fait que le PM encapsule complètement tous le comportement de la vue.

Ce modèle est un candidat très solide pour une utilisation dans les applications WPF et est aussi appelé Model-View-ViewModel.

Plus : http://reinout.vanrees.org/weblog/2011/12/13/django-mvc-explanation.html

WSGI

Web Server Gateway Interface (whis-gey)

  • Ceci est une spécification de python pour supporter une interface commune entre tous les différents frameworks web et une application (Apache, par exemple) qui est ‘serving’.

  • Cela permet à tout cadre compatible WSGI à être hosted dans un serveur compatible WSGI.

  • Pour la plupart de développement de GeoNode, les détails de cette spécification peuvent être ignorés.

Plus : http://en.wikipedia.org/wiki/Wsgi

GeoNode et GeoServer

GeoNode utilise GeoServer pour fournir des services de l’OGC.

À sa base, GeoNode fournit une plateforme basée sur des standards well-known pour permettre l’accès programmatique intégrée à vos données via des services Web de l’OGC, qui sont des éléments essentiels nécessaires pour déployer une infrastructure de données spatiales (SDI) conformes à l’OGC. Ces services Web permettent la découverte, la visualisation et le téléchargement des vos données, sans avoir nécessairement à interagir directement avec votre site de GeoNode.

  • GeoNode configure GeoServer via l’API REST

  • GeoNode récupère et met en cache les informations spatiales provenant de GeoServer. Cela inclut des liens pertinents OGC de services, les métadonnées spatiales, et des informations d’attributs .

    GeoServer contient les données des couches et le modèle de la couche de GeoNode étend les métadonnées présents dans GeoServer avec son propre.

  • GeoNode peut découvrir couches publiées dans un GeoServer via le document de capacités WMS (GetCapabilities).

  • GeoServer délégue l’authentification et l’autorisation à GeoNode

  • Les données chargées dans GeoNode sont d’abord élaborée dans GeoNode et enfin publiées à GeoServer (ou ingérées dans la SGBD).

OGC Web Services:

  • Ils fonctionnent sur HTTP ( GET, POST )

  • Ils fournisse une API formalisée et largement accepté

  • Ils fournissent des formats accepté formalisée

Les OGC Web Services fournis par GeoNode ont une base de mise en œuvre mature et fournissent une approche multi-application à l’intégration. Cela signifie, en tant que développeur, il ya déjà de nombreuses off -the-shelf SIG paquets, des outils et des webapps (exclusif, gratuit, open source) qui prennent en charge nativement les services Web de l’OGC.

Il existe de nombreuses façons d’ utiliser des services Web de l’OGC de GeoNode:

  • desktop GIS

  • application Web

  • bibliothèques client / toolkits

  • développement personalisèe

Votre GeoNode répertorie OGC Web Services et de leurs URL à “http://localhost:8000/developer. Vous pouvez utiliser ces API directement pour interagir avec votre GeoNode

Les sections suivantes décrivent brièvement les OGC Web Services fournis par GeoNode.

Web Map Service (WMS)

WMS fournit une API pour récupérer des images de carte ( PNG, JPEG, etc.) de données géospatiales . WMS est adapté pour la visualisation et lorsque l’accès aux données brutes n’est pas obligatoire .

WFS

WFS fournit une API pour récupérer des données brutes vectorielles géospatiales directement . WFS est adapté pour la requête directe et l’accès à des caractéristiques géographiques .

WCS

WCS fournit une API pour récupérer des données brutes raster géospatiales directement . WCS est adapté pour un accès direct à l’imagerie par satellite, MNE, etc.

CSW

CSW fournit une interface pour publier et rechercher des métadonnées ( données sur les données ) . CSW est adapté pour le catalogage des données géospatiales et le rend détectable afin de permettre la visualisation et l’accès .

WMTS

WMTS fournit une API pour tuiles de carte pré-rendus de données géospatiales .

WMC

WMC fournit un format pour enregistrer et charger des vues de carte et l’état de l’application via XML . Ceci permet, par exemple, un utilisateur d’enregistrer leur application de cartographie Web dans WMC et de le partager avec d’autres, la visualisation de la même teneur .

Plus: http://geoserver.org

GeoNode et PostgreSQL/PostGIS

Dans la production, GeoNode est configuré pour utiliser PostgreSQL / PostGIS pour sa mémoire persistante . Dans le développement et le mode de test, souvent une base de données SQLite intégrée est utilisée . Ce dernier n’a pas suggéré pour la production .

  • La configuration de base de données stocke des informations et de l’application. Cela inclut les utilisateurs, des couches, des cartes, etc.

  • Il est recommandé que GeoNode soit configuré pour utiliser PostgreSQL / PostGIS pour stocker des données vectorielles ainsi . Tout en se servant directement à partir de couches shapefile permet une performance adéquate dans de nombreux cas, le stockage caractéristiques dans la base de données permet une meilleure performance, surtout lors de l’utilisation des règles de style complexes basés sur des attributs .

GeoNode et pycsw

GeoNode est construit avec pycsw. pycsw est utilitsè pour fournir les fonctionnalités de serveur CSW par défaut.

Publishing

Alors que pycsw est intégré dans GeoNode, les couches publiées dans GeoNode sont automatiquement publiés à pycsw et détectable via CSW . Aucune configuration supplémentaire ou d’actions est tenus de publier des couches, des cartes ou des documents à pycsw .

Découverte

CSW le critère de GeoNode est déployé disponible à http://localhost:8000/catalogue/csw et est disponible pour les clients à utiliser pour la découverte basée sur des normes. Voir http://docs.pycsw.org/en/latest/tools.html pour une liste de clients et d’outils CSW .

Javascript dans GeoNode

GeoNode fournit un certain nombre d’installations pour l’interactivité dans le navigateur Web intégré sur le dessus de plusieurs frameworks JavaScript de haute qualité :

  • Bootstrap pour l’interface graphique de GeoNode et l’interaction commune avec l’utilisateur final.

  • Bower pour la gestion des paquets de l’interface graphique de GeoNode.

  • ExtJS pour la construction et les données interface utilisateur l’accès à base de composants

  • OpenLayers pour la cartographie interactive et d’autres opérations géospatiales

  • GeoExt pour intégrer ExtJS avec OpenLayers

  • Grunt pour l’automatisation des tâches frontal .

  • GXP pour fournir certains de niveau supérieur la construction d’installations d’application sur le dessus de GeoExt, ainsi que l’amélioration de l’intégration avec GeoServer .

  • jQuery à la manipulation abstraite javascript, la gestion des événements, l’animation et l’Ajax

GeoNode utilise des modules spécifiques à l’application pour gérer les pages et services qui sont uniques à GeoNode . Ce cadre comprend :

  • GeoNode mixin classe qui fournit GeoExplorer avec les méthodes nécessaires pour fonctionner correctement dans GeoNode . La classe est responsable de la vérification des autorisations, la récupération et la présentation de la CSRF jeton, l’authentification et de l’utilisateur.

  • Au module de recherche responsable de la fonctionnalité de recherche de l’ensemble du site de la GeoNode .

  • Un téléchargement et l’etat du module pour soutenir les téléchargements de fichiers .

  • Template files pour générer sections html couramment utilisés .

  • Un front-end testing module pour tester GeoNode javascript .

Les concepts suivants sont particulièrement importants pour le développement avec ​​le cadre JavaScript deGeoNode.

  • Composants

    Composants Ext gére la fonctionnalité la plus interactive dans les pages web «réguliers» . Par exemple, le tableau triable filtrables défilement / / sur la page de recherche par défaut est une composante de la grille . Alors que GeoNode fait utiliser certains composants personnalisés, la familiarité avec l’idée de composants utilisés par ExtJS est applicable dans le développement de GeoNode .

  • Viewers

    Les téléspectateurs affiche des cartes interactives dans les pages Web, éventuellement décorée avec des contrôles de Ext pour les barres d’outils, la sélection de la couche, etc. téléspectateurs dans GeoNode utilisent la classe de base GeoExplorer, qui construit sur ​​le dessus de l’Observateur de GXP de fournir des fonctionnalités communes telles que le respect des paramètres au niveau du site pour couches de fond . Les téléspectateurs peuvent être utilisés comme composants embarqués dans les pages, ou ils peuvent être en pleine page des applications JavaScript .

  • Controls

    Les contrôles sont des outils à utiliser dans les cartes d’OpenLayers (comme une commande à main levée pour dessiner de nouvelles géométries sur une carte, ou un identifient commande pour obtenir des informations sur les caractéristiques individuelles sur une carte. ) GeoExt fournit des outils pour l’utilisation de ces contrôles ExtJS “Actions” - opérations qui peuvent être invoqués comme des boutons ou des options de menu ou associés à d’autres événements.