- From: Peter Baumann <p.baumann@jacobs-university.de>
- Date: Sun, 7 Jun 2015 20:45:21 +0200
- To: <Kerry.Taylor@csiro.au>, <Simon.Cox@csiro.au>
- CC: <frans.knibbe@geodan.nl>, <public-sdw-wg@w3.org>, <allaves@fi.upm.es>
- Message-ID: <55749141.3000702@jacobs-university.de>
On 06/07/15 06:46, Kerry.Taylor@csiro.au wrote:
> I am not certain about the first. Are we happy to represent linked metadata
> but to deliver the data in some relatively obscure format? Maybe...
this is not necessarily necessary ;-)
we might map the coverage definition to RDF triples so that there is a seamless
connection. There is an exactly defined glue point in the coverage where "data
get binary". OGC has XML already established, currently they are diving into
adding JSON. RDF could be a nice 3rd option.
>
> 'Yes' to the second. But how many is multiple? I do not know. Maybe only one.
which one? :-)
>
> In both cases the emphasis on access / usability should overrride
> completeness, and in this space it will certainly be a tradeoff to negotiate.
yes, I understand this, makes much sense to me.
We might walk the coverage types and decide for each whether it is desirable at
this stage or not.
best,
Peter
>
> In any case I think both questions should stay open for some time yet, So I
> support leaving it as an issue and following up much later ( as we work at
> the technical level ).
>
>
> Kerry
>
> On 6 Jun 2015, at 1:50 am, "Cox, Simon (L&W, Highett)" <Simon.Cox@csiro.au
> <mailto:Simon.Cox@csiro.au>> wrote:
>
>> ISSUE-19
>>
>>
>>
>> Frans asks:
>>
>> Does this mean some kind of standard classification of coverage types is
>> required, so the coverage type can be indicated in the metadata for example?
>>
>>
>>
>> Or does this mean that there should be standard encodings for different
>> coverage types?
>>
>> 'Yes' to the first.
>>
>>
>>
>> 'Maybe' to the second, but I would draw attention to the 's' on the end of
>> 'encodings'. We know that there is and will continue to be diversity in
>> coverage encodings for several very valid reasons. GMLCOV, netCDF,
>> GeoTIFF, JPEG-2000 are widely used. There are current activities in OGC
>> (WaterML2, TimeseriesML) to harmonize the interleaved geometry-value pair
>> representation of coverages (building on earlier work going back to 2006).
>> Each of these approaches addresses a known need and is used by viable
>> communities, meeting requirements that are not going to go away. We should
>> have a goal of recognising the diverse uses, minimising the number of
>> solutions as much as possible, but there is no way the count of solutions
>> will be reduced to one.
>>
>>
>>
>> *Simon Cox** | **Research Scientist**
>> CSIRO Land and Water*
>> PO Box 56, Highett Vic 3190, Australia
>> Tel +61 3 9252 6342 <tel:%2B61%203%209252%206342> *| *Mob +61 403 302 672
>> <tel:%2B61%20403%20302%20672>
>> simon.cox@csiro.au
>> <https://vic.owa.csiro.au/owa/redir.aspx?C=Y8HMKTuUBkmbM97NjtDx5lGOnwxj1c9IdyRdGXbcQ8yykNtSsGHlgXUbOJN1bdSmnc9NFxd8E0M.&URL=mailto%3asimon.cox%40csiro.au>
>> *| *http://people.csiro.au/C/S/Simon-Cox
>>
>>
>> --------------------------------------------------------------------------------
>> *From:* Frans Knibbe [frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>]
>> *Sent:* Saturday, 6 June 2015 1:28 AM
>> *To:* SDW WG Public List
>> *Cc:* Alejandro Llaves; Peter Baumann; Taylor, Kerry (Digital, Acton); Cox,
>> Simon (L&W, Highett)
>> *Subject:* Re: The Multiple types of coverage requirement
>>
>> Hello all,
>>
>> I have the feeling my original question still needs answering: What exactly
>> do we think is required?
>>
>> I have created an issue for this in the tracker: ISSUE-19
>> <https://www.w3.org/2015/spatial/track/issues/19>.
>>
>> Regards,
>> Frans
>>
>>
>>
>> 2015-06-04 23:30 GMT+02:00 <Simon.Cox@csiro.au <mailto:Simon.Cox@csiro.au>>:
>>
>> There is an existing branch of the OGC /def/ space for 'coverage-type' -
>> see http://www.opengis.net/def/coverageType/
>> <http://www.opengis.net/def/coverageType/>
>>
>> Currently the types listed there all relate to some special requirements
>> from some OGC Earth Observation standards -
>> http://www.opengis.net/def/coverageType/OGC-EO/ but this is a potential
>> place to put a suitable list.
>>
>>
>>
>> BTW - real soon now we will change the platform used to manage and
>> publish the OGC definitions. This will enable management of branches of
>> the tree to be delegated. This could support other requirements emerging
>> from SDWWG.
>>
>>
>>
>> *Simon Cox** | **Research Scientist**
>> CSIRO Land and Water*
>> PO Box 56, Highett Vic 3190, Australia
>> Tel +61 3 9252 6342 <tel:%2B61%203%209252%206342> *| *Mob +61 403 302 672
>> <tel:%2B61%20403%20302%20672>
>> simon.cox@csiro.au
>> <https://vic.owa.csiro.au/owa/redir.aspx?C=Y8HMKTuUBkmbM97NjtDx5lGOnwxj1c9IdyRdGXbcQ8yykNtSsGHlgXUbOJN1bdSmnc9NFxd8E0M.&URL=mailto%3asimon.cox%40csiro.au>
>> *| *http://people.csiro.au/C/S/Simon-Cox
>>
>>
>> --------------------------------------------------------------------------------
>> *From:* Alejandro Llaves [allaves@fi.upm.es <mailto:allaves@fi.upm.es>]
>> *Sent:* Wednesday, 3 June 2015 11:57 PM
>> *To:* Peter Baumann
>> *Cc:* Taylor, Kerry (Digital, Acton); Frans Knibbe; SDW WG Public List
>> *Subject:* Re: The Multiple types of coverage requirement
>>
>> For instance, the description of the coverage type and a link to a
>> superclass entity, such as "coverage types by grid complexity"?
>>
>> Alejandro
>>
>> On 1 June 2015 at 16:20, Peter Baumann <p.baumann@jacobs-university.de
>> <mailto:p.baumann@jacobs-university.de>> wrote:
>>
>> Alejandro-
>>
>> nope, no URIs defined as of yet. What information could be provided
>> at the target of the URI?
>>
>> -Peter
>>
>>
>>
>> On 06/01/15 15:16, Alejandro Llaves wrote:
>>> Thanks, Peter! Are there URIs for these identifiers? If not, I think
>>> this may be work for the group's Coverage in Linked Data
>>> deliverable. For now, I can add them as examples for the Multiple
>>> types of coverage
>>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MultipleTypesOfCoverage> requirement.
>>>
>>>
>>> Cheers,
>>> Alejandro
>>>
>>> On 1 June 2015 at 14:49, Peter Baumann
>>> <p.baumann@jacobs-university.de
>>> <mailto:p.baumann@jacobs-university.de>> wrote:
>>>
>>> Here is a classification by grid complexity, hope it helps somehow:
>>>
>>> - just array, mapping is 1:1
>>> -> GridCoverage (GML 3.2.1)
>>> - linear mapping from n-D array to n-D grid, g = a*x+b for a,b
>>> in R^n
>>> -> RectifiedGridCoverage
>>> - linear mapping with g = A*x+b for A in R^n*n
>>> -> ReferenceableGridCoverage, byVector
>>> - linear mapping from n-D array (x_n) to m-D grid (g_m), m>n:
>>> g_m = A * x_n + b for A in R^n*m
>>> ->ReferenceableGridCoverage, byArray
>>> - nonaffine transformations, ex: Sensor geometries
>>>
>>> (anybody disagreeing?)
>>>
>>> One could classify along dimension axes (horizontal, vertical,
>>> time, ...) but the above one I believe is most helpful for the
>>> purpose on hand, and it also very much determines implementation
>>> complexity and dataset sizes (in particular: byArray approx.
>>> doubles data set size).
>>>
>>> -Peter
>>>
>>>
>>>
>>>
>>> On 05/31/15 09:35, Kerry.Taylor@csiro.au
>>> <mailto:Kerry.Taylor@csiro.au> wrote:
>>>> I am quite ok with the UCR expressed as it is, but I note that
>>>> our use cases do not actually require very many of these
>>>> multiple types and I suggest that we should look more closely
>>>> at * which* of the multiple types we really need as we go
>>>> progress. I would like to suggest that we make a note of this
>>>> in the UCR, attached to this requirement, to prevent the
>>>> "multiple" being interpreted as"all that have ever been thought
>>>> of" .
>>>>
>>>> note- i am prepared to back down on the request for the note,
>>>> as I think argued almost contradictorily in the case of
>>>> "multiple" applied to "multilingual" in last week's meeting.
>>>> Although in that language case I saw no harm other than realism
>>>> in attacking every conceivable language, but in the coverage
>>>> case I think there is a risk of harm in confusion if we take
>>>> on too many, which is worse.
>>>>
>>>> Kerry
>>>>
>>>>
>>>>
>>>> On 29 May 2015, at 11:47 pm, "Peter Baumann"
>>>> <p.baumann@jacobs-university.de
>>>> <mailto:p.baumann@jacobs-university.de>> wrote:
>>>>
>>>>> Frans-
>>>>>
>>>>> here a slate (not comprehensive, but likely covering all
>>>>> considered by W3C currently):
>>>>> - gridded coverages:
>>>>> - by dimension: 1-D through 4-D (climate people also
>>>>> consider 5-D)
>>>>> - by grid type:
>>>>> - regular grid (equidistant spacing ("resolution"),
>>>>> such as ortho imagery)
>>>>> - irregular grids (grid lines have individual spacing
>>>>> per axis, such as timeseries often have)
>>>>> - warped grids (grid points sit anywhere in space, but
>>>>> still topologically isomorphic to a grid)
>>>>> - sensor grids (geo position of grid points determined
>>>>> by sensor model, usually some involved non-linear algorithm)
>>>>> - non-gridded coverages:
>>>>> - point clouds
>>>>> - (rest likely not of interest here)
>>>>>
>>>>> cheers,
>>>>> Peter
>>>>>
>>>>>
>>>>> On 05/29/15 14:36, Frans Knibbe wrote:
>>>>>> Hello Alejandro,
>>>>>>
>>>>>> I am looking at the Multiple types of coverage
>>>>>> <http://w3c.github.io/sdw/UseCases/SDWUseCasesAndRequirements.html#MultipleTypesOfCoverage>
>>>>>> requirement now: "It should be possible to represent many
>>>>>> different types of coverage."
>>>>>>
>>>>>> Does this mean some kind of standard classification of
>>>>>> coverage types is required, so the coverage type can be
>>>>>> indicated in the metadata for example?
>>>>>>
>>>>>> Or does this mean that there should be standard encodings for
>>>>>> different coverage types?
>>>>>>
>>>>>> Greetings,
>>>>>> Frans
>>>>>>
>>>>>> --
>>>>>> Frans Knibbe
>>>>>> Geodan
>>>>>> President Kennedylaan 1
>>>>>> 1079 MB Amsterdam (NL)
>>>>>>
>>>>>> T +31 (0)20 - 5711 347 <tel:%2B31%20%280%2920%20-%205711%20347>
>>>>>> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
>>>>>> www.geodan.nl <http://www.geodan.nl>
>>>>>> disclaimer <http://www.geodan.nl/disclaimer>
>>>>>>
>>>>>
>>>>> --
>>>>> Dr. Peter Baumann
>>>>> - Professor of Computer Science, Jacobs University Bremen
>>>>> www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>>>> mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>>>> tel: +49-421-200-3178 <tel:%2B49-421-200-3178>, fax: +49-421-200-493178 <tel:%2B49-421-200-493178>
>>>>> - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>>>> www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>>>> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 <tel:%2B49-173-5837882>
>>>>> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>>>>
>>>>>
>>>
>>> --
>>> Dr. Peter Baumann
>>> - Professor of Computer Science, Jacobs University Bremen
>>> www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>>> mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>>> tel: +49-421-200-3178 <tel:%2B49-421-200-3178>, fax: +49-421-200-493178 <tel:%2B49-421-200-493178>
>>> - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>>> www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>>> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 <tel:%2B49-173-5837882>
>>> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>>
>>>
>>>
>>>
>>>
>>> --
>>> Alejandro Llaves
>>>
>>> Ontology Engineering Group (OEG)
>>>
>>> Artificial Intelligence Department
>>>
>>> Universidad Politécnica de Madrid
>>>
>>> Avda. Montepríncipe s/n
>>>
>>> Boadilla del Monte, 28660 Madrid, Spain
>>>
>>>
>>> http://www.oeg-upm.net/index.php/phd/325-allaves
>>>
>>>
>>> allaves@fi.upm.es <mailto:allaves@fi.upm.es>
>>>
>>
>> --
>> Dr. Peter Baumann
>> - Professor of Computer Science, Jacobs University Bremen
>> www.faculty.jacobs-university.de/pbaumann <http://www.faculty.jacobs-university.de/pbaumann>
>> mail: p.baumann@jacobs-university.de <mailto:p.baumann@jacobs-university.de>
>> tel: +49-421-200-3178 <tel:%2B49-421-200-3178>, fax: +49-421-200-493178 <tel:%2B49-421-200-493178>
>> - Executive Director, rasdaman GmbH Bremen (HRB 26793)
>> www.rasdaman.com <http://www.rasdaman.com>, mail: baumann@rasdaman.com <mailto:baumann@rasdaman.com>
>> tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882 <tel:%2B49-173-5837882>
>> "Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
>>
>>
>>
>>
>>
>> --
>> Alejandro Llaves
>>
>> Ontology Engineering Group (OEG)
>>
>> Artificial Intelligence Department
>>
>> Universidad Politécnica de Madrid
>>
>> Avda. Montepríncipe s/n
>>
>> Boadilla del Monte, 28660 Madrid, Spain
>>
>>
>> http://www.oeg-upm.net/index.php/phd/325-allaves
>>
>>
>> allaves@fi.upm.es <mailto:allaves@fi.upm.es>
>>
>>
>>
>>
>> --
>> Frans Knibbe
>> Geodan
>> President Kennedylaan 1
>> 1079 MB Amsterdam (NL)
>>
>> T +31 (0)20 - 5711 347
>> E frans.knibbe@geodan.nl <mailto:frans.knibbe@geodan.nl>
>> www.geodan.nl <http://www.geodan.nl>
>> disclaimer <http://www.geodan.nl/disclaimer>
>>
--
Dr. Peter Baumann
- 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
- Executive Director, rasdaman GmbH Bremen (HRB 26793)
www.rasdaman.com, mail: baumann@rasdaman.com
tel: 0800-rasdaman, fax: 0800-rasdafax, mobile: +49-173-5837882
"Si forte in alienas manus oberraverit hec peregrina epistola incertis ventis dimissa, sed Deo commendata, precamur ut ei reddatur cui soli destinata, nec preripiat quisquam non sibi parata." (mail disclaimer, AD 1083)
Received on Sunday, 7 June 2015 18:46:09 UTC