Re: [Talk-es] Herramienta de fusión de los datos actuales con el catastro
en general veo que el catastro tiene sus cosas y requiere trabajo manual gracias por mirarlo si no tienen solución por lo menos queda como cosas en las que fijarse antes de subir a osm El 17/02/2012, a las 12:22, Ander Pijoan escribió: @sergiosevillano.mail en gmail.com VP__all; VP_0001_cauceNoEsFarm_EsNada; polígonos estrechos muy largos suelen ser cauces o caminos, no subir, dejar hueco VP_0002_CaminoNoEsFarm_EsNada; polígonos estrechos muy largos suelen ser cauces o caminos, no subir, dejar hueco Entendemos que lo que comentas es que no se suba el polígono que representa el hueco entre parcelas delimitadas por un río o carretera. Es complicado ya tendríamos que mirar como hacer que el programa entienda cuando es un polígono de esos porque no llevan ningún tag especial. VP_0003_streamNoEsLimite; a veces los arroyos (stream o river) no dividen las parcelas si a ambos lados son la misma En catastro se representan así, no cortan una parcela. No se muy bien como querrías representarlo de otra manera. mi sugerencia es que si realmente el río está en la parcela y ésta no se divide en dos, la línea del río no debe incluirse como un miembro de la relación de la parcela. VP_0004_streamDireccionesERR; el sentido del río (que debe coincidir con el de la vía) no es congruente se divide en dos y uno de ellos acaba, luego éste tiene sentido erróneo. No nos habíamos dado cuenta de que en OSM los ríos se indicase en su sentido. Esto en catastro seguramente no esté contemplado por lo que habría que invertir la vía desde JOSM. VP_0005_farmNoEsScree; el tag scree se refiere a pedregal de alta montaña (Canchal) creo que viene de improductivo en el catastro no tiene traducción para osm, dejar vacío En la imagen pone scrub. De todas formas scree se ha descartado hace un tiempo. ups, fallo mío VP_0006_huertoNoEsScrub; scrub es matorral, pero esto no lo es parece huerto (no sé en osm, quizás también farm) Esto tiene pinta de ser datos incorrectos en el catastro porque ese scrub viene de que lo han catalogado como suelo improductivo. VP_0007_FarmEsIgualAFarmland; en la wiki landuse=farm es lo mismo que landuse=farmland deberíamos elegir uno, parece preferible landuse=farm (tierras de cultivo) no confundir con landuse=farmyard que es donde están las construcciones de granja apero almacenes ... VP_0008_NoScreeNoFarmSiFarmyard; ver VP_0007 VP_0009_NoFarmSiFarmyardFaltaBuilding; VP_0012_NoFarmSiFarmyard; edificio de granja esta siempre en landuse=farmyard y no en landuse=farm, ver VP_0007 En catastro no hay una categoría para granja o edificios de granja. El decirle al programa que toda construcción que encuentre sobre un landuse=farm lo convierta a farmyard puede ser peor porque pueden ser viviendas, silos, etc. etc. VP_0010_SiScrub; el matorral está en parcela residencial VP_0011_NoScrub; un edificio no puede ser natural=scrub Esto seguramente sea porque pertenecen a los datos rústicos del catastro. A estos datos por ser rústicos hay que añadirles un tipo de cultivo de la parcela y tendrá como cultivo asociado improductivo. Lo único que se podría hacer es introducir bloqueos. En este caso ¿cuales serían los bloqueos? ¿landuse=residencial no puede tener tipo de cultivo que en este caso se traduce en natural=scrub? parece que terreno improductivo es lo que más errores genera . quizás eliminaría todo terreno improductivo de la importación. ésta definición es negativa, y no sé si hay tag para terreno improductivo en general, aunque sí hay para cosas que son improductivas: de hecho todos los landuse excepto los de cultivo (que son farm, orchard, vineyard, grass, forest), son improductivos. http://wiki.openstreetmap.org/wiki/ES:Map_Features#Uso_del_suelo_.28Landuse.29 lo que es cierto es que no todo lo improductivo es scrub por ejemplo a todo el casco urbano se le aplica scrub !? VP_0013_SegmentoPerdidoOverRio; el rio se usa como línea que divide cultivos y miembro de relaciones, pero en este segmento tenemos 2 vías superpuestas una con las relaciones y otra con el río solo. Esto es una chapuza de los que hayan hecho la importación, cada pueblo tiene sus sorpresas. VP_0014_SinTagsRelevantes; vías y relaciones sin ningún tag que lo identifique como algo de osm, solo tiene refs del catastro y source.. Esto significa que esa casa no tiene ningún registro en el catastro. Solo tenemos su geometría en los shapefiles y no hay datos extra del archivo .cat. VP_0015_NoWater; natural=water es tag de vías cerradas o o tag de relaciones multipoligono, nunca un segmento suelto puede tener tag de área. ademas el propio tag no es correcto la relacion superior ya dice que es piscina luego no es natural=water. (porque los segmentos no están unidos en una sola vía cerrada?) Esto esta explicado en la wiki, las piscinas, pozos, etc tienen las geometrías partidas de origen (de formas muy
Re: [Talk-es] Herramienta de fusión de los datos actuales con el catastro
Curioso lo de la presa. Si tiene los tags de building-levels es que lo han incluido en catastro como construcción y tendrá el atributo CONSTRU indicando que tiene 1050 alturas. No tengo ni idea en qué se habrán basado para decidir que tiene esa altura. Otra de las muchas curiosidades que irán apareciendo en catastro. mi sugerencia es que si realmente el río está en la parcela y ésta no se divide en dos, la línea del río no debe incluirse como un miembro de la relación de la parcela. Tendría que mirar exactamente si esto para la mayoría de los municipios es algo que está haciendo cat2osm el partir esa pequeña parcela en dos por haber un río en medio o de verdad viene así también en catastro. En caso de que sea la primera, una solución rápida puede ser crear primero un resultado sin los archivos ELEMLIN que son los que contienen ríos y elementos lineales, luego generar uno solo con estos elementos y al final juntarlos. ups, fallo mío parece que terreno improductivo es lo que más errores genera . quizás eliminaría todo terreno improductivo de la importación. ésta definición es negativa, y no sé si hay tag para terreno improductivo en general, aunque sí hay para cosas que son improductivas: de hecho todos los landuse excepto los de cultivo (que son farm, orchard, vineyard, grass, forest), son improductivos. http://wiki.openstreetmap.org/wiki/ES:Map_Features#Uso_del_suelo_.28Landuse.29 lo que es cierto es que no todo lo improductivo es scrub por ejemplo a todo el casco urbano se le aplica scrub !? El problema es que en cada población siempre hay alguna cosa distinta que es la que da problemas. En cada pueblo han importado de una forma distinta y han tenido sus vicios con X tag o han hecho las cosas de cierta manera distinto a lo que se indica en catastro. Cierto es que cualquier traducción mejor para los datos es muy bienvenida y sigue haciendo falta adecuar los tags de la mejor forma. VP_0013_SegmentoPerdidoOverRio; el rio se usa como línea que divide cultivos y miembro de relaciones, pero en este segmento tenemos 2 vías superpuestas una con las relaciones y otra con el río solo. Esto es una chapuza de los que hayan hecho la importación, cada pueblo tiene sus sorpresas. VP_0014_SinTagsRelevantes; vías y relaciones sin ningún tag que lo identifique como algo de osm, solo tiene refs del catastro y source.. Esto significa que esa casa no tiene ningún registro en el catastro. Solo tenemos su geometría en los shapefiles y no hay datos extra del archivo .cat. VP_0015_NoWater; natural=water es tag de vías cerradas o o tag de relaciones multipoligono, nunca un segmento suelto puede tener tag de área. ademas el propio tag no es correcto la relacion superior ya dice que es piscina luego no es natural=water. (porque los segmentos no están unidos en una sola vía cerrada?) Esto esta explicado en la wiki, las piscinas, pozos, etc tienen las geometrías partidas de origen (de formas muy entretenidas). de acuerdo, pero nunca son natural=water. en osm (que básicamente es lago natural) tenemos piscina, deposito, estanque, fuente...(todo artificial) alguno parece registro de aguas que no sé que sería en osm.. puede que la solución sea saber el error y simplemente chequear todos ellos a mano uno a uno. Bien, me parece correcto, ¿entonces cual sería el tag apropiado? En un principio catastro no diferencia de agua artificial y natural, pero si que parece que salen mas artificiales que naturales. donde está documentado landuse=health ? sí he encontrado que la relación tenga un type=health http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#Usage_of_the_health-relation Es lo que nos recomendaron en la página http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_features. Aunque si que nos planteamos el cambiarlo a amenity=hospital. La que creáis que es la mejor opción. VP_0016_Scrubdentrodeedificio; un multipolígono edificio contiene (dentro no a modo de patio) otro mas pequeño que es matorral (scrub), no puede ser, parece que quería ser edificio con patio jardín y el edificio estrecho es mas bien barier=wall que sería lineal .esto último es mejor a mano Esto es tema de las geometrías interesantes de catastro. Poco se puede hacer. Saludos. -- Ander Pijoan Lamas ademas de lo anterior en el mismo archivo osm de Villanueva de Perales esta lo que comenté de que el contorno urbano está marcado como scrub Esto creo que no hay forma de solucionarlo. En los archivos rústicos de parcelas crean una parcela que abarca toda la urbana y le dan un tag que crean conveniente. Por ejemplo en el caso de Aldeaseca de Alba la zona urbana está sobre una parcela rústica de tierras de cultivo o en Ciudad Real también toda la ciudad está sobre una parcela de scrub. A lo mejor se podría poner un tag landuse=none que veo en TagInfo que suele usarse. VP_0017_CemeteryNoIndustrial; un cementerio es landuse=industrial?
