contributingFootprint

[KathiSchleidt]

In the INSPIRE Model, the contributingFootprint is provided in the aggregation association contributingElevationGridCoverage, that aggregates multiple coverages together into a larger coverage.
When transferring the INSPIRE properties from the extended ElevationGridCoverage featureType to the ElevationGridCoverageMetadata dataType, providing a hierarchically nested set of metadata elements structured as foreseen for ElevationGridCoverage would cause issues with correct provision of metadata by WCS; the metadata could be handled easier if the individual ElevationGridCoverageMetadata were provided as a flat list.
In order to maintain the information provided by the contributingFootprint, I would propose shifting it down into the aggregated coverage metadata.

[pebau]

switching discussion from email to git - good point, Kathi!

I very much hope that we can find a metadata modeling that allows to have the single coverage with a single metadata bucket, and I still believe it is possible. From what I can see we need "some way" to describe a footprint, plus a rule that describes what footprint should mean (ie: how it gets modified in case of a coverage update, such as through WCS-T UpdateCoverage).

For my understanding:

• do we agree that the coverage footprints are mutually disjoint, ie: any given pixel is in at most (exactly one?) footprint?
  if the contributing footprint is a rectangle it is inexact anyway. Even a polygon is not the best way, to be exact it would need a mask. Am I missing something?

[KathiSchleidt]

contributingFootprint is of type GM_MultiSurface

-- Definition --
Multi polygon delineating the geographic area of the elevation grid coverage that contributes to the aggregated elevation grid coverage.

In the original INSPIRE Model, the coverages are not merged into one coverage, they're provided as a hierarchical network of associated (sub)coverages, with the footprint polygon (or surface) provided within the association, leaving everything else to the end user

Question is if we should even bother with merging, or also just handle them as individual coverages, provide a reference to the IDs of the other coverages?

[KathiSchleidt]

IR Requirement (5)
The contributing footprints of any two ElevationGridCoverage instances referred to by the same aggregated ElevationGridCoverage instance shall be either adjacent or disjoint.

IR Requirement (6)
The union of the contributing footprints of the ElevationGridCoverage instances referred to by the same aggregated ElevationGridCoverage instance shall determine the geographic extent (domainExtent) of the aggregated ElevationGridCoverage instance.

[pebau]

ok, so mathematically: the domainExtent = direct sum of all footprints. So new patches need to be tested for intersection with existing footprints, and depending on the replacement policy the ingested footprint and/or existing footprints need to be updated.

BTW, Req 5 raises in interesting question: how does the footprint delineate? I mean: is the border line crossing the pixel's center, or some corner, or is it enclosing the pixel? Has impact on what "adjacent"means.

On the fly we see: in Req5 they forgot to mention that all pixels shall have the same alignment (pixel in corner / center / etc).

[KathiSchleidt]

Ah... to update - please see: #3
turns out any update (other than a recalculation of the original primary data due to a known calculation error) is a new id
thus, I'd say update is a mute point :(

[KathiSchleidt]

Also - domainExtent = Bounding Box of the direct sum of all footprints
domainExtent [1..*]: EX_Extent (so a 4D spatiotemporal BB)
contributingFootprint [1]: MultiSurface

As there's a statement that aggregated coverages can be further aggregated, what I don't know is what the footprint of the aggregated coverage is, as you suggest direct sum of all footprints?

[pebau]

On 22.07.19 22:49, Kathi Schleidt wrote: Also - domainExtent = Bounding Box of the direct sum of all footprints domainExtent [1..*]: EX_Extent (so a 4D spatiotemporal BB) contributingFootprint [1]: MultiSurface As there's a statement that aggregated coverages can be further aggregated, what I don't know is what the footprint of the aggregated coverage is, as you suggest direct sum of all footprints?

hooray, did anybody think through what recursively nested coverages mean? Eg, the envelope of a coverage is approximate, so if the super-coverage relies on it it may get false information. And the extent is not identical to the direct sum, but a superset (the convex hull). Can anybody explain to me how that propagates? Nested coverages considered bad.

-Peter

— You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1?email_source=notifications&email_token=ABOR5DVOYF7732QIM4PDJWDQAYMOFA5CNFSM4IF2NUY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2RDW5Y#issuecomment-513948535>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABOR5DT6KH4CVFGLGEP2DF3QAYMOFANCNFSM4IF2NUYQ>.

-- Dr. Peter Baumann - Executive Director, rasdaman GmbH Bremen (HRB 26793) www.rasdaman.com, mail: baumann@rasdaman.com tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 - Professor of Computer Science, Jacobs University Bremen www.faculty.jacobs-university.de/pbaumann mail: p.baumann@jacobs-university.de tel: +49-421-200-3178, fax: +49-421-200-493178 "A brilliant idea is a job halfdone."

[pebau]

Two more questions are popping up (not sure whether they want their own issue):

• Why is a surface used? Surfaces have their own properties which, AFAICS are not used - and effectively the footprint's purpose is not to define a surface. Rather, a polygon ring would have been more appropriate from my understanding.
• Is it ensured that this surface cannot have holes?

[pebau]

another comment on the above:

In the original INSPIRE Model, the coverages are not merged into one coverage, they're provided as a hierarchical network of associated (sub)coverages, with the footprint polygon (or surface) provided within the association, leaving everything else to the end user

so the "aggregated coverage" is effectively useless for practical purposes, the barrier put up to digest such a structure makes it tedious for experts and impossible for others.

Question is if we should even bother with merging, or also just handle them as individual coverages, provide a reference to the IDs of the other coverages?

Then we fall back to the medieval approach of single scenes while it is commonly accepted that "analysis-ready data" are the way forward. Back to single scenes instead of mosaics. Sorry to be so blunt.

This is why I suggested to have the complex concept of "aggregated coverages" as an optional extension - ESA can keep doing the complicated part, but the rest of Europe gets a simple, tractable, commercially viable definition.

[KathiSchleidt]

not sure if you're mixing 2 terms here (I was for a while, but hey, what do I know? ;) ): aggregation and mosaics are 2 separate concepts (at least in INSPIRE!). Luckily, the mosaic bit only shows up in IO, that we're ignoring for the present.

If you are interested, I've uploaded the UML for IO:

However, I see mosaic as currently out-of-scope, as:

1. The closest to data contained is an imageSourceReference of type CharacterString
2. While there is an AggregatedMosaicElement available, this was not fully modeled (just a stub in the UML)

[KathiSchleidt]

Nested coverages considered bad.

OK - this is where we run into issues with full INSPIRE Requirements :(

I see 2 ways forward:

1. Bow down to the INSPIRE Requirements, provide each coverage individually with references between (useless, but legal)
2. Continue on with a pragmatic merged approach, provide a metadata element for each coverage aggregated in, tell JRC that this is as good as it gets, and if they want alternatives, they can do the work ;)

I'd be all for Option 2, but would like Jordi's confirmation that this would be what users would really need!

[pebau]

not sure if you're mixing 2 terms here (I was for a while, but hey, what do I know? ;) ): aggregation and mosaics are 2 separate concepts (at least in INSPIRE!). Luckily, the mosaic bit only shows up in IO, that we're ignoring for the present.

oops, I was using "mosaic" in the general remote sensing sense [1] - effectively, an aggregated DEM in its intention is a mosaic, isn't it?

[1] eg: http://desktop.arcgis.com/en/arcmap/10.3/manage-data/raster-and-images/what-is-a-mosaic.htm

[pebau]

If you are interested, I've uploaded the UML for IO:

impressive work! But it is still incompatible with OGC CIS, correct?

[KathiSchleidt]

I'm the wrong person to ask, but here we need to focus on a) INSPIRE Requirements and b) workable solutions!

[KathiSchleidt]

UML for IO - impressive work! But it is still incompatible with OGC CIS, correct?

Hey - you're Mr. CIS! You've told me that the moment we extend the CIS coverage classes (anywhere other than the foreseen metadata extension slot), we break things.

And - I fail to be impressed by a AggregatedMosaicElement FT without additional properties or associations, while the SingleMosaicElement derived from the base MosaicElement has the imageSourceReference, the aggregate is the same as the parent.