[sqlalchemy] Re: postgres POLYGON data type
On Sep 17, 5:03 am, [EMAIL PROTECTED] wrote: Has anyone added support for the POLYGON data type in PostgreSQL? If so, is there any code that can be shared? I haven't seen POLYGON but the beginnings of such support is over at bycycle.org[1]. I'm interested in something similar for MySQL's spatial extensions. Has anyone done MySQL yet? Scott [1] http://bycycle.org/2007/01/29/using-postgis-with-sqlalchemy/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres POLYGON data type
On Sep 17, 3:03 pm, [EMAIL PROTECTED] wrote:
Has anyone added support for the POLYGON data type in PostgreSQL? If
so, is there any code that can be shared?
Here's a patch implementing PGPolygon. The conversion from/to python
types should be done in dbapi IMHO (i.e. psycopg2) but this will work
until it is.
Ants
PS: any idea why the google groups web api doesn't allow attaching of
files
Index: lib/sqlalchemy/databases/postgres.py
===
--- lib/sqlalchemy/databases/postgres.py(revision 3500)
+++ lib/sqlalchemy/databases/postgres.py(working copy)
@@ -140,6 +140,28 @@
def get_col_spec(self):
return self.item_type.get_col_spec() + '[]'
+class PGPolygon(sqltypes.TypeEngine):
+def dialect_imp(self, dialect):
+return self
+
+def bind_processor(self, dialect):
+def process(value):
+if value is None:
+return value
+return '(' + ','.join('(%G,%G)' % (x,y) for x,y in value)
+ ')'
+return process
+
+def result_processor(self, dialect):
+points = re.compile(r'\(([0-9.Ee]+),([0-9.Ee]+)\)')
+def process(value):
+if value is None:
+return value
+return tuple(map(lambda v:tuple(map(float, v)),
points.findall(value)))
+return process
+
+def get_col_spec(self):
+return POLYGON
+
colspecs = {
sqltypes.Integer : PGInteger,
sqltypes.Smallinteger : PGSmallInteger,
@@ -177,6 +199,7 @@
'bytea' : PGBinary,
'boolean' : PGBoolean,
'interval':PGInterval,
+'polygon': PGPolygon,
}
def descriptor():
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres POLYGON data type
sc0ttbeardsley wrote: On Sep 17, 5:03 am, [EMAIL PROTECTED] wrote: Has anyone added support for the POLYGON data type in PostgreSQL? If so, is there any code that can be shared? I haven't seen POLYGON but the beginnings of such support is over at bycycle.org[1]. I'm interested in something similar for MySQL's spatial extensions. Has anyone done MySQL yet? Just before the first 0.4 beta I started looking at adding support for the OGC types for databases that support them. The basic column plumbing in SQLAlchemy is simple- an hour's work, with unit tests- but what's less obvious is what to map those column types *to*. They could just be tuples or the like, but that didn't feel as useful as one might want. I've been idly monitoring the progress summary for the GeoDjango project to see if their efforts scare up any clear winners for python-side representation of the geometry types. They seem to be mapping to ctypes-fronted native classes, which feels like a good direction to me. What do all of you GIS folks think about the python mappings? Is there a clear approach, or would the type implementation (e.g. Point, Curve, etc.) need to be pluggable? Some specialized expression functions to make query specification smooth might also be in order. I think it would be pretty nifty to have a GeoAlchemy kind of extension or add-on that really rocks for GIS work. I haven't had cause to use geometry in database work and so my GIS experience is pretty limited, but I would be more than delighted to lend a hand if folks with working domain knowledge are also game. -j --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: postgres POLYGON data type
i don't have recent py-gis experience, but from past, its been tuple-likes and numpy arrays. Best option will be to have some default data-representation constructor for each SA-GIS type, and allow overriding that. e.g. Point holds data by default in a tuple (Point.DataHoler=tuple), but i can override Point.DataHolder=my-special-point-type and i'll get those. There might be numerous aspects to count here before choosing a representation. Even some semantix can float (e.g. is closed polygon represented as p1..pn + closed=true, or as p1..pn,p1 again), so have a clear non-twofold creation-protocol and leave actual representation to the programer. Otherwise u're stick with something half people won't like. my 2baht svilen On Monday 17 September 2007 21:59:00 jason kirtland wrote: sc0ttbeardsley wrote: On Sep 17, 5:03 am, [EMAIL PROTECTED] wrote: Has anyone added support for the POLYGON data type in PostgreSQL? If so, is there any code that can be shared? I haven't seen POLYGON but the beginnings of such support is over at bycycle.org[1]. I'm interested in something similar for MySQL's spatial extensions. Has anyone done MySQL yet? Just before the first 0.4 beta I started looking at adding support for the OGC types for databases that support them. The basic column plumbing in SQLAlchemy is simple- an hour's work, with unit tests- but what's less obvious is what to map those column types *to*. They could just be tuples or the like, but that didn't feel as useful as one might want. I've been idly monitoring the progress summary for the GeoDjango project to see if their efforts scare up any clear winners for python-side representation of the geometry types. They seem to be mapping to ctypes-fronted native classes, which feels like a good direction to me. What do all of you GIS folks think about the python mappings? Is there a clear approach, or would the type implementation (e.g. Point, Curve, etc.) need to be pluggable? Some specialized expression functions to make query specification smooth might also be in order. I think it would be pretty nifty to have a GeoAlchemy kind of extension or add-on that really rocks for GIS work. I haven't had cause to use geometry in database work and so my GIS experience is pretty limited, but I would be more than delighted to lend a hand if folks with working domain knowledge are also game. -j --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
