[OpenJDK 2D-Dev] <AWT Dev> Question: Area changes order of points

[Hruda, Steve]

Hi Jim,
thank you for the insides!

We implemented a renderer which uses the OGC Symbology Encoding definition to style geometries and a polygon will not only stroke, it can also be filled.
I removed the code which clips the geometry by using the area, to avoid your mentioned issues.

And yes the reason for that was to avoid the decoration-process outside of the clip.

In addition one of our developer (before my time ;-) ) solved printing problems. The colleagues  told me that big polygons like country frontiers produced line-fragments and the clipping of the geometries solved that issue. I wasn't able to reproduce that issue. Maybe this issue is already solved or it doesn't occur since we forced the print engine to use the raster pipeline.

Best Regards,
Steve




Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H.
Vertretungsberechtigte Geschäftsführer: Maximilian Weber
Sitz der Gesellschaft: Margaretenstraße 70/I/1, 1050 Wien, Österreich, Tel. +43 (1) 9610567-0
Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN 116859 b
Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401, Steuer-Nummer: 264/4807

This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H.
Authorised Managing Directors: Maximilian Weber
Registered office and Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel. +43 (1) 9610567-0
The company is recorded at the commercial court of Vienna under the company register number FN 116859 b
VAT-ID: ATU15138401, Austrian Tax ID: 264/4807

Diese E-Mail (mit zugehörigen Dateien) enthält möglicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Geschäftsgeheimnis darstellen. Falls Sie diese Nachricht irrtümlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und löschen Sie bitte diese E-Mail und Ihre Antwort darauf. Sämtliche aufgeführten Ansichten oder Meinungen sind ausschließlich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph.

This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph.


-----Original Message-----
From: Jim Graham [mailto:james.graham at oracle.com]
Sent: Thursday, October 8, 2015 12:32 AM
To: Hruda, Steve <steve.hruda at hexagongeospatial.com>
Cc: 2d-dev <2d-dev at openjdk.java.net>
Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> Question: Area changes order of points

Note that "Area" is specifically targeted to processing areas, not outlines.  While it does express its answer in the form of an outline, on the other hand the information it is processing, operating on, and representing internally is areas, not outlines.  It's output is intended only for filling, not for stroking.  You can stroke its output because the graphics system allows you to stroke any path, but the Area class wasn't concerned at all about stroking issues (such as path direction) during its internal operations.

If you are simply trying to simplify the polygon to throw out unnecessary segments to simplify rendering then the Area class is not designed or optimized to address your needs.  Additionally, it is doing way more work than your application needs and writing your own implementation may perform better.

Also, Area will perform optimizations that you don't want such as removing an interior segment that does not contribute to the boundary between interior and exterior.  Such segments are superfluous for filling, but might be visible when stroking.  The Area class won't care and will just delete them all the same because it only cares about areas internally.

Another issue to consider is that if you have arrows or other periodic decorations then removing segments will mean that those decorations will shift their locations.  The length of the omitted path must be considered while computing where the decorations are placed, but if you pre-edit the path to remove them then those lengths cannot be computed.

Out of curiosity, are you trying to clip these paths to avoid having to process decorations on parts of the path that are far outside of the clip?  We've recently discussed that performance issue internally in the Graphics-Rasterizer project and noted that it is an opportunity for future performance work...

                        ...jim

On 10/7/15 12:37 AM, Hruda, Steve wrote:
> Hi Jim,
> we are using the Area to clip/intersect geometries like a polygon. Such a polygon has a digitizing direction and this direction has an effect on the point order.
>
> If we visualize a clipped polygon in our map, than we have the problem that complex line styles like a placed graphic along a line e.g. an arrow, shows in the wrong direction.
>
> Thanks for the explanation Jim, I will consider the point-order manipulation in our application.
>
> Regards,
> Steve
>
>
>
>
> Diese E-Mail wurde versandt im Auftrag des Unternehmens Intergraph Ges.m.b.H.
> Vertretungsberechtigte Geschäftsführer: Maximilian Weber Sitz der
> Gesellschaft: Margaretenstraße 70/I/1, 1050 Wien, Österreich, Tel. +43
> (1) 9610567-0 Eingetragen beim Handelsgericht Wien, Firmenbuch-Nr.: FN
> 116859 b Umsatzsteuer-Identifikationsnummer / VAT-ID: ATU15138401,
> Steuer-Nummer: 264/4807
>
> This E-Mail has been sent on behalf of the company Intergraph Ges.m.b.H.
> Authorised Managing Directors: Maximilian Weber Registered office and
> Austrian headquarters: Margaretenstr. 70/I/1, 1050 Wien, Austria, Tel.
> +43 (1) 9610567-0 The company is recorded at the commercial court of
> Vienna under the company register number FN 116859 b
> VAT-ID: ATU15138401, Austrian Tax ID: 264/4807
>
> Diese E-Mail (mit zugehörigen Dateien) enthält möglicherweise Informationen, die vertraulich sind, dem Urheberrecht unterliegen oder ein Geschäftsgeheimnis darstellen. Falls Sie diese Nachricht irrtümlicherweise erhalten haben, benachrichtigen Sie uns bitte umgehend, indem Sie eine Antwort senden, und löschen Sie bitte diese E-Mail und Ihre Antwort darauf. Sämtliche aufgeführten Ansichten oder Meinungen sind ausschließlich diejenigen des Autors und entsprechen nicht notwendigerweise denen des Unternehmens Intergraph.
>
> This E-Mail (and any attachments) may be confidential and protected by legal privilege. If you are not the intended recipient please notify us immediately by replying to the sender and delete this E-Mail and your reply from your system. All the views and opinions published here are solely based on the author's own opinion and should not be considered necessarily as reflecting the opinion of Intergraph.
>
>
> -----Original Message-----
> From: Jim Graham [mailto:james.graham at oracle.com]
> Sent: Tuesday, October 6, 2015 8:38 PM
> To: Hruda, Steve <steve.hruda at hexagongeospatial.com>
> Cc: Sergey Bylokhov <Sergey.Bylokhov at oracle.com>; 2d-dev
> <2d-dev at openjdk.java.net>
> Subject: Re: [OpenJDK 2D-Dev] <AWT Dev> Question: Area changes order
> of points
>
> Hi Steve,
>
> Area simplifies the shape into a normalized version that defines the same interior area.  It does not care what the original ordering of the points was as it internalizes the shape, all it cares about is which areas are geometrically inside vs. outside and it creates a path according to its own internal policies that defines the same inside/outside boundaries.
>
> There is no "trick" to customizing this behavior and I'm not entirely sure why the point ordering would matter when you are performing CAG (Constructive Area Geometry) operations - only interiors and exteriors should matter.
>
>                          ...jim
>
> On 10/5/15 8:19 AM, Sergey Bylokhov wrote:
>> Hello,
>> I think this question is related to java2d, correct alias cc.
>>
>> On 24.09.15 12:53, Hruda, Steve wrote:
>>> I use the java.awt.geom.Area class to clip a shape. Today I noticed
>>> that new Area(Shape) changes the orientation of the shape, so that I
>>> get the points of the Area counter-clockwise in every case.
>>>
>>> The following test shows you my problem.
>>>
>>> https://drive.google.com/file/d/0B7P_rknS1TWxVGJ6a3hBaElBTk0/view?us
>>> p
>>> =sharing
>>>
>>>
>>> Is this a bug or do I something wrong?
>>>
>>> Is there a trick to get the points in the correct order?
>>
>>
>