search

opengeospatial / OGCAPI-EDR-Sprint2

This Github repository is for the second OGC API - EDR code sprint focusing on the OGC API - Environmental Data Retrieval candidate standard.
1 stars 6 forks source link

What is everybody going to be working on? #1

Closed ghobona closed 3 years ago

ghobona commented 4 years ago

Post a comment letting us know what you are going to be working on.

chris-little commented 4 years ago

As my coding and scripting days are long past and I am now a 'suit', I will be gathering issues, requirements, outcomes, etc., and publishing on GitHub. And influencing. (If I was there in person, I would probably be running around distributing coffee, pizza and beer)

dblodgett-usgs commented 4 years ago

My hope is to plan and perhaps start an EDR API server wrapping USGS streamflow web services. Will follow the mock up here. https://github.com/opengeospatial/Environmental-Data-Retrieval-API/wiki/Monitoring-network-mockup

jkreft-usgs commented 4 years ago

I (or potentially others as interested) would be interested in building out a client based on one of the openAPI code generation tools.

chris-little commented 4 years ago

@PeterTrevelyan will work on examples, potentially to go the spec annex or a Best Practice document

chris-little commented 4 years ago

@iandruska-ibl will be focussing on metadata exposure from IBL's server, using C++. IBL's server has a wide range of data types

chris-little commented 4 years ago

@m-burgoyne will probably work on:

  1. a VisualCode++ extension to easily test and extend schemas

  2. try to implement API on the fisheries use case and its OGC standard datastores

chris-little commented 4 years ago

@ShaneMill1 will probably build some test scripts, perhaps using SmartBear, focussing on valid queries to keep a narrow scope.

iandruska-ibl commented 4 years ago

In general, I would like to test interoperability on metadata level.

In our software, we have this GUI dialog for browsing NWP datasets: Screenshot from 2020-11-05 16-23-38

My plan is to implement an EDR backend into this dialog and to test it against all implementations. Goal is to identify missing/deficient information, inconsistencies or any issues with metadata that might pose unnecessary obstacles to implementers.

ShaneMill1 commented 4 years ago

@ShaneMill1 will probably build some test scripts, perhaps using SmartBear, focussing on valid queries to keep a narrow scope.

In addition to test scripts, I will be in coordination with @m-burgoyne regarding implementations

boyi-shangguan commented 4 years ago

WHU plans to develop a use case client demo of "Flood Disaster Decision Support System" to use EDR API to gather data, instead of using a WPS workflow to extract data of interesting area from WCS or WFS server originally. 1 2

StephanSiemen commented 4 years ago

Anyone needs some helping hands? I am otherwise play with pygeoapi and see how it can be possibly be the frontend at ECMWF for an EDR interface to our data. @tomkralidis is there anything you need help with in pygeoapi for supporting EDR? Any area need more testing?

NazihFino commented 4 years ago

my plan is to test ArcGIS server enterprise ( AWS cloud)

ludona7 commented 4 years ago

Hi, as a newcomer I just want to play around with the API from the client side. I noticed 2 of the demos looked almost identical in terms of styling, so thought they may have used a common base for the client UI. I saw the leaflet plugin (https://github.com/Reading-eScience-Centre/leaflet-coverage) but I'm curious to know if a 'full' generic client/UI is available anywhere to use as a starting point?

PeterTrevelyan commented 4 years ago

Hi Nazih, Do you have an ESRI image server with data already loaded? Pete T

From: NazihFino notifications@github.com Sent: 09 November 2020 15:56 To: opengeospatial/OGCAPI-EDR-Sprint2 OGCAPI-EDR-Sprint2@noreply.github.com Cc: Trevelyan, Pete peter.trevelyan@metoffice.gov.uk; Mention mention@noreply.github.com Subject: Re: [opengeospatial/OGCAPI-EDR-Sprint2] What is everybody going to be working on? (#1)

This email was received from an external source. Always check sender details, links & attachments.

my plane is to test ArcGIS server enterprise ( AWS cloud)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/OGCAPI-EDR-Sprint2/issues/1#issuecomment-724102169, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJVX4LIIYEVXSVHAUAJITK3SPAGJHANCNFSM4STJTBMA.

tomkralidis commented 4 years ago

As time permits, I'll be looking into metadata models for search based on OGC API - Records as well as try to cover any pygeoapi EDR integration.

NazihFino commented 4 years ago

@PeterTrevelyan

no, not the image server.

PeterTrevelyan commented 4 years ago

I am having problems s with the internet here. Will let you know as soon as it returns to normal. Can I have your email address so I can send you an invite. Pete

From: NazihFino notifications@github.com Sent: 09 November 2020 15:56 To: opengeospatial/OGCAPI-EDR-Sprint2 OGCAPI-EDR-Sprint2@noreply.github.com Cc: Trevelyan, Pete peter.trevelyan@metoffice.gov.uk; Mention mention@noreply.github.com Subject: Re: [opengeospatial/OGCAPI-EDR-Sprint2] What is everybody going to be working on? (#1)

This email was received from an external source. Always check sender details, links & attachments.

my plane is to test ArcGIS server enterprise ( AWS cloud)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/opengeospatial/OGCAPI-EDR-Sprint2/issues/1#issuecomment-724102169, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJVX4LIIYEVXSVHAUAJITK3SPAGJHANCNFSM4STJTBMA.

ethanrd commented 3 years ago

I’m using this sprint as a time to catch up on the details of the EDR API and start mapping it to the THREDDS framework (conceptually, not coding yet). We will be working on implementing basic EDR API support in the THREDDS Data Server in the next 6-12 months, starting with support for the point query.

chris-little commented 3 years ago

Hi, as a newcomer I just want to play around with the API from the client side. I noticed 2 of the demos looked almost identical in terms of styling, so thought they may have used a common base for the client UI. I saw the leaflet plugin (https://github.com/Reading-eScience-Centre/leaflet-coverage) but I'm curious to know if a 'full' generic client/UI is available anywhere to use as a starting point?

@ludona7 A 'full' generic client is actually a browser with a URL input box! And a JSON stylesheet. Some are using pyegeoapi and leaflet. One of the driving use cases was to get away from people having to mess around with GeoServer, GDAL etc. The intellikgence really is in the server exposing the correct query responses. Does that make sense?

chris-little commented 3 years ago

I’m using this sprint as a time to catch up on the details of the EDR API and start mapping it to the THREDDS framework (conceptually, not coding yet). We will be working on implementing basic EDR API support in the THREDDS Data Server in the next 6-12 months, starting with support for the point query.

@ethanrd Please talk to @dblodgett-usgs as he seems to have that clear. I think the THREDDS perspective is that a datastore/Collection/Geospatial Data with an EDR API in front is a distribution. Good to hear we are in your plans!

ethanrd commented 3 years ago

@chris-little - Thanks. Yes, I've talked with @dblodgett-usgs about this some, will definitely talk more.

paul-breen commented 3 years ago

@ludona7 A 'full' generic client is actually a browser with a URL input box! And a JSON stylesheet. Some are using pyegeoapi and leaflet. One of the driving use cases was to get away from people having to mess around with GeoServer, GDAL etc. The intellikgence really is in the server exposing the correct query responses. Does that make sense?

Hi @chris-little. I'm struggling to understand that, I'm afraid! If we wanted to run the same UI that you used in your demo, how would we go about it? Is there an online instance of that UI we can access, or can we run it locally on our own laptops? If the latter, what do we need to install and from where?

chris-little commented 3 years ago

@ludona7 A 'full' generic client is actually a browser with a URL input box! And a JSON stylesheet. Some are using pyegeoapi and leaflet. One of the driving use cases was to get away from people having to mess around with GeoServer, GDAL etc. The intellikgence really is in the server exposing the correct query responses. Does that make sense?

Hi @chris-little. I'm struggling to understand that, I'm afraid! If we wanted to run the same UI that you used in your demo, how would we go about it? Is there an online instance of that UI we can access, or can we run it locally on our own laptops? If the latter, what do we need to install and from where?

@paul-breen Issue/Task17 by @jkreft-usgs is one approach to clients. @m-burgoyne can give you some pointers to the apporach that you outlined.

chris-little commented 3 years ago

All the tasks identified above have been copied into separate Issues (#16 to #26). Please continue discussions there.