Hi @kirsten_mc and @Symbioquine - sorry for the long silence! Recovering from a house electrical fire… catching up on everything that has happened over the past few weeks.
Some thoughts:
I’d be happy to reach out to some of the research farms I’m working with to see if they would be willing to let us use their geometry. That could be a nice option, because they are generally non-profits and are serving the public already.
As for the assets/logs records, my inclination is to invent it ourselves in an intentional way to highlight/demonstrate specific areas of farmOS functionality, rather than using “real world” data. This will keep the demo data simpler, and it can represent “canonical demonstrations”, in a sense.
As for how we store the demo content in the repository, I really like the idea of storing it in JSON files that match what the API of farmOS expects. This is how we will want to do it in farmOS 2.x with the Default Content module, anyway. And in farmOS 1.x we can do the same thing, and perhaps just use hook_install() to create the content via the API directly - so it would just read in the JSON files and send them to the appropriate endpoints to create content.
Then, when we need to make a 2.x branch of the farm_demo module, we can just make minor changes to the JSON files to match the new API. This will also serve as some documentation for differences between the 1.x and 2.x APIs, because you’ll be able to just view the Git diff between the 1.x and 2.x branch files.
So, TL;DR, I’d suggest this approach:
Ask research farm to use their geometries.
Make up our own assets/log records in a way that highlights features and best practices.
Export these as JSON for storage in the repo, and use the API to create them on install.
Sorry I’ve been slow to reply, @mstenta, I’ve been busy buying our land (*dance*dance*) and getting to work on it (*too sore to dance*too sore to dance*)
We talked about this in the last Community Call, and Wolfe’s Neck Center are happy for us to use their data. Leah and I were going to have a call to sort out exactly which data - would you like to join in?
No worries @kirsten_mc - congrats on the new property! How exciting!
That’s great to hear! Wolfe’s Neck is a great example because they manage both livestock and vegetable production, as well as some small grain trials (I believe).
We can pretty easily get a set of their areas copied over to demo.farmos.net. I still think we should invent our own assets and logs, though, rather than copying real data from their farmOS. The main reason being: we can ensure that it is a good cross-section of functionality and demonstrates specific features. So maybe we can start talking about what that can include. The next monthly call is August 12th. Perhaps we can get the areas set up before then, and then talk about example data. I like the idea of doing it in a way that we can export it all to JSON and put that into the farm_demo module.
Sounds good, @mstenta. Unfortunately, I’m going to miss the next Community Call (it’s my birthday!).
Leah and I would like to include you in a call, but I don’t have your email address to co-ordinate on a time. I believe you have mine - could you please email Leah and I so that we can find a time we can all meet up to discuss what information we need and how to export it from their system?
We discussed the two purposes for this data: for training and tutorial videos, and to set up a test server for development work. We also discussed how we are mostly interested in the KML data, as we can create “fake” data for the rest.
It sounds like there will be no issues with FarmOS using Wolfe’s Neck’s KML data as a starting point. Some outstanding issues are:
how should we name the fields, etc? Do we want to use the original Wolfe’s Neck field names, or create new ones?
do we want to use the rest of the Wolfe’s Neck data as a starting point for the fake data?
Will this data require any maintenance from Wolfe’s Neck’s perspective?
Leah has sent over the KML data, which I will put in the farm_demo GitHub project. As it sounds like a really busy time right now, we can discuss the other points via email, discussion forum, or Zoom call.
how should we name the fields, etc? Do we want to use the original Wolfe’s Neck field names, or create new ones?
I think using the same field names would be fine.
do we want to use the rest of the Wolfe’s Neck data as a starting point for the fake data?
I think we should invent our own data, so that it is a smaller/simpler and more intentional demonstration of specific types of data that we want to highlight/test. I am happy to help with this process. I think keeping the data very intentional and structured will also be necessary for it to be useful in automated tests. We may just start with a VERY small set of data, and then add to it over time as we need to do more demo videos or as we add tests.
Will this data require any maintenance from Wolfe’s Neck’s perspective?
Nope! My thought is that apart from the areas it will be totally disconnected from Wolfe’s Neck’s real activities moving forward.
I just thought of another potential fun use of this data:
Using the farmOS-map library, along with this data, we could make the web banner on farmOS.org interactive. It’d be a really cool way to showcase at least some of farmOS’s functionality right there on the home page, w/o the need of a fully fledged farmOS server, since it could all just run right there in the browser w/ a static data source.
This would probably have to wait for the Gatsby implementation, but otherwise wouldn’t be that hard, I don’t think.
Hi @mashvee - welcome to the farmOS forum! The demo site discussed above is not ready yet. But if you’d like to test farmOS you can start a trial here: https://farmier.com/signup