Opino como Skorpiano. Lo único que creo es que desmarcar la casilla no va a ser de mucha ayuda, ya que si hay un usuario de waze para que pase y levante el corte, lo habrá para marcar el corte primero. Y en el supuesto caso que se haga desde la PC el usuario de waze no pasara por ahí ya sea porque vera el corte o porque lo ruteará por otro lado.

También es importante tener en cuenta que los cortes muchas veces son móviles.

marba73 wrote:La idea sería no adelantarse al corte , solo ante corte confirmado, porque sino seríamos funcionales al mismo.


Enviado desde mi iPhone utilizando Tapatalk

Marba73, se sabe donde serán los cortes y los horarios?

Entonces se pueden poner los cortes que sabemos los horarios precisos con opcion a que se levanten cuando alquien circule por ahi y el resto dejar que los vayan poniendo en vivo los usuarios. Seria una alternativa intermedia.

Planteemos 3 escenarios:

1) hay L4 (uno o mas) que puedan estar a lo largo del dia monitoreando y cargando cortes

Podriamos cargar los corte programados con opción a levantarse en caso de que alguien circule por ahi y ademas el o los L4 lo van ajustando a la realidad, sumado a los cortes desde la app en vivo desde la calle.

2) no hay nadie que pueda hacerlo

Podríamos cargar los corte programados con opción a levantarse en caso de que alguien circule por ahi y sumamos los cortes desde la app en vivo desde la calle.

3) Lo hay en algún momento y en otro no

Podríamos cargar los corte programados con opción a levantarse en caso de que alguien circule por ahi y ademas el o los L4 lo van ajustando a la realidad en el momento que los haya, sumado a los cortes desde la app en vivo desde la calle.


Por lo que me parece que cargar los cortes es algo que no depende de que haya L4 o no para monitorear.

que piensan?

andrex77 wrote:El corte "con opción que se levante", o sea, sin tildar el checkbox "IGNORAR TRAFICO", no creo que sea una buena opción para el uso que le quieren dar.
Esto es porque si se utiliza, las rutas generadas van a evitar ese camino si es que no hay un flujo constante de wazers pasando por ahi.
Y es probable que eso no ocurra si desde un principio ponen el corte y las rutas no se generan para llevar wazers a ese camino.
En mi humilde opinión, y como se dijo en otro post, es hacerle el juego a los piquetes.

y que sugeririas? que se carguen los cierres desde la app en vivo solamente?

andrex77 wrote:

krema10 wrote: y que sugeririas? que se carguen los cierres desde la app en vivo solamente?

Como se dijo antes, esperar confirmación de wazers o TV para desde el editor marcarlos.
Eso implica >L4 o con permiso RTC estén atentos a los cortes.

Entonces el primer wazer que pase por algún corte se va a comer el garrón sacrificandose por el resto...

En caso de que el cierre sea por un evento que sabemos donde y a que hora va a ser, lo cerramos antes. Porque en este caso, sabiendo a que hora y donde es el corte no lo hacemos?

La idea sería no adelantarse al corte , solo ante corte confirmado, porque sino seríamos funcionales al mismo.


Enviado desde mi iPhone utilizando Tapatalk

krema10 wrote:

marba73 wrote:La idea sería no adelantarse al corte , solo ante corte confirmado, porque sino seríamos funcionales al mismo.


Enviado desde mi iPhone utilizando Tapatalk

Marba73, se sabe donde serán los cortes y los horarios?

Los cortes están en Clarin.com pero no me parece bien anticiparse a los cortes , sino ponerlos en el momento que sucedan , para no ser funcionales al mismo , y para tener más exactitud .