En realidad no es “nunca”. Hay muchas situaciones en que sí es posible determinar el origen del problema y que no está relacionado con errores en el mapa.
Algunos ejemplos:
-
Reportes indicando que no se puede virar o ingresar a una calle porque carabineros la cerró por alguna razón puntual, por ser un eje ambiental en días de (pre)emergencia o por algún otro motivo “temporal” (accidente, marcha no autorizada, etc.). Este es un error del usuario en que no supo hacer el reporte correcto, como poner un cierre.
-
Reportes reclamando que la app lo dejó al otro lado de una avenida en la dirección de destino. Por ahora no hay mucho que hacer al respecto. Se puede introducir basura extra al mapa para forzar a que se llegue por el otro lado cuando se trata de un lugar de acceso público y muy buscado, pero en general no es recomendable.
-
Reportes porque la app lo llevó a Bellavista 990 cuando iba al 0990. Es problema conocido y no tiene solución desde el punto de vista nuestro, es decir, no hay nada que nosotros podamos hacer si no se resuelve el problema de la numeración con ceros a la izquierda en el software de Waze.
-
Cuando hay un verdadero error detectado y resuelto, pero el ciclo de actualización del mapa en los servidores productivos se dilata, nuevos reportes por el mismo error seguirán apareciendo por algunos días y hay que cerrarlos en forma similar a cuando efectivamente fue resuelto (por uno mismo o por otro editor).
-
Reportes respecto a que la app lo saca de la autopista y lo vuelve a incorporar a ella unos kilómetros después. En un principio pensábamos que era problema del mapa e hicimos muchos cambios y experimentos para resolver eso, pero unos meses después nos enteramos que es una “característica” del servidor de rutas que penaliza los TAG y peajes con un par de minutos durante la búsqueda de la mejor ruta y por eso prefiere hacer que el conductor se ahorre ese dinero si el hecho de pasar por la caletera con semáforos y congestión no lo demora más que ese par de minutos. Lamentablemente este modo “ahorro” no se puede deshabilitar en la aplicación y como comunidad estamos intentando que se quite en Chile, pues en una sola autopista urbana con varios pórticos TAG puede suceder varias veces, retrasando al wazer varios minutos y que puede ser un porcentaje del tiempo no despreciable para un viaje.
-
Hace unas semanas hubo una actualización en el servidor de rutas que introdujo un problema grave: él es quien utiliza todos los TBR (reglas basadas en el horario) para el cálculo de rutas, e internamente hizo un corrimiento de días de la semana. ¿Consecuencia? Todas las reglas de vías reversibles, de virajes prohibidos y de cierres se adelantaron un día. Durante la semana no se notó de lunes a jueves (salvo en las ferias libres que se corrieron de día), pero el viernes no teníamos ninguna vía reversible operando (el día sábado es el con menos TBRs)… caos total. Yo dejé de contar los reportes que cerré cuando llevaba más de 100, y seguía encontrando reportes algunos días después en lugares no tan cercanos a ese tipo de vías (con TBR definidas). No sé cuántos reportes habrán cerrado otros editores.
A ninguno de estos casos yo lo calificaría como “No identificado”, y en todos ellos hay que dar una respuesta apropiada al usuario al momento de cerrar como “Resuelto” (según yo).
Sólo en casos donde no se sabe qué sucedió realmente y no se hizo nada al respecto porque no se obtuvo respuesta a la solicitud de información adicional en el tiempo acordado y prudente, lo cerraría efectivamente como “No identificado” junto a un mensaje indicando ese motivo de cierre.
Si bien este tema puntual no corresponde a este hilo, quería aprovechar la instancia que el STAFF mira aquí y tome conciencia de estas situaciones del día a día que nos afectan y las hagan llegar a los equipos internos que correspondan para justificar las peticiones que les hemos hecho como comunidad y que aún no son atendidas.