GeoDjango provides some specialized form fields and widgets in order to visually\ndisplay and edit geolocalized data on a map. By default, they use\nOpenLayers-powered maps, with a base WMS layer provided by NASA.
\nIn addition to the regular form field arguments,\nGeoDjango form fields take the following optional arguments.
\nsridLink to this heading#This is the SRID code that the field value should be transformed to. For\nexample, if the map widget SRID is different from the SRID more generally\nused by your application or database, the field will automatically convert\ninput values into that SRID.
\ngeom_typeLink to this heading#You generally shouldn’t have to set or change that attribute which should\nbe set up depending on the field class. It matches the OpenGIS standard\ngeometry name.
\nmax_geom_collectionsLink to this heading#The maximum number of geometry collections the field accepts before\nrefusing to parse the input and raising a\nValidationError. This guards against crashes\nin the underlying GEOS library when parsing deeply nested\nGEOMETRYCOLLECTION input. It defaults to 198.
The limit is applied differently depending on the input format: for\nwell-known text (WKT) it bounds the nesting depth, while for well-known\nbinary (WKB and hex-encoded WKB) it bounds the total number of geometry\ncollections (both breadth and depth). As a result, the same value may\naccept a wide, shallow collection as WKT but reject it as WKB. For GeoJSON,\nthe limit is not applied at all, since GDAL parses that input type instead.
\nIncrease this value (or set to None) only if you must accept\nlegitimately deep geometries, since doing so reduces protection against\nfatal errors.
GeometryFieldLink to this heading#PointFieldLink to this heading#LineStringFieldLink to this heading#PolygonFieldLink to this heading#MultiPointFieldLink to this heading#MultiLineStringFieldLink to this heading#MultiPolygonFieldLink to this heading#GeometryCollectionFieldLink to this heading#GeoDjango form widgets allow you to display and edit geographic data on a\nvisual map.\nNote that none of the currently available widgets supports 3D geometries, hence\ngeometry fields will fallback using a Textarea widget for such data.
GeoDjango widgets are template-based, so their attributes are mostly different\nfrom other Django widget attributes.
\nThe OpenGIS geometry type, generally set by the form field.
\nSRID code used by the map (default is 4326).
\nBoolean value specifying if a textarea input showing the serialized\nrepresentation of the current geometry is visible, mainly for debugging\npurposes (default is False).
Indicates if the widget supports edition of 3D data (default is False).
The template used to render the map widget.
\nYou can pass widget attributes in the same manner that for any other Django\nwidget. For example:
\nfrom django.contrib.gis import forms\n\n\nclass MyGeoForm(forms.Form):\n point = forms.PointField(widget=forms.OSMWidget(attrs={"display_raw": True}))\nBaseGeometryWidget
This is an abstract base widget containing the logic needed by subclasses.\nYou cannot directly use this widget for a geometry field.\nNote that the rendering of GeoDjango widgets is based on a template,\nidentified by the template_name class attribute.
OpenLayersWidget
This is the default widget used by all GeoDjango form fields.\ntemplate_name is gis/openlayers.html.
OpenLayersWidget and OSMWidget use the ol.js file hosted\non the cdn.jsdelivr.net content-delivery network. You can subclass\nthese widgets in order to specify your own version of the ol.js file in\nthe js property of the inner Media class (see\nAssets as a static definition).
OSMWidget
This widget uses an OpenStreetMap base layer to display geographic objects\non. Attributes are:
\ngis/openlayers-osm.html
The default center latitude and longitude are 47 and 5,\nrespectively, which is a location in eastern France.
The default map zoom is 12.
The OpenLayersWidget note about JavaScript file hosting above also\napplies here. See also this FAQ answer about https access to map\ntiles.