• Stars
    star
    1,081
  • Rank 42,808 (Top 0.9 %)
  • Language
    Python
  • License
    MIT License
  • Created almost 12 years ago
  • Updated about 1 month ago

Reviews

There are no reviews yet. Be the first to send feedback to the community and the maintainers!

Repository Details

Geographic add-ons for Django REST Framework. Maintained by the OpenWISP Project.

django-rest-framework-gis

Build Status Coverage Status Dependency monitoring PyPI version PyPI downloads Black

Geographic add-ons for Django Rest Framework - Mailing List.

Install last stable version from pypi

pip install djangorestframework-gis

Install development version

pip install https://github.com/openwisp/django-rest-framework-gis/tarball/master

Setup

Add rest_framework_gis in settings.INSTALLED_APPS, after rest_framework:

INSTALLED_APPS = [
    # ...
    'rest_framework',
    'rest_framework_gis',
    # ...
]

Compatibility with DRF, Django and Python

DRF-gis version DRF version Django version Python version
1.0.x 3.10 up to 3.13 2.2 to 4.0 3.6 to 3.9
0.18.x 3.10 up to 3.13 2.2 to 4.0 3.6 to 3.9
0.17.x 3.10 up to 3.12 2.2 to 3.1 3.6 to 3.8
0.16.x 3.10 2.2 to 3.1 3.6 to 3.8
0.15.x 3.10 1.11, 2.2 to 3.0 3.5 to 3.8
0.14.x 3.3 to 3.9 1.11 to 2.1 3.4 to 3.7
0.13.x 3.3 to 3.8 1.11 to 2.0 2.7 to 3.6
0.12.x 3.1 to 3.7 1.11 to 2.0 2.7 to 3.6
0.11.x 3.1 to 3.6 1.7 to 1.11 2.7 to 3.6
0.10.x 3.1 to 3.3 1.7 to 1.9 2.7 to 3.5
0.9.6 3.1 to 3.2 1.5 to 1.8 2.6 to 3.5
0.9.5 3.1 to 3.2 1.5 to 1.8 2.6 to 3.4
0.9.4 3.1 to 3.2 1.5 to 1.8 2.6 to 3.4
0.9.3 3.1 1.5 to 1.8 2.6 to 3.4
0.9.2 3.1 1.5 to 1.8 2.6 to 3.4
0.9.1 3.1 1.5 to 1.8 2.6 to 3.4
0.9 3.1 1.5 to 1.8 2.6, 2.7, 3.3, 3.4
0.9 3.1 1.5 to 1.8 2.6, 2.7, 3.3, 3.4
0.9 3.1 1.5 to 1.8 2.6, 2.7, 3.3, 3.4
0.8.2 3.0.4 to 3.1.1 1.5 to 1.8 2.6, 2.7, 3.3, 3.4
0.8.1 3.0.4 to 3.1.1 1.5 to 1.8 2.6, 2.7, 3.3, 3.4
0.8 3.0.4 1.5 to 1.7 2.6, 2.7, 3.3, 3.4
0.7 2.4.3 1.5 to 1.7 2.6, 2.7, 3.3, 3.4
0.6 2.4.3 1.5 to 1.7 2.6, 2.7, 3.3, 3.4
0.5 from 2.3.14 to 2.4.2 1.5 to 1.7 2.6, 2.7, 3.3, 3.4
0.4 from 2.3.14 to 2.4.2 1.5 to 1.7 2.6, 2.7, 3.3, 3.4
0.3 from 2.3.14 to 2.4.2 1.5, 1.6 2.6, 2.7
0.2 from 2.2.2 to 2.3.13 1.5, 1.6 2.6, 2.7

Fields

GeometryField

Provides a GeometryField, which is a subclass of Django Rest Framework (from now on DRF) WritableField. This field handles GeoDjango geometry fields, providing custom to_native and from_native methods for GeoJSON input/output.

This field takes three optional arguments:

  • precision: Passes coordinates through Python's builtin round() function (docs), rounding values to the provided level of precision. E.g. A Point with lat/lng of [51.0486, -114.0708] passed through a GeometryField(precision=2) would return a Point with a lat/lng of [51.05, -114.07].
  • remove_duplicates: Remove sequential duplicate coordinates from line and polygon geometries. This is particularly useful when used with the precision argument, as the likelihood of duplicate coordinates increase as precision of coordinates are reduced.
  • auto_bbox: If True, the GeoJSON object will include a bounding box, which is the smallest possible rectangle enclosing the geometry.

Note: While precision and remove_duplicates are designed to reduce the byte size of the API response, they will also increase the processing time required to render the response. This will likely be negligible for small GeoJSON responses but may become an issue for large responses.

New in 0.9.3: there is no need to define this field explicitly in your serializer, it's mapped automatically during initialization in rest_framework_gis.apps.AppConfig.ready().

GeometrySerializerMethodField

Provides a GeometrySerializerMethodField, which is a subclass of DRF SerializerMethodField and handles values which are computed with a serializer method and are used as a geo_field. See example below.

Serializers

GeoModelSerializer (DEPRECATED)

Deprecated, will be removed in 1.0: Using this serializer is not needed anymore since 0.9.3, if you add rest_framework_gis in settings.INSTALLED_APPS the serialization will work out of the box with DRF. Refer Issue #156.

Provides a GeoModelSerializer, which is a subclass of DRF ModelSerializer. This serializer updates the field_mapping dictionary to include field mapping of GeoDjango geometry fields to the above GeometryField.

For example, the following model:

class Location(models.Model):
    """
    A model which holds information about a particular location
    """
    address = models.CharField(max_length=255)
    city = models.CharField(max_length=100)
    state = models.CharField(max_length=100)
    point = models.PointField()

By default, the DRF ModelSerializer ver < 0.9.3 will output:

{
    "id": 1,
    "address": "742 Evergreen Terrace",
    "city":  "Springfield",
    "state": "Oregon",
    "point": "POINT(-123.0208 44.0464)"
}

In contrast, the GeoModelSerializer will output:

{
    "id": 1,
    "address": "742 Evergreen Terrace",
    "city":  "Springfield",
    "state": "Oregon",
    "point": {
        "type": "Point",
        "coordinates": [-123.0208, 44.0464],
    }
}

Note: For ver>=0.9.3: The DRF model serializer will give the same output as above, if;

  • rest_framework_gis is set in settings.INSTALLED_APPS or
  • the field in the serializer is set explicitly as GeometryField.

GeoFeatureModelSerializer

GeoFeatureModelSerializer is a subclass of rest_framework.ModelSerializer which will output data in a format that is GeoJSON compatible. Using the above example, the GeoFeatureModelSerializer will output:

 {
    "id": 1,
    "type": "Feature",
    "geometry": {
        "type": "Point",
        "coordinates": [-123.0208, 44.0464],
    },
    "properties": {
        "address": "742 Evergreen Terrace",
        "city":  "Springfield",
        "state": "Oregon"
    }
}

If you are serializing an object list, GeoFeatureModelSerializer will create a FeatureCollection:

{
    "type": "FeatureCollection",
    "features": [
    {
        "id": 1
        "type": "Feature",
        "geometry": {
            "type": "Point",
            "coordinates": [-123.0208, 44.0464],
        },
        "properties": {
            "address": "742 Evergreen Terrace",
            "city":  "Springfield",
            "state": "Oregon",
        }
    }
    {
        "id": 2,
        "type": "Feature",
        "geometry": {
            "type": "Point",
            "coordinates": [-123.0208, 44.0489],
        },
        "properties": {
            "address": "744 Evergreen Terrace",
            "city":  "Springfield",
            "state": "Oregon"
        }
    }
}
Specifying the geometry field: "geo_field"

GeoFeatureModelSerializer requires you to define a geo_field to be serialized as the "geometry". For example:

from rest_framework_gis.serializers import GeoFeatureModelSerializer

class LocationSerializer(GeoFeatureModelSerializer):
    """ A class to serialize locations as GeoJSON compatible data """

    class Meta:
        model = Location
        geo_field = "point"

        # you can also explicitly declare which fields you want to include
        # as with a ModelSerializer.
        fields = ('id', 'address', 'city', 'state')
Using GeometrySerializerMethodField as "geo_field"

geo_field may also be an instance of GeometrySerializerMethodField. In this case you can compute its value during serialization. For example:

from django.contrib.gis.geos import Point
from rest_framework_gis.serializers import GeoFeatureModelSerializer, GeometrySerializerMethodField

class LocationSerializer(GeoFeatureModelSerializer):
    """ A class to serialize locations as GeoJSON compatible data """

    # a field which contains a geometry value and can be used as geo_field
    other_point = GeometrySerializerMethodField()

    def get_other_point(self, obj):
        return Point(obj.point.lat / 2, obj.point.lon / 2)

    class Meta:
        model = Location
        geo_field = 'other_point'

Serializer for geo_field may also return None value, which will translate to null value for geojson geometry field.

Specifying the ID: "id_field"

The primary key of the model (usually the "id" attribute) is automatically used as the id field of each GeoJSON Feature Object.

The default behaviour follows the GeoJSON RFC, but it can be disabled by setting id_field to False:

from rest_framework_gis.serializers import GeoFeatureModelSerializer

class LocationSerializer(GeoFeatureModelSerializer):

    class Meta:
        model = Location
        geo_field = "point"
        id_field = False
        fields = ('id', 'address', 'city', 'state')

The id_field can also be set to use some other unique field in your model, eg: slug:

from rest_framework_gis.serializers import GeoFeatureModelSerializer

class LocationSerializer(GeoFeatureModelSerializer):

    class Meta:
        model = Location
        geo_field = 'point'
        id_field = 'slug'
        fields = ('slug', 'address', 'city', 'state')
Bounding Box: "auto_bbox" and "bbox_geo_field"

The GeoJSON specification allows a feature to contain a boundingbox of a feature. GeoFeatureModelSerializer allows two different ways to fill this property. The first is using the geo_field to calculate the bounding box of a feature. This only allows read access for a REST client and can be achieved using auto_bbox. Example:

from rest_framework_gis.serializers import GeoFeatureModelSerializer

class LocationSerializer(GeoFeatureModelSerializer):
    class Meta:
        model = Location
        geo_field = 'geometry'
        auto_bbox = True

The second approach uses the bbox_geo_field to specify an additional GeometryField of the model which will be used to calculate the bounding box. This allows boundingboxes differ from the exact extent of a features geometry. Additionally this enables read and write access for the REST client. Bounding boxes send from the client will be saved as Polygons. Example:

from rest_framework_gis.serializers import GeoFeatureModelSerializer

class LocationSerializer(GeoFeatureModelSerializer):

    class Meta:
        model = BoxedLocation
        geo_field = 'geometry'
        bbox_geo_field = 'bbox_geometry'
Custom GeoJSON properties source

In GeoJSON each feature can have a properties member containing the attributes of the feature. By default this field is filled with the attributes from your Django model, excluding the id, geometry and bounding box fields. It's possible to override this behaviour and implement a custom source for the properties member.

The following example shows how to use a PostgreSQL HStore field as a source for the properties member:

# models.py
class Link(models.Model):
    """
    Metadata is stored in a PostgreSQL HStore field, which allows us to
    store arbitrary key-value pairs with a link record.
    """
    metadata = HStoreField(blank=True, null=True, default=dict)
    geo = models.LineStringField()
    objects = models.GeoManager()

# serializers.py
class NetworkGeoSerializer(GeoFeatureModelSerializer):
    class Meta:
        model = models.Link
        geo_field = 'geo'
        auto_bbox = True

    def get_properties(self, instance, fields):
        # This is a PostgreSQL HStore field, which django maps to a dict
        return instance.metadata

    def unformat_geojson(self, feature):
        attrs = {
            self.Meta.geo_field: feature["geometry"],
            "metadata": feature["properties"]
        }

        if self.Meta.bbox_geo_field and "bbox" in feature:
            attrs[self.Meta.bbox_geo_field] = Polygon.from_bbox(feature["bbox"])

        return attrs

When the serializer renders GeoJSON, it calls the method get_properties for each object in the database. This function should return a dictionary containing the attributes for the feature. In the case of a HStore field, this function is easily implemented.

The reverse is also required: mapping a GeoJSON formatted structure to attributes of your model. This task is done by unformat_geojson. It should return a dictionary with your model attributes as keys, and the corresponding values retrieved from the GeoJSON feature data.

Pagination

We provide a GeoJsonPagination class.

GeoJsonPagination

Based on rest_framework.pagination.PageNumberPagination.

Code example:

from rest_framework_gis.pagination import GeoJsonPagination
# --- other omitted imports --- #

class GeojsonLocationList(generics.ListCreateAPIView):
    # -- other omitted view attributes --- #
    pagination_class = GeoJsonPagination

Example result response (cut to one element only instead of 10):

{
    "type": "FeatureCollection",
    "count": 25,
    "next": "http://localhost:8000/geojson/?page=2",
    "previous": null,
    "features": [
        {
            "type": "Feature",
            "geometry": {
                "type": "Point",
                "coordinates": [
                    42.0,
                    50.0
                ]
            },
            "properties": {
                "name": "test"
            }
        }
    ]
}

Filters

note: this feature has been tested up to django-filter 1.0.

We provide a GeometryFilter field as well as a GeoFilterSet for usage with django_filter. You simply provide, in the query string, one of the textual types supported by GEOSGeometry. By default, this includes WKT, HEXEWKB, WKB (in a buffer), and GeoJSON.

GeometryFilter

from rest_framework_gis.filterset import GeoFilterSet
from rest_framework_gis.filters import GeometryFilter
from django_filters import filters

class RegionFilter(GeoFilterSet):
    slug = filters.CharFilter(name='slug', lookup_expr='istartswith')
    contains_geom = GeometryFilter(name='geom', lookup_expr='contains')

    class Meta:
        model = Region

We can then filter in the URL, using GeoJSON, and we will perform a __contains geometry lookup, e.g. /region/?contains_geom={ "type": "Point", "coordinates": [ -123.26436996459961, 44.564178042345375 ] }.

GeoFilterSet

The GeoFilterSet provides a django_filter compatible FilterSet that will automatically create GeometryFilters for GeometryFields.

InBBoxFilter

Provides a InBBoxFilter, which is a subclass of DRF BaseFilterBackend. Filters a queryset to only those instances within a certain bounding box.

views.py:

from rest_framework_gis.filters import InBBoxFilter

class LocationList(ListAPIView):

    queryset = models.Location.objects.all()
    serializer_class = serializers.LocationSerializer
    bbox_filter_field = 'point'
    filter_backends = (InBBoxFilter,)
    bbox_filter_include_overlapping = True # Optional

We can then filter in the URL, using Bounding Box format (min Lon, min Lat, max Lon, max Lat), and we can search for instances within the bounding box, e.g.: /location/?in_bbox=-90,29,-89,35.

By default, InBBoxFilter will only return those instances entirely within the stated bounding box. To include those instances which overlap the bounding box, include bbox_filter_include_overlapping = True in your view.

Note that if you are using other filters, you'll want to include your other filter backend in your view. For example:

filter_backends = (InBBoxFilter, DjangoFilterBackend,)

TMSTileFilter

Provides a TMSTileFilter, which is a subclass of InBBoxFilter. Filters a queryset to only those instances within a bounding box defined by a TMS tile address.

views.py:

from rest_framework_gis.filters import TMSTileFilter

class LocationList(ListAPIView):

    queryset = models.Location.objects.all()
    serializer_class = serializers.LocationSerializer
    bbox_filter_field = 'point'
    filter_backends = (TMSTileFilter,)
    bbox_filter_include_overlapping = True # Optional

We can then filter in the URL, using TMS tile addresses in the zoom/x/y format, eg:. /location/?tile=8/100/200 which is equivalent to filtering on the bbox (-39.37500,-71.07406,-37.96875,-70.61261).

For more information on configuration options see InBBoxFilter.

Note that the tile address start in the upper left, not the lower left origin used by some implementations.

DistanceToPointFilter

Provides a DistanceToPointFilter, which is a subclass of DRF BaseFilterBackend. Filters a queryset to only those instances within a certain distance of a given point.

views.py:

from rest_framework_gis.filters import DistanceToPointFilter

class LocationList(ListAPIView):

    queryset = models.Location.objects.all()
    serializer_class = serializers.LocationSerializer
    distance_filter_field = 'geometry'
    filter_backends = (DistanceToPointFilter,)

We can then filter in the URL, using a distance and a point in (lon, lat) format. The distance can be given in meters or in degrees.

eg:. /location/?dist=4000&point=-122.4862,37.7694&format=json which is equivalent to filtering within 4000 meters of the point (-122.4862, 37.7694).

By default, DistanceToPointFilter will pass the 'distance' in the URL directly to the database for the search. The effect depends on the srid of the database in use. If geo data is indexed in meters (srid 3875, aka 900913), a distance in meters can be passed in directly without conversion. For lat-lon databases such as srid 4326, which is indexed in degrees, the 'distance' will be interpreted as degrees. Set the flag, 'distance_filter_convert_meters' to 'True' in order to convert an input distance in meters to degrees. This conversion is approximate, and the errors at latitudes > 60 degrees are > 25%.

DistanceToPointOrderingFilter

Provides a DistanceToPointOrderingFilter, available on Django >= 3.0, which is a subclass of DistanceToPointFilter. Orders a queryset by distance to a given point, from the nearest to the most distant point.

views.py:

from rest_framework_gis.filters import DistanceToPointOrderingFilter

class LocationList(ListAPIView):

    queryset = models.Location.objects.all()
    serializer_class = serializers.LocationSerializer
    distance_ordering_filter_field = 'geometry'
    filter_backends = (DistanceToPointOrderingFilter,)

We can then order the results by passing a point in (lon, lat) format in the URL.

eg:. /location/?point=-122.4862,37.7694&format=json will order the results by the distance to the point (-122.4862, 37.7694).

We can also reverse the order of the results by passing order=desc: /location/?point=-122.4862,37.7694&order=desc&format=json

Schema Generation

Note: Schema generation support is available only for DRF >= 3.12.

Simplest Approach would be, change DEFAULT_SCHEMA_CLASS to rest_framework_gis.schema.GeoFeatureAutoSchema:

REST_FRAMEWORK = {
    ...
    'DEFAULT_SCHEMA_CLASS': 'rest_framework_gis.schema.GeoFeatureAutoSchema',
    ...
}

If you do not want to change default schema generator class:

  • You can pass this class as an argument to get_schema_view function [Ref].
  • You can pass this class as an argument to the generateschema command [Ref].

Running the tests

Required setup

You need one of the Spatial Database servers supported by GeoDjango, and create a database for the tests.

The following can be used with PostgreSQL:

createdb django_restframework_gis
psql -U postgres -d django_restframework_gis -c "CREATE EXTENSION postgis"

You might need to tweak the DB settings according to your DB configuration. You can copy the file local_settings.example.py to local_settings.py and change the DATABASES and/or INSTALLED_APPS directives there.

This should allow you to run the tests already.

For reference, the following steps will setup a development environment for contributing to the project:

  • create a spatial database named "django_restframework_gis"
  • create local_settings.py, eg: cp local_settings.example.py local_settings.py
  • tweak the DATABASES configuration directive according to your DB settings
  • uncomment INSTALLED_APPS
  • run python manage.py syncdb
  • run python manage.py collectstatic
  • run python manage.py runserver

Using tox

The recommended way to run the tests is by using tox, which can be installed using pip install tox.

You can use tox -l to list the available environments, and then e.g. use the following to run all tests with Python 3.6 and Django 1.11:

tox -e py36-django111

By default Django's test runner is used, but there is a variation of tox's envlist to use pytest (using the -pytest suffix).

You can pass optional arguments to the test runner like this:

tox -e py36-django111-pytest -- -k test_foo

Running tests manually

Please refer to the tox.ini file for reference/help in case you want to run tests manually / without tox.

To run tests in docker use

docker-compose build
docker-compose run --rm test

Running QA-checks

Install the test requirements:

pip install -r requirements-test.txt

Reformat the code according to our coding style conventions with:

openwisp-qa-format

Run the QA checks by using

./run-qa-checks

In docker testing, QA checks are executed automatically.

Contributing

  1. Join the Django REST Framework GIS Mailing List and announce your intentions
  2. Follow the PEP8 Style Guide for Python Code
  3. Fork this repo
  4. Write code
  5. Write tests for your code
  6. Ensure all tests pass
  7. Ensure test coverage is not under 90%
  8. Document your changes
  9. Send pull request

More Repositories

1

openwisp-controller

Network and WiFi controller: provisioning, configuration management and updates, (pull via openwisp-config or push via SSH), x509 PKI management and more. Mainly OpenWRT, but designed to work also on other systems.
Python
556
star
2

ansible-openwisp2

Ansible role that installs and upgrades OpenWISP.
Python
477
star
3

openwisp-config

OpenWRT configuration agent for OpenWISP Controller
Lua
374
star
4

django-freeradius

Administration web interface and REST API for freeradius 3 build in django & python, development has moved to openwisp-radius
Python
365
star
5

openwisp-radius

Administration web interface and REST API for freeradius 3 build in django & python. Supports captive portal authentication, WPA Enerprise (802.1x), freeradius rlm_rest, social login, Hotspot 2.0 / 802.11u, importing users from CSV, registration of new users and more.
Python
363
star
6

netjsonconfig

Network configuration management library based on NetJSON DeviceConfiguration
Python
359
star
7

django-x509

Reusable django app implementing x509 PKI certificates management
Python
340
star
8

netjsongraph.js

NetJSON NetworkGraph visualizer.
JavaScript
270
star
9

django-netjsonconfig

Configuration manager for embedded devices, implemented as a reusable django-app
JavaScript
194
star
10

django-loci

Reusable Django app for storing geographic and indoor coordinates. Maintained by the OpenWISP Project.
Python
181
star
11

openwisp-network-topology

Network topology collector and visualizer. Collects network topology data from dynamic mesh routing protocols or other popular networking software like OpenVPN, allows to visualize the network graph, save daily snapshots that can be viewed in the future and more.
Python
170
star
12

openwisp-monitoring

Network monitoring system written in Python and Django, designed to be extensible, programmable, scalable and easy to use by end users: once the system is configured, monitoring checks, alerts and metric collection happens automatically.
Python
166
star
13

openwisp-users

Implementation of user management and multi-tenancy for OpenWISP
Python
163
star
14

docker-openwisp

OpenWISP in docker. For production usage we recommend using the ansible-openwisp2 role.
Python
153
star
15

django-netjsongraph

Network Topology Visualizer & Network Topology Collector
Python
141
star
16

openwisp-wifi-login-pages

Configurable captive page for public/private WiFi services providing login, sign up, social login, SMS verification, change password, reset password, change phone number and more.
JavaScript
128
star
17

ansible-openwisp2-imagegenerator

Automatically build several openwisp2 firmware images for different organizations while keeping track of their differences
Shell
120
star
18

openwisp-ipam

IP address space administration module of OpenWISP
Python
104
star
19

OpenWISP-Firmware

An OpenWRT based firmware to be used with OpenWISP Manager
Shell
86
star
20

netdiff

Python library for parsing network topology data (e.g.: OpenVPN, Wireguard, ZeroTier, NetJSON, Dynamic Routing Protocols) and detect changes.
Python
80
star
21

django-ipam

The development of this project has moved to openwisp-ipam
Python
78
star
22

openwisp-utils

Python and Django utilities shared between different openwisp modules
Python
74
star
23

django-flat-json-widget

Flat JSON widget for django, used and maintained by the OpenWISP project.
Python
64
star
24

OpenWISP-Captive-Portals-Manager

OWCPM is a captive portal written from scratch with Ruby on Rails.
Ruby
58
star
25

openwisp-firmware-upgrader

Firmware upgrade solution for OpenWRT with possibility to add support for other embedded OSes. Provides features like automatic retry for network failures, mass upgrades, REST API and more.
Python
53
star
26

openwisp-docs

OpenWISP Documentation.
Python
50
star
27

vagrant-openwisp2

Ansible Vagrant profile to install an OpenWISP 2 server
44
star
28

openwisp-notifications

Notifications module of OpenWISP
Python
41
star
29

OpenWISP-User-Management-System

OpenWISP User Management System (OWUMS) is a Ruby on Rails application, capable of managing a WISP's user base.
Ruby
40
star
30

OpenWISP-Website

OpenWISP Project's website
HTML
39
star
31

netengine

Python abstraction layer for extracting information from network devices.
Python
38
star
32

OpenWISP-Manager

The OpenWISP Manager is a RoR web GUI for configuring OpenWISP firmware-based access points.
Ruby
36
star
33

openwrt-openwisp-monitoring

OpenWRT monitoring agent for openwisp-monitoring
Lua
23
star
34

luci-openwisp

OpenWISP configuration interface implemented as LuCI extensions
HTML
20
star
35

django-owm-legacy

OpenWISP Manager backward compatible legacy features implemented in django
Python
17
star
36

OpenWISP-Geographic-Monitoring

A Rails application for managing a wISP's access points
Ruby
15
star
37

coova-chilli-openwrt

Makefile
13
star
38

openwrt-zabbixd

Ucified Zabbix Packages
Makefile
13
star
39

netjsonconfig-editor.js

[GSOC 2017] This project has stalled.
JavaScript
12
star
40

django-jsonschema-widget

JavaScript
11
star
41

OpenWISP-Middle-Ware

A Sinatra application for interconnecting OpenWISP applications via a RESTful API
Ruby
11
star
42

OpenWISP-Puppet-Modules

A set of modules and hacks for the https://openwisp.caspur.it project
HTML
10
star
43

AdaLoveBot-intents

Helping bot of the OpenWISP Chat
JavaScript
9
star
44

ansible-freeitaliawifi-login-page

Standard login page for Free ItaliaWifi federated networks
JavaScript
9
star
45

openwisp-netcheck

Shell
9
star
46

openwisp-template-library-backend

Python
8
star
47

netjson-templates

CSS
6
star
48

ansible-wireguard-openwisp

Python
6
star
49

openwisp-template-library-frontend

GSOC 19
JavaScript
6
star
50

OpenWISP-ETL

Extract Transform Load Module developed with pentaho pdi ce-5.0.1.A
6
star
51

openVPNServer

Ruby
5
star
52

openwrt-feed

DEPRECATED, work moved on OpenWisp-Firmware repo
Shell
5
star
53

ansible-openwisp-wifi-login-pages

Ansible role to deploy and manage OpenWISP WiFi Login Pages
Jinja
5
star
54

lxdock-openwisp2

This repository is only a mirror. If you want to work on it, make a fork on https://gitlab.com/openwisp/lxdock-openwisp2
5
star
55

packet-legacy

packet-legacy
Ruby
4
star
56

ansible-ow-influxdb

4
star
57

OpenWISP-BI

Business Intelligence module developed with pentaho biserver ce-4.8.0
4
star
58

openwisp-sphinx-theme

OpenWISP Sphinx Theme
CSS
3
star
59

openwisp-dev-env

Automated development environment for OpenWISP, work in progress.
3
star
60

openwisp-sentry-utils

Python
2
star
61

ansible-openwisp2-iptables

ansible role containing iptables rules to protect an openwisp2 instance
Shell
2
star