modify data type of contribution type

[FabiKo117]

Description

use correct boolean instead of "true" as string

Checklist

• My code follows the code-style rules, and I have checked on the static analyses
• I have commented my code
  I have written javadoc (required for public methods)
• I have added sufficient unit and API tests
• I have made corresponding changes to the documentation
• I have updated the CHANGELOG.md
  I have adjusted the examples in the check-ohsome-api script or created an issue in the corresponding repository. More Information here.

[tyrasd]

strictly speaking this would be a major breaking change, and would need to wait for the 2.0.0 release (api version v2). Or do we think that this is actually a bug which needs to be fixed in the current v1?

[tyrasd]

slightly related:

I think we also misuse the properties=metadata parameter to trigger the output of the contribution type flags. Also the properties parameter is currently not documented for the contribution extraction endpoint(s). IMHO the following would have made more sense:

properties – specifies what properties should be included for each feature representing an OSM contribution (i.e. edit to an OSM element): tags and/or metadata and/or contributionType; multiple values can be delimited by commas; default: empty

[FabiKo117]

strictly speaking this would be a major breaking change, and would need to wait for the 2.0.0 release (api version v2). Or do we think that this is actually a bug which needs to be fixed in the current v1?

Good question.. I am okey with either options. I also think that after 1.4, it could be time to go for the v2 release as we could also include the advanced response structure then into production. Then also this change/fix here could go live.

Otherwise there are people like @Zia- that would use it immediately and you could also see this as a fix, therefore it could be included in the next patch or minor release too.

[tyrasd]

I'm actually also a bit torn. Could live with both options for the "true" -> true fix. Not sure about the proposed #135 (comment) though.

[FabiKo117]

slightly related:

I think we also misuse the properties=metadata parameter to trigger the output of the contribution type flags. Also the properties parameter is currently not documented for the contribution extraction endpoint(s). IMHO the following would have made more sense:

properties – specifies what properties should be included for each feature representing an OSM contribution (i.e. edit to an OSM element): tags and/or metadata and/or contributionType; multiple values can be delimited by commas; default: empty

True, we're not mentioning the use of properties and clipGeometry in the docs. Only the geometryType is mentioned. Do you think that it would be necessary to make the contributionType another value of the properties parameter?

[tyrasd]

clipGeometry

isn't that one undocumented for a reason? 😉

[bonaparten]

In relation to version 2.0, I think we should discuss soon how we want to proceed after the 1.4 release since we have at that moment already two PRs "blocked" because of breaking changes these PRs would introduce.

[tyrasd]

Do you think that it would be necessary to make the contributionType another value of the properties parameter?

I would prefer it that way. Because the contribution type has not much to do with the OSM elements' metadata (@version, @changesetId, etc.)

[FabiKo117]

clipGeometry

isn't that one undocumented for a reason? 😉

It is mentioned here, what I mean is that it's not mentioned in the docs part of the /contributions endpoint. Also the properties parameter is not mentioned there, but can be used.

[FabiKo117]

So did I understand it correctly now out of the recent discussions that we define this as a bug-fix and can therefore include it in the next minor release?

The thing regarding the new property contributionType: This could be handled in another issue/PR I'd say and would just be a new feature and non-breaking (as long as it's still included when metadata is set as well).

[tyrasd]

So did I understand it correctly now out of the recent discussions that we define this as a bug-fix and can therefore include it in the next minor release?

yes, that was also my understanding.

The thing regarding the new property contributionType: This could be handled in another issue/PR I'd say

sounds good 👍