GeoNode is an open source platform that facilitates the creation, sharing, and collaborative use of geospatial data.

Overview

GeoNode OSGeo Project

Table of Contents

What is GeoNode?

GeoNode is a geospatial content management system, a platform for the management and publication of geospatial data. It brings together mature and stable open-source software projects under a consistent and easy-to-use interface allowing non-specialized users to share data and create interactive maps.

Data management tools built into GeoNode allow for integrated creation of data, metadata, and map visualization. Each dataset in the system can be shared publicly or restricted to allow access to only specific users. Social features like user profiles and commenting and rating systems allow for the development of communities around each platform to facilitate the use, management, and quality control of the data the GeoNode instance contains.

It is also designed to be a flexible platform that software developers can extend, modify or integrate against to meet requirements in their own applications.

Try out GeoNode

If you just want to try out GeoNode visit our official Demo online at: http://master.demo.geonode.org. After your registration you will be able to test all basic functionalities like uploading layers, creation of maps, editing metadata, styles and much more. To get an overview what GeoNode can do we recommend to have a look at the Users Workshop.

Install

The latest official release is 3.2!

GeoNode can be setup in different ways, flavors and plattforms. If you´re planning to do development or install for production please visit the offical GeoNode installation documentation:

Learn GeoNode

After you´ve finished the setup process make yourself familiar with the general usage and settings of your GeoNodes instance. - the User Training is going in depth into what we can do. - the Administrators Workshop will guide you to the most important parts regarding management commands and configuration settings.

Development

GeoNode is a web based GIS tool, and as such, in order to do development on GeoNode itself or to integrate it into your own application, you should be familiar with basic web development concepts as well as with general GIS concepts.

For development GeoNode can be run in a 'development environment'. In contrast to a 'production environment' development differs as it uses lightweight components to speed up things.

To get you started have a look at the Install instructions which cover all what is needed to run GeoNode for development. Further visit the the Developer workshop for a basic overview.

If you're planning of customizing your GeoNode instance, or to extend it's functionalities it's not advisable to change core files in any case. In this case it's common to use setup a GeoNode Project Template.

Contributing

GeoNode is an open source project and contributors are needed to keep this project moving forward. Learn more on how to contribute on our Community Bylaws.

Roadmap

GeoNode's development roadmap is documented in a series of GeoNode Improvement Projects (GNIPS). They are documented at GeoNode Wiki.

GNIPS are considered to be large undertakings which will add a large amount of features to the project. As such they are the topic of community dicussion and guidance. The community discusses these on the developer mailing list: http://lists.osgeo.org/pipermail/geonode-devel/

Showcase

A handful of other Open Source projects extend GeoNode’s functionality by tapping into the re-usability of Django applications. Visit our gallery to see how the community uses GeoNode: GeoNode Showcase.

The development community is very supportive of new projects and contributes ideas and guidance for newcomers.

Most useful links

General

Related projects

Support

Licensing

GeoNode is Copyright 2018 Open Source Geospatial Foundation (OSGeo).

GeoNode is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. GeoNode is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with GeoNode. If not, see http://www.gnu.org/licenses.

Issues
  • GNIP 89: Architecture Design - Resource and Storage Manager Modules

    GNIP 89: Architecture Design - Resource and Storage Manager Modules

    Refererences: GNIP 89: Architecture Design - Resource and Storage Manager Modules

    Checklist

    Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

    For all pull requests:

    • [x] Confirm you have read the contribution guidelines
    • [x] You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
    • [x] Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

    The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

    • [x] There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
    • [ ] The issue connected to the PR must have Labels and Milestone assigned
    • [ ] PR for bug fixes and small new features are presented as a single commit
    • [x] Commit message must be in the form "[Fixes #<issue_number>] Title of the Issue"
    • [x] New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented
    • [x] This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
    • [x] This PR passes the QA checks: flake8 geonode
    • [ ] Commits changing the settings, UI, existing user workflows, or adding new functionality, need to include documentation updates
    • [ ] Commits adding new texts do use gettext and have updated .po / .mo files (without location infos)

    Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

    cla-signed 
    opened by afabiani 74
  • Migrating Geonode 2.0 Application (Postgresql Table) data to Geonode 2.4

    Migrating Geonode 2.0 Application (Postgresql Table) data to Geonode 2.4

    I'm working on migrating data for John Jediny's nepanode.anl.gov site, which is Geonode 2.0, to a new site that will use the latest version Geonode 2.4. From my perspective, there are three parts to this process:

    1. Migrate Geonode 2.0's application data, typically found in Postgresql database "geonode", schema "geonode" to Geonode 2.4's application database "geonode", schema "public".
    2. Migrate GeoServer's upload data store, typically found in Postgresql database "geonode_upload", schema "public" to Geonode 2.4's application database "datastore", schema, "public".
    3. Migrate GeoServer's data directory.

    At this point in time, I'm working on step 1. To that end, I've written a Python program named "create_migrate", that opens two connections, one for the source (Geonode 2.0) database and a second for the destination (Geonode 2.4) database. Next it compares the tables in each, providing a list of tables in the source, but not in the destination, a second list of tables that exist in the destination, but not in the source, and a third list of tables that exist in both. The it writes a set of "migrate_<table_name>.py" Python programs that can perform the migration. Why write a set of programs? Because each program has a section where select values are assigned to insert values, and it is there that a programmer can customize each program, if needed, to perform translations, ID substitutions, assign default values, etc..

    For Geonode 2.0 to 2.4 here is the lists it produced:

    Tables in src not in dst:

    auth_user auth_user_groups auth_user_user_permissions base_thumbnail django_comment_flags django_comments notification_noticequeuebatch notification_noticesetting notification_noticetype people_role people_role_permissions security_genericobjectrolemapping security_objectrole security_objectrole_permissions security_userobjectrolemapping south_migrationhistory tagging_tag tagging_taggeditem taggit_templatetags_amodel

    I've removed from this list captcha and zinnia tables that are unique modifications to NEPAnode.

    Tables in dst not in src:

    account_signupcodeextended base_license celery_taskmeta celery_tasksetmeta djcelery_crontabschedule djcelery_intervalschedule djcelery_periodictask djcelery_periodictasks djcelery_taskstate djcelery_workerstate groups_groupinvitation groups_groupmember groups_groupprofile guardian_groupobjectpermission guardian_userobjectpermission layers_layerfile layers_uploadsession maps_mapsnapshot people_profile_groups people_profile_user_permissions services_service services_servicelayer services_serviceprofilerole services_webserviceharvestlayersjob services_webserviceregistrationjob tastypie_apiaccess tastypie_apikey

    Tables in both:

    account_account account_accountdeletion account_emailaddress account_emailconfirmation account_signupcode account_signupcoderesult actstream_action actstream_follow agon_ratings_overallrating agon_ratings_rating announcements_announcement announcements_dismissal auth_group auth_group_permissions auth_permission avatar_avatar base_contactrole base_link base_region base_resourcebase base_resourcebase_regions base_restrictioncodetype base_spatialrepresentationtype base_topiccategory dialogos_comment django_admin_log django_content_type django_session django_site documents_document layers_attribute layers_layer layers_layer_styles layers_style maps_map maps_maplayer people_profile taggit_tag taggit_taggeditem upload_upload upload_uploadfile user_messages_message user_messages_thread user_messages_userthread

    First issue found: I have found that Geonode 2.0's auth_user and people_profile tables have been merged in Geonode 2.4, and accordingly, I modified the generated program migrate_people_profile.py.

    Second issue found: I have found that there are a set of configuration and/or code tables, where the "meaning" of the ID values has not been preserved from Geonode 2.0 to Geonode 2.4. May I suggest that in the future greater attention be paid to the reuse of such IDs? The only solution I have at this time is to build a mapping table from the old values to the new values, and swapping the values on-the-fly in the migration programs. That is a lot of extra work that may negative impact the adoption of Geonode going forward, and I don't want to see that happen.

    Third issue: concerning the list of Geonode 2.0 tables that are not in Geonode 2.4, do you have any documentation or explanation as to why? Were these table renamed, merged, or did they become obsolete?

    Fourth issue: concerning the list of Geonode 2.4 tables that are not in Geonode 2.0, do you have any documentation or explanation as to why? Are these table renamed, merged, or really new?

    John Jediny and I would like to share our migration work so others who are in a similar situartion may benefit. How do we go about doing that within the structure of your project?

    opened by donaldbales 55
  • Printing not working - Communication Trouble: Status undefined [object, Object]

    Printing not working - Communication Trouble: Status undefined [object, Object]

    When trying to print a map, the following error message is given

    Communication Trouble: Status undefined [object, Object]

    Verified the yaml file is correct. Issue is reproducible on alpha dev server.

    opened by stephenedavis 53
  • Ubuntu 14.04, Geonode 2.4b22 ==> 500 Internal Server Error

    Ubuntu 14.04, Geonode 2.4b22 ==> 500 Internal Server Error

    After previouse success lunching geonode 2.01 on ubuntu 12.04 and making project for custom theming, for using latest version, jumped to 2.4, but some error appeared.. 500 Internal Server Error !

    after tracking changes from apache to new version 2.4, error steel exist.

    from error.log of apache :

    [Tue Mar 03 02:45:09.631507 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] mod_wsgi (pid=1299): Exception occurred processing WSGI script '/home/dary/my_geonode/my_geonode/wsgi.py'. [Tue Mar 03 02:45:09.631563 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] Traceback (most recent call last): [Tue Mar 03 02:45:09.631596 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/django/core/handlers/wsgi.py", line 187, in call [Tue Mar 03 02:45:09.631638 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] self.load_middleware() [Tue Mar 03 02:45:09.631654 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 47, in load_middleware [Tue Mar 03 02:45:09.631674 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] mw_instance = mw_class() [Tue Mar 03 02:45:09.631687 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/django/middleware/locale.py", line 24, in init [Tue Mar 03 02:45:09.631707 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] for url_pattern in get_resolver(None).url_patterns: [Tue Mar 03 02:45:09.631720 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 365, in url_patterns [Tue Mar 03 02:45:09.631739 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] patterns = getattr(self.urlconf_module, "urlpatterns", self.urlconf_module) [Tue Mar 03 02:45:09.631752 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/django/core/urlresolvers.py", line 360, in urlconf_module [Tue Mar 03 02:45:09.631770 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] self._urlconf_module = import_module(self.urlconf_name) [Tue Mar 03 02:45:09.631783 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/django/utils/importlib.py", line 40, in import_module [Tue Mar 03 02:45:09.631802 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] import(name) [Tue Mar 03 02:45:09.631815 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/home/dary/my_geonode/my_geonode/urls.py", line 4, in [Tue Mar 03 02:45:09.631833 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] from geonode.urls import * [Tue Mar 03 02:45:09.631846 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/local/lib/python2.7/dist-packages/geonode/urls.py", line 30, in [Tue Mar 03 02:45:09.631865 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] from geonode.api.urls import api [Tue Mar 03 02:45:09.631878 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/local/lib/python2.7/dist-packages/geonode/api/urls.py", line 3, in [Tue Mar 03 02:45:09.631910 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] from .api import TagResource, TopicCategoryResource, ProfileResource,
    [Tue Mar 03 02:45:09.631935 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/local/lib/python2.7/dist-packages/geonode/api/api.py", line 21, in [Tue Mar 03 02:45:09.631958 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] from tastypie.resources import ModelResource [Tue Mar 03 02:45:09.631972 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/tastypie/resources.py", line 18, in [Tue Mar 03 02:45:09.631993 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] from tastypie.authentication import Authentication [Tue Mar 03 02:45:09.632022 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] File "/usr/lib/python2.7/dist-packages/tastypie/authentication.py", line 13, in [Tue Mar 03 02:45:09.632045 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] from tastypie.compat import User, username_field [Tue Mar 03 02:45:09.632072 2015] [:error] [pid 1299:tid 140148981966592] [remote 127.0.0.1:39424] ImportError: cannot import name username_field

    please help to removing errors..

    opened by darabk 45
  • [Issue #6079] Enable spatial data stores for Django database

    [Issue #6079] Enable spatial data stores for Django database

    Closes #4346

    This PR is now a major component of GNIP-75 and enables spatial Django datastores for GeoNode.

    Previous Description

    This PR aims to enable full functionality of the 'search by extent' feature when filtering layers.

    The previous implementation stored bounding box coordinates as decimal fields in the database, performing complex custom methods to infer coordinates and search queries such as filtering by layer extent.

    To address issues in #4346, this PR:

    • Uses the PostGIS extension in the GeoNode database (as specified by DATABASE_URL= in geonode/settings.py)
    • Replaces existing decimal-based bounding fields with a PostGIS polygon (includes data migration)
    • Relies on PostGIS to perform any queries related to bounding boxes

    As a side effect, bounding boxes not provided in EPSG4326 can now be reprojected on-the-fly.

    Previous decimal bbox_ fields have not been removed yet, but such a migration can be added once people are happy with our implementation.

    Checklist

    Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

    For all pull requests:

    • [x] Confirm you have read the contribution guidelines
    • [x] You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
    • [x] Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

    The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

    • [x] There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
    • [x] The issue connected to the PR must have Labels and Milestone assigned
    • [x] PR for bug fixes and small new features are presented as a single commit
    • [x] Commit message must be in the form "[Fixes #<issue_number>] Title of the Issue"
    • [ ] New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented
    • [x] This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
    • [x] This PR passes the QA checks: flake8 geonode
    • [x] Commits changing the settings, UI, existing user workflows, or adding new functionality, need to include documentation updates

    Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

    cla-signed 
    opened by mtnorthcott 43
  • GNIP-84: Upload Page Enhancements #7154

    GNIP-84: Upload Page Enhancements #7154

    GNIP-84: Upload Page Enhancements #7154

    Checklist

    Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

    For all pull requests:

    • [x] Confirm you have read the contribution guidelines
    • [x] You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
    • [x] Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

    The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

    • [x] There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
    • [x] The issue connected to the PR must have Labels and Milestone assigned
    • [ ] PR for bug fixes and small new features are presented as a single commit
    • [x] Commit message must be in the form "[Fixes #<issue_number>] Title of the Issue"
    • [x] New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented
    • [x] This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
    • [x] This PR passes the QA checks: flake8 geonode
    • [ ] Commits changing the settings, UI, existing user workflows, or adding new functionality, need to include documentation updates
    • [x] Commits adding new texts do use gettext and have updated .po / .mo files (without location infos)

    Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

    cla-signed backport 3.2.x 
    opened by afabiani 38
  • Job for uwsgi.service failed

    Job for uwsgi.service failed

    Hi eb, I'm here, Ubuntu 20.04 Core installation Install and configure NGINX https://docs.geonode.org/en/master/install/advanced/core/#install-and-configure-nginx

    When I restart the uwsgi service: sudo service uwsgi restart

    I get: Job for uwsgi.service failed because the control process exited with error code. See "systemctl status uwsgi.service" and "journalctl -xe" for details.

    The service status is: ● uwsgi.service - LSB: Start/stop uWSGI server instance(s) Loaded: loaded (/etc/init.d/uwsgi; generated) Active: failed (Result: exit-code) since Sun 2021-01-03 20:00:21 CET; 2min 51s ago Docs: man:systemd-sysv-generator(8) Process: 25449 ExecStart=/etc/init.d/uwsgi start (code=exited, status=1/FAILURE)

    Thanks

    question configuration 
    opened by valeriodeluca 35
  • GNIP 75 - Enable spatial data store for Django DB

    GNIP 75 - Enable spatial data store for Django DB

    GNIP 75 - Enable spatial data store for Django DB

    Overview

    This GNIP proposes the transition to spatial data stores such as PostGIS and Spatialite in place of the existing Django database. This will enable more streamlined and easier implementation of features involving geospatial queries such as 'search by extent'. The implication of this transition is the migration of existing data sets. The implementation requires adjustments to all installation sources and fixes to the Travis CI and paver test suites.

    Proposed By

    @mtnorthcott @GeoTob

    Assigned to Release

    This proposal is for GeoNode 3.x

    State

    • [ ] Under Discussion
    • [ ] In Progress
    • [x] Completed
    • [ ] Rejected
    • [ ] Deferred

    Existing work

    This GNIP started as a fix for the 'search by extent' feature, proposed in #6064 which serves as a basis. In this state, the feature works with the Docker, paver and SPCGeoNode installation methods. The focus is now on getting Travis CI tests to pass, documenting and advertising all changes thoroughly.

    Pull Requests:

    Motivation

    • Easier storage and handling of geospatial data
    • Removal of unnecessary bbox_* decimal fields
    • More simplistic implementation of features like 'search by extent'
    • On-the-fly reprojection of non-EPSG4326 bounding boxes

    Originally, an issue (#4346) was raised over the 'search by extent' feature not working properly. The issue was mitigated in a commit, however, the end goal is to transition to spatial databases exclusively. Work towards this goal has begun in effort to enable full functionality to the 'search by extent' feature in #6064.

    Proposal

    • [x] Update paver installation method and test accordingly
    • [x] Update Docker installation method and test accordingly
    • [x] Update Django test suite
    • [x] Update Travis CI
    • [x] Update all documentation accordingly, especially the setup parts
    • [ ] Advertise all new changes accordingly

    Backwards Compatibility

    • We can maintain access to bounding box fields but calculate these upon request via Python @property decorated access methods
    • Tests require adjustment to be compatible with spatial data stores

    Future evolution

    Feedback

    Some initial thoughts have been discussed in the original issue (#4346) and the 'search by extent' pull request (#6064).

    Voting

    Project Steering Committee:

    • Giovanni Allegi: ✔
    • Alessio Fabiani: ✔
    • Francesco Bartoli: abstained
    • Simone Dalmasso:
    • Toni Schoenbuchner: ✔
    • Florian Hoedt: ✔

    Links

    gnip 
    opened by mtnorthcott 35
  • Unable to access WFS or WMS Resources using QGIS

    Unable to access WFS or WMS Resources using QGIS

    Expected Behavior

    Connect to resources based on access permissions set in GeoNode

    Actual Behavior

    QGIS is unable to see any available layers.

    Steps to Reproduce the Problem

    1. Uploaded a "Test_Layer" and changed permissions: image
    2. Attempt to connect to WFS resource using QGIS @ http://<geonode-url>/geoserver/ows?service=wfs&version=2.0.0&request=GetCapabilities and basic authentication for the testuser account.
    3. QGIS is showing no layers for the connected WFS resource.
    4. Geofence rules created by GeoNode are visible in Geoserver: image

    Specifications

    • GeoNode version: 2.10.1
    • Installation method (manual, GeoNode Docker, SPCGeoNode Docker): manual
    • Platform: Ubuntu Server 18.04 LTS
    • Additional details:
    needs further investigation wontfix 
    opened by rgmrtn 35
  • Geonode Add New Vector Layer Error:  java.lang.NoSuchMethodError: org.locationtech.jts.geom.Polygon.getExteriorRing;

    Geonode Add New Vector Layer Error: java.lang.NoSuchMethodError: org.locationtech.jts.geom.Polygon.getExteriorRing;

    Expected Behavior

    I installed GeoNode with Docker with this doc. Geonode is installed on production mode and every part of application works. I want to import a shapefile to GeoNode as an vector layer.

    Actual Behavior

    It has an error after geoserver configuration step during adding new vector layers.

    java.lang.NoSuchMethodError: org.locationtech.jts.geom.Polygon.getExteriorRing()Lorg/locationtech/jts/geom/LinearRing; org.locationtech.jts.geom.Polygon.getExteriorRing()Lorg/locationtech/jts/geom/LinearRing; In the database, shapefile data, is stored in the geonode_data database ,and in the Geoserver,layer is publish from PostGIS store, But the in Geoserver I can't see the layer, and I also face with above error.

    Steps to Reproduce the Problem

    1. GeoNode Installed completely.
    2. Raster Layer Upload worked.
    3. Vector Layer Upload Face with an error.

    Specifications

    • GeoNode version: 3.1.0.dev1598252669
    • Installation method (manual, GeoNode Docker, SPCGeoNode Docker): GeoNode Docker
    • Platform: Ubuntu Server 18.04 LTS
    • Additional details: I didn't changed any configuration ,and followed steps that were in this documentation.
    regression dependencies needs further investigation 
    opened by mahdin75 34
  • Mapstore2 Add Group button is missing

    Mapstore2 Add Group button is missing

    Expected Behavior

    You can add a new group to a map like in mapstore2 demo: https://dev.mapstore.geo-solutions.it/mapstore/#/viewer/openlayers/6200

    grafik

    Actual Behavior

    The add group button is missing in GeoNode

    grafik

    Steps to Reproduce the Problem

    1. open master.demo.geonode.org and login
    2. create a map
    3. try to create a new group

    Specifications

    I tested this on my dev instance with SPC 2.10.1 and master.demo.geonode.org

    • GeoNode version: master.demo.geonode.org ? / 2.10.1
    • Installation method (manual, GeoNode Docker, SPCGeoNode Docker): ? / SPC
    • Platform: some Linux
    • Additional details:
    feature frontend 
    opened by gannebamm 30
  • WIP - [Fixes #9511] extrapolate FileUploadSizeLimit and UploadParallelismLi…

    WIP - [Fixes #9511] extrapolate FileUploadSizeLimit and UploadParallelismLi…

    …mit limit from upload form

    ref #9511

    Checklist

    Reviewing is a process done by project maintainers, mostly on a volunteer basis. We try to keep the overhead as small as possible and appreciate if you help us to do so by completing the following items. Feel free to ask in a comment if you have troubles with any of them.

    For all pull requests:

    • [x] Confirm you have read the contribution guidelines
    • [x] You have sent a Contribution Licence Agreement (CLA) as necessary (not required for small changes, e.g., fixing typos in the documentation)
    • [x] Make sure the first PR targets the master branch, eventual backports will be managed later. This can be ignored if the PR is fixing an issue that only happens in a specific branch, but not in newer ones.

    The following are required only for core and extension modules (they are welcomed, but not required, for contrib modules):

    • [x] There is a ticket in https://github.com/GeoNode/geonode/issues describing the issue/improvement/feature (a notable exemption is, changes not visible to end-users)
    • [x] The issue connected to the PR must have Labels and Milestone assigned
    • [x] PR for bug fixes and small new features are presented as a single commit
    • [x] Commit message must be in the form "[Fixes #<issue_number>] Title of the Issue"
    • [ ] New unit tests have been added covering the changes, unless there is an explanation on why the tests are not necessary/implemented
    • [x] This PR passes all existing unit tests (test results will be reported by travis-ci after opening this PR)
    • [x] This PR passes the QA checks: flake8 geonode
    • [ ] Commits changing the settings, UI, existing user workflows, or adding new functionality, need to include documentation updates
    • [ ] Commits adding new texts do use gettext and have updated .po / .mo files (without location infos)

    Submitting the PR does not require you to check all items, but by the time it gets merged, they should be either satisfied or inapplicable.

    cla-signed backport 4.x 
    opened by mattiagiupponi 1
  • Bump dropbox from 11.31.0 to 11.32.0

    Bump dropbox from 11.31.0 to 11.32.0

    Bumps dropbox from 11.31.0 to 11.32.0.

    Release notes

    Sourced from dropbox's releases.

    v11.32.0

    Release Notes:

    • Automated Spec Update (#435)
    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies cla-signed backport 4.x 
    opened by dependabot[bot] 0
  • Update setuptools requirement from <62.4.0,>=59.1.1 to >=59.1.1,<62.7.0

    Update setuptools requirement from <62.4.0,>=59.1.1 to >=59.1.1,<62.7.0

    Updates the requirements on setuptools to permit the latest version.

    Changelog

    Sourced from setuptools's changelog.

    v62.6.0

    Changes ^^^^^^^

    • #3253: Enabled using file: for requirements in setup.cfg -- by :user:akx (this feature is currently considered to be in beta stage).
    • #3255: Enabled using file: for dependencies and optional-dependencies in pyproject.toml -- by :user:akx (this feature is currently considered to be in beta stage).
    • #3391: Updated attr: to also extract simple constants with type annotations -- by :user:karlotness

    v62.5.0

    Changes ^^^^^^^

    • #3347: Changed warnings and documentation notes about experimental aspect of pyproject.toml configuration: now [pyproject] is a fully supported configuration interface, but the [tool.setuptools] table and sub-tables are still considered to be in beta stage.
    • #3383: In _distutils_hack, suppress/undo the use of local distutils when select tests are imported in CPython.

    Documentation changes ^^^^^^^^^^^^^^^^^^^^^

    • #3368: Added documentation page about extension modules -- by :user:mkoeppe

    • #3371: Moved documentation from /userguide/commands to /depracted/commands. This change was motived by the fact that running python setup.py directly is considered a deprecated practice.

    • #3372: Consolidated sections about sdist contents and MANIFEST.in into a single page.

      Added a simple MANIFEST.in example.

    • #3373: Moved remarks about using :pypi:Cython to the newly created page for extension modules.

    • #3374: Added clarification that using python setup.py egg_info commands to manage project versions is only supported in a transitional basis, and that eventually egg_info will be deprecated.

      Reorganized sections with tips for managing versions.

    • #3378: Updated Quickstart docs to make it easier to follow for beginners.

    Misc ^^^^

    • #3385: Modules used to parse and evaluate configuration from pyproject.toml files are intended for internal use only and that not part of the public API.

    v62.4.0

    ... (truncated)

    Commits
    • 7514c6a Bump version: 62.5.0 → 62.6.0
    • 645a53f Add beta status to 'file' directive for reading dependencies
    • 21d5b57 Allow file directive for dependencies (#3253, #3255)
    • 8e83289 Add support for type annotations to attr: ast parsing (#3391)
    • 7e4cb12 Merge pull request #1 from abravalheri/ast-annotation
    • 0b1d090 config.expand.StaticModule: handle scenarios when annotated assignment does n...
    • 6384f26 config.expand: Refactor StaticModule
    • 0488436 test_expand: Add example for annotated assignment without value
    • 15af535 Add changelog entry for attr: type annotation support
    • 685c80c Add support for annotated assignments to static attribute lookup.
    • Additional commits viewable in compare view

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies cla-signed backport 4.x 
    opened by dependabot[bot] 0
  • Bump boto3 from 1.24.2 to 1.24.12

    Bump boto3 from 1.24.2 to 1.24.12

    Bumps boto3 from 1.24.2 to 1.24.12.

    Changelog

    Sourced from boto3's changelog.

    1.24.12

    • api-change:connect: [botocore] This release updates these APIs: UpdateInstanceAttribute, DescribeInstanceAttribute and ListInstanceAttributes. You can use it to programmatically enable/disable High volume outbound communications using attribute type HIGH_VOLUME_OUTBOUND on the specified Amazon Connect instance.
    • api-change:connectcampaigns: [botocore] Added Amazon Connect high volume outbound communications SDK.
    • api-change:dynamodb: [botocore] Doc only update for DynamoDB service
    • api-change:dynamodbstreams: [botocore] Update dynamodbstreams client to latest version

    1.24.11

    • api-change:redshift-data: [botocore] This release adds a new --workgroup-name field to operations that connect to an endpoint. Customers can now execute queries against their serverless workgroups.
    • api-change:redshiftserverless: [botocore] Add new API operations for Amazon Redshift Serverless, a new way of using Amazon Redshift without needing to manually manage provisioned clusters. The new operations let you interact with Redshift Serverless resources, such as create snapshots, list VPC endpoints, delete resource policies, and more.
    • api-change:secretsmanager: [botocore] Documentation updates for Secrets Manager
    • api-change:securityhub: [botocore] Added Threats field for security findings. Added new resource details for ECS Container, ECS Task, RDS SecurityGroup, Kinesis Stream, EC2 TransitGateway, EFS AccessPoint, CloudFormation Stack, CloudWatch Alarm, VPC Peering Connection and WAF Rules

    1.24.10

    • api-change:finspace-data: [botocore] This release adds a new set of APIs, GetPermissionGroup, DisassociateUserFromPermissionGroup, AssociateUserToPermissionGroup, ListPermissionGroupsByUser, ListUsersByPermissionGroup.
    • api-change:guardduty: [botocore] Adds finding fields available from GuardDuty Console. Adds FreeTrial related operations. Deprecates the use of various APIs related to Master Accounts and Replace them with Administrator Accounts.
    • api-change:servicecatalog-appregistry: [botocore] This release adds a new API ListAttributeGroupsForApplication that returns associated attribute groups of an application. In addition, the UpdateApplication and UpdateAttributeGroup APIs will not allow users to update the 'Name' attribute.
    • api-change:workspaces: [botocore] Added new field "reason" to OperationNotSupportedException. Receiving this exception in the DeregisterWorkspaceDirectory API will now return a reason giving more context on the failure.

    1.24.9

    • api-change:budgets: [botocore] Add a budgets ThrottlingException. Update the CostFilters value pattern.
    • api-change:lookoutmetrics: [botocore] Adding filters to Alert and adding new UpdateAlert API.
    • api-change:mediaconvert: [botocore] AWS Elemental MediaConvert SDK has added support for rules that constrain Automatic-ABR rendition selection when generating ABR package ladders.

    1.24.8

    • api-change:outposts: [botocore] This release adds API operations AWS uses to install Outpost servers.

    1.24.7

    • api-change:frauddetector: [botocore] Documentation updates for Amazon Fraud Detector (AWSHawksNest)

    1.24.6

    ... (truncated)

    Commits
    • 735332e Merge branch 'release-1.24.12'
    • ed889fe Bumping version to 1.24.12
    • b9102b8 Add changelog entries from botocore
    • 9618284 Merge branch 'release-1.24.11'
    • 16a44f6 Merge branch 'release-1.24.11' into develop
    • 426cf85 Bumping version to 1.24.11
    • f0dc0c6 Add changelog entries from botocore
    • b3674ed Merge branch 'release-1.24.10'
    • 5c454ae Merge branch 'release-1.24.10' into develop
    • 96fe661 Bumping version to 1.24.10
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies cla-signed backport 4.x 
    opened by dependabot[bot] 0
  • Bump django-markdownify from 0.9.1 to 0.9.2

    Bump django-markdownify from 0.9.1 to 0.9.2

    Bumps django-markdownify from 0.9.1 to 0.9.2.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies cla-signed backport 4.x 
    opened by dependabot[bot] 0
  • Bump django-filter from 21.1 to 22.1

    Bump django-filter from 21.1 to 22.1

    Bumps django-filter from 21.1 to 22.1.

    Changelog

    Sourced from django-filter's changelog.

    Version 22.1 (2022-6-17)

    • Update supported Python and Django versions: minimal Python is now 3.7, minimum Django is now 3.2.

    • Added testing for Python 3.10 and Django 4.1.

    • Removed outdated deprecated warnings for code removed in version 2.1.

    • The code base is now formatted with Black.

    Commits
    • 2c81768 Updated isort config to use black profile.
    • 6d02135 Renamed branch in GHA workflow.
    • 9f188ff Added Black usage to change notes.
    • f4866a9 Applied Black.
    • ab35490 Updated version and change notes for 22.1 release.
    • f532ca1 Removed duplicate Python version specifier.
    • e2f560f Install package when building docs.
    • 057eaee Added RTD config.
    • b972fc7 Updated change notes.
    • cd994e0 Updated copyright in docs.
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies cla-signed backport 4.x 
    opened by dependabot[bot] 0
Releases(3.3.2.post2)
Owner
GeoNode Development Team
GeoNode Development Team
Minimum Bounding Box of Geospatial data

BBOX Problem definition: The spatial data users often are required to obtain the coordinates of the minimum bounding box of vector and raster data in

Ali Khosravi Kazazi 1 Dec 5, 2021
The geospatial toolkit for redistricting data.

maup maup is the geospatial toolkit for redistricting data. The package streamlines the basic workflows that arise when working with blocks, precincts

Metric Geometry and Gerrymandering Group 54 Jun 25, 2022
A part of HyRiver software stack for handling geospatial data manipulations

Package Description Status PyNHD Navigate and subset NHDPlus (MR and HR) using web services Py3DEP Access topographic data through National Map's 3DEP

Taher Chegini 4 Jun 11, 2022
Enable geospatial data mining through Google Earth Engine in Grasshopper 3D, via its most recent Hops component.

AALU_Geo Mining This repository is produced for a masterclass at the Architectural Association Landscape Urbanism programme. Requirements Rhinoceros (

null 2 Apr 12, 2022
Specification for storing geospatial vector data (point, line, polygon) in Parquet

GeoParquet About This repository defines how to store geospatial vector data (point, lines, polygons) in Apache Parquet, a popular columnar storage fo

Open Geospatial Consortium 290 Jun 26, 2022
Rasterio reads and writes geospatial raster datasets

Rasterio Rasterio reads and writes geospatial raster data. Geographic information systems use GeoTIFF and other formats to organize and store gridded,

Mapbox 1.7k Jun 26, 2022
leafmap - A Python package for geospatial analysis and interactive mapping in a Jupyter environment.

A Python package for geospatial analysis and interactive mapping with minimal coding in a Jupyter environment

Qiusheng Wu 1.3k Jun 20, 2022
WebGL2 powered geospatial visualization layers

deck.gl | Website WebGL2-powered, highly performant large-scale data visualization deck.gl is designed to simplify high-performance, WebGL-based visua

Vis.gl 9.9k Jun 21, 2022
Summary statistics of geospatial raster datasets based on vector geometries.

rasterstats rasterstats is a Python module for summarizing geospatial raster datasets based on vector geometries. It includes functions for zonal stat

Matthew Perry 415 Jun 29, 2022
Geospatial Image Processing for Python

GIPPY Gippy is a Python library for image processing of geospatial raster data. The core of the library is implemented as a C++ library, libgip, with

GIPIT 81 Jun 3, 2022
🌐 Local tile server for viewing geospatial raster files with ipyleaflet

?? Local Tile Server for Geospatial Rasters Need to visualize a rather large raster (gigabytes) you have locally? This is for you. A Flask application

Bane Sullivan 160 Jun 8, 2022
h3-js provides a JavaScript version of H3, a hexagon-based geospatial indexing system.

h3-js The h3-js library provides a pure-JavaScript version of the H3 Core Library, a hexagon-based geographic grid system. It can be used either in No

Uber Open Source 566 Jun 27, 2022
🌐 Local tile server for viewing geospatial raster files with ipyleaflet or folium

?? Local Tile Server for Geospatial Rasters Need to visualize a rather large (gigabytes) raster you have locally? This is for you. A Flask application

Bane Sullivan 160 Jun 8, 2022
Cloud Optimized GeoTIFF creation and validation plugin for rasterio

rio-cogeo Cloud Optimized GeoTIFF (COG) creation and validation plugin for Rasterio. Documentation: https://cogeotiff.github.io/rio-cogeo/ Source Code

null 200 Jun 6, 2022
GebPy is a Python-based, open source tool for the generation of geological data of minerals, rocks and complete lithological sequences.

GebPy is a Python-based, open source tool for the generation of geological data of minerals, rocks and complete lithological sequences. The data can be generated randomly or with respect to user-defined constraints, for example a specific element concentration within minerals and rocks or the order of units within a complete lithological profile.

Maximilian Beeskow 11 Feb 13, 2022
A package built to support working with spatial data using open source python

EarthPy EarthPy makes it easier to plot and manipulate spatial data in Python. Why EarthPy? Python is a generic programming language designed to suppo

Earth Lab 376 Jun 25, 2022
Open Data Cube analyses continental scale Earth Observation data through time

Open Data Cube Core Overview The Open Data Cube Core provides an integrated gridded data analysis environment for decades of analysis ready earth obse

Open Data Cube 379 Jun 12, 2022
Mmdb-server - An open source fast API server to lookup IP addresses for their geographic location

mmdb-server mmdb-server is an open source fast API server to lookup IP addresses

Alexandre Dulaunoy 38 Jun 15, 2022
EOReader is a multi-satellite reader allowing you to open optical and SAR data.

Remote-sensing opensource python library reading optical and SAR sensors, loading and stacking bands, clouds, DEM and index.

ICube-SERTIT 69 Jun 19, 2022