sio2sio2 / lobaton Goto Github PK

Hay que sacarlo de filtros y añadirlo a ajustes.

Documentar la interfaz para que un usuario pueda utilizarla.

Al cambiar de especialidad, queda seleccionado el centro en la barra lateral. Debería desaparecer por completo, si en la nueva especialidad no existe ese centro, o cambiar los datos si el centro sí existe. Haciendo uso de lo sugerido en #29, bastaría al cargar con hacer:

g.cluster.seleccionado = centro

y que centro sea null si el centro no existe en los nuevos datos.

El centro selecccionado tiene relevancia, pues es aquel del que debe mostrarse información. o al que ha de llevarse la ruta que parta del origen. La idea es añadir a Centro un descriptor de acceso llamado "seleccionado" cuyo valor sea el centro que se ha seleccionado y que al tomar un valor lance los eventos asociados a "markerselect" y al tomar null los eventos asociados a "markerdeselect".

Esta misma idea puede tomarse para otras acciones como añadir/quitar un origen al mapa, añadir/quitar una ruta o añadir/quitar una isocrona.

Implementar una corrección sobre las adjudicaciones para eliminar aquellas que no respondan a una vacante inicial.

Los datos asociados a las marcas pueden verse alterados, porque un usuario desee desechar algunos que considere irrelevantes o añadir otros que le interesen. Esto supone dos cosas:

• Registrar cuáles son esas alteraciones para poder revertirlas si el usuario se arrepiente de ellas.
• Modificar el aspecto de los iconos si algunos de esos datos tenían representación visual en él.

Implementar una corrección para desechar las vacantes que no sean telefónicas.

Y, más adelante, ¿dónde que el botón derecho abre un menú contextual para crear rutas, isocronas, etc? Si se entiende la interfaz visual como una carcasa en que se define exclusivamente lo que requiere una mayor complejidad en la introducción de datos (filtros, ajustes de visualización) y que penosamente se podría hacer exclusivamente a través del mapa , lo lógico es que todo esto esté definido en map.js. En cambio, si se quiere dar más libertad al definirla debería dejarse para map.js el nivel más bajo de definición:

• Creación del tipo "markerselect".
• Generación de las isocronas.
• Definición de rutas.

Y para la interfaz, lo que se comenta al abrir el hilo que es un nivel más alto.

• Click selecciona el centro.
• Rutas e icocronas con click derecho.

Una posibilidad intermedia que es sencillísima de implementar, es añadir un parámetro booleano al crear el objeto MapAdjOfer y que lo segundo se defina en maps.js sólo si es verdadero.

Es preciso documentar el la API de leafext.js, y en general, de todo el proyecto. Sería interante tantear la posibilidad de usar sphinx-js.

SI teniendo un estilo de iconos, hay marcas filtradas; se cambia a otro estilo y. tras el cambio, se elimna el filtro, las marcas aparecen con el estilo antiguo.

Este bug se puede reproducir usando el ejemplo de demostración, cambiando al estilo boliche y elimando la corrección de bilingüismo:

x.Centro.uncorrect("bilingue");
x.Centro.invoke("refresh");

Los iconos seguirán viéndose en estilo chupachups.

Implementar una correción sobre las adjudicaciones para tener en cuenta los resultados del Concurso General de Traslados.

EL código actual, consulta cuáles son las correcciones definidas en el objeto CorrSys del prototipo de la marca. Sin embargo, las correcciones aplicadas se apuntan en la propia marca, en principio, para que distintas marcas puedan tener aplicadas distintas correcciones o iguales pero con distintas opciones de corrección. Esto, sin embargo, no es muy lógico y además, imposibilita poder definir un estado que establezca cuáles son las correcciones aplicadas a las maras de tipo "X" de un mapa.

Por tanto, es necesario que la aplicación se apunte en el objeto CorrSys común a todas las marcas. Se introduce la limitación, pero se puede soslayar creando distintas clases de marcas. La ventaja, si se implementa también la Issue #22, es evidente: si se añade una nueva marca después de la carga inicial, al enchufarle los datos, se le podrán aplicar automáticamente las correcciones y filtros que tienen las demás.

Implementar un filtro que elimine centros que no hayan aumentado su oferta educativa.

Implementar un filtro sobre las adjudicaciones que elimine aquellos centros sin adjudicaciones.

Utilizando la interfaz visual (ocurre también utilizando la consola) se puede comprobar que si aplicamos una corrección (por ejemplo de adjudicaciones), posteriormente aplicamos otra de la misma sección, y desmarcamos una de las dos, éstas no serán desaplicadas. Al eliminarlas todas vuelve al estado normal debido a que la interfaz detecta que no hay ninguna seleccionada y llama al método desaplicar.
El funcionamiento correcto sería que cada vez que se llame al método de aplicar correcciones, se desapliquen, si estaban, las correcciones que no están en el nuevo array de parámetros

Debe añadirse al objeto MapAdjOfer de map.js capacidad para usar los servicios de OpenRouteService en particular:

• Creación de isocronas.
• Cálculo de rutas.
• Capacidad de geolocalización.

Implementar una corrección sobre las adjudicaciones para eliminar aquellas que no sea de los puestos indicados.

Las vacantes telefónicas en la interfaz visual se tratan como si fueran una adjudicación del proedimiento de modo que se muestra una leyenda absurda:

(J) Interino: T.S. 0-0-0 (pet. ).

Debería indicarse, simplemente: vacante telefónica.

Las vacantes telefónicas se caracterizar por tener una "pet" (petición) igual a null

leafext.js precisa aún un sistema que permita ocultar (y volver a mostrar) iconos que cumplan ciertos requisitos especificados.

Crear la clase de iconos que usa una marca mutable es un poco engorroso, puesto que los iconos que usan CSS y un trozo de documento HTML se crean instantáneamente; pero los iconos que toman su definición de un fichero (p.e. un SVG guardado en fichero aparte) necesitan hacer una petición AJAX.

La intención es añadir un al icono una propiedad ready que informe de si la clase ya está lista para usarse y un método onready() que permita pasar una función que se ejecutará cuando el icono ya esté listo.

Apoyándose en las áreas que definen las isocronas (issue #42), puede definirse un filtro que filtre centros alejados más de N minutos del origen establecido.

Implementar una corrección sobre la oferta que deseche aquellas enseñanzas que el usuario decida.

En el desglose de la oferta, sería recomentable que los modificadores (turno, bilingüismo, carácter, etc.) fueran iconos fácilmente identificables.

Debería reservarse un apartado de la barra lateral para facilitar al usuario información sobre los datos y el estado del propio mapa.

En lo relativo a los datos, información sobre

• De qué curso son los datos del PCE.
• De qué curso son los datos de las plantillas orgánicas.
• De qué curso es la oferta de FP.
• De qué curso es la oferta general (ESO/Bachillerato).
• SI están disponibles los datos de vacantes telefónicas.
• Si están disponibles los datos del CGT.

En resumen, lo que ya ofrece la interfaz antigua, al pulsar sobre el icono de información.

En los relativo al estado del mapa, sería recomendable incluir:

• Si hay definido origen y cuál es. Aunque también debería barajarse la idea de crear un modo de escogerlo introduciendo la dirección y no sólo pinchando en el mapa. En este último caso, se podría aprovechar esto, para informar del origen seleccionado y no haría falta que se incluyera en el estado.
• Si hay generada una ruta y sus características (longitud, tiempo).
• SI hay generada una isocrona y una leyenda colores-tiempo.
• Número de consultas a OpenRouteServices.

La razón de incluir el estado del mapa es doble:

• Por un lado, se le da cuanta al usuario de que esos conceptos existen, así que alguno se preocupará de saber cómo se ponen en práctica..
• Por otro lado, cuando a´un no están generados se puede incluir una leyenda muy sucinta, de cuál es el siguiente paso que se debe realizar para llevar a cabo. Por ejemplo, si aún no hay definido un origen. El estado de isocronas y rutas podría ser:

Isocronas....... Fije origen primero
Rutas.... Fije origen primero.

Si ya lo hay definido, la leyenda en cambio podría ser:

Isocronas...... Click derecho sobre origen.
Rutas..... Click derecho sobre centro.

En lo referente al número de consultas, podría incluirse un icono "?" al lado que al pulsar abra un e informe del límite de 2.500 consultas diarias y por qué debe procurarse no realizar consultas gratuitas y mantener bajo este número cada vez que usemos el mapa.

Es preciso documentar la interfaz de la clase MapAdjOfer que usa la interfaz virtual.

Posiblemente baste con usar:

https://thednp.github.io/bootstrap.native/v4.html

Ahora mismo, es necesario usar explícitamente el método prepare() o aplicar una corrección con apply para que los arrays corregibles de los datos pasen a ser Correctables. En consecuencia, cualquier tarea que pretenda mostrar datos o la función de un objeto Converter (que también necesita leerlos) se ve obligada a comprobar antes de leer si el dato es un array normal o un Correctable.

Sería deseable que los arrays fueran Correctable desde el momento en que los datos se asocian a una marca.. Como la propiedad en la que se enchufan los datos es conocida desde el principio (ya que es el valor de la opción mutable), se podría hacer que tal propiedad fuera un descriptor de acceso y que su método set() consulte cuáles son las correcciones definidas y aplique directamente las correcciones a Correctable (p.e. usando el actual método `.prepare()qe podría pasar a ser._prepare()`` ya que no formará parte de la API pública.

Por ejemplo:

const Centro = L.Marker.extend({options: {mutable: "feature.properties.data"}});

En este caso, la propiedad feature de marca se podría transformar en un selector de acceso.

Implementar una corrección sobre la oferta que considere el carácter bilingüe de la enseñanza.

Implementar un filtro que elimine centros sin oferta educativa.

NO aparece al desglooar la oferta qué enseñanzas son bilingües.

La demora en unos pocos segundos de la generación de las isocronas (es necesaria una petición web y después un calculo costoso), aconseja dos cosas :

1. La interrupción periódica de la tarea para liberar la interfaz y que el navegador no dé la impresión de congelado.
2. La aparición de una barra de progreso.

Ambas tareas están relacionadas, ya que la interrupción da pie a que se envíe el grado de consecucióm y que la interfaz sea capaz de generar la barra de progreso.

Para la primera tarea, puede cogerse como modelo la estrategia que usa el plugin Leaflet.markercluster cuando procede a cargar las marcas.

Implementar un filtro sobre la oferta para eliminar aquellos centros que tengan menos de N enseñanzas.

La actual forma en que se define cómo se convierten los datos en las opciones de dibujo a través de una simple función y la opción fast es muy chapucera y exige demasiado al programador de la función converter.

Lo apropiado es definir un objeto conversor que sea capaz de gestionar la conversión entre uno y otro objeto y las correspondencias que existen entre las propiedades de los datos y las opciones de dibujo.

La actual implementación de Conrrectable añade directamente al array original métodos y propiedades, lo cual tiene dos inconvenientes:

• Es complicado eliminar todos esos métodos y propiedades para dejarlo como en un principio en caso de que se quiera revertir la conversión en Correctable.
• Obliga a recorrer el objeto (walk) y calcular su longitud de distinta manera, lo que puede traer problemas

La propuesta es construir el Correctable a través de Object.create.

Implementar una corrección sobre las adjudicaciones para eliminar todas aquellas obtenidas por adjudicatarios con mayor preferencia que el de referencia.

Implementar una corrección sobre la oferta para atender al turno (mañana o tarde) en que se imparten

Implementar un filtro atendiendo al tipo de centro: normal, compensatoria o difícil desempleño

El sistema de correcciones tiene la limitación de que cada corrección sólo puede aplicarse a una propiedad de los datos. Para soslayar esta limitación, se propone implementar lo siguiente. Al definir una corrección es posible definir una cadena de correcciones que se vayan aplicando sucesivamente. Por ejemplo:

Centro.register("a", {
   attr: "prop1",
   func: function(idx, adj, opts) { ... },
   chain: [
   {
      corr: "b",
      func: function(opts) { ...}
   },
   {
      corr: "c",
      func: function(opts) { ...}
   } ]
});

significa que se registra una corrección de nombre "a" que al acabar aplicará una corrección de nombre "b" seguida de una corrección de nombre "c". Ambas corrección deberán registrarse por separado, y no pueden ser de adición. La función que se provee con cada corrección de la cadena, se ejecuta antes de aplicar la corrección propiamente y sirve para transformar las opciones de corrección para "a" en opciones de correcciones para "b" (o "c", según el caso). Devuelve las opciones o null, si se decide que no procede aplicar la corrección.

Al aplicarse las correcciones en el sistema, el nombre de cada una incluirá el nombres de las que la desencadenaron separados por espacios. En el ejemplo, se registrarán las correcciones "a", "a b" y "a c".

Es necesario que durante la aplicación de las correcciones se pasen los nombres de las correcciones desencadenantes para evitar bucles.

El método debe ser análogo al de CorrSys: con el argumento a true elimina del sistema el registro de todos los filtros definidos; mientras que de lo contrario, se limita a marcar como desaplicados los filtros.

Hecho el método se puede añadir un parámetro al método reset de Marker para que, si es true, se desapliquen, además de las correcciones, los filtros.

Se adjunta un parche con una posible solución:

josem.js.patch.txt

También se podría hacer que al pinchar sobre el centro ya seleccionado, se deseleccionara:

g.cluster.selecionado = g.cluster.seleccionado === this?null:this;

En este caso habría que añadir la acción que se desencadenaría al deseleccionar:

g.cluster.on("markerdeselect", function(e) {
   // Eliminar la sección sobre información de centro de la barra lateral, por ejemplo.
});

Debería incluirse un tittle en las marcas con el nombre del centro para que al pasar sobre él con el ratón se le identifique fácilmente,

Implementar una corrección sobre las adjudicaciones para incluir las vacantes iniciales como adjudicación.

Se deben eliminar algunos datos redundantes: properties.name` `, que ya se encuentra en properties.data.id.nom`, y properties.data.mod.bil ya que el bilingüismo se determina revisando la oferta, no esa propiuedad.

Además, puede hacerse que properties.data pase a ser properties sin más.

Con la implementación actual, el valor de las opciones de dibujo de los iconos (icon.options.params) depende exclusivamente de los datos asociados a la marca. Quizás fuera fácil permitir que también se puedan alterar estas opciones pasando información directamente. El problema posiblemente sea que esa información no está almacenada en ningún sitio y ante un refresco de la marca (o que esta se quite y se ponga), se perderá la información visual asociada a esos datos inyectados.

Una alternativa es permitir que se puedan añadir/modificar datos directamente. Algo así como un método marca.changeData(obj) . La aplicación directa es clara: se podría señalar visualmente si un centro se ha seleccionado.

Cuando se usa la opción fast puesta a true para agilizar la ejecución de la función converter, se aplican correcciones y se usa un estilo de icono más simple que usa menos opciones de dibujo, al cambiar a un estilo que use opciones extra respecto al primero y cuyos valores se ven afectados por las correcciones, el aspecto del icono no refleja correctamente los valores de estas opciones extra.

Para reproducir el bug en la prueba canon.hhtml, basta con usar inicialmente el icono del "chupachups" (que no refleja la oferta), usar fast: true en la definición de todos los estilos de icono, y cambiar el estilo a "boliche", que sí refleja la oferta mediante colores. El icono representará la oferta como si no se hubiera aplicado la corrección "bilingüe",

Sería deseable que el desarrollo se realizara con webpack (o browserify) y babel para lograr la modularidad del código, mejorar la compatibilidad con navegadores y hacer más cómoda y sencilla la programación.

Implementar el cálculo de rutas entre el origen y un centro concreto.

Implementar la geocodificación dentro de la clase MapAdjOfer.

Al implementar #37, se introdujo un argumento adicional en el método correct() de las marcas que permitía aplicar a voluntad las correcciones encadenadas. Si no se incluye, no se sigue la cadena. Es conveniente, sin embargo, que se añada un atributo al registrar la corrección que defina si la cadena se sigue:

Centro.register("deseable", {
   attr: "oferta",
   auto: true,
   func: function(idx, oferta, opts) => false,
   chain: [{
       corr: "ofens",
       func = function(opts) { ... }
   }]
});

En este caso, la cadena se seguiría, aunque no se incluyera el argumento adicional a aplicar.

La lista de especialidades es muy larga, por lo que sería recomendable habilitar algún mecanismo para que el usuario fuera capaz de filtrar las alternativas. Uno del que debe comprobarse la validez en móviles es usar un <input> de texto asociado a un <datalist>, tal como se muestra aquí.