* TST: test read_postgis with NULL geometry
Though GIS databases permit NULL values in the geometry field, read_postgis throws exceptions when it encounters them.
test_read_postgis_null_geom defines this test case with sqlite3 database, and support functions are revised to support it.
create_sqlite is revised to loosen data type restrictions and follow [recommendations from the python manual](https://docs.python.org/3/library/sqlite3.html)
- connection parameter instead of filename to allow for in-memory database
- 'with' statement for transaction management
- parameter substitution instead of string operations
validate_boro_df strips NULL values before checking geometry type.
* TST: replace sqlite test with spatialite test
The original SQLite test reflected unlikely usage for geospatial analysis.
In parity with PostGIS, the new test runs against SQLite with SpatiaLite enabled.
For coverage, test geometries read as text and binary.
* TST: add libspatialite as a test dependency
* TST: add conda-forge testing environment for Python 2.7
add this environment to continuous integration
conda-forge Python 2.7 enables loadable SQLite extensions with conda-forge/python-feedstock#227
adding this environment enables SpatiaLite tests
* BUG: fix read_postgis & GeoDataFrame to accept NULL geometry values
read_postgis failed to load nullable binary geometry data while GeoDataFrame raised exceptions on NULL in the geometry field.
This fixes both issues.
It moreover adds logic to detect python version & load geometries from
python 2 buffers as necessary.
* ENH DOC: drop hex_encoded parameter from read_postgis & from_postgis
drop hex_encoded, since sqlite3 represents binary & text as distinct Python data types
adjust names to clarify this distinction
adjust documentation to clarify geometry is expected in WKB representation (which was implicit)
add example SpatiaLite usage reflecting this expectation
* Fixing minor misspelling in Contributing.md file
* Updating CONTRIBUTING file to reflect python 3.x
* Support for Python v 2.7 edits
* Consistent capitalization of Python
* Adjust python support version
* Allow to specify varying distances for buffer and interpolate
* Minor fixes in interpolate method and its test
* Verify geoseries and distance indexes are the same
* Comparison of GeoSerie and distance indexes
After further investigation, it seems like the current `read_postgis`
command would not support a spatialite database in the wild (as compared
to the one I'd created using ogr2ogr that had made me optimistic that we
had spatialite read capabilities in place). So long as it is not likely
to work for more use cases, let's leave it as `read_postgis`, since that
is all we think it is likely able to do.
YuichiNotoya