This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
This person has a SecurePRO™ card. Because this person is not a ProZ.com Plus subscriber, to view his or her SecurePRO™ card you must be a ProZ.com Business member or Plus subscriber.
University
Year of study
Area of interest
Study type
Student organization
Affiliations
This person is not affiliated with any business or Blue Board record at ProZ.com.
Expertise
Works in:
Aerospace / Aviation / Space
Portfolio
Sample translations submitted: 3
Portuguese to English: Aerodrome Capacity Calculation in Tactical Session General field: Tech/Engineering Detailed field: Aerospace / Aviation / Space
Source text - Portuguese Cálculo de capacidade para Aeródromos na sessão Tática
A capacidade do aeródromo exibidada na sessão tática é afetada pelos seguintes itens:
- Horário de funcionamento do aeródromo.
- Capacidade cadastrada no elemento regulado:
- Runway Capacity Configuration: considerada quando aeródromo possui estado
meteorológico baseado em mensagens do tipo METAR, SPECI e TAF.
- Time Capacity: considerada quando aeródromo não possui estado meterológico.
- Inoperâncias criadas em > Operability > Operability Management
- SUA/RAR criados em > Operability > SAC
Entendendo as funcionalidades:
- Cadastrar a capacidade no Elemento regulado:
Para um aeródromo X, considerando que tenha 2 pistas. Pista A e pista B. Essas pistas
possuem cabeceiras as [09/27, 14/32]. No painel Runway Capacity Configuration (Figura 1) do
cadastro do elemento regulado o usuário configura a capacidade para um determinado estado
meteorológico (VMC, MVMC e IMC) selecionando quais pistas estão disponíveis. É possível
cadastrar várias configurações, porém só uma pode ser selecionada como ativa.
Essa seleção da configuração ativa é feita na tela > Flow > Operational Panel, onde ao clicar
na capacidade do aeródromo abre-se um modal. Como mostra a imagem (Figura 2) abaixo:
Figura 1: Runway Capacity Configuration
Figura 2: Data from the Aerodrome Capacity Settings
A outra forma de cadastrar a capacidade no Elemento Regulado é no painel Time Capacity.
A figura abaixo (Figura 3) mostra como é a tela, basicamente o usuário configura uma capacidade
para cada hora ou a cada quarto de hora.
Abaixo um exemplo do horário de funcionamento cadastrado no elemento regulado:
Como podemos ver na figura 5, o gráfico de demanda da sessão tática tem a capacidade 0 a
partir das 20:00 por conta do fechamento do aeródromo.
Observe que na figura 5 a capacidade entre 00:00 e 15:00 é 45. Entre 15:00 e 20:00 a
capacidade é 90. Entre 20:00 e 23:59 a capacidade é 0. Isso ocorre porque existem inoperâncias ou
SUA/RAR cadastrados que impactam o aeródromo VABB. Por esse motivo o aeródromo VABB
fica destacado de amarelo no grid da esquerda no gráfico de demanda da tela de sessão. A figura 6
abaixo é referente a tela Capacity Projection, nesta funcionalidade é possível identificar os impactos
Figura 3: Time Capacity
Figura 4: Horário de funcionamento 00:000 até 20:00
Figura 5: Capacidade na Sessão Tática
em um elemento. Como podem ver, existia uma inoperância que afetava o elemento VABB de 00:00
até as 15:00 em 50% de sua capacidade, por isso a capacidade caiu de 90 para 45 nesse período.
Voltou ao normal após a inoperância terminar entre 15:00 e 20:00. Após 20:00 caiu para 0 porque o
aeródromo estava fechado.
Capacidade em função de dados meteorológicos:
VABB possui estado meteorológico MVMC por conta de um METAR. Baseado no cadastro
‘Runway Capacity Configuration’ do elemento regulado a capacidade para MVMC é 45, ver figura
8. Por isso a capacidade atual é 45. A previsão do TAF é de estado IMC entre 15:00 e 23:00
deixando a capacidade em 35.
Figura 6: Capacity Projection
Figura 7: Painel operacional
Figura 8: Previsão de capacidade
O gráfico abaixo mostra a capacidade em intervalos de 15 minutos:
Horário – capacidade:
14:00 – 12
14:15 – 11
14:30 – 11
14:45 – 11
Soma: 45
15:00 – 9
15:15 – 9
15:30 – 9
15:45 – 8
Soma: 35
16:00 – 9
16:15 – 9
16:30 – 9
16:45 – 8
Soma: 35
17:00 – 9
17:15 – 9
17:30 – 9
17:45 – 8
Soma: 35
Entre 14:00 e 15:00 a capacidade horária é 45 em função do METAR.
Entre 15:00 e 16:00 a capacidade horária é 35 em função da TAF.
Entre 16:00 e 17:00 a capacidade horária é 35 em função da TAF.
Entre 17:00 e 18:00 a capacidade horária é 35 em função da TAF.
Entre 18:00 e 19:00 a capacidade horária é 35 em função da TAF.
Entre 19:00 e 20:00 a capacidade horária é 35 em função da TAF.
Visualizar a capacidade em quartos de hora (Intervalos de 15 minutos) ajuda a verificar a
capacidade. Abaixo a capacidade em intervalos de 60 minutos:
Entre 14:00 e 15:00 capacidade 45.
Entre 15:00 e 20:00 capacidade 35.
Atenção: O gráfico de demanda faz contas a partir do quarto de hora atual, ou seja, no exemplo
acima a hora atual era entre 13:46 e 13:59. Por isso a capacidade é exibida a partir das 14:00.
Para o exemplo abaixo a hora atual é 14:25. Sendo assim o gráfico começa as 14:15.
Horário – capacidade:
14:15 – 11
14:30 – 11
14:45 – 11
15:00 – 9
Soma: 42
15:15 – 9
15:30 – 9
15:45 – 8
16:00 – 9
Soma: 35
16:15 – 9
16:30 – 9
16:45 – 8
17:00 – 9
Soma: 35
17:15 – 9
17:30 – 9
17:45 – 8
18:00 – 9
Soma: 35
Entre 14:15 e 15:15 a capacidade horária é 42 pois:
Capacidade faixa horário 14:00: capacidade 45 (12, 11, 11, 11)
Capacidade faixa horário 15:00: capacidade 35 (9, 9, 9, 8)
Entre 14:15 e 15:15 a conta é feita pegando cada quarto de hora e somando os valores:
14:00 – 12
14:15 – 11
14:30 – 11 Capacidade 42
14:45 – 11
15:00 – 9
15:15 – 9
15:30 – 9
15:45 – 8
Abaixo o gráfico mostra entre 14:15 e 15:15 a capacidade horária 42:
Translation - English Aerodrome Capacity Calculation in Tactical Session
The aerodrome capacity displayed on the tactical session is affected
by the following items:
- Aerodrome working hours.
- Capacity registered in the regulated element:
- Runway Capacity Configuration: it is considered when the
aerodrome has weather state based on METAR, SPECI and TAF messages.
- Time Capacity: it is considered when aerodrome does not have
weather.
Inoperability created in > Operability > Operability Management.
- SUA/RAR created in > Operability > SAC.
Functionalities:
- Register the capacity on Regulated Element:
For an aerodrome X, considering it has 2 runways. Runway A and runway B.
These tracks have the threshold [09/27, 14/32]. In the Runway Capacity Configuration panel (Figure 1) of regulated element register, the user sets the capacity for a particular weather state (VMC, MVMC or IMC) selecting which runways are available. It is possible to register many configurations, however, only one can be selected as active.
Figure 1: Runway Capacity Configuration
This active configuration selection is done on the screen > Flow >
Operational Panel, in which clicking on aerodrome capacity opens up a modal. As shown in the following image (Figure 2):
Figure 2: Data from the Aerodrome Capacity Settings
The other way to register the capacity in Regulated Element is in
the Time Capacity panel. The figure below (Figure 3) shows the screen. Basically, the user sets up a capacity to every hour or every quarter of an hour.
Figure 3: Time Capacity
Below follows an example of the working hours registered in the regulated element:
Figure 4: Working hours 00:00 to 8:00 p.m.
As we can see in Figure 5, the graphic of tactical session demand has the capacity 0 from 8:00 p.m. due to the airfield closure.
Figure 5: Tactical Session Capacity
Observe in Figure 5 the capacity between 00:00 and 3:00 p.m. is
45. Between 3:00 p.m. and 8: 00 p.m. the capacity is 90. Between 8:00 p.m. and 11:59 p.m. the capacity is 0. This occurs because there are inoperabilities or SUA/RAR registered impacting the aerodrome VABB. For this reason, the aerodrome VABB is highlighted in yellow in the left grid in the demand graphic of the session screen. The figure 6 below refers to the screen Capacity Projection, in this functionality is possible to identify the impacts in an element. As you can see, there was an inoperability affecting 50% of element VABB capacity from 00:00 to 3:00 p.m., therefore the capacity has dropped from 90 to 45 in this period.
It back to normal capacity after inoperability ended between 3:00 p.m.
and 8:00 p.m. After 8:00 p.m. it dropped down to 0 because the aerodrome was closed.
Figure 6: Capacity Projection
Capacity based on meteorological data:
VABB has weather state MVMC due to a METAR. Based on the register
'Runway Capacity Configuration' of the regulated element, the capacity
to MVMC is 45, see the Figure 8. Therefore, the current capacity is 45. The forecast of TAF is IMC state between 3:00 p.m. to 11:00 p.m., maintained the capacity in 35.
Figure 7: Operational Panel
Figure 8: Prediction Capacity
The graphic below shows the capacity at 15-minute intervals:
Time - Capacity:
2:00 p.m. - 12
2:00 p.m. - 11
2:30 p.m. - 11
2:45 p.m. – 11
Sum: 45
3:00 p.m. - 9
3:15 p.m. - 9
3:30 p.m. - 9
3:45 p.m. - 8 Sum: 35
4:00 p.m. - 9
4:15 p.m. - 9
4:30 p.m. - 9
4:45 p.m. - 8
Sum: 35
5:00 p.m. - 9
5:15 p.m. - 9
5:30 p.m. - 9
5:45 p.m. - 8
Sum: 35
Between 2:00 p.m. and 3:00 p.m. the time capacity is 45 in function of METAR.
Between 3:00 p.m. and 4:00 p.m. the time capacity is 35 in function of TAF.
Between 4:00 p.m. and 5:00 p.m. the time capacity is 35 in function of TAF.
Between 5:00 p.m. and 6:00 p.m. the time capacity is 35 in function of TAF.
Between 6:00 p.m. and 7:00 p.m. the time capacity is 35 in function of TAF.
Between 7:00 p.m. and 8:00 p.m. the time capacity is 35 in function of TAF.
Viewing the capacity in quarters (15-minute intervals) helps to check the
capacity. The graphic below shows the capacity at 60-minute intervals:
Between 2:00 p.m. and 3:00 p.m. capacity is 45.
Between 3:00 p.m. and 8:00 p.m. the capacity is 35.
Warning: The demand graphic does the math from the quarter of the current
hour, that is, in the above example the current hour was between 1:46 p.m. and 1:59 p.m. Therefore, the capacity is displayed from 2:00 p.m.
In the below example, the current time is 2:25 p.m. Thus, the graphic
starts at 2:15 p.m.
Time - Capacity:
2:15 p.m. - 11
2:30 p.m. - 11
2:45 p.m. - 11
3:00 p.m. - 9
Sum: 42
3:15 p.m. - 9
3:30 p.m. - 9
3:45 p.m. - 9
4:00 p.m. - 9
Sum: 35
4:15 p.m. - 9
4:30 p.m. - 9
4:45 p.m. - 8
5:00 p.m. - 9
Sum: 35
5:15 p.m. - 9
5:30 p.m. - 9
5:45 p.m. - 8
6:00 p.m. - 9
Sum: 35
Between 2:00 p.m. and 3:15 p.m. the time capacity is 42 because:
Time range capacity is 2:00 p.m.: capacity is 45 (12, 11, 11, 11)
Time range capacity is 3:00 p.m.: capacity is 35 (9, 9, 9, 8)
Between 2:15 p.m. and 3:15 p.m. the math is done summing every quarter of an hour.
2:00 p.m. - 12
2:15 p.m. - 11
2:30 p.m. - 11 Capacity is 42
2:45 p.m. - 11
3:00 p.m. - 9
3:15 p.m. - 9
3:30 p.m. - 9
3:45 p.m. – 8
Below, the graphic shows that between 2:15 p.m. and 3:15 p.m. the time
capacity is 42:
Portuguese to English: Timbrado General field: Tech/Engineering Detailed field: Aerospace / Aviation / Space
Source text - Portuguese
Web Statistics and Trends in Data W3Counter site to support the choice of resolutions.
1 1366x768, 1440x900 (TV LCD) 21%
6 320x568, 360x640 (Mobile) 13.70%
5 1280x800, 1280x1024 8.58%
2 1920x1080 (TV Full HD) 7.72%
3 768x1024 (Tablet) 6.36%
4 1024x768 5.60%
As estatísticas de utilização de resolução de tela encontradas a nível mundial focam em uma interface com 3 breakpoints (views de responsividade) sendo que a view mais alta seria para desktop fixa em 1280 que atenderia o padrão indiano de 1366.
A decisão de usabilidade foi baseada também na utilização do Drupal como bootstrap. O Drupal tem padrão 1280 que permite uma responsividade com maior controle do tipo de adequação que as boxes do WEB Portal serão submetidas quando a tela aumentar.
Ao se decidir usar algo fora do padrão, corre-se riscos ao aplicar o full (100%), uma vez que não há garantias de controle das informações e de alinhamentos. Perdendo muito no quesito usabilidade de grande quantidade de dados.
Avaliando as estatísticas de resoluções usadas e dos break points mais utilizados em 2017 podemos verificar que existe uma tendência de visualização para 1366. Essa tendência não afetaria a responsividade do WEB Portal, que por usar o padrão continuaria a manter o controle da sua responsividade.
Translation - English
Web Statistics and Trends in Data W3Counter site to support the choice of resolutions.
1 1366x768, 1440x900 (TV LCD) 21%
6 320x568, 360x640 (Mobile) 13.70%
5 1280x800, 1280x1024 8.58%
2 1920x1080 (TV Full HD) 7.72%
3 768x1024 (Tablet) 6.36%
4 1024x768 5.60%
The worldwide found statistics about screen resolution usage focus on an interface with 3 breakpoints (responsiveness views) whose higher view would be to desktop in 1280px and would meet the Indian standard of 1366px.
The usability decision was also based on using Drupal as a bootstrap. Drupal’s default is of 1280px allowing responsiveness with greater control over the type of fitness that the boxes of the WEB Portal will be submitted when the screen increases.
If you decide to use something non-standard, there is a risk when applying the full (100%), since there is no guarantee of information control and alignment. There is no more advantage in the usability of large amounts of data.
Evaluating the statistics of used resolutions and breakpoints more used in 2017, we can see that there is a display trend of 1366px. This trend would not affect the responsiveness of the WEB Portal, which using the pattern would continue to keep track of your responsiveness.
Portuguese to English: Comportamento de gestos e rolagem no mobile General field: Tech/Engineering Detailed field: Aerospace / Aviation / Space
Source text - Portuguese A web está ao nosso alcance em todos os lugares graças à navegação móvel, mas navegar na internet no celular ainda é ineficiente. Dois fatores principais causam isso: inconsistências no design do navegador e hábitos de navegação. Todas as plataformas e navegadores suportam os tipos básicos de gestos móveis, mesmo com nomes diferentes. O tipo de rolagem é utilizado em todas, porém sofre variações nas suas aplicações.
Alguns dispositivos móveis têm comportamentos padrão para touchmove, como o efeito overscroll do iOS clássico, que faz com que a exibição seja recuperada quando a rolagem excede os limites do conteúdo. A maioria dos navegadores implementa seus próprios estilos em resposta ao toque do usuário.
No caso específico do portal AAI, temos uma situação que lida com essas diferenças de aplicação de um combinado de gestos. Caso você passe pelo swipe direto ele não entende o toque dentro da tabela, mas ao clicar na tabela e realizar ao swipe nela ele só sai dela e passa a realizar o scroll na página completa quanto o conteúdo da tabela acabar. Porém isso varia do Android para o iOS e de acordo com o browser utilizado em cada plataforma. Em alguns casos o uso de dois dedos resolve o problema, mas não pode ser considerada uma solução universal.
Os gestos tornam a navegação produtiva e fornecem benefícios cognitivos significativos. Como mudar:
1. https://www.html5rocks.com/en/mobile/touch/
2. https://developer.android.com/training/gestures/scroll
3. Suprimir estilos padrão de navegadores
4. https://developers.google.com/web/updates/2017/11/overscroll-behavior
Podemos realizar a personalização de gestos para o site, mesmo que isso não seja indicado do ponto de vista de usabilidade e da intuitividade de cada sistema para seu usuário comum (previsto na 3a. heurística de Nielsen). Mas garantir a compatibilidade com todos os browsers é complexa. Caso optemos por implementar interações e gestos personalizados, devemos ter em mente dois tópicos:
1. Como oferecer suporte a todos os navegadores. (consistência da 4a. Heurística)
2. Como manter a taxa de quadros alta. (produtividade, seguida pela 7a. Heurística)
Warning: não se esqueça de que alguns usuários preferem usar o teclado e que usuários que usem tecnologias auxiliares em um dispositivo com tela sensível a toque podem não conseguir realizar certos gestos por eles serem interceptados/consumidos pela tecnologia assistiva.
Translation - English The web is within our reach everywhere, thanks to mobile browsing, but browsing on the internet on the mobile phone is still ineffective. Two main factors cause this: inconsistencies in browser design and browsing habits. All platforms and browsers support the basic types of mobile gestures, even with different names. The type of scrolling is used across all platforms, but it suffers variations in its applications.
Some mobile devices have standard behaviors for touch move, such as the over scroll effect of the classic iOS, which causes the display to be retrieved when the scrolling exceeds the limits of the content. Most browsers implement their own styles in response to a user's touch.
In the specific case of the AAI portal, we have a situation that deals with these differences of application of a combination of gestures. If you go through the swipe directly, it will not understand the touch inside the table, but when you click on the table and swipe it, it just exits the table and scrolls to the full page when the content of the table ends. However, this varies from Android to iOS and according to the browser used on each platform. In some cases, the use of two fingers solves the problem, but cannot be considered a universal solution.
Gestures make navigation productive and provide significant cognitive benefits. How to change?
1. https://www.html5rocks.com/en/mobile/touch/
2. https://developer.android.com/training/gestures/scroll
3. Suppress default browser styles
4. https://developers.google.com/web/updates/2017/11/overscroll-behavior
We can perform the custom gestures for the site, even if this is not indicated by the usability and the intuitiveness perspective of each system to its common user (predicted in the 3rd Nielsen heuristic). However, in order to assure compatibility with all browsers is complicated. In case we choose to implement customized gestures and interactions, we must bear in mind two topics:
1. How to offer support to all browsers? (consistency of the 4th. heuristic)
2. How to keep the high frame rate? (production, followed by the 7th. heuristic)
WARNING: do not forget about some users who prefer to use the keyboard and some users use auxiliary technologies in a device with a touchscreen may not be able to perform certain gestures because they will be intercepted/consumed by assistive technology.
More
Less
Experience
Years of experience: 6. Registered at ProZ.com: Aug 2017.
Portfolio