Aron,
I like it. We could consider collecting the methods into simplify with
a preserve keyword option?
def simplify(self, tolerance, preserve_topology=False):
if preserve_topology:
...
else:
...
The question then is whether the default is to preserve or not.
On Nov 10, 2009, at 5:26 AM, Aron Bierbaum wrote:
> Sounds good to me. I have added two methods, simplify and
> topology_preserve_simplify to the base geometry class in r1493. I
> wasn't sure about the naming of the methods. The second method is a
> little long, and I would normally use camel case, but I think this is
> the Shapely standard. Please correct me if this is wrong though. I
> copied a few of the tests from GEOS and they seem to work fine. Is
> this what you were thinking for support in 1.2? I would agree that in
> 2.0 we could add something better since it might not be a OGC
> standard. This should allow people to start using it though.
>
> -Aron
>
> On Mon, Nov 9, 2009 at 2:13 PM, Sean Gillies
> <[email protected]> wrote:
>> On Nov 9, 2009, at 7:43 PM, Helge Jensen wrote:
>>
>>> I am doing simplification of polygons for storage and calculation
>>> efficiency. and would like to do polygon-simplification.
>>>
>>> Currently I use the postgis function ST_SimplifyPreserveTopology to
>>> do the
>>> simplification, however the dataset is growing large and I would
>>> like to
>>> move the pre-processing away from the database which should be busy
>>> answering real-time queries.
>>>
>>> I am already doing pre-processing (parsing from list(x,y,level),
>>> rasterisation and polygonization) in python (and distributed too,
>>> thanks to
>>> the new multiprocessing module).
>>>
>>> So, I spotted the shapely bindings for GEOS, and the thread
>>> http://www.mail-archive.com/[email protected]/msg00510.htmlwhich
>>> indicated that a Douglas-Peucker variant was easily accessible for
>>> me
>>> and my pre-processing code.
>>>
>>> However I have checked out the trunk and not been able to "from
>>> shapely.geos.ops import simplify", or even find the shapely.geos.ops
>>> module
>>
>> Hi,
>>
>> In that email, I'd suggested that in the trunk I *might* move the
>> simplify method to a function in an ops module, or provide a
>> complementary function. The work hasn't been done yet.
>>
>> Instead of using the trunk, I strongly recommend trying the 1.2
>> branch. Aron Bierbaum has put a lot of work into it, tests are
>> passing, and I think we're pretty close to where we can start to
>> consider a preview release. A geometry simplify method or its
>> functional counterpart isn't implemented there yet, but wouldn't be
>> much work, and would be a lot closer to being deployable than the
>> Shapely trunk.
>>
>> http://svn.gispython.org/svn/gispy/Shapely/branches/1.2
>>
>> Aron, what do you think about simplification for 1.2?
>>
>> --
>> Sean Gillies
>> Programmer
>> Institute for the Study of the Ancient World
>> New York University
>>
>> _______________________________________________
>> Community mailing list
>> [email protected]
>> http://lists.gispython.org/mailman/listinfo/community
>>
> _______________________________________________
> Community mailing list
> [email protected]
> http://lists.gispython.org/mailman/listinfo/community
--
Sean
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
