This page will track the progress of my alternative accommodation siting analysis. I don't have much time to devote to it, unfortunately, but it will have served its purpose if it does any of the following...
refreshes my memory on SQL, which I haven't touched since early in my Ph.D.
helps me gain familiarity with framing problems and solutions in a business context.
shows me exactly where to launch my cabinette empire enterprise.
I will be using DMAIC (in this case, DMADV) and Agile
principles to guide my work as indicated by the tags in each entry. Sprints will be weekly, and posts will be as-needed to plan and document progress. I will do my best to wear both user and product owner hats and keep the tool as realistic as possible; obviously, there are very real concerns about feasibility (parcel slope, utility availability, favorability of state laws, wildfire risk, etc.) which extend beyond the current scope of this project. They may be considered at a later stage.
Sprint 1 Kickoff-Determine the scope of the project based on available data
User story: I would like to target my investment in launching a new cabinette lodging enterprise.
I want a ranked list of potential sites near U.S. National Parks to prioritize scouting efforts.
Some considerations I have are the desirability of proximity to multiple parks and consciousness of how competitive the market is.
Acceptance:
[x] problem statement documented
[x] KPIs documented
Acceptance:
[x] NPS visitation data
[x] park visitor center coordinate data
[x] OSM lodging and road data
[x] land status (public/private) data [ ] flood zone data [deferred]
[x] critical habitat data
[x] files documented in DATA_SOURCES.md
Notes: Monthly summaries of NPS visitation data from 2020-2024 were downloaded via the Query Builder for Public Use Statistics (note: COVID Shutdown impact currently ignored for this project). Target columns and their definitions are documented in DATA_SOURCES.md.
A 2023 map of NPS buildings has been downloaded from ArcGIS. It should be possible to filter features by building name and average the polygons to a point.
Land status data has been downloaded from ScienceBase for states within the project scope.
FEMA's National Flood Hazard Layer will be used to assess flood risk. The U.S. Fish and Wildlife Service information on critical habitats will be used to avoid protected areas.
Completed: NPS visitation data, visitor center coordinates, OSM lodging data, land status data, critical habitat data
Incomplete: flood zone data, documentation in DATA_SOURCES.md (OSM info pending)
Notes: There was some trouble with the flood zone data acquisition; it will be deprioritized until further notice.
Acceptance:
[x] All files documented in DATA_SOURCES.md
[x] Perform basic quality checks on all sourced datasets
[x] Preprocess the sourced datasets (consistent projection, clipping to target region)
Retrospective: Sprint 1 was successful in gathering most of the required datasets, but some challenges were encountered with downloading the flood zone data. There was also an error in querying the OSM road data. A replacement, the National Transportation Atlas Database, will be used instead. This data will be acquired and preprocessed in Sprint 2, which will focus on ensuring all datasets are preprocessed and properly documented. The product owner has approved the deferral of flood zone data incorporation and the replacement road dataset as keeping development on schedule is the top priority. The product user is satisfied with the reduction in features for this iteration.
Acceptance:
[ ] Define site scoring criteria in terms of demand, access, and competition [moved to Sprint 4 backlog]
[x] Design and implement workflow for identification of candidate locations (i.e., land with no known constraints within 30 miles of park visitor centers)
[ ] Design and implement workflow for calculation of candidate location features (e.g., proximity to visitor centers, access to roads) [moved to Sprint 4 backlog]
[ ] Design workflow for adjustable scoring of candidate locations [moved to Sprint 4 backlog]
Notes: All essential layers for the first iteration (visitor centers, visitation, lodging, roads, land status) have been preprocessed and loaded into the database. The next step is to develop scoring criteria for new cabin sites. The product owner wants to keep the scoring weights adjustable so that they may be readily modified and explored by the product user (who also happens to be me).
Retrospective: Sprint 2 was successful in establishing a foundation for the analysis.
Acceptance:
[x] Create interactive dashboard to visualize and organize sites and scores
Notes: The UI of the dashboard should be geographic and intuitive, allow for easy exploration of alternative site scoring weights, and have clear visualizations of site scores and rankings. The main view should be of the top sites in the entire study region. Visitor centers should be selectable on the map to view their top site candidates. Sites themselves should be available for selection on the map to see their properties and scoring breakdowns.
Acceptance:
[x] Design and implement workflow for calculation of candidate location features (e.g., proximity to visitor centers, access to roads)
[x] Design workflow for adjustable scoring of candidate locations
[x] Define site scoring criteria in terms of demand, access, and competition
[x] Create interactive dashboard to visualize and organize sites and scores
Notes: Sprint 4 will now focus on completing the site suitability analysis and developing the interactive dashboard. The product owner has approved the new goals as generating mock data for the dashboard would only serve to delay progress towards a functional product.
Retrospective: In Sprint 3 only the workflow for identification of candidate locations was completed. The primary reason for delay was half of the sprint being unexpectedly allocated to another high-priority project, impacting my available capacity for the Cabinette project. On a positive note, planning Sprint 4 in advance was very useful in guiding the workflow development for Sprint 3.
Acceptance:
[x] Refine interactive dashboard after further testing
[x] Push changes in workflow scripts
[x] README updated with database reproduction instructions
[x] Supporting data published
[x] Dashboard that meets KPIs
[x] Determine strategy for dashboard "deployment"
Notes: In Sprint 5, the rudimentary map dashboard will be refined to improve functionality and UX. Since I have only limited access to Power BI Desktop, I will need to look into less conventional ways to share or showcase the dashboard.
Retrospective: Due to the backlog from Sprint 3, there was an exceptionally high workload in Sprint 4. The product owner approved the first iteration of the dashboard, but some of the functionalities planned, namely the rank table, still have issues that need debugging for product user use.
Sprint 5 Review-First Iteration of Dashboard Available
Notes: The dashboard is running locally and meets or exceeds the requirements set by the KPIs. The product user was satisfied with the ease of changing scoring methods and weights but finds the map "fiddly". The product owner is satisfied that the KPIs were delivered on the first iteration and is eager to expand on the logistical aspects, starting with the deferred features.
Retrospective: Through careful rearrangement of sprint tasks, it was possible to deliver the first iteration of the dashboard on time. The next sprint will be far in the future, likely necessitating updates to the data sources. Online publication of the Power BI report without affiliation or paying for licensing was unfortunately not feasible.
Known Issues: The desktop version of the dashboard map can be difficult to interact with, zooming suboptimally, but this seems engrained in the behavior of Icon Map.
Next Steps: Further development is not planned until there is hope of an actual use case. User feedback is welcome via email or as a GitHub issue.
Notes: In order to gain more practical JS experience and create a more conveniently accessible dashboard, I will be recreating the cabinette dashboard using open-source JavaScript/TypeScript tools.
As opposed to the mini-sprints I was conducting in the earlier phases, this will be a more traditional sprint lasting several weeks to the end of 2025.
I am extending the window to accomodate the holiday season. KPIs will reflect, at minimum, feature parity with the Power BI dashboard.
Acceptance:
[ ] Dashboard prototype that meets KPIs
Key Performance Indicators (KPIs):
Users can pan, zoom, and select features on an interactive map.
Charts/graphs will be integrated with feature selection to display site scores and rankings.
Users can adjust scoring weights and filter sites dynamically.
Dashboard loads within 30 seconds for existing datasets.
Planned Steps:
Define requirements: List core features, data sources, and user needs
Investigate applicability of proposed tech stack: React (TypeScript), Leaflet, Plotly.js
Set up project: Configure folder structure and basic files
Implement core features:
Data loading from APIs
Map component for spatial data
Chart components for non-spatial data
Interactive filters and controls
Testing & QA: Write unit/integration tests and validate with real datasets.
Deployment: Host on Azure App Service (or similar), set up CI/CD.
Notes: The project infrastructure has been planned and set up. The required (based on PowerBI model) tables from the PostgreSQL database are hosted on Neon an accessed via GCP to support dynamic SQL queries. Progress has started on the front-end using React (TypeScript) for UI components, Leaflet for interactive maps, and Plotly.js for data visualizations. The app will be hosed in a separate repository Cabinette-Frontend
Notes: Progress continues with components. All basic functionalities from the Power BI report have been replicated with the exception of the site visitation gagues which require further troubleshooting. There was a decision to be made on whether to maintain query logic on the client side or move it to the API.
Given the current scope and dataset size, keeping query/filter/sort logic on the client side seemed like the better choice and has simplified development. Although such a scenario is currently not foreseen, this issue may be revisited if there is ever a need to scale the app up.
Notes: The new fully online version Cabinette dashboard is now live and accessible on Vercel. All planned features have been implemented and pass preliminary testing, including interactive map navigation, dynamic site scoring and filtering, and selection-dependent visitation charts. The app is backed by the Neon-hosted PostgreSQL database and meets all performance and usability requirements. Feedback is very welcome!
Acceptance:
[x] Dashboard deployed and publicly accessible
[x] All KPIs for interactive map, charts, scoring, and filtering met
[x] Performance target (loads within 30 seconds) met and exceeded
[x] Documentation and user guides updated
Retrospective: Sprint 6 successfully delivered a fully functional and accessible dashboard, replicating and extending the capabilities of the original Power BI report just in time to ring in the new year. The migration to open-source web technologies has met the goal of improving accessibility.
Incorporate Bookmarks and Theme Toggle: Response to User Feedback
Notes (2026-01-07): Recent user feedback highlighted the desire for a way to bookmark favorite sites and the option for a lighter theme. In response, a site bookmarking functionality and a theme toggle will be added.
Acceptance:
[x] Site bookmarks can be toggled from the text details card or ranking table
[x] Bookmarked sites are accessible in a filtered view
[x] Users can toggle between light and dark themes
[x] Bookmarks/theme persist across sessions using local storage
Retrospective: Upon clarifying user feedback, it was determined that the introduction of bookmark utilities was also a requirement, so upload, download, and merge capacity was added. The new features were well-received in user testing. After weighing the complexity tradeoff, Redux was introduced to manage a global state for bookmarks and theme preference across components. This helped streamline the visible site filtering, with a selector being applied to address a staleness issue.