[geos-devel] Problems with BufferOp when using BufferParameters

[Markus Meyer]

Hi everyone,

just to let you know:

I had an interesting evening with CMake and Visual Studio and noticed 
that the test by Mateusz runs fine even with my own data. Turns out my 
problem was that I was using the build created by NMake with a Visual 
Studio 2008 project which somehow corrupted memory, even when using the 
correct C runtime library. I am now using CMake to create a .sln file 
instead and build the DLL with "shared multithreaded" runtime library 
support (which is the default in the .sln files created by CMake 
anyway). I also changed the input from a line string to a polygon, 
though I'm not sure if this still matters at all.

All in all, the buffering works without flaws now for me.

Thanks for all your support.

Best regards,
Markus

Am 28.10.2011 11:39, schrieb Markus Meyer:
> Mateusz,
>
> thanks for creating the test.
>
> Here are information about the used coordinates and the used offset 
> (dumped from the code):
>
> Coordinate #0 = 0.0, 0.0
> Coordinate #1 = 100.0, 0.0
> Coordinate #2 = 100.0, 100.0
> Coordinate #3 = 0.0, 100.0
> Coordinate #4 = 0.0, 0.0
> fOffset = 5.00
>
> Is there any chance that this problem is being fixed soon? I reviewed 
> the code myself already but so far I could not easily find the problem 
> so I would really need to debug into the code which might be rather 
> time-consuming. So I would really appreciate if someone who is 
> familiar with the inner concepts of GEOS could have a quick look at 
> the problem, especially as now there is a test case for it.
>
> Best regards,
> Markus
>
> Am 26.10.2011 20:56, schrieb Mateusz Łoskot:
>> On 26 October 2011 11:14, Markus Meyer<meyer at mesw.de>  wrote:
>>> I'm using GEOS 3.3.0 on Microsoft Visual Studio 2008 (Windows 7) for
>>> buffering lines using BufferOp.
>>>
>>> I would like to use the BufferParameters class to control extended
>>> parameters. However, it seems that I must be using the BufferOp 
>>> class the
>>> wrong way because my parameters are never accepted. To explain this, I
>>> created a simple test program which offsets a rectangle.
>>>
>>> When I do the buffering with the static function Buffer::bufferOp() the
>>> resulting geometry looks OK:
>>>
>>>     // Working code
>>>     geos::geom::Polygon* pPolygon = dynamic_cast<geos::geom::Polygon*>(
>>>         geos::operation::buffer::BufferOp::bufferOp(
>>>             pLineString, fOffset, 16,
>>>             geos::operation::buffer::BufferParameters::CAP_ROUND));
>>>
>>> When I do the buffering by using the BufferOp and BufferParameters 
>>> class
>>> directly, the resulted geometry looks very strange:
>>>
>>>     // Not working code
>>>     geos::operation::buffer::BufferParameters params(
>>>         16,
>>>         geos::operation::buffer::BufferParameters::CAP_ROUND);
>>>
>>>     geos::operation::buffer::BufferOp op(pLineString, params);
>>>     geos::geom::Polygon* pPolygon =
>>>         
>>> dynamic_cast<geos::geom::Polygon*>(op.getResultGeometry(fOffset));
>>>
>>>  From my understanding, the results of both code snipets should be 
>>> the same.
>> Markus,
>>
>> As Sandro confirmed, both ways should produce the same results.
>>
>> I have added test case that tries to reproduce your use case.
>> Here it is:
>>
>> http://trac.osgeo.org/geos/changeset/3509
>>
>> It is based on one of test geometries used across the GEOS unit tests.
>> If you can provide your geometry, it would be helpful.
>> Then we could replace the WKT input in the test and have it covered.
>>
>> Best regards,
>
> _______________________________________________
> geos-devel mailing list
> geos-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/geos-devel