GeoAlchemy 2

[Eric Lemoine]

Hi list

This email is announcing the developement of GeoAlchemy 2. GeoAlchemy 2 is a rewrite of its predecessor; the objectives are:

- Simplify the GeoAlchemy internals by using SQLAlchemy's new features. See Mike Bayer's email [*] for more details.

- Improve the API, and provide constructs that are closer to SQLAlchemy standards.

- Support PostGIS 2.

The repository is here <https://github.com/geoalchemy/geoalchemy2/>. It contains working code, and an initial version of the documentation.

The doc is available on readthedocs: <http://geoalchemy-2.readthedocs.org>. It needs some love, but this is a start.

The current code base supports PostGIS only, and there no architecture in place for supporting other dialects. I'd be interested to know if there are people interested in adding – and maintaining – support for other dialects.

Thanks for any feedback.

[*] <https://groups.google.com/forum/m/?fromgroups#!topic/geoalchemy/k3PmQOB_FX4>

--
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.l...@camptocamp.com
http://www.camptocamp.com

[Christian Ledermann]

First of all thanks,

I tried to solve a specific problem with geoalchemy and ran into some problems,
with geoalchemy2 these have all disappeared. :)

I work with posgres 8.4, postgis 1.5, python 2.7, inside the pyramid
framework.

some observations (the SQL code was copied out of pgadmin):

For me it is very important that i can just define a column as
Geometry/Geography,
without the constraint to a specific Feature Type. a) because i have to import
lots of data from shapefiles which can consist of Polygons + MultiPolygons or
Lines + MultiLines, so being restricted to a specific feature type would be
inconvenient for me. In the future there will also be an import form KML which
can be a mix of all Types.

with geoalchemy i could define a column:

Column(name, Geometry(dim))

which resulted in the sql:
++++++++++++++++++++

CREATE TABLE seas
(
"name" character varying(100),
id character varying(16) NOT NULL,
gazetteer integer,
geom geometry,
CONSTRAINT seas_pkey PRIMARY KEY (id),
CONSTRAINT enforce_dims_geom CHECK (st_ndims(geom) = 2),
CONSTRAINT enforce_srid_geom CHECK (st_srid(geom) = 4326)
)
WITH (
OIDS=FALSE
);


CREATE INDEX idx_seas_geom
ON seas
USING gist
(geom);
-----------------------------------------------

The same defintion with geoalchemy2 throws the exception:

+++++++++++
ProgrammingError: (ProgrammingError) type modifier is not allowed for
type "geometry"
LINE 6: geom geometry(GEOMETRY,4326)
^
'\nCREATE TABLE seas2 (\n\tname VARCHAR(100), \n\tid VARCHAR(16),
\n\tgazetteer INTEGER, \n\tgeom geometry(GEOMETRY,4326)\n)\n\n' {}

----------------

It would be nice to have the geoalchemy behavior back.



If I define the geometry as:

Column(name, Geography(srid=4326, dimension=dim))

the table creation succeeds as:

++++++++++++++++++++++++
CREATE TABLE seas2
(
"name" character varying(100),
id character varying(16),
gazetteer integer,
geom geography(4326)
)
WITH (
OIDS=FALSE
);
------------------------------------------


Q: Is it by design that no spatial index gets created for geography columns?


BTW I love the to_shape, from_shape functions, a great time and effort saver!

--
Best Regards,

Christian Ledermann

Nairobi - Kenya
Mobile : +254 702978914

<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that species rely on.

3) Don’t change the climate in ways that will result in the above.

}<(((*>

[erilem]

Le mercredi 5 septembre 2012 15:30:12 UTC+2, Christian Ledermann a écrit :

First of all thanks,

I tried to solve a specific problem with geoalchemy and ran into some problems,
with geoalchemy2 these have all disappeared. :)

I work with posgres 8.4, postgis 1.5, python 2.7, inside the pyramid
framework.

some observations (the SQL code was copied out of pgadmin):

For me it is very important that i can just define a column as
Geometry/Geography,
without the constraint to a specific Feature Type. a) because i have to import
lots of data from shapefiles which can consist of Polygons + MultiPolygons or
Lines + MultiLines, so being restricted to a specific feature type would be
inconvenient for me. In the future there will also be an import form KML which
can be a mix of all Types.

with geoalchemy i could define a column:

Column(name, Geometry(dim))

I accidentally replied to this in another thread. See <https://groups.google.com/d/topic/geoalchemy/lmiMEks-Cxg/discussion>.

[erilem]

I addition, you need to call geoalchemy._setup_ddl_events() prior to creating/dropping tables when working with PostGIS < 2. See <https://github.com/elemoine/geoalchemy2/blob/master/geoalchemy2/tests/test_functional.py#L27>.


 

[erilem]

Q: Is it by design that no spatial index gets created for geography columns?

No spatial index will be created for geometry columns either. The current code just doesn't have the required logic for this. https://github.com/geoalchemy/geoalchemy/blob/master/geoalchemy/postgis.py#L138 is what's missing in GeoAlchemy 2. I'll look at adding it back - I'll need to see how to make this work with both PostGIS 1 and 2. The _setup_ddl_events is probably temporary.

Thanks for testing and reporting this issue.

[erilem]

Fixed in master.

No need to call _setup_ddl_events anymore. If you use PostGIS < 2 you need Geometry(mgmt=True) for the AddGeometryColumn and DropGeometryColumn functions to be called. And spatial indexes should now be created for Geometry columns as well as Geography columns. Please tell us if things work for you now.

[Christian Ledermann]

Thanks a lot Eric,

On Thu, Sep 6, 2012 at 1:02 AM, Eric Lemoine <eric.l...@gmail.com> wrote:
> To let you know that I've just renamed the "mgmt" option to
> "management". Sorry about that.

No worries, it has it benefits working in different timezones ;)

>
>
>
> ---------- Forwarded message ----------
> From: erilem <eric.l...@gmail.com>
> Date: Wed, Sep 5, 2012 at 11:47 PM
> Subject: Re: [GeoAlchemy] GeoAlchemy 2
> To: geoal...@googlegroups.com
>
>
>
>
> Le mercredi 5 septembre 2012 22:48:55 UTC+2, erilem a écrit :
>>
>>
>>> Q: Is it by design that no spatial index gets created for geography columns?
>>
>>
>>
>> No spatial index will be created for geometry columns either. The current code just doesn't have the required logic for this. https://github.com/geoalchemy/geoalchemy/blob/master/geoalchemy/postgis.py#L138 is what's missing in GeoAlchemy 2. I'll look at adding it back - I'll need to see how to make this work with both PostGIS 1 and 2. The _setup_ddl_events is probably temporary.
>>
>> Thanks for testing and reporting this issue.
>
>
> Fixed in master.
>
> No need to call _setup_ddl_events anymore. If you use PostGIS < 2 you
> need Geometry(mgmt=True) for the AddGeometryColumn and
> DropGeometryColumn functions to be called.

Does this mean in postgis >= 2 this is ignored? what implications
does management=True have for postgis >= 2?

> And spatial indexes should
> now be created for Geometry columns as well as Geography columns.
> Please tell us if things work for you now.

Just did a git pull, If you don't hear anything back in the next 8
hours it works for me.

>
> --
> Eric

As an aside: Would it be possible to change the _GISType
to accept a list for geometry_type? From the sql created
it looks like the type is only a constraint on the column
(I do not have deeper insights in the postgis internals
so maybe this is a stupid suggestion)

Background: If you import from shapefiles the possible
values could be (afaik): Point, [LineString, MultiLinestring],
[Polygon, MultiPolygon]

[Eric Lemoine]

>> Fixed in master.
>>
>> No need to call _setup_ddl_events anymore. If you use PostGIS < 2 you
>> need Geometry(mgmt=True) for the AddGeometryColumn and
>> DropGeometryColumn functions to be called.
>
> Does this mean in postgis >= 2 this is ignored? what implications
> does management=True have for postgis >= 2?

It should work. If management is True the geometry column will be
added using AddGeometryColumn, instead of relying on the new,
one-step, mechanism.

>
>> And spatial indexes should
>> now be created for Geometry columns as well as Geography columns.
>> Please tell us if things work for you now.
>
> Just did a git pull, If you don't hear anything back in the next 8
> hours it works for me.
>
>>
>> --
>> Eric
>
> As an aside: Would it be possible to change the _GISType
> to accept a list for geometry_type? From the sql created
> it looks like the type is only a constraint on the column
> (I do not have deeper insights in the postgis internals
> so maybe this is a stupid suggestion)

In PostGIS a Geometry or Geography column has one geometry type only,
which can be "GEOMETRY" if any geometry type can be inserted for the
column.





--
Eric

[Christian Ledermann]

On Thu, Sep 6, 2012 at 10:37 AM, Eric Lemoine <eric.l...@gmail.com> wrote:
>>> Fixed in master.
>>>
>>> No need to call _setup_ddl_events anymore. If you use PostGIS < 2 you
>>> need Geometry(mgmt=True) for the AddGeometryColumn and
>>> DropGeometryColumn functions to be called.
>>
>> Does this mean in postgis >= 2 this is ignored? what implications
>> does management=True have for postgis >= 2?
>
>
> It should work. If management is True the geometry column will be
> added using AddGeometryColumn, instead of relying on the new,
> one-step, mechanism.
>
>
>>
>>> And spatial indexes should
>>> now be created for Geometry columns as well as Geography columns.
>>> Please tell us if things work for you now.
>>
>> Just did a git pull, If you don't hear anything back in the next 8
>> hours it works for me.

Tested and confirmed working

>>
>>>
>>> --
>>> Eric
>>
>> As an aside: Would it be possible to change the _GISType
>> to accept a list for geometry_type? From the sql created
>> it looks like the type is only a constraint on the column
>> (I do not have deeper insights in the postgis internals
>> so maybe this is a stupid suggestion)
>
>
> In PostGIS a Geometry or Geography column has one geometry type only,
> which can be "GEOMETRY" if any geometry type can be inserted for the
> column.
>
>
>
>
>
> --
> Eric