Hola de nuevo, si quieres puedes ver en https://github.com/aarranz/cat2osm/commit/19c894041c4e43b6164c94381ecd600e880845d3 una primera aproximación para usar geotools para transformar las coordenadas de los shapes usando geotools. De todas formas... tengo una mala noticia, según mis pruebas se sigue generando un fichero osm con el desplazamiento de 2-5, así que de momento usar geotools para transformar las coordenadas no aporta ningún avance en este sentido :(.
Un saludo. P.D. En el proyecto eclipse tendrás que asegurarte de que se usan los jar gt-referencing, gt-epsg-wkt, y otros que ahora mismo no sé decirte exactamente, pero vamos, todos son de geotools. El 18 de noviembre de 2011 13:13, Álvaro Arranz García < alvaro.arr...@gmail.com> escribió: > Hola de nuevo, > > hoy no es mi día ^^, nueva metedura de pata ^^. > > Evidentemente para usarlo en cat2osm, que está en java, sería utilizar las > funciones de geotools para transformación de coordenadas. > > Un saludo. > > > > On 18/11/11 12:58, Álvaro Arranz García wrote: > > Me equivoque de librería la que quería indicar es PROJ.4 [ > http://trac.osgeo.org/proj/]. > > Un saludo. > > On 18/11/11 12:53, Álvaro Arranz García wrote: > > Primero, un hola a todos ^^ (dado que este es el primer correo que mando a > la lista). > > Ya yendo al tema. La verdad es que no tengo muchos conocimientos de como > se relacionan los datos de los fichero shape y los ficheros .cat, pero una > posible opción sería usar *proj4j*[1]. El inconveniente es que habría que > usar las funciones de proj4j para traducir las coordenadas una a una. Esto > podría ser una ventaja si algunas de las coordenadas de los .cat/.shp están > en una proyección diferente de las que se usan generalmente dentro de estos > ficheros (la verdad es que esto es parte de lo que no controlo, pero tengo > entendido que en los cat se indica en que proyección están algunas > coordenadas, pero no sé si tiene sentido que al bajarte los datos de un > municipio se indiquen sistemas de coordenadas diferentes). > > Un saludo. > > [1] http://trac.osgeo.org/proj4j/ > > On 18/11/11 10:09, Ander Pijoan wrote: > > Un pequeño mensaje de socorro también. > > Seguimos sin conseguir hacer la reproyección de forma correcta. Hemos > descargado la cuadricula, ogr2ogr, probado un sinfín de comandos, todas las > combinaciones, etc y no ha habido forma de solucionar ese desplazamiento de > 2-5 metros que comentasteis hace un tiempo. > > Pongamos como caso de ejemplo la población de Aldeaseca de Alba > (Provincia de Salamanca), Huso geográfico 30N y en el catastro viene como > EPSG:23030. ¿Exactamente que comando hay que utilizar para reproyectarlo a > wgs84 utilizando la cuadricula de España? ¿Hay alguna otra forma distinta a > ogr2ogr? > > Necesitamos un poco de ayuda en este aspecto. > > El 18 de noviembre de 2011 09:59, Ander Pijoan > <ander.pij...@deusto.es>escribió: > >> Hola a todos. >> >> Tenéis actualizados los datos en la wiki >> http://wiki.openstreetmap.org/wiki/Spanish_Catrastro explicando el >> funcionamiento mas en detalle y las cosas que quedan por hacer. >> >> También está actualizado el código en el repositorio y hemos añadido un >> archivo .jar para que podáis directamente pasando el archivo >> de configuración ejecutar el código (java -jar cat2osm.jar >> rutaarchivoconfig). Si vais a hacer alguna prueba un par de comentarios: >> >> >> -El mas importante: EL RESULTADO DEL PROGRAMA AUN NO ESTA EN >> CONDICIONES DE SER SUBIDO A OSM. >> >> -Si tenéis dudas en la wiki >> http://wiki.openstreetmap.org/wiki/Spanish_Catrastro está todo detallado. >> >> -Para obtener un resultado menos emborronado y lleno de lineas, os >> recomendamos que de momento no utilicéis los shapefiles Elemlin.shp, >> Elempun.shp ni Elemtex.shp, es decir, el programa solo leerá en ese caso el >> de Parcelas, Subparcelas, Construcciones, Masas y Ejes. >> >> -Podéis abrir el resultado en JOSM o Mekaartor y comentarnos los >> problemas, dudas o ideas que os surjan. Decir, que como es un trabajo que >> importa de forma manual cada ayuntamiento, seguramente encontraremos >> fallos, curiosidades y sorpresas dependiendo del pueblo. >> >> Esperamos ansiosos vuestros comentarios. >> >> Saludos. >> >> El 13 de noviembre de 2011 20:10, Ander Pijoan >> <ander.pij...@deusto.es>escribió: >> >> Hola a los dos, >>> >>> Gracias por los comentarios, para nada los tomamos como críticas, de >>> hecho estamos encantados de que los hagais porque son de gran ayuda ya que >>> vosotros sabeis exáctamente como tiene que ir todo representado para que >>> esté lo mejor posible. >>> >>> Lo que comenta Santiago no hay ningún problema este lunes mismo lo >>> cambiamos. >>> >>> En cuanto a lo de Jaime, vamos por partes =) : >>> >>> Los nombres de las calle si que es un problema. Ya habeis visto que no >>> trae las particulas "de", "del", etc. y no sabemos muy bien como se puede >>> solucionar eso. Si que en el Elemtex.shp (el que vienen los nombres para >>> "dibujarlos" encima de los planos) vienen los nombres de las calles con >>> esas partículas. Pero puede ser muy complicado buscar qué nombres están mas >>> o menos encima de qué calles. Por cierto, mirando en la wiki lo del >>> karlusche no me queda muy claro pero bueno también es que es domingo, >>> mañana lo vuelvo a mirar. >>> >>> Lo de polígonos y relaciones (http://imgur.com/bWeyz y >>> http://imgur.com/bWeyz) rotas estamos mirando a ver dónde falla el >>> programa porque deducimos que es al crear una nueva vía que es cuando se >>> comprueba si ya existe una igual, mirando sus dos nodos, para no crearla y >>> únicamente darle su id. >>> Por alguna razón el programa aunque la vía no existe, está diciendo que >>> si y le está devolviendo el id de una que como veis no tiene nada que ver >>> con su geometría y por eso se queda el polígono "roto". Esto si que puede >>> darnos mas de un dolor de cabeza para encontrarlo y la verdad que >>> al suceder solo en algunos casos nos da que pensar si en vez de ser >>> problema de nuestro programa puede ser que en catastro esas geometrías >>> concretas están metidas con algún problema q no estamos teniendo en cuenta. >>> >>> Lo de las vias con multipolygon mañana mismo lo corregimos, no tiene >>> complicación alguna. >>> >>> Sobre el atributo constru, es uno de los atributos mas significativos >>> del catastro con el que luego se podrían hacer muchas cosas ya que >>> representa lo que es cada construcción (página 15 >>> http://www.catastro.meh.es/ayuda/manual_descriptivo_shapefile.pdf). Las >>> ruinas yo las veo como otro edificio cualquiera, no se si requiere algunos >>> tags especiales. >>> >>> Información adicional sobre edificios de si son colegios, hospitales, >>> etc. no hemos encontrado en los datos del catastro. Como mucho viene el uso >>> del suelo con lo que si se puede especificar algo pero no viene el nombre. >>> Si que también es verdad que en el archivo Elemtex (el que vienen los >>> nombres para "dibujarlos" encima de los planos) pudiera darse que en alguna >>> población los hayan incluido para dibujar sobre la parcela del hospital su >>> nombre. Primero habría que mirar si lo han hecho así y segundo habría que >>> comparar sobre qué parcela o edificio están y añadir la información (que en >>> este caso no es muy complicado, es peor para el caso de las calles). >>> Cogeremos una población un poco mas grande y comprobamos. >>> >>> Creo que no me dejo nada. >>> >>> Saludos y gracias! >>> >>> El 11 de noviembre de 2011 18:18, Jaime Crespo <jy...@jynus.com>escribió: >>> >>>> El 11 de noviembre de 2011 16:16, Santiago Crespo < >>>> talk-openstreetmap....@flanera.net> escribió: >>>> >>>>> Gracias por ir compartiéndo los avances! >>>>> >>>> >>>> Ídem y enhorabuena por el curre. >>>> >>>> Más cosas: >>>> >>>> * Hay un problema del catastro en sí (no con el conversor), y es que da >>>> el nombre y el tipo de vía por separado, lo cual es bueno, pero no >>>> permitirá rutear con los estándares actuales de OSM. ¿Como se podría >>>> solucionar (pregunta al aire)? Concatenarlos funcionará un poco mal (están >>>> en mayúsculas, no sabemos si van sin nada, con un "de", "del", "de la", "de >>>> los", "de las"). Lo importante, eso sí, es que tengan el mismo nombre que >>>> las vías o estén relacionadas, siguiendo el karlusche schema. >>>> * He visto en el archivo generado varias relaciones rotas: ejemplo, >>>> falta la vía entre 3717901TL9231N y 3717904TL9231N >>>> * Hay superposición de vías ¿quizá errores que ya estaban en el >>>> catastro? ejemplo: en la ref 3717901TL9231N, entre el multipolígono roto y >>>> los del sur <http://imgur.com/bWeyz> Lo comento por si no lo habéis >>>> visto. >>>> * He visto algún artefacto más en el que parece que sobran vías, pero >>>> igual es la combinación de algunas que faltan + superposición < >>>> http://imgur.com/MZ8zg> en la ref 3617509TL9231N >>>> * Se han aplicado a las vías etiquetas como type=multipolygon , >>>> catastro:ref, building, que en algunos casos no tienen sentido (una vía no >>>> es un multipolígono ni un edificio, es el área) y en otras queda la >>>> referencia de sólo una de las parcelas/paredes, por lo que es incorrecto. >>>> Borraría todo eso. >>>> * Los solares ya aparecen bien, pero parece ser que los edificios o lo >>>> que sea en ruinas se marcan de una manera especial ¿constru=ruina? Me lo >>>> anoto aquí como recordatorio para ver cómo realizar la conversión a OSM >>>> * Pregunta: ¿podrían aplicarse alguno de los textos que ahora no están >>>> en el OSM a edificios? Si son POIs, son tema aparte, pero si son nombres en >>>> plan "Colegio Lalala", serían de ayuda para que posteriormente, a mano, se >>>> categorizaran los edificios >>>> >>>> PD: Creo que debería quedar claro que nadie debería subir esto como >>>> está, son pruebas de desarrollo >>>> >>>> PD2: Ander, espero que no te tomes estas cosas como críticas, al >>>> contrario, reconozco tu labor enormemente: es sólo que soy bastante >>>> estricto en QAs :-) A ver si ahora que he terminado con las charlas tengo >>>> tiempo para meterme con el código directamente >>>> >>>> -- >>>> Jaime Crespo >>>> >>>> _______________________________________________ >>>> Talk-es mailing list >>>> Talk-es@openstreetmap.org >>>> http://lists.openstreetmap.org/listinfo/talk-es >>>> >>>> >>> >>> >>> -- >>> Ander Pijoan Lamas >>> Ingeniero Técnico en Informática de Gestión >>> Universidad de Deusto >>> >>> Contacto: >>> Email: ander.pij...@deusto.es >>> Móvil: 664471228 >>> >>> >> >> >> -- >> Ander Pijoan Lamas >> Ingeniero Técnico en Informática de Gestión >> Universidad de Deusto >> >> Contacto: >> Email: ander.pij...@deusto.es >> Móvil: 664471228 >> >> > > > -- > Ander Pijoan Lamas > Ingeniero Técnico en Informática de Gestión > Universidad de Deusto > > Contacto: > Email: ander.pij...@deusto.es > Móvil: 664471228 > > > > _______________________________________________ > Talk-es mailing > listTalk-es@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk-es > > > > -- > ─────────────────────────── Álvaro Arranz García. CoNWeT Lab. School of > Computer Science Universidad Politéncica de Madrid (UPM) > ─────────────────────────── > > > > -- > ─────────────────────────── Álvaro Arranz García. CoNWeT Lab. School of > Computer Science Universidad Politéncica de Madrid (UPM) > ─────────────────────────── > > > > -- > ─────────────────────────── Álvaro Arranz García. CoNWeT Lab. School of > Computer Science Universidad Politéncica de Madrid (UPM) > ─────────────────────────── >
_______________________________________________ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
