Comments (10)
what is your workflow with this regard?
you remind me of a no-go comment from the UBC garden, where they lamented the way Bauble handles plantings, and the inability to separate-join things within one accession. if I understood their comment correctly, this was something they use when they split plants (same accession) at several locations. then imagine they move a plant group to a location where there's already a plant group for the same accession, and they expect to be able to join groups.
it surely is possible to have a list of intended locations and it's good you mention this now because it does need a database change.
from ghini.desktop.
That sounds like a bad accessioning policy to me! We would give something planted in the same spot from the same source material a different planting number if it was planted at a different time (unless it was within a short period and was a straight forward replacement or the like).
Work flow is fairly straight forward basically its collection planning. Currently when planning for the next years planting (3500 plants a year on average, we are a young blank site that is growing fast) we use a spreadsheet then add it to the database when we plant. Its double handling and I feel we should be able to do this planning within the database and have been experimenting with it and I think, with a slight change, we should be able to do it.
So hypothetically: we start the record for an accession at the planning stage, when we are looking at what we are going to be planting in a new collection (e.g. we are going to be having a community planting day and are going to plant 500 trees in a "timber trees" collection) but don't fill in every field, e.g. the date received, just the ones we need at this point. We use the "intended locations" to show where we are looking to plant them and add a note for which planting bee date they are intended for. Then, when we receive the plants, we fill in the received date and when we plant them we create a plant entry for them and add the planting date (now that there is a spot to add it!
What I would like to be able to get from the data is to be able to search for everything that has an intended location of garden bed XYZ or everything with a note for a set planting bee date (or both date and bed) or everything that isn't planted and is intended to be from a certain supplier or, of course, everything yet to planted. All things I think I could make queries for.
Do you think there is a better way to do this collection planning? I do have concerns about inserting accessions before they actually exist but can't think of a better way and it's a fairly critical part of my day to day work. I did think of having a second database for it and exporting/importing the data when it is planted but worry that it could get messy with an accession having a few plant entries and on different dates etc.. but you only want to import 1 of the plant entries at this point and will pull in the others later when they get planted. I need to get away from the current spreadsheet method!!
from ghini.desktop.
I think I follow you but do not see the problem.
why are you doing first spreadsheet then bauble and not directly into the database?
if you are clear that accessions with a blank date_received
are things that you are still just planning, I do not see why you should not use this workflow.
is a tag
unpractical here? it's a pity we cannot tag an object while we're editing it. what do you think if we would define a keyboard shortcut, so while editing something, you would hit ctrl-shift-t
and the object would be tagged (with a selected tag). for this to work, the tag plugin should register a global keyboard shortcut, which would be active when any editor is open, and there should be a way to select the tag associated to the shortcut.
from ghini.desktop.
on the other hand, if you have advantages from the spreadsheet method, you only need transform it into a json file and import it in the database when you're comfortable.
from ghini.desktop.
That is what I'm trying to say, I don't want to be doing it in a spreadsheet first and then adding it to the database it's double handling. I want to be able to add it into the database when we are planing our next years collection expansions and planting days. My concern is I don't want to "pollute" the database with lots of inaccurate an irrelevant data. (Our first database began life as the landscape architects "procurement and design" database with thousands of entries about what species "could" be part of the various collections. Thing is it never got cleaned up to a reflect the as constructed state so I am currently in the processes of manually going through all the data and auditing the collection to see what does actually exist before I entering it into Bauble)
So for example, in any one year (being a large, young, developing garden on a blank site) we may be designing 10 to 20 new collections containing a total of 3000-4500 plants. Most of these collections would have sub categories, e.g. "Palms Walk" is broken up into 5 major global regions or "Ethnobotanical Collection" into various uses (medicinal, food, shelter, etc.) The issue is that planning involves a lot of research, brainstorming with stakeholders/landscape architects/etc, testing against our Living Collection Policy, risk assessing for weed potential etc. and looking for availability from suppliers etc. etc. so, in our current spreadsheet method, things are put in and then removed or the location changed or the numbers of plants are changed or what have you and this can take some time to "nut out" before a consensus is arrived at and we have a definitive planting schedule for the year. In its early days it is usual to have twice the number of species as we end up with on the list. Then we have to lock in dates (ideally each intended location should have an intended planting date and an intended number of plants for this purpose) based around our works program and community engagement programs. Of course then there are the little additions that creep in throughout the year also as replacements for damaged plants etc. So its a big ugly beast of a process and a big ugly spreadsheet.
As for why we haven't been doing this within Bauble already is two things, the concern of polluting the data with a whole heap of irrelevant data that will ruin search results, reports, counts, etc. and because of the limitations on the number of intended locations, it is quite common for us to buy a tray of 100 plants of one species and use them up throughout the years, planting them in almost every new collection (e.g. 10 locations). So that would be one accession with 10 intended locations and hence "plant" entries.
I know your going to tell me that I am expanding the brief as I go accession where quantity_recvd!=0
part to the query). But to do this I would need intended location
int. date planted
and intended quantity
kind of like a list or table with 3 fields or columns. Does this make sense? This is another of those things that has been bugging me for sometime and I haven't brought up as I'm not sure I have the ideal solution but this one seems like it would work to me. I can't stand double handling the data by putting it in a spreadsheet then entering it into Bauble later.
from ghini.desktop.
@RoDuth, attach here one of those spreadsheets of yours!
maybe not a full real one, but one with the full real structure.
and you have had a look at the new dynamic fields, that can be used in reporting? not useful to you here?
from ghini.desktop.
I'll have to grab the latest spreadsheet from work but have a few days off this week (public holiday, etc.) so it will have to be later in the week.
I did consider the notes/dynamic fields option but kept coming back to the fact that the "Intended Locations" functionality is already there, its just very limited. So much so that it's almost useless for me. It's one of those things, you either use it or you don't, and I had too many examples where it didn't work with just the 2 locations so I ended up not using it. Its a shame when there is a function that almost works but not quite, especially when it is such a big part of what we do here!
from ghini.desktop.
Procurement Living Collection.xlsx.zip
Example of the sort of planning spreadsheet we work with. This is greatly stripped back version, basically just copied out the sheet that is relevant, without any links, and left one entry in there. The last column has some basic explanations of what some of the less obvious columns are used for. It's fairly simple really just feels like double handling doing it this way when it could all be in the database.
from ghini.desktop.
@mfrasca I think this should be reopened (I can't as you closed it). Unless I've misunderstood or missed something I believe this feature has not made it into 3.1. This is a very useful feature for us.
from ghini.desktop.
port this to 3.2 please
from ghini.desktop.
Related Issues (20)
- restoring backup does not refresh home count
- Exporting data with CSV does not seem to work in 1.0.87 and 1.0.88 HOT 11
- Authors missing on some labels HOT 4
- install sentry on rino.ghini.me HOT 1
- taxon-accession automatic link to accepted HOT 2
- implement autonyms HOT 8
- consider GBIF as (alternative) taxonomic source HOT 10
- Source names not sorted
- sp_dist_data could make better use of available space
- quick-csv export stops on None step
- Theplantlist => worldfloraonline HOT 7
- Species addition confusion HOT 8
- Better support for plant culture information
- Quantity needs units and fuzzy support HOT 7
- Accessions id for prior years HOT 3
- Location support needed HOT 3
- Cannot install on ubuntu 20.04.1 LTS HOT 8
- the TNRS has moved
- convert data from IrisDB to ghini desktop. HOT 2
- Pictures? HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ghini.desktop.