Bryce L Nordgren a écrit :
> If there were such a thing as a Map, where the Keys were geometry objects,
> and the Values were a particular arbitrary class (possibly containing
> geometry objects); this is almost precisely the definition of a coverage
> via 19123. (Make the keys "DomainObjects" to be perfect.) Does anyone
> object to making the Coverage interface extend Map? The implication is
> that the individual entries in the Map are not themselves Features. (This
> agrees with 19123.) The coverage itself is the feature. The drawback to
> this analogy is that Maps have a size() and can generate a finite keySet,
> entrySet, and Collection of Values. A coverage does not necessarily have
> any entries (it could calculate Values from an equation which accepts
> Keys.) Any opinions on whether this size()/keySet()/entrySet()/values()
> issue should influence the extension of Map?
As of Map contract, we have to implement iterators over entrySet(). It is not
clear to me how such iterator could be implemented if Coverage can generates an
infinite amount of values computed from an infinite amount of arbitrary keys.
Actually, I think that in term of ISO, Coverage would be an extension of a
TransfiniteMap (if such interface existed in Java) rather than a Map.
Citing ISO 19107:
"TransfiniteSet<T> – a possibly infinite set; restricted only to values.
For example, the integers and the real numbers are transfinite sets.
This is actually the usual definition of set in mathematics, but
programming languages restrict the term set to mean finite set."
Same applies to Map I guess: in mathematic, Map should have been a possibly
infinite map without iterator() or size() methods, and the current
java.util.Map
should have been a subclass of mathematic Map called "FiniteMap".
This lead me to believe that a mathematic Map object (or TransfiniteMap) would
have been an appropriate superclass for Coverage, but java.util.Map is not. I
would prefer a MapAdapter class or a "Coverage.mapView(...)" method, where the
'mapView(...)' arguments are the envelope and the interval to use for iterating
over the domain. Then we get a finite map, consistent with java.util.Map
contract.
> The special case of a discrete coverage is just a collection of homogeneous
> records (not themselves features) which are indexed by geospatial location.
> A discrete coverage is very much like a database table. A discrete
> coverage _can_ provide values for size(), can generate the Sets and
> Collections listed above, and can therefore fully implement the Map
> interface.
Right. It would be correct to set "DiscreteCoverage extends Coverage, Map"
(which is allowed for interfaces), but I would avoid "Coverage extends Map".
However, I may wish to try to implements ISO 19123 as it stand before to add
Map
in the inheritence (i.e. we may want to see how MapAdapter of
Coverage.mapView(...) work in practice, if we implement them).
Martin
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
