[
https://issues.apache.org/jira/browse/SIS-172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux closed SIS-172.
-----------------------------------
Resolution: Won't Fix
Storing the inclusion/exclusion state for each border separately is not very
practical when the envelope is the result of a map projection. Instead, we
document {{intersects(Envelope, boolean)}} in terms of more classical
{{intersects}} and {{touches}} operation.
We have to change the behavior of {{intersects(Envelope)}} for making it
conform to the usual definition of {{intersects}}, i.e. does not include the
cases where the envelopes only touch each-other.
> Replace boolean argument in AbstractEnvelope.contains and intersects
> --------------------------------------------------------------------
>
> Key: SIS-172
> URL: https://issues.apache.org/jira/browse/SIS-172
> Project: Spatial Information Systems
> Issue Type: Task
> Components: Referencing
> Affects Versions: 0.3, 0.4, 0.5, 0.6, 0.7
> Reporter: Martin Desruisseaux
> Assignee: Martin Desruisseaux
> Priority: Minor
> Fix For: 0.8
>
>
> The {{AbstractEnvelope}} class provides the following methods:
> * {{boolean contains(Envelope envelope, boolean edgesInclusive)}}
> * {{boolean intersects(Envelope envelope, boolean edgesInclusive)}}
> We may replace the {{boolean}} argument by something more generic.
> h3. First alternative: enumeration
> We could replace the {{boolean}} argument by something like the following
> enumeration:
> {code:java}
> public enum EdgeInclusion {
> /**
> * All edges are inclusive. This is the default policy for Envelope.
> */
> ALL,
> /**
> * All edges are exclusive.
> */
> NONE,
> /**
> * Edges defined by the lower corner are inclusive, while edges defined
> by the upper corner are exclusive.
> * This is the usual policy in Java2D.
> */
> LOWER,
> /**
> * Edges defined by the upper corner are inclusive, while edges defined
> by the lower corner are exclusive.
> * This policy is defined for completeness but rarely used.
> */
> UPPER
> }
> {code}
> The policy used in the majority of cases is the {{ALL}} one. Consequently we
> should provide convenience methods expecting only an {{Envelope}} argument
> and using that mode by default.
> h3. Second alternative: {{isLowerInclusive(int)}} and
> {{isUpperInclusive(int)}} methods.
> We could add a pair of methods telling whether the lower and upper values are
> inclusive or exclusive for a given dimension. This would be more generic than
> the above-cited enumeration, and would also be closer to the
> {{org.apache.sis.measure.Range}} API. The inclusion/exclusion information
> would be part of the {{Envelope}} state instead than an argument provided to
> the {{contains}} and {{intersects}} methods. However we would need to revisit
> also the {{contains(DirectPosition)}} and {{add(Envelope)}} methods.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
