Posts: 47
Threads: 7
Joined: 09/2013
(2014-06-07, 14:51)Tobi Wrote: Here's what I've written in the internal forum:
(2014-05-17, 06:51)Tobi Wrote: For privacy reasons the station coordinates on the map are rounded. There's no reason to see the exact position on this map, so I the stations are now hidden on higher zoom level.
It's just a compromise. We can also add an option for participants to show the exact coordinates of their stations to the public...
It is not necessary for me, I'm just wondering....
Posts: 10
Threads: 1
Joined: 06/2014
Hi,
if i run the realtime map on my iPad 3 (iOS 7.1.1), after several minutes the safari is crashing (closing).
NosDE
Posts: 177
Threads: 9
Joined: 12/2013
(2014-06-09, 20:08)NosDE Wrote: Hi,
if i run the realtime map on my iPad 3 (iOS 7.1.1), after several minutes the safari is crashing (closing).
NosDE
It does the same on mine with iOs 6.1.2, FR24 also does the same, safari is not very stable on iOS and crashes if the data rate is too high.
Ben.
NB it works fine on the iMac.
RED Station: 878, Flightradar24: F-EGLF1, Open Glider Network: Aldersht2, PlanePlotter: M7.
Stations: 878
Posts: 2,178
Threads: 78
Joined: 06/2012
(2014-06-09, 20:08)NosDE Wrote: Hi,
if i run the realtime map on my iPad 3 (iOS 7.1.1), after several minutes the safari is crashing (closing).
NosDE
We already investigating this problem. It seems, it happens due to a bug in iOS 7 in combination with GoogleMaps. There seem to be other projects which have similar problems.
Posts: 10
Threads: 1
Joined: 06/2014
2014-06-10, 10:39
(This post was last modified: 2014-06-10, 11:12 by NosDE.)
Hi Tobi,
i think safari did consume too much memory due to the number of placemarks (strikes) that have to be rendered into the map.
This exist on iPhone 5s with iOS 7.1.1 and iPhone 4 with iOS 6.1.3 too.
A possible solution temporalily solution could be, to render only strikes on the map, that are in the bounds of current view.
A second approach could be, to limit the time, that a strike is placed on the map.
-NosDE
Posts: 164
Threads: 19
Joined: 06/2013
(2014-06-10, 10:14)Tobi Wrote: There seem to be other projects which have similar problems.
The problem i have runned over with my own maps is that browsers starts to crash/slow down when the amount of markers (strikes) reach x amount. This level varys a bit between the browsers but from my tests are it somewhere between 1000 and 2000 markers. The only way to get around this is to limit the amount of shown markers to say 1500.
// Henkka
Posts: 10
Threads: 1
Joined: 06/2014
That is what i want to say 
The strikes on the map should be limited. When the limit is reached (user selectable) the oldest strikes should be removed from map.
-NosDE
Posts: 2,178
Threads: 78
Joined: 06/2012
The markers are already limited to a few hundred.
Posts: 164
Threads: 19
Joined: 06/2013
(2014-06-10, 18:17)Tobi Wrote: The markers are already limited to a few hundred.
OK. Then its probably the animations and the recoloring of the markers what cause it. From what i have noted its fully possible such things needs to be forced shut off in (some of) the mobile browsers before things starts to work smoothly. I know, its a cool feature but i have runned over similar things with my own maps too, its a never-ending compromise between the coolness and core functionality.
// Henkka
Posts: 2,178
Threads: 78
Joined: 06/2012
All those animations and effects were already very limited on the mobile style. Since yesterday they are even more reduced. However, some animation is needed, otherwise you wouldn't see new strikes popping up and the real time map would be useless. So far we didn't experience much crashes any more on iDevices, but maybe that's also due to the lower strike rates now.
BTW: An own app would be great, but so far nobody want to write an official app for us. We could do it too, but there's no time for that. 
|
