I believe that olwidget, the app I've been working on to allow easy
creation of editable maps outside of geodjango admin (as well as
additional map features inside admin), is reaching a degree of
stability that it could be included in geodjango. Olwidget now
supports:
* Editable maps outside and inside of admin
* High customizability of maps, including multiple map providers,
different styles, start points, zoom levels, etc.
* Multiple geometry types per map, and geometry collection types
* Read-only geometry display maps with clickable popups
* Overview maps in the change list of admin pages to display the
geometries of all entries in the change list
If the maintainers agree, I would like to contribute patches to
include olwidget in Django. However, I have some questions regarding
how to do this:
1. Where do I submit patches? http://geodjango.org has hg
repositories, but now that it is included in Django trunk, should I
contribute patches against the Django svn instead?
2. Geodjango documentation doesn't seem to live in Django svn. Where
do I submit patches for geodjango documentation?
3. I could submit patches for olwidget either to replace the current
geoadmin implementation, or to live along side it, leaving two options
for geographic admin. What strategy would geodjango committers
prefer?
4. If I submit patches to replace the current GeoAdmin implementation,
the changes may be large enough that they warrant branching at first.
If so, would a maintainer be willing to help me get started with this?
The code currently lives on github. I'm always grateful for any
testing and feedback on it.
I second this motion! =) Specifically replacing the existing GeoAdmin
implementation.
We've been using olwidget.js fairly heavily (infact extended with a couple
of different features that aren't quite stable yet, namely a map served by a
jsonrpc callback for live updating, and a custom symboliser that renders the
externalGraphic at a rest url from a base icon drawn by PIL and an overlay
symbol placed on top, both used to make a resource tracking map), they
aren't really ready for release yet, but olwidget definitely is, especially
its improved admin maps (the changelist is awesome!).
On Sun, Sep 13, 2009 at 6:53 AM, Charlie DeTar <cha...@gmail.com> wrote:
> Hi,
> I believe that olwidget, the app I've been working on to allow easy
> creation of editable maps outside of geodjango admin (as well as
> additional map features inside admin), is reaching a degree of
> stability that it could be included in geodjango. Olwidget now
> supports:
> * Editable maps outside and inside of admin
> * High customizability of maps, including multiple map providers,
> different styles, start points, zoom levels, etc.
> * Multiple geometry types per map, and geometry collection types
> * Read-only geometry display maps with clickable popups
> * Overview maps in the change list of admin pages to display the
> geometries of all entries in the change list
> If the maintainers agree, I would like to contribute patches to
> include olwidget in Django. However, I have some questions regarding
> how to do this:
> 1. Where do I submit patches? http://geodjango.org has hg
> repositories, but now that it is included in Django trunk, should I
> contribute patches against the Django svn instead?
> 2. Geodjango documentation doesn't seem to live in Django svn. Where
> do I submit patches for geodjango documentation?
> 3. I could submit patches for olwidget either to replace the current
> geoadmin implementation, or to live along side it, leaving two options
> for geographic admin. What strategy would geodjango committers
> prefer?
> 4. If I submit patches to replace the current GeoAdmin implementation,
> the changes may be large enough that they warrant branching at first.
> If so, would a maintainer be willing to help me get started with this?
> The code currently lives on github. I'm always grateful for any
> testing and feedback on it.
+1, I'm a big fan of olwidget, especially for the front-side in my case but
also for the improved admin. From my experimentation, it allows for editing
GeometryCollectionField in the admin where as default GeoAdmin doesn't?
I'll be putting the current version of olwidget through it's paces over the
next days. I can drop notes here unless you have a preferred space.
On Sat, Sep 12, 2009 at 10:59 PM, Adon Metcalfe <adon.metca...@gmail.com>wrote:
> I second this motion! =) Specifically replacing the existing GeoAdmin
> implementation.
> We've been using olwidget.js fairly heavily (infact extended with a couple
> of different features that aren't quite stable yet, namely a map served by a
> jsonrpc callback for live updating, and a custom symboliser that renders the
> externalGraphic at a rest url from a base icon drawn by PIL and an overlay
> symbol placed on top, both used to make a resource tracking map), they
> aren't really ready for release yet, but olwidget definitely is, especially
> its improved admin maps (the changelist is awesome!).
> On Sun, Sep 13, 2009 at 6:53 AM, Charlie DeTar <cha...@gmail.com> wrote:
>> Hi,
>> I believe that olwidget, the app I've been working on to allow easy
>> creation of editable maps outside of geodjango admin (as well as
>> additional map features inside admin), is reaching a degree of
>> stability that it could be included in geodjango. Olwidget now
>> supports:
>> * Editable maps outside and inside of admin
>> * High customizability of maps, including multiple map providers,
>> different styles, start points, zoom levels, etc.
>> * Multiple geometry types per map, and geometry collection types
>> * Read-only geometry display maps with clickable popups
>> * Overview maps in the change list of admin pages to display the
>> geometries of all entries in the change list
>> If the maintainers agree, I would like to contribute patches to
>> include olwidget in Django. However, I have some questions regarding
>> how to do this:
>> 1. Where do I submit patches? http://geodjango.org has hg
>> repositories, but now that it is included in Django trunk, should I
>> contribute patches against the Django svn instead?
>> 2. Geodjango documentation doesn't seem to live in Django svn. Where
>> do I submit patches for geodjango documentation?
>> 3. I could submit patches for olwidget either to replace the current
>> geoadmin implementation, or to live along side it, leaving two options
>> for geographic admin. What strategy would geodjango committers
>> prefer?
>> 4. If I submit patches to replace the current GeoAdmin implementation,
>> the changes may be large enough that they warrant branching at first.
>> If so, would a maintainer be willing to help me get started with this?
>> The code currently lives on github. I'm always grateful for any
>> testing and feedback on it.
> 1. Where do I submit patches? http://geodjango.org has hg > repositories, but now that it is included in Django trunk, should I > contribute patches against the Django svn instead?
Mainline development occurs against SVN, and tickets/patches should be placed on the Django Trac (code.djangoproject.com). Mercurial branches are used for experimental features that have a broad scope and require extensive testing. If there's a separate branch, there are at least one or more tickets associated with it. For example, #10923 is for GEOS thread safety:
I've gone in and edited the description of ticket #5472 to be more general, and also because OpenLayers will be used for the default map widget implementation. #5472 is now officially the ticket for this feature, and I'd like to see it 1.2.
> 2. Geodjango documentation doesn't seem to live in Django svn. Where > do I submit patches for geodjango documentation?
For now, as I am the maintainer of the documentation please submit any patches directly to me. Originally, the docs got hosted in mercurial because of their rapid changes. I am in the planning stages for moving docs of prior releases into the branches on SVN (e.g., 1.1.X, and 1.0.X) but have not yet had the time.
> 3. I could submit patches for olwidget either to replace the current > geoadmin implementation, or to live along side it, leaving two options > for geographic admin. What strategy would geodjango committers > prefer?
I want to have admin use the widgets and replace the 'hacktastic' (GeoModelAdmin.get_map_widget) approach it currently takes. Thus, for the record I'm +1 on refactoring the admin to using general-purpose widgets that will live in `django.contrib.gis.forms`.
> 4. If I submit patches to replace the current GeoAdmin implementation, > the changes may be large enough that they warrant branching at first. > If so, would a maintainer be willing to help me get started with this? > The code currently lives on github. I'm always grateful for any > testing and feedback on it.
Yes. I'll take a look at the code, and whether if it's really necessary to create a mercurial branch for it. If you can come up with a patch that applies cleanly against SVN go ahead and post it to #5472 to make easier for others to review as well.
from django import forms from olwidget.widgets import EditableMap
class GeomForm(forms.ModelForm): point = forms.CharField(widget=EditableMap()) mpoint = forms.CharField(widget=EditableMap()) line = forms.CharField(widget=EditableMap()) mline = forms.CharField(widget=EditableMap()) poly = forms.CharField(widget=EditableMap()) mpoly = forms.CharField(widget=EditableMap()) collection = forms.CharField(widget=EditableMap())
class Meta: model = Geom
when I render {{form.media}} and {{form}} I end up with the widgets for a PointField() in every field. Maybe I'm missing something? In the admin, the Geom model has different widgets for each field.
> when I render {{form.media}} and {{form}} I end up with the widgets for a > PointField() in every field. Maybe I'm missing something? In the admin, > the Geom model has different widgets for each field.
> `` __init__() got an unexpected keyword argument 'options' ``
Hmmm... not sure about that error there (I can't reproduce it here -- do
you have the latest version of olwidget?). But anwyway, this is not the
way to do it. The editing toolbar used by olwidget is customized, and
not the default OpenLayers EditingToolbar, so you won't get functional
editing that way.
Since the EditableMap() constructor has no way of knowing what the
context of its use is, you need to specify the geometry that it should
use. It defaults to "point". Here's how to do your example:
from django import forms
from olwidget.widgets import EditableMap
It might be useful to have a ModelForm helper that introspects the model
and sets the appropriate geometry type for each geometric field in the
model (this is what the admin implementation does, and why you don't
have to specify geometry types per field there). I'll think about that.
> when I render {{form.media}} and {{form}} I end up with the widgets
> for a PointField() in every field. Maybe I'm missing something? In
> the admin, the Geom model has different widgets for each field.
> Hmmm... not sure about that error there (I can't reproduce it here -- do > you have the latest version of olwidget?).
I was sure that I was on HEAD but I redid everything just to make sure and it works, now I can give options to EditableMap. All is well. I think that the way you have it is fine; maybe just add a line or two to the docs.
