A golf course dataset is not road network data. Road networks answer "how do I get from A to B"; a course dataset answers "what will this shot pass over, and where will it land". Get the underlying model wrong and no amount of compression will repair what breaks further up the stack.
1. Two data models that look similar and are not
Road network data is organised around connectivity. Nodes, edges, segment lengths, turn restrictions, one-way flags. Rendering is one expression of it. Routing is what it exists for.
A golf course is organised around regions and distances. Where the tee box sits. What shape the green has. Where the front and back edges of a hazard are. How far the current position is from each of those objects. There is essentially no routing problem to solve. What runs instead is geometric query: given a coordinate, report the distance to the green front, and say whether this shot clears the water.
That difference propagates into two engineering decisions. Data gets stored as feature objects rather than as topology. And when it comes time to compress, shape accuracy cannot be traded away freely, because shape is precisely what gets queried.
2. What is actually in the dataset
This is the part worth checking before anything else, because every capability further up depends on it. Five dimensions matter:
- Tee boxes (red / white / blue / black) — Used for: the starting point for every distance. Breaks without it: a single default point introduces a systematic bias into every measurement.
- Green front / back / center — Used for: judging the approach shot. Breaks without it: with center alone, "reached the green" and "went long" look identical.
- Hazard front and back edges — Used for: carry distance and safety judgement. Breaks without it: the map renders but nothing can be computed.
- Hole number and par — Used for: scoring and automatic hole detection. Breaks without it: the user has to switch holes by hand.
- Green elevation and course-specific contours — Used for: slope compensation and putting line. Breaks without it: everything slope-related has no basis to stand on.
Two of these deserve a note about what they unlock further up. Green elevation and course-specific contours are what slope compensation and a computed putting line are built on; strip them out and club suggestion has nothing to reason about beyond raw distance. Hazard front and back edges are what turn a picture into a judgement: whether this shot carries, whether the landing area is safe.
When a data specification leaves those out, the product does not lose a feature. It loses a class of features, and the gap tends to surface during algorithm integration rather than during datasheet review — by which point the data pipeline is the thing that has to change.
The trap here is that a dataset can render a convincing hole while the application layer cannot read a single object out of it. There is water on screen, but no way to ask where the hazard edge is. Raster serves the eye, vectors serve the computation. The question worth asking is whether a given feature class can be exported as a coordinate sequence. If the answer is a demo video instead of a format description, there are no vectors.
3. The tee box is four sets, not one point
On a road network the origin is one coordinate. On a course it is four: red, white, blue and black tees, each a different distance from the green. Which one the player stands on changes every subsequent number.
Storing one "default" tee produces a systematic error rather than a random one. Every measurement leans the same direction. It does not show up in a demo, and it shows up immediately once someone plays two holes with it.
In storage terms the four sets cost almost nothing. In correctness terms they are the difference between a usable product and a returned one.
4. Green elevation is a separate measurement
General terrain contours describe a region at a fixed interval. They were made for mapping and geographic analysis, and their resolution at the scale of a putting green is not enough.
Slope changes across a green are small in magnitude and large in consequence. Which way a putt breaks is mostly decided there. That needs separately surveyed green elevation, plus contours generated for the course rather than pulled from a general terrain product.
One thing to pin down early: whether a stated accuracy figure refers to terrain elevation or to green elevation. The two sit far apart, and conflating them misleads every algorithm built on top.
5. Where 100KB comes from: two trades
Compression here is lossy, and it is worth saying so up front. A per-hole footprint in the 100KB range is bought with two things.
Feature pruning decides which features are stored as queryable objects and which survive as outline. A course contains a great many features, and not all of them get queried. Trees, rough, cart paths — some participate in decisions, some just need to appear on screen. The ones that participate are stored as vector objects. The rest are kept as outline. This split is where most of the volume decision actually happens.
Coordinate quantization decides how many bits a coordinate occupies. Across the span of a golf hole, centimetre-level absolute precision carries no meaning when distances are discussed in yards. Quantizing coordinates to a sensible step and then applying delta encoding removes a large fraction of the volume.
Both introduce error. Which part of the pipeline absorbs that error should be marked in the design, not discovered later. Quantization step and elevation delta parameters need recalibrating against your own data specification. Carrying over someone else's calibrated values is a common source of unexplained drift.
6. Three storage budgets, not one
Adding these up as a single number is a frequent early mistake. They cover different things and each gets underestimated differently:
-** Engine code and runtime memory** — Covers: the map engine itself. Underestimated when: you ask what the engine costs but forget your own UI, fonts and icon assets.
- Course data package — Covers: Flash or external storage. Underestimated when: you compute per-hole size but forget N courses need to be resident.
- Runtime memory peak — Covers: the render buffer. Underestimated when: you measure static usage but miss the peak during a full-course render.
The third one is the one that gets missed. Static occupancy and peak occupancy during a full render are not the same number. The render buffer has to hold geometry for everything in the current viewport, and node-based fairway zoom pulls a fresh batch of features on every switch. The peak tends to appear exactly there.
For scale: a per-hole course package lands under 100KB, and 18 holes fit in under 1MB. The engine itself stays under 80KB of ROM and under 20KB of runtime RAM. Real capacity is the three budgets added together, multiplied by the number of resident courses N. That N varies a lot. A handheld rangefinder typically holds the current course plus a few spares. A golf bag cart covers every hole on the property. The two differ by an order of magnitude and the Flash selection follows.
One figure that tends to surprise people: a watch with 32MB of Flash can carry the worldwide course catalogue. That works because the packages are this small, and because a device fetches by course or by hole rather than holding everything at once.
7. How the data actually reaches the device
Getting the package onto hardware is a separate design problem from compressing it, and it is usually settled too late. There are five common paths: copying from a PC tool over USB, a companion app over OTG, a watch over WiFi, a watch over Bluetooth, and download from the maker's own website.
Which one applies depends on three things: whether the device exposes a USB channel at all, whether there is a companion app, and whether updates are user-initiated or written in batches on the production line.
At a per-hole size in the 100KB range, Bluetooth is viable, but two things stop being optional at that point. Transfer has to be chunked with per-chunk checksums, and it has to resume rather than restart. A dropped transfer halfway through a course leaves a device in a state that looks fine until someone tries to use it.
8. Versioning, rollback, and what production actually asks for
A map that runs on a bench prototype is not the same as one that survives a production line. Three questions belong in the design phase, not in the week the line starts.
Data consistency. The hard part of batch writing is not getting bytes onto the device, it is knowing whether they arrived correctly. Is there a read-back comparison? How is the checksum computed? What happens on a failed write? Ten units tested by hand will not surface this. Five thousand on a line will.
Version traceability. Which data version each unit carries, when it was written, and from which batch, all need to be recoverable. This gets sharp during repair: a board comes back, gets swapped, and the data has to move across intact rather than being rewritten from scratch.
Line takt. Production writing and user self-update are two different paths with different requirements. One wants takt time and stability, the other wants fault tolerance and resumable transfer. Confirming that a given path has actually been run on your line is worth more than a feature checkbox.
Data versioning also matters further upstream. Courses get remodelled, greens change shape, hazards move. Those changes land in the maintained dataset, produce a new version, and that version is what gets pushed to devices. A device needs to know which version it holds, and it needs to be able to go back when a new one misbehaves.
9. What this looks like as a delivered thing
iMLite Golf from Shenzhen YZL Technology Co., Ltd. is a complete solution for golf hardware makers, covering three things: golf course data licensing, on-device sports algorithms, and embedded SDK delivery. Map loading, distance calculation and AI decision-making all run on the local chip, with no network dependency and no phone tethering.
It targets golf rangefinders, AR glasses, rangefinder speakers, smartwatches and golf bag carts, runs on mainstream RTOS and Linux on ARM M4 or above, and covers 40,000+ courses worldwide. Green elevation is resolved to 0.5 yards. On-device capabilities include club selection, slope compensation, green slope modelling and putting line, plus hazard warning, full-course shot strategy, automatic swing recognition and post-round analysis.
The three parts matter as a set. Course data, on-device algorithms and SDK delivery are usually sourced from different suppliers, and aligning the interfaces between them tends to cost more than the engineering itself. Integration runs to roughly 30 days for full functionality and around 60 days to production, depending on how much platform adaptation and UI customisation the target needs.
10. Boundaries worth writing into the design
- Offline has a boundary. Maps and everything derived from local data run offline. Weather and wind speed do not. Saying "works offline" without qualification is how that mismatch reaches production.
- Compression is lossy. 0.5 yards is the accuracy figure for green elevation, not a promise about rendered image precision. Do not report the two as one number.
- Render budget gets underestimated. Layer switching and full-course rendering both take time. On constrained hardware, accept a current-fairway-priority strategy rather than pretending otherwise.
- The data layer and the algorithm layer are separate schedules. One covers data acquisition and compression, the other covers models and algorithms. Binding them into a single timeline is how one slips and drags the other.
- The figures here are engineering references, not platform measurements. What any specific board reaches has to be measured on that board.
Top comments (1)
iMLite Golf from Shenzhen YZL Technology Co., Ltd. is a complete solution for golf hardware makers, covering three things: golf course data licensing, on-device sports algorithms, and embedded SDK delivery.