Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added in Relation flattening #233

Merged
merged 4 commits into from
Oct 5, 2018
Merged

Added in Relation flattening #233

merged 4 commits into from
Oct 5, 2018

Conversation

adahn6
Copy link
Contributor

@adahn6 adahn6 commented Oct 4, 2018

Description:

This PR adds in a function to Relation.java that "flattens" the Relation into a set of its non-Relation child members.

Potential Impact:

Probably nothing, giving it's a new API addition.

Unit Test Approach:

Unit tests cover basic relation (one node), nested relations (several nodes and one nested relation), and recursive relations (relation with itself as a child).

Test Results:

2018-10-04 13:48:28 INFO  [main] RelationFlatteningTest:62 - Relation 6: [Relation: id=6, [Members: 
				{Member: ID = 1, Type = NODE, Role = outside}
			], [Tags: ]]
2018-10-04 13:48:28 INFO  [main] RelationFlatteningTest:64 - Flattened: [[Node: id=1, location=POINT (-122.009566 37.33531), inEdges=[], outEdges=[], [Tags: ]]]
2018-10-04 13:48:28 INFO  [main] RelationFlatteningTest:43 - Relation 8: [Relation: id=8, [Members: 
				{Member: ID = 4, Type = NODE, Role = outside}, 
				{Member: ID = 5, Type = NODE, Role = outside}, 
				{Member: ID = 8, Type = RELATION, Role = outside}
			], [Tags: ]]
2018-10-04 13:48:28 INFO  [main] RelationFlatteningTest:45 - Flattened: [[Node: id=4, location=POINT (-122.009566 37.33531), inEdges=[], outEdges=[], [Tags: ]], [Node: id=5, location=POINT (-122.009566 37.33531), inEdges=[], outEdges=[], [Tags: ]]]
2018-10-04 13:48:28 INFO  [main] RelationFlatteningTest:24 - Relation 7: [Relation: id=7, [Members: 
				{Member: ID = 1, Type = NODE, Role = outside}, 
				{Member: ID = 2, Type = NODE, Role = outside}
			], [Tags: ]]
2018-10-04 13:48:28 INFO  [main] RelationFlatteningTest:26 - Flattened: [[Node: id=1, location=POINT (-122.009566 37.33531), inEdges=[], outEdges=[], [Tags: ]], [Node: id=2, location=POINT (-122.009566 37.33531), inEdges=[], outEdges=[], [Tags: ]]]

Describe other (non-unit) test results here.


In doubt: Contributing Guidelines

@adahn6 adahn6 mentioned this pull request Oct 4, 2018
Copy link
Contributor

@MikeGost MikeGost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really nice code, very clean! One minor OSM intricacy found and a suggestion for tests.

while (!toProcess.isEmpty())
{
polledMember = toProcess.poll();
if (relationsSeen.contains(polledMember.getIdentifier()))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a really rare case, but OSM identifiers are only unique within their type - meaning a Relation and Way can have the same identifier, but two Relations cannot. Because of this, it's technically possible for two different AtlasEntitys to have the same identifier. To avoid this, we also want to check the type. I would add an explicit check that the polledMember is a Relation, in addition to having been seen. You can add this check in at line 127 when you're checking for Relations.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm probably reading it wrong - won't the issue still be present? If we have a polledMember, that's a Node, with the same identifier as an already seen Relation - that Node wouldn't make it into the final return set, right? May be worth adding a unit test case for this too :)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I see, this is my mistake-- I had initially thought you were just referring to the adding of an ID as seen. but, obviously, it should apply to the check as well. I'll move it in, and also make a unit test.

*/
public class RelationFlatteningRule extends CoreTestRule
{

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: extra line

@Member(id = "8", role = "outside", type = "relation") }) }

)
private Atlas atlas1;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: there is only one atlas - no need for 1.

)
private Atlas atlas1;

public Atlas getAtlas1()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: likewise here - getAtlas?

@Relation(id = "7", members = {
@Member(id = "1", role = "outside", type = "node"),
@Member(id = "2", role = "outside", type = "node") }),
@Relation(id = "8", members = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about testing a valid relation with one or more sub-relations? Currently this is only testing an invalid relationship. It may be good to separate these into individual tests and test atlases. Something like below. Thoughts?

  • testShallowRelation
  • testNestedRelation
  • testLoopingRelation

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good idea

@adahn6
Copy link
Contributor Author

adahn6 commented Oct 4, 2018

@MikeGost changes addressed!

Copy link
Contributor

@MikeGost MikeGost left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Very clean, thanks @adahn6!

@MikeGost MikeGost merged commit 6d73202 into osmlab:dev Oct 5, 2018
Copy link
Collaborator

@matthieun matthieun left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Late review, but really nice, thanks @adahn6!

@matthieun matthieun added this to the 5.1.14 milestone Oct 17, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants