Folder reconfig, adding reading data notebook, and Onboarding 4 notebook

[mbforr]

1. Adding a new folder structure and removing old notebooks that are not working ATM or need review

.
├── README.md
├── advanced                
├── datasets
│   └── foursquare-places-example
│       └── assets
├── get-started
│   └── map-config
├── snippets
├── wherobots-ai
│   ├── conf
│   ├── gpu
│   │   ├── img

2. New snippets section with code snippets and one new notebook
3. New Onboarding Part 4 notebook

[gitnotebooks]

Found 17 changed notebooks. Review the changes at https://app.gitnotebooks.com/wherobots/wherobots-examples/pull/38

[prantogg]

LGTM!

[RoboDonut]

We really shouldn't be storing datasets here. IIRC those assets were more images and configs and just needs a rename.

I was hoping we could look at a much more of a flat structure and consistency in the naming.

Something like
FeatureType_feature_lang e.g.

• WherobotsDB-Importing-Python
• WherobotsAI-DBScan-Scala
• WherobotsAI-ObjectDetection-Python

When there is a hard requirement for a GPU or other org upgrade we highlight that the top of the first cell.

[RoboDonut]

something more like this with consistent naming Product-Feature-Language. Asset names match the notebook with asset name suffix. A dir for on-boarding and a dir for partner notebooks.

cc @jiayuasu @james-willis @rbavery

├── assets/
│   ├── Foursquare-Places-Wherobots-map-config.json
│   ├── Foursquare-Places-Wherobots-choropleth.png
│   ├── Foursquare-Places-Wherobots-placemaker-tools-2.png
│   ├── Foursquare-Places-Wherobots-1.png
│   ├── WherobotsAI-MapConfig-JSON.json
│   ├── Wherobots-Onboarding-CentralPark-Config.json
│   ├── Wherobots-Onboarding-Config.json
│
├── notebooks/
│   ├── First-Wherobots-Notebook.ipynb
│   ├── WherobotsDB-KNN-Python.ipynb
│   ├── WherobotsDB-OvertureMaps-Python.ipynb
│   ├── WherobotsDB-STACReader-Python.ipynb
│   ├── WherobotsDB-TileGeneration-Python.ipynb
│   ├── WherobotsDB-Example-Python.ipynb
│   ├── WherobotsAI-DBSCAN-Python.ipynb
│   ├── WherobotsAI-Glocal-Python.ipynb
│   ├── WherobotsAI-LOF-Python.ipynb
│   ├── WherobotsAI-MapMatching-Python.ipynb
│   ├── WherobotsAI-ObjectDetection-Python.ipynb
│   ├── WherobotsAI-Segmentation-Python.ipynb
│   ├── WherobotsAI-GPU-BringYourOwnModel-Python.ipynb
│   ├── WherobotsAI-GPU-Classification-Python.ipynb
│   ├── WherobotsAI-GPU-ObjectDetection-Python.ipynb
│   ├── WherobotsAI-GPU-Segmentation-Python.ipynb
│   ├── WherobotsDB-Havasu-Iceberg-Geometry-ETL-Python.ipynb
│   ├── WherobotsDB-Havasu-Iceberg-OutDB-Raster-ETL-Python.ipynb
│   ├── WherobotsDB-Havasu-Iceberg-Raster-ETL-Python.ipynb
│   ├── ESA-WorldCover-Python.ipynb
│   ├── WherobotsDB-KNN-Scala.ipynb
│   ├── WherobotsDB-TileGeneration-Scala.ipynb
│   ├── WherobotsDB-Example-Scala.ipynb
│   ├── WherobotsDB-Havasu-Iceberg-Geometry-ETL-Scala.ipynb
│
├── onboarding/
│   ├── Wherobots-Onboarding-Part1-LoadingData.ipynb
│   ├── Wherobots-Onboarding-Part2-LoadingData.ipynb
│   ├── Wherobots-Onboarding-Part3-Accelerating-Geospatial-Datasets.ipynb
│
├── partner_examples/
│   ├── Foursquare-Places-Wherobots-Python.ipynb
│
├── sedona-maven-example/
│   ├── .gitignore
│   ├── pom.xml
│   ├── src/
│   │   ├── main/
│   │   │   ├── scala/
│   │   │   │   ├── com/
│   │   │   │   │   ├── wherobots/
│   │   │   │   │   │   ├── sedona/
│   │   │   │   │   │   │   ├── SedonaDbExample.scala
│   │   ├── test/
│   │   │   ├── resources/
│   │   │   │   ├── .gitignore
│   │   │   │   ├── scalastyle_config.xml
│
├── README.md

[mbforr]

@RoboDonut so there are not datasets just notebooks to connect to data - namely Out-DB rasters. This is meant to capture some of the Earth Engine audience.

For the naming I tend to lean away from feature based naming. I think that is fine for existing customers or those who have spent time with our platform but for those who haven't it tends to be a bit confusing as in they don't know what they need yet. If we go on a more use case naming that might be a bit easier.

[rbavery]

I prefer Feature based naming without long file names including the product and language. This gets repetitive imo and I think a more nested folder structure would be easier to view and navigate for first time and long time users. Features can be named by commonly understood terms rather than our particular product name (so we could avoid putting Havasu in the name)

Agree on not having a folder called "datasets" I would expect to find data in there.

We could look to some existing examples for inspiration. I like how this community example for GEE separates "Feature" focused notebooks from more conceptual notebooks that integrate multiple features like "HowEarthEngineWorks" or "Tutorials". In cases where we have scala examples (uncommon) we could have only a scala subfolder rather than an additional python folder

[mbforr]

@RoboDonut @prantogg @rbavery added new changes based on the above feedback. I went with:

• Feature based folder structure
• Shorter names for notebooks

We will need to decide on - vs _ and then capitalization vs all lower case.

[prantogg]

Folder structure LGTM. I prefer _ over - in file names.
_ makes selecting files name with double click much easier.

[james-willis]

I hate having the product name at the start of the file. it looks like this in the browser:

As the customer why do I give a crap that its called wherobotsDB knn join, I just want to do a knn join.

[rbavery]

I think that's the old structure @james-willis and agree. Love the new update @mbforr https://github.com/wherobots/wherobots-examples/tree/48816a1c38a01c981a0960ad77a5ded03775044b I see we use wherobots-db in a handful of places which I don't mind for some features which are extra unique to Wherobots, and since they don't occur in folders with lots of repetitive product names.