[WIP patch] Upcoming API 0.6 change: limit maximum number of relation members

[mmd]

We will deploy a new API 0.6 change shortly, which will reject relations exceeding a certain number of relation members.

The overall logic is very similar to "waynodes", only that it applies to relation members this time, i.e. you need to use the /api/0.6/capabilities endpoint to retrieve the current maximum relation member value.

It would be good to show an error message to the user even before uploading, like it is done today for "waynodes" in ApiPreconditionCheckerHook.

Please refer to the following two issues on impact on the capabilities call, as well as new API error messages.

​https://github.com/openstreetmap/openstreetmap-website/pull/3440
​https://github.com/openstreetmap/openstreetmap-website/issues/1711

Snipped from capabilities which includes the new relationmembers element:

<?xml version="1.0" encoding="UTF-8"?>
<osm version="0.6" generator="OpenStreetMap server" copyright="OpenStreetMap and contributors" attribution="http://www.openstreetmap.org/copyright" license="http://opendatacommons.org/licenses/odbl/1-0/">
  <api>
    <version minimum="0.6" maximum="0.6"/>
    <area maximum="0.25"/>
    <note_area maximum="25"/>
    <tracepoints per_page="5000"/>
    <waynodes maximum="2000"/>
    <relationmembers maximum="32000"/>
    <changesets maximum_elements="10000"/>
    <timeout seconds="300"/>
    <status database="online" api="online" gpx="online"/>
  </api>
  <policy>
    <imagery>
      <blacklist regex=".*\.google(apis)?\..*/(vt|kh)[\?/].*([xyz]=.*){3}.*"/>
      <blacklist regex="http://xdworld\.vworld\.kr:8080/.*"/>
      <blacklist regex=".*\.here\.com[/:].*"/>
    </imagery>
  </policy>
</osm>

[gaben]

add support for capabilities on max relation members (checked only on upload)

[Woazboat]

The second function arguments here should probably be maxMembers and not maxNodes?

 	55	            long maxMembers = api.getCapabilities().getMaxRelationMembers();
 	56	            if (maxMembers > 0) {
 	57	                if (!checkMaxMembers(apiData.getPrimitivesToAdd(), maxNodes))
 	58	                    return false;
 	59	                if (!checkMaxMembers(apiData.getPrimitivesToUpdate(), maxNodes))
 	60	                    return false;
 	61	                if (!checkMaxMembers(apiData.getPrimitivesToDelete(), maxNodes))
 	62	                    return false;
 	63	            }

[Woazboat]

Deleting relations with too many members should still be possible as far as I can tell from looking at the proposed api changes. The maxMember preconditions are only checked when creating or updating relations.

​https://github.com/openstreetmap/openstreetmap-website/blob/2efd73c672dae8f6956024638b4b090961e74781/app/models/relation.rb#L163.L182

[Woazboat]

Adding a check to the relation editor to detect these errors while editing (and prevent too many members from being added in the first place) and not just when attempting to upload the changes would also be a good idea.

[gaben]

Thanks! Yes, it's a copy-paste error.

Deleting possibility over the limit sounds logical to me, but then why is it denying upload over the limit of way nodes? I didn't know the reason, so copied the functionality.

[skyper]

Replying to Woazboat:

Adding a check to the relation editor to detect these errors while editing (and prevent too many members from being added in the first place) and not just when attempting to upload the changes would also be a good idea.

As relation editor is only one place, I'd rather go with a validator error warning like relations without members.

[mmd]

Deleting relations with too many members should still be possible as far as I can tell from looking at the proposed api changes.

That's correct, we want mappers to still be able to delete those relations.

[mmd]

why is it denying upload over the limit of way nodes? I didn't know the reason, so copied the functionality.

I guess those ways have been cleaned up (manually?) right before API 0.6 went live years ago. Nevertheless, the API would allow deleting such ways with more than 2000 nodes.

[Woazboat]

Replying to skyper:

Replying to Woazboat:

Adding a check to the relation editor to detect these errors while editing (and prevent too many members from being added in the first place) and not just when attempting to upload the changes would also be a good idea.

As relation editor is only one place, I'd rather go with a validator error warning like relations without members.

Why not both?

[skyper]

Replying to Woazboat:

Replying to skyper:

Replying to Woazboat:

Adding a check to the relation editor to detect these errors while editing (and prevent too many members from being added in the first place) and not just when attempting to upload the changes would also be a good idea.

As relation editor is only one place, I'd rather go with a validator error warning like relations without members.

Why not both?

Mmh, I am no fan of constantly validating as it uses resources and in this case, I think the situation will happen rarely. At least an option to disable it would be nice.

[gaben]

fix typo, allow deleting over the API limit

[SImonPoole]

Replying to skyper:
...

Mmh, I am no fan of constantly validating as it uses resources and in this case, I think the situation will happen rarely. At least an option to disable it would be nice.

The issue is that splitting ways and similar operations will increase relation member count without direct involvement of the user. That is it is quite possible to be slightly under the limit and then with a few way splits go over it (at 32'000 members that is obviously going to extremely rare, but just wait till it comes down to 10'000 or lower). Failing on upload is just not good UX design in such a situation.

[skyper]

Replying to SImonPoole:

Replying to skyper:
...

Mmh, I am no fan of constantly validating as it uses resources and in this case, I think the situation will happen rarely. At least an option to disable it would be nice.

The issue is that splitting ways and similar operations will increase relation member count without direct involvement of the user. That is it is quite possible to be slightly under the limit and then with a few way splits go over it (at 32'000 members that is obviously going to extremely rare, but just wait till it comes down to 10'000 or lower). Failing on upload is just not good UX design in such a situation.

We can always show a validator error for the limit before upload instead of checking all involved relations on each change.