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

Mie Feb 22 09:36:42 GMT 2012

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.

Llevamos una semana un tanto liados pero poco a poco seguimos haciendo
pequeños cambios.

Saludos.

El 22 de febrero de 2012 10:05, David <cymerio en gmail.com> escribió:

> ¡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
>
> _______________________________________________
> 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
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120222/d0184b86/attachment-0001.html>