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
    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.
    Angelos Tzotsos
    @kalxas
    +1
    David Huard
    @huard
    @tomkralidis Do you want to meet Wednesday morning to plan the owslib sprint ? If we are able to split the work into small easily digestible chunks, I could get some of my colleagues to pitch in.
    Tom Kralidis
    @tomkralidis
    hi all: we’re in https://meet.jit.si/geopython
    MacPingu
    @cehbrecht
    Opened an issue for client part of rest api wps implementation (OGC API - processes) to collect infos:
    geopython/OWSLib#749
    Tom Kralidis
    @tomkralidis
    thanks. We can jump on Jitsi if folks want?
    David Huard
    @huard
    Sounds good.
    Tom Kralidis
    @tomkralidis
    @cehbrecht ?
    MacPingu
    @cehbrecht
    I’m in :)
    Alex Kmoch
    @allixender
    Sorry I keep missing Tom's announcements 0.o
    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