Toward Shapely 1.1
Over the holiday I created a 1.0 branch for Shapely and began working toward Shapely 1.1. The next release will have the same API, but with some new and improved implementations of the same classes and methods, and a few new features. So far, I've managed to cut the code base by about 6% (the less code, the better, I say), not including the new tests written to get coverage to 97%:
Name Stmts Exec Cover Missing ---------------------------------------------------------------- shapely 0 0 100% shapely.array 14 12 85% 22-23 shapely.deprecation 13 13 100% shapely.factory 195 195 100% shapely.geometry 8 8 100% shapely.geometry.base 265 265 100% shapely.geometry.collection 12 8 66% 25-28 shapely.geometry.geo 48 48 100% shapely.geometry.linestring 55 55 100% shapely.geometry.multilinestring 44 44 100% shapely.geometry.multipoint 82 82 100% shapely.geometry.multipolygon 59 59 100% shapely.geometry.point 92 92 100% shapely.geometry.polygon 177 177 100% shapely.geometry.proxy 31 31 100% shapely.geos 59 32 54% 12-24, 29-38, 40, 45-51, 84, 90-91 shapely.iterops 30 30 100% shapely.ops 24 24 100% shapely.predicates 35 35 100% shapely.topology 29 29 100% shapely.wkb 22 22 100% shapely.wkt 22 22 100% ---------------------------------------------------------------- TOTAL 1316 1283 97% ---------------------------------------------------------------------- Ran 196 tests in 0.836s FAILED (errors=1, failures=1)
Feel free to grab the new code from its Subversion repository:
$ svn co http://svn.gispython.org/svn/gispy/Shapely/trunk Shapely
By the way, I've used git and git-svn exclusively for my work since the 1.0/1.1 branching, and am becoming a fan.
I remain unenthusiastic about implementing heterogeneous geometry collections. I never use them ... what am I missing?
Comments
Re: Toward Shapely 1.1
Author: Martin Daly
You will be missing completeness, and compatibility with Simple Features. For example, what is the union of a Point and a LineString, if not a GeometryCollection? You might argue that that is a poor-ish example because you can just say "I won't allow that". A better example would be the intersection between LineString-s that are colinear for some portion of their length, and cross at some other point. The result of that - according to Simple Features - is a LineString and a Point, and it would be hard to disallow intersections between LineString-s just because you don't like the resulting geometry type.Re: Toward Shapely 1.1
Author: Sean
Okay, thanks Martin. Can you think of an example of how heterogeneous geometries might be part of the same single feature (sharing the same attributes) in a GIS?Re: Toward Shapely 1.1
Author: Martin Daly
You mean something in practice, not theory? I'm out :) I can't remember having seen an example in data that we have been given. I could probably make something up, but it would be just that: made up. Of course Shapefiles have no provision for geometry collections, so they don't actually exist, right?So where's the git repo?
Author: Holger
So, where is the public git repository for all of us who don't want to have to learn yet another version control system, just to get to your subversion repo?Re: Toward Shapely 1.1
Author: Sean
No need to learn svn:
Re: Toward Shapely 1.1
Author: Sean
Alright, I'm sticking with heterogeneous collections which might be incidental products of operations, but are otherwise discouraged. And we've reached a limit of code coverage. I can only get to 100% now by fooling the test runner into believing that it's on different platforms that have or do not have numpy.