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

Changesets refactor #1329

Merged
merged 73 commits into from
Sep 4, 2019
Merged

Changesets refactor #1329

merged 73 commits into from
Sep 4, 2019

Conversation

westnordost
Copy link
Member

@westnordost westnordost commented Feb 6, 2019

5 steps:

  • refactor the quest upload to be more easily extendable and more easily testable. (I am slowly losing the overview at 500+ LOC)
  • in the future, treat (substantial) changes to the geometry as unsolvable conflict and drop quest answer. For example:
    • shop node has been moved hundreds of meters (shop moved or node was re-purposed by a mapper)
    • road end(s) have been extended or merged with another road-piece
    • ... (will need to think about further what changes on the geometry are still ok)
  • optionally release the changes done so far
  • implement the ability to split up a way at a certain position, including propagating the change to possible relations automatically
  • persisting split ways for offline usage (+undo?), interweave with quest system
  • Add UI for all or some way-based quests to cut a way into two pieces when choosing he other answer option "It differs along the way..."

@westnordost
Copy link
Member Author

westnordost commented Jun 18, 2019

implement the ability to split up a way at a certain position, including propagating the change to possible relations automatically

  • all that work done already
  • tests for updating relations
  • special logic for splitting up closed ways (require 2 split points and merge ends)
  • tests for that special logic

@matkoniecz matkoniecz mentioned this pull request Jul 5, 2019
@matkoniecz
Copy link
Member

One thing that seems to be missing - on splitting some closed ways one needs to create a multipolygon (on splitting say natural=water closed way).

Maybe it can be assumed that it will not happen in StreetComplete and is not worth implementing but may be worth noting it in comments that it is supposed to not happen.

@westnordost
Copy link
Member Author

Multipolygon? Not sure what you mean. A closed way is just a closed way, if you split it up, you get two unclosed ways. That is the behavior of JOSM.

@matkoniecz
Copy link
Member

Yes, but

  • there is closed way with natural=water
  • way is split in two natural=water ways

is incorrect (water area will disappear), and following is necessary:

  • there is closed way with natural=water
  • way is split in two natural=water ways
  • multipolygon relation is created, with this two ways as members
  • tags are removed from ways and added to relation

@westnordost
Copy link
Member Author

Probably not a multipolygon but two separated closed ways. But anyway, splitting a way is quite a different operation from splitting an area. The way is just 1-dimensional, so it can be split in a point. The area is 2-dimensional, so the split itself is a line, or a polyline.

In OSM, there exists no data structure for an area. I wonder, does JOSM have such a function, splitting a closed way (=area) along a (poly)line?

I can imagine use cases in StreetComplete where such a function would be helpful, for example if one wants to split up a building, a farmland or so. I'll keep this in mind, but for now, this won't be part of the implementation. A simple split of a way is already complicated enough, also UI wise. Imagine the user would need to draw a polyline (on a smartphone screen) to split an area with.

@westnordost
Copy link
Member Author

I'll probably be back from my "cave" this weekend, pushing a huge refactor of the whole upload system:

  • persisting split way uploads, integrating it into the upload service
  • pulling apart the different functionalities into separate classes that are also separately tested. For example, one class to upload a single quest answer change, one class to manage changesets, one class to update the diff-result of an upload, one class to coordinate the upload of all quest answers
  • not letting the undo osm quests inherit functionality from osm quests as certain fields (such as quest status, last update time etc) are irrelevant for it

@westnordost
Copy link
Member Author

westnordost commented Aug 26, 2019

Second problem: I reopened the app and the star counter is zero again. (still not authorized)

OK this sounds like a bug. Will investigate. I also received feedback in the German forum, so probably a beta-Release needs to be postponed (it was initially planned to be this Wednesday).

I understand the problems. But the question is not solved. Offline User is probably confused why the question is not raised again after split.

Yes, they might be. I was hoping that the dialog shown before the split-way screen explains this good enough. Do you or anyone else have a suggestion how to make the wording clearer so that the user is not surprised why he can't answer the question anymore (until next upload)?

If I split a small part from a long way, it would be the best if the longest (as in node count) part would get the osm way id and the stub gets a new id from the server.

Yes, this is the case.

@HolgerJeromin Are you interested to test the cases I wrote about above from A-Z(, or some of them)?

@westnordost
Copy link
Member Author

Second problem: I reopened the app and the star counter is zero again. (still not authorized)

Ok fixed

<string name="quest_generic_answer_differs_along_the_way">"Differs along the way…"</string>
<string name="quest_split_way_description">If it differs along the way, the first step is to split up the way. After that, the quest can be answered for each split part separately.\nNote that the quests for the split parts may appear mach later.\nSplit it now?</string>
<string name="quest_split_way_tutorial">Tap on the way to split it at the point(s) where the answer differs. Try to be as precise as possible, you can zoom in as usual.</string>
<string name="quest_split_way_too_imprecise">"Please zoom in further"</string>
Copy link
Member

Choose a reason for hiding this comment

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

This appears also at the maximum possible zoom.

Copy link
Member Author

Choose a reason for hiding this comment

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

Hm. The message appears if you tapped multiple nodes at once with your finger. If the nodes are absurdedly close to each other, then it wouldn't be possible to split up the way.

Copy link
Member Author

Choose a reason for hiding this comment

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

I'd love to just set the maximum zoom further up. But The default maximum zoom in tangram-es is 20.5 and it cannot be turned up further (and only starting at the new tangram-es version that we do not use).

At zoom 20.5, the diameter of the tap of the finger is about 3 meters in our latitude and about 5 on the equator. So, that is about still 4 zoom levels away from achieving the OSM 7-decimals-precision.

So the best choice here is to instead of requiring to further zoom in at already that high of a zoom level, just choose the node that is closest to the center of the tap position.

Will work on it. Thank you!

Copy link
Member Author

Choose a reason for hiding this comment

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

Implemented it. Would you mind testing it again at the position where you discovered it?

Copy link
Member Author

Choose a reason for hiding this comment

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

@westnordost
Copy link
Member Author

westnordost commented Sep 1, 2019

While testing, I discovered two more problems:

  • on creation/commenting of each note, the app calls the upload-photos API, even if there are no photos to upload.
  • the (split way) upload does not correctly update the local copy of the uploaded way with the inserted nodes: The inserted nodes are still referred to with negative ids after the upload. This destroys any subsequent attempt to upload new versions of the way (i.e. answering further questions)

So, the release will be postponed further.

@matkoniecz
Copy link
Member

Is the second error manifesting as de.westnordost.osmapi.common.errors.OsmBadUserInputException: Bad Request (400) - Placeholder node not found for reference -1 in way 713795301 crashes? Or is it a potential separate issue?

@westnordost
Copy link
Member Author

Yes

@HolgerJeromin
Copy link
Contributor

HolgerJeromin commented Sep 1, 2019

Yes, they might be. I was hoping that the dialog shown before the split-way screen explains this good enough. Do you or anyone else have a suggestion how to make the wording clearer so that the user is not surprised why he can't answer the question anymore (until next upload)?

The first dialog is forgotten. Another Toast after splitting "The quest you selected will be available after upload" would have helped me.

@westnordost
Copy link
Member Author

Solution still WIP...

@westnordost
Copy link
Member Author

westnordost commented Sep 4, 2019

Tests listed here complete. Further tests done:

  • split way which is member of multiple different relations
  • split way which is a member of an unknown relation
  • unsolvable conflict during split way upload

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants