Format 'groupByObject' as JSON-object, not list for /elements/{agg}/groupBy/boundary/groupBy/tag

[SlowMo24]

Endpoint: https://api.ohsome.org/v1/elements/area/groupBy/boundary/groupBy/tag

Body: {'time': '2021-02-28', 'bboxes': 'id1:12.4458570122,45.4386880794,12.4468333362,45.4393693706', 'filter': 'building=* and geometry:polygon', 'groupByKey': 'building'}

Returns: {'attribution': {'url': 'https://ohsome.org/copyrights', 'text': '© OpenStreetMap contributors'}, 'apiVersion': '1.3.2', 'groupByResult': [{'groupByObject': ['id1', 'building=yes'], 'result': [{'timestamp': '2021-02-28T00:00:00Z', 'value': 20.29}]}, {'groupByObject': ['id1', 'building=hut'], 'result': [{'timestamp': '2021-02-28T00:00:00Z', 'value': 1153.18}]}]}

The {'groupByObject': ['id1', 'building=yes']...} is risky as it relies on the right order in the list which may change at any time. Explicit results would also be easier to parse: {'groupByObject': {'boundaryId':'id1', 'tag':'building=yes'}...} or if there is some reason to stick to the list: {'groupByObject': [{'boundaryId':'id1'},{'tag':'building=yes'}]...}

[FabiKo117]

I am having troubles understanding your issue. The groupByObject only has two elements inside: the boundary ID and the tag. The combination of those two makes one groupByResult JSON object unique. So it does not matter what the order of the boundary ID and the tag within the groupByObject actually is, as it's just used as a unique identifier for the respective JSON object.

If you mean the order of the groupByResult array, it does not matter there either, as one object within that array consists of the combination of the groupByObject and the result meaning no matter in what order they come, the correct matching between the result and the groupByObject should always be possible.

Example URL that I've used to check:
https://api.ohsome.org/v1/elements/count/groupBy/boundary/groupBy/tag?bboxes=8.694826%2C49.414523%2C8.697165%2C49.415926&filter=type%3Away&format=json&groupByKey=building&showMetadata=yes&time=2014-01-01%2F2017-01-01%2FP1Y

[SlowMo24]

yes, there is no issue with the result itself, each response is unique. It is more about style and ease of user side processing.

Most users probably want to link the results back to the input, so e.g. attach the groupByResult to a geometry. But in the current state it is not explicit which part of the groupByObject is the geometry-id and which one is the tag. By making it explicit (as stated in the issue) this would make the API more robust and user friendly enabling code like geomid=groupByObject["geomid"]

Imagine the following two unlikely but possible cases where this may cause confusion:

• some change of code in the api swaps the order of the groupByObject list. strictly speaking this is not a breaking change as no order of the list is implied. All client code would need to change form geomid=groupByObject[0] to geomid=groupByObject[1]. Depending on the code behind the API this may even occur without the developer noticing?
• consider the following request: https://api.ohsome.org/v1/elements/count/groupBy/boundary/groupBy/tag?bboxes=building=yes:8.694826%2C49.414523%2C8.697165%2C49.415926|remainder:8.694826%2C49.414523%2C8.697165%2C49.415926&filter=type%3Away&format=json&groupByKey=building&showMetadata=yes&time=2014-01-01%2F2017-01-01%2FP1Y. Order now highly matters.

This may be a bit nit-picking but just trying to improve.