[Talk-es] Herramienta de fusión de los datos actuales con el catastro

Mie Feb 22 09:05:08 GMT 2012

¡Muy buena pinta!

El 20 de febrero de 2012 10:41, Ander Pijoan <ander.pijoan en 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.mail en 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 en 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.pijoan en deusto.es
> Móvil: +34 664471228
>
>
> _______________________________________________
> Talk-es mailing list
> Talk-es en openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>
>

-- 
Saludos
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120222/03750c38/attachment.html>