NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
This is a multi-part message in MIME format. Hi all, just a brief comment from my observations. I have had several talks with INSPIRE team members and national voices. Some personal opinions gathered seem to indicate that INSPIRE first went for WMS and WFS, and in the next step raster (!) data will be considered; nobody thinks about general meshes in the INSPIRE context for now. Mind you, the overwhelming set of applications is mapping (ortho images, scanned maps, and the like). =46rom that background it is hard to see for me that the mapping communities would go for netcdf. This is not meant to insult anybody or to deny the clearly high importance (and expressiveness) of netcdf. But these folks just as well have their traditional approaches which they want to find again in the new standards. Bottom line, WCS is going to move forward with one phase cycle behind WFS/WMS. It is a hard way to achieve the vision of WCS, interoperability across various coverage using communities, but I see WCS as the vehicle to do this job. Problems would remain the same for any other approach as well. my $.02, Peter Lawrence, BN (Bryan) wrote:
Hi Folks Like most, I'm watching this with interest. I don't believe INSPIRE will mandate us to use WCS with SOAP, but if itdoes, as already explained, that will apply to national infrastructure, not community infrastructure ... the line we are taking within NERC is thatwe will support INSPIRE because it will improve our ability to do science,both within our communities and between! If there really is a clash between these, there is no doubt that community expediency will win, withonly lip-service paid to compliance. However, if only one or two communities are out on a limb, then they might well wither ...So, from a technology point of view: What's more interesting for me is fusing metadata, with semantic subsetting (i.e by lat/lon etc not array index stride). It would appear that WCS provides that in a way that is more interoperable (although far from perfect)... but is stuffed by having todeliver non-interoperable payloads (in that regard, from some perspective, *all* parochial formats are non-interoperable). Opendap per se, doesn'tchange that argument - although it might simplify the construction of useful WCS servers that exploit existing infrastructure (assuming netcdf clients). More useful IMHO are tools that describe coverages in useful ways so that clients and/or servers can work out whether they can map a coverage in one format to another that they understand as part of the user workflow. Hence without CSML, or the Unidata CDM, or some equivalent, I ththink we're all arguing about a form of interoperability that doesn't really exist. Then, once we talk about coverages conforming to some data model, we're really talking about features ... and feature servers can delivercoverages. Me, while I think the WCS is temporarily important, it's not going to be important for long!Bryan
galeon archives: