<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
El 22/03/12 23:11, David Marín Carreño escribió:
<blockquote
cite="mid:CAHPETy6Mhh5AFaG-CP0onfzPK3TpgwmF9uA5dLbjE-9cEWE-+g@mail.gmail.com"
type="cite">Pues, como era de esperar, se abrió la caja de Pandora...
<div><br>
Comentarios desde la lista de imports:
<div><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">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.</blockquote>
<div> </div>
<i>(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)<br>
</i></div>
</div>
</blockquote>
No entiendo muy bien a qué se refiere con lo de land registry records,
¿a la referencia catastral o a qué?<br>
<blockquote
cite="mid:CAHPETy6Mhh5AFaG-CP0onfzPK3TpgwmF9uA5dLbjE-9cEWE-+g@mail.gmail.com"
type="cite">
<div>
<div><i></i><br>
En otro mensaje:<br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">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. </blockquote>
<div><i>(¿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).</i></div>
<div><i><br>
</i></div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">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. </blockquote>
<i>(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)</i> </div>
<div><br>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">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).</blockquote>
<div><i>(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)</i></div>
<div><i><br>
</i></div>
<div><i><br>
</i></div>
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... </div>
<div>¿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)?</div>
</div>
</blockquote>
Yo tampoco estoy muy seguro de que debamos importar las parcelas
rústicas, por algunos de los problemas que han mencionado.<br>
<blockquote
cite="mid:CAHPETy6Mhh5AFaG-CP0onfzPK3TpgwmF9uA5dLbjE-9cEWE-+g@mail.gmail.com"
type="cite">
<div>
<div><br>
</div>
<div><br>
</div>
<div>Por otro lado, también indican:</div>
<blockquote class="gmail_quote"
style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">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.</blockquote>
<div><i>(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)</i></div>
<div><br>
</div>
<div>Esto me ha dejado picueto. ¿Algún experto en estas lides en la
sala?</div>
</div>
</blockquote>
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.<br>
<br>
En cuanto a lo de separar propuestas (I suggest breaking your import
proposal into sub-proposals for each <span class="moz-txt-citetags"></span>type
of data set. E.g. have a different proposal for roads than for <span
class="moz-txt-citetags"></span>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.<br>
</body>
</html>