Recent posts
#1
BETAS / Re: New beta 10.6.x
Last post by jherb - Today at 02:35:08 AMI 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?
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?
#2
ERRORES/BUGS / Re: Maybe wrong calculation of...
Last post by olwaldi - May 17, 2024, 03:35:47 PMThanks for the quick response. That explains my issues partly.
And I might add that restarting oruxmaps changes much: Now the waypoints are centered correctly. And the height gain/loss have different, more correct values. Probabely now oruxmaps uses different height data sources?
And I had a misunderstandig: of course the height loss ist NOT zero, but instead should be the same as the height gain (for a roundtrip).
Regards, Michael
And I might add that restarting oruxmaps changes much: Now the waypoints are centered correctly. And the height gain/loss have different, more correct values. Probabely now oruxmaps uses different height data sources?
And I had a misunderstandig: of course the height loss ist NOT zero, but instead should be the same as the height gain (for a roundtrip).
Regards, Michael
#3
GENERAL / Re: Résultats sur la carte lat...
Last post by Tronpo - May 17, 2024, 02:31:40 PMHello, that data is displayed while you are recording the route. It's live information
#4
ERRORES/BUGS / Re: Maybe wrong calculation of...
Last post by Tronpo - May 17, 2024, 02:24:23 PMHello, the planner data is given by the brouter / GraphHopper database, they are not from Oruxmaps, in my experience they are not reliable, (this has fix soon)
Once you have your route in the Oruxmaps database, do an altitude correction, with your DEM Confidence , you will see how you get more sensible data.
Regarding waypoints, when we mark a waypoint we don't always do it right on the route, Oruxmaps creates the waypoint where you have marked but the route line generates it at the nearest point existing in the planner database (brouter / GraphHopper).
I hope this helps you understand some of the anomalies you mention.
Once you have your route in the Oruxmaps database, do an altitude correction, with your DEM Confidence , you will see how you get more sensible data.
Regarding waypoints, when we mark a waypoint we don't always do it right on the route, Oruxmaps creates the waypoint where you have marked but the route line generates it at the nearest point existing in the planner database (brouter / GraphHopper).
I hope this helps you understand some of the anomalies you mention.
#5
ERRORES/BUGS / Maybe wrong calculation of hei...
Last post by olwaldi - May 17, 2024, 12:37:49 PMI've created a route with brouter using the recent oruxmaps 10.6.1 GP.
One can display route statistics - but I do not understand the meaning of height gain resp. loss. My route is a roundtrip, i.e. it starts and ends at the same location. Thus I'd expect to get a height loss of 0m - but oruxmaps reports 189m. Similar I mistrust the height gain - oruxmaps reports 164m, but qmapshacks calculates 380m.
Similar spurious: When I delete a waypoint during creation of my route the calculated max. height is at a wrong location/height.
Maybe also related: The tip of the waypoint icons do not end at the route but their circles seem to be centered at the route. But the automaticaly created km waypoints are rendered correct - i.e. their tips end at the route.
Please find enclosed my route as a sample.
Regards, Michael
One can display route statistics - but I do not understand the meaning of height gain resp. loss. My route is a roundtrip, i.e. it starts and ends at the same location. Thus I'd expect to get a height loss of 0m - but oruxmaps reports 189m. Similar I mistrust the height gain - oruxmaps reports 164m, but qmapshacks calculates 380m.
Similar spurious: When I delete a waypoint during creation of my route the calculated max. height is at a wrong location/height.
Maybe also related: The tip of the waypoint icons do not end at the route but their circles seem to be centered at the route. But the automaticaly created km waypoints are rendered correct - i.e. their tips end at the route.
Please find enclosed my route as a sample.
Regards, Michael
#6
MEJORAS/NEW FEATURES / Re: Bike radar plugin
Last post by matt - May 17, 2024, 06:58:40 AMInteresting, "Garmin Radar Data BLE Protocol and Documentation" seem to be available on request
https://developer.garmin.com/radar-data-ble/overview/
https://developer.garmin.com/radar-data-ble/overview/
#7
GENERAL / Résultats sur la carte latéral...
Last post by Guy85 - May 16, 2024, 08:21:43 PMBonsoir,
Pourquoi, je n'ai pas de résultats sur les statistiques de la carte latérale ?
Voir fichier joint:
Good evening,
Why don't I have results on the side map statistics?
See attached file:
Pourquoi, je n'ai pas de résultats sur les statistiques de la carte latérale ?
Voir fichier joint:
Good evening,
Why don't I have results on the side map statistics?
See attached file:
#8
BETAS / Re: New beta 10.6.x
Last post by Starfighter - May 16, 2024, 03:04:16 PMQuote 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
#9
MEJORAS/NEW FEATURES / Re: Bike radar plugin
Last post by Tronpo - May 16, 2024, 07:14:34 AMHello, I didn't know about garmin radar until I read your suggestion, I find it very interesting, to be able to link a peripheral of this type with Oruxmaps.
I would also be willing to pay. 👍
I would also be willing to pay. 👍
#10
MEJORAS/NEW FEATURES / Bike radar plugin
Last post by Fetnat - May 15, 2024, 09:26:40 PMHello,
I use Oruxmaps with great satisfaction on all my hikes and have done so for several years. I'd like to do the same for my bike rides, during which I use a Garmin varia radar for safety reasons. Would it be possible for you to create a paid plugin (5-10€) that displays the presence of cars in the same way as the Garmin bike gps?
With kind regards
I use Oruxmaps with great satisfaction on all my hikes and have done so for several years. I'd like to do the same for my bike rides, during which I use a Garmin varia radar for safety reasons. Would it be possible for you to create a paid plugin (5-10€) that displays the presence of cars in the same way as the Garmin bike gps?
With kind regards