¡Muy buena pinta! El 20 de febrero de 2012 10:41, Ander Pijoan <[email protected]>escribió:
> Os traemos hoy una curiosa imagen. Tenemos desplegado en local nosotros > para nuestras pruebas un servidor Mapnik en el que hoy hemos volcado el > resultado de cat2osm de Ciudad Real, después de reparar los errores que > tenía. Como la caché de imágenes conserva las antiguas aquí tenéis una > buena comparación del antes y después. > > http://i.imgur.com/0miKR.png > > Saludos. > > El 19 de febrero de 2012 19:02, sergio sevillano < > [email protected]> escribió: > >> 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_0000_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 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. >> >> >VP_0015_NoLanduseHealth; no existe landuse=health, se podría sustituir >> por amenity=hospital hasta que nos aclaremos en osm con: >> http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0 , >> http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare >> >> Sabemos que hay cierta pelea con esto, nos reocmendaron usar >> landuse=health como forma de hacer lobby, supongo. >> >> >> 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 >> >> >> > 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 >> y: >> >> VP_0017_CemeteryNoIndustrial; un cementerio es landuse=industrial? >> VP_0018_DuplicacionNoGrave_yard; no puede haber un nodo y un área para la >> misma cosa (landuse=cemetery), además el nodo tiene icorrectamete el tag >> amenity=grave_yard (tumbas al lado de iglesia) y el nombre no puede ser el >> genérico "CEMENTERIO" (quitar mayúsculas), eso ya lo dice el tag. si no se >> sabe nombre propio quitar tag name=* >> VP_0019_TourismAttractionCual; esta marcado como atracción turística pero >> no se sabe cual, falta nombre o por lo menos qué tipo: ayuntamiento, >> palacio, museo.... >> >> >> si queréis las fotos de esto decídmelo y os la mando directamente a >> vuestro mail. >> >> >> cheers, >> sergio >> >> >> >> >> >> >> >> _______________________________________________ >> Talk-es mailing list >> [email protected] >> http://lists.openstreetmap.org/listinfo/talk-es >> >> > > > -- > Ander Pijoan Lamas > Ingeniero Técnico en Informática de Gestión > Universidad de Deusto > > Contacto: > Email: [email protected] > Móvil: +34 664471228 > > > _______________________________________________ > Talk-es mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk-es > > -- Saludos
_______________________________________________ Talk-es mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-es
