-
-
Notifications
You must be signed in to change notification settings - Fork 155
Meetings 2017 02 06
Monday 06 February 2017 1400h UTC
https://gitter.im/geopython/pycsw
- Review of action items
- RFC8
- pyfes status/update
- repository plugins (ElasticSearch)
- OAI/SRU support
- Python 3 based packages
- Google Summer of Code 2017 via OSGeo
- @ricardogsilva - Ricardo Garcia Silva
- @tomkralidis - Tom Kralidis
-
A: Review RFC8 - DONE RFC8 has been reviewed and merged into master
-
B: Create pyfes repository under geopython umbrella - DONE See https://github.com/geopython/pyfes
-
C: Prepare a roadmap for pyfes development - DONE (mostly) See https://github.com/geopython/pyfes/projects - still needs some more detail
-
Commit history has been cleaned up and work has been reviewed
-
The PSC has voted favorably and code has been merged into pycsw master branch on github as of e952e064cc24c26dfad4625162f36a12f6775bdf
-
@ricardogsilva is working on some follow up stuff:
- A set of unit tests for
pycsw.core.util
. This can serve as an example of how to set up unit tests - A Pull Request with Work in Progress will become visible until the end of the week - Integration with some coverage analysis service, like codecov (action A)
- A set of unit tests for
-
In order to make the code easier to test, it would beneficial to refactor some big methods in
pycsw
into smaller methods/functions
-
@ricardogsailva has been re-reading the FESv2.0.2 standard in order to gain a better insight on the requirements
-
The initial implementation seems overly simplistic, as most FES types had been modelled as
namedtuple
types. After consideration of validation constraints, it seems more appropriate to model them as full blown python classes. -
A roadmap has been setup for pyfes. It needs some more detail
-
@tomkralidis offered to contribute development effort/time as part of his attendance to OSGEO Code Sprint. @ricardogsilva will prepare some materials to guide @tomkralidis work (action B)
-
pyfes must also implement version 1 of FES standard.
- @tomkralidis has been working on an ElasticSearch backend for pycsw. There are some promising preliminary results on his private dev infrastructure.
- However, work is still blocked by lack of a tool to translate FES expressions into ES syntax. Hopefully pyfes will provide a breakthrough here.
- No update from the situation reported on the previous meeting
- Now that pycsw is ported to Python3, it would be beneficial to have Debian/UbuntuGIS packages for it
- @kalxas will provide a summary on the effort/constraints related to this topic (action C)
-
Pycsw is participating in OSGEO's GSOC offerings for the first time with some ideas.
-
Some additional ideas have been briefly discussed:
-
Refactoring some of pycsw's big methods into smaller functions (might be hard for a student, as it requires some knowledge of the codebase as a whole)
-
Creating more unit tests in order to raise our code coverage marks (might be somewhat boring for a student)
-
Refactoring
pycsw-admin.py
, as previsouly discussed on the mailing-list
-
-
The HTTP API topic has also been discussed. It seems we might addopt some established web framework for this, like werkzeug, cherrypy, flask, bottle, etc (lots of frameworks out there)
-
@tomkralidis will open up a new wiki page for discussing ideas and setting up some sort of specification for this topic (and perhaps maybe for the other topics as well?) (action D)
- Lets spend some time on pyfes, as it will enable other interesting features
- A: @ricardogsilva will experiment with a code coverage service and will bring it to the mailing-list for further discussion (tentatively until 13 February)
- B: @ricardogsilva will prepare some materials for guiding @tomkralidis efforts in pyfes development during his OSGEO Code Sprint Week
- C: @kalxas will provide a summary on Py3 packaging for next meeting
- D: @tomkralidis will open up a space in pycsw's wiki for discussion of GSOC topics
Next meeting should happen in about 4 weeks - probably on 6th March