contributing olwidget to geodjango

[Charlie DeTar]

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.

http://github.com/yourcelf/olwidget

Thanks very much!
Charlie

[Adon Metcalfe]

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!).

--
Adon Metcalfe
mobile: 0429 080 931
Sent from Perth, WA, Australia

[Skylar Saveland]

+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.

[Justin Bronn]

Charlie DeTar wrote:
> Hi,

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?

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:

http://geodjango.org/hg/gis-ts/

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.
>
> http://github.com/yourcelf/olwidget

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.

-Justin

[Skylar Saveland]

Running a test on the olwidget I have:

class Geom(models.Model):
    ...
    point = models.PointField(blank=True, null=True)
    mpoint = models.MultiPointField(blank=True, null=True)
    line = models.LineStringField(blank=True, null=True)
    mline = models.MultiLineStringField(blank=True, null=True)
    poly = models.PolygonField(blank=True, null=True)
    mpoly = models.MultiPolygonField(blank=True, null=True)
    collection = models.GeometryCollectionField(blank=True, null=True)
    zoom = models.PositiveIntegerField(blank=True, null=True)
    objects = models.GeoManager()

    ...

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.

Thanks,
Skylar

[Skylar Saveland]

I suppose that I should so something lie:

    collection = forms.CharField(widget=EditableMap(
        options={'controls':['EditingToolbar'], }
    ))

but:

`` __init__() got an unexpected keyword argument 'options' ``

[Charlie DeTar]

Skylar Saveland wrote:
> I suppose that I should so something lie:
>
> collection = forms.CharField(widget=EditableMap(
> options={'controls':['EditingToolbar'], }
> ))
>
> but:
>
> `` __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

class GeomForm(forms.ModelForm):

point = forms.CharField(widget=EditableMap(options={
'geometry': 'point'
}))
mpoint = forms.CharField(widget=EditableMap(options={
'geometry': 'point',
'is_collection': True
}))
line = forms.CharField(widget=EditableMap(options={
'geometry': 'linestring'
}))
mline = forms.CharField(widget=EditableMap(options={
'geometry': 'linestring',
'is_collection': True}
))
poly = forms.CharField(widget=EditableMap(
options={'geometry': 'polygon'}
))
mpoly = forms.CharField(widget=EditableMap(options={
'geometry': 'polygon',
'is_collection': True
}))
collection = forms.CharField(widget=EditableMap(options={
'geometry': ['point', 'linestring', 'polygon'],
'is_collection': True
}))

class Meta:
model = Geom

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.

-charlie

[Skylar Saveland]

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.