[Talk-es] [CATASTRO] Cuestiones formales

Carlos Dávila cdavilam en orangecorreo.es
Jue Mar 22 22:38:36 GMT 2012


El 22/03/12 23:11, David Marín Carreño escribió:
> Pues, como era de esperar, se abrió la caja de Pandora...
>
> Comentarios desde la lista de imports:
>
>     I see that you are proposing importing land registry records. I
>     believe this is a bad idea and the consensus is that land registry
>     data is not suitable for import into OSM.
>
> /(Veo que proponéis importar los registros de terreno. Creo que es una 
> mala idea y que el consenso es que los datos de registro no son 
> adecuados para su importación en OSM)
> /
No entiendo muy bien a qué se refiere con lo de land registry records, 
¿a la referencia catastral o a qué?
> //
> En otro mensaje:
>
>     Are you really going to import all parcels ? Here in France, we
>     had a very large consensus to refuse the parcels. Parcels are
>     changing frequently (more than buildings) and are overloading the
>     data density which is already at the limits with individual
>     buildings and addresses. 
>
> /(¿De verdad vais a importar todas las parcelas? Aquí, en Francia, 
> consensuamos por mayoría rechazar las parcelas: cambian frecuentemente 
> (más que los edificios) y sobrecargan la densidad de datos, que ya 
> está al límite con los edificios individuales y las direcciones)./
> /
> /
>
>     And parcels are not 1:1 with landuse. Many landuse single polygon
>     can group a lot of parcels or a single parcel may
>     contain different landuse. 
>
> /(Y las parcelas no se corresponden 1:1 con el uso del terreno. Muchos 
> polígonos de un solo uso de terreno pueden agrupar muchas parcelas, o 
> una única parcela puede tener varios usos del terreno)/
>
>     Your community should really reconsider the pros and cons of
>     parcels import. What does it bring to OSM ? Nobody can modify
>     them, they are not verifiable. It makes manual editions
>     very complicated. It does not really help for tagging other
>     things (excepted some fences or walls as we do manually in France
>     but we use the parcels as an external source with a seperate WMS
>     layout in the editor).
>
> /(Vuestra comunidad debería realmente reconsiderar los pros y las 
> contras de la importación de parcelas. ¿Qué ventajas trae a OSM? Nadie 
> puede modificarlas, ni son verificables. Hace que las ediciones 
> manuales sean muy complicadas. No ayuda para etiquetar otras cosas 
> (excepto algunos muros o vallas, según lo hacemos manualmente en 
> Francia, pero usamos las parcelas como fuente externa con una vista 
> WMS separada en el editor)/
> /
> /
> /
> /
> El caso es que razón no les falta... Las parcelas rurales molan mucho, 
> pero creo que sólo nos sirven realmente para determinar los usos del 
> terreno, o quizá algún otro dato que podamos sacar como el nombre de 
> las tierras...
> ¿Sería muy complicado unir en áreas más grandes, como dice el último 
> mensaje del usuario francés, todas las subparcelas que compartan los 
> mismos usos de terreno (o al menos las adyacentes)?
Yo tampoco estoy muy seguro de que debamos importar las parcelas 
rústicas, por algunos de los problemas que han mencionado.
>
>
> Por otro lado, también indican:
>
>     JOSM is not suited for uploading across multiple changesets. There
>     are some tools that will sort a .osc file to have ways follow
>     shortly after the nodes that make them up. If you upload directly
>     from JOSM you will have a large number of nodes followed by the
>     ways. If anything goes wrong, you will be left with stray nodes in
>     the database. It would also be easy for a user to delete a stray
>     node while you are uploading, causing you to have a conflict.
>
> /(JOSM no es adecuado para subir a través de múltiples changesets. Hay 
> algunas utilidades que ordenarán un fichero .osc para hacer que las 
> vías vayan justo detrás de los nodos que las conforman. Si se sube 
> directamente desde JOSM se tendrá un gran número de nodos seguidos de 
> las vías. Si algo va mal, se quedarán nodos huérfanos en la base de 
> datos. También sería facil para un usuario borrar un nodo huérfano 
> mientras se está en el proceso de subida, provocando un conflicto)/
>
> Esto me ha dejado picueto. ¿Algún experto en estas lides en la sala?
Desconozco qué utilidades se podrían usar en vez de JOSM, pero si se usa 
JOSM creo que no sería complicado limitar el tamaño de las subidas, como 
ya se ha hecho en alguna importación del IGN. Si el flujo de trabajo 
como se ha propuesto sería: 1-abrir en JOSM el osm generado por car2osm, 
2-descargar en una capa distinta (osm) la zona en la que se vaya a 
trabajar, 3-ir pasando elementos de la capa cat2osm a la capa osm y 
trabajar sobre ellos. Me parece que es fácil ir subiendo trozos pequeños 
con frecuencia para evitar problemas.

En cuanto a lo de separar propuestas (I suggest breaking your import 
proposal into sub-proposals for each type of data set. E.g. have a 
different proposal for roads than for buildings.) quizás se podía hacer 
aprovechando los distintos parámetros de cat2osm (-contru, -ejes, 
-elemlin, etc.). Entre otras cosas permitiría trabajar con archivos más 
pequeños, con todas las ventajas que eso supone.
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120322/8a50f8c2/attachment.html>


Más información sobre la lista de distribución Talk-es