Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    Tom Kralidis
    @tomkralidis
    lolol
    Alex Kmoch
    @allixender
    I'm in Europe, I guess my time slots are slightly shifted too. I'll join "my" tomorrow morning :tired_face:
    I'll be active in pygeoapi
    Tom Kralidis
    @tomkralidis
    great Alex! Have a good day
    MacPingu
    @cehbrecht

    We are working on a first version of the ogcapi-processes implementation:
    geopython/OWSLib#749

    Today I’m looking at using notebooks for documentation:
    geopython/OWSLib#752

    Tom Kralidis
    @tomkralidis
    Excellent!
    Just van den Broecke
    @justb4
    @cehbrecht +1 for Notebooks! We used these also in the GeoPython Workshop, also for OWSLib and I just saw Anita's AT lab here
    MacPingu
    @cehbrecht
    @justb4 :thumbsup:
    Angelos Tzotsos
    @kalxas
    nice!
    Alex Kmoch
    @allixender
    :thumbsup:
    David Huard
    @huard
    I've looked at the automated Data Model generation from schemas and it's not smooth sailing... the codegen utility is not smart enough to name all data models correctly, so there's going to be some editing needed. The autogenerated client from OpenAPI seems more solid, but it also needs editing to avoid repeat copies of boilerplate code. I've also looked at FastAPI, which also has an automated client generator, but it chokes on unresolved references... The FastAPI way to designing the client probably deserves to be looked at for inspiration. https://github.com/dmontagu/fastapi_client
    Tom Kralidis
    @tomkralidis
    @huard / @cehbrecht I’ve refactored collections as discussed yesterday: geopython/OWSLib#753
    MacPingu
    @cehbrecht

    @huard / @cehbrecht I’ve refactored collections as discussed yesterday: geopython/OWSLib#753

    :thumbsup:

    Tom Kralidis
    @tomkralidis
    @huard I’ve added you to the OWSLib team on GitHub. You should receive a notification
    David Huard
    @huard
    I did thanks.
    David Huard
    @huard

    Is it possible there is a mismatch between the ogcapi-processes/core/examples/json/ProcessDescription.json and the schema ? The literalInput object has

    "input": {
                "literalDataDomain": {
                    "dataType": {
                      "name": "double"
                    },
                    "valueDefinition": {
                        "anyValue": true
                    }
                }
            },

    but the schema for literalDataType says:

    type: object
    required:
      - literalDataDomains
    properties:
      literalDataDomains:
        type: array
        items:
          $ref: "literalDataDomain.yaml"

    To be clear, I see too mismatches: literDataDomain instead of literalDataDomains (with an s), and the fact that it should be an array.

    David Huard
    @huard

    The 52N server has the same issue. Also, it has

    {'literalDataDomain': {'dataType': 'string',
      'valueDefinition': {'anyValue': True}}}

    but dataType should be a dict with a name key.

    Anyway, it looks like using pydantic to validate objects seems to be a good idea. It really helps catching those mismatches.
    Francesco Bartoli
    @francbartoli
    @huard yep we could benefit for the validation even in the server side to assure the returned payload is respecting the types of specification
    paul van genuchten
    @pvgenuchten
    does anyone know if the graphic-overview gets parsed as part of the iso19139 parser? if so, where is it in the python structure?
    David Huard
    @huard
    Should I submit an issue to ogcapi-processes for these discrepancies ? And also mention that we're working on a client ?
    MacPingu
    @cehbrecht

    Should I submit an issue to ogcapi-processes for these discrepancies ? And also mention that we're working on a client ?

    I think that would be good.

    Tom Kralidis
    @tomkralidis
    @huard +1, agree with Carsten. As well, it would be very valuable for you to demo/talk to this at today's closing demos for the sprint. Folks were asking about pydantic, I showed your PR but didn't do it justice. Are you able to demo?
    Francesco Bartoli
    @francbartoli
    @huard any link to the code where to look at?
    MacPingu
    @cehbrecht
    currently in this PR: geopython/OWSLib#755
    using this issue to track the ogcapi.processes implementation:
    geopython/OWSLib#749
    David Huard
    @huard
    Could do a very superficial demo at 12h EST or 15h EST. I'm getting a lot of clashes between the examples, the schema and the models.
    Tom Kralidis
    @tomkralidis
    where is the actual code/workflow that generates the Python?
    David Huard
    @huard
    eh... it's a manual process... the automated workflow had hiccups.
    It's datamodel-codegen applied to individual files, then copy pasted with a few fixes.
    Tom Kralidis
    @tomkralidis
    ugh
    David Huard
    @huard
    There may be hope to clean that. I don't really know what I'm doing to be frank.
    MacPingu
    @cehbrecht

    Hi @cehbrecht : we added a CSW 3 client to. master. Any objections to 0.24.0 release? I know we did 0.23.0 recently, but the CSW 3 client is a big feature that we need to ref in downstream tools.

    @tomkralidis do you want to do a release after the sprint?

    @huard can i merge?:
    geopython/OWSLib#755

    I can integrate the model with the existing code and look at the failures ...

    David Huard
    @huard
    @cehbrecht Yes
    MacPingu
    @cehbrecht

    @cehbrecht Yes

    :thumbsup:

    David Huard
    @huard
    I think the testing strategy should be to start with the most simple objects and work our way up.
    Tom Kralidis
    @tomkralidis
    so everything has a parse_obj method?
    David Huard
    @huard
    yes
    most objects should also work with Model(**dict)
    Tom Kralidis
    @tomkralidis
    we should have started to implement this at the same time with different approaches and see who got done first ;)
    David Huard
    @huard
    ; )
    Francesco Bartoli
    @francbartoli
    Yep, and you get the validation by design
    The nicest thing is that you can even use the outer models for HTTP responses, query string params and body. That’s actually what FastAPI is doing natively
    MacPingu
    @cehbrecht
    @huard there is a demo for ogcapi-processes now:
    https://global.gotomeeting.com/join/978960909
    Francesco Bartoli
    @francbartoli
    but I’m a too much early fan to be considered as an honest opinion 😁
    paul van genuchten
    @pvgenuchten
    Hi, I'm looking at qgis metasearch for oarec, i noticed the oarec implementation differs quite a bit from the csw implementation, one aspect is even conflicting: CatalogueServiceWeb stores its search results at self.catalog.records, where oarec has a method at self.records(). What is your view on this, the goal is to aligns these implementations at some point, or should be considered to be differently, since the nature of the service is quite different?
    Tom Kralidis
    @tomkralidis
    I would keep these distinct, given OWSLib’s OARec support (like OGC API in general) is a clean break.
    David Huard
    @huard
    Hi @tomkralidis , I'm struggling to understand how reconcile how pygeoapi processes execution works with the schemas defined in ogcapi-processes. The hello-world process in pygeoapi requires inputs that do not seem to match the schema defined in "InlineOrRefData" (id, type).
    Tom Kralidis
    @tomkralidis
    hi @huard the OAProc implementation is draft as we await changes made to OAProc proper. We do need to revisit what the spec looks like today