Protected Document
Enter the passcode to view this proposal.
Enter the passcode to view this proposal.
Prepared for
Brian Nolte
Nolte Analytics LLP — Litigation Support
Proposal Date
Ref: SPACEO-2025-NOLTE-001
Project Proposal
A comprehensive routing analysis for ~32,000–35,000 Las Vegas delivery addresses. This tool quantifies the non-linear relationship between subscriber count and delivery distance, and compares delivery efficiency across time-of-day scenarios — producing court-defensible, data-driven evidence for litigation.
Proves that reducing subscribers by X% does NOT reduce driving distance by X%. Quantifies the true cost ratio at each subscriber level.
Compares 2 AM (night, free-flow) vs 2 PM (afternoon, traffic) delivery. Shows driver count difference and total hour impact.
Self-service tool where you upload addresses, configure scenarios, and get results with charts, tables, and maps — no coding required.
Export CSV and JSON data for use in depositions, expert witness reports, or further analysis. Methodology section included for court defensibility.
We've built a fully functional prototype and tested it with 1,000 synthetic Las Vegas addresses. You can try it right now — upload data, configure scenarios, and see real results.
| Subscribers | Addresses | Miles | % of Full Distance | Cost Ratio |
|---|---|---|---|---|
| 100% | 1,000 | 558.5 | 100% | 1x |
| 50% | 500 | 383.4 | 68.6% | 1.37x |
| 30% | 300 | 300.9 | 53.9% | 1.8x |
| 20% | 200 | 253.3 | 45.4% | 2.27x |
| 10% | 100 | 185.5 | 33.2% | 3.32x |
Delivering to only 10% of subscribers still requires 33.2% of the total driving distance — not 10%. Each remaining subscriber costs 3.32x more per mile to reach. This proves the non-linear relationship between subscriber count and delivery cost.
You upload your CSV file containing the ~32,000 delivery addresses (street, city, state, zip). If the addresses don't have latitude/longitude coordinates, we geocode them automatically using the US Census Bureau Geocoder (free, no API key needed) or Geocodio (~$35 for 35K addresses, faster).
Your data: Street number + street name + city + state + ZIP → converted to lat/lon coordinates
Addresses are grouped into geographic "zones" using K-means clustering (~50 addresses per zone). With 32,000 addresses, this creates approximately 640 delivery zones. This mirrors how real newspaper delivery territories are organized — nearby addresses grouped together.
Why zones? The road distance API has a 100-address limit per call. Zones also produce more realistic routes — a driver delivers to one neighborhood, not zigzags across the city.
For each zone, we compute the actual driving distance between every pair of addresses using OSRM (Open Source Routing Machine). OSRM uses real OpenStreetMap road network data — actual streets, speed limits, turn restrictions, one-way roads. This is the same road data that powers many GPS navigation apps.
Result: a distance matrix (how far each address is from every other address) for each zone, measured in actual road miles — not straight-line distance.
Google OR-Tools solves the Vehicle Routing Problem (VRP) for each zone. This is the same class of algorithms used by Amazon, UPS, and FedEx. The solver finds the shortest possible route through all addresses while enforcing constraints:
Output: optimized routes, total distance, total time, and minimum number of drivers needed.
The entire pipeline (clustering + distances + route optimization) runs multiple times with different subscriber counts: 100%, 50%, 30%, 20%, 10% (or any custom percentages you choose). For subset simulations, we randomly sample addresses from the full population, re-cluster, and re-optimize — producing a fair comparison.
You can also add custom percentages (e.g., 75%, 15%) and adjust the delivery window for each run.
We compare delivery at 2:00 AM (free-flow, night) vs. 2:00 PM (afternoon traffic) using road-class-specific speed profiles:
| Road Type | 2 AM Speed | 2 PM Speed | Examples |
|---|---|---|---|
| Residential | 100% | 90% | Side streets, neighborhoods |
| Arterial | 100% | 65% | Flamingo, Sahara, Tropicana, Charleston |
| Highway | 100% | 72% | I-15, I-215, US-95 |
Speed factors derived from Nevada DOT Traffic Monitoring Program data and FHWA HPMS standards. LV delivery routes are typically ~60% residential, ~30% arterial, ~10% highway.
Answer: No. Our analysis proves it's significantly more than 10%.
Because delivery addresses are scattered across the Las Vegas metro area, a driver must still traverse the same major roads and neighborhoods even with fewer stops. Removing 90% of subscribers doesn't eliminate 90% of driving — it eliminates only the short detours to individual houses. The "backbone" driving distance between neighborhoods remains largely unchanged.
In our 1,000-address demo: 10% of subscribers = 33.2% of total driving distance (cost ratio: 3.32x). With 32,000 real addresses, we expect similar or even higher ratios due to Las Vegas's sprawling geography.
Answer: Afternoon delivery requires ~19% more time and 2 additional drivers.
At 2 AM, Las Vegas roads are virtually empty — drivers move at free-flow speed. At 2 PM, arterial roads like Flamingo and Sahara drop to 65% of free-flow speed due to traffic. This increases total delivery time, which in turn requires more drivers to complete all deliveries within the 4-hour window.
In our demo: Night delivery needs 10 drivers (38.8 total hours). Afternoon delivery needs 12 drivers (46.1 total hours). That's 2 additional drivers and 7.3 additional labor hours per delivery cycle.
Every component uses industry-standard, open-source tools. No proprietary "black box" algorithms.
| Component | Technology | Details |
|---|---|---|
| Geocoding | US Census Bureau / Geocodio | Street address → lat/lon. Census is free; Geocodio is $1/1,000 addresses for bulk. |
| Clustering | scikit-learn K-means | Groups nearby addresses into zones of ~50. Deterministic (same input = same output). |
| Road Distances | OSRM (self-hosted) | OpenStreetMap road network. Real road geometry, speed limits, turn restrictions. Self-hosted for speed. |
| Route Optimization | Google OR-Tools VRP | Vehicle Routing Problem solver with time-window constraints. Same algorithm family as Amazon/UPS. |
| Traffic Model | Road-class speed profiles | Residential 90%, Arterial 65%, Highway 72% at 2 PM. Based on Nevada DOT data. |
| Stop Time | Configurable (default 30s) | Per-stop service time for newspaper toss from vehicle. Adjustable for different delivery types. |
All tools are open-source and free to use. No recurring API licensing fees. Full source code can be provided for independent audit.
The demo runs on 1,000 addresses. Here's how we handle your full dataset.
| Component | Demo (1K) | Production (35K) |
|---|---|---|
| OSRM | Public demo server | Self-hosted via Docker (Nevada OSM data) |
| Delivery Zones | 20 zones | ~640 zones |
| VRP Solving | Sequential | Parallel (8+ cores) |
| Server | Any laptop | VPS: 8 GB RAM, 4+ cores |
| Total Run Time | ~5 min | ~30–45 min (all 5 subsets) |
The public OSRM demo server has rate limits that make 35K addresses impractical (~100 minutes per subset). Self-hosting OSRM is a one-time Docker setup that downloads Nevada road data from OpenStreetMap. Once running, each distance matrix call takes <0.5 seconds instead of ~8 seconds — making the full analysis feasible in under an hour.
Self-service tool at a dedicated URL. Upload your 32K addresses, configure scenarios, run analysis, view results with charts/maps, download reports. No software installation required.
Table showing total miles, % of full distance, and cost ratio for each subscriber level (100%, 50%, 30%, 20%, 10%, or custom).
2 AM vs 2 PM comparison: drive hours, stop hours, total hours, drivers needed. Includes road-class breakdown.
Complete raw data: every route, every cluster, every simulation. Suitable for independent verification or import into other tools.
Leaflet.js map showing all delivery addresses color-coded by delivery zone. Zoomable, pannable, embedded in the web app.
Written explanation of every algorithm, data source, and assumption. Designed for use in depositions and expert witness reports.
All-inclusive pricing. No hidden API fees or recurring charges.
| Item | Cost | Notes |
|---|---|---|
| Production scaling (35K support) | Included | Self-hosted OSRM, parallel processing, Geocodio integration |
| Web application & analysis tool | Included | Full web UI with interactive maps, charts, and report generation |
| Geocoding (35K addresses) | ~$35 | Geocodio batch. One-time. Free if you already have lat/lon. |
| VPS hosting (Hostinger KVM 4) | ~$13/mo | 4 vCPU, 16 GB RAM, 200 GB NVMe, 16 TB bandwidth. Includes OSRM self-hosted. |
| Unlimited re-runs during project | Included | Run as many scenarios/percentages as needed for 1 month. |
| Total (all-inclusive) | $4,500 | One-time project fee. Hosting billed separately. |
Any change requests, customizations, or enhancements not outlined in the above solution will be billed at USD $45/hour. All additional work will be scoped and approved before starting.
The application runs on a Hostinger KVM VPS. Recommended plan based on project requirements:
| Plan | Specs | Price |
|---|---|---|
| KVM 2 (Budget) | 2 vCPU, 8 GB RAM, 100 GB NVMe, 8 TB bandwidth | ~$6.99/mo |
| KVM 4 (Recommended) | 4 vCPU, 16 GB RAM, 200 GB NVMe, 16 TB bandwidth | ~$12.99/mo |
| KVM 8 (Enterprise) | 8 vCPU, 32 GB RAM, 400 GB NVMe, 32 TB bandwidth | ~$19.99/mo |
KVM 4 is recommended for smooth performance with 35K addresses and OSRM. Hosting is billed monthly and can be cancelled anytime.
Payable to: Space-O Infoweb Inc
Address: 21 E. 6th Street, Unit 417, Tempe, AZ 85281
Accepted methods: Wire transfer and PayPal only
All payments and contracts to be made in the name of Space-O Infoweb Inc.
The original $10K–$15K estimate assumed $6,000–$7,000 in GraphHopper API licensing fees. By using 100% open-source tools (OSRM + OR-Tools + Census Bureau), we eliminated all API licensing costs. The only external costs are ~$35 for batch geocoding and ~$13/month for Hostinger VPS hosting.
Residential addresses: Most delivery locations are houses or ground-floor units. We assume curbside delivery (newspaper toss from vehicle) with 30-second stop time. If some locations are high-rise apartments requiring lobby access, stop time should be increased.
4-hour delivery window: Each driver shift is limited to 4 hours (e.g., 2 AM – 6 AM). This is standard for newspaper delivery. If the actual window is different, this is configurable in the tool.
Single depot: All drivers start from the same location (a central distribution point). If there are multiple depots, the tool can be modified to support that.
Las Vegas area: Road-class speed profiles are calibrated for Las Vegas metro (based on Nevada DOT data). If the analysis needs to cover areas outside LV, profiles would need adjustment.
No toll roads: OSRM routing does not differentiate toll vs. non-toll. In Las Vegas, this is not an issue (no major toll roads). Toll avoidance can be added if needed.
Random sampling for subsets: When simulating 50%, 30%, etc., we randomly sample from the full address list. This means each run produces a representative geographic distribution, not a cherry-picked subset.
Address data quality: We assume the CSV contains valid street addresses in the Las Vegas metro area. Invalid or ambiguous addresses will be flagged during geocoding.
No routing API in the world provides comprehensive real-time traffic prediction with high accuracy. Google has not released its traffic prediction APIs. We use road-class speed profiles based on published DOT data, which provides a defensible estimate (+/- 15%) but not minute-by-minute accuracy. This is the industry standard approach for litigation-grade analysis.
The 2 PM speed factors (65% for arterials, 72% for highways) are averages from DOT monitoring stations. Actual traffic varies by day, season, and weather. The model represents a typical weekday afternoon, not a specific date.
The Vehicle Routing Problem is NP-hard (computationally impossible to solve perfectly for large datasets). OR-Tools uses heuristics (Guided Local Search) with a time limit. Routes are typically within 5-10% of theoretical optimal. This is the same approach used by commercial logistics companies.
All drivers are assumed identical (same vehicle, same speed, same start location). The tool does not model individual driver knowledge of shortcuts or personal delivery preferences.
We assume each vehicle can carry enough newspapers for its full route. For newspaper delivery, this is a safe assumption (papers are light and compact).
Geocoding places the address at the road-level centroid, not the actual front door. For residential delivery (curbside toss), this is sufficient. The error margin is typically <50 meters.
Why we chose this approach over commercial alternatives.
| Option | Cost (35K addresses) | Pros | Cons |
|---|---|---|---|
| Our approach (OSRM + OR-Tools) | ~$4,500 total | No API fees, unlimited re-runs, full control, open-source, auditable | Requires self-hosted OSRM; no real-time traffic |
| GraphHopper (paid API) | $6,000–$7,000 API + $3K–$4K dev | Hosted, fast, good documentation | Per-request pricing; each re-run costs more; rate limits at 35K |
| Google Maps Platform | $15,000–$25,000+ | Best geocoding; has traffic data | Very expensive at scale; routing limited to 25 stops per request |
| NextBillion.ai | $8,000–$15,000 | Historical traffic data; good for large scale | Enterprise pricing; minimum commitment; slower onboarding |
| Manual / Google Maps | $0 (+ enormous time) | Free | Google Maps supports max 10 stops. 32,000 stops = impossible manually. |
Yes. You can change the subscriber percentages, delivery window hours, stop time, and OSRM settings, then re-run. There's no per-run cost. During the 1-month project period, you can run unlimited analyses.
OSRM uses OpenStreetMap road data, which is continuously maintained by a global community. For Las Vegas, the road network coverage is excellent. Distances are based on actual road geometry, not straight lines. Accuracy is typically within 5% of what Google Maps would show.
Yes. Every component uses published, peer-reviewed algorithms (K-means: MacQueen 1967; VRP: Dantzig-Ramser; OSRM: Luxen-Vetter 2011). Speed profiles are based on Nevada DOT and FHWA published data. All source code is open-source and can be independently audited. The methodology section in the tool provides a written description suitable for expert witness reports.
The tool geocodes them automatically. Just upload a CSV with street address, city, state, and ZIP. We use the US Census Bureau geocoder (free) or Geocodio (~$35 for 35K addresses). Geocoding happens once; coordinates are cached for re-runs.
Not in the current version. All addresses are treated equally. If priority delivery is needed (e.g., premium subscribers first), this can be added as a feature enhancement.
The tool routes to the building address. For multi-unit buildings, the stop time (30 sec default) may need to be increased to account for lobby access, elevator time, etc. For most Las Vegas residential delivery (single-family homes), the default is accurate.
Yes. The entire codebase is Python (Flask, pandas, scikit-learn, OR-Tools). We can provide the full source code for independent audit or for your team to run locally. No proprietary dependencies.
You receive all reports, data exports, and optionally the source code. The hosted web app remains available for the project duration. If you need ongoing access, server hosting can be extended at ~$13/month (Hostinger KVM 4). There are no software licensing fees.
Click "Try Live Demo" to test with our 1,000 synthetic Las Vegas addresses. See the full workflow: upload, configure, analyze, results.
Share your ~32,000 address CSV. We'll geocode it, validate the data, and run the first analysis to confirm everything works at scale.
Let us know: Which subscriber percentages matter most? 4-hour delivery window correct? Any specific scenarios for the litigation? We'll configure accordingly.
We deploy the production environment with self-hosted OSRM, run your full analysis (~30–45 min), and deliver all reports and hosted tool access.