On Wed, Apr 21, 2010 at 10:29 PM, E. Antero Tammi <[email protected]> wrote: >> <skip> >> >> Hi, >> >> I recommend following a pattern like Zope's adapter instead of >> deriving from Shapely classes, and Shapely supports this pattern with >> 2 options. If your class provides either the Numpy array interface or >> the so-called "Python geo interface", you can use >> shapely.geometry.asShape to adapt your own instances without copying >> coordinate data. You might want to use Numpy anyway for your spatial >> math, so that would seem to be the better option. The same adapter >> pattern will be supported in future versions of Shapely. >> >> I'm not aware of theory or standards around 2.5D topology. I hope >> someone else will respond with good references. >> >> Cheers, >> >> -- >> Sean > > Hi, > > I will anyway use Numpy/ Scipy and it's very good feature to be able to > share directly the data with shapely. > > I did some experiments with shapely and I'll like to ask (for now), if it > would be possible: > - for the .project method to return the actual point (in LineString) as well > as its distance?
I think the API is easier to understand if methods do only one thing. We can always follow up with a call to interpolate. In many (probably most) cases, we'll know that point already. > - for the .project method to accept MultiPoints as well? And return a list of distances? I think this increases the complexity too much. Given a linestring and multipoint like >> from shapely.geometry import * >>> a = LineString(((0, 0), (10, 10))) >>> b = MultiPoint([(i, i) for i in range(11)]) it is simple to gather distances and interpolated points together like this >>> [(a.interpolate(d, True), d) for d in [a.project(p, True) for p in b]] [(<shapely.geometry.point.Point object at 0x73b570>, 0.0), (<shapely.geometry.point.Point object at 0x73b390>, 0.10000000000000001), (<shapely.geometry.point.Point object at 0x73b770>, 0.20000000000000001), (<shapely.geometry.point.Point object at 0x73b550>, 0.29999999999999999), (<shapely.geometry.point.Point object at 0x73b5b0>, 0.40000000000000002), (<shapely.geometry.point.Point object at 0x73b5d0>, 0.5), (<shapely.geometry.point.Point object at 0x73b5f0>, 0.59999999999999998), (<shapely.geometry.point.Point object at 0x73b6b0>, 0.69999999999999996), (<shapely.geometry.point.Point object at 0x73b810>, 0.80000000000000004), (<shapely.geometry.point.Point object at 0x73b830>, 0.90000000000000002), (<shapely.geometry.point.Point object at 0x73b850>, 1.0)] > - to add method .extrapolate (similar than .interpolate) but operates > outside the end points as well? > This I do like. > I do realize tough that above kind of functionality may not be relevant for > majority of shapely users. However shapely could just be the "common > denominator" for many different pythonical geometrical "packages". I do also > agree with the Zope's component philosophy, just hoping interfaces would be > part of the "official" python. > > Are there people needing/ interested of additional geometrical operations/ > primitives (on top shapely, without infering its current functionality)? If > so, perhaps we could discuss more detailed manner on the requirements. > > > Regards, > eat Good idea. PostGIS, for example, has a bunch of useful functions that are additions to the standard OGC methods. See http://www.postgis.org/docs/ch08.html. The sub-linestring function, for example, could be handy. -- Sean _______________________________________________ Community mailing list [email protected] http://lists.gispython.org/mailman/listinfo/community
