[Talk-es] Bloqueo de catastro_pontevedra

[Rafael Avila Coya]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bueno, yo lo de los edificios y los landuses los hago con relaciones
(sólo al principio, cuando no dominaba las relaciones, lo hacía con
ways). Podéis ver en Noia (por ejemplo) como lo hago así (el casco
viejo, por lo menos, está íntegramente hecho con relaciones
multipolygon). Así que, como ya he dicho antes, sería una
contradicción que se pudiesen generar esas relaciones a mano, y no se
pudiesen, en cambio, hacer por medio de un script!

En mi opinión, yo creo que queda mucho mejor con relaciones que con ways.

En todo caso, inspeccionando los datos con detenimiento, veo que son
bastante comunes multipolígonos que tienen nodos dentro de un mismo
segmento recto y que podríamos, por lo tanto, eliminar.

Como ejemplo, para el municipio de Porto do Son hice un cat2osm de
construcciones sólo, donde se pueden ver muchos edificios que aparecen
con montón de nodos en medio de segmento recto. Como no puedo enviar
fichero de PortoDoSonCONSTRU.osm (22Mbytes) por correo, os envío un
cachito. En él podéis fijaros por ejemplo en el edificio más grande
que hay en el centro, en forma de 7, y veréis claro esto que digo de
los nodos supérfluos.

También, quizás, se podría simplificar lo de separar lo que parece son
detalles menores (aleros...) dentro de un mismo edificio. En este
mismo fichero un ejemplo serían los edificios que hay debajo (al sur)
del edificio grande.

Quizás con eso mejorase la perspectiva de cara a subir otros datos que
no sean viales y parques, como aceptan hasta ahora. Y en todo caso,
sea mediante vías o mediante relaciones, repito de nuevo que sería una
pérdida importante de datos el subir masas, y no los edificios con sus
separaciones entre ellos.

Un saludo.

On 05/05/12 17:17, Cruz Enrique Borges Hernandez wrote:
>> Hola:
>> 
>> Lo de eliminar las separaciones entre edificios sería en mi
>> opinión absurdo, pues es un dato bien importante saber dónde
>> acaba un edificio y dónde empieza otro. Además sería
>> contradictorio. Por poner un ejemplo, la importación del catastro
>> francés se hizo así, mostrando cada bloque separado del
>> siguiente. Podéis verlo en París, por ejemplo:
>> http://osm.org/go/0BOdwT6zu-- O si queréis, yo llevo un par de
>> años haciendo esto a mano, a los pocos, en varios ayuntamientos, 
>> por ejemplo en Noia ( http://osm.org/go/b9LZ4u6Gn--  ), y nunca
>> recibí ningún bloqueo por esto.
> 
> O.o lo han hecho a base de ways, no de relaciones. Esto tengo que
> hablarlo con Ander... De todas formas, los expertos direis, ?¿?¿?
> es mejor hacer las geometrias compartidas como un relacion (como lo
> hacemos nosotros) o con ways (como se hizo en París)?¿?¿?¿?¿?¿? Más
> editable es lo de París, pero no estoy seguro de su "correctitud".
> 
> 
> De todas fornas, creo que los tiros van más por el parcelario
> rústico, que por otra cosa. La gran pega que dan es que luego sería
> muy difícil editar dichos datos con las herramientas actuales.
> Sobre todo por la barbaridad de relaciones que generamos. Tampoco
> se entiende que se generen tantas "parcelas" con datos 
> "infignificantes" (nótese las comillas de ironía), supongo que no
> han volado por encima de España nunca y flipado con el minifundismo
> salvaje del norte de España.
> 
>> Aún sin saber las razones que dan, pienso que sería un gran
>> error renunciar a divisiones entre edificios consecutivos, un
>> error que en el futuro sería muy difícil de revertir...
>> 
>> Un saludo.
> 
> 
> _______________________________________________ Talk-es mailing
> list Talk-es en openstreetmap.org 
> http://lists.openstreetmap.org/listinfo/talk-es


- -- 
- --------------------------------

Por favor, non me envíe documentos con extensións .doc, .docx, .xls,
.xlsx, .ppt, .pptx, aínda podendoo facer,  non os abro.

Atendendo á lexislación vixente, empregue formatos estándares e abertos.

http://es.wikipedia.org/wiki/OpenDocument#Tipos_de_ficheros
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJPpVFcAAoJEB3niTly2pPQVScP+wfhx67AqIYzaDiV0OVP1YFN
yFhKEZ6kpWfkWxdyuq0+yaqqlvBf+0Blh7yz2TP09D8c8AxnWKPszC1md1csTIhc
FGDtFJsPCVzMTqA1sslWHK4oH6kdKG32yMWnUXex1ITpMxWuDxKTivUdWRo3usK6
DLypRz2FDUZWTtmK2Ng9spwCb6AMZI3d3A1iPtlq8XkAUIMEFQ2NK4+msYQFD5qW
pTiNK6klNVJPecRY7BB2v/w5iMdIWeIT7WmJ6eD0Jw2hor65WvVJHTv4ucQusPlR
/Qp18Cby/uOgWZvv42nMKqTZvx4mPBsKwWWgoWyqoyRgGDp/xhtl3SuLDdNR380r
pFfTfHu5u2bMXtCUVl+aaOcJf82BL5gciYvWdu9dNtxcPWSqbaSA+/OS6p++YIUI
KyDzW0J2rubBJ/5y5vCWc/M1JKNfAZcLOvCZ8Gwpi4lUZphxw1qCz05cY/53RNh/
4PKn9mQW0cRKCDSnjSMKUSlWNb0chnf1EGry6sCvwNnw6qaIyjyl8EyFcN0g+trN
e6HFUDy/J0UpODerv/c+ERC3gO/+7iEExt64VRDkZMoQrSe6UUrfzkFRlHHXtMBA
NvZgJ6anEY7kS9k/JPwb+RXy8GTS/pxQa6i90dZvRQcF6pz7gv1nBKwjOOy5kqrk
uDKBBjBeLtsZzpjtteq0
=FSaB
-----END PGP SIGNATURE-----
------------ próxima parte ------------
A non-text attachment was scrubbed...
Name: portoDoSonCONSTRUextracto.osm
Type: text/xml
Size: 54756 bytes
Desc: no disponible
URL: <http://lists.openstreetmap.org/pipermail/talk-es/attachments/20120505/26cc2b73/attachment-0001.xml>