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 Garnett
On 21 April 2016 at 03:00, Niels Charlier <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
