Show HN: TrikeScore – proof of concept for trike-specific route accessibility (OSM-based)
Walk Score and Bike Score exist; nothing scores whether an adult tricycle can get around a place, and trikes fail differently than bikes — can't hop curbs, grade-sensitive, and wind is a real routing constraint (a slope with the wind at your back vs. against it can flip from ridable to not). I hand-mapped my own trike routes in Ilhéus, Brazil into OpenStreetMap with the relevant tags (kerb type, incline, segregation) and rendered them via CyclOSM. No scoring algorithm yet — this is just proving the mapping method works. trikescore.com
The distinction that trikes fail differently than bikes is what caught my attention.
From the people who've looked at this so far, are they mainly validating that the mapping captures the constraints they actually experience, or are they already asking for the scoring layer before they're convinced the underlying map is complete?
Honest answer: not enough people have looked at it to have a pattern. You're one of about three responses total, so anything I said about "what people are asking" would be me inventing a trend out of noise.
What I can tell you is which order I think matters. The map has to be right before a score means anything — a score computed over incomplete tagging is just a confident-looking number. And the tagging is the expensive part. Sidewalks here aren't municipally continuous; each property owner builds their own, so it's a segment-by-segment survey rather than anything you can infer from road geometry. That's the real bottleneck, and it's why I haven't gone near the scoring layer yet.
That’s a fair answer, especially with only a few responses so far. The mapping bottleneck sounds like the more important constraint to understand first. I’d be interested to hear how the next few responses change your view.
The wind detail is what makes this interesting. Most accessibility scoring treats terrain as static, but wind direction changes through the day, so a route that is fine at 8am could be miserable at 2pm. Are you planning to eventually pull live wind data into the score, or is this meant to stay a one time proof of the mapping method for now. Hand tagging kerb type and incline in OSM for your own routes first, before trying to scale it, seems like the right order to build this in.
Wind is the constraint I underestimated, and it's directional, which is exactly what breaks static scoring.
Concrete example. The Jorge Amado bridge here in Ilhéus: prevailing wind is from the southeast. Heading north, uphill toward downtown, the wind's at my back — the climb is a slog above the halfway point but it's doable. Coming back south I'm going downhill and riding straight into it, and that's the direction I can't do without assist. Same segment, same day, opposite verdicts — and the harder direction is the downhill one. Slope alone would never predict that.
So yes, conditional edge weights rather than a static score is where this has to go. But not yet. Right now it's a proof that the mapping method works, and I'd rather have the tagging correct for one city than a live wind feed decorating incomplete data. Live wind is a real feature on a real map; on this one it'd be a demo.
And you're right about the order — I mapped my own daily routes first because those are the ones I can verify by having ridden them.