a rev eng project regarding waze's tile map formats
more specifically, some scripts that help parse and create new tiles for waze using geojson (mainly aiming to bring Waze into ETS2, sorta)
/hexpatscontains hexpat files for use in apps like ImHex to understand waze tile files/protoscontains the protobuf files used by waze (for proper server faking)/scriptscontains python scripts regarding the processing of waze tile files (WZM/MAP_PKG/RDM, WZDF, WZT)/srccontains server-related TS code. also contains a few tests, and the some intermediate scripts
- generate a geojson file using truckermudgeon's lovely map parser/generator
- shove it into
/src/scaleGeoJSON.tsto scale it down to size (ETS2 uses maps 1:19 at scale) - run
/src/parseGeoJSON.tsto generate a json file representing the data to be converted into waze tiles - then you can either
- run
/src/index.tsand have it generate the tiles on the fly - run
/src/generate_tiles.pyand have it generate tiles ahead of time
- run
- note, tiles are often cached in the app after receiving them, so generating on the fly isnt slow
- serve the initial login stuff
- serve tiles
- handle alert data
- handle beacon data
- handle searches
- handle routes
- handle much more stuff
- splitting of map packages
- decompressing waze data files (WZDF)
- parsing wzt
- entry count
- mask bits
- offsets
- string arrays
- shape data
- line data
- line summary
- "broken"
- line round about
- point data
- point id
- line route
- from_flags
- to_flags
- from_turn_flags
- to_turn_flags
- street name
- street city
- polygon head
- first_polygon_point_idx
- polygon_point_count
- name
- cfcc
- north
- west
- east
- south
- polygon point
- line ref
- line speed average
- line speed id
- line speed id small
- range
- alert data
- square data
- metadata attribute
- venue head
- venue id
- line ext type
- line ext id
- line ext level by line
- line ext level
- line speed max
- polygon ex
- line attribute
- street id
- beacon pos
- beacon id
- beacon ex pos
- beacon ex id
- beacon ex mask
- lane type
- line new type
- ext protobuf data
- creating a new tile from own data
- python is stupidly slow at parsing json and looping through objects
- python is simple enough to use for parsing the binary files themselves (although i do plan to write a rust lib EVENTUALLY, once i finish understanding the format) but too slow for most operations
- typescript is sth im super familiar with already, but i dont wanna deal with
Uint8Arrays, trust me.
- only cause i didnt get to create a server-client approach yet, so the giant-ass json file that results from
parseGeoJSON.tstakes forever to process and is reprocessed PER tile. multiply that by 20x (because thats how many tiles are by default in a map_pkg request) and yeah
- i initially wanted to use ETS2LA's navigation sockets but for some reason theyre broken on my machine, so i just edited the nav sockets to instead use http posts to a hardcoded link lol
AA_test.tsuses Google's DHU to load android auto automatically with (almost) all sensors enabled, and set the location via the headunit itselfredirector_test.tsuses a custom app i made in 2 minutes which uses a TCP socket to send over location data, and mock the location directly on device
- use sth like httptoolkit to redirect
rt.waze.com,rt-xlb-row.waze.com,gapi.waze.comandctilesgcs-row.waze.comto your server - works on both root and non-root devices because you can easily add the cert settings thing to waze since it thankfully doesnt use pairip (god bless 🙏)
- you could also just replace
rt.waze.comand the other urls directly in the app sourcecode to your own server if thats what you'd like
- restart the app until it wants to work
- still unsure whether this is a problem with my server impl (
index.ts) or with HTTPToolkit - u could also try clearing storage a few times, its kinda rng honestly
- check status
| id | data |
|---|---|
| 1 | freeway |
| 2 | major highway |
| 3 | minor highway / boulevard |
| 4 | ramp |
| 5 | primary street |
| 6 | passage way(?) |
| 7 | street |
| 8 | non-routable pedestrian path |
| 9 | dirt path |
| 10 | routable pedestrian path |
| 11 | stairway |
| 12 | railway |
| 13 | runway / taxiway |
| 14 | ferry |
| 15 | private road |
| 16 | parking lot road |
note: editor ids dont match with internal waze ids for some goddamn reason, so dont try to get them from the web editor. use those
| cfcc | polygon category |
|---|---|
| 12 | land |
| 15 | building / venue |
| 16 | city / tile (the entire tile) |
| 20 | water |
note: there may be more polygon categories than this
| offset | string usage |
|---|---|
| 0 | street type |
| 1 | street base name |
| 2 | |
| 3 | street prefix name |
| 4 | street suffix name |
| 5 | city name |
| 6 | metadata |
| 7 | venue name |
| id | alert type |
|---|---|
| 2 | speed cam |
| 3 | dummy speed cam |
| 4 | red light cam |
| 5 |
note: these alert type things are taken from the old code, and may not be correct
a tile has a size of 10000x10000, which represents 0.01x0.01 (deg lat x deg lon). its (0,0) position is in the bottom left corner
tile_id is calculated via a simple formula from latitude, longitude, and scale. check the scripts to find out how (im too lazy to copy paste)
no idea why streets seem slimmer than they normally are on the map, but it might also be because they lack most data lol
routing seems painful to even THINK about starting. Check UserDriveV2.proto (StartNavigationInfo), and just try to understand it lmfao. i mean, its not hard to understand, but oh my god the amount of calculations that seem to be required... ill do it eventually™
- waze for existing in the first place
- truckermudgeon for his lovely map generation scripts
- mkoloberdin for keeping a clone of waze's old source code

