jsantiago318/sumo-str-sim

1. This repository is a SUMO-based traffic simulation asset set, not an application with source code. Its architecture is centered on map input, network generation, simulation scenarios, detector instrumentation, and exported results.

2. The base geographic input lives in mapa_original/, which contains the original road map as mapa-pr-2.gz and an OSM source file for editing. This is the upstream reference for all network variants.

3. dtl_modif/ is a modified scenario built from a local map file (mapa-pr-2.osm) plus SUMO network artifacts. It represents one network branch used for simulation after manual editing or conversion.

4. pureba/ is a self-contained test scenario. It includes a network definition (net.net.xml), network edit config (net.netecfg), route file (net.rou.xml / sumoNet.rou.xml), detector definitions, and a SUMO config (sumoNet.sumocfg). This folder looks like the main sandbox for verifying detector placement and output behavior.

5. abr-28/ is the most complete simulation package. It contains the SUMO config, network files, additional network/route/detector artifacts, and a large set of detector-specific configuration files. This looks like the primary experiment set with multiple measurement points and output captures.

6. The core SUMO network layer appears in files such as simulador.net.xml, sumo_sim.net.xml, and net.net.xml, with matching route files (*.rou.xml) and SUMO launcher files (*.sumocfg). These are the main inputs that SUMO consumes at runtime.

7. Network editing is supported via NetEdit configuration files like sim_net.netecfg and net.netecfg. These tie the OSM/map source to generated SUMO network files and suggest the workflow is: edit/import map, generate network, then run simulation.

8. Detector infrastructure is a major subsystem. pureba/ has named detectors such as detector_entrada.xml, detector_final.xml, and detector_recta.xml. abr-28/sumo_config/ has many detector placement variants (entrada_*, antes_*, despues_*, conteo*, de1_simulador.xml, etc.), implying multiple counting/observation points along the road network.

9. The output/csv/ subtree under abr-28/sumo_config/ is the results boundary. It contains per-detector XML/CSV outputs generated by SUMO, showing the flow from network + routes + detectors into analysis-ready measurement files.

10. The repository’s implicit data flow is: OSM/map source in mapa_original/ or dtl_modif/ → network generation/editing via NetEdit configs → route and detector definitions → SUMO execution through *.sumocfg → detector outputs in output/csv/.

11. There are multiple scenario variants rather than one unified pipeline. pureba/ is a test harness, dtl_modif/ is a modified map/network branch, and abr-28/ is a richer scenario with many detector and output files. An architecture diagram should show these as parallel scenario bundles sharing the same SUMO tooling pattern.

12. External tooling that matters here is SUMO itself and NetEdit. The repository is organized around those tools’ file formats, so the key boundary is between static simulation assets in the repo and the SUMO runtime that reads them and emits detector-based results.