Attribute naming of bounding-box wrong (North and South Longitude)

[pdante-ubc]

I was working on a harvester to grab data/metadata from Dataverse and noticed that North and South Latitude fields in the geospatial metadata are mislabeled as "Longitude". The web interface titles the fields as "Latitudes" so this doesn't break anything other than for developers who are trying to parse metadata coming out of Dataverse. The error is both in actual metadata coming out of Dataverse and in the field names in the Dataverse Metadata v4.x spreadsheet, although the spreadsheet has the correct labels in the title.

[djbrooke]

Hi @pdante-ubc - I'll tag in local metadata block enthusiast @jggautier to get his thoughts about what a fix would look like here.

[jggautier]

Thanks for pointing out this error, @pdante-ubc!

Because this fix involves changes to the database's field names, as opposed to the field labels we see in the UI, I don't know if editing and reloading the geospatial.tsv, the thing I'm most familiar with doing, would be appropriate. There's a warning in our metadata customization guides:

Great care must be taken when reloading a metadata block. Matching is done on field names (or identifiers and then names in the case of controlled vocabulary values) so it’s easy to accidentally create duplicate fields.

So would only editing these field names in the geospatial.tsv and reloading it create duplicate fields?

[pdurbin]

If it helps, the logic is in "DatasetFieldServiceApi.java": https://github.com/IQSS/dataverse/blob/v4.11/src/main/java/edu/harvard/iq/dataverse/api/DatasetFieldServiceApi.java

---

Update: I'm just adding the terms northLongitude and southLongitude here so I can more easily find this issue. Yes, these are incorrect and should be northLatitude and southLatitude, respectively, as noted at https://groups.google.com/g/dataverse-community/c/kYNkZjc1CJM/m/c3eUp6vNFgAJ

[mheppler]

Related to Improve Geospatial Metadata Block #6713.

[scolapasta]

@jggautier sorry no one fully answered your question, but yes it would create duplicates since the "name" is what we use to match the DatasetFieldType.

So the change in the tsv would need to be accompanied by a corresponding db change. But it would be a straightforward update query.

[cmbz]

2024/01/08: This is a cleanup task. See tasks below. Update with size: 10

• - Correct the typo in the code
• - Provide SQL script to update database
• - Consider and address backwards compatibility issues

[cmbz]

2024/01/31

• Possibly update with a flyway script, but needs additional investigation. Resized at 33 (from 10) during kickoff.

[landreev]

As for maintaining backward compatibility on the API level - I don't really have a strong opinion. We can keep code in place that recognizes the old names, or we can say firmly that this is a breaking change and the old names are no longer accepted because they were wrong in the first place. Either option is ok, IMO.