GeoDjango and requirement's versions

[Volker Froehlich]

Hello!

https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#requirements lists GeoDjango's version requirements.

Fedora ships newer versions of those libraries. I was wondering whether
any incompatibility could exist:

Fedora has:

Proj 4.8
GDAL 1.9

I was also wondering about PostGIS 2.0, although there is no Fedora
package yet.

Greetings,

Volker Fröhlich
Fedora

[Chris Northwood]

On 28 May 2012 07:50, Volker Froehlich <volk...@gmx.at> wrote:
> Hello!
>
> https://docs.djangoproject.com/en/dev/ref/contrib/gis/install/#requirements lists GeoDjango's version requirements.
>
> Fedora ships newer versions of those libraries. I was wondering whether
> any incompatibility could exist:

I've been using GeoDjango on my Fedora desktop with no issues

>
> I was also wondering about PostGIS 2.0, although there is no Fedora
> package yet.

I believe PostGIS 2.0 isn't supported yet:
https://code.djangoproject.com/ticket/16455

Chris

[Anssi Kääriäinen]

On May 28, 3:14 pm, Chris Northwood <cnorthw...@gmail.com> wrote:
> I believe PostGIS 2.0 isn't supported yet:https://code.djangoproject.com/ticket/16455

I added some comments to that ticket.

I am going to hijack this thread, and ask what is the status of Oracle
and spatialite support? Anybody running tests on these backends?
spatialite seems a bit hard to install, and Oracle GIS functionality
seems to be available only in the commercial versions.

I think in the long run the requirement for any DB backend to stay in
core must be that we have a way to run tests automatically on that
backend. When working with the ORM, running tests on all backends
manually is impossible, as it takes just too much time. Especially if
you add Py3 to the mix. Currently Oracle - both gis and standard - is
missing automatic testing, and spatialite is missing too. Anybody have
the know-how to set these up? Any chance of getting another machine
with Oracle installation?

- Anssi

[Jani Tiainen]

28.5.2012 15:35, Anssi K��ri�inen kirjoitti:
> On May 28, 3:14 pm, Chris Northwood<cnorthw...@gmail.com> wrote:
>> I believe PostGIS 2.0 isn't supported yet:https://code.djangoproject.com/ticket/16455
>
> I added some comments to that ticket.
>
> I am going to hijack this thread, and ask what is the status of Oracle
> and spatialite support? Anybody running tests on these backends?
> spatialite seems a bit hard to install, and Oracle GIS functionality
> seems to be available only in the commercial versions.
>

Oracle has two different GIS functionalities Locator and Spatial.
Locator is available for free and is subset of Spatial functionality.

Stupid thing is that you get full Spatial installed and you just have to
know which feature belongs to what version. Top of that features
included in Locator varies between Oracle versions.

Most of the GeoDjango functionality works with Locator features - I
don't recall but I think there was a ticket about features only in
Spatial and those would be Documented.

Oracle tests are slow for some reason and personally I don't think I've
run full suite of spatial tests on it ever. (Though I just use
GeoDjango, not develop it actively)

> I think in the long run the requirement for any DB backend to stay in
> core must be that we have a way to run tests automatically on that
> backend. When working with the ORM, running tests on all backends
> manually is impossible, as it takes just too much time. Especially if
> you add Py3 to the mix. Currently Oracle - both gis and standard - is
> missing automatic testing, and spatialite is missing too. Anybody have
> the know-how to set these up? Any chance of getting another machine
> with Oracle installation?

Setting automated tests shouldn't be a problem - I think problem is that
to actually to be able to test you would need real Oracle server - and
that costs money.

--
Jani Tiainen

- Well planned is half done and a half done has been sufficient before...

[Anssi Kääriäinen]

On May 29, 10:50 am, Jani Tiainen <rede...@gmail.com> wrote:
> 28.5.2012 15:35, Anssi K ri inen kirjoitti:
>
> > On May 28, 3:14 pm, Chris Northwood<cnorthw...@gmail.com>  wrote:
> >> I believe PostGIS 2.0 isn't supported yet:https://code.djangoproject.com/ticket/16455
>
> > I added some comments to that ticket.
>
> > I am going to hijack this thread, and ask what is the status of Oracle
> > and spatialite support? Anybody running tests on these backends?
> > spatialite seems a bit hard to install, and Oracle GIS functionality
> > seems to be available only in the commercial versions.
>
> Oracle has two different GIS functionalities Locator and Spatial.
> Locator is available for free and is subset of Spatial functionality.
>
> Stupid thing is that you get full Spatial installed and you just have to
> know which feature belongs to what version. Top of that features
> included in Locator varies between Oracle versions.
>
> Most of the GeoDjango functionality works with Locator features - I
> don't recall but I think there was a ticket about features only in
> Spatial and those would be Documented.
>
> Oracle tests are slow for some reason and personally I don't think I've
> run full suite of spatial tests on it ever. (Though I just use
> GeoDjango, not develop it actively)

OK. I see Locator is in XE. Does the above mean that if I run gis test
on XE and those happen to use features from Spatial, then I am in
breach of their license? If so, I will not touch Oracle GIS
functionality.

> > I think in the long run the requirement for any DB backend to stay in
> > core must be that we have a way to run tests automatically on that
> > backend. When working with the ORM, running tests on all backends
> > manually is impossible, as it takes just too much time. Especially if
> > you add Py3 to the mix. Currently Oracle - both gis and standard - is
> > missing automatic testing, and spatialite is missing too. Anybody have
> > the know-how to set these up? Any chance of getting another machine
> > with Oracle installation?
>
> Setting automated tests shouldn't be a problem - I think problem is that
> to actually to be able to test you would need real Oracle server - and
> that costs money.

I am running tests on XE on my local machine. We once had XE available
in automatic testing, too, but the installation somehow corrupted and
we don't have that anymore. The experience has been that XE is
somewhat picky about its installation environment, and once something
goes wrong it is very hard to fix. As far as I know Oracle XE
installation is all we need, and is free for our use case, but we
don't have even that.

- Anssi

[Jani Tiainen]

Well you can't run GeoDjango on XE. Problem is that GeoDjango uses
to/from WKT utility methods/functions and those don't work without
database Java engine - and that does only exists in Oracle Standard
edition and upwards.

And yes, if you use features from Spatial without proper license you (at
least at some point ) breach it.

But since I'm not a lawyer I'm not sure what following clause will
cover: "All software downloads are free, and most come with a Developer
License that allows you to use full versions of the products at no
charge while developing and prototyping your applications, or for
strictly self-educational purposes."

Excerpt from Developer License [1]:

"LICENSE RIGHTS
We grant you a nonexclusive, nontransferable limited license to use the
programs only for the purpose of developing, testing, prototyping and
demonstrating your application, and not for any other purpose. If you
use the application you develop under this license for any internal data
processing or for any commercial or production purposes, or you want to
use the programs for any purpose other than as permitted under this
agreement, you must obtain a production release version of the program
by contacting us or an Oracle reseller to obtain the appropriate
license. You acknowledge that we may not produce a production release
version of the program and any development efforts undertaken by you are
at your own risk. We may audit your use of the programs. Program
documentation, if available, may accessed online at "

Maybe someone should ask from Oracle support about legal advice.

>>> I think in the long run the requirement for any DB backend to stay in
>>> core must be that we have a way to run tests automatically on that
>>> backend. When working with the ORM, running tests on all backends
>>> manually is impossible, as it takes just too much time. Especially if
>>> you add Py3 to the mix. Currently Oracle - both gis and standard - is
>>> missing automatic testing, and spatialite is missing too. Anybody have
>>> the know-how to set these up? Any chance of getting another machine
>>> with Oracle installation?
>>
>> Setting automated tests shouldn't be a problem - I think problem is that
>> to actually to be able to test you would need real Oracle server - and
>> that costs money.
>
> I am running tests on XE on my local machine. We once had XE available
> in automatic testing, too, but the installation somehow corrupted and
> we don't have that anymore. The experience has been that XE is
> somewhat picky about its installation environment, and once something
> goes wrong it is very hard to fix. As far as I know Oracle XE
> installation is all we need, and is free for our use case, but we
> don't have even that.

From my experience *nix installations (except RHEL/Centos
distributions) of Oracle (XE) is quite painful, but Windows
installations goes pretty much without a pain.

> - Anssi
>


[1] http://www.oracle.com/technetwork/licenses/standard-license-152015.html

[Matthias Runge]

> Volker Fr�hlich
> Fedora
>
Has anybody tested GDAL 1.9 or Proj 4.8? I've seen, ubuntu uses GDAL 1.7
(and gdal 1.9 for the next release). Is there any known test case to
check, if geodjango works with proj 4.8 and/or GDAL 1.9?

Thanks,
Matthias
--
Matthias Runge <mru...@matthias-runge.de>
<mru...@fedoraproject.org>

[Václav Řehák]

> Has anybody tested GDAL 1.9 or Proj 4.8? I've seen, ubuntu uses GDAL 1.7
> (and gdal 1.9 for the next release). Is there any known test case to
> check, if geodjango works with proj 4.8 and/or GDAL 1.9?

I haven't tested myself but the chances are high that some tweaks are
needed as contrib.gis application in Django has some hardcoded
versions of libgdal: https://github.com/django/django/blob/master/django/contrib/gis/gdal/libgdal.py

If you have the environment to test it would be beneficial to try to
run the test suite with different databases and reported bugs. See
https://docs.djangoproject.com/en/dev/internals/contributing/writing-code/unit-tests/

Vaclav

[Volker Froehlich]

I ran (some?) Geodjango tests with:

Django 1.4
GDAL 1.9.1
GEOS 3.2.2
PostGIS 1.5.3
Proj 4.7.0
Libspatialite 2.4.0-RC4

I used settings like described here:

https://docs.djangoproject.com/en/dev/ref/contrib/gis/testing/#geodjango-tests

$ python manage.py test --settings=postgis

Can you please look through the results? Do I need to run further tests
than that?

Volker



Creating test database for alias 'default'...
.....
BEGIN - expecting GEOS_ERROR; safe to ignore.

GEOS_ERROR: ParseException: Expected number but encountered ','
GEOS_ERROR: ParseException: Unknown WKB type 255
GEOS_ERROR: ParseException: Unexpected EOF parsing WKB

END - expecting GEOS_ERROR; safe to ignore.

.....F........
BEGIN - expecting GEOS_NOTICE; safe to ignore.

GEOS_NOTICE: Duplicate Rings at or near point 60 300

END - expecting GEOS_NOTICE; safe to ignore.

.....................
BEGIN - expecting Warnings; safe to ignore.

/usr/lib/python2.7/site-packages/django/contrib/gis/geos/tests/test_geos.py:907: UserWarning: Calling transform() with no SRID set does no transformation!
g.transform(2774)
/usr/lib/python2.7/site-packages/django/contrib/gis/geos/tests/test_geos.py:907: FutureWarning: Calling transform() with no SRID will raise GEOSException in v1.5
g.transform(2774)

END - expecting Warnings; safe to ignore.

.....
BEGIN - expecting GEOS_NOTICE; safe to ignore.

GEOS_NOTICE: Too few points in geometry component at or near point 0 0

END - expecting GEOS_NOTICE; safe to ignore.

.............................................................
BEGIN - expecting out of range feature id error; safe to ignore.

ERROR 1: Attempt to read shape with feature id (50000) out of available
range.
ERROR 1: Attempt to read shape with feature id (50000) out of available
range.

END - expecting out of range feature id error; safe to ignore.
....F..................F......
BEGIN - expecting IllegalArgumentException; safe to ignore.

ERROR 1: IllegalArgumentException: Points of LinearRing do not form a
closed linestring

END - expecting IllegalArgumentException; safe to ignore.

...........................................................................................................................F..........
======================================================================
FAIL: test01i_json
(django.contrib.gis.geos.tests.test_geos.GEOSTest)
Testing GeoJSON input/output (via
GDAL).
----------------------------------------------------------------------
Traceback (most recent call
last):
File
"/usr/lib/python2.7/site-packages/django/contrib/gis/geos/tests/test_geos.py", line 200, in test01i_json
self.assertEqual(g.json,
geom.json)
AssertionError: '{ "type": "Point", "coordinates": [ 100.000000,
0.000000 ] }' != '{ "type": "Point", "coordinates": [ 100.0, 0.0
] }'

======================================================================
FAIL: test05_geometries
(django.contrib.gis.gdal.tests.test_ds.DataSourceTest)
Testing Geometries from Data Source
Features.
----------------------------------------------------------------------
Traceback (most recent call
last):
File
"/usr/lib/python2.7/site-packages/django/contrib/gis/gdal/tests/test_ds.py", line 184, in test05_geometries
self.assertEqual(source.srs_wkt,
g.srs.wkt)
AssertionError:
'GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]' != 'GEOGCS["GCS_WGS_1984",DATUM["WGS_1984",SPHEROID["WGS_84",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]'

======================================================================
FAIL: test01e_json
(django.contrib.gis.gdal.tests.test_geom.OGRGeomTest)
Testing GeoJSON
input/output.
----------------------------------------------------------------------
Traceback (most recent call
last):
File
"/usr/lib/python2.7/site-packages/django/contrib/gis/gdal/tests/test_geom.py", line 115, in test01e_json
self.assertEqual(g.json,
geom.json)
AssertionError: '{ "type": "Point", "coordinates": [ 100.000000,
0.000000 ] }' != '{ "type": "Point", "coordinates": [ 100.0, 0.0 ] }'

======================================================================
FAIL: test_time_field
(django.contrib.gis.tests.inspectapp.tests.OGRInspectTest)
----------------------------------------------------------------------
Traceback (most recent call last):
File
"/usr/lib/python2.7/site-packages/django/contrib/gis/tests/inspectapp/tests.py", line 87, in test_time_field
self.assertEqual(model_def, '\n'.join(expected))
AssertionError: '# This is an auto-generated Django model module created
by ogrinspect.\nfrom django.contrib.gis.db import models\n\nclass
Measurement(models.Model):\n f_decimal =
models.DecimalField(max_digits=0, decimal_places=0)\n f_float =
models.FloatField()\n f_int = models.IntegerField()\n f_char =
models.CharField(max_length=10)\n f_date = models.DateField()\n
f_datetime = models.DateTimeField()\n f_time = models.TimeField()\n
geom = models.PolygonField()\n objects = models.GeoManager()' != '#
This is an auto-generated Django model module created by
ogrinspect.\nfrom django.contrib.gis.db import models\n\nclass
Measurement(models.Model):\n f_decimal =
models.DecimalField(max_digits=0, decimal_places=0)\n f_int =
models.IntegerField()\n f_datetime = models.DateTimeField()\n
f_time = models.TimeField()\n f_float = models.FloatField()\n
f_char = models.CharField(max_length=10)\n f_date =
models.DateField()\n geom = models.PolygonField()\n objects =
models.GeoManager()'

----------------------------------------------------------------------
Ran 270 tests in 11.068s

FAILED (failures=4)
Destroying test database for alias 'default'...