addition of parameter ‘unclipped’

[FabiKo117]

implementing processing and adding it to the logic
adding it to the docs (swagger and sphinx)
refactoring boolean parameter usage
adding test
closes #20

[tyrasd]

looks good. small suggestion: maybe we should put a comment in the code that the old (undocumented) variant with properties=unclipped is deprecated, so we don't forget to remove it in the next release(s). perhaps it's possible to use @Deprecated for that?

[FabiKo117]

looks good. small suggestion: maybe we should put a comment in the code that the old (undocumented) variant with properties=unclipped is deprecated, so we don't forget to remove it in the next release(s). perhaps it's possible to use @Deprecated for that?

I've tried this already, but can't find a proper position where to add the @deprecated annotation. Can you find one maybe?
Cause it's only relevant in line 464 in InputProcessor.java.

[tyrasd]

looks good. small suggestion: maybe we should put a comment in the code that the old (undocumented) variant with properties=unclipped is deprecated, so we don't forget to remove it in the next release(s). perhaps it's possible to use @Deprecated for that?

I've tried this already, but can't find a proper position where to add the @deprecated annotation. Can you find one maybe?
Cause it's only relevant in line 464 in InputProcessor.java.

I believe it should be possible if one rewrites the whole statement slightly, like this:

    for (String property : properties) {
      @Deprecated boolean oldUnclippedParameter = "unclipped".equalsIgnoreCase(property)
      if ("tags".equalsIgnoreCase(property)) {
        this.includeTags = true;
      } else if ("metadata".equalsIgnoreCase(property)) {
        this.includeOSMMetadata = true;
      } else if (oldUnclippedParameter) {
        this.unclipped = true;
      } else {
        throw new BadRequestException(ExceptionMessages.PROPERTIES_PARAM);
      }
    }

[tyrasd]

aah, regarding my comment above #29 (comment), I realize now that it could result in double-negatives sometimes: unclipped=false could be a bit confusing. Maybe turn the whole thing around, and just call this parameter clipGeometries (or so)?!

[FabiKo117]

aah, regarding my comment above #29 (comment), I realize now that it could result in double-negatives sometimes: unclipped=false could be a bit confusing. Maybe turn the whole thing around, and just call this parameter clipGeometries (or so)?!

that's a good point yes.. then it would be better to call it "clipGeometries"