GeoDjango ready for merge to trunk

[Justin Bronn]

The `gis` branch, aka GeoDjango, is ready to be merged into trunk.
With Malcom's recent commits closing #7637 and #7589, there is almost
no difference between the branch and the trunk, other than the
addition of `django.contrib.gis`.

I say "almost" because my patch from #7904 is a prerequisite for
merging, as it re-enables custom managers for related field queries --
this is critical for GeoDjango on MySQL and Oracle. [1] Moreover, I
also had to add a `gis` media folder in `contrib.admin` to house a few
icons used by the geographic admin. [2] The alternative was to re-
implement a custom `AdminMediaHandler` and a `runserver` management
command, so I chose the path of least resistance.

Documentation is still sub par, but I'm actively working on updating
and transitioning the wiki docs to sphinx-enabled reST. [3] The docs
will be complete for 1.0 by September.

-Justin

[1] See also http://groups.google.com/group/django-developers/browse_thread/thread/a2326c32f8860fb0/79f346e40983a1fe
[2] http://code.djangoproject.com/browser/django/branches/gis/django/contrib/admin/media/img/gis
[3] http://geodjango.org/docs/ (source at http://geodjango.org/hg/gis-docs/)

[Malcolm Tredinnick]

On Jul 30, 10:54 am, Justin Bronn <jbr...@gmail.com> wrote:
> The `gis` branch, aka GeoDjango, is ready to be merged into trunk.
> With Malcom's recent commits closing #7637 and #7589, there is almost
> no difference between the branch and the trunk, other than the
> addition of `django.contrib.gis`.

Well done. :-)

>
> I say "almost" because my patch from #7904 is a prerequisite for
> merging, as it re-enables custom managers for related field queries --
> this is critical for GeoDjango on MySQL and Oracle. [1]

I'm happy enough with this patch. It's not an ideal solution for all
problems, but it's a reasonable path of least resistance for the
current issues.

Moreover, I
> also had to add a `gis` media folder in `contrib.admin` to house a few
> icons used by the geographic admin. [2] The alternative was to re-
> implement a custom `AdminMediaHandler` and a `runserver` management
> command, so I chose the path of least resistance.

Is #7977 something you want to complete before the merge or let it
wait. My concern there is that the patch in that ticket looks like a
bad approach: leaking information about one contrib app (gis) into
another one (admindocs) when admindocs doesn't depend on gis. It also
suggests there's a broader problem to be solved. Some way to any
external application to add field types to admin docs would seem to be
needed there. So I'd be happy enough if you wanted to punt that until
after the merge and we work out a proper solution.

Or maybe we include something like that patch for now (much as
including the icons in the admin media folder for devserver's use) and
make a note that we need a better solution for the long-term. That's
probably more in line with getting 1.0 out the door, I guess.

Anyway, I'm obviously +1 on merging this. The code is excellent,
you've worked well with the existing maintainers over the lifetime of
the branch and have actively improved the core code in the process. I
think you've achieved your goals here.

Regards,
Malcolm

[Ariel Mauricio Nunez Gomez]

Excellent,

Congrats to everyone involved. The gis branch is an very fine piece of work.

Ariel.

[alex....@gmail.com]

I think the static issue speaks to a larger issue. Applications
providing media(such as a reusable app providing a piece of
javascript), currently there isn't a good way to do this other than
moving the media to your static dir(or in this case, the admin's).

On Jul 30, 1:17 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[Malcolm Tredinnick]

On Wed, 2008-07-30 at 11:21 -0700, alex....@gmail.com wrote:
> I think the static issue speaks to a larger issue. Applications
> providing media(such as a reusable app providing a piece of
> javascript), currently there isn't a good way to do this other than
> moving the media to your static dir(or in this case, the admin's).

Yes, but it's relatively minor in the grand scheme of things. Only
affects the dev server and can be solved with a symlink when you're
developing if you need to use the dev server and do that (remembering
that the devserver takes a "document root" setting, so you only need to
symlink under a single common directory somewhere). It'd be nice to
solve this immediately, but not something we need to hold up this merge
for.

Regards,
Malcolm

[Malcolm Tredinnick]

On Wed, 2008-07-30 at 11:25 -0700, Malcolm Tredinnick wrote:
[...]

> solve this immediately, but not something we need to hold up this merge
> for.

*sigh* ...and by "immediately", I meant "eventually". I should hold a
conversation whilst writing email. :-(

Malcolm

[alex....@gmail.com]

No question, I don't have a good solution either, other than perhaps a
management command that automatically sym links media from a specific
directory to MEDIA_ROOT (similar to per-app template loading I guess).

Alex

On Jul 30, 1:25 pm, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

[mtrier]

> *sigh* ...and by "immediately", I meant "eventually". I should hold a
> conversation whilst writing email. :-(

Or possibly "shouldn't" unless you have some unique talent. :)

Michael

[Justin Bronn]

> I'm happy enough with this patch. It's not an ideal solution for all
> problems, but it's a reasonable path of least resistance for the
> current issues.

Agreed, it's a compromise for the time being.

> Is #7977 something you want to complete before the merge or let it
> wait.

It's obviously more of an annoyance than a critical bug, just
something one of our users encountered and reported; as such it can
wait until we come up with a better solution.

GeoRSS support (#6547) is a more important feature, and in a similar
predicament. Essentially, there needs to be hooks to customize the
low-level XML elements in RSS and Atom feeds so that location elements
may be inserted. At the moment, I cannot see how this could be done
without duplicating and modifying large portions of
`django.contrib.syndication`. [1] I think there's enough work on the
core devs plate for 1.0 besides rewriting syndication, so this one can
wait as well -- we've got a deadline to meet.

> Anyway, I'm obviously +1 on merging this. The code is excellent,
> you've worked well with the existing maintainers over the lifetime of
> the branch and have actively improved the core code in the process. I
> think you've achieved your goals here.

Thanks for the compliment, your support and feedback, it's been fun :)

-Justin

[1] See Robert Coup's analysis: http://code.djangoproject.com/ticket/6547#comment:5

[David Cramer]

Great work guys!

Just in time for me to build our search component ;)

Has anyone done any performance benchmarks in regards to using
GeoDjango's distance searching vs something like PostGIS, or even an
engine like Sphinx?

[Manuel Saelices]

On 30 jul, 20:28, "alex.gay...@gmail.com" <alex.gay...@gmail.com>
wrote:

> No question, I don't have a good solution either, other than perhaps a
> management command that automatically sym links media from a specific
> directory to MEDIA_ROOT (similar to per-app template loading I guess).

The main problem for that is only works in developing server. The
goodness of media content is that can be retrieve by web server like
apache without enter in python/django machinery.

But your idea is still usable with maybe a automatized way of
deploying all media directories into a single directory to the end...
something like a command or so.

Regards,
Manuel Saelices

[Jeremy Dunck]

On Wed, Jul 30, 2008 at 6:17 PM, David Cramer <dcr...@gmail.com> wrote:
> Has anyone done any performance benchmarks in regards to using
> GeoDjango's distance searching vs something like PostGIS, or even an
> engine like Sphinx?

GeoDjango with Postgres uses PostGIS as the backend.

Did you mean vs raw PostGIS queries?

I'd imagine the performance roughly equivalent because all the
marshalling from WKB to GEOS is lazy.

[springmeyer]

I could not agree more.

Congrats and thanks Justin for all your hard work.

Dane


On Jul 30, 11:19 am, "Ariel Mauricio Nunez Gomez"

<ingenieroar...@gmail.com> wrote:
> Excellent,
>
> Congrats to everyone involved. The gis branch is an very fine piece of work.
>
> Ariel.
>
> On Wed, Jul 30, 2008 at 12:54 PM, Justin Bronn <jbr...@gmail.com> wrote:
>
> > The `gis` branch, aka GeoDjango, is ready to be merged into trunk.
> > With Malcom's recent commits closing #7637 and #7589, there is almost
> > no difference between the branch and the trunk, other than the
> > addition of `django.contrib.gis`.
>
> > I say "almost" because my patch from #7904 is a prerequisite for
> > merging, as it re-enables custom managers for related field queries --
> > this is critical for GeoDjango on MySQL and Oracle. [1]  Moreover, I
> > also had to add a `gis` media folder in `contrib.admin` to house a few
> > icons used by the geographic admin. [2]  The alternative was to re-
> > implement a custom `AdminMediaHandler` and a `runserver` management
> > command, so I chose the path of least resistance.
>
> > Documentation is still sub par, but I'm actively working on updating
> > and transitioning the wiki docs to sphinx-enabled reST. [3]  The docs
> > will be complete for 1.0 by September.
>
> > -Justin
>
> > [1] See also

> >http://groups.google.com/group/django-developers/browse_thread/thread...
> > [2]
> >http://code.djangoproject.com/browser/django/branches/gis/django/cont...
> > [3]http://geodjango.org/docs/(source at
> >http://geodjango.org/hg/gis-docs/)

[Kegan]

Congrats to Justin.

Is the GeoDjango going to make it for 1.0?

~KEGan