Not Logged In

django-pyodbc-gis 0.0.6

This driver implements basic GIS (geodjango) support for Microsoft SQLServer, built on top of[django-pyodbc-azure](https://github.com/michiya/django-pyodbc-azure)

It should be considered very alpha-quality at this stage! Feedback,issues, and patches are all very welcome.

# Supported and unsupported operations

Most[possible operations](https://docs.djangoproject.com/en/dev/ref/contrib/gis/geoquerysets/)are supported. The primary exceptions are those that include the boundaryitself, and convenience operations such as `left`/`right`,`overlaps_above`, etc.

In addition, for performance reasons not all geometry operations havea corresponding geography analogue. The following operations are**not** available on geography types:

* `bbcontains`, `bboverlaps`, `contained`, `crosses`, `touches`

# Limitations of SQL Server

SQL Server is OGC compliant, but does fall short of the functionalityprovided by [PostGIS](http://postgis.net/) and[Oracle Spatial](http://www.oracle.com/technetwork/database/options/spatialandgraph/overview/index.html)In particular, all of the boundary inclusion operations are missing:for example,[`contains`](https://docs.djangoproject.com/en/dev/ref/contrib/gis/geoquerysets/#contains)is supported, but not[`covers`](https://docs.djangoproject.com/en/dev/ref/contrib/gis/geoquerysets/#covers)

Type information is also slightly different in SQL Server. Instead ofkeeping the geometry type (Point, Polygon, etc) in the column'smetadata, it is a property of the *instance* (and hence so is thedimensionality), and similarly for the SRID. This means you can intheory store geometries of different types and SRIDs in the samecolumn; this driver creates a constraint to check the type, butnothing else. It also means that introspection is rather fragile.

Geometries cannot be transformed to a different SRID (such as with[`ST_Transform`](http://postgis.org/docs/ST_Transform.html) inPostGIS).

# Admin Interface

The admin interface works. This is worth noting here simply becausethe interface has to be pretend to be MySQL in order to run! Thereare some hard-coded checks for MySQL in the framework, and thelimitations (with respect to introspection) of SQL Server are actuallysimilar enough that this works for SQL Server too.

# Installation and Setup

The only direct dependency is[django-pyodbc-azure](https://github.com/michiya/django-pyodbc-azure)If you are on linux this will require installing[freetds](http://www.freetds.org/) and[odbcinst](http://www.unixodbc.org/) You will also need to[configure](http://www.unixodbc.org/doc/FreeTDS.html) it (the mostimportant is `odbcinst.ini`).

You have two options regarding specifying the host connection details;if you have configured a DSN you may omit the `HOST` key and use the`dsn` key in `OPTIONS` to specify it. If not, you will probably needto specify the TDS version in `extra_params` (if you get errormessages about[unicode](http://www.seanelavelle.com/2011/07/30/pyodbc-and-freetds-unicode-ntext-problem-solved/)you may well have gotten this wrong)

# TODO

* extended operations (gml, geojson, etc. Further investigation: SQL Server only supports GML, but treats it as an instance method where-as geodjango assumes it is a function. This might remain on the back-burner for now)* Check inspectdb support* Test suite!