-
Notifications
You must be signed in to change notification settings - Fork 0
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
GeoJSON uploaded - how to report problems with initial conversion to JSON to user? #30
Comments
I've updated the proposed interface in #24 (comment) create a space for the conversion errors. |
To be clear about scope: this issue is about when the user uploads GeoJSON and we have some issues converting that to JSON. Some issues here could be recoverable - like there are inconsistent references. That's really what this issue is about - problems that aren't recoverable are easy (they just see an error screen as there is nothing we can do). For recoverable ones, I can try and put them into the "data conversion" box as described in #24 but I'm wondering if this deserves more space. For instance in the case of inconsistent organisation references, we can actually list the Network & Org ID's that are inconsistent. How about putting new headings in the "Additional checks" section? We are in effect here reporting an issue with data the user uploaded so put it in the same section? (The user doesn't care if that's raised from the GeoJSON->JSON conversion or the JSON checking) I think I'm getting confused here due to #36 - technically if a user uploads really bad GeoJSON they could have errors converting that to JSON, then there could be more errors converting it back to GeoJSON. |
Aside from inconsistent organisation references, what other recoverable conversion issues can be reported? |
Currently inconsistent phases and networks, but I'm sure there will be more - I've already seen features with no network information. For many of these we could display more information - currently for inconsistent organisations, phases and networks we store a list of ID's that might help the user. |
There could also be inconsistent node data as mentioned in #5 (comment) |
For now, I think it would be best to separate the errors that are reported against the GeoJSON data from the errors that are reported against the JSON data. Otherwise, I think it will be confusing for users. How about this for an interface: Edit: HTML version |
Separating them looks good to me. From Open-Telecoms-Data/lib-cove-ofds#26 - @duncandewhurst has made spreadsheet with details of how the issues should look: https://docs.google.com/spreadsheets/d/14zlBYjqKZBgruKR3lVzVuuUOYYhvkN75YSnT-zb-UMM/edit#gid=638797896 |
If there is an inconsistent $X, then by definition it occurs in at least 2 places and has at least 2 values. How to handle? Should one row somehow show multiple items, or one separate row per item? |
I prefer a single row per value like in the screenshot above. We could perhaps add the phase identifier to the list of identifiers in the first column. |
Can we think about the UI of this? We said in a call we'd put it in the download box but there isn't much room there.
Open-Telecoms-Data/lib-cove-ofds#26 is for library work to find errors - any errors in algorithm, report there.
The text was updated successfully, but these errors were encountered: