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 -~----------~----~----~----~------~----~------~--~---
