palashbadjatya01/dataexplorationprojects

1. This repository is not a single application; it is a collection of independent Python/Jupyter data-analysis projects. Each subdirectory is a self-contained notebook workspace focused on one dataset or one analytics exercise.

2. The top-level architecture is very simple: a shared README.md, a Conda environment file (environment.yml), and multiple project folders. There is no shared application code, service layer, or cross-project package structure.

3. The main execution unit across the repo is the notebook. Every project folder centers on a .ipynb file that likely contains data loading, cleaning, exploration, visualization, and conclusions in one place rather than separating those concerns into modules.

4. The data layer is file-based and local. Inputs are stored directly in each project folder as CSV, JSON, or GeoJSON files, which means each notebook reads from static datasets rather than a database, API, or message stream.

5. CrimeDataExploration is a spatial/data exploration project using actes-criminels.csv and limitespdq.geojson. That combination implies a workflow that joins tabular crime records with geographic boundaries for map-based analysis or district-level aggregation.

6. DataOutlierDetectionsCSV is a CSV-focused analysis notebook. Its structure suggests a pipeline of inspecting a raw tabular dataset, identifying anomalous values, and validating outlier detection logic inside the notebook.

7. DynamicPricingTransformationJSON is the JSON-based counterpart. The main flow here is likely parsing nested JSON, transforming it into analysis-friendly tabular form, and then evaluating pricing-related patterns or rules.

8. UIUCBuildingInventoryExploration is another tabular exploration project, using building_inventory.csv. This appears to be a standalone dataset analysis notebook centered on building inventory attributes and descriptive statistics or filtering.

9. DashboardBuildingVSSqFootage is the closest thing in the repo to an interactive reporting layer. It contains a single notebook, so the “dashboard” is notebook-driven rather than a deployed web app or separate BI service.

10. problemStatement.txt files in some folders indicate that these notebooks are assignments or guided exercises. Architecturally, those text files define the analysis objective, while the notebook implements the solution and narrative.

11. There is no shared persistence or backend infrastructure. The repository’s data flow is: static raw dataset files in each folder → notebook reads and transforms them → notebook outputs charts, tables, and interpretation.

12. The environment boundary is managed through environment.yml, and the Binder badge in the README shows the repo is intended to be reproducible in a hosted notebook runtime. That matters because it suggests the notebooks are meant to run in a consistent Python environment rather than as installed packages.

13. Overall, the repository should be diagrammed as a set of parallel, isolated analytics workspaces under one roof, not as a layered system. The key architectural elements are notebooks, local raw datasets, and a reproducible Python environment for interactive exploration.