Hi all,
I've been working on fleshing this proposal out and adding a bit to it. See
the conversation on on-the-fly reprojection in ImageMosaic. My updated API
proposal is on my own Wiki for now, I can update the master one but I
wanted to solicit early feedback. Please let me know if something doesn't
make sense. Wanted to throw it out there earlier for feedback rather than
later:
https://github.com/dvntucker/geotools/wiki/Refactor-ImageMosaic-for-extensibility
Cheers,
Devon
On Fri, Apr 22, 2016 at 1:20 AM, Niels Charlier <ni...@scitus.be> wrote:
> 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> 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
>
>
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
