Processing algorithm ToDos

[koebi]

List of ToDos for the processing algorithms. Not sorted by priority at all.

• [x] Add algorithm description. They should link to the docs and mention any non-intuitive things (such as the period format, any checkbox-related behavior, …)
• [x] Pass point + radius to bcircle instead of buffering via QGIS. This could be a line in the description
• [x] Get default start and end parameters from metadata …if possible. Mention that they are in UTC
• [x] Rename "Format" -> "Output format"
• [x] Group stuff like "harmonize geometries" and "qgis temporal feature" together, since they are QGIS-related, not ohsome-API-related
• [x] Is the timeout internal or external? It should be external, i.e. the parameter should be passed to ohsome
• [x] Rework time period Currently, it's Years/Months/Days, it should be one text area called "Period" with a note that it's an ISO 8601 period and default P1M
• [x] Error handling Any errors returned by the API should be relayed to the user in a usable format, probably in the processing algorithm output panel (that is anyways opened once the algorithm starts).

[koebi]

New ToDos from yesterday's meeting - again not ordered by Priority, but sligthly sorted ;)

Naming/Documentation

• [x] Input: docs should mention that polygons will be passed "as is" (bpoly), points will be passed with radius (bcircles)
• [x] Time: mention UTC for Start/End Date
• [x] Radius: Name should reflect that it's only for Point Layer Input
• [x] Group-By-Options should have "cleartext" names, not /tag/groupby/boundary or similar
• [x] Endpoint and Parameter options need better names
• [x] density-checkbox could be named Calculate Density or similar.
• [x] Filter/Filter2 might be clearer if they have different names
• [x] Output layer naming could be clearer, e.g. by referencing the alg or the query or sth other. Dashboard sorta does this.
• [x] Algorithms might be renamed, e.g. for Elements Aggregation to something along the lines of Aggregate Elements (though it's not quite clear what "elements" means in this context - there probably exist better names). I'd personally assume that naming should be a description of what the algorithm does, but other algs (and algs from other plugins) could be checked for how others do it.

Parameter sorting:

• [x] put options that influence another together:
  • Radius should go with input layer
  • Group-By keys and values should go with Group-By
    • [x] Date/Period should go in order Start - End - Period
    • [x] Checkboxes for output manipulation should go together (I think that's already the case, but not sure)
    • [x] Options can be grouped and "hidden" in an "Advanced Parameters"-Tab. Can this tab be arbitrarily named? Can there be multiple? We'd probably wish for two of these option groups, one for Grouping Parameter and one for output manipulation parameters.

Others:

• [x] Adapt plugin UI to roughly follow the Dashboard layout, albeit with input layer for bpolys.
• [x] Implement "Provider" similar to ORS
• [x] Query login sort of happens into the ohsome Tools box. One could look into whether this output could be formulated as a valid cURL-command, and whether the query can somehow be saved with the layer it corresponds to?

Optional other stuff:

• [ ] QgsProcessingParameterField has a method dependsOnOtherParameters - what does that do? Does it allow dynamic parameters, somehow? Similarly, QgsProcessingParameters has a method isDynamic - what does that do?

[merydian]

Regarding Elements Aggregation: In the Ohsome docs this is also called "Elements Aggregation". If we should rename it, I would suggest "Feature Aggregation" to follow the QGis nomenclature.

[koebi]

Tagging @mcauer for input here :)

[merydian]

Regarding: Filter/Filter2, in the docs this is also called Filter/Filter2. Maybe add an explanation in the description instead of renaming?

[koebi]

Regarding: Filter/Filter2, in the docs this is also called Filter/Filter2. Maybe add an explanation in the description instead of renaming?

An explanation is a good idea either way. Do you think there are good names that we could replace them by, and then maybe note in the explanation that they're called differently in the docs?

[merydian]

Alright. Maybe "Filter/Filter for ratio" would be an idea. I'd copy the docs explanation and add the comment for the difference in naming?

[mcauer]

In the results you will get

 "ratioResult": [
    {
      "timestamp": "2014-01-01T00:00:00Z",
      "value": 4708,
      "value2": 1022,
      "ratio": 0.217077
    },
    ...

So if we only write "filter/filter for ratio" its not clear from which filter value2 is resulting from. And the ratio is actually the result of devising filter2 by filter.

[mcauer]

Regarding Elements Aggregation: In the Ohsome docs this is also called "Elements Aggregation". If we should rename it, I would suggest "Feature Aggregation" to follow the QGis nomenclature.

So to explain why ohsomeAPI uses Elements and not Features: Features is what "normal" GIS people use when they work with QGIS or PostGIS or GeoJSON. This is related to the "SimpleFeature Access" Specification. Now the OSM Data Model is different and OSM calls those (nodes, ways, relations) Elements --> https://wiki.openstreetmap.org/wiki/Elements

At some point in the pipeline from OSHDB to QGIS the Elements are transformed into Features. So when we do Feature extraction we get Features, but when we do Aggregations we might aggregate things that are not features like turn restriction relations (e.g. dashboard example )

I think people must learn that OSM is different from SimpleFeatures and stick to Elements with reference to the docs

[koebi]

fixed in #58