On 21-04-16 20:01, Jody Garnett wrote:
Thanks for the clarification Niels, I was not aware that Prop was part
of the current API.
Still we have some duplication here right? Should we try running the
property collectors, look at the results, and generate the schema
appropriate to store the results?
Jody, have a look at this:
http://geoserver.geo-solutions.it/multidim/en/imagemosaic/mosaic_indexer.html#imagemosaic-xml-indexer-example
You see that in the current index configuration file, there is a
separate section for the schemas and the property collectors. Both
sections provide a completely different kind of information.
I do not think that there is duplication. You cannot run property
collectors if you do not have a schema yet. The property collectors are
run per feature (granule). The schema is made before you can even create
features. The schema is defined per coverage inside the store and can
differ between them. The property collectors are unaware of the
coverages, and they may operate for multiple. Once the schema has been
created for a coverage, the features are created and then values might
be needed for each feature. This is the time that (for some properties)
the appropriate property collectors are looked up and called to fill in
those values.
In summary:
the schema -> defines the metadata (table structure) of the index per
coverage
the property collectors -> defines how to grab the data for the index
(from the metadata of the granules)
two different functions altogether.
--
Jody Garnett
On 21 April 2016 at 03:00, Niels Charlier <ni...@scitus.be
<mailto:ni...@scitus.be>> wrote:
On 17-04-16 04:17, Jody Garnett wrote:
This proposal (and email thread) should be orthogonal to the
RnD discussion on setting up a mosaic with multiple projections.
This mosaic is focused on creating/managing the index used.
One part I cannot wrap my head around is the workflow behind
these two methods - createSchema(String name,
CoordinateReferenceSystem crs) which creates the FeatureType
used for the index, and Collection<PropertiesCollector>
getPropertiesCollectors().
It seems these two methods need to be implemented together, a
single PropertyCollector may collect more than once value on
examining a raster. I am not sure how to line up these
collected values with the created schema without more information.
Just to be clear, the proposal doesn't change anything about
PropertyCollectors work. This would simply continue to work as it
is working right now, until somebody makes a proposal to change it
to something else!
These two things have a completely different function. The schema
defines the structure of the index.
Property Collectors are customisable mechanisms that provides
(some of the) values of the index per granule, taking information
from the file and/or the coverage metadata.
The schema creation includes attributes that are not collected
with a PropertyCollector (such as location), while one Propery
Collector can potentially supply multiple attribute values.
We also have String getParameter(Prop prop) defined, but the
class Prop is not included in the proposal.
Prop already exists in the current API.
Suggestions:
- Use a list of PropertiesCollectors to provide order, which
can then be used to determine the Schema?
- Language consistency - raster / granule
- Language consistency - could we use AttributeDescriptor
rather than introduce a new thing called "Prop" ?
You do know that Props are configuration properties, nothing to do
with features?
- Are the class responsibilities clear: GranuleCatalogManager,
GranuleCatalog, GranuleStore, MosaicHarvester, etc...
(It could also be that since I am unfamiliar with the
internals being refactored that I am just struggling with the
language - so if everyone else is okay ...)
Regards
Niels
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
