Re: [Talk-es] Traducción longitudes
El 18/04/12, Jose Luis Perez Diez escribió: > El Wednesday 18 April 2012 11:43:31 Jonay Santana va escriure: >> Voy a copiar algunas tramas más, junto con la longitud que la >> aplicación me dice que tiene el vehículo para ese momento preciso. >> Encontré uno en un garaje, que se movía poco, con lo que las >> longitudes son casi iguales (a veces incluso lo son, pero no así el >> dato que el vehículo mandó). >> >> 01 D0304205E00F73E2F77A192A5B001A88 -> 2012.01.01-00.23.32 = NO ESTÁ > >>14 D0304206600F71E9F779BC3473001A89 -> 2012.01.01-00.25.32 = NO ESTÁ >>15 D0304206200F72DFF77A383755001A88 -> 2012.01.01-00.24.32 = -15º25’56.1” > > > ¿que datos deduce la aplicacion del stream? En la base de datos se almacenan montones: + Identificador del vehículo (número entero) + Identificador de la flota + Timestamp + Latitud + Longitud + Velocidad + Kilómetros recorridos + Rumbo + Causa del registro (número entero) + Nivel de la batería (aunque no se muestra en la aplicación). + Satélites visibles / satélites usados + Niveles de temperatura Luego hay un par de campos más que no sé qué son, y casi siempre están a cero o a nulo. Yo he descifrado la latitud (en las posiciones 10 a 15), la velocidad (en las posiciones 22 a 23), y los kilómetros recorridos (30 y 31). > (los bits 6:8 y 9:11 son compatibles con las cordenadas que te puede dar un > vehiculo > terrestre dos lecturas seguidas no se han de diferenciar en mas de un valor > de 11 bits) Esta parte no la he entendido... :( -- Jonay ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
El Wednesday 18 April 2012 11:43:31 Jonay Santana va escriure: > Voy a copiar algunas tramas más, junto con la longitud que la > aplicación me dice que tiene el vehículo para ese momento preciso. > Encontré uno en un garaje, que se movía poco, con lo que las > longitudes son casi iguales (a veces incluso lo son, pero no así el > dato que el vehículo mandó). > > 01 D0304205E00F73E2F77A192A5B001A88 -> 2012.01.01-00.23.32 = NO ESTÁ >14 D0304206600F71E9F779BC3473001A89 -> 2012.01.01-00.25.32 = NO ESTÁ >15 D0304206200F72DFF77A383755001A88 -> 2012.01.01-00.24.32 = -15º25’56.1” ¿que datos deduce la aplicacion del stream? seria interesante que tene un trozo del stream de unas horas (tal como llega al servidor) integro con la latitud i longitud observada ya por los datos que envias parece que el sistema datos cada 60 segundos (aunque en le flujo nada parece indicar un timestamp en segundos ) ya que la unica parte que se incrementa constantemente lo hace de 0x40 (64) (los bits 6:8 y 9:11 son compatibles con las cordenadas que te puede dar un vehiculo terrestre dos lecturas seguidas no se han de diferenciar en mas de un valor de 11 bits) ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
Pues "podando", la información de la longitud ha de estar en los caracteres que no son X: D030XX0FAXXXF70B03XX ¿Cómo lo sé? Lanzando una consulta en la base de datos que almacena las posiciones, y buscando todas las que compartían longitud. Luego cotejé esa información con lo que enviaron los vehículos en ese instante, obtuve varias tramas, y con X enmascaré todo lo que no era igual. Rudimentario, cierto, pero creo que correcto. Vamos a ver si encontramos el dichoso árbol... :D El 18/04/12, Benjamín Valero Espinosa escribió: > El 18 de abril de 2012 11:43, Jonay Santana > escribió: > >> Uf, 47.9 segundos son demasiados metros de error donde me encuentro... >> >> Voy a copiar algunas tramas más, junto con la longitud que la >> aplicación me dice que tiene el vehículo para ese momento preciso. >> Encontré uno en un garaje, que se movía poco, con lo que las >> longitudes son casi iguales (a veces incluso lo son, pero no así el >> dato que el vehículo mandó). >> >> 01 D0304205E00F73E2F77A192A5B001A88 -> 2012.01.01-00.23.32 = NO ESTÁ >> 02 D0304205A00F748CF77A8B2B6D001A87 -> 2012.01.01-00.22.32 = -15º25’53.3” >> 03 D0304205600F7562F77AB2326B001A86 -> 2012.01.01-00.21.32 = NO ESTÁ >> 04 D0304205200F7588F77B924B8D001A86 -> 2012.01.01-00.20.32 = -15º25’56.3” >> 05 D0304204E00F7514F77D76509D001A84 -> 2012.01.01-00.19.32 = NO ESTÁ >> 06 D0304204A00F7471F77F03507A001A83 -> 2012.01.01-00.18.32 = -15º25’56.3” >> 07 D0304204600F7374F78067539D001A82 -> 2012.01.01-00.17.32 = NO ESTÁ >> 08 D0304204200F736AF782234A80001A80 -> 2012.01.01-00.16.32 = -15º25’56.3” >> 09 D0304203E00F7351F783E94988001A7F -> 2012.01.01-00.15.32 = NO ESTÁ >> 10 AF304203A00F738FF785A6351A7E -> 2012.01.01-00.14.32 = -15º25’56.5” >> 11 D0304203600F733CF7867D4DA3001A7D -> 2012.01.01-00.13.32 = NO ESTÁ >> 12 D0304203200F71E2F787B050A3001A7C -> 2012.01.01-00.12.32 = -15º25’56.5” >> 13 D0304202E00F7055F752A8001A7B -> 2012.01.01-00.11.32 = NO ESTÁ >> 14 D0304202A00F6EA6F788985208001A79 -> 2012.01.01-00.10.32 = -15º25’56.3” >> 15 D0304202600F6D28F7880E4CAF001A78 -> 2012.01.01-00.09.32 = NO ESTÁ >> 01 D030420A600F70ABF77B922127001A8D -> 2012.01.01-00.41.32 = NO ESTÁ >> 02 D030420A200F7134F77B382911001A8C -> 2012.01.01-00.40.32 = -15º25’56.3” >> 03 D0304209E00F7127F77AD81301001A8C -> 2012.01.01-00.39.32 = NO ESTÁ >> 04 D0304209A00F712CF77A8E1A41001A8B -> 2012.01.01-00.38.32 = -15º25’56.5” >> 05 D0304209600F716DF77A00193A001A8B -> 2012.01.01-00.37.32 = NO ESTÁ >> 06 D0304209200F71C4F779872B22001A8B -> 2012.01.01-00.36.32 = -15º25’56.3” >> 07 D0304208E00F71C4F778E81D5D001A8A -> 2012.01.01-00.35.32 = NO ESTÁ >> 08 D0304208A00F71D1F7791C0C9A001A8A -> 2012.01.01-00.34.32 = -15º25’56.6” >> 09 D0304208600F71D1F7793F0051001A8A -> 2012.01.01-00.33.32 = NO ESTÁ >> 10 D0304207E00F71CFF7793F0046001A8A -> 2012.01.01-00.31.32 = NO ESTÁ >> 11 D0304207600F71D0F7793F0044001A8A -> 2012.01.01-00.29.32 = NO ESTÁ >> 12 D0304206E00F71D1F779400042001A8A -> 2012.01.01-00.27.32 = NO ESTÁ >> 13 D0304206A00F71E3F7794B0060001A8A -> 2012.01.01-00.26.32 = -15º25’56.1” >> 14 D0304206600F71E9F779BC3473001A89 -> 2012.01.01-00.25.32 = NO ESTÁ >> 15 D0304206200F72DFF77A383755001A88 -> 2012.01.01-00.24.32 = -15º25’56.1” >> >> Me ha llamado la atención que la aplicación desecha posiciones que >> el vehículo sí que ha mandado (son las que he puesto como NO ESTÁ, >> cosa que desconocía. >> > > ¿Y el resto de datos sí los tienes relacionados y contrastados en varias > tramas (kilometrajes, hora, velocidad, latitud...)? Quizá dejando sólo los > "bits" que aún no sabes a qué se corresponden (que serán pocos ya), se vea > (lo veamos) más fácilmente. Las tramas a bote pronto tienen pinta de estar > ordenadas en varios sitios (los dos últimos bytes, y los de las posiciones > 13-14), no sé si por casualidad o por algo en especial, porque con las > horas no se corresponden. Quizá quitando algo de bosque podamos ver el > árbol ;) > -- Jonay ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
El 18 de abril de 2012 11:43, Jonay Santana escribió: > Uf, 47.9 segundos son demasiados metros de error donde me encuentro... > > Voy a copiar algunas tramas más, junto con la longitud que la > aplicación me dice que tiene el vehículo para ese momento preciso. > Encontré uno en un garaje, que se movía poco, con lo que las > longitudes son casi iguales (a veces incluso lo son, pero no así el > dato que el vehículo mandó). > > 01 D0304205E00F73E2F77A192A5B001A88 -> 2012.01.01-00.23.32 = NO ESTÁ > 02 D0304205A00F748CF77A8B2B6D001A87 -> 2012.01.01-00.22.32 = -15º25’53.3” > 03 D0304205600F7562F77AB2326B001A86 -> 2012.01.01-00.21.32 = NO ESTÁ > 04 D0304205200F7588F77B924B8D001A86 -> 2012.01.01-00.20.32 = -15º25’56.3” > 05 D0304204E00F7514F77D76509D001A84 -> 2012.01.01-00.19.32 = NO ESTÁ > 06 D0304204A00F7471F77F03507A001A83 -> 2012.01.01-00.18.32 = -15º25’56.3” > 07 D0304204600F7374F78067539D001A82 -> 2012.01.01-00.17.32 = NO ESTÁ > 08 D0304204200F736AF782234A80001A80 -> 2012.01.01-00.16.32 = -15º25’56.3” > 09 D0304203E00F7351F783E94988001A7F -> 2012.01.01-00.15.32 = NO ESTÁ > 10 AF304203A00F738FF785A6351A7E -> 2012.01.01-00.14.32 = -15º25’56.5” > 11 D0304203600F733CF7867D4DA3001A7D -> 2012.01.01-00.13.32 = NO ESTÁ > 12 D0304203200F71E2F787B050A3001A7C -> 2012.01.01-00.12.32 = -15º25’56.5” > 13 D0304202E00F7055F752A8001A7B -> 2012.01.01-00.11.32 = NO ESTÁ > 14 D0304202A00F6EA6F788985208001A79 -> 2012.01.01-00.10.32 = -15º25’56.3” > 15 D0304202600F6D28F7880E4CAF001A78 -> 2012.01.01-00.09.32 = NO ESTÁ > 01 D030420A600F70ABF77B922127001A8D -> 2012.01.01-00.41.32 = NO ESTÁ > 02 D030420A200F7134F77B382911001A8C -> 2012.01.01-00.40.32 = -15º25’56.3” > 03 D0304209E00F7127F77AD81301001A8C -> 2012.01.01-00.39.32 = NO ESTÁ > 04 D0304209A00F712CF77A8E1A41001A8B -> 2012.01.01-00.38.32 = -15º25’56.5” > 05 D0304209600F716DF77A00193A001A8B -> 2012.01.01-00.37.32 = NO ESTÁ > 06 D0304209200F71C4F779872B22001A8B -> 2012.01.01-00.36.32 = -15º25’56.3” > 07 D0304208E00F71C4F778E81D5D001A8A -> 2012.01.01-00.35.32 = NO ESTÁ > 08 D0304208A00F71D1F7791C0C9A001A8A -> 2012.01.01-00.34.32 = -15º25’56.6” > 09 D0304208600F71D1F7793F0051001A8A -> 2012.01.01-00.33.32 = NO ESTÁ > 10 D0304207E00F71CFF7793F0046001A8A -> 2012.01.01-00.31.32 = NO ESTÁ > 11 D0304207600F71D0F7793F0044001A8A -> 2012.01.01-00.29.32 = NO ESTÁ > 12 D0304206E00F71D1F779400042001A8A -> 2012.01.01-00.27.32 = NO ESTÁ > 13 D0304206A00F71E3F7794B0060001A8A -> 2012.01.01-00.26.32 = -15º25’56.1” > 14 D0304206600F71E9F779BC3473001A89 -> 2012.01.01-00.25.32 = NO ESTÁ > 15 D0304206200F72DFF77A383755001A88 -> 2012.01.01-00.24.32 = -15º25’56.1” > > Me ha llamado la atención que la aplicación desecha posiciones que > el vehículo sí que ha mandado (son las que he puesto como NO ESTÁ, > cosa que desconocía. > ¿Y el resto de datos sí los tienes relacionados y contrastados en varias tramas (kilometrajes, hora, velocidad, latitud...)? Quizá dejando sólo los "bits" que aún no sabes a qué se corresponden (que serán pocos ya), se vea (lo veamos) más fácilmente. Las tramas a bote pronto tienen pinta de estar ordenadas en varios sitios (los dos últimos bytes, y los de las posiciones 13-14), no sé si por casualidad o por algo en especial, porque con las horas no se corresponden. Quizá quitando algo de bosque podamos ver el árbol ;) ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
Uf, 47.9 segundos son demasiados metros de error donde me encuentro... Voy a copiar algunas tramas más, junto con la longitud que la aplicación me dice que tiene el vehículo para ese momento preciso. Encontré uno en un garaje, que se movía poco, con lo que las longitudes son casi iguales (a veces incluso lo son, pero no así el dato que el vehículo mandó). 01 D0304205E00F73E2F77A192A5B001A88 -> 2012.01.01-00.23.32 = NO ESTÁ 02 D0304205A00F748CF77A8B2B6D001A87 -> 2012.01.01-00.22.32 = -15º25’53.3” 03 D0304205600F7562F77AB2326B001A86 -> 2012.01.01-00.21.32 = NO ESTÁ 04 D0304205200F7588F77B924B8D001A86 -> 2012.01.01-00.20.32 = -15º25’56.3” 05 D0304204E00F7514F77D76509D001A84 -> 2012.01.01-00.19.32 = NO ESTÁ 06 D0304204A00F7471F77F03507A001A83 -> 2012.01.01-00.18.32 = -15º25’56.3” 07 D0304204600F7374F78067539D001A82 -> 2012.01.01-00.17.32 = NO ESTÁ 08 D0304204200F736AF782234A80001A80 -> 2012.01.01-00.16.32 = -15º25’56.3” 09 D0304203E00F7351F783E94988001A7F -> 2012.01.01-00.15.32 = NO ESTÁ 10 AF304203A00F738FF785A6351A7E -> 2012.01.01-00.14.32 = -15º25’56.5” 11 D0304203600F733CF7867D4DA3001A7D -> 2012.01.01-00.13.32 = NO ESTÁ 12 D0304203200F71E2F787B050A3001A7C -> 2012.01.01-00.12.32 = -15º25’56.5” 13 D0304202E00F7055F752A8001A7B -> 2012.01.01-00.11.32 = NO ESTÁ 14 D0304202A00F6EA6F788985208001A79 -> 2012.01.01-00.10.32 = -15º25’56.3” 15 D0304202600F6D28F7880E4CAF001A78 -> 2012.01.01-00.09.32 = NO ESTÁ 01 D030420A600F70ABF77B922127001A8D -> 2012.01.01-00.41.32 = NO ESTÁ 02 D030420A200F7134F77B382911001A8C -> 2012.01.01-00.40.32 = -15º25’56.3” 03 D0304209E00F7127F77AD81301001A8C -> 2012.01.01-00.39.32 = NO ESTÁ 04 D0304209A00F712CF77A8E1A41001A8B -> 2012.01.01-00.38.32 = -15º25’56.5” 05 D0304209600F716DF77A00193A001A8B -> 2012.01.01-00.37.32 = NO ESTÁ 06 D0304209200F71C4F779872B22001A8B -> 2012.01.01-00.36.32 = -15º25’56.3” 07 D0304208E00F71C4F778E81D5D001A8A -> 2012.01.01-00.35.32 = NO ESTÁ 08 D0304208A00F71D1F7791C0C9A001A8A -> 2012.01.01-00.34.32 = -15º25’56.6” 09 D0304208600F71D1F7793F0051001A8A -> 2012.01.01-00.33.32 = NO ESTÁ 10 D0304207E00F71CFF7793F0046001A8A -> 2012.01.01-00.31.32 = NO ESTÁ 11 D0304207600F71D0F7793F0044001A8A -> 2012.01.01-00.29.32 = NO ESTÁ 12 D0304206E00F71D1F779400042001A8A -> 2012.01.01-00.27.32 = NO ESTÁ 13 D0304206A00F71E3F7794B0060001A8A -> 2012.01.01-00.26.32 = -15º25’56.1” 14 D0304206600F71E9F779BC3473001A89 -> 2012.01.01-00.25.32 = NO ESTÁ 15 D0304206200F72DFF77A383755001A88 -> 2012.01.01-00.24.32 = -15º25’56.1” Me ha llamado la atención que la aplicación desecha posiciones que el vehículo sí que ha mandado (son las que he puesto como NO ESTÁ, cosa que desconocía. Voy a seguir investigando, si a alguien se le ocurre algo, le estaré eternamente agradecido. :) El 18/04/12, Maria Arias de Reyna escribió: > El Martes, 17 de abril de 2012, Rafael Avila Coya escribió: >> En 17/04/12 20:09, Iván Sánchez Ortega escribiu: >> > On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió: >> >> D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6” >> >> D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8” >> >> D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5” >> >> D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0” >> >> D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8” >> > >> > [...] >> > >> >> El 0 que tiene inmediatamente a la izquierda de los corchetes *creo* >> >> que puede indicar el signo, para latitudes N sería 0, y para latitudes >> >> S sería F. >> > >> > Eso se llama complemento a 2 en binario, el 0 o la F es parte del número >> > (el número son 6 caracteres hexadecimales, no 5). >> > >> >> Así asumí que la longitud estaría entre las llaves: >> >> D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del >> >> signo sí tendría sentido, la F anterior sería el menos, pero el 787AF >> >> no es la longitud, al menos no sin transformarla de alguna manera que >> >> aún no pillo. >> > >> > Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra. >> >> Uy, por poco... >> >> 1024*1024-hex2dec(0x787af) = 555089, pero >> 15º 25’ 56.8” = 68 décimas de segundo... >> >> Una diferencia de 47.9 segundos :-/ > > > No descartes que eso sea un error de redondeo en alguna parte del > decodificador > que está usando el programa. > > -- > María Arias de Reyna Domínguez > Área de Operaciones > > Emergya Consultoría > Tfno: +34 954 51 75 77 / +34 607 43 74 27 > Fax: +34 954 51 64 73 > www.emergya.com > > ___ > Talk-es mailing list > Talk-es@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-es > -- Jonay ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
El Martes, 17 de abril de 2012, Rafael Avila Coya escribió: > En 17/04/12 20:09, Iván Sánchez Ortega escribiu: > > On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió: > >> D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6” > >> D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8” > >> D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5” > >> D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0” > >> D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8” > > > > [...] > > > >> El 0 que tiene inmediatamente a la izquierda de los corchetes *creo* > >> que puede indicar el signo, para latitudes N sería 0, y para latitudes > >> S sería F. > > > > Eso se llama complemento a 2 en binario, el 0 o la F es parte del número > > (el número son 6 caracteres hexadecimales, no 5). > > > >> Así asumí que la longitud estaría entre las llaves: > >> D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del > >> signo sí tendría sentido, la F anterior sería el menos, pero el 787AF > >> no es la longitud, al menos no sin transformarla de alguna manera que > >> aún no pillo. > > > > Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra. > > Uy, por poco... > > 1024*1024-hex2dec(0x787af) = 555089, pero > 15º 25’ 56.8” = 68 décimas de segundo... > > Una diferencia de 47.9 segundos :-/ No descartes que eso sea un error de redondeo en alguna parte del decodificador que está usando el programa. -- María Arias de Reyna Domínguez Área de Operaciones Emergya Consultoría Tfno: +34 954 51 75 77 / +34 607 43 74 27 Fax: +34 954 51 64 73 www.emergya.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
El 17 de abril de 2012 19:41, Jonay Santana escribió: > Mucha razón, perdón por no haber puesto algo obvio. Ahí van las > tramas con sus longitudes: > > D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8” > D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8” > Si no te has equivocado, estas dos tramas deberían coincidir en alguna parte, suponiendo que la longitud "hexadecimal" esté expresada a nivel de décimas de segundo como en la latitud. Lo único que coincide es el F787, que no nos sirve porque también coincide en otros valores distintos :S Uff, incluso estoy mirando en binario por si el "corte" estuviera en medio de algún hexadecimal, pero ni por esas. Si tienes suficientes datos y ganas, yo lo haría a lo bestia pasándolo todo a binario y comparando los que sabes que coinciden, pero aún así puede ser engañoso, porque lo mismo las dos del ejemplo realmente son 56,77'' y 56,82'' :( ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 En 17/04/12 20:09, Iván Sánchez Ortega escribiu: > On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió: >> D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6” >> D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8” >> D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5” >> D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0” >> D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8” > [...] >> El 0 que tiene inmediatamente a la izquierda de los corchetes *creo* >> que puede indicar el signo, para latitudes N sería 0, y para latitudes >> S sería F. > > Eso se llama complemento a 2 en binario, el 0 o la F es parte del número (el > número son 6 caracteres hexadecimales, no 5). > >> Así asumí que la longitud estaría entre las llaves: >> D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del >> signo sí tendría sentido, la F anterior sería el menos, pero el 787AF >> no es la longitud, al menos no sin transformarla de alguna manera que >> aún no pillo. > > Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra. > > Uy, por poco... 1024*1024-hex2dec(0x787af) = 555089, pero 15º 25’ 56.8” = 68 décimas de segundo... Una diferencia de 47.9 segundos :-/ - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPjeFiAAoJEB3niTly2pPQlDMQAIbmHwv/34e+SWAX+lELwDYr LncC068j3AxM+Y5QzNzZVuG6IlUS4augjXRjefue/0aCATgJJK0YWrO0En2xRLj7 p7yYzlWSnpCWj3QB2YFTIYThaYqBQGmCZwW+BXg4lTv4sHt+GHstgJvjb7AeGdW8 hHA/xUouOuvGy68jH7vQNSCW1Syu516fVSGwEgKegUKUDZsmX5gIop/asLwOLye8 uohu64tD2rRvmsxlj55cdLU0vS1udJM0DXzNfjZnNaafBDs4zGc12vfPcsGiXGQc EVKuISUi2wP2NZnhZShA1mnFwApTw2FdIpJMMNRnIPB41c1SKv5LZT3lh9XIk3rE zTbNyGqkdcNPCBQMeupyFZbRhK3jAvPnzu7Qpijq4Whso0sDZ5ohtd1z7SzVsYma K3veesTP0UIyEm79VeMsj4QCQv5JGut4TggKE/sfOObr2We8IJIlK66gq92GhYF7 ITpKd5G7kG/HGZ98DTkb8S2MJK3YrS0eoDsUzjqFueFz4h6gKNvn8RHon8m13DdS FWeL5V6b4Yy5lc0GbR7b3uxUCCq64/wMlEG4lx27Z0uUSevKkMl9qBp4ODQRiIMZ DJkM89K6Er46MyIbYqK6r+N8xC17lzDjBywkOcW4TglZhyycLIY+MBaINKy3Syea 53fUwK4Qc1+fC7uKL6kd =NhPW -END PGP SIGNATURE- ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
On Martes, 17 de abril de 2012 19:41:38 Jonay Santana escribió: > D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6” > D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8” > D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5” > D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0” > D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8” [...] > El 0 que tiene inmediatamente a la izquierda de los corchetes *creo* > que puede indicar el signo, para latitudes N sería 0, y para latitudes > S sería F. Eso se llama complemento a 2 en binario, el 0 o la F es parte del número (el número son 6 caracteres hexadecimales, no 5). > Así asumí que la longitud estaría entre las llaves: > D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del > signo sí tendría sentido, la F anterior sería el menos, pero el 787AF > no es la longitud, al menos no sin transformarla de alguna manera que > aún no pillo. Prueba 1024*1024-hex2dec(0x787af), a ver si te cuadra. -- -- Iván Sánchez Ortega The more you tighten your grip, Tarkin, the more star systems will slip through your fingers. -- Princess Leia ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
El Tuesday día 17 de April de 2012, a las 13:48:36 +0100, Jonay Santana escribió: > las longitudes se me atraviesan. > Aquí van un par de dichas tramas: > > Trama 01: D0304202200F6BA1*F7880A*4A0E001A77 > Trama 02 D0304201E00F6A2F*F7878A*4007001A76 > Trama 03 D0304201A00F699E*F787B0*008A001A75 > Trama 04 D0304201200F699C*F787AE*006D001A75 > Trama 05 D0304200A00F699B*F787B2*0061001A75 > Trama 06 D0304200200F699F*F787AF*0057001A75 > En primer lugar, decir que tú sí que sabes divertirte, hacer ingeniería inversa de un protocolo o formato que a todas luces parece "mejorable" ;-) Yo no puedo decir mucho, sólo dos cosas: 1. Parece que el texto entre asteriscos es hexadecimal, por lo tanto, cuatro bits por carácter, por lo tanto, máximo de 24 bits para representar la longitud, que tiene un rango de escala de 360 grados, o 180 grados positivos, y otros tantos negativos. Con 24 bits puedes codificar máximo 2^24 combinaciones, de tal manera que la precisión máxima que teóricamente puedes obtener será de 360/16777216 = 0.077 segundos de grado. O pasado a metros, 4*1000/16777216 = 2.4 metros. Esa información puede ser de utilidad para deducir qué significa un valor. 2. ¿Existe la posibilidad, o tienes ya, datos contrastados de ubicación de algún vehículo junto con su trama asociada? Es decir, que para un vehículo tengas a la vez tramas indescifrables, y una posición GPS fiable, al menos, en un rango de unos 100 metros, debería ser suficiente. Si hay una ubicación fija conocida (parking de una base de operaciones) o similar puedes obtener esos datos sin necesidad de ayuda de terceros. 3. Abundando en lo anterior, lo ideal sería tener posiciones verificables con coordenadas GPS para puntos a igual latitud y longitudes distintas. Si sabes de algún trayecto y pasa por una carretera totalmente norte-sur, podrías valerte de esa información aún sin posiciones GPS válidas, gracias a la velocidad y la marca de tiempo. En cualquier caso, habría que colgar a quien diseñó el sistema del palo mayor, porque estas cosas se documentan. Salvo, claro está, que se diseñara con la intención de tener al cliente cogido por los interfaces. Un saludo. -- José Luis Domingo López Linux Registered User #189436 Linux Kubuntu 11.10 (Linux 3.0.0-17-generic-pae) signature.asc Description: Digital signature ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
El 17/04/12, Rafael Avila Coya escribió: > -BEGIN PGP SIGNED MESSAGE- > Quizá sería interesante que pusieses la longitud de cada trama, para así > poder discurrir cual es la forma de codificar la longitud que tiene ese > sistema. Es decir, poner algo así como: > > F7880A = 18,45678 grados N > F7878A = 23,43269 grados S > etc. > Rafa Ávila. Mucha razón, perdón por no haber puesto algo obvio. Ahí van las tramas con sus longitudes: D0304202200F6BA1F7880A4A0E001A77 = -15º 25’ 56.6” D0304201A00F699EF787B0008A001A75 = -15º 25’ 56.8” D0304201200F699CF787AE006D001A75 = -15º 25’ 56.5” D0304200A00F699BF787B20061001A75 = -15º 25’ 56.0” D0304200200F699FF787AF0057001A75 = -15º 25’ 56.8” Como decía antes, la latitud la ubiqué rápidamente, en una trama normal estaría entre los corchetes, tal que así: D0304200200[F699F]F787AF0057001A75 -> F699F = 1010079 décimas de segundo, que concuerda exactamente con la latitud que sé que tenía el vehículo. El 0 que tiene inmediatamente a la izquierda de los corchetes *creo* que puede indicar el signo, para latitudes N sería 0, y para latitudes S sería F. Así asumí que la longitud estaría entre las llaves: D0304200200F699FF{787AF}0057001A75, pero no cuadra ni de broma. Lo del signo sí tendría sentido, la F anterior sería el menos, pero el 787AF no es la longitud, al menos no sin transformarla de alguna manera que aún no pillo. A ver si alguien en la lista me ilumina... Muchas gracias aunque sea por intentarlo. -- Jonay ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Quizá sería interesante que pusieses la longitud de cada trama, para así poder discurrir cual es la forma de codificar la longitud que tiene ese sistema. Es decir, poner algo así como: F7880A = 18,45678 grados N F7878A = 23,43269 grados S etc. Rafa Ávila. En 17/04/12 16:14, Jonay Santana escribiu: > -- Forwarded message -- > From: Jonay Santana > Date: Tue, 17 Apr 2012 15:14:26 +0100 > Subject: Re: [Talk-es] Traducción longitudes > To: Maria Arias de Reyna > > El 17/04/12, Maria Arias de Reyna escribió: >> >> Veamos, ¿de dónde salen esas tramas? > > Eso es lo que recibe el servidor que almacena los datos de posición > de los vehículos. > >> ¿Es de un GPS? ¿Es del sistema de >> gestión >> de flotas? > > Pues sí, y también, sí. Lo envían los vehículos, y lo recibe el servidor. > >> ¿Qué documentación tiene? > > Ninguna, ese es el problema. > >> ¿No te referencia ningún formato >> concreto? > > Nada de nada. Sin documentación me tengo que dejar los ojos para > sacarlo por mí mismo. > >> ¿Por qué sabes que la longitud tiene que estar ahí? > > Porque sí puedo ver la latitud y la longitud en otra aplicación, y > cotejando esta que se muestra con lo que el servidor recibe, tengo que > descifrar lo que mandan los vehículos. He mirado todos los coches con > la misma longitud, he comparado las tramas para esos instantes, y los > únicos campos que no cambian son los que destaqué. > >> ¿No será que has >> descifrado alguna otra cosa mal? > > Hombre, puede ser, pero estoy bastante seguro de que lo poco que > tengo, lo tengo bien. He comprobado bastantes posiciones y concuerdan > a la perfección. La que se me atraviesa es la longitud... > > - -- - Por favor, non me envíe documentos con extensións .doc, .docx, .xls, .xlsx, .ppt, .pptx, aínda podendoo facer, non os abro. Atendendo á lexislación vixente, empregue formatos estándares e abertos. http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJPjZ7TAAoJEB3niTly2pPQwYEQAIepnyY1LrhKZzLBZaGZyC9j Ya0lZsHmslO8YPhhTx7q49jyNN0sqTNUpWq5DHsUwuYEf9Tn99bMHel0x6w5B9vS h2eNqUfiU2mL1KV7KhFkmeQLkwEuReV5d6QsepMvoZBKUq/ApvUwjom9t+ASHwK+ zftjncSKAqhXzIP4+aUI3GDo9Uzey1/yGz6p/+H/SLNoj1jV00MWeNZRGKqcPxmr wOWLh8vqFDWo+5dVEZxUCBemQoh4X4Lkw7JxPRrGIL7Hn7x25gJkzsYT7QC45zlA SaC/GKJ1cngtMftSoEwnB0yrJECMLgWvcye19mc0NZtyEL+KPGdtD880nOYxDDcM FwfNbHCUL67Bep6j6yrgbaH2BOtVe5fV1Xg5FeUjCoOa+sDpYAYjcKsIB7fta+OP BC0l7sFc+UJMqFA1qMSbH8wImcfSqAeaO82x6ylXqwFw0KsKKMetMHgRdUcs1AFx Hj1eXftL+JrcYenOQPGRhnrM3DooTd1i4PxfXwHJ76TksTLm+4DM9WeIsBKuv4by l/BBqGA7aoYSDFOjQCzF3p6+b3STwtleBZi7Bi7aPlZQTpwfHp7kcA3nB0pbh+Jq fJiLaoOWilWSSchM3O8XXiG8zgIq0cW7eoFL9vhV8DjQ8FsfYnAqOLP/WIEsAY3C yCP3956VlkFTCnkcfGwX =dXYc -END PGP SIGNATURE- ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Traducción longitudes
El Martes, 17 de abril de 2012, Jonay Santana escribió: > Buenos días a todos. Recurro a la inteligencia colectiva de la > lista, a ver si me pueden echar un cabo, porque lo que es la > inteligencia individual de un servidor no da para mucho más. ;) > > A lo que vamos, estoy trabajando en un sistema de gestión de flotas > que va actualizando posiciones de vehículos en un mapa, y los equipos > envían su posición, velocidad, etc. en un formato de trama fijo. > Aunque he "descifrado" parámetros como kilometrajes, velocidades, y > latitudes, las longitudes se me atraviesan. > > Aquí van un par de dichas tramas: > > Trama 01: D0304202200F6BA1*F7880A*4A0E001A77 > Trama 02 D0304201E00F6A2F*F7878A*4007001A76 > Trama 03 D0304201A00F699E*F787B0*008A001A75 > Trama 04 D0304201200F699C*F787AE*006D001A75 > Trama 05 D0304200A00F699B*F787B2*0061001A75 > Trama 06 D0304200200F699F*F787AF*0057001A75 > > Tengo claro que la longitud tiene que estar por narices en las > posiciones que he destacado entre los asteriscos, pero no le veo > lógica ninguna. Las latitudes simplemente estaban en décimas se > segundo, pasadas a hexadecimal, e incrustadas en las tramas, pero las > longitudes no me cuadran. > > ¿Alguna sugerencia? Agradecido que quedo de antemano... Veamos, ¿de dónde salen esas tramas? ¿Es de un GPS? ¿Es del sistema de gestión de flotas? ¿Qué documentación tiene? ¿No te referencia ningún formato concreto? ¿Por qué sabes que la longitud tiene que estar ahí? ¿No será que has descifrado alguna otra cosa mal? -- María Arias de Reyna Domínguez Área de Operaciones Emergya Consultoría Tfno: +34 954 51 75 77 / +34 607 43 74 27 Fax: +34 954 51 64 73 www.emergya.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es