Geometry sequence as features

[perrygeo]

This PR allows @features_in_arg to take a sequence of geometry objects on stdin and casts them to features with empty properties.

Resolves #13

[sgillies]

return 'coordinates' in obj is the way to go here, yes?

[perrygeo]

Yeah, return <boolean expression> is definitely the way to go.

In terms of 'coordinates' in obj vs coordinates in obj.keys(): I prefer the explicit call to the keys method because it enforces that the object is a mapping and won't match this is a geometry just because it has coordinates in the string.

[sgillies]

Yes, but check out the performance hit from calling keys():

>>> timeit.timeit(stmt="'coordinates' in obj", setup="obj={'coordinates': [0, 0]}")
0.04499248508363962
>>> timeit.timeit(stmt="'coordinates' in obj.keys()", setup="obj={'coordinates': [0, 0]}")
0.12553653097711504

[perrygeo]

So if is_geometry was intended to be a reusable public function, I'd want to assert that it was a mapping with a coordinate key, not a string containing "coordinate". However, this is more of a private utility function to make the code read better. Should we just inline 'coordinates' in obj and forget the function?

[sgillies]

@perrygeo yes to that.

[perrygeo]

I had to resolve some merge conflicts and take a slightly different approach.

@sgillies 👀 ?

[sgillies]

@perrygeo I've got no immediate use for what I'm about to suggest: but what about adding a properties keyword argument to this function, the value of which would be copied to the result's properties member?

[perrygeo]

Could we punt on that and cover that use case with a more general tool like the proposed fio calc?

[perrygeo]

@sgillies anything need to move on this before merging?