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

Mie Feb 22 10:06:00 GMT 2012

El 22 de febrero de 2012 10:36, Ander Pijoan <ander.pijoan en 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 <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
>
>
> _______________________________________________
> Talk-es mailing list
> Talk-es en openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-es
>
>

-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.com/
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120222/2cf500a5/attachment-0001.html>