<br>
Am 06.04.2019 um 17:32 schrieb mmd:<br>
><br>
>     I have to say from an editor POV there is no good solution as<br>
>     invariably the link between template ids in the editor and what<br>
>     has actually been created in the DB is lost.<br>
><br>
> ...unless the /diffResult/ reponse is important enough to store it one<br>
> the database for later retrieval, and associate it to some kind of<br>
> unique identifier provided by the client.<br>
><br>
But it is entirely unnecessary except in a chunked upload scenario (aka<br>
the client still has non-uploaded changes that have references to the<br>
uploaded data). The -only- thing that the user/editor needs to know in<br>
the non-chunked scenario is if the upload was successful or not. If<br>
successful there is no need to update the local data after the fact, as<br>
that is only an optimisation (which iD for example does), which can be<br>
replaced by downloading again.<br>
><br>
> I have to say that I don't find any of the 3 options you mentioned<br>
> compelling, and that's the main motivation for opening up this issue.<br>
> JOSM implements option 1, iD either 1 and/or 3 (not exactly sure at<br>
> the moment), maybe some other editor does 2 already.<br>
><br>
All allow one of the three options manually (AFAIK they don't explicitly<br>
offer them though).<br>
<br>
> Allowing only a single upload per changeset sounds tempting, but it<br>
> doesn't solve the diffResult issue,. and many users would very likely<br>
> be somewhat unhappy with this approach.<br>
><br>
> Let's assume someone wants to upload 12'000 changes, first upload w/<br>
> 10'000 changes runs, changeset gets closed, yet the diffResult gets<br>
> lost due to some networking issue on the way back.<br>
> How would you match the actual object ids to the placeholder ids in<br>
> this case? This information may be crucial for the remaining 2'000<br>
> objects, if they have references to those 10'000 objects.<br>
><br>
Chunked uploads are problematic, but that isn't covered by the original<br>
proposal either.<br>
><br>
> (By the way, 10'000 is just the maximum changeset size I used an an<br>
> example. If a user has configured their JOSM to upload data in chunks<br>
> of eg. 500 objects, this very same situation can obviously occur with<br>
> much smaller changesets).<br>
><br>
> Using some kind of changeset counter would allow some heuristic to<br>
> find out if a changeset has been uploaded. Like in the previous case,<br>
> it doesn't solve the diffResult issue.<br>
><br>
Not if the changeset has been uploaded, but if the last upload to the<br>
changeset was successful.<br>
><br>
> Implementation wise you would have to<br>
><br>
>   * extend the changeset table,<br>
>   * extend the changeset API call,<br>
>   * change the changeset upload to update the counter,<br>
>   * issue a separate changeset query call on the client after a failed<br>
>     changeset<br>
>   * download the changeset<br>
>   * implement some heuristic to match actual object ids back to<br>
>     placeholder ids (unless no more data is to be uploaded, in which<br>
>     case you can simply re-download the area in question, like iD does).<br>
><br>
IMHO if we want to support chunked downloads, there does actually need<br>
to be a way of accessing the last diffresult data, but a single API call<br>
with the changeset as parameter would be enough as it is trivial for the<br>
client to determine if the changes have already been applied or not :<br>
<br>
- diff upload fails for the client<br>
<br>
- calls "last diff result" API call<br>
<br>
- checks if changes have already been applied, if no -re-uploads- if<br>
yes, applies changes from diff result.<br>
<br>
Simon<br>
<br>
> —<br>
> You are receiving this because you commented.<br>
> Reply to this email directly, view it on GitHub<br>
> <https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480513276>,<br>
> or mute the thread<br>
> <https://github.com/notifications/unsubscribe-auth/AA9wlI1vRVRl2Oyn-vEkH5OLNk8Qfw3uks5veL4XgaJpZM4cgFOf>.<br>
><br>


<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">—<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480515155">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/ABWnLZIoInpqWqrNdEG3gM9qjQNjw1h6ks5veMPwgaJpZM4cgFOf">mute the thread</a>.<img src="https://github.com/notifications/beacon/ABWnLZP_0W27q_2i44Iy63gi1U5CbwTdks5veMPwgaJpZM4cgFOf.gif" height="1" width="1" alt="" /></p>
<script type="application/json" data-scope="inboxmarkup">{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/openstreetmap/openstreetmap-website","title":"openstreetmap/openstreetmap-website","subtitle":"GitHub repository","main_image_url":"https://github.githubassets.com/images/email/message_cards/header.png","avatar_image_url":"https://github.githubassets.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/openstreetmap/openstreetmap-website"}},"updates":{"snippets":[{"icon":"PERSON","message":"@simonpoole in #2201: \nAm 06.04.2019 um 17:32 schrieb mmd:\n\u003e\n\u003e     I have to say from an editor POV there is no good solution as\n\u003e     invariably the link between template ids in the editor and what\n\u003e     has actually been created in the DB is lost.\n\u003e\n\u003e ...unless the /diffResult/ reponse is important enough to store it one\n\u003e the database for later retrieval, and associate it to some kind of\n\u003e unique identifier provided by the client.\n\u003e\nBut it is entirely unnecessary except in a chunked upload scenario (aka\nthe client still has non-uploaded changes that have references to the\nuploaded data). The -only- thing that the user/editor needs to know in\nthe non-chunked scenario is if the upload was successful or not. If\nsuccessful there is no need to update the local data after the fact, as\nthat is only an optimisation (which iD for example does), which can be\nreplaced by downloading again.\n\u003e\n\u003e I have to say that I don't find any of the 3 options you mentioned\n\u003e compelling, and that's the main motivation for opening up this issue.\n\u003e JOSM implements option 1, iD either 1 and/or 3 (not exactly sure at\n\u003e the moment), maybe some other editor does 2 already.\n\u003e\nAll allow one of the three options manually (AFAIK they don't explicitly\noffer them though).\n\n\u003e Allowing only a single upload per changeset sounds tempting, but it\n\u003e doesn't solve the diffResult issue,. and many users would very likely\n\u003e be somewhat unhappy with this approach.\n\u003e\n\u003e Let's assume someone wants to upload 12'000 changes, first upload w/\n\u003e 10'000 changes runs, changeset gets closed, yet the diffResult gets\n\u003e lost due to some networking issue on the way back.\n\u003e How would you match the actual object ids to the placeholder ids in\n\u003e this case? This information may be crucial for the remaining 2'000\n\u003e objects, if they have references to those 10'000 objects.\n\u003e\nChunked uploads are problematic, but that isn't covered by the original\nproposal either.\n\u003e\n\u003e (By the way, 10'000 is just the maximum changeset size I used an an\n\u003e example. If a user has configured their JOSM to upload data in chunks\n\u003e of eg. 500 objects, this very same situation can obviously occur with\n\u003e much smaller changesets).\n\u003e\n\u003e Using some kind of changeset counter would allow some heuristic to\n\u003e find out if a changeset has been uploaded. Like in the previous case,\n\u003e it doesn't solve the diffResult issue.\n\u003e\nNot if the changeset has been uploaded, but if the last upload to the\nchangeset was successful.\n\u003e\n\u003e Implementation wise you would have to\n\u003e\n\u003e   * extend the changeset table,\n\u003e   * extend the changeset API call,\n\u003e   * change the changeset upload to update the counter,\n\u003e   * issue a separate changeset query call on the client after a failed\n\u003e     changeset\n\u003e   * download the changeset\n\u003e   * implement some heuristic to match actual object ids back to\n\u003e     placeholder ids (unless no more data is to be uploaded, in which\n\u003e     case you can simply re-download the area in question, like iD does).\n\u003e\nIMHO if we want to support chunked downloads, there does actually need\nto be a way of accessing the last diffresult data, but a single API call\nwith the changeset as parameter would be enough as it is trivial for the\nclient to determine if the changes have already been applied or not :\n\n- diff upload fails for the client\n\n- calls \"last diff result\" API call\n\n- checks if changes have already been applied, if no -re-uploads- if\nyes, applies changes from diff result.\n\nSimon\n\n\u003e —\n\u003e You are receiving this because you commented.\n\u003e Reply to this email directly, view it on GitHub\n\u003e \u003chttps://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480513276\u003e,\n\u003e or mute the thread\n\u003e \u003chttps://github.com/notifications/unsubscribe-auth/AA9wlI1vRVRl2Oyn-vEkH5OLNk8Qfw3uks5veL4XgaJpZM4cgFOf\u003e.\n\u003e\n"}],"action":{"name":"View Issue","url":"https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480515155"}}}</script>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480515155",
"url": "https://github.com/openstreetmap/openstreetmap-website/issues/2201#issuecomment-480515155",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>