Thx. Sounds promising. :Stefan
Am Mi., 22. Mai 2019 um 16:14 Uhr schrieb Tom Kralidis <tomkrali...@gmail.com>: > > The forthcoming OGC API Hackathon should help clarify much of these > discussions. > Agree with Chris' endpoint patterns. I would probably update the CSW > endpoints like: > > /collections/search > /search > > To be continued -- stay tuned! > > ..Tom > > On Sat, May 18, 2019 at 4:27 PM Stefan Keller <sfkel...@gmail.com> wrote: > > > > Dear Chris (dear all) > > > > Thanks, Chris, again for your detailed answer and explanation. > > > > We've implemented a tiny WFS3 server in Go and I'm just stumbled over > > the response requiring a “self-link” (rel=“self” which includes the > > collectionId). > > Is that really mandatory - and what's it used for? > > > > (Tell me where to move with this discussion if this list isn't the right > > place). > > > > :Stefan > > > > > > Am Fr., 3. Mai 2019 um 16:41 Uhr schrieb Chris Holmes > > <cholmes@radiant.earth>: > > > > > > Hey Stefan, I composed a pretty long message on my view on ideal > > > relationship between STAC and CSW, I'll paste it in below. The main > > > conceptual thing to me is that most CSW's have been about 'layer' level > > > search, and image / 'asset' level search is actually different. In OGC > > > history the 'ebrim profile' of CSW actually did the image / asset level > > > search well. But in my opinion they are different enough that we > > > shouldn't group them all in one thing. An asset level catalog > > > could/should be equivalent to a 'data cube', and so should slot at the > > > 'layer' level. > > > > > > As for schema.org, we've made attempts to align with it, but at the level > > > where STAC is transformed into HTML output. See > > > https://github.com/radiantearth/stac-spec/blob/dev/catalog-spec/catalog-best-practices.md#stac-on-the-web > > > for info on how we think about HTML & STAC, and in particular the > > > sub-section on schema.org, etc. > > > > > > The in depth view I wrote on csw and stac is: > > > > > > > > > The ideal relationship between CSW, WFS and STAC is that WFS _is_ the api > > > that all three use. STAC and CSW should just be specialized content - > > > they use the same API response, but the JSON responses must comply with > > > particular JSON Schemas. With STAC the core is id, geometry, datetime, > > > links and assets - > > > https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#item-fields > > > Any WFS Item that meets the STAC Schema could be considered part of > > > STAC. STAC also includes an ecosystem of more particular types that build > > > on that base. So the Electro-Optical extension has more fields that > > > comply to a schema that can be added and queried. The goal is to > > > encourage more bottom up communities of interest. But any of those can be > > > queried from the STAC endpoint. That's the vision at least, and we're > > > trying to align with WFS to do it, but there's more work needed, which > > > I'll detail below. > > > > > > Then to me CSW should be a set of fields that describe a collection of > > > data. So it'd have like title, license, keywords, spatial and temporal > > > extents, etc. Could theoretically just use the same fields that CSW 3.0 > > > defined, and make those a JSON content type. Define the schema, and then > > > a 'CSW 4.0' would just be a WFS 3 that serves up that content. WFS 3 > > > still hasn't quite specified its query language afaik, so maybe CSW4 > > > requires a particular richer query language. But it should be the same > > > query language that is at least an option for WFS. Thus any WFS client > > > could naively query a catalog, requesting the fields it needs and getting > > > the response. A CSW 4 client would be an extension to the WFS one that > > > perhaps takes advantage of some more expectations. It could be possible > > > that you would add like 'harvesting' extensions for CSW 4, but those > > > should be generic WFS API mechanisms. So a CSW is a WFS endpoint that > > > meets a set schema definition - whatever flavor of dublin core works best > > > - plus it may also specify some required WFS API extensions that should > > > be used. > > > > > > I do think there is an opportunity to combine WFS and CSW even more, by > > > aligning the schema of CSW with the response in the > > > /collection/{collectionId} endpoint in WFS. Like the way it defines > > > extents, title, etc. should be the same as the CSW JSON response. Ideally > > > CSW defines additional fields that are useful for defining a dataset, and > > > then the WFS /collection/{collectionId} endpoint can use those same > > > fields. This would make it so every WFS is 'harvestable' by a CSW. And > > > then any WFS could supply a special /collections/csw endpoint, that > > > exposes the metadata of all the other collections that are in that WFS. > > > > > > So basically CSW should be the summary of dataset / collection level > > > metadata, available through the WFS API. And then STAC is 'asset' level > > > metadata - references to other types of geographic files that can be > > > downloaded. So one could easily see a service that implements all three: > > > > > > /collections/buildings/ (a standard WFS layer - a set of vectors) > > > /collections/landsat/ (a STAC (and EO Extension) compliant WFS layer that > > > has every landsat scene available for search) > > > /collections/sentinel/ (another STAC & eo compliant WFS layer) > > > /collections/csw/ (the CSW endpoint, that has 3 records - the collection > > > level metadata for buildings, landsat and sentinel) > > > /stac/ - the browse endpoint for STAC, that returns STAC catalogs that > > > navigate down to individual records) > > > /stac/landsat/L8/166/077/ returns all a json STAC Catalog that returns > > > links to individual feature records in /collections/landsat/ > > > /stac/search/ - the endpoint that does cross collection search, returning > > > results from both landsat and sentinel. > > > > > > The 'collection level metadata' of the /collections/csw/items/ would be > > > the exact same fields returned at /collections/buildings, etc. > > > > > > In an ideal world we probably wouldn't even have /stac/search - that > > > would just be a standard WFS search endpoint that can do cross collection > > > search, which it sounds like people are maybe working on? > > > > > > That highlights that in STAC we do a few things that should just be done > > > in the WFS spec. Indeed any type of API construct, like querying and > > > transactions (which we do have in STAC), should be defined in WFS. STAC > > > could choose to use a particular set of API constructs, but they should > > > be more generic components at the WFS level. We have /stac/search/ > > > because WFS doesn't yet have cross collection search. We have a query > > > language because WFS's doesn't have one that meets our needs yet, etc. > > > The other thing WFS doesn't have is the 'static' browse ability, that we > > > have in /stac/, but I do think it would be a good addition, and then we > > > wouldn't really need to do anything 'special' - STAC would just be a set > > > of schemas to be used in WFS. > > > > > > We have actually aligned STAC even more with WFS, with our STAC > > > Collection using the same fields as a WFS collection. Though there were a > > > couple little things off about the WFS Collections. The goal to me is to > > > make a 'collection definition' of some set of core required fields, plus > > > additional dublin core/etc metadata fields that are optional. And that is > > > returned at /collections/{collectionId} but is also the same fields for a > > > CSW search, but even also defines coverages or other data types as well - > > > you have the same core construct of how you describe a 'layer'. > > > > > > On Fri, May 3, 2019 at 6:14 AM Stefan Keller <sfkel...@gmail.com> wrote: > > >> > > >> Thx for the quick info. > > >> Now I'm keen to learn more about SpatioTemporal Asset Catalog (STAC) > > >> and it's relationship to existing metadata standards (geo and general > > >> non-geo). > > >> :Stefan > > >> > > >> Am Fr., 3. Mai 2019 um 14:55 Uhr schrieb Scott Simmons > > >> <ssimm...@opengeospatial.org>: > > >> > > > >> > Hi Stefan, > > >> > > > >> > I can talk to WFS3. We now have a roadmap for all OGC candidate > > >> > standards under development (not fully populated, but those closest to > > >> > approval and a few others are in the roadmap): > > >> > http://www.opengeospatial.org/roadmap > > >> > > > >> > This roadmap will be more formally promoted in the coming weeks once > > >> > we get it fully populated. > > >> > > > >> > WFS3 (now being referred to as OGC API Features) is to be briefed to > > >> > both ISO / TC 211 and OGC in June in advance of approval voting in > > >> > each organization. No guarantees, but the OGC approval is forecast to > > >> > occur after our June Technical Committee Meeting (24-27 June) in > > >> > Leuven, Belgium. Voting takes about 2 months in total. > > >> > > > >> > Best Regards, > > >> > Scott > > >> > > > >> > Scott Simmons > > >> > Chief Operations Officer > > >> > Open Geospatial Consortium (OGC) > > >> > tel +1 970 682 1922 > > >> > mob +1 970 214 9467 > > >> > ssimm...@opengeospatial.org > > >> > > > >> > The OGC: Making Location Count… > > >> > www.opengeospatial.org > > >> > > > >> > On May 3, 2019, at 6:44 AM, Stefan Keller <sfkel...@gmail.com> wrote: > > >> > > > >> > Hi Chris > > >> > > > >> > Let me chime in here with two specific question about my understanding > > >> > of WFS3 and of STAC.. > > >> > A. When will WFS3 become an OGC standard? Is there a road a map? (I > > >> > know about the London Hackathon mid year) > > >> > B. What is the relationship of STAC with Catalog Service for Web > > >> > (CS-W) and metadata (schema.org) in general? > > >> > > > >> > :Stefan > > >> > > > >> > Am Do., 1. März 2018 um 14:33 Uhr schrieb Angelos Tzotsos > > >> > <gcpp.kal...@gmail.com>: > > >> > > > >> > > > >> > Thank you Chris for the information. > > >> > > > >> > Best regards, > > >> > Angelos > > >> > > > >> > On 03/01/2018 02:17 PM, Chris Holmes wrote: > > >> > > > >> > Just realized I forgot to reply to this, but that's a great idea. I'll > > >> > be > > >> > in Orleans for the OGC meetings, so will be on the same time zone. And > > >> > there's definitely some STAC collaborators who will be in Bonn. > > >> > > > >> > Note also that we're organizing a remote participation option for next > > >> > week. GeoSolutions is going to be working on implementing WFS 3 in > > >> > GeoServer and Even Rouault is going to be looking in to GDAL bindings > > >> > for > > >> > WFS 3.0 and STAC. Would be great for others in Europe to work on OSGeo > > >> > projects while we're working away in Ft. Collins. Obviously any WFS 3 / > > >> > STAC implementation & spec feedback in the next few weeks would be > > >> > great, > > >> > but we're hoping to be able to show lots of diverse progress next week. > > >> > > > >> > For more info see > > >> > https://medium.com/@cholmes/participate-remotely-in-the-wfs-hackathon-next-week-d11a99eb510b > > >> > and please sign up to participate at > > >> > https://goo.gl/forms/v8hyeJvd2yudYvZS2 > > >> > > > >> > best regards, > > >> > > > >> > Chris > > >> > > > >> > > > >> > > > >> > On Thu, Feb 15, 2018 at 8:15 PM, Angelos Tzotsos > > >> > <gcpp.kal...@gmail.com> > > >> > wrote: > > >> > > > >> > Thank you Chris for organizing this event and for reaching out to this > > >> > mailing list. > > >> > > > >> > I feel there is strong interest from our community to participate on > > >> > the > > >> > development of these new standards, and I know that there is ongoing > > >> > work > > >> > towards this from some OSGeo members, so I am sure you will see some > > >> > of us > > >> > in Ft Collins. > > >> > > > >> > Let's make an OGC/WFS/STAC Catalog session during the Bonn Code > > >> > Sprint: I > > >> > realized that the Orleans OGC TC meeting is on the same week as the > > >> > Bonn > > >> > code sprint. Perhaps we could all join a video call session during that > > >> > week? > > >> > > > >> > Best, > > >> > Angelos > > >> > > > >> > > > >> > > > >> > On 02/13/2018 03:34 AM, Chris Holmes wrote: > > >> > > > >> > Hello OSGeo-ers! > > >> > > > >> > I just wanted to make sure everyone knew about an event [1] I'm helping > > >> > organize, to bring together developers to give feedback on the > > >> > evolving WFS > > >> > 3.0 specification. It's organized by Open Geospatial Consortium (OGC), > > >> > and > > >> > sponsored by USGS, but the goal is make it different than a typical OGC > > >> > event. Indeed the direct inspiration is the code sprints that OSGeo > > >> > runs, > > >> > but to center it around a standard and give developers an opportunity > > >> > to > > >> > actually code against the spec _before_ it becomes an official > > >> > standard, > > >> > and to have any feedback incorporated. > > >> > > > >> > I'm not sure if many people have been following the progress of WFS > > >> > 3.0, > > >> > but it's been made more like how we build open source software, with an > > >> > open repository on github [2], and management of the spec through > > >> > issues > > >> > and pull requests. And it's JSON and RESTful at the core, aiming to be > > >> > much > > >> > easier to implement than existing OGC specs. For more backstory on it > > >> > and > > >> > my take on its potential see my blog posts [3]. > > >> > > > >> > I'd love to see a number of OSGeo people come, it's on March 6 & 7th > > >> > in Ft. > > >> > Collins, Colorado. Contributing I believe will help show OGC that > > >> > there is > > >> > interest in the wider developer and open source world if they do things > > >> > differently, and help evolve how they create standards to be more > > >> > compatible with how developers work. I'm also organizing a day on > > >> > March 8th > > >> > on SpatioTemporal Asset Catalog[4] [5], an open spec a group of us > > >> > started > > >> > working on to search satellite imagery archives, that I'm hoping we can > > >> > align with the WFS specification. If you're interested in WFS and/or > > >> > STAC > > >> > just email me and I can give you more details, or just fill out the > > >> > form athttps://goo.gl/forms/RqQtNbfdEOHuLE272 - there are some limited > > >> > travel > > >> > grants if that helps get there. > > >> > > > >> > I know travel may be tough for those also going to Bonn, as the OSGeo > > >> > sprint there is two weeks later. I am figuring out if we will do a > > >> > remote > > >> > participation option for Colorado, so email me if you're interested in > > >> > that. And Angelos had a great idea[6], of organizing a session on > > >> > WFS/STAC > > >> > at Bonn, which I'd love to see. Drop me a line if you are attending the > > >> > OSGeo code sprint and interested in attending (or leading :) a session > > >> > there. > > >> > > > >> > best regards, > > >> > > > >> > Chris > > >> > > > >> > > > >> > [1]https://medium.com/@cholmes/wfs-3-0-and-spatiotemporal-asset-catalog-stac-in-person-collaboration-609e10d7f714 > > >> > [2] https://github.com/opengeospatial/WFS_FES > > >> > [3] https://medium.com/tag/wfs-3/latest > > >> > [4] https://github.com/radiantearth/stac-spec/ > > >> > [5] https://medium.com/tag/stac-spec/latest > > >> > [6] https://twitter.com/tzotsos/status/963081024187060225 > > >> > > > >> > > > >> > > > >> > _______________________________________________ > > >> > Discuss mailing > > >> > listDiscuss@lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/discuss > > >> > > > >> > > > >> > -- > > >> > Angelos Tzotsos, PhD > > >> > Charter Member > > >> > Open Source Geospatial Foundationhttp://users.ntua.gr/tzotsos > > >> > > > >> > > > >> > > > >> > -- > > >> > Angelos Tzotsos, PhD > > >> > Charter Member > > >> > Open Source Geospatial Foundation > > >> > http://users.ntua.gr/tzotsos > > >> > > > >> > _______________________________________________ > > >> > Standards mailing list > > >> > standa...@lists.osgeo.org > > >> > https://lists.osgeo.org/mailman/listinfo/standards > > >> > > > >> > _______________________________________________ > > >> > Standards mailing list > > >> > standa...@lists.osgeo.org > > >> > https://lists.osgeo.org/mailman/listinfo/standards > > >> > > > >> > > > _______________________________________________ > > Standards mailing list > > standa...@lists.osgeo.org > > https://lists.osgeo.org/mailman/listinfo/standards _______________________________________________ Discuss mailing list Discuss@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/discuss
