El 22 de febrero de 2012 10:36, Ander Pijoan <ander.pij...@deusto.es>escribió:
> Recordad que estamos mas o menos pendientes de si hay alguna mejor forma > para el tag natural=water para denominar aguas artificiales, pozos, > piscinas, depósitos... En catastro a veces vienen bien especificadas y en > esos casos si que les ponemos su tag correspondiente pero en un gran caso > todas esas aguas artificiales vienen como agua a secas y no sabemos cual es > el mejor tag que se le ajusta. > > También los edificios que ahora están saliendo como TourismAttraction, > tras probar en varios pueblos hemos visto que son principalmente edificios > que pertenecen a los ayuntamientos o al gobierno, por lo tanto si conoceis > otro tag que se le asemeje más lo modificamos. > Podría valer http://wiki.openstreetmap.org/wiki/Tag:amenity=public_buildingaunque creo que dicen que es mejor no usarlo (no soy muy dado al ingles). Otra cosa que se pueda asemejar no me suena que exista. > > Llevamos una semana un tanto liados pero poco a poco seguimos haciendo > pequeños cambios. > Me puesto a intentar convertir los datos de Salamanca y me a empezado a dar el error de simplificando vías. Con tanto mensaje ya me pierdo. ¿Esta solucionado ya? A ver si voy a estar con una versión antigua del programa y yo sin enterarme. jejeje > > Saludos. > > El 22 de febrero de 2012 10:05, David <cyme...@gmail.com> escribió: > > ¡Muy buena pinta! >> >> El 20 de febrero de 2012 10:41, Ander Pijoan >> <ander.pij...@deusto.es>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 < >>> sergiosevillano.m...@gmail.com> 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 >>>> 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: +34 664471228 >>> >>> >>> _______________________________________________ >>> Talk-es mailing list >>> Talk-es@openstreetmap.org >>> http://lists.openstreetmap.org/listinfo/talk-es >>> >>> >> >> >> -- >> Saludos >> >> _______________________________________________ >> 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: +34 664471228 > > > _______________________________________________ > Talk-es mailing list > Talk-es@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-es > > -- Jorge Sanz Sanfructuoso - Sanchi Blog http://blog.jorgesanzs.com/
_______________________________________________ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es