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

Should the Geographic Bounding Box allow optional coordinates and multiple boxes in the UI? #7091

Closed
JingMa87 opened this issue Jul 16, 2020 · 10 comments
Labels
Feature: Geospatial Type: Suggestion an idea User Role: Depositor Creates datasets, uploads data, etc.

Comments

@JingMa87
Copy link
Contributor

When the issue occurs: When administrating or filling in metadata for a dataset with Geospatial Metadata
Which page it occurs on: Go to a dataverse, then Edit > General Information > Metadata Fields > Geospatial Metadata
To whom it occurs: People who administrate or add Geospatial Metadata
Version: 4.20

Context
In issue #3648 we addressed the problem that Dataverse doesn't always produce valid DDI. One of the issues is that DDI doesn't allow optional coordinates and multiple geographic bounding boxes. This problem could be fixed by filtering out DDI-invalid entries when making the XML, but it could also be solved by changing the UI elements and preventing DDI-invalid data to be entered in the first place. Since this problem might extend into the UI of Dataverse, I made a separate issue for this part of the problem.

Should all four points be mandatory?
To me the optionality of each point of a bounding box is strange since you need all four to make the box.

image

Moreover, DDI requires a bounding box element to have exactly one occurrence of every point. The default minOccurs and maxOccurs is 1 when not specified.

image

To me it makes more sense that the four points should always be filled in when the "Geographic Bounding Box" checkbox is ticked, so the four options in the UI for the points should be removed. But this depends, of course, on the people who upload this kind of data.

image

Unlimited boxes?
Also, the geoBndBox element can only occur once according to DDI. In Dataverse you can add as many as you want, does it logically make sense to add unlimited amounts then? Do researchers define multiple boxes?

image

image

@JingMa87
Copy link
Contributor Author

@jggautier Are you usually the person to talk to researchers in order to conclude these UI changes? I'd like to make the UI change, but only if we can conclude this matter with the users.

@pdurbin
Copy link
Member

pdurbin commented Jul 16, 2020

@JingMa87 UI changes are usually designed by @TaniaSchlatter and @mheppler but a number of us (including @jggautier) often attend design meetings.

Thanks for opening this issue and thinking about all this stuff.

You might be interested in joining the Geospatial Discovery Working Group. These groups were recently announced at https://groups.google.com/g/dataverse-community/c/EY0dduRj3Ac/m/EDcEQHLoAwAJ

@JingMa87 JingMa87 changed the title The Geographic Bounding Box allows optional coordinates and multiple boxes The Geographic Bounding Box allows optional coordinates and multiple boxes in the UI Jul 22, 2020
@JingMa87 JingMa87 changed the title The Geographic Bounding Box allows optional coordinates and multiple boxes in the UI Should the Geographic Bounding Box allow optional coordinates and multiple boxes in the UI? Jul 22, 2020
@qqmyers
Copy link
Member

qqmyers commented Dec 3, 2020

If I look in the geospatial metadatablock definition, none of the points are required - is the first point being required a local admin change?

FWIW: I've suggested elsewhere that it might be possible to change the way blocks work to allow a parent field to be optional while having the required param on the child fields indicating that if the parent is included, then the children are/aren't required (versus the current logic that a required child means the parent is required) - would that help here?

Also - linking to #7455 which has a multiple bounding boxes use case

@jggautier
Copy link
Contributor

jggautier commented Dec 4, 2020

If I look in the geospatial metadatablock definition, none of the points are required - is the first point being required a local admin change?

Yes

FWIW: I've suggested elsewhere that it might be possible to change the way blocks work to allow a parent field to be optional while having the required param on the child fields indicating that if the parent is included, then the children are/aren't required (versus the current logic that a required child means the parent is required) - would that help here?

In this case, this would allow an installation administrator to make a change to the metadatablock TSV that says that if the Geographic Bounding Box is required, then all four of its child fields are required.

Then when a dataverse administrator edits which metadata fields are used and required (in the Metadata Fields section of the General Information page), the dataverse administrator would have the option only to make the Geographic Bounding Box required or not required. There would not be an option to make the child fields required or optional.

Is this right? I think this would help a lot.

I left comments in #7455 about multiple bounding boxes.

@qqmyers
Copy link
Member

qqmyers commented Dec 4, 2020

Is this right? I think this would help a lot.

~yes

There would not be an option to make the child fields required or optional.

How the UI changes could be separable, but I'd think you'd at least want the bounding box parent to have a required/optional choice itself. In general, I think it wouldn't work to not allow children to be switched (e.g. would it be OK if you couldn't switch which child fields were required for an author or contact or keyword?), but perhaps the logic could be that for child fields you can only require when the block says its optional but not the other way around. Or maybe a new flag would be needed?

@jggautier
Copy link
Contributor

We seem to be sold on the idea of using field validation to fix the problem of bad metadata here, but I just thought it might be helpful to address the merits of field validation (as opposed to other ways to ensure that depositors provide useful metadata) more explicitly. We can always improve other things, like tooltips, training, and the visual hierarchy of fields and labels on metadata forms, but validation error messages can be more defense against poor metadata or simple mistakes. Most of the cases of people filling fewer than four bounding box fields involve people who wanted to use the fields as lat/long coordinates.

I agree that for most metadata compound fields, people would still need to be able to make some child fields optional and some child fields required, like the Author fields. So that flexibility is still needed.

The Geographic Bounding Box fields are a case where field validation that forces all or no child fields to be filled can be really helpful. I think we agree that we should try to avoid relying on dataverse administrators to edit their dataverse to make all four of these fields required. The decision to force depositors to fill all four of these fields if any of the fields are filled should be made by people who implement and control the metadata schema. I think the same can be said for child fields in other compound fields, like the ID Type/Number pair in the Related Publication field and the Identifier Scheme/Identifier pair in the Author field.

@pdurbin pdurbin added Type: Suggestion an idea User Role: Depositor Creates datasets, uploads data, etc. Feature: Geospatial labels Oct 10, 2022
@pdurbin
Copy link
Member

pdurbin commented Oct 12, 2022

@JingMa87 is no longer working on the issues he opened: #7412 (comment)

We should check with the DANS crew to see if any of them are still interested in this: @PaulBoon @janvanmansum @WittenbergM @LauraHuisintveld

@janvanmansum
Copy link
Contributor

@pdurbin : to be complete: this is also no longer a priority for DANS.

@jggautier
Copy link
Contributor

There's some related work being documented at #9547

@cmbz
Copy link

cmbz commented Aug 20, 2024

To focus on the most important features and bugs, we are closing issues created before 2020 (version 5.0) that are not new feature requests with the label 'Type: Feature'.

If you created this issue and you feel the team should revisit this decision, please reopen the issue and leave a comment.

@cmbz cmbz closed this as completed Aug 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature: Geospatial Type: Suggestion an idea User Role: Depositor Creates datasets, uploads data, etc.
Projects
None yet
Development

No branches or pull requests

7 participants