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

Convert inches to cm in Extent field of museum objects #2656

Open
Gabz73 opened this issue Jun 17, 2024 · 2 comments
Open

Convert inches to cm in Extent field of museum objects #2656

Gabz73 opened this issue Jun 17, 2024 · 2 comments
Labels
maintenance/performance not new features or bugfixes, but keeping/improving the app running well

Comments

@Gabz73
Copy link

Gabz73 commented Jun 17, 2024

Museum objects use inches instead of cm in Past Perfect. We want to convert the extent statements to metric. Can this be done on the back end? Conversion s/b 2.54 cm per inch, with one decimal point retained.

@Gabz73 Gabz73 added the maintenance/performance not new features or bugfixes, but keeping/improving the app running well label Jun 17, 2024
@eddierubeiz
Copy link
Contributor

This is perfectly feasible, but it's not a 10-minute job either.

See e.g.: https://digital.sciencehistory.org/works/fb4948977 for an example: all the dimensions are contained in one string.
So we want a recipe that can take a few hundred strings of the form:
10.25 in. H x 8.25 in. (each of which can contain up to three separate dimensions in inches)
and return a string with each value converted appropriately, and of course with the new units.

@jrochkind
Copy link
Contributor

jrochkind commented Jun 17, 2024

Yep. i'd use a regex to look for something like /(\d+\.?\d*) in\./. and just replace each one with ${converted_to_cm} cm

The code doesn't need to know whether there are two dimensions or three or that the dimensions might be lableled with W or anything, just replaces every XX.XX in. with XX.X cm. Only in the specific field(s) specified. (I think just extent)

Does need some testing to make sure no data corruption, it is a bit risky true! Still a human doing it manually would probably make some errors too!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintenance/performance not new features or bugfixes, but keeping/improving the app running well
Projects
None yet
Development

No branches or pull requests

3 participants