The following document contains the listing of user tags found in the code. Below is the summary of the occurrences per tag.
| Tag Class | Total number of occurrences | Tag strings used by tag class |
|---|---|---|
| TODO | 97 | @todo |
Each tag is detailed below:
Number of occurrences found in the code: 97
| org.opengis.coverage.Coverage | Line |
|---|---|
| We need to explain the relationship with {@link #getDomainExtents}, if any. | 130 |
| org.opengis.coverage.DiscreteCoverage | Line |
| Is it duplicating {@link Coverage#list}? | 63 |
| org.opengis.coverage.DiscreteCurveCoverage | Line |
| evaluate and evaluateInverse | 55 |
| org.opengis.coverage.DiscreteGridPointCoverage | Line |
| Should we restrict {@link DomainObject} to {@link GridPoint} as well? It sound like a logical consequence of {@link GridPointValuePair} restriction. | 73 |
| Should we move this interface to org.opengis.coverage.grid as all the other grid interfaces, or should it remain in org.opengis.coverage to follow the ordering in ISO19123? | 75 |
| What should be the behavior of {@link #evaluate(DirectPosition)} when the position is not exactly on a grid point? Current proposal is to return an empty set. | 77 |
| org.opengis.coverage.DiscreteSolidCoverage | Line |
| evaluate and evaluateInverse | 61 |
| org.opengis.coverage.DiscreteSurfaceCoverage | Line |
| evaluate and evaluateInverse | 64 |
| Review the constraints. Something must be missing... | 78 |
| Review the constraints. Something must be missing... | 92 |
| org.opengis.coverage.ThiessenPolygonCoverage | Line |
| Provide a figure derived from figure 11 in ISO 19123. | 70 |
| org.opengis.coverage.ThiessenValuePolygon | Line |
| The ISO 19123 specification returns a {@link org.opengis.geometry.coordinate.Polygon}. We will have some trouble here, since {@code Polygon} is not a {@link org.opengis.geometry.Geometry}. | 63 |
| org.opengis.coverage.TinCoverage | Line |
| Add a figure derived from figure 22 in ISO 19123. | 65 |
| org.opengis.coverage.ValueCurve | Line |
| I'm not sure to understand how the exception clause is related to the first sentence in the two first points? | 99 |
| org.opengis.coverage.ValueObject | Line |
| Consider leveraging the parameter package. | 83 |
| org.opengis.coverage.ValueTriangle | Line |
| The returns type in ISO-19123 is {@link Triangle}. | 61 |
| org.opengis.coverage.grid.FootPrint | Line |
| his role name in ISO 19123, "center", is a misnomer. By definition, the sample point represented in the same external coordinate reference system as the footprint, is the "center" of the footprint. This "center" attribute associates the footprint with a grid point, which represents only the index into the grid. This implementation specification, therefore, has renamed the association role to "index". | 69 |
| org.opengis.coverage.grid.GridCoverage | Line |
| Which indices vary fastest? | 373 |
| This operation can't be implemented efficiently in Java with a {@code byte[]} return type, since there is no way to cast an array of arbitrary type to an array of type {@code byte[]}. Even the {@code java.nio.Buffer} doesnt allow that (it allows the opposite way however). | 434 |
| org.opengis.coverage.grid.GridCoverageReader | Line |
| This javadoc may not apply thats well in the iterator scheme. | 91 |
| This javadoc may not apply thats well in the iterator scheme. | 103 |
| The javadoc should also be more explicit about hierarchical format. Should the names be returned as paths? Explain what to return if the GridCoverage are accessible by index only. A proposal is to name them "grid1", "grid2", etc. | 117 |
| Do we need a special method for that, or should it be a metadata? | 129 |
| org.opengis.coverage.grid.GridCoverageWriter | Line |
| This javadoc may not apply thats well in the iterator scheme. | 90 |
| This javadoc may not apply thats well in the iterator scheme. | 101 |
| Do we need a special method for that, or should it be a metadata? | 111 |
| org.opengis.coverage.grid.GridValuesMatrix | Line |
| Comment (Wim): Both extracting an image for display and operation chaining require memory effiecient and fast access to the data. How should the data be structured per record? Some use cases: <table border=1> <tr><td>DTM<td>double<td>List<double> <tr><td>TM image<td>7 bytes<td> <tr><td>Landuse map<td>string<td>{@code List<double>} with look up table for the strings </table> | 61 |
| org.opengis.coverage.grid.HexagonalGridCoverage | Line |
| evaluateInverse | 74 |
| org.opengis.coverage.grid.ReferenceableGrid | Line |
| Comment (Wim): there seems to be no way to check whether two ReferenceableGrids are equal, i.e. exactly fitting on all GridPoints.<br> Martin: a possible approach is to import the "gridToCRS" attribute from the legacy OGC specification, exactly as proposed for {@link RectifiedGrid}. Two ReferenceableGrids with the same grid geometry and the same "gridToCRS" math transform are exactly fitting on all GridPoints. | 54 |
| Question (Wim): GridCoordinates are always integers, how to get the not rounded results?<br> Martin: The legacy OGC specification defined a "gridToCRS" math transform for that. We may consider to import this element in the proposed set of interfaces. | 86 |
| org.opengis.coverage.grid.quadrilateral.GridValuesMatrix | Line |
| Comment (Wim): Both extracting an image for display and operation chaining require memory effiecient and fast access to the data. How should the data be structured per record? Some use cases: <table border=1> <tr><td>DTM<td>double<td>List<double> <tr><td>TM image<td>7 bytes<td> <tr><td>Landuse map<td>string<td>{@code List<double>} with look up table for the strings </table> | 64 |
| org.opengis.coverage.grid.quadrilateral.ReferenceableGrid | Line |
| Question (Wim): GridCoordinates are always integers, how to get the not rounded results?<br> Martin: The legacy OGC specification defined a "gridToCRS" math transform for that. We may consider to import this element in the proposed set of interfaces. | 79 |
| org.opengis.coverage.processing.Operation | Line |
| This interface should be renamed {@code CoverageOperation}. | 66 |
| The return type will be changed from {@link String} to {@link Identifier}. | 77 |
| org.opengis.filter.FilterFactory | Line |
| should be equal (so equals can refer to geometry) | 136 |
| org.opengis.filter.FilterFactory2 | Line |
| should be equals, resolve conflict with PropertyIsEqualTo equals( Expression, Expression ) | 123 |
| org.opengis.filter.capability.Operator | Line |
| Which relationship with Filter and expressions? | 68 |
| org.opengis.filter.sort.SortBy | Line |
| Use QName | 113 |
| org.opengis.geometry.aggregate.AggregateFactory | Line |
| Need to check if ISO 19107 defines constructors for aggregates. | 56 |
| org.opengis.geometry.complex.Complex | Line |
| Some associations are commented out for now. | 69 |
| Consider using a Collection return type instead. | 87 |
| Consider using a Collection return type instead. | 98 |
| org.opengis.geometry.complex.ComplexFactory | Line |
| Need to check if ISO 19107 defines constructors for complexes. | 55 |
| org.opengis.geometry.complex.CompositeCurve | Line |
| This interface extends (indirectly) both {@link org.opengis.geometry.primitive.Primitive} and {@link org.opengis.geometry.complex.Complex}. Concequently, there is a clash in the semantics of some set theoretic operation. Specifically, {@code Primitive.contains(...)} (returns FALSE for end points) is different from {@code Complex.contains(...)} (returns TRUE for end points). | 54 |
| org.opengis.geometry.complex.CompositeSolid | Line |
| This interface extends (indirectly) both {@link org.opengis.geometry.primitive.Primitive} and {@link org.opengis.geometry.complex.Complex}. Concequently, there is a clash in the semantics of some set theoretic operation. Specifically, {@code Primitive.contains(...)} (returns FALSE for end points) is different from {@code Complex.contains(...)} (returns TRUE for end points). | 52 |
| org.opengis.geometry.complex.CompositeSurface | Line |
| This interface extends (indirectly) both {@link org.opengis.geometry.primitive.Primitive} and {@link org.opengis.geometry.complex.Complex}. Concequently, there is a clash in the semantics of some set theoretic operation. Specifically, {@code Primitive.contains(...)} (returns FALSE for end points) is different from {@code Complex.contains(...)} (returns TRUE for end points). | 53 |
| org.opengis.geometry.coordinate.AffinePlacement | Line |
| Refactor as an {@code org.opengis.referencing.operation.AffineTransform} interface? | 64 |
| org.opengis.geometry.coordinate.Arc | Line |
| Inconsistent UML: "startAngle" and "startOfArc" are both used. Which one is the right one? | 116 |
| Inconsistent UML: "endAngle" and "endOfArc" are both used. Which one is the right one? | 131 |
| org.opengis.geometry.coordinate.Bezier | Line |
| Add equations from ISO 19107 to the javadoc. | 50 |
| org.opengis.geometry.coordinate.CoordinateSystem | Line |
| This interface is defined in the ISO 19107 draft. But maybe we should consider retrofitting it in the GeoAPI <code>org.opengis.referencing.cs.CoordinateSystem</code> interface instead. See <a href="http://jira.codehaus.org/browse/GEO-202">GEO-202</a>. | 51 |
| org.opengis.geometry.coordinate.GenericSurface | Line |
| Investigate why this interface doesn't extends {@link Geometry}, since it is a cause of difficulty with {@link org.opengis.coverage.Coverage}. | 51 |
| org.opengis.geometry.coordinate.HomogeneousDirectPosition | Line |
| Move this definition in the <cite>geoapi normative</cite> module if approved. | 74 |
| org.opengis.geometry.coordinate.Parameterization | Line |
| This interface is defined in the ISO 19107 draft. But maybe we should consider retrofitting it in the GeoAPI <code>org.opengis.referencing.operation.MathTransform</code> interface instead. See <a href="http://jira.codehaus.org/browse/GEO-202">GEO-203</a>. | 67 |
| org.opengis.geometry.coordinate.Placement | Line |
| Retrofit in {@link org.opengis.referencing.operation.MathTransform}? | 53 |
| org.opengis.geometry.primitive.CurveSegment | Line |
| This interface has been removed from ISO 19107:2008 draft, since it is now inherited from {@link GenericCurve}. | 158 |
| This interface has been removed from ISO 19107:2008 draft, since it is now inherited from {@link GenericCurve}. | 182 |
| org.opengis.geometry.primitive.Point | Line |
| Some associations are commented out for now. | 57 |
| org.opengis.geometry.primitive.Primitive | Line |
| Some associations are commented out for now. | 67 |
| Using a {@link Set} returns type allows the user to add or remove element in this set at his convenience. Is it the right interpretation of this specification? | 101 |
| Using a {@link Set} returns type allows the user to add or remove element in this set at his convenience. Is it the right interpretation of this specification? | 114 |
| Should we stretch out some relation with contained primitive? For example should we update the specification with something like the following? "Invoking {@code B.getContainingPrimitive().add(A)} is equivalent to invoking {@code A.getContainedPrimitive().add(B)}". | 117 |
| org.opengis.geometry.primitive.Solid | Line |
| Some associations are commented out for now. | 51 |
| In UML diagram, this operation has an {@code Area} return type. | 84 |
| In UML diagram, this operation has a {@code Volume} return type. | 96 |
| org.opengis.geometry.primitive.SurfaceBoundary | Line |
| Consider using a Collection return type instead. | 94 |
| org.opengis.metadata.ApplicationSchemaInformation | Line |
| In UML, the type was {@code CharacterString}. It is not clear if it should be the file name or the file content. | 82 |
| In UML, the type was {@code binary}. It is not clear if it was intented to be the file content. | 101 |
| org.opengis.metadata.content.BandDefinition | Line |
| the same as the documentation for {@link #HALF_MAXIMUM}. | 68 |
| the same as the documentation for {@link #THREE_DB}. | 77 |
| org.opengis.metadata.spatial.PixelOrientation | Line |
| The sentence "<cite>closest to the origin of the SRS</cite> probably applies to positive coordinates only. For the general case including both positive and negative coordinates, we should probably read "in the direction of negative infinity". This interpretation should be clarified with ISO. | 82 |
| org.opengis.temporal.Calendar | Line |
| The original version of this class returned {@code TemporalCalendarEra}, which doesn't exists in the provided sources. I assumed that it was a typo and that the actual class was {@link CalendarEra}. | 68 |
| Method name doesn't match the UML identifier. | 79 |
| org.opengis.temporal.Clock | Line |
| Retrofit in the referencing framework. | 47 |
| org.opengis.temporal.IndeterminateValue | Line |
| Need javadoc for each enumeration. | 51 |
| org.opengis.temporal.OrdinalPosition | Line |
| The method name doesn't match the return type. | 52 |
| org.opengis.temporal.OrdinalReferenceSystem | Line |
| The javadoc doesn't seem accurate. | 47 |
| Missing UML annotations. | 48 |
| What the structure is exactly? | 56 |
| org.opengis.temporal.PeriodDuration | Line |
| Uses Java 1.5 {@link javax.xml.datatype.Duration}. | 47 |
| org.opengis.temporal.RelativePosition | Line |
| Need javadoc for each enumeration. | 52 |
| org.opengis.temporal.Separation | Line |
| The Javadoc suggest that this interface should extends some kind of {@linkplain TemporalGeometricPrimitive temporal geometric primitive}. | 46 |
| org.opengis.temporal.TemporalComplex | Line |
| Missing UML tag. | 40 |
| org.opengis.temporal.TemporalCoordinate | Line |
| Should we return a primitive type? | 53 |
| org.opengis.temporal.TemporalCoordinateSystem | Line |
| Retrofit in {@link org.opengis.referencing.cs.TimeCS}. | 50 |
| org.opengis.temporal.TemporalOrder | Line |
| The javadoc suggests that this interface should extends some kind of {@link TemporalPrimitive}. | 47 |
| org.opengis.temporal.TemporalPosition | Line |
| Method name doesn't match the return type. | 54 |
| org.opengis.temporal.TemporalTopologicalComplex | Line |
| Missing UML annotation. | 53 |
| org.opengis.webservice.MetadataLink | Line |
| Which relationship with {@link SimpleLink}? | 61 |
| org.opengis.webservice.WebServiceException | Line |
| document | 64 |
| document | 69 |
| The argument order (locator before message) may surprises users who don't read carefully the javadoc. We could expect optional argument to appears next to mandatory ones. | 84 |
| The argument order (locator before message) may surprises users who don't read carefully the javadoc. We could expect optional argument to appears next to mandatory ones. | 97 |
| org.opengis.webservice.capability.Service | Line |
| Original type was CodeList (which CodeList?), but all others occurences of this method in the API used a character string. | 37 |
| org.opengis.webservice.capability.ServiceIdentification | Line |
| Which kind of code exactly (or CodeList?) | 120 |
| org.opengis.webservice.capability.ServiceMetadata | Line |
| Check type. | 80 |
| org.opengis.webservice.capability.ServiceOperation | Line |
| Which relationship with {@link Operation}? | 5 |