-
Notifications
You must be signed in to change notification settings - Fork 80
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
Conversation
There was a problem hiding this 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())) |
There was a problem hiding this comment.
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 AtlasEntity
s 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.
There was a problem hiding this comment.
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 :)
There was a problem hiding this comment.
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 | ||
{ | ||
|
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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() |
There was a problem hiding this comment.
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 = { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good idea
@MikeGost changes addressed! |
There was a problem hiding this 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!
There was a problem hiding this 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!
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:
Describe other (non-unit) test results here.
In doubt: Contributing Guidelines