Code

Opened 7 years ago

Closed 11 months ago

Last modified 11 months ago

#5472 closed New feature (fixed)

Implement Individual Map Widgets for Geometry Fields

Reported by: p Owned by: claudep
Component: GIS Version: master
Severity: Normal Keywords: openlayers javascript map maps mapping widget forms
Cc: chazen@…, dbsgeo@… Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description (last modified by jbronn)

The form provided by GeoDjango for geometry fields (django.contrib.gis.forms.fields.GeometryField) is just a simple text box that accepts textual representations of geometries. The way admin currently generates its map forms is functional, but not really suited for general-purpose use. In particular, the map widget is generated dynamically by GeoModelAdmin.get_map_widget(). For better API consistency with the rest of Django, there should be reusable map editing widgets.

Because the geographic admin already uses OpenLayers, the default widgets should be written using it. It should be general enough to make supporting alternative geometry frameworks possible, however, OpenLayers support is the priority.

Doing this will hopefully make fixing related tickets, like #9806 and #11002, easier.

Attachments (2)

olwidget_admin.diff (79.3 KB) - added by yourcelf 5 years ago.
Initial patch replacing geodjango admin with olwidget
admin_media_img_gis.tar.gz (6.2 KB) - added by yourcelf 5 years ago.
Binary media files for olwidget (they don't show up in svn diff). Place in django/contrib/admin/media/img/

Download all attachments as: .zip

Change History (26)

comment:1 Changed 7 years ago by p

  • Keywords sprintsept14 added
  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

comment:2 Changed 7 years ago by p

  • Owner changed from nobody to p

comment:3 follow-up: Changed 7 years ago by p

  • Status changed from new to assigned
  • Triage Stage changed from Unreviewed to Design decision needed

I think a design decision should be made about the inclusion of OpenLayers support, and for that matter Google Maps or Y! Maps support. It seems like these libraries should be treated the same way as Ajax support has been for Django, that is, out-of-band of the framework. It's arguable that for mapping application, a special case could be made in order to get a simple map up quickly with the KML from the models, which both GMaps and OpenLayers support. In that case, it seems a template tag may be more appropriate.

comment:4 in reply to: ↑ 3 Changed 7 years ago by jbronn

Replying to p:

It seems like these libraries should be treated the same way as Ajax support has been for Django, that is, out-of-band of the framework. It's arguable that for mapping application, a special case could be made in order to get a simple map up quickly with the KML from the models, which both !GMaps and OpenLayers support.

But we want widgets for the admin and databrowse -- how can these be supported without support for any mapping framework built-in? I agree the feature-set should be minimal but still should be present -- users may then customize and/or extend the JavaScript templates at their discretion, and widgets may be created in the admin and databrowse.

We would not be playing to Django's strength's by excluding any sort of mapping framework.

In that case, it seems a template tag may be more appropriate.

I think it will be very difficult to shoehorn all map creation options into a template tag -- it seems more appropriate to have an object with that type of detail instantiated in the views, and passed into the template.

comment:5 Changed 6 years ago by springmeyer

OpenLayers support was added as a built in feature of the admin in r7980.

Should this be closed and re-opened as a ticket for discussion how to integration the OL js into the framework outside the admin?

comment:6 Changed 5 years ago by christian@…

I'm working on a project called "OpenWebGIS" (demo:demo) and using OpenLayers to display and manage Features.
There is also a project called "olwidget".

comment:7 Changed 5 years ago by jbronn

  • Description modified (diff)
  • Keywords widget forms added; sprintsept14 removed
  • milestone set to 1.2
  • Summary changed from Add OpenLayers support to django.contrib.gis to Implement Individual Map Widgets for Geometry Fields
  • Triage Stage changed from Design decision needed to Accepted
  • Version changed from gis to SVN

comment:8 Changed 5 years ago by jbronn

  • Description modified (diff)

Changed 5 years ago by yourcelf

Initial patch replacing geodjango admin with olwidget

comment:9 Changed 5 years ago by yourcelf

  • Has patch set
  • Needs tests set

Just added an initial patch which replaces the Geodjango admin implementation with olwidget (from http://github.com/yourcelf/olwidget ), as discussed in this thread: http://groups.google.com/group/geodjango/browse_thread/thread/5cb91dd1a5867c24/62341910f188bae9

Still missing: tests, documentation, examples.

Changed 5 years ago by yourcelf

Binary media files for olwidget (they don't show up in svn diff). Place in django/contrib/admin/media/img/

comment:10 Changed 5 years ago by yourcelf

  • Cc chazen@… added

comment:11 Changed 4 years ago by yourcelf

This patch has grown stale, a lot of bugfixing has happened on the github repository for olwidget (http://github.com/yourcelf/olwidget ). I'll make a new patch here soon.

comment:12 Changed 4 years ago by springmeyer

  • Cc dbsgeo@… added

comment:13 Changed 4 years ago by ubernostrum

  • milestone 1.2 deleted

1.2 is feature-frozen, moving this feature request off the milestone.

comment:14 Changed 4 years ago by jbronn

  • milestone set to 1.3

comment:15 Changed 3 years ago by brutasse

I have a github branch that implements rich map widgets for geometry fields. It's based on the current admin implementation and the admin has been modified to use widgets from django.contrib.gis.forms.

The github branch is here: https://github.com/brutasse/django/compare/5472-map-widgets

There is also a discussion on the geodjango mailing list: http://groups.google.com/group/geodjango/browse_thread/thread/1f318cbd38411488

The implementation is complete, there is some documentation but the wording can probably be improved by a native english speaker.

I'm not sure how to test the widget functionality. Testing the rendering is easy but not very useful since it's mostly javascript code.

comment:16 Changed 3 years ago by ubernostrum

  • milestone 1.3 deleted

1.3 is feature-frozen now.

comment:17 Changed 3 years ago by gabrielhurley

  • Severity set to Normal
  • Type set to New feature

comment:18 Changed 2 years ago by aaugustin

  • UI/UX unset

Change UI/UX from NULL to False.

comment:19 Changed 2 years ago by aaugustin

  • Easy pickings unset

Change Easy pickings from NULL to False.

comment:20 Changed 13 months ago by claudep

  • Owner changed from p to claudep

I'm currently working on this issue based on floppyforms implementation. I will publish a branch as soon as something usable is ready.

comment:21 Changed 13 months ago by claudep

Branch here: https://github.com/claudep/django/tree/5472

Tests are still missing, and there are still some rough edges, but it's a start.

comment:22 Changed 13 months ago by claudep

  • Needs tests unset

I've just rebased the branch and created a pull request:
https://github.com/django/django/pull/944

Now is the time to review it!

comment:23 Changed 11 months ago by Claude Paroz <claude@…>

  • Resolution set to fixed
  • Status changed from assigned to closed

In b16b72d415808073da0418de93bf32f71ead959d:

Fixed #5472 --Added OpenLayers-based widgets in contrib.gis

Largely inspired from django-floppyforms. Designed to not depend
on OpenLayers at code level.

comment:24 Changed 11 months ago by claudep

I eventually pushed the patch. This week-end sprint might be an opportunity to fix rough edges if needed.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.