implement /contributions/latest/count

[FabiKo117]

Use Case Description

OQT would use this endpoint for the computation of the lastEdit indicator.

Request Description

Enlarges the /contributions data-aggregation endpoint as an addition to the already existing /contributions/latest/{geometry-type} data-extraction endpoint.

[tyrasd]

marked as waiting because the use case description is too vague at the moment.

[bonaparten]

As supposed, they would like to speed up the count process of edited entities in a period of time

//edit @tyrasd

basically we want to know: what is the percentage of features that have been edited on the past 12 months.

[tyrasd]

ok, this is a valid use case, thanks for clarifying. //cc @Hagellach37

What's unclear to me now is, if the resource is well placed in the /contributions/ path of the API, because the use case mentions that it's more about counting features (i.e. elements) than the contributions. I think as a new user, one would intuitively not expect to find an answer to the above mentioned question in the proposed resource. 🤔 Or am I wrong here?

Also we should now probably also think about how we could grow the API around this new endpoint in the near future: I think that it would be quite useful to extend this from simple counts to the other metrics like length or area in order to answer questions like: “what is the percentage of the road network length has been edited during the past 12 months.”. But when we provide this, it would be essential to split the output between creations/modifications and deletions, so the result structure should reflect this already with the count endpoint IMHO.

PS: now I just notice that even to answer the original question of “what is the percentage of features that have been edited on the past 12 months” it would be needed to split the result between created/modified and deleted features, since one could get results > 100% when there are many deletions in an area (e.g. when there were 2 POIs in a region, one gets deleted and the other is modified, then the result should be 100% not 200%), shouldn't it?

[bonaparten]

A different feature to offer could be to just add, for every element endpoint, a new boolean parameter a contributionType parameter that takes creation, geometryChange, tagChange and other. The solution will give back elements filtered by their contribution type. For the contributions endpoints, it should be possible to use the same parameter filtering by all values (also deletion).
But I don't know if the whole work is really necessary at this stage. Only implementing a /contributions/latest/count now doesn't invalidate the possibility to add these other features in a fast way in the future. So the point is now whether the /contributions/latest/count feature is what it is wanted.

//edited

[Hagellach37]

Hey,
let me jump in here and try to explain. At the moment we use the contributions/latest/centroid endpoint to find out which features have been modified in the past x months for a specific region. Whereas it is nice that we get all the information for these contributions and their centroids, we are actually not using much of this information. Because in the end we just count them and don't use the geometry or tags at all.

Being able to distinguish between the type of the contribution (e.g. created, deleted, modified) would be really good.

When it comes to anything else than count it gets even more difficult. Because then we need to be able to aggregate more fine grained, e.g. contributions that increase and contributions that decrease the road length etc. So I would only focus on the count for now and it is also "good enough" for the use case we have in OQT at the moment.