Comunidad
Buenas a todos.
Os traigo buenas noticias.
He ampliado un poco más el programa VisorNET y he añadido un comando para hacer el estudio de Análisis de Visibilidad.
Lo estoy haciendo con la normativa española pero si no trae mucho trabajo, podéis darme sugerencias u otras normativas para tratar de implementarlas ahora que estoy metido de lleno en este comando.
Voy a hacer una pequeña introducción de cómo lo hacen los otros programas y cómo lo he enfocado yo.
Civil 3D, para hacer el análisis de Visibilidad, no necesita del objeto corredor, necesita la superficie "Top" que genera dicha obra y a ser posible que tenga ya pegado el terreno natural. (Es decir, una nueva superficie que tenga pegadas ambas superficies).
En otros programas (Ispol, WinH,..) que yo sepa no se le puede cargar una superficie LandXML, de modo que trabajan con archivos de transversales, siendo del propio terreno natural y archivos transversales con la sección tipo acabada.
Eso quiere decir, que si hemos hecho nuestro proyecto en Civil 3D y queremos hacer el análisis de Visibilidad en otro programa, es prácticamente inviable porque sería como hacer un proyecto de nuevo con ese programa configurando las secciones tipo de la obra lineal...
Por tanto, como vemos, el resto de programas no piden superficies, ya que las tienen como ficheros de transversales o las generan durante el transcurso del propio comando de Análisis conociendo el terreno y generando su corredor.
En la primera ventana de diálogo de Civil 3D, respecto a Análisis de Visibilidad, tendríamos:
En Civil 3D, se selecciona el eje guía sobre el cual se aplicará el intervalo de comprobación.
Esto puede ser una alineación con su perfil, bien una LC o polilinea 3D.
Sobre este "eje guía", el punto del observador se puede colocar desfasado a este eje guía, mediante el valor "Desfase del ojo".
A su vez, también respecto este "eje guía", el punto del obstáculo se puede colocar desfasado, mediante el valor "Desfase del objetivo".
En este punto, lo que no me queda claro, es cómo Civil 3D sabe la elevación (cota absoluta) que tendrá el punto observador y cual será la del punto obstáculo (objetivo).
Esto lo digo, porque si el observador no tiene desfase, entonces la elevación del terreno se conoce porque se obtiene del perfil o de las elevaciones de la LC o polilinea 3D, pero si hay un offset, cómo sabe qué cota del terreno es?
En mi programa, por ejemplo, las cotas en los que se encuentran el punto observador y objetivo, se toman de la superficie (a las que luego sumo su altura de observador y objetivo respectivamente), pero en el caso de Civil 3D, se pueden asignar más de una superficie y no he leído nada al respecto de qué superficie tomaría las elevaciones si el observador y/o objetivo están desfasados del eje.
En mi opinión, este criterio que utiliza Civil 3D es pobre, porque sólo trabaja con desfases del "eje guía" seleccionado.
Por ejemplo, si tenemos una obra lineal que hay tramos que pasa de carril único a carril doble, el análisis de Civil 3D no serviría y se tendría que hacer por tramos.
En mi caso, mi comando (a falta de añadir más cosas), tendría la siguiente apariencia:
En primer lugar, mi programa permite definir 2 ejes:
-Eje principal (Tronco de la vía) al cual se referirán los PK y el incremento de intervalo del observador se harán sobre este eje.
(también, aunque ahora no está puesto, habrá un combobox para seleccionar uno de los perfiles de este eje para calcular la distancia de parada, puesto que se requiere conocer la pendiente longitudinal en cada PK concreto del intervalo). Esto por ahora lo tengo en un comando aparte que fusionaré con este formulario.
-Eje guía observador:
Puede suceder, en muchos casos, que el eje del observador, (el cual generalmente está a 1.50m de su linea blanca izquierda), no sea el propio eje que nos pide Civil 3D con su perfil.
Por tanto, seleccionaremos una entidad "alignment", que será por dónde transcurrirá el observador ("ojo").
El PK obtenido en el eje Tronco, se proyecta sobre este eje, de modo que en el listado, se ofrecen los 2 PK (referido al tronco y a este eje).
En mi caso, no he puesto un "Desfase del ojo" puesto que ya para eso, haces directamente una alineación desfasada respecto ésta.
Y aquí viene lo importante, a diferencia de Civil 3D:
Para el caso del objetivo (obstáculo), mi programa permite seleccionar otra entidad (que puede ser un eje, polilinea o LC) o bien indicar un offset del obstáculo respecto el "eje guía del observador", tal como hace Civil 3D.
La ventaja de indicar un "eje guía del obstáculo" es que no tiene porque ser un desfase constante respecto al eje. (en el caso del proyecto dónde hay tramos de un único carril a doble carril, es ideal, ya que la línea de pintura exterior no sería siempre con un offset constante al eje).
Otra cosa que no indica Civil 3D, es la tolerancia en la que la visual llega ya a interseccionar con la superficie.
En mi caso, se puede indicar dicha tolerancia. El programa es capaz de hacer 3 subiteraciones.
Por defecto, empieza con un intervalo de 20 metros. Cuando detecta la zona de intersección, itera con un intervalo de 2 metros y finalmente, lo vuelve a hacer con un intervalo de 0.10m, resultando por tanto una tolerancia de 0.10 metros.
Obviamente, cuanto menor sea la tolerancia, más tiempo de cálculo necesita.
Por último, este comando genera una lista, con las coordenadas de los puntos observador y obstáculo, así como la distancia de visibilidad y la distancia de parada, para cada PK del intervalo, y se puede mostrar una línea 3D dinámicamente desde una paleta (que actúa de modo transparente):
Antes de empezar, pide seleccionar una linea que hayamos dibujado previamente en el dibujo, y la seleccionamos con el botón [Selecciona línea..] y posteriormente, a media que cambiamos de PK, el punto inicio y final de la línea se colocan a sus nuevas coordenadas según la posición del observador y obstáculo en el PK seleccionado.
Si se hace un ORBIT, también se puede ver la visual porque es una línea 3D.
En esta paleta, tengo que añadir más cosas, como por ejemplo que si la distancia de visibilidad es inferior a la distancia de parada, se muestre el label en rojo.
También pondré un botón de [play], con un intervalo de tiempo, para que recorra todos los PK de manera automática.
Aquí hay otra excepción que creo que no controlan los programas cuando hacen análisis de Visibilidad:
Como vemos en la imagen, la linea blanca (visual), llega hasta su objetivo , en el cual pierde ya su rastro (aunque es probable que pueda recuperarlo pero los programas ya no analizan esta situación).
Sin embargo, como vemos, la superficie usada, puede que tenga zonas sin cubrir y al tirar la visual, la visual pase por alguna zona dónde no hay superficie TIN, como en este caso.
Si se trata de una montaña, como puede ser este caso y se conociera la superficie de esa zona, es PROBABLE, que la visual interseccionara antes con el terreno, por tanto, la distancia de visibilidad sería menor.
En este caso, por tanto, no creo que haya programas que informen de esta situación.
Mi idea, por tanto, es poner un textbox de "intervalo sobre visual", para comprobar cada X metros, si el punto sobre la visual está dentro de la superficie TIN (esto con la API se puede hacer fácilmente), y en caso que pase como el caso expuesto, en el informe, justo al lado de la distancia de visibilidad, informe con un comentario de que "es probable que la distancia sea menor".
Ahora con más opciones:
Se ha añadido la posibilidad de poder escoger el perfil de superficie del eje guía del observador, de modo que para el cálculo de la distancia de parada, que requiere de la pendiente instantánea longitudinal, antes se hacía siempre con la rasante del eje principal. Ahora si se quiere se puede seleccionar un perfil (generalmente será el perfil de superficie con la superficie que usamos), para obtener su pendiente.
Más mejoras:
Ahora ya funciona la alineación desfasada para seleccionarla con el botón [Sel.eje Obs. Offset].
Lo que haría el usuario, es crear una alineación desfasada respecto el eje guía observador, a pongamos 1mm de offset.
A esta alineación desfasada, puede darle el estilo de alineación que quiera representarla.
Luego, el programa, cada vez que se cambia el PK del observador (ya sea pulsándolo o con el PLAY), el programa modifica el PK inicio y final de esa alienación desfasada, que son precisamente el PK del observador sobre el eje guía observador y el PK objeto sobre el eje guía observador.
De este modo, incluso, si se tiene seleccionada dicha alineación desfasada en el dibujo, se va viendo dinámicamente ese eje con su longitud, que correspondería a la distancia de visibilidad medida sobre el eje guía observador.
La verdad que es muy llamativo.
Tengo pendiente, llevar un grado más allá el programa, así que voy a "duplicar" el código, es decir, que el programa permita seleccionar a la vez 2 ejes guía del obstáculo, que generalmente será el borde de pintura interior del carril y el borde de pintura exterior de carril.
En el listado de excel, se mostrará exactamente los mismos datos pero para el lado interior y para el lado exterior de carril.
A su vez, en la paleta, se mostrarán 2 lineas de visión, en la que el observador, desde su posición, observa el objetivo situado en el interior y la que observa el objetivo situado en el exterior.
Y también, en la paleta, se mostrarán la distancia de visibilidad de cada objetivo y se pondrán en rojo si son inferiores a la distancia de parada.
Este programa de AutoTurn 3D a lo que se refiere al Análisis de Visibilidad, es un timo:
https://www.youtube.com/watch?v=1Z5_CiF4e0I
En realidad, creo que opera de la misma forma que Civil 3D.
Me extrañaba mucho cómo eran capaces de hacer los cálculos tan rápido cuando he caído en la cuenta que esos programas no hacen iteraciones y utilizan un valor fijo de distancia de visibilidad.
Por ejemplo, si observáis el vídeo de youtube, veréis que el usuario puede cambiar 2 parámetros:
-Stopping sight distance.
-Interval.
El stopping sight distance, NUNCA DEBE SER un valor fijo, se calcula en función de la pendiente de la rasante y la velocidad de proyecto en la que se encuentra el punto observador.
Pero además, si se muestra la línea de visión, esa distancia sería la distancia de visibilidad medida sobre el eje del observador, la cual tampoco es un valor fijo.
Hay que hacer iteraciones para encontrar el punto del obstáculo en el cual el observador, desde su mismo PK, deja de ver el obstáculo y eso sólo se consigue con cálculos de iteración.
Hacer lo que hacen esos programas, es una absoluta chorrada puesto que lo que hacen es, pongamos como ejemplo:
P.K observador: 0+300
Stopping sight distance (valor fijo)= 200.
Entonces, el P.K del obstáculo, se encuentra en el P.K 0+500, y a partir de una función , que incluso tiene la API de Civil 3D y de hecho usa de manera secundaria mi programa, es obtener las coordenadas X,Y del obstáculo en ese P.K sobre el eje (offset=0).
De este modo, uniendo el punto observador con ese punto obstáculo, se tiene la línea de visión.
Luego dibuja, desde cada P.K del observador, su correspondiente línea de visión haciendo el cálculo anterior.
Es por eso que esos programas calculan tan rápido, porque en realidad no calculan nada importante que requiera de reiteraciones... 
Ya va saliendo el gráfico: 
Es altamente configurable desde el formulario. Luego se puede exportar con el botón [Exportar a JPG].
Falta por dibujar las barras apiladas para la recuperación y pérdida de visibilidad.
En realidad, cuando se ejecutaba el comando "vispar", devuelve una hoja de excel con los datos. Mediante programación, se podía haber dibujado directamente el chart (como objeto chart de excel) en ese mismo reporte pero he preferido no hacerlo.
Ya tengo el comando acabado en cuanto a obtener gráficas:
Este apartado, de "Análisis de Visibilidad", estará formado por 3 comandos, que abrirán su respectivo formulario, y deberán ejecutarse con el mismo orden que se expone aquí:
1) En primer lugar, tenemos el comando "vispar", para configurar los parámetros del análisis de Visibilidad:
Lo más destacado en este formulario, antes de pulsar el botón [Generar], es si se quiere obtener un listado *.csv (de Excel) de los resultados, en ese caso se activa el checkbox de "Generar listado de resultados", el cual está activado por defecto.
Luego tenemos el checkbox de "Generar Análisis Pérdida/Recuperación Visibilidad", para luego mostrar un gráfico de columnas.
Por tanto, es obligado activar este último checkbox si luego se quiere mostrar la Recuperación y pérdida de visibilidad en el próximo gráfico.
Digamos que una vez ejecutado este formulario, AutoCAD guarda 2 List<T>, la primera lista contiene las distancias de parada y distancias de visibilidad de cada P.K del observador.
La segunda lista (si se activó el checkbox), guarda las distancias de pérdida y recuperación de visibilidad desde cada PK.
2) Una vez se ha generado los cálculos, se puede abrir una paleta, con el comando "paletaanalisisvisibilidad":
Al funcionar como una paleta cualquiera de AutoCAD (funciona de manera transparente al uso de otros comandos), se ha decidido que el usuario dibuje primero las entidades (polilinea 3D, alineación desfasada) y luego la seleccione . Aunque todo esto es opcional.
En esta paleta, sólo faltaría por programar, cuando se hace un "orbit", que la posición de la cámara coincida con la posición y dirección del observador en ese P.K actual.
Por último, lo nuevo que se ha añadido es el botón [Gráficos], por tanto, para ir al formulario de gráficos, debe pulsarse este botón , aunque quizá haga un comando nuevo para ir a su acceso directo sin tener que abrir esta paleta.
2) una vez pulsado el botón [Gráficos], abre el siguiente formulario:
Se muestran los 3 tipos que se pueden configurar de manera independiente, e incluso visualizarlos de manera independiente.
La parte superior del formulario, es un panel superior que se puede contraer (pulsando el botón rojo de la parte superior derecha [V]). Si se contrae el panel superior, se muestra sólo el gráfico en toda la extensión del formulario.
El formulario se puede maximizar y redimensionar manualmente por pinzamiento.
Se puede configurar cualquier elemento, desde el tipo letra, color,contenido y visibilidad de cualquier título.
El color,grosor y visibilidad de cada serie. Incluso las etiquetas de punto.
Se puede configurar el intervalo para el eje X e Y, se puede configurar el Rango mínimo y máximo para cada eje o dejarlo en automático, etc..
-Se puede configurar las etiquetas (color,fuente, rotación) de cada eje (la visibilidad de las etiquetas del lado derecho del eje Y,...), así como sus marcas.
También se puede configurar el intervalo de rejilla para cada eje.
-Todo lo relativo a la Leyenda, etc...
Aquí sería una muestra teniendo desactivado las series de columnas (recuperación y pérdida de visibilidad):
La imagen se puede exportar a imagen *.JPG, o incluso a XML para ser abierto en Excel como un Map, aunque esto tengo que investigarlo.
Las únicas cosas que podrían añadirse de más en cuanto a gráficos, pero no creo que sea necesario, es indicar si se quiere barras deslizantes del eje horizontal y vertical (cuando fueran necesarias).
Si se quiere hacer un zoom a una área del gráfico, o mostrar la información del punto (x,y) al poner el cursor encima.
Saludos.
...
Saludos, una vez mas excelente información y aporte que haces con respeto a tus programas con el fin de mejorar el procesamiento o trabajo dentro de CIVIL 3D...
Muchas felicidades y que tengas un buen día...
Atte.
Saludos, una vez mas excelente información y aporte que haces con respeto a tus programas con el fin de mejorar el procesamiento o trabajo dentro de CIVIL 3D...
Muchas felicidades y que tengas un buen día...
Atte.
> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
PD:
Si la info es de tu interés, dale manitos arriba (KUDO)...
Si la info da solución a tu inquietud, o es conocimiento nuevo para poderlo aplicar en el futuro, acéptalo como SOLUCIÓN...
TU ACEPTACIÓN O APOYO EN CUALQUIERA DE LAS 2 FORMAS, ES EL INCENTIVO PARA PODER SEGUIR APORTANDO CON LO MUCHO O POCO QUE SEPAMOS DE ESTE GRAN SOFTWARE PARA EL BIEN DE TODA LA COMUNIDAD...
Felices festividades de Carnaval y feriado...
ALEJANDRO PANCHANA (Guayaquil-Ecuador)
Facebook | Twitter | Screencast
He hecho algunas mejoras al programa, que cito a continuación.
Si el "eje guía observador" era sólo de segmentos de recta, al proyectar el punto (PK desde el eje principal), podía provocar error porque el método "Alignment.StationOffset()" de la API de Civil 3D a veces produce excepción si puede haber 2 resultados.
Pongamos que un punto se puede proyectar a 2 lados (2 segmentos consecutivos de rectas), con lo que finalizaba el programa.
He visto que la API, tiene ese método sobrecargado y permite indicar una Tolerancia, por tanto, en el programa se ha añadido un parámetro llamado "Tolerancia PIs", aunque no entiendo realmente lo que hace.
Por otro lado, he mejorado el programa en un apartado que hacía tiempo quería mejorar:
Resulta que si la superficie S1 es estrecha o no es muy amplia, puede suceder que una visual (entre el punto observador y objeto), pase parcialmente por fuera del contorno de la superficie.
Una opción, hubiera sido que el usuario tuviera que extraer el contorno de la superficie en polilinea y asignarla al programa, pero lo que he hecho, es que por cada visual que debe calcular, el programa genera temporalmente una alineación (tramo recto de la visual) y su perfil de superficie (respecto la superficie S1).
Luego se compara la longitud del eje y su perfil. Si la longitud del perfil es menor, podemos asegurar que la visual ha pasado por fuera del exterior de la superficie.
Cuando eso sucede, se le indica al usuario en la hoja de Excel, en una columna aparte (llamada "Dist- Visual Ext), la distancia entre el observador y el objeto medida sobre el eje guía observador.
Si la visual no pasa por fuera, el valor es "--" .
Esta opción es opcional, porque si se activa, los cálculos necesitan muchísimo más tiempo (estamos hablando que crea una alineación y perfil para cada visual y los vuelve a destruir).
También hay otra opción disponible, siempre que se active la primera, que permite considerar que si la visual pasa por fuera del contorno de la superficie, inmediatamente se consideraría como si intersectara con la superficie, de modo que el cálculo retrocedería hacia atrás de PK y volvería a calcular por subiteraciones, tal como lo hace cuando realmente intersecta con la superficie.
De todos modos, aunque el programa trate de interpretar esto, es obvio que una superficie debería cubrir siempre cualquier visual que deba darse, para no hacer suposiciones, porque al fin y al cabo son eso.
¿No encontraste lo que buscabas? Pregúntale a la comunidad o comparte tus conocimientos.
Publicar en los foros
