Re: [Geotools-devel] Maps, layers, legends and styles - now and later

[Martin D. <mar...@no...>]

Jody Garnett a =E9crit :
> parameter   ------synchornized----   difficult to use, but consistent

I noticed too that more convenience methods may be needed in parameters.=20
The hard thing is to find the right methods. For example I'm pretty much=20
against using ParameterDescriptor as keys, because it would not work=20
with different implementations (even inside Geotools, e.g. EPSG database=20
and various MathTransforms have different ParameterDescriptor for the=20
same "False northing" parameter: alias, identifiers, remarks and range=20
of valid values may be different, but it still the same parameter as far=20
as projections are concerned). ParameterDescriptor is metadata about a=20
parameter, and the key is the name.

I'm interrested in learning which kind of difficulties you encounter, so=20
we can try to improve on that.



> Metadata    ------synchornized----   strongly typed, does not scales

Geotools's implementation in org.geotools.metadata.iso do not scales; it=20
was not designed for large amount of data. However, Geotools=20
implementation in org.geotools.metadata.sql do scale, since it is fully=20
backed by an arbitrary database. Using java.lang.reflect.Proxy, the ~100=20
metadata interfaces are all implemented (with only 3 classes!) as a JDBC=20
binding. Unless I'm missing what you mean by scalable?

It seems to me that the scalability of metadata is not that much related=20
to the interfaces, but is rather implementation-dependent. Geotools has=20
both kind of implementations.

	Martin.