Difference between revisions of "Java 2017 Code Sprint"
| Line 1: | Line 1: | ||
The current plan is for the Java tribe to meet in Italy at the start of March. This page will allow us to plan the event. | The current plan is for the Java tribe to meet in Italy at the start of March. This page will allow us to plan the event. | ||
| − | We will be hosted at the GeoSolutions offices in beautiful Tuscany for | + | We will be hosted at the GeoSolutions offices in beautiful Tuscany for a week long sprint. |
| − | a week long sprint. | ||
Questions: | Questions: | ||
| + | |||
# Who would be interested in joining as a participating? | # Who would be interested in joining as a participating? | ||
# Who would be interested in sponsoring? ;-) | # Who would be interested in sponsoring? ;-) | ||
# Do you have any preferred week between say Feb 13 and end of March? | # Do you have any preferred week between say Feb 13 and end of March? | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
== Participants == | == Participants == | ||
| Line 37: | Line 26: | ||
| 3 || Andrea Antonello || Italy || HydroloGIS || || || gvSIG and cross-project ideas || I have a strong preference for the end of March | | 3 || Andrea Antonello || Italy || HydroloGIS || || || gvSIG and cross-project ideas || I have a strong preference for the end of March | ||
|- | |- | ||
| + | |||
| + | == GeoServer == | ||
| + | |||
| + | The GeoServer team really benefited from [[GeoServer Code Sprint 2016|geoserver code sprint 2016]] and is eager to repeat the success. | ||
| + | === Plans === | ||
| + | |||
| + | We are still at the planning stage so please let us know if a particular topic interests you or would be a deal breaker. The sprint does not have to be a single topic, if we can swarm a large beast good, but if someone wants to join and work on a side topic to leverage the presence of others, that’s good too. | ||
| + | |||
| + | ==== CITE ==== | ||
| + | |||
| + | CITE - upgrade the test harness, make sure the tests are still passing (probably they won’t), add new test that we are missing, WFS 2.0, WCS 2.0, CSW, WMTS 1.0, WPS 1.0, maybe GML and KML and GeoPackage, maybe stand up a reference server for OGC to use, with one test per workspace/virtual service? | ||
| + | |||
| + | ==== REST API Update and and Documentation ==== | ||
| + | |||
| + | REST API switch to Spring MVC (Andrea and Ian worried about making things worse user wise in terms of bugs) --- idea can we couple also fixing the actual bug reports in Jira? What about the other modules using restlet, importer and resource-rest-api, rest-upload, sldService, anything else? Need quite a bit of people. | ||
| + | |||
| + | ==== Mapbox Style ==== | ||
| + | |||
| + | The GeoServer application can be extended to work with multiple styling languages (SLD, CSS, YSLD). Mapbox has recently defined an open standard for drawing vector tiles that has been picked up by not only their own software but by the OpenLayers team. Initial investigation into this standard shows that it is a "whole" map standard similar to "sld" describing both the layers that make up the map, and the symbology used to represent them visually. | ||
| + | |||
| + | While some features (3d extrusions, camera and lighting angle) are not suitable for use by GeoServer the rest of it looks quite fun. | ||
| + | |||
| + | References: | ||
| + | |||
| + | - https://www.mapbox.com/mapbox-gl-style-spec/ | ||
| + | - https://boundlessgeo.com/2017/01/using-mapbox-style-objects-open-layers/ | ||
| + | |||
| + | Rough planning: | ||
| + | |||
| + | * Focus on styling a single layer using a mapbox style | ||
| + | ** Requires a parser for mapbox style capable of producing the internal geotools style objects; package as a geotools community module. | ||
| + | ** Setup geoserver extension and integration for new style format | ||
| + | * Whole map styling | ||
| + | ** LayerGroup defines both an order of layers, and the style associated with each layer - this information can be defined from a single mapbox style | ||
| + | ** (Optional) Consider offering SLD the same ability to define a LayerGroup | ||
| + | |||
| + | ==== Library upgrades ==== | ||
| + | |||
| + | Last year's sprint was devoted to updating a key library and required all hands on deck to help make the transition a smooth one. Ideally we would like to stay on top of library upgrades; however often a change to one has a cascade effect as we need to update (and test) each library in turn. | ||
| + | |||
| + | |||
| + | |||
| + | |||
| + | == GeoTools == | ||
| + | |||
| + | == Plans === | ||
| + | |||
| + | The GeoTools codebase has a number of smaller of ideas that may of be of interest to volunteers: | ||
| + | |||
| + | * JDK 9 + maybe JDK 8 updates in the code base (like stream ready support for feature collection, where we can use lambda for profit) | ||
| + | * JDK 9 replacement for plugin system (service registry) is required | ||
| + | |||
| + | The above ideas may also be suitable to anyone attending remotely who like the focus and support of a dedicated code sprint block on the calendar. | ||
Revision as of 15:10, 16 January 2017
The current plan is for the Java tribe to meet in Italy at the start of March. This page will allow us to plan the event.
We will be hosted at the GeoSolutions offices in beautiful Tuscany for a week long sprint.
Questions:
- Who would be interested in joining as a participating?
- Who would be interested in sponsoring? ;-)
- Do you have any preferred week between say Feb 13 and end of March?
Participants
Please add your name and the projects you are planning to sprint and note the likehood of your attendance.
GeoServer
The GeoServer team really benefited from geoserver code sprint 2016 and is eager to repeat the success.
Plans
We are still at the planning stage so please let us know if a particular topic interests you or would be a deal breaker. The sprint does not have to be a single topic, if we can swarm a large beast good, but if someone wants to join and work on a side topic to leverage the presence of others, that’s good too.
CITE
CITE - upgrade the test harness, make sure the tests are still passing (probably they won’t), add new test that we are missing, WFS 2.0, WCS 2.0, CSW, WMTS 1.0, WPS 1.0, maybe GML and KML and GeoPackage, maybe stand up a reference server for OGC to use, with one test per workspace/virtual service?
REST API Update and and Documentation
REST API switch to Spring MVC (Andrea and Ian worried about making things worse user wise in terms of bugs) --- idea can we couple also fixing the actual bug reports in Jira? What about the other modules using restlet, importer and resource-rest-api, rest-upload, sldService, anything else? Need quite a bit of people.
Mapbox Style
The GeoServer application can be extended to work with multiple styling languages (SLD, CSS, YSLD). Mapbox has recently defined an open standard for drawing vector tiles that has been picked up by not only their own software but by the OpenLayers team. Initial investigation into this standard shows that it is a "whole" map standard similar to "sld" describing both the layers that make up the map, and the symbology used to represent them visually.
While some features (3d extrusions, camera and lighting angle) are not suitable for use by GeoServer the rest of it looks quite fun.
References:
- https://www.mapbox.com/mapbox-gl-style-spec/ - https://boundlessgeo.com/2017/01/using-mapbox-style-objects-open-layers/
Rough planning:
- Focus on styling a single layer using a mapbox style
- Requires a parser for mapbox style capable of producing the internal geotools style objects; package as a geotools community module.
- Setup geoserver extension and integration for new style format
- Whole map styling
- LayerGroup defines both an order of layers, and the style associated with each layer - this information can be defined from a single mapbox style
- (Optional) Consider offering SLD the same ability to define a LayerGroup
Library upgrades
Last year's sprint was devoted to updating a key library and required all hands on deck to help make the transition a smooth one. Ideally we would like to stay on top of library upgrades; however often a change to one has a cascade effect as we need to update (and test) each library in turn.
GeoTools
Plans =
The GeoTools codebase has a number of smaller of ideas that may of be of interest to volunteers:
- JDK 9 + maybe JDK 8 updates in the code base (like stream ready support for feature collection, where we can use lambda for profit)
- JDK 9 replacement for plugin system (service registry) is required
The above ideas may also be suitable to anyone attending remotely who like the focus and support of a dedicated code sprint block on the calendar.
| # | Participant | Country | Organization | Arrival | Departure | Project Work on | Attendance / Notes | |
| 1 | Andrea Aime | Italy | GeoSolutions | CITE or REST API switch | Preference for CITE, I'm game for the REST API switch too | |||
| 2 | Ian Turton | UK | Astun | CITE, Java 8 upgrade | ||||
| 3 | Andrea Antonello | Italy | HydroloGIS | gvSIG and cross-project ideas | I have a strong preference for the end of March |