Well, obviously according to all opinions I’ve read so far - and that does very much include my own - TTNMapper is way apart from being obsolete. I don’t think there can be any doubt about that.
Do you think you could publish an overview of the current architecture of the project? There are the Github repositories, but they contain code only, but not much of an explanation of how they work together.
Probably - the heatmap tiles and the beams JSON aren’t being served - these came from servers at JP’s previous residence. So I guess he’s finished moving now.
Oh, what a pity that ttnmapper is no longer available. I was not using it much, but when I needed it it was a great service.
I had not realized so far that funding was an issue for ttnmapper. I would consider some financial contribution (personally, or maybe we can find some budget with Meet Je Stad), but I also suspect that the funding is only part of the story. Running a service like this takes a lot of energy and time, which I can imagine @jpmeijers wants to put an end to after this long. Given the service is shutdown, I conclude there is no ready community of contributors and co-admins to keep the service running, which I can imagine also means it was often a lonely responsibility over the past years. So even though I would be willing to contribute some funding if need be, I realize that it would not be proper to expect JP to continue running the service if enough funding shows up.
I’ll join the others in offering thanks and appreciation to @jpmeijers, for all this work and dedication over the past years!
It would be great if some people would get together and start such a community to collectively revive and run ttnmapper again. I will not have time for this, but as said, am willing to chip in a bit in the cost of hosting.
When they say there are no stupid questions, sometimes they can be rather uninformed so here’s enough for you to go and figure out who the players are and what the scale of the issue might be.
@md_dw1 has used the published open source code for TTN Mapper that’s on GitHub. He is not the original author, scroll to the top to find out who is.
He’s having a go at hosting a phoenix version but without any of the previous data. Using leaflet-heat map.js makes for a quick win but currently the 15,058 database entries are served unfiltered by map view, uncompressed and with no caching so either the tiny pop noise you hear will be their server exploding once there is sufficient data in it OR your web browser will melt your CPU as it tries to process the data - if it doesn’t die downloading a few hundred megabytes of JSON.
Okay. Thank you.
I asked about the new implementation using the new map and interface.
I know that TTN Mapper is open source
I have been using TTN Mapper for 4 years since I joined the TTN Madrid (Spain) community and for me it is an indispensable tool because I set out to try to complete the map as much as possible.
Thanks again, Nick.
I’m currently out of the country and have the mapper permanently installed in my car. Therefore, all of Bavaria and Baden-Württemberg, as well as the border regions of Switzerland and Austria, are constantly being mapped.
However, there are many entries from ground planes, including some from myself, that are no longer there or have been offline for a long time.
There are also many flight maps, for aircraft that don’t make any sense at all, or where the ground plane position is incorrectly recorded.
I have data sets where, according to TTNMapper, I received a ground plane signal in China while in Germany.
It has not been shut down yet. It will be clearly communicated if that will happen and when.
There was an outage caused by a combination of CloudFlare rules - detecting unexpected traffic hitting my APIs, and an update to a load balancer. The issues have been resolved now.
Cleaning up this kind of bad data is the biggest headache. The only reason TTN Mapper succeeded was because I manually cleaned this up during the first couple of years. But lately I really do not have the time to scroll through the map, or answer the hundreds of emails asking me to clean up the data.
A potential new iteration of the mapping service will have to take this into account. How do one get the community to clean up the data?
it might be very obvious but:
it would make sense to check every received datapoint automaticly. if its x height (*lowest safe altitude: >*1000 foot on developed area else >500ft ) above ground it must be a flying object and would be dropped automaticly. this would take cpu cycles but no human interaction. grep ground level via osm.
btw just curious…how many locations per second do you receive?
Hello and many thanks for developing and hosting the TTN Mapper. Your project has been very useful to the entire LoRaWAN community. It would be a shame to see it go offline. If you can let us know what the expenses are, I’m sure some members will be willing to share these expenses, including myself. We could help keep it online for much longer. This project is still very useful, especially in places where they’ve only just begun deploying LoRAWAN.
To all, please note the update to the initial post which reads:
The TTN Mapper service is not yet being shut down. Currently the community feedback is being collected to work out a future proof alternative. A timeline will be communicated here once any final decisions have been made.
Given the hints I’ve seen earlier, it isn’t simply hosted by the odd person. I’d say it requires at least a proper server if not two with a bunch of proper hard drives, at least to generate all tiles daily. So a random computer laying around won’t cut it.
