Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 16 21:46
    l0b0 commented #686
  • May 13 22:35
    captaincoordinates edited #688
  • May 13 21:18
    captaincoordinates opened #688
  • May 13 14:12
    jmbelanger commented #686
  • May 13 11:42
    KoalaGeo edited #687
  • May 13 11:42
    KoalaGeo labeled #687
  • May 13 11:42
    KoalaGeo opened #687
  • May 11 06:39
    ldesousa commented #615
  • May 10 13:18
    ksonda commented #615
  • May 10 13:05
    ldesousa commented #615
  • May 10 11:17
    ksonda commented #615
  • May 10 11:16
    ksonda commented #615
  • May 10 08:11
    ldesousa commented #173
  • May 10 08:04
    ldesousa commented #615
  • May 08 00:17
    tomkralidis commented #686
  • May 07 15:33
    ksonda commented #615
  • May 07 04:14
    ksonda commented #173
  • May 07 04:08
    ksonda commented #173
  • May 07 04:07
    ksonda commented #173
  • May 07 04:03
    ksonda commented #173
jmckenna
@freenode_jmckenna:matrix.org
[m]
request for pygeoapi PSC: please add into your release process, actually creating a 'release' on Github so that all 'followers' are magically notified. eg. go here and look at bottom-right panel, empty releases section: https://github.com/geopython/pygeoapi versus go here and look at lower-right 'releases' section: https://github.com/MapServer/MapServer That automated notice of the release sent by Gihub, is now as important as the old email
notices to the mailing list. thanks!
Tom Kralidis
@tomkralidis
good idea jmckenna. Trying this out
jmckenna
@freenode_jmckenna:matrix.org
[m]
thanks
@tomkralidis: very nice, received! VIP
Tom Kralidis
@tomkralidis
thank you jmckenna for the suggestions and continuous improvement. VIP
Note I've added this step to our release management page: https://github.com/geopython/pygeoapi/wiki/ReleaseManagement#step-9
jmckenna
@freenode_jmckenna:matrix.org
[m]
perfect, great document. thanks!
Sander Schaminee
@GeoSander
Hi @tomkralidis. I guess you were too busy last week with the presentations and so on, but this is just a friendly reminder to have a look at PR #664 :)
Tom Kralidis
@tomkralidis

thanks @GeoSander I had a look and #664 looks a bit less invasive to the providers, great :). Some questions:

  • the docs would have to be updated (I am guessing you left the docs as is while we decide on which PR to move forward with)
  • in pygoeapi config, why do we break out links into en and fr as well? Shouldn’t their hreflang be enough? I’m good with doing language for string properties but for entire objects?
  • it looks like the pygeoapi.api.pre_process decorator and request header handling has been fixed/cleaned up via the APIRequest object
  • can you provide an overview of where/how to use the APIRequest object?
  • https://github.com/geopython/pygeoapi/pull/664/files#diff-f3ee4caa7dc224a51caf333d89b130fe02ff0351a77dfdd11c06d0a4b56e6732R755 : passing language to a coverage function? Do we need this?

Overall, I think we are close here, and while putting language so deep into the data codepaths is new for me, this work does move the yardstick on multilingual support. Great work!

I did add a few others to review the PR, and would want at least one of them to do a fulsome review of the PR as well.

10 replies
Rob
@robrichter

Hi all.
At first I want to thank you for a great work.
I am participating on a project where I would like to use Pygeoapi.
I have a few questions about functionality I need on my project that I was not able to find in documentation.

  1. Transactions
    PR: geopython/pygeoapi#524

  2. CQL filters
    PR: geopython/pygeoapi#478

  3. Custom projection (epsg: 5514)
    PR: geopython/pygeoapi#307

I found pull requests that didn't make it to master. Is it planned to finish them? What is the blocker? Can I help it myself?
Thanks

Francesco Bartoli
@francbartoli
Hi @robrichter, those PRs 1. and 2. were provided during the GSoC last year. They are both a good starting point for those features but definitively cannot be merged as they are. And definitively to be improved as well. About the CQL filters for the JSON dialect in the ES provider there is a PR opened geopython/pygeoapi#670. It is a working in progress yet
Sander Schaminee
@GeoSander
@tomkralidis I have updated PR #664 once again according to your suggestions earlier. I really hope someone else can have a look too...
I put some code examples in the docstring of the APIRequest class as well.
Tom Kralidis
@tomkralidis
thanks Sander. I think Francesco will review soon.
Sander Schaminee
@GeoSander
:+1: :grinning:
Chris Barrett
@christophersbarrett
Hi all, I'm having trouble with relative paths - for example I am deploying pygeoapi as a docker container to a Fargate cluster on AWS ECS. The cluster is access through ALB (load balancer) which also assigns a domain to the ip address. I'd like pygeoapi to be accessible from the path <domain>/pygeoapi. I have that working, but none of the links work in the UI. So the link is constructed as <domain>/pygeoapi/collections, but it 404s
So in short, pygeoapi image is accessible at the path we want - but none of the links work. So app routing isn't working it seems like. Server config in local config:
server:
bind:
host: 0.0.0.0
port: 80
url: /pygeoapi
mimetype: application/json; charset=UTF-8
encoding: utf-8
language: en-US
cors: true
Another clue: it can't find the static resources either.
Just van den Broecke
@justb4
@christophersbarrett are you following config conventions as described here?
Chris Barrett
@christophersbarrett
I have SCRIPT_NAME hard coded in entrypoint.sh:
SCRIPT_NAME="/pygeoapi"
But I don't see where it's actually consuming? It's not passed into gunicorn's start?
Just van den Broecke
@justb4
Mm, SCRIPT_NAME is usually set in the Docker environment like docker-compose. It is something Flask-specific, not gunicorn. It needs to be in the global env. Two hints you may try:
export SCRIPT_NAME="/pygeoapi" and local config url: /pygeoapi IMO must be external/full URL.
Chris Barrett
@christophersbarrett
I just added SCRIPT_NAME="/pygeoapi" to the docker file as an ENV, not sure if that is the right approach.
Oh, so the url config should have domain/pygeoapi?
Just van den Broecke
@justb4
yes, that is what we use in most deployments like the demo server: url: https://demo.pygeoapi.io/master plus ```
environment:
  • SCRIPT_NAME=/master
    ```
    in docker-compose.yml.
Chris Barrett
@christophersbarrett
okay, i'll give that a try as well :) It's interesting that the urls in the templates are being constructed properly, but the app isn't routing correctly
Chris Barrett
@christophersbarrett
@justb4 made changes: put whole url in server config in config yml file, added SCRIPT_NAME env var in docker file - neither made any difference unfortunately
can you think of anything else that might contribute to it failing to route? How is SCRIPT_NAME actually used as an env variable? I see it used in severless wsgi - but that file isn't used afaict when you are running in a docker container?
Chris Barrett
@christophersbarrett
2021-04-09 14:32:49[2021-04-09 20:32:49 +0100] [20] [ERROR] Error handling request /
2021-04-09 14:32:49Traceback (most recent call last):
2021-04-09 14:32:49File "/usr/lib/python3/dist-packages/gunicorn/workers/base_async.py", line 55, in handle
2021-04-09 14:32:49self.handle_request(listener_name, req, client, addr)
2021-04-09 14:32:49File "/usr/lib/python3/dist-packages/gunicorn/workers/ggevent.py", line 143, in handle_request
2021-04-09 14:32:49super().handle_request(listener_name, req, sock, addr)
2021-04-09 14:32:49File "/usr/lib/python3/dist-packages/gunicorn/workers/base_async.py", line 94, in handle_request
2021-04-09 14:32:49resp, environ = wsgi.create(req, sock, addr,
2021-04-09 14:32:49File "/usr/lib/python3/dist-packages/gunicorn/http/wsgi.py", line 183, in create
2021-04-09 14:32:49path_info = path_info.split(script_name, 1)[1]
2021-04-09 14:32:49IndexError: list index out of range
Chris Barrett
@christophersbarrett
So I put SCRIPT_NAME='/pygeoapi' into CDK's container start up environment variables, and it does appear to be taking effect inside of the startup logs. However, I still get this error ^ as well as the routing still isn't working for anything other than the root page
Another thing to note, if I build this image and run it locally - it does work fine. Which is very annoying.
localhost:5000/pygeoapi/collections, etc
If thats transferable to your setup
Just van den Broecke
@justb4
@christophersbarrett : @KoalaGeo shows the same conventions (url + SCRIPT_NAME) as I mentioned above when using a domain plus subpath. Providing GitHub or other code paths helps us to understand your deployment-context. My AWS knowledge is minimal.
Tom Kralidis
@tomkralidis
@kalxas @francbartoli @justb4 @jorgejesus @pvgenuchten I’d like to have a PSC Gitter meeting. Is anyone around this Friday at 11h or 12h UTC?
Just van den Broecke
@justb4
@kalxas @francbartoli @justb4 @jorgejesus @pvgenuchten friday ok with me 11 or 12 UTC.
Angelos Tzotsos
@kalxas
ok for me
Tom Kralidis
@tomkralidis
@pvgenuchten @francbartoli ?
I spefically want to address the multilingual and CQL PRs
Francesco Bartoli
@francbartoli
Sorry folks, it’s hard for me this week. What about Monday 19th at the same time?
Tom Kralidis
@tomkralidis
how about Monday 19 April at 11h or 12h UTC?
Francesco Bartoli
@francbartoli
It works for me @tomkralidis
Sander Schaminee
@GeoSander
Looking at @pvgenuchten 's calendar (if it's up to date), I think that 11h UTC works best next Monday. He has another meeting at 12 UTC. I could also join silently and perhaps answer some questions about the multilingual PR, if needed.
Tom Kralidis
@tomkralidis
thanks Sander. I will let @pvgenuchten confirm and then setup the agenda/call the meeting on the mailing list.
paul van genuchten
@pvgenuchten
both fine for me