New beta 10.6.x [CLOSED]

Started by orux, April 12, 2024, 05:15:03 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Starfighter

#15
Quote from: orux on April 19, 2024, 10:57:28 AMLos 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,

Tronpo

Quote from: Starfighter on April 22, 2024, 05:11:21 PMHola, 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, he seguido tus aportaciones sobre los sombreados aqui y en el foro de OAM.
Estando de acuerdo con ellas me gustaría aportar algunas cosas.
Sombreado mapsforge :
Este sombreado es generado por el motor de renderizado mapsforge integrado en Oruxmaps, es por esto que los ajustes de grises no tienen efecto sobre el, como app no puede acceder a ello.
Pero nosotros si podemos modificar la intencidad de dicho sombreado, desde el codigo del tema (por ejemplo Elevate),no recuerdo que Tobias te lo comentara.
Para esto hay que añadir el atributo magnitude a la linea de sombreado, por defecto el valor del sombreado mapsforge es magnitude="64"
Te muestro unas comparaciónes:


Sombreado original Elevate

Sombreado modificado
Linea sombreado
<hillshading magnitude="128" zoom-min="9" zoom-max="17" />

Sombreado modificado + vtm

El visor VTM atenua también el sombreado mapsforge.

Otro data adicional aparte de que orux es la única app que usa Dem de alta definición, es también de las pocas que ofrece el sombreado mapsforge.(yo no conozco otras..)

Por lo que sera complicado pedir que mapsforge utilice dem de alta definición.
Y teniendo en cuenta que Oruxmaps no puede intercalar su capa dem entre las capas de un mapa vectorial, tendremos que buscar una mejor aplicación del sombreado jugando con los ajustes y los dem utilizables.

Saludos!!

Starfighter

#17
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,

Tronpo

#18
Desde hace poco instale "locus map" para analizar ciertos paralelismos con Oruxmaps en busca de conceptos de mejoras con para Oruxmaps.
Por ejemplo este tema del sombreado esta muy trabajado.(también el uso de sombreado esta bajo una suscripción anual)
Los dem de alta definición  dan un resultado impresionante no solo para el sombreado, también para el resto de capas dem.
Hace un tiempo unos cuantos miembros de un grupo de usuarios iniciamos un proyecto
Toda España Dem Mdt05
Aquí lo dejo para que el resto de usuarios españoles pueda hacer uso de ellos
https://t.me/OruxDeMDT50
Si quieres colaborar en algún momento sera un placer contar con tus conocimientos.

Después del trabajazo de las capas dem en la última beta coincido contigo en que se debería mejorar el tratamiento de los archivos dem(no solo los de alta definición, pues no están a la mano del usuario global) talvez aplicar un algoritmo o filtro de imagen diferente al actual para minimizar el pixelado.
Ofrecer al usuario dem 1" si no es mediante descarga directa como los dem actuales 3", mediante los enlaces correspondientes a los dem de sonny o de NASA.
El usuario medio/básico no los conoce y estas nuevas capas dem no lucen con los dem por defecto (3")

"aclarar que" no conozco otra app que trabaje con el sombreado mapsforge, Locus no lo hace, cruiser app(del desarrollador de mapsforge) tampoco

A mas ver

Tronpo

Un apunte más Oruxmaps ya admite archivos tiff, pero parece que hay varios tipos de ello(no entiendo mucho) y algunos no los lee como en este caso los modelos digitales del terreno del IGN en formato COG(tiff)

odin

Hi orux found another bug with using Bluetooth speed and cadence sensors, if one of the sensors doesn't connect properly (ie dead battery) then both sensors will be aborted and both will remain disconnected

Tronpo

Quote from: orux on April 12, 2024, 05:15:03 PMAs always, starting a new series of betas.

Version 10.6 is in progressive release, will be in GP soon available to everyone.


This beta has new features:

1. Climber. Analysis of segments by slope. In construction. This is a new screen on the trip computer views, which reports on slope segments data (configurable). These data for each route can be modified and saved for future use. In the trip computer view > Climber view, there is a button that takes us to the list of slope segments. In that screen we can see the different segments calculated. We can change the parameters (distance and slope used for the calculations, top action bar > more button). We can delete/join/split the segments.

1.1. New buttons over some graphs, to do zoom/reset to the current position, if following a route.

2. New slope graph, using the altitude graph, by colors.

3. Route planner. New option to trace sections with the finger.

4. Rearrange dashboard elements in the map viewer or trip computer views by dragging and dropping. For this purpose, a new dashboard editing tool has been added (map viewer > left panel > other tools).

5. Improved side button bars constructor, with more help to find the right buttons. The button and the description is displyed when we drag the bar to select a different button.




beta2:
--New setting in route plenner. Try to adjust the path made with the finger to an existing route in Brouter.
--bug corrections




https://oruxmaps.org/OruxMaps10.6.1beta2.apk




orux
Hello orux!!

As far as the "Climber" functions are concerned.

I think it's the beginning of a very interesting and long-awaited merger.

Currently it is limited to a visual analysis of the route as far as the "slopes" are concerned, I like the predefined criteria and the option that the user can "play to build" to their liking the "climber's screen".

I understand that it is a first contact and that we will see an evolution, for my taste I will present some points.
1-The settings of the climber segments are saved for later use en route (and are exportable gpx, kml, etc. (currently they are not saved at least to me) 
2-The climber segments generate warnings, with the information of the segment when we are following the route, (maybe a waypoint with the information) proximity alert etc
3- For the duration of the segment, the altitude graph automatically zooms in.
4-Live segment information, you have added data about it for the dashboard (Already existing 👍)

Best regards   

orux

Hello!

Updated the link to the right beta version,



orux

odin

#23
Hi orux, I was recording a route using oruxmaps, and also recording using a dedicated cycle computer, most of the stats were similar except on the bike computer the altitude gain/loss was off by almost 1000 ft from what orux shows, im not sure what one is correct. (I have more confidence in orux then the chinese bike computer (Xoss G2 Plus) but who knows.).

Anyways I have another bike computer arriving in a few days so i'll be able to compare against that one too.

btw the new update works great.

orux

Quote from: odin on April 20, 2024, 08:51:22 AMHi orux, awesome work,
I picked up some bike sensors recently, so I was messing around in orux to see how they work.
I was wondering with the sensors like cadence / speed, could you make it so it retries to re-connect to them indefinitely (or a configurable time), sometimes I walk away from my bike for a few minutes and often forget to tell orux to reconnect to the sensor, also on the track statistic page it's a bit confusing what data is from the sensors and what's from the GPS, maybe a toggle to show sensor stats and a toggle to show GPS stats if possible.

I was also messing with some bike computer app, it could play back your ride route like a video from 1x to 100x speed and has like a little dot icon that moves through the route and shows riding speed as it plays through, I thought that would be pretty neat if orux could do that, but you could show more stats like altitude, speed, grade...etc

Edit:
also minor bugs, when adding a second sensor to the BLE cadence / speed, it should show the mac address like the first sensor does, since there is no way to know if the second sensor is added, also for popup noticications it just says bluetooth sensor connected, maybe that could be improved to something like BTLE speed sensor connected / BTLE cadance sensor connected, same with the connection lost message.

Hello!

I am working with those sensors...


About reconnections. If you start the sensors manually (you do not use the automatic connect setting) the app should try to reconnect indefinitely. This is so that it is not constantly trying to connect when automatic connection is activated, and you are not using the sensors.


I will correct the problem with the MAC of second sensor, and add the sensor name to the warning messages about connection/disconnections.



orux





orux

Quote from: Starfighter on April 22, 2024, 05:11:21 PMHola, 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,


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

odin

#26
Quote from: orux on May 11, 2024, 08:12:36 AMHello!

I am working with those sensors...


About reconnections. If you start the sensors manually (you do not use the automatic connect setting) the app should try to reconnect indefinitely. This is so that it is not constantly trying to connect when automatic connection is activated, and you are not using the sensors.


I will correct the problem with the MAC of second sensor, and add the sensor name to the warning messages about connection/disconnections.



orux


Thanks for the tip about automatic sensor connection, I will do manual connection for now on when I need to use the sensors.

Btw do you have any plans to update the 3d map viewer (not mapbox), often times I get stuck with a partial rendering regardless of optimize 3d rendering, texture size/complexity, I'm on miui 14/android 13 if that helps.

IBERO


Buenos días Orux:

¿Habría alguna posibilidad, de que la previsión del tiempo en la ubicación actual (botón en la barra lateral), mostrará la previsión por cada hora, en lugar de cada 3 horas? y ¿Qué la velocidad del viento la diera en km/h, en vez de m/s,  que es la medida con la que se esta más familiarizado?.

Lo de la previsión cada hora, ayudaría mucho a ajustar con más precisión, una salida que se pretenda realizar.

Muchas gracias

Starfighter

#28
Quote from: orux on May 11, 2024, 10:48:03 AMVamos 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

jherb

I have the following problem with 10.6.2beta2 and beta3:

Starting yesterday, I cannot access any files from within OruxMap which were not created by it. I can see folders, but e.g. not any gpx files within them. (But image files like *.jpg or *.png are visible). The same applies to some map files. Older ones, which I can see by the Google Files browser, I cannot see from within OruxMap. But some newer maps, which I installed within the last year are visible.

I "solved" this by starting the process to "Move data to public folder" (if I remember correctly), granting Oruxmap access to all files and then "killing" the app.
 
Temporarily, also the Google Files browser didn't work but this issue somehow disappeared. I updated Android last month and OruxMap worked with that version. But perhaps this problem is somehow related to the latest updates by Google Play?

My versions are:
Android 14 (security updates of March 1st, 2024), Google Play system update May 1st, 2024.

All OruxMap files live within /storage/emulated/0/oruxmaps and its subfolders.

Does anybody know what happened? Was this caused by some system updates?