Yes, it’s clear from the feedback so far that the realtime spot speed limit updates, that come from users of the app, aren’t suitable for the OSM database, regardless of how correctly (or historically incorrectly - sorry!) I might format it. 
Before I completely revert to using our own database for this (working on it now!), please do let me know if such data has any value to the OSM community whatsoever? And if so, how/where best to make it available?
To clarify @trial , the fine-tuning I speak of is only in relation to attempting to ensure that, using OSM data, the app is as successful as it can be in advising the driver/user of the app the correct speed limit for the section of road that they’re currently on. Nothing more, nothing less.
I feel that this is a worthy goal to attempt to fine-tune.
If not for reporting on and using constructively, what else is the speed limit data in OSM for?
“Welcome to OpenStreetMap, the project that creates and distributes free geographic data for the world. We started it because most maps you think of as free actually have legal or technical restrictions on their use, holding back people from using them in creative, productive, or unexpected ways.”
@hfs Your question is certainly something that I’ve given thought to, but don’t have a solid answer right now, more’s the pity!
I want to place a strong emphasis on safety/simplicity so that drivers (if/when it’s safe and legal to do so) can 1-click the screen, hence making best/largest use of the screen for the various elements
If I/we can come up with a UI that clearly and safely accommodates the difference between a permanent and a temporary speed limit, then I’ll certainly consider encouraging reatime user feedback on temporary limits.
This comment reminded me that this entire project is wholly redundant to StreetComplete and SCEE, which has already done its homework on dealing with speed limits (mostly) and has a really solid flow.
That would be a good one to suggest for Osmand.
Thanks for implementing a new App and sharing related information here 
So as i understand you want have a replacement of Google Maps, Waze, and Apple Maps:
Before testing and installing the App I usually check the implemented tracker, because I don’t like to have so much unwanted data transfer in background.
Here the result: 3 Trackers
https://reports.exodus-privacy.eu.org/de/reports/697070
Google AdMob
advertisement
Google CrashLytics
crash reporting
Google Firebase Analytics
analytics
and even from Google which doesn’t match well with the open OSM philosophy.
As far as I can see you like KI tools, so I asked for alternatives (source perplexity prompt “name FOSS alternatives to the following trackers: Google AdMob advertisement, Google Crashlytics crash reporting, Google Firebase Analytics analyticss”). Result see below.
Do you think you can do something to get rid of the google tracker?
The previous answer discussed FOSS‑friendly, privacy‑respecting alternatives for three categories (ads, crash reporting, analytics) and how to replace the listed Google trackers in an app environment.*
It explained that there are several well‑established free and open‑source alternatives that avoid Google and can often be self‑hosted.
## Advertising (AdMob alternatives)
For FOSS‑friendly apps, traditional ad networks are often problematic because they track users; therefore, data‑sparing/contextual solutions or donation‑based models are usually more appropriate.
Possible approaches:
** Voluntary funding: In‑app purchases/donations (e.g., via Liberapay, Open Collective, your own paywall) instead of an ad network; this can be implemented without any tracking libraries.*
** Direct sales / own ads: Display your own simple banners whose content comes from your own server; only server‑side log files are used and no third‑party SDKs are required.*
** Contextual open‑source ad servers: Self‑hosted ad servers such as Revive Adserver (PHP/MySQL, GPL) that can be used in a purely contextual way and therefore work without user profiles.*
Truly “FOSS AdMob SDKs” with significant market share are rare; many projects that show up as trackers in the Exodus context are proprietary ad networks.
## Crash reporting (Crashlytics alternatives)
There are several established crash‑reporting tools that are open source or can be operated in a privacy‑friendly way.
Common options:
** Sentry (server and SDKs under open‑source license, hosted or self‑hosted): Comprehensive error tracking, release tracking, and can be configured in a GDPR‑friendly way (own server, IP masking, PII filtering).*
** ACRA (Android crash‑reporting library, Apache license): A library that collects crashes and sends them via HTTP/SMTP to any endpoint you choose (own server, email, etc.).*
** Crash reporting without Firebase Crashlytics: A custom global Thread.setDefaultUncaughtExceptionHandler that logs stack traces locally or sends them to your own backend endpoint; this can be implemented entirely without third‑party SDKs.*
## Analytics (Firebase Analytics alternatives)
For privacy‑friendly, preferably FOSS analytics, self‑hosted or privacy‑focused solutions are the most suitable.
Typical alternatives:
** Matomo (formerly Piwik): A full‑featured, self‑hostable web analytics system (GPL) that can also track app usage via simple HTTP events; IP anonymization and opt‑out are available.*
** Aptabase: Open‑source analytics specifically for mobile/desktop apps, inspired by Plausible; it focuses on privacy by design and aggregates events in an anonymized way.*
** Custom minimal event API: A very simple REST API on your own server that receives a small number of pseudonymous events from the app; analysis is done using SQL/BI tools instead of a commercial tracker.*
## Recommendation for a FOSS‑/privacy‑friendly app
** Advertising: If possible, avoid advertising or, at most, use self‑hosted contextual ads without third‑party SDKs.*
** Crash reporting: Use Sentry (self‑hosted) or ACRA plus your own endpoint.*
** Analytics: Use Matomo or Aptabase with minimal, anonymized events and clear documentation in your privacy policy.*
*This setup allows an app to run largely tracker‑free while still providing error diagnostics and basic usage statistics.
Btw, the main feature (showing speed limit) seems similar which was done for a similar App, crosslink:
Hi Ross,
Thank you for contributing to the great world of OSM using apps. You might pick up a few negative comments on here but everyone is coming from a position of supporting OSM and wanting a well behaved app from you. Well behaved means it generates accurate, clean, minimal data and it it handles previous speed limit contributions in a thoughtful, gentle way. Don’t be deterred - keep pushing onwards with your speed limit app!
What may help OSM people reading here to immediately jump to saying “Hey that’s Great!” is a clear statement of what tags you want your app to add, amend or delete.
Yes, a speed limit attribute will require segmenting the way every time the limit changes so you could tell us how you plan to do that. Single way roads will have two speed limits, one for upstream and one for downstream traffic so that is a lot of segmentation. Some discussion of how you want to do segments will draw in all the techies to chew over your proposals.
And more…you are in a great position to capture and record as an attribute the average or median speed on a segment. That data won’t sell your speed limit app but would be really useful for routing applications.
Thanks everyone for your feedback so far, especially (obviously!) the more constructive, encouraging ones! 
I’ve nearly finished fully transitioning the app to use our own Firebase storage for the spot speedlimit updates from users of the app, so very shortly it’ll be read-only in relation to the OSM db.
In parallel with the above, and thanks very much indeed @westnordost and @emvee and others, I’m incorporating this into the app too:
GitHub - westnordost/osm-legal-default-speeds: Infer default legal speed limits from OpenStreetMap tags - fantastic!
There are other suggestions for improvement in this discussion which I’ll respond to shortly… right now I just want to get the above completeed, tested, and and LIVE in the Google Play store.
THANK YOU!
Hello,
We (The DWG) have recently been seeing a big influx of unusable (dare I say spam) notes in Krakow, all mentioning ‘SpeedLimitApp’, which seems to lead to your app. If it is your app that is responsible for creating these notes, please fix or disable this feature.
The vast majority of them have been hidden as spam, but here are few that are still visible.
@Itomic This is still ongoing, though I see that the name is now different. Could you respond here whether these notes are produced by your app, or whether they come from elsewhere?
I hesitate to revive an old thread, but I would like to point out that the google play store listing for this app still explicitly states that you can connect your OSM account to the app in order to contribute “data”, and has a screenshot of the OSM authorization page (which would not be required if there were an intermediary database, to the best of my understanding), despite being updated in March.
This, on top of not responding to the two most recent queries regarding an influx of garbage data, (GIGO, as your LLM said) seems to be a clear demonstration of bad faith.
I would urge you, @Itomic, to heed the advice already given to you. You keep rebutting that OSM is the best source of data for a project such as this, without considering the health of the OSM project. The functionality that you want would be better as a CoMaps feature that allowed you to quickly make geo-tagged notes about incorrect speed limits that you could manually review and submit when not driving. This would, of course, prevent you from charging a subscription fee and profiting off of a crowd-sourced non-profit project.
And for the sake of the human condition, please do not use an LLM for human-to-human communication. The internet is sanitized enough as it is.
Hi @Rambling_Banjo , and thanks for pointing this out.
Sincere apologies to the community… I’ve been hugely distracted by other other projects recently, and have missed recent comms in this thread.
Definitely no intentional bad faith on my part.
The Google Play store listing for the app incorrectly shows the ability to connect to OSM. This functionality in the app was removed some months ago. I have just this second deleted that screenshot from the store listing, and now it just requires a ‘Google Review’ for them to consent to the screenshot being removed. I guess that will happen within 12-24 hours.
Regarding the big influx of unusable notes… I’m looking into that now and will report back asap.
“And for the sake of the human condition, please do not use an LLM for human-to-human communication. The internet is sanitized enough as it is.”
I can’t stress the following enough: I only used AI once in this thread. That was the opening description/summary of the app. It was a convenient way of quickly creating that description based on the work on the app that had been done to-date.
All my comments after that initial description are all me, warts and all.
Thanks for flagging this, and sincere apologies again for not responding sooner.
I’ve reviewed both the current codebase and the app’s git history. The current Speed/Limit app no longer writes to OpenStreetMap at all (since 17th Jan 2026); contributions now go to our own Firestore backend. Earlier app versions that did interact with OSM used authenticated changesets under the user’s OSM account, not anonymous OSM notes.
I also checked the note format in your screenshots and it does not match any code or string in our repository history.
In particular, the reported notes were created anonymously on 12-13 March 2026 and use identifiers like ovp_… / cache_…, whereas our historical app used OSM way IDs and changesets.
**So based on the evidence I have, these notes are not being produced by our app.
**
If I can be of further assistance, please ask. Thank you.
