Te agradezco los halagos, pero es que no hay otra manera de mejorar las cosas, que remangarse un poco y colaborar en lo que se puede. Hay gente con capacidad para programar, otros son buenos detectando fallos porque usan los programas al límite de sus posibilidades, y en general cualquier usuario aporta información valiosa que sirve a los desarrolladores para saber qué demanda la gente. Un software sin usuarios tiene un escaso recorrido y nunca llegará a nada, y es la comunidad la que ayuda a que los programas triunfen y mejoren día a día, y todos somos partícipes de ello. Anoche envié un mensaje a la lista de desarrolladores y usuarios de QLGT mencionando temas varios relacionados con los mapas. En lo que a más inmediato y que nos afecta a los españoles se refiere, ya han cargado en el servidor las nuevas versiones corregidas (gracias chichomtb y mitxelin) para la cartografía base, cartografía rasterizada y fotos PNOA para toda España. A partir de ya, cuando uno obtenga dichos mapas mediante "Load Online Map", deberían estar perfectamente calibrados, al menos las zonas de Madrid y Asturias lo están, probar en las islas y en Galicia nunca está de más, porque están en zonas distintas y podría haber algún problemilla. También he comentado el tema de que los mapas de Google disponibles mediante "Load Online Map" no funcionan tal cuales, y en efecto me confirman que para dichos mapas (de tipo TMS) lo correcto es definirlos según comento unos mensajes más atrás, que las entradas para Google en la lista de mapas remotos es algo que quedó pendiente de corregir. Así que, a continuar usando el programa, detectando fallos, y viendo carencias, que sólo así iremos poco a poco un programa cada vez más interesante.
Pequeñas novedades un par de meses después de la última entrada en este hilo. No ha habido mucha actividad en lo que a nuevas versiones o características se refiere en QLGT, durante el verano, también los desarrolladores se toman su tiempo más allá de la pantalla de un ordenador. Pero se acaba de publicar la versión 1.5.2 de QLGT que trae una novedad y cambios (mejoras) en otra característica que ya existía, pero que al menos yo no he sabido de ella hasta esta versión. Como novedad está que se ha añadido soporte para autenticación cuando se usa un proxy HTTP para conectar a Internet. Al común de los mortales esto le resultará innecesario, pues nuestros PC no suelen salir a Internet a través de proxy, pero para gente que ejecute QLGT desde el trabajo o haciendo uso de conexiones tipo WiFi hotspot podría necesitarlo. La IP/nombre del servidor proxy y el puerto siguen configurándose en el menú "Preferencias -> General -> Servicios & Rutas", pero el usuario y contraseña para el proxy se pedirán la primera vez que se necesiten, y se guardarán en memoria durante todo el tiempo que dure la ejecución de QLGT (es decir, habrá que volver a autenticarse cuando volvamos a lanzar la aplicación). La otra característica, que no novedad, es el soporte mejorado para la georreferenciación de fotografías desde QLGT y la creación automática de waypoints a partir de fotografías ya georreferenciadas, o a partir de fotografías (con fecha y hora) más un track. Las capacidades son las siguientes: + Creación de waypoints a partir de fotografías georreferenciadas (datos GPS incluidos en la información EXIF de la foto). El waypoint incluye las coordenadas, la altitud, la foto (como parte del waypoint (es decir, parte del archivo cuando se exporta) o enlazando al archivo original y la orientación de la misma (hacia dónde miraba el fotógrafo, aunque esto no es de fiar). Y el nombre de cada waypoint así creado coincide con el del archivo que contiene la foto. + Se pueden georreferenciar las imágenes que no tengan datos GPS combinándolas con un track, según la hora de la foto y la de los puntos del track. Para ello QLGT tiene un asistente para calcular la diferencia horaria entre la cámara y la hora del GPS, y que así el etiquetado geográfico sea más acorde a la realidad + Como el anterior, pero aquí se calcula la diferencia entre la hora de la cámara y la del GPS teniendo una foto del GPS y su posición cuando se hizo cierta foto, y no como en el caso anterior, donde lo que se tiene es una foto de la hora del GPS y la hora de la cámara En cualquiera de los dos últimos casos, la idea es que el programa aplique una corrección a la hora de la cámara igual a todas las fotos que haga que la georreferenciación se corresponda más a la realidad. Por lo tanto, no usar los dos últimos métodos seleccionados para etiquetar fotos hechas en días o con cámaras distintas. Para poder acceder a esta funcionalidad QLGT debe estar compilado con las librerías EXIF, en caso contrario bajo el menú "Waypoint" no aparecerá la opción adicional "A partir de imágenes...", que despliega un diálogo como el siguiente: Si las fotos ya están georreferenciadas, como es mi caso, mantener la opción "De la cabecera EXIF", si lo que se desea es georreferenciar fotos sin dicha información y crear waypoints como resultado, seguir alguno de los otros dos mecanismos. Si lo que uno quiere es georreferenciar fotos, no necesariamente para crear waypoints desde QLGT, hay múltiples programas para ello, yo desde Linux usé en su momento "gpscorrelate-gui", que más simple no puede ser, pero hay multitud de otros programas para Linux, Mac OS X y Windows. A disfrutar del campo y de la bici, aquellos que podéis PD: al probar la funcionalidad de creación de waypoints desde imágenes georreferenciadas he detectado un bug que nos afecta a quienes tomamos fotos en España, y es que cualquier coordenada al oeste del meridiano cero se convierte en coordenada al este del mismo y de igual magnitud (apareciendo los waypoints en medio del Mediterráneo). Bug reportado y para el que ya hay parche, así que nadie se alarme por tal error. PD 2: las imágenes asociadas a un waypoint se mantienen cuando el punto se guarda en la base de datos interna de QLGT o cuando se exporta al formato propio de QLGT, pero por ejemplo, no se mantiene cuando se exporta a GPX. Cuidado con eso, no sea que perdáis todo el trabajo de un rato por exportar a un formato que no mantiene las imágenes.
Decir que Oliver Eichler ha corregido el "bug" que había en la generación de waypoints a partir de fotos georreferenciadas, y como era una característica, existente pero muy mejorada en la versión 1.5.2, ha decido en consecuencia publicar la versión 1.5.3 con dicho arreglo, para que nadie tenga una mala experiencia con esa nueva prestación. Próximamente en todos sus repositorios y orígenes de paquetería habituales.
Un breve apunte para los usuarios de MacOS X en procesadores Intel, ya está disponible la versión 1.5.3 de QLGT (y en breve también para CPU PowerPC), que además, viene acompañada de una nueva recopilación de "Mac OS X Helpers and Libraries", que el autor recomienda encarecidamente actualizar al mismo tiempo que QLGT, y que incluye: - GDAL versión 1.9.2 (manejo de cartografía y datos raster) - PROJ4 versión 4.8.0 (manejo de proyecciones de mapas) - EXIF versión 0.6.21 (para el manejo de imágenes georreferenciadas) - libexpat versión 2.1.0 - libjpeg versión 8d
Hola a todos, antes de nada me presento, me llamo Lucio y, lamentablemente, no soy aficionado a la bicicleta de montaña, pero sí a la montaña, y además soy usuario del programa protagonista de este hilo, QlandkarteGT, y ese es el motivo por el que me he registrado, ya que después de varias actualizaciones del programa me encuentro con un gran problema al que no encuentro solución. La versión que utilizo es la última, la 1.5.3, pero el problema ya lo tenía con versiones anteriores. En primer lugar indicar que el programa lo utilizo en dos portátiles, uno con WINDOWS 7 y otro con WINDOWX VISTA, y en los dos tengo el mismo problema: el programa no se comunica con el GPS, un Garmin eTrex Legend HCX, con lo cual no puedo subir ni descargar tracks del GPS. Cuando voy a configurar el dispositivo me aparece un desplegable con varias opciones, entre ellas elijo GARMIN, pero cuando voy a la lista de dispositivos para seleccionar mi eTrex Legend dicha lista ni siquiera se despliega, con lo cual no le puedo indicar al programa con qué GPS se tiene que comunicar. Tengo instalados los drivers de Garmin, pero no se si QlandkarteGt necesita algún otro driver especial para que se produzca la comunicación entre el programa y el GPS, o si esos drivers tengo que copiarlos en alguna carpeta específica del programa, desde luego en la página web del programa no se dice nada al respecto. En el desplegable que he indicado anteriormente también aparece la opción de comunicarse como dispositivo de almacenamiento externo, en este caso no tengo ningún problema, el programa reconoce la tarjeta microSD del GPS y puedo meter tracks en dicha tarjeta, pero claro, esos tracks el GPS no los puede leer cuando voy por el monte, así que como si nada. He buscado información en este hilo y en otros, pero no encuentro absolutamente nada sobre este problema. He utilizado el Qlandkarte en el ordendor de mesa, en el que tengo instalado Ubuntu, y no he tenido este problema, lo que pasa es que ese ordenador ha muerto y me veo obligado a tirar de portátil y de WINDOWS. También utilizo el Basecamp, pero la verdad es que me resulta más cómodo el Qlandkarte y me gustaría sacarle más provecho. En fin, que si alguien sabe por donde puede ir la solución se lo agradecería. Un saludo.
Aupa werlisa He hecho varias pruebas, incluso reinstalando versiones mas antiguas para win(1.3.01 / 1.2.4 / 1.1.0 / 0.18.2), y el unico resultado ha sido corrobar lo que dices en todas ellas.... En linux no tengo pegas para elegir el modelo de gps y en win si... hace tiempo aparbadexu tambien daba cuenta de este problema en el mensaje #56 de este hilo: .. y de momento nadie ha dado respuesta, he mirado un poco en la lista de correo de QLGT pero aun no he encontrado nada, buceare un poco mas, y si no tal vez habria que plantear la duda alli.
Gracias por la respuesta Mitxelin. Para no liarte con los foros si quieres olvídate del hilo de MENDIAK y si tienes que comentar algo nuevo yo estaré atento siguiendo este hilo en foromtb. Si damos con la solución al problema ya lo comentaré en MENDIAK por si le sirve a alguien. Lo dicho, muchas gracias por tu interés y un saludo.
Corrijo el mensaje porque mi aseveración anterior parecía no corresponderse plenamente con la realidad. Según parece, el autor del software ya no mantiene los drivers para que QLGT se comunique con los dispositivos GPS Garmin usando el protocolo del mismo nombre, para sistema operativo Windows: http://comments.gmane.org/gmane.comp.gis.qlandkartegt.user/604 Ahora bien, los drivers existen, parecen plenamente funcionales (después de revisar el código fuente), y habría que buscar bien alguien que los tenga compilados y empaquetados para Windows, bien alguien que sepa y se anime a hacerlo (probablemente será un paquete con varias DLL , que guardar en algún lado y registrar en Windows, con su InstalShield instalador y todo ). El código fuente está en el siguiente enlace: http://sourceforge.net/projects/qlandkartegt/files/garmindev/ http://downloads.sourceforge.net/pr...in Device Driver 0.3.4/garmindev-0.3.4.tar.gz En unas cuantas búsquedas de Google no he sido capaz de localizar ningún paquete ya compilado para Windows de los drivers. Tampoco tengo los recursos (instalación de Windows nativa, compilador para Windows) ni el conocimiento para hacerlo yo mismo, pero el código es sencillo y tiene muy poquitas dependencias (apenas un puñado de archivos en "garmindev" son específicos de la plataforma, el resto son comunes). Cualquier programador que haya hecho pinitos con Windows debería poder generar unas DLL en cuestión de un par de horas a lo sumo. No he investigado el código tan en detalle como para ver el nivel de funcionalidad, o si podría no funcionar con según qué versiones de Windows, pero un vistazo rápido dice que enviar y recibir datos puede (y sólo la parte de interfaz serie/USB es específica de sistema operativo, el resto es protocolo Garmin, que depende del GPS y no del sistema operativo), así que lo básico (waypoints, rutas, tracks) debería funcionar. El mensaje del citado comentario #56 de apabardexu aparece cuando el programa trata de localizar las DLL correspondientes, y no encuentra nada bajo el directorio predeterminado: CODE, HTML o PHP Insertado: CDlgConfig.cpp: labelMessage->setText(tr("No plugins found. I expect them in: %1").arg(XSTR(PLUGINDIR))); De todas maneras, mientras alguien no compile las DLL, no nos podemos preocupar mucho de dónde meterlas A ver si algún programador Windows se anima y echa una mano a la tropa...
Como tampoco tenía nada mejor que hacer anoche estuve jugueteando con una máquina virtual de Windows que tengo por aquí, y me instalé el CYGWIN para obtener todo el conjunto de compiladores y otro software típico de Linux para desarrollo, pero adaptado a Windows. Tras un par de intentos y un par de chapuzas conseguí que compilaran al menos un par de DLL para sendos modelos de GPS de Garmin, y metí todos los archivos resultantes bajo la capeta "plugins" (que creé a mano) dentro del directorio de instalación de QLGT 1.5.3 en Windows, que en mi caso es algo así como "C:\Archivos de Programa\QLandkarteGT\". A partir de ese momento ya podía elegir en la configuración de QLGT la opción de GPS Garmin, pero lamentablemente la lista me aparecía vacía: no sé si tendré que intentar compilar todos los drivers para todos los modelos (algunos fallan al compilar con errores "raros"), o me faltará algún paso (registrar las DLL en Windows con "regsrv32"), pero intentaré de nuevo otro rato en cuanto pueda, para ver si consigo dar con ello. Si me llegan a contar que voy a estar tocando Windows a estas alturas de mi vida, no me lo creo Seguiremos informando, pero si algún desarrollador Windows caritativo está por ahí, seguro que lo saca en dos patadas.
En otro orden de cosas, el forero Godos me ha escrito para darme cuenta de un comportamiento del programa que yo hasta la fecha no había probado, pero que resulta ciertamente "inquietante", o por lo menos, sorprendente a primera vista. El hecho es que se puede crear una "polilínea de distancia", y atribuirle una velocidad (dándole a "Editar..." sobre la misma). Sin embargo, al convertir esa polilínea en track, la información de velocidad no se mantiene. Y más raro aún, si ese track se guarda como GPX y se carga de nuevo en el programa, aparece en el track recién cargado desde disco una velocidad para el mismo que parece completamente arbitraria. He estado mirando el asunto, y todo tiene una explicación. Ciertamente, la velocidad configurada en la polilínea no se mantiene al exportar a track: he mirado el código, y sólo se exportan las coordenadas, pero no se convierte (o se inicializa) la fecha y hora de los puntos del track, por lo tanto, malamente van a tener: CODE, HTML o PHP Insertado: COverlayDistance.cpp:1141 for(int i = 0; i < points.count(); ++i) { pt2 = points[i]; pt.lon = pt2.u * RAD_TO_DEG; pt.lat = pt2.v * RAD_TO_DEG; pt._lon = pt.lon; pt._lat = pt.lat; *track << pt; } En cuanto a guardar posteriormente el track generado como GPX, lo que se ve al analizar el archivo GPX correspondiente, es que el primer punto del track se establece con una fecha y hora igual al inicio del "UNIX epoch" (medianoche del 1 de Enero de 1970), y a cada punto subsiguiente, se le añade un segundo en relación al anterior. Sin pararme a investigar, supongo que en un archivo GPX todos los puntos necesitan por definición una marca temporal, y el autor de QLGT ha decidido que, a falta de otra mejor, la indicada es suficiente. CODE, HTML o PHP Insertado: <trkseg> <trkpt lon="-4.11149120" lat="40.67990875"> <ele>1044</ele> <time>1970-01-01T00:00:01.000Z</time> </trkpt> <trkpt lon="-4.11189890" lat="40.68023300"> <ele>1052.42</ele> <time>1970-01-01T00:00:02.000Z</time> </trkpt> <trkpt lon="-4.11230659" lat="40.68056107"> <ele>1061.23</ele> <time>1970-01-01T00:00:03.000Z</time> </trkpt> Cuando el GPX así generado se carga de nuevo en esta u otra aplicación, según la distancia relativa entre puntos consecutivos la velocidad que marque la ventana con el detalle de puntos del track puede ser alta (puntos muy cerca entre sí) o enorme (puntos separados más de unos pocos metros entre sí): diez metros, 36 Km/h, 100 metros, 360 Km/h. En el capítulo de las soluciones, de momento ninguna que yo sepa. La solución correcta yo la veo de la siguiente manera: 1. No tiene mucha lógica que se pueda atribuir velocidad a una polilínea y esa información no se pase al track en que se convierta. Y en ese caso, en tiempo de conversión habría que preguntar al usuario qué hora inicial se quiere establecer para el track (una velocidad sin un punto de comienzo no tiene sentido) 2. En caso de guardar un track sin información temporal, o con una información temporal que no sea "lógica" (por ejemplo, si se ha convertido desde polilínea y el comienzo es del 1970), se debería preguntar al usuario si se quiere establecer una fecha y hora distinta de inicio para el track, y si el track aún no tiene marcas de tiempo para los puntos, dar la elección de establecer una velocidad o dejar al programa hacer lo que hace ahora 3. Se debería ampliar el conjunto de filtros que aplicar a los track para añadir uno que permita inicializar un track sin información de tiempo a una fecha/hora determinada, y una velocidad media (para tracks creados desde trozos de otros o desde polilíneas) 4. Ya para nota, que estos y otros filtros ya existentes se puedan aplicar a rangos de puntos de un track, y no sólo a tracks enteros (como mínimo aplicar a etapas de un track y no al track completo). Daría bastante juego a la hora de crear tracks desde cero con estimaciones de tiempo de paso, por ejemplo, para planificarse rutas largas o de varios días. El caso es que existen los filtros para "anonimizar" tracks con información de tiempo válida (estableciendo el inicio a uno dado y cambiando las fechas/horas de los puntos a valores aleatorios), que básicamente son lo mismo que lo mencionado más arriba, pero con una parametrización distinta. Sin embargo, a mi dichos filtros me salen desactivados (1.5.3), y no sé siquiera si estarán codificados, o no (lo estaban en versiones antiguas de QLGT). Ahora bien, todo lo anterior supone picarse los filtros en C++ y enviárselos al autor del software para que lo integre, o comentarlo para ver si le parece bien como característica que añadir. El autor ha dicho muchas veces que el software se lo hace para sí mismo y con las cosas que principalmente usa, así que a falta de un programador para la funcionalidad todo dependerá de si el autor estima los añadidos como de su interés. Yo lo comentaré en la lista, por si acaso suena la flauta. Si aprovechando la cercanía de las navidades alguien quiere hacer su propia lista a los autores del software, podemos compartir por aquí lo que se echa en falta, que a lo mejor algo cae.
Y ya para concluir mis aportaciones de este fin de semana, un par de enlaces que hasta ahora no había puesto, de cómo sacarle partido a QLGT, escritos en inglés, pero muy fáciles de entender y con información que yo ni siquiera conocía, como la del "Diario", que puede ser de utilidad: Página principal de la Wiki de QLandkarteGT http://sourceforge.net/apps/mediawiki/qlandkartegt/index.php?title=QLandkarte_GT Página de la Wiki con un tutorial para hacer rápidamente lo más habitual con QLandkarteGT: planificar rutas y analizarlas más tarde http://sourceforge.net/apps/mediawiki/qlandkartegt/index.php?title=A_Grand_Day_Out
Sobre el tema de compilar los drivers para que el programa reconozca los GPS de Garmin bajo Windows, darte las gracias por la molestia que te has tomado y si hay suerte o alguien puede hacerlo ya nos informarás. Un saludo.
Hola A la hora de exportar una porcion de mapa como se explica (aqui) hasta la version 1.5.3 resulta que en la version para linux SI aparecia la opcion de exportar a JNX (Birdseye) mientras que en la version de windows esta opcion NO aparecia, y planteabamos una solución casera para habilitarla Bueno, pues tras comentar el tema en la lista de correo del programa esto ya se ha corregido en la versión 1.6.0, asi que si teneis una version más antigua basta con actualizar para que aparezca esta opción en la version para windows, (y supongo que para Mac). Ademas en esta nueva versión tambien permite exportar a formato RMP de Magellan ( Yo no lo he probado)
me encantaría que pudierais habilitar esa opción en la versión de mac. Le estáis dando un repaso al programa bien bueno, a ver cuándo me meto a aprenderlo...
Gracias por el interesantísimo aporte mitxelin, enlazado desde el primer mensaje del hilo. En cuanto a la versión para MAC, a efectos de compilación no debería ser diferente a la versión para Linux, y supongo que será cuestión de que alguien con un Mac OS X le de por instalarse el software compilándolo, o que pruebe a ver si exportar a JNX funciona sin tener que hacer nada más.
Bien, por desgracia la situación de los drivers para acceder a GPS Garmin desde QLGT en Windows era bastante peor de la que creía después de tener cierto éxito compilando los mismos, y el autor del software ha despejado todas las dudas al respecto: usuarios de Windows, o aparece alguien cualificado en desarrollo que adopte el código para hacer lo anterior posible, o no os quedará otra que hablar con el GPS usándolo como almacenamiento USB (los modernos), o transfiriendo datos usando otros programas: Disculpas por las falsas esperanzas de mis anteriores mensajes.
Se agradece el esfuerzo y el interés mostrado. Habrá que utilizar el Basecamp para tal menester... Un saludo.
Estupendas noticias para los usuarios de QLGT , pues Oliver Eichler nos ha regalado, a un mes de la Navidad, una nueva versión, la 1.6.0, con interesante novedades. Ya disponible en el sitio oficial en su versión instalable EXE para Windows, así como en código fuente, y en breve también estarán los paquetes para Mac OS X y para las distintas versiones de Linux. El mensaje original del autor se puede ver en el siguiente enlace: Publicación de QLandkarte GT 1.6.0 El cambio más importante es que el autor ha añadido soporte básico para dispositivos GPS de la marca Magellan (tras conseguir que le cambiaran el dispositivo que le había llegado defectuoso). Se pueden subir y bajar tracks y waypoints de los dispositivos, así como mapas en el formato propio de Magellan, el RMP. Otros detalles, como los adjuntos multimedia, los deja para mejor ocasión. En el capítulo de las mejoras sobre características que ya existían, el autor le ha dado un repaso adicional a todo el mecanismo de filtros. A petición de un servidor, ha hecho posible que los filtros apliquen, bien a tracks completos, bien a selecciones parciales de un track, lo que da mucho juego sobre todo en la fase de planear rutas desde casa (por ejemplo, marcando un tramo de una ruta y aplicándole el filtro de "establecer velocidad"). Así, puedes coger un track de terceros, o crear uno desde cero sobre un mapa vectorial basado en OpenStreepMap, e ir seleccionando tramos de distintas características. En un tramo llano lo marcas y estableces la velocidad a 20 Km/h, en una bajada le pones 40 Km/h, en una subida le pones 10 Km/h , etc. Como además puedes forzar a que el track, o un tramo del mismo, empiece a una determinada fecha y hora, puedes planear una ruta y horas de paso estimadas por cada punto. Esto puede ser interesante desde planear una ruta de unas pocas horas, porque quieras saber más o menos cuánto puedes tardar, a rutas tipo Transpirenaica, rutas de varios días donde quieres tener una estimación aproximada de lo que puedes avanzar cada día, y dónde vas a terminar. Las posibilidades son impresionantes. Entre los filtros añadidos está uno para desplazar la elevación del track (o rango de puntos del track) ciertos metros hacia arriba o hacia abajo, así como los mencionados para establecer el comienzo de un track (o subtrack) o la velocidad del mismo. Y también uno que permite establecer una diferencia en tiempo constante entre puntos consecutivos de un track, que es muy útil para "anonimizar" los tracks y no dar pistas a la gente de cuándo has ido por dónde (o qué rápido ;-) ) Recomiendo encarecidamente a todos probar esta nueva versión, y disfrutarla al máximo. Dejo una lista de las mejoras, en inglés, pues hay alguna que no he mencionado porque es sobre temas con los que yo no he jugado aún, pero son de interés: CODE, HTML o PHP Insertado: Request #411: Add basic data exchange for Magellan devices Request #412: Add trackfilter to add offset to elevation Request #413: Add lock flag to database folders and remove locked folders from possible target folders Request #414: Update DEM elevation in tracks if DEM attached to map file changes. Request #415: Add support for Magellan RMP map format. Request #416: Load other JNX files with same product ID as the one initially loaded Request #417: Add support to export raster maps to Magellan RMP format. Request #418: Add track filter to split tracks at stages. Request #419: Add 3-click track point selection Request #420: Apply track filters to slection only, if there is a selection Request #421: Add track filter to change start time of track Request #422: Add track filter to change speed of track Request #423: Add track filter to remove/unify timestamps
Y este es uno de los cambios que me parecen de más interés. Así sobre el papel parece como si fuera un cambio que permitiera tener cargados y mostrar a la vez varios archivos JNX, y después de probarlo, efectivamente así es. Se pueden ver a la vez y sin solución de continuidad (en principio) tantos mapas JNX como se quiera, siempre y cuando estén todos ellos en el mismo directorio y compartan el mismo Product ID. Para hacer la prueba, me he descargado los siguientes archivos, que creo son parte del excelente trabajo de iogrea y el resto de colaboradores que han creado archivos de este tipo para toda la geografía nacional: CODE, HTML o PHP Insertado: user@server:/tmp$ ls -lrt /tmp/*.jnx -rw-rw-r-- 1 user group 330273048 Nov 26 14:48 /tmp/04W_Pamplona.jnx -rw-rw-r-- 1 user group 355933205 Nov 26 15:45 /tmp/04X_Quintorreal.jnx Cuando cargo uno cualquiera de los mapas desde disco ("Archivo" -> "Cargar Mapa..."), me aparece un sólo mapa en el panel izquierdo de mapas "Raster", pero si hago botón derecho sobre el nombre del mapa, y elijo "Info/Config" me salen las propiedades de todos los mapas de ese directorio, cuyos "Product ID" son iguales, y en este caso iguales a 11. Además, si el zoom es lo bastante alejado, se muestra en pantalla el límite de ambos (en mi caso) JNX marcados con cuadros de color azul. Cuando voy haciendo zoom llega un momento en el cual ya se comienza a ver la primera capa de los JNX unidos sin solución de continuidad, y tal condición se mantiene a niveles de zoom crecientes, pasando a la segunda capa (MTN 1:25000) y finalmente a la tercera capa (ortofoto). Por lo tanto, a partir de QLGT 1.6.0 (y es algo que debería funcionar en todos los sistemas operativos) se deberían poder ver en pantalla a la vez tantos archivos JNX como se tenga en un mismo directorio, y siempre que sus "Product ID" sean iguales. En el caso de los JNX de iogrea, creo que todos llevan el mismo (11), y por lo tanto debería funcionar. A probar la funcionalidad, y a disfrutarla.
