Obtener coordenadas gps

Hola Comunidad,

después de montarle una estupenda aplicación para las tabletas de un cliente pasa lo de siempre: quieren más …

Me están pidiendo que envíe al servidor de la central la posición física de la tableta cada x tiempo. La tableta por supuesto tiene GPS, la cuestión es :

¿Alguien sabe cómo obtener las coordenadas de la posición de la tableta de forma automática ?

Saludos a todos

Reviviendo este tema.

Lo mismo pero desde Android, alguna idea?

Saludos.

@mibarra

muy buenas. No te sé decir exactamente cuál ni me voy a poner a buscarla por que hay que verse la lista entera pero existe una open app que hace esto para Android.

Saludos

Me parece que la open app que os dice apinna.winmotor es la siguiente: http://velneo.es/velneo-open-app/vtools4android/

Saludos

La open app es gratis, pero usa una app Android que si es de pago, y es 20,38 U$ por dispositivo, si no entendí mal.

El link en el playstore es:
https://play.google.com/store/apps/details?id=ascsl.vtools4android

Cualquier info adicional de este tema, por favor, comenten acá.

Alguna novedad en este tema en Velneo 7.17? En el mundo qt5, hace mucho que abundan las herramientas que permitirían hacer maravillas desde vDevelop, de forma nativa y transparente.

¿No era esto de mucho mas valor agregado que el manejo de la cámara, por poner un ejemplo? Está esto ya hecho, y si no lo está, al menos ya está previsto de incluirse? ¿O hay que agregar una idea de esto, para que sea considerado recién?

http://doc.qt.io/qt-5/qtpositioning-index.html
http://qt-project.org/quarterly/view/location_and_mapping_services

Este hilo es del 2013, y aun sigue sin tenerse respuesta oficial de Velneo.

Como desarrolladores, ¿tan pocos necesitan leer las coordenadas del dispositivo de forma nativa?
En el mundo empresarial (el mundo al que apuesta Velneo supuestamente), lo de manejar geo-localización ya es algo standard, no un agregado bonito. http://www.ciospain.es/industria-y-utilities/la-geolocalizacion-y-la-realidad-aumentada-crean-oportunidades-para-las-empresas

Existe QtPositioning, que ha sido portado totalmente hacia Android e iOS desde Qt 5.3.0, entonces ¿cual sería la excusa para que siga sin estar disponible en v7, si sabemos que la 7.17 está basada en Qt 5.3.2?

Por favor, les animo votar la idea, a ver si así podemos tener esto cuanto antes en v7, y no seguir con esta limitación inadmisible en tiempos actuales.
https://velneo.zendesk.com/entries/92989707-Obtener-coordenadas-GPS-desde-eventos-v7

Hola cjribera.

Con vClient Android en beta y el vclient de IOS en la incubadora, me imagino que leer la posicion gps de la Tablet desde Velneo será de las tareas menos urgentes a afrontar.

De todas maneras esta funcionalidad y otras referentes a periféricos y gadgets olvídate que se puedan hacer de forma nativa con Velneo, por lo menos a medio plazo tal como ya se adelantó en el LIS de 2014.

De momento habrá que probarlo con QML/JavaScript:

  • Tenemos la librería C/C++ disponible en Velneo -> Qt5Positioning.dll
  • Podemos importar los Tipos mediante -> import QtPositioning 5.2
  • No disponemos todavía de QtQuick 2.0 así que habrá que probar si funciona con QtQuick 1.1

Me imagino que los expertos en QML y los revendedores de aplicaciones Velneo estarán trabajando en esta y otras novedades de QT5. Espero ver pronto ejemplos de uso.

Saludos
Paco Satué

Hola Paco, gracias por la respuesta. Quisiera por favor consultar (a ti, a Velneo, o a quien sepa del tema) sobre un texto tuyo “De todas maneras esta funcionalidad y otras referentes a periféricos y gadgets olvídate que se puedan hacer de forma nativa con Velneo”.

Si con QtCreator, que es supuestamente una herramienta menos sofisticada que Velneo V7, se pueden hacer muchas de estas cosas sin necesidad de estar comprometiendo la seguridad a través de parches javascript (ver por ejemplo http://www.open-terrain.org/index.php/Pong/August18th2014QtCreatorAndAndroid ), ¿que es lo que hace que Velneo se incline tanto hacia javascript, ya no solo para cosas rebuscadas, sino también para características que deberían considerarse básicas (ya leer unas simples coordenadas, o copiar registros completos, en el caso de los tubos)?

Lo otro que quisera discutir, ¿será que manejar la cámara del movil era una caracteristica empresarialmente mas importante que leer las coordenadas?

Es decir, para la georeferencia se pueden encontrar cientos de aplicaciones funcionales, la realidad aumentada es basada en la georeferencia interactuando con las bases de datos, o tomar datos para un GIS, o simplemente rellenar campos de un registro de clientes, para luego tenerlo referenciado geográficamente.

Leer las coordenadas del movil es de las cosas mas básicas que se puedan pensar al operar un dispositivo móvil, y de las mas útiles también. Leer el GPS ya lo hacía Terrasync hace eones. Y acá, con una herramienta sofisticada, teniendo todo el desarrollo que hay en QT, y habiendo podido lograr operar nativamente la cámara del dispositivo, ¿será que lo tienen tan complicado leer las coordenadas, encapsulando el uso de qtPositioning hacia el usuario final?

Hola cjribera.

Te recomiendo encarecidamente que vuelvas a ver el video del LIS 2014 de Juan Muñoz Cobos. Con más de un año de perspectiva te quedas con una imagen más clara de lo que estamos hablando.

Yo saco la conclusión de que Velneo V7 no se va a usar para programar con las APIS’s de periféricos y gadgets de nuestro hardware. Como mucho se llegará a algo parecido al nuevo control TreeWidget, es decir, tendremos un objeto en Velneo y lo programaremos con el API y JavaScript. ¿Cuál es el motivo? Quizás se piensa que para qué vamos a crear un objeto V7 estático y muy encorsetado si tenemos toda la flexibilidad y dinamismo del API/JavaScript y QML.

El acceso a la Webcam en el control Imagen refleja muy bien este hecho, está bien pero claramente insuficiente. ¿Cómo controlas si tienes la cámara activa?¿Cómo seleccionas cámara frontal o trasera?¿Cómo gestionas el tamaño de la captura?¿Cómo accedes a los controles de la cámara: contraste, zoom, …? Me parece que todo esto necesita un API que se programa con JavaScript (QT5Multimedia.dll).

En definitiva, yo prefiero un API completo de acceso al GPS de la máquina, que tenga un montón de propiedades y métodos, para obtener mediante JavaScript cosas como el nivel de cobertura GPS, nº de satélites, precisión de medida, etc…, que disponer de una simple función Velneo que me devuelva las coordenadas del gps.

Y ¿Cuál es la solución? Pues está clarísimo. Ya lo hizo Microsoft con los componentes OCX/ActiveX. Las emnpresas expertas en QML deben proporcionarnos componentes que encapsulen toda la complejidad de las diferentes API’s. Ya tenemos buenos, aunque pocos ejemplos, como el TPV de VERP, plugins de bicodesoft, ¿…?

Esta es mi opinión personal ¿Alguién da más?.

Saludos
Paco Satué

Hola Paco
Todo muy bien para quien quiera mas complejidad, incluso hay algo mucho mas completo que Qt Positioning, llamado Qt Location http://doc.qt.io/qt-5/qtlocation-index.html, pero para algo tan simple, como obtener las coordenadas, ¿es lógico que se tenga que esperar tanto?

Hay hilos del 2010, este mismo hilo es del 2013, y el ejemplo que mostré en mi anterior mensaje es de qt Creator, no creo que no puedan utilizar eso y encapsularlo en una SIMPLE función nativa GET_COORDINATES o algo así.

Ya para lo otro, que lo hagan con javascript si quieren (no quiero mencionar otras herramientas acá, pero sin necesidad de javascript, se logra lo que dices Paco, a mi me parece mas una obsesión con javascript, y no consideran los hoyos de seguridad que se pueden abrir con tanto js), pero que por lo menos provean lo BÁSICO, porque si esperamos lo perfecto y flexible, nos puede agarrar el 2016 sin nada, ¿no crees?

Estando totalmente de acuerdo con Paco en cuanto al enfoque a seguir, respecto a la movilidad directa con Velneo actualmente hay que ser realista.
No cuentes con ella. Le queda mucho, y lo mejor es esperar y dejar de desear.
Cuándo esté, estará.
Lo que hay es una beta, y tardará tiempo en salir de ahí.
Tú planteas el gps, y yo resulta que te planteo por ejemplo, los sensores…y así hasta el final…

Usa herramientas nativas/híbridas, y comunícalas con Velneo; esa es la solución.
Que además con el escenario actual, te llevará mucho menos tiempo y dolores de cabeza.

Saludos.

+1 con velneoYellow,

Cada cosa para lo que es, en el apartado de movilidad la verdad yo no espero mucho Velneo y la verdad no debería, el mobile es otra cosa, los controles, transiciones, sensores y particularidades de cada plataforma exigen bastante y se necesita un entorno creado para ello; en v7 con el hecho que te puedas crear fácilmente una API con vModApache o Cirrus ya es mucho avance (se espera con ansias la clase vNetwork para cerrar el circulo) y están surgiendo cada vez más plataformas que hacen muy llevadero todo el tema del desarrollo mobile.

El vClient Android tiene su lugar siempre que las soluciones y despliegues tengan bien delimitado su alcance, pero para aplicaciones mas “normalitas” lo mejor es que el vServer sera simplemente el Back-End.

Un saludo,

Parece que no entienden que no se esta pidiendo algo recontra-complejo, sino algo que es DE LO MAS BASICO en un móvil, que es leer las coordenadas del GPS.

En el link que puse, lo hacen con QT Ctreator, ¿que impide a I+D de Velneo, tomar ese código http://www.open-terrain.org/index.php/Pong/August18th2014QtCreatorAndAndroid, y encapsularlo dentro de una función nativa?, , y eso lo hacían con Necessitas, supuestamente, desde Qt5.3 debería ser mas simple aún, ¿cual puede ser entonces la ‘insalvable’ complejidad?.

Y por si acaso, para leer otras cosas del dispositivo, ya habían opciones desde Qt 5.1, http://linuxgizmos.com/qt-5-1-arrives-with-qt-for-android-and-ios-previews “Qt 5.1 adds a Qt Sensors module that provides APIs for sensors including accelerometer, rotation, and gyroscope devices. The module initially supports the Android and iOS versions, as well as BlackBerry.”

Yo no veo por donde se tengan que invertir miles de horas de I+D, en características de tanto valor agregado, sinceramente, no le veo cual es el gran impedimento.