Atentamente, Alejandro Suárez 2017-06-15 10:37 GMT+02:00 Javier Sánchez Portero <[email protected]>:
> Hola. > > Contesto entre lineas > > El 14 de junio de 2017, 13:58, Alejandro S. <[email protected]> > escribió: > >> ¿El Atom tiene tanta información como la base de datos del Catastro en su >> formato shp? ¿Está reflejada en el Atom la información correspondiente a >> building:min_level? Si no es así, ¿queremos importar esta información >> parcial en lugar de la general? ¿podemos combinar información de ambos >> repositorios para quedarnos con lo mejor de cada uno? >> > > La información del servicio Atom no es tan detallada como la de los > shapefiles pero casi. Creo que es más que suficiente. Falta si el edificio > está en construcción, la definición de algunas partes como escaleras o > balcones, pero la forma de los edificios y el número de pisos es igual. > > http://www.catastro.minhap.gob.es/webinspire/documentos/ > Conjuntos%20de%20datos.pdf > Respondiendo a Matías, hablo de la etiqueta building:min_level[0] no de la etiqueta building_levels. Y entiendo de [2] que no está reflejada. Según entiendo de esa definición se está usando el modelo "ISNPIRE 2D extended BU" pero en la página que indican[1] en la web de del catastro no aparece referenciado ese modelo "extended", ya empezamos mal... [0]: https://wiki.openstreetmap.org/wiki/Key:building:min_level [1]: http://inspire.ec.europa.eu/schemas/ [2]: http://www.catastro.minhap.gob.es/webinspire/documentos/ Conjuntos%20de%20datos.pdf > http://datos.gob.es/sites/default/files/manual_descriptivo_shapefile.pdf > > >> Entiendo que para los polígonos adyacentes se esta optando por la >> solución de usar áreas adyacentes que comparten los nodos. ¿Es esta la >> estructura de datos que queremos utilizar? >> > > No entiendo muy bien a que te refieres > A la hora de reflejar polígonos adyacentes, se puede utilizar áreas que comparten los nodos (sistema que usa el programa ahora) o multipolígonos que compartan las vías que separan unas áreas de otras, aquí puedes ver un ejemplo[3] [3]: http://www.openstreetmap.org/#map=19/41.64392/-0.88465 > > >> >> ¿Se está comprobando que no se generan nodos superpuestos en geometrías >> adyacentes? >> >> > Cuando se genera el archivo OSM, los nodos que tienen las mismas > coordenadas se introducen una sola vez, con una referencia única. Las > distintas vías 'padres' del nodo usan la misma referencia. Aun así todavía > salen algunos nodos duplicados (pocos) al validar en JOSM en municipios con > mucha información (pendiente de revisar). > > Más información sobre temas parecidos en > https://wiki.openstreetmap.org/wiki/ES:Catastro_espa%C3% > B1ol/Importaci%C3%B3n_de_edificios/Conversi%C3%B3n_de_datos/Programa > > Genial que se haya tenido en cuenta, muy buen labor de documentación, solo hay que ser conscientes de que este programa va a procesar grandes conjuntos de datos y tiene que ser mínimamente eficiente, que no pase como con cat2osm... > El 15 de junio de 2017, 7:49, Matías h <[email protected]> > escribió: > >> >> - En el archivo correspondiente a las direcciones, el código postal >> aparece como 6900 cuando en realidad es 06900. >> >> Corregido en la última versión. > >> >> - addr:street = CL SANTIAGO y addr:city = LLERENA. Aparecen en >> mayúsuculas. >> >> > Lo de los municipios es una cuestión abierta y para la que se piden > opiniones, voy a abrir un hilo para tratarlo. > > Lo de corregir los nombres de las calles (que vienen en mayúsculas y con > varios errores) es una cuestión que estoy trabajando para definir e > implementar. Se agraden colaboradores, especialmente para Catalán, > Gallego... y otros. > Con el tema de las direcciones hay que tener cuidado, ya que ha sitios donde ya hay mucha información de ese tipo introducida o importada y hay que dar facilidad a la conflación de los datos existentes. Saludos, Alejandro
_______________________________________________ Talk-es mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-es
