Messages

[v10.6.3]

Oruxmaps es una herramienta maravillosa y vaya esta confesión por delante.

Muchos montañeros/senderistas la utilizamos como guía sobre el terreno, donde cuando no hay cobertura el único apoyo que llevamos encima es el que no depende de conexiones con terceros.

Esa es la razón por la que mi intervención está enfocada en destacar aspectos de la aplicación que pueden aún mejorar mucho en la experiencia offline y muy en especial en la consulta/visualización de los mapas.

Basten como muestra las dos imégenes del enlace que pongo al final de este escrito que estoy seguro sorprenderán a más de uno y sí, estas imágenes son capturas de pantalla de Oruxmaps sin más manipulación que la de unirlas en una sola.

Hay que tener en cuenta que el nivel de zoom utilizado para la creación de las imágenes es el 14 y que en niveles superiores aparecen más detalles,.

La imagen más grande está formada por 48 pantallazos y estos son sus datos técnicos:
   Orux app: v10.6.3
   Mapa mapsforge: Spain-Portugal_oam.osm de OpenAndroMaps.org - ZOOM 14
   Sombreado: Archivos personales HGT creados a partir de los datos MDT05 del IGN España con resolución horizontal 1/4" segundo de arco y vertical de 1dm
   Render Theme: Elevate v5.4 - magnitud sombreado 160 (modificada sobre el archivo Elevate.xml)
   
La imagen pequeña esta formada por 2 pantallazos:
   Orux app: v10.8.0 beta 3
   Mapa mapsforge: Spain-Portugal_oam.osm de OpenAndroMaps.org - ZOOM 14
   Sombreado: Archivos personales creados a partir de los datos MDT05 del IGN España con resolución horizontal 1/2" segundo de arco y vertical de 1dm
   Render Theme: Elevate v5.4 - Mapsforge/VTM maps > Hill shadow magnification > Normal

Y a continuación la razón de que esto vaya en el hilo de la Beta 3
   
La imagen pequeña cubre una pequeña area de la imagen grande y podemos ver que el cambio de "renderizado" empeora claramente la percepción del relieve (creo está universalmente aceptado una fuente de luz que viene del NW en un ángulo de unos 45º); no puedo saber si este cambio es debido a una elección en el tipo de sombreado (Orux app), o a un cambio interno en la nueva versión de la/s librerias Mapsforge (Mapsforge libs). Entiendo que si estuviéramos en el primer caso la solución sería fácil y rápida y que ante diferencias de opinión bastaría con sacar los posibles tipos de sombreado a la interface de usuario para que éste pudiera elegir según sus preferencias, tal como ha ocurrido ya con la profundidad del sombreado.

Otro aspecto en el que hay un retroceso en las nuevas librerías es que no aceptan los archivos HGT con la resolución 1/4" que sí permitían las antiguas. No habrá muchos afectados porque, como ya dije antes, los archivos HGT utilizados son personales, aunque envié una muestra a José Vázquez (Orux) para que pudiera hacer pruebas con ellos. La imagen pequeña sólo tiene 1/2" arcsec de resolución horizontal, también a partir de archivos HGT personales.

Desgraciadamente nunca fue posible utilizar mayores resoluciones a partir de los MDT02 del IGN (por ejemplo 1/8" arcsecond), y no por problemas técnicos ya que los archivos HGT no tiene formato, simplemente son una sucesión de enteros de 2 bytes con el valor de la altitud de cada uno de los puntos geográficos representado.


SUGERENCIA: Quizá fuera del agrado de muchos usuarios de Orux la posibilidad de "renderizar" un área elegida sobre un bitmap, en lugar de la pantalla, que pudiera imprimirse para utilizarlo como cualquier otro mapa en papel. Supongo que se aprecia claramente en la imagen grande la excelencia del posible mapa resultante.


https://photos.app.goo.gl/DrGYPY66KUx87WhT6

Vamos con las sombras

Los dos visores (tradicional y vtm) funcionan muy diferente respecto a las sombras.

En el visor tradicional yo tengo el control 100%, por lo que la app lo que hace no es superponer la capa de sombras con un nivel de transparencia, como se hace en el visor vtm. Lo que hago es multiplicar los colores, con lo que el efecto que se consigue es mucho mejor que la superposición. El nivel de sombreado no juega con el nivel de transparencia, juega con la oscuridad del color. En el visor vtm yo no tengo el control, lo que hace el visor es aplicar la capa con transparencia sobre el mapa, al final del procesado. Si el nivel de transparencia es bajo, solo se vería la capa de sombras. El juego con este visor cambia mucho respecto al del visor tradicional. Pero con el visor tradicional, mapas mapsforge, usando sombreado genérico (no el específico de mapsforge) yo no puedo elegir pintar el sombreado en medio de las capas del mapa, con lo que la multiplicación de colores afecta a carreteras y demás.

Y por otro lado están los mapas mapsforge, que tienen su propia capacidad de pintar sombras. La ventaja de estas sombras es que se aplican al nivel de capas que debe ser, antes de pintar carreteras, símbolos y esas cosas. Pero tienen sus limitaciones, claro, ya no tengo el control al 100%.

Por eso ofrezco todas las posibilidades, para que el que quiera, elija la que mejor se adapta a sus necesidades.

Cuando digo que los ajustes de sombras son separados para un y otro tipo de mapas no quiero decir que el valor 99 hace lo mismo en ambos, significa que en un tipo de mapas puedes tener el valor 99 y en el otro un valor 55. Pero como la forma de pintar las sombras son absolutamente diferentes entre mapas mapsforge sombreado nativo/visor tradicional/visor vtm, conseguir el mismo aspecto visual es imposible.

A medida que evolucionen las librerías mapsforge/vtm, supongo que se podrá ir personalizando más todas estas cosas, con lo que igual se termina consiguiendo lo ideal: Poder pintar la capa de sombras, con el nivel de grises que se quiera, usando los ficheros hgt/hdr y al nivel adecuado, debajo de carreteras y símbolos.


No obstante, le daré una vuelta, son tantas cosas que ya no tengo claro del todo cómo hago con algunas cosas!


orux

Hola, Orux.

Agradezco tu contestación (que ya no esperaba), pero me alegra pues tengo noticias buenas acerca del tema que quizá ni siquiera conozcas de tu propia aplicación (soy informático aunque no de Android y pasa a veces).

En este tiempo que ha pasado he seguido investigando el tema y he conseguido generar archivos .hgt más detallados que los tipicos de 1" y 3" segundos de arco del proyecto SRTM, y lo que es más importante: la librería de mapsforge es capaz de leerlos.

Los ficheros creados parten del los originales del IGN MDT05 y tienen una resolución horizontal de 1/4 de segundo de arco y una vertical de 10 cm (Los originales del IGN, tanto los antiguos .asc como los GeoTiff actuales tienen una resolución vertical inferior al milímetro). Esta resolución vertical es imprescindible para que los terrenos con relativamente poca inclinación no generen terrazas.

Un efecto no deseado de esta resolución vertical queda patente en los 3 pantallazos que te envío que indican altitudes de más de 13.000 metros. Esto ya me pasaba con los HDR y no sé si es que Orux no tiene acceso a esa info dentro del fichero, en cuyo caso la cosa se complica.

Te pongo los enlaces de 3 pantallazos con distinto sombreado (hay que modificarlo en el archivo Elevate.xml y es un parámetro que ni siquiera viene cuando te lo bajas aunque sí está documentado), en el que se puede apreciar que aún con un sombreado extremo nunca dejan de verse los senderos/caminos/etc.

Puestos a suponer que los mapas más usados son los de OpenAndroMaps (sin duda los mejores), cualquier motor de renderizado que se precie tendría que tener en cuenta esta estructura de capas de Mapsforge. En mi opinión resulta difícil aceptar un resultado que no esté a la altura; se pierden demasiados detalles que está ahí.

Por cierto, una ventaja de los archivos .hgt con la nomenclatura propia es que pueden mezclarse perfectamente archivos de distintas resoluciones; las uniones son perfectas.

https://photos.google.com/share/AF1QipMepIAETZVe-L7XM1P9aNrdmMbkqPlJyZFCDRsYMgEoUmTL0N4oliY_MPdYXRv6Jg/photo/AF1QipNuo6e_Ad5upAwkIhgdJtfVPhZQYWDGA-DG_TV3?key=b2xpU3pvVU1lTnlMUzU0NGxDQy0zSDZmUDNEM3F3

https://photos.google.com/share/AF1QipMepIAETZVe-L7XM1P9aNrdmMbkqPlJyZFCDRsYMgEoUmTL0N4oliY_MPdYXRv6Jg/photo/AF1QipMCZeejhMeOnDpSylIgAc8ALG2PahYghKHTfNbx?key=b2xpU3pvVU1lTnlMUzU0NGxDQy0zSDZmUDNEM3F3

https://photos.google.com/share/AF1QipMepIAETZVe-L7XM1P9aNrdmMbkqPlJyZFCDRsYMgEoUmTL0N4oliY_MPdYXRv6Jg/photo/AF1QipOn2lJBGO6gynuGAXvDs4ruL8XWt0kvmLRN5hRQ?key=b2xpU3pvVU1lTnlMUzU0NGxDQy0zSDZmUDNEM3F3

Solo me queda decir que la comunicación por esta vía es excesivamente lenta cuando como en este caso hay mucha información y muchos matices a tener en cuenta que requerirían una comunicación más fluida.

Sigo pensando que Orux es una aplicación excelente y mi apuesta es por todo aquello que cuando estás en medio de las montañas y no hay cobertura está ahí para ayudarte.

Saludos,

Pedro

Hola, Tronpo.
En primer lugar, gracias por hacerte eco de mi participación en el foro que eso siempre es de agradecer pues indica que no estoy solo en lo que a este tema se refiere.

Te indicaré que lo que comentas acerca de hillshading/@magnitude lo conocía pues está en la única documentación que me indicó Tobias y ya lo había probado, pero desde el momento en que solo aplica a archivos HGT, además del poco contraste resultante, no me resulta interesante pues no aporta nada que mejore el valor por defecto (el valor máximo es 255)

Afortunadamente, el control del nivel de grises hace que por fin se puedan usar archivos DEM más detallados ya que antes debían tener por defecto un valor cercano a 99 y eran completamente inutilizables.

Puedes ver que mi primer post en el foro en August 23, 2020 ya hablé de ese tema sin que nadie respondiera. Mi post acababa así: Sería posible aclarar el sombreado de los archivos HDR? Pasando al usuario la configuración de este aspecto? Incluyendo incluso la dirección y altura de la luz?
Eso es lo que acaban de añadir para que el usuario pueda configurarlo, asi que contento pues más vale tarde que nunca, que dice el dicho.

En cualquier caso, no estaría mal que Orux/José Vázquez y/o sus colaboradores tuvieran en cuenta en su calendario de mejoras el tema del "hillshading", sobre todo porque es la única aplicación que permite un sombreado de alta resolución y el resultado es espectacular.

Te comento, que si no conoces otra aplicación como Oruxmaps pruebes Locus Map. Dependiendo en qué, se intercambian los puestos 1 y 2 en mi podio particular. No hay ninguna aplicación que se les acerque siquiera y ninguna de las dos es claramente mejor que la otra.

He subido dos parejas de pantallas: una para ilustrar diferencia en el tratamiento de capas entre el visor Mapsforge y el general (Valle de la Fuenfría, Cercedilla, Madrid) en el que se aprecia clarísimamente que por muy oscuro que sea el sombreado los caminos, sendero, ríos, etc... resaltan siempre sobre el sombreado mientras que la semitransparencia se aplica solo al terreno (el verde de la vegetación); en cambio el visor general crea una única imagen fundiendo indiscriminadamente todas las capas y a la imagen resultante le aplica una semitransparencia para fusionarla con el fondo del sombreado dando como resultado la pérdida de la info más relevante en el campo/montaña.

https://lh3.googleusercontent.com/pw/AP1GczMCGtS0gcVw5JrMaTIPaoXDaKWsfVfj9WWUIyGFho4n2QLR37yNPmpBBVjBTRi8z_DMqiQomQhRJ3IFRpiervHlDgXP4VvJduT05cgpvIorGsYU1SxCvh9RJZO8chZy56xEFhgHmXpV4LBqlsffxlrt=w641-h1425-s-no?authuser=0

https://lh3.googleusercontent.com/pw/AP1GczNlIfp1MVlJKWFQcbe7qOtcYIQmc0ags2KVoQ1zrV58hksqDce5wNhUZy9U42skcl5baErFCQ1edVqZCEv3B8sWPrK8tdL7csN0RfaD0Cf_SscJWH3AON6hTrgKBg1mdyMCpuUwOeZ6jqE1OhiTni0R=w641-h1425-s-no?authuser=0

La segunda pareja, utiliza en ambos casos el vison general con un valor de 60 y sirve para ilustrar la enorme diferencia entre los archivos HGT y los archivos HDR+DEM (zona Embalse de Navalmedio, Cercedilla, Madrid). Las he añadido para que todo el mundo que lea esto sepa de qué estamos hablando cuando nos referimos a alta resolución.

https://photos.google.com/share/AF1QipMepIAETZVe-L7XM1P9aNrdmMbkqPlJyZFCDRsYMgEoUmTL0N4oliY_MPdYXRv6Jg/photo/AF1QipOxOlPkr_-Lb9TB0eDCkhBmumr2puFR95kPWSod?key=b2xpU3pvVU1lTnlMUzU0NGxDQy0zSDZmUDNEM3F3

https://lh3.googleusercontent.com/pw/AP1GczNRyQZY7CzvIGXf1A9QdsC-j7HOJXZFXV--DcJGruEyJt7QqOC7Ly8tenI3fZTAZrhBd62MTxkUhXnkNebablsccUXXjlfJAtCNyRlkRfQZbXBgN1zPs5Ao_l8py6TwzrzdPvJkU0fvE6tTFuILB79T=w641-h1425-s-no?authuser=0

Otro añadido al programa que lo mejoraría enormemente sería incluir el formato GeoTIFF a los ya existentes, especialmente si tenemos en cuenta que el CNIG ha sustituido los archivos .asc por este formato y cuyas especificaciones son públicas... pero dejaremos este tema para otra ocasión.


Saludos,

[definitivamente no hay ajustes implícitos separados]

Los ajustes son, en teoría separados, para los visores que usan tecnología diferente (superposición vs multiplicación de colores).

Debes poder ajustar con diferentes valores para uno u otro tipo de mapa.

Prueba a cargar un mapa mapsforge, por ejemplo, con uno y otro visor, verás que los ajustes de opacidad pueden ser diferentes,

orux

Hola, Orux.

Aunque el tema de los sombreados es algo que he explorado en profundidad, tomándome muy en serio el papel de beta tester, me voy a limitar a seguir únicamente con la recientemente añadida posibilidad de controlar la gama de grises con los que se hace el sombreado.

Lo cierto es que los dos pantallazos que envié utilizan el mismo valor, 99, y mientras que en el visor "de siempre" el efecto es dramático, con el visor VTM se queda en un nivel medio claro de grises en su valor más oscuro, con lo que la prueba que me sugieres estaría hecha y no, definitivamente no hay ajustes implícitos separados; el mismo valor tiene resultados muy distintos para cada visor.

La configuración [Settings > Mapsforge settings > Apply hill shadows] no se ve afectada por el valor elegido en [DEM based maps > Shadows exageration] y tampoco ifluye que se seleccione [VTM map viewer], dando siempre la gama de grises de siempre (bastante claro).

A esto añado que [Mapsforge settings] sólo funciona con archivos HGT, dejando fuera de juego los archivos HDR+DEM que es donde el tema del sombreado se pone realmente interesante por el nivel de detalle que permiten alcanzar cuando se obtienen a partir de archivos LiDAR.

Si entiendo bien los conceptos detrás de "superposición vs multiplicación de colores" tenemos un nuevo problema. Solo el API de Mapsforge respeta la información de capas (superposición) contenida en los "renderthemes" en la que hay distintos grados de transparencia e incluso establece en qué capa debe ir el sombreado (este asunto lo he comentado con Tobias, el creador de los temas Elevate y Elements para OpenAndroMaps)

Volviendo a la configuración general [Settings > Apply hill shadows], que es donde realmente se aplica el resultado de [DEM based maps > Shadows exageration], y eligiendo sombreados detallados (HDR + DEM), siempre se utiliza la (multiplicación de colores), ignorando los "mapstyles" de Mapsforge aun con mapas OAM, provocando que más allá de un nivel medio-claro de grises se pierdan los senderos/caminos/pistas, debido a la transparencia indiscriminada aplicada para fusionarse con el sombreado. Por fortuna, el poder decidir la gama de grises permite utilizar estos sombreados detallados que antes no eran utilizables por demasiado oscuros con la consabida perdida de información debida a la forma fusionar las dos capas (shadows+oam map).

Si no me he expresado bien o necesitas algún pantallazo para ilustrar lo que comento sólo tienes que decírmelo y estaré encantado en ayudar con el tema.

Saludos,

Hola, Orux!
Recientemente he visto que en "DEM based maps" se ha añadido una nueva propiedad configurable llamada "Shadows exageration" para controlar la gama de grises empleada en el sombreado del relieve.
Mi propuesta es que se duplique esa propiedad, una para el visor tradicional y otra para el VTM por una razón obvia cuando se analizan los dos pantallazos que adjunto, ambos con valor de 99 (el más claro es el VTM; el visor de siempre para igualarlo le basta con 40), con el fin de que se puedan establecer valores independientes para cada uno de los visores.

https://photos.google.com/share/AF1QipMepIAETZVe-L7XM1P9aNrdmMbkqPlJyZFCDRsYMgEoUmTL0N4oliY_MPdYXRv6Jg/photo/AF1QipMtOJ6SSJrulU0NH4Gd-FbjBbgPbdlQzZwOEDbv?key=b2xpU3pvVU1lTnlMUzU0NGxDQy0zSDZmUDNEM3F3

https://photos.google.com/share/AF1QipMepIAETZVe-L7XM1P9aNrdmMbkqPlJyZFCDRsYMgEoUmTL0N4oliY_MPdYXRv6Jg/photo/AF1QipNi0baxF1NWXj0FE5JEWpdbIJqAa1RrkntWiSfU?key=b2xpU3pvVU1lTnlMUzU0NGxDQy0zSDZmUDNEM3F3

[hdr+dem]

Hello!! Indeed, the mapsforge shading, which has always "dominated" the general shading, seems that this has been extended by "overriding" the rest of the layers based on DEM (relief, slopes). In my opinion the elimination of the mapsforge shading would be a "loss", since this shading has the peculiarity of being shown in specific layers of the mapsforge map (defined by the creator of the mapsforge theme) such as in some cases it is above the terrain and below of roads, paths, labels, etc. Unlike the general shading that shows on top of everything. But I would like a notice in the interface informing about it, for example it would have saved me some confusion. Greetings

Estoy totalmente de acuerdo en que Mapsforge shading NO debe desaparecer .

En los temas Mapsforge, determinadas capas, como el terreno, son semitransparentes, mientras que senderos, caminos, carreteras, etc son opacas por lo que destacan siempre del fondo, cosa que el sombreado general no tiene en cuenta.

Por ello más bien pienso que el shading general debería considerar las capas de cada mapa en aquellos tipos de mapa en que esto sea posible ya que el "merge" utilizado del mapa con los archivos dem lo convierte en inservible cuando se utilizan archivos hdr+dem, especialmente si son muy detallados, pues hace que prácticamente no sean visibles los senderos en las zonas de sombra.

Desgraciadamente, el sombreado Mapsforge tiene un problema: sólo funciona con archivos hgt

A propósito de esto tuve una conversación con Tobias (creador de los temas Elevate y Elements) en la que me sugirió generar un Shadows.map y combinarlo con el mapa Mapsforge (OAM), obviamente editando elementos y capas del tema (básicamente he trasladado elementos a otras capas y eliminado el fondo por no poder mantener la semi-transparencia).

La idea es buena y funciona pero tiene un pero que no comprendo: Shadows.map sólo funciona hasta el zoom 16 cuando se combina con el mapa OAM, independientemente de que se indique un zoom más alto al generarlo y también al combinarlo, sorprendente si se tiene en cuenta que funciona perfectamente si está solo.

Cabría destacar que Oruxmaps es la única aplicación que permite usar sombreados detallados (hdr+dem) y es una pena que no sea práctico utilizarlos por el motivo expuesto.

Sería muy de agradecer que orux revisara este comportamiento.

I have read all the previous posts carefully and I would like to contribute my cent to the discussion.

I bring to the table two screen captures of the Cares River area from the Shadows virtual map made from DEM files; it is exactly the hillshading underlay layer alone. I hope this will help to understand what are we talking about when we refer to 5 m dem files.

One picture is from HGT files and the other is from HDR+DEM files obtained from MDT05 IGN .asc originals.

To use highly detailed DEM (hdr+dem) files should not be a problem but need to be indexed, which obviously are not.
Indexes in HGT files are included in its name, but HDR files must be read one by one to get the info and maybe store it in a database for quick access.

Zoom level of both pictures is 14

I would like the developer/s of Oruxmaps feel the need of review this part of the application because...

Oruxmaps is the only application out there that allows detailed hillshading!!!

Both pictures had to be cropped because of the ridiculous limit of 500KB per upload item in this forum. Without this limit I could post below 1 m precision dem files.

What do you call "Shadows" map ?
I guess that this map is limited to zoom 16 ? In this case, it's normal that multilayer combination including "Shadows" is also limited to level 16.

Multilayer map are always limited to zoom level existing for ALL of its layers (and NOT for ANY of its layers)

If my asumption is not OK, pls share "Shadows" mapsource file, that we can test.

Hi, LaurentG
Zoom levels in Shadows map are up to you and I've chosen 19 as max zoom level because my DEM files are very detailed even at high zoom levels.
Shadows, Relief and Slope maps are virtual maps calculated on the fly from DEM files and maybe cached for better performance.
I'm afraid that the answer to my question can only come from someone who knows the application internals because the reason of this behavior cannot be seen at a user level.

Anyway, thanks for your interest.

I've attached a screenshot of the configuration menu where you decide maps and zoom levels that should work if you are allowed to choose...

Regards

I've been trying to combine Shadows+OAM maps and in spite of zoom settings from 9 to 19 Shadows map stops redrawing at zoom 16.
Using VTM visor doesn't help; it can reach zoom 19 but enlarging the picture in zoom 16 as if it was the last zoom picture in a raster map.

Regards

Recently, a friend of mine showed me the way that Gaia GPS, the app she uses, deals with 3D allowing to navigate any map, even satellite maps, as a true and useful flight experience, giving a feeling of the terrain that is not possible with any other map view, specially in the mountains.

I'd like you to have a look at this app to see what I mean. I'm pretty sure that adding this feature to Orux will make our preferred app even better.

There is a file Explorer app that works fine with Android , FV File Explorer

Lo sé, CronoX, pero ninguno de ellos puede acceder a esos mismos directorios en la tarjeta externa que es donde guardo principalmente los mapas y los archivos dem (.hgt y .hdr) que ocupan varios gigas...

Bueno, hay varias apps que pueden acceder a toda la tarjeta SD siempre que tengan permisos de "root".

Aun así, estas carpetas no son visibles desde el PC, por lo que tampoco puedes copiar archivos como antes...

Hola orux,
sigo probando las betas para detectar pérdoda de funcionalidades con el cambio que se avecina y en esta ocasión me centraré en el uso de la tarjeta SD.

Muchos usuarios recurrimos a la tarjeta SD cuando se trata de archivos voluminosos como los dem y los mapas con el fin de ahorrar espacio en el almacenamiento interno a la par de hacer portables a otros dispositivos los archivos y flexibilizar su manejo.

Y es en el uso de la tarjeta donde he encontrado todos los problemas del mundo con el nuevo almacenamiento privado (Android/data).

No es posible acceder a los datos de ninguna forma: programas como Explorer/Root Explorer, Solid Explorer y X-plorer (los he probado), no pueden acceder de ninguna forma, aunque sí pueden acceder a los datos en el almacenamiento interno ¿?

Ni siquiera Oruxmaps tiene acceso cuando usa la app del sistema, Files, como gestor de archivos.

Comento brevemente un caso que creo muy significativo: Sali a hacer una ruta creando un track y cuando traté de exportarla a gpx... seguí sin tener acceso a dicho track pues automáticamente lo guarda en Android/data/oruxmaps/tracklogs que al estar en la tarjeta SD no es accesible... ah, y tampoco se pueden cargar desde Oruxmaps los ficheros .gpx recien creados por la aplicación misma!

Entiendo que en este último ejemplo bastará con no asumir el directorio de destino y preguntar al usuario dónde quiere exportar el archivo.

Tengo la sospecha de que estamos asistiendo a una iOS-ificación de Android y que puede que el siguiente paso sea la supresión de cualquier medio externo de almacenamiento en favor de sus propuestas interesadas como Google Drive, Dropbox, etc... y que para copiar un fichero desde/hacia el pc tenga que dar antes la vuelta al mundo de servidor en servidor...

Quizá, y entiendo que eso puede ser un curro enorme, la única solución sea que Oruxmaps se encargue directamente de de comunicar, en un sentido y en otro, la parte privada con la compartida, y eso podría hacerse extensible a todos loa archivos.

En mi opinión, aquí se produce el sinsentido de considerar archivos de usuario como archivos de la aplicación y no es el caso, porque tanto mapas como dem's como gpx son tan de usuario como los .pdf, los .mp3 o los .docx

Disculpa la parte política de mi mensaje, pero no me he podido aguantar y quizá en algún foro pudieran servir como argumento.

Saludos

Prueba la siguiente beta.
Ya se pueden seleccionar carpetas dentro de la carpeta principal en cada uno de los directorios.


orux

Acabo de probar la beta 9.0.4 y me parece perfecta la solución.
Muchisimas gracias por tan pronta respuesta y mis felicitaciones por tu excelente aplicación, para mi la mejor

No creas que no me he resisistido, y no le he dado vueltas...

Android/media está 'obsoleto' con lo que en cualquier momento Google lo elimina o no deja usarlo, con lo que volvemos a otra migración que sería otra locura.

Las carpetas media, descargas,... tienen otras limitaciones. La propiedad de los ficheros es temporal por parte de las apps que los crean, el acceso a las que no son tuyos no es directo,...
Explorer sí puede acceder a las carpetas bajo Android/data/ con lo cual con ese explorador puedes mover/eliminar/copiar,... en las carpetas de la app. No es el único navegador de ficheros, lo único que hay que hacer es darle el permiso para el acceso.

Si actualizas de 8.5 a 9.x, la app te da la opción de NO migrar al nuevo sistema de almacenamiento, con lo que puedes actualizar y mantener los ficheros donde siempre. Solo cuando se instala de cero (no actualización de versión antigua) la app se ve forzada sí o sí a usar el nuevo sistema de acceso a ficheros.

orux

En primer lugar, gracias por tu rápida respuesta.

Por fin he conseguido acceder a los directorios de la aplicación y copiar ficheros de mapas en ellos. Es muy incómodo porque obliga a copiar primero a una carpeta compartida desde el PC y luego desde esta a, por ejemplo, mapfiles... pero es posible y habrá que conformarse.

La parte a la que no veo solución sin que lo facilite Oruxmaps es a la de los ficheros DEM.
Me explico: dentro del directorio dem tengo creado otro (hgt) con todos los archivos *.hgt de España,
pero con bastante frecuencia cuando voy a una zona concreta, pongamos Picos de Europa, me creo a partir de los datos de CNIG duplas dem/hdr con una precisión muy alta y los coloco en otra carpeta específica, también dentro de la carpeta dem.
Esto me permite, dependiendo de la necesidad, tener un sombreado distinto de la zona de interés.
Es obvio que ambos tipos de archivos no pueden convivir en la misma carpeta pues entrarían en conflicto...
Creo que la única forma de solucionarlo sería flexibilizando la elección del directorio dem, tal como estaba en versiones anteriores pero desconozco la dificultad que eso puede suponer.
Adjuntaría un fichero hdr/dem de ejemplo pero el más pequeño que tengo (8.40MB) sobrepasa el límite del foro.
Saludos,

Hola orux,
he probado la versión 9 y me he quedado sorprendido por la nueva normativa de Google que recorta claramente posibilidades al programa.
He intentado explorar la forma de paliar el problema creado y no he encontrado la vía: programas como Explorer no pueden realmente acceder a los ficheros y, por si fuera poco, tampoco Root Explorer puede hacerlo
No estoy seguro pero, y si los datos se guardaran bajo el directorio Android/media en lugar de data?
Se me ocurre otra propuesta que podría ser válida: colocar la estructura oruxmaps/* bajo la carpeta Documents, por ejemplo. No es concebible que mp3, podcasts, alarmas, videos, fotos, etc se puedan guardar en carpetas especiales compartidas y mapas, tracks, etc no puedan hacerlo cuando son archivos que pueden cambiar con relativa frecuencia.
Te añado un uso muy concreto que con la nueva propuesta es imposible utilizar. Se trata de los archivos dem; bajo el directorio dem tengo subcarpetas, una de ellas con los archivos hgt de toda españa y luego otras carpetas de zonas muy concretas con archivos hdr, permitiéndome elegir el directorio concreto que me interesa en un momento dado.
Espero que se me entienda y si no fuera el caso, por favor, pregúntame que intentaré aclararlo mejor.
Por el momento, y después de probar la beta 9.02 cme quedo en la versión 8.5.5
Gracias por tu excelente aplicación.
Saludos,