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.
_______________________________________________
Talk-es mailing list
Talk-es@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-es
