Devon,
Great work, thanks for improving the explanation of my part. I'm glad to
see the plan is moving forward.
Kind Regards
Niels
On 21-05-16 01:21, Devon Tucker wrote:
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
<mailto: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
<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
<mailto: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
