Re: [Jts-topo-suite-user] Issue with BufferBuilder.buffer
Brought to you by:
dr_jts
Menu
▾
▴
Re: [Jts-topo-suite-user] Issue with BufferBuilder.buffer
|
From: Martin D. <mtn...@te...> - 2011-12-08 06:06:03
|
The fact that buffer always returns polygons as output is not a bug -
it's an intentional feature of the algorithm design.
The algorithm(s) to compute skeletons (either the true medial axis, or
the alternative straight skeleton) are at least as complex as the
current buffer algorithm (and unfortunately have nothing in common with
it). I don't have any plans to work on this for JTS in the near future.
You might try searching around on the Web for an appropriate algorithm
with code. Good luck!
On 12/7/2011 1:46 AM, Anders Johansson wrote:
> Hi,
> It was not my intention to start a semantic debate, even though I
> understand that it is important
> in other aspects. If the result of the offset operation
> had been a line or a point or anything else than a polygon I would
> have been satisfied. The problem is that
> the result was a polygon, with an area. Which isn't at all what I
> expected, and I don't know a work around. Do you have
> any idea when this bug might be fixed, or do you know a work around?
> Unfortunately, my use case encounters this
> issue quite often :(
>
> /Anders
>
>
> On Tue, Nov 29, 2011 at 10:52 PM, Martin Davis<mtn...@gm...> wrote:
>
>> The OGC specs don't say much about buffer semantics. The concept of large
>> inside buffers of polygons being empty is mine. It also (not
>> coincidentally) matches well with the implementation algorithm used in JTS.
>>
>> Computing skeletons of polygons is a different (and probably more complex)
>> algorithm.
>>
>> Personally I'm quite happy with the current semantics - but then I'm pretty
>> used to thinking that way.
>>
>> m
>>
>>
>> On Tue, Nov 29, 2011 at 12:24 PM, Stefan Steiniger<ss...@ge...>
>> wrote:
>>> mhm.. ok, yeah, makes sense for consistency.
>>>
>>> However, I agree only partly. From my (morphology) perspective I actually
>>> would assume that a line would be left (skeleton) - and for circles a single
>>> point (center point). But well, developing such a geometry type change isn't
>>> a piece of cake.
>>>
>>> I used for that bug (in case it can be considered one) a check for the
>>> returned area/polygon size. And if it is zero.. well then I know that its
>>> "empty".
>>>
>>> but that my personal 2 cents. Don't know if the OGC specs say anything on
>>> that?
>>>
>>> stefan
>>>
>>>
>>> On 29/11/2011 1:05 PM, Martin Davis wrote:
>>>
>>> Ok, Anders, I see your issue now. Yes, you're right - with the given
>>> buffer distance the result of inside buffering the polygon should be empty.
>>> This is a bug.
>>>
>>> I don't have an ETA on fixing it at the moment.
>>>
>>> On Tue, Nov 29, 2011 at 11:27 AM, Anders Johansson
>>> <and...@gm...> wrote:
>>>> I expect it to be empty since the offset chosen should, according to
>>>> me, eat up all the inside and even more.
>>>>
>>>> /Anders
>>>>
>>>> On Tue, Nov 29, 2011 at 6:58 PM, Stefan Steiniger<ss...@ge...>
>>>> wrote:
>>>>> Hi Anders,
>>>>>
>>>>> if you buffer a polygon "inwards" (which is what the minus does).
>>>>> Why would you expect it to be empty?
>>>>>
>>>>> For me this is actually one of the great features of JTS, because it
>>>>> allows to do morphological operations on polygons.
>>>>>
>>>>> stefan
>>>>>
>>>>> On 29/11/2011 5:06 AM, Anders Johansson wrote:
>>>>>> Hi,
>>>>>> I have encountered an issue with BufferBuilder.buffer. I want to
>>>>>> compute the inner offset
>>>>>> of a polygon and I expect the result to be empty.
>>>>>> BufferBuilder.buffer, however, returns a polygon. What more,
>>>>>> buffer behaves differently depending on the type of the argument,
>>>>>> which I believe is inconsistent.
>>>>>> Here is the code that reproduces it:
>>>>>>
>>>>>> package foo;
>>>>>>
>>>>>> import com.vividsolutions.jts.geom.Coordinate;
>>>>>> import com.vividsolutions.jts.geom.GeometryFactory;
>>>>>> import com.vividsolutions.jts.geom.LinearRing;
>>>>>> import com.vividsolutions.jts.operation.buffer.BufferBuilder;
>>>>>> import com.vividsolutions.jts.operation.buffer.BufferParameters;
>>>>>>
>>>>>> public class Bar
>>>>>> {
>>>>>> static public void main(String[] args)
>>>>>> {
>>>>>> final GeometryFactory geometryFactory = new
>>>>>> GeometryFactory();
>>>>>> final double offset = -0.184;
>>>>>> final BufferBuilder bufferBuilder = new BufferBuilder(new
>>>>>> BufferParameters());
>>>>>>
>>>>>> Coordinate[] coordinates = new Coordinate[]{new
>>>>>> Coordinate(0.28, 0.38),
>>>>>> new
>>>>>> Coordinate(0.41, 0.21),
>>>>>> new
>>>>>> Coordinate(0.13, 0.0),
>>>>>> new
>>>>>> Coordinate(0.0, 0.16),
>>>>>> new
>>>>>> Coordinate(0.28, 0.38)};
>>>>>>
>>>>>> LinearRing linearRing =
>>>>>> geometryFactory.createLinearRing(coordinates);
>>>>>> com.vividsolutions.jts.geom.Polygon polygon =
>>>>>> geometryFactory.createPolygon(linearRing, new LinearRing[]{});
>>>>>>
>>>>>> // Succeeds expectedly
>>>>>> assert
>>>>>> bufferBuilder.buffer(geometryFactory.createLinearRing(polygon.getCoordinates()),
>>>>>> offset).isEmpty();
>>>>>>
>>>>>> // Succeeds expectedly
>>>>>> assert bufferBuilder.buffer(linearRing, offset).isEmpty();
>>>>>>
>>>>>> // Fails unexpectedly. Isn't this result inconsistent with
>>>>>> the others?
>>>>>> assert bufferBuilder.buffer(polygon, offset).isEmpty();
>>>>>> }
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Thanks in advance!
>>>>>>
>>>>>> /Anders
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> All the data continuously generated in your IT infrastructure
>>>>>> contains a definitive record of customers, application performance,
>>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>>> data and makes sense of it. IT sense. And common sense.
>>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>>> _______________________________________________
>>>>>> Jts-topo-suite-user mailing list
>>>>>> Jts...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> All the data continuously generated in your IT infrastructure
>>>>> contains a definitive record of customers, application performance,
>>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>>> data and makes sense of it. IT sense. And common sense.
>>>>> http://p.sf.net/sfu/splunk-novd2d
>>>>> _______________________________________________
>>>>> Jts-topo-suite-user mailing list
>>>>> Jts...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>>>
>>>> ------------------------------------------------------------------------------
>>>> All the data continuously generated in your IT infrastructure
>>>> contains a definitive record of customers, application performance,
>>>> security threats, fraudulent activity, and more. Splunk takes this
>>>> data and makes sense of it. IT sense. And common sense.
>>>> http://p.sf.net/sfu/splunk-novd2d
>>>> _______________________________________________
>>>> Jts-topo-suite-user mailing list
>>>> Jts...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> All the data continuously generated in your IT infrastructure
>>> contains a definitive record of customers, application performance,
>>> security threats, fraudulent activity, and more. Splunk takes this
>>> data and makes sense of it. IT sense. And common sense.
>>> http://p.sf.net/sfu/splunk-novd2d
>>>
>>>
>>>
>>> _______________________________________________
>>> Jts-topo-suite-user mailing list
>>> Jts...@li...
>>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure
>> contains a definitive record of customers, application performance,
>> security threats, fraudulent activity, and more. Splunk takes this
>> data and makes sense of it. IT sense. And common sense.
>> http://p.sf.net/sfu/splunk-novd2d
>> _______________________________________________
>> Jts-topo-suite-user mailing list
>> Jts...@li...
>> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>>
> ------------------------------------------------------------------------------
> Cloud Services Checklist: Pricing and Packaging Optimization
> This white paper is intended to serve as a reference, checklist and point of
> discussion for anyone considering optimizing the pricing and packaging model
> of a cloud services business. Read Now!
> http://www.accelacomm.com/jaw/sfnl/114/51491232/
> _______________________________________________
> Jts-topo-suite-user mailing list
> Jts...@li...
> https://lists.sourceforge.net/lists/listinfo/jts-topo-suite-user
>
>
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 2012.0.1873 / Virus Database: 2102/4660 - Release Date: 12/06/11
>
>
>
|