<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2017-06-15 13:27 GMT+02:00 Javier Sánchez Portero <span dir="ltr"><<a href="mailto:javiersanp@gmail.com" target="_blank">javiersanp@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-">El 15 de junio de 2017, 11:22, Alejandro S. <span dir="ltr"><<a href="mailto:alejandroscf@gmail.com" target="_blank">alejandroscf@gmail.com</a>></span> escribió:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra">Respondiendo a Matías, hablo de la etiqueta building:min_level[0] no de la etiqueta building_levels. Y entiendo de [2] que no está reflejada.<br><br><div class="gmail_quote"><div>Según entiendo de esa definición se está usando el modelo "ISNPIRE 2D extended BU" pero en la página que indican[1] en la web de del catastro no aparece referenciado ese modelo "extended", ya empezamos mal...<br><br><br>[0]: <a href="https://wiki.openstreetmap.org/wiki/Key:building:min_level" target="_blank">https://wiki.openstreetmap.org<wbr>/wiki/Key:building:min_level</a><br>[1]: <a href="http://inspire.ec.europa.eu/schemas/" target="_blank">http://inspire.ec.europa.eu/sc<wbr>hemas/</a><br>[2]: <a href="http://www.catastro.minhap.gob.es/webinspire/documentos/Conjuntos%20de%20datos.pdf" target="_blank">http://www.catastro.minhap.gob<wbr>.es/webinspire/documentos/Conj<wbr>untos%20de%20datos.pdf</a></div><span><div></div></span></div></div></div></blockquote><div class="gmail_quote"><br></div></span><div class="gmail_quote">Tienes razón. Sólo tenemos la información de building:levels y building:levels:underground, pero falta building:min_level. Esto afecta principalmente a los balcones, que están 'plantados' a nivel del suelo. Tampoco tenemos una información que nos distinga los balcones y permita hacer algo con ellos (eliminarlos, por ejemplo). La única solución que veo en este momento es que como en cualquier caso hay que revisar edificio por edificio para comprobar errores de Catastro que pueden ocurrir (principalmente edificios mal situados o que no existen), esa podría ser una cuestión más a revisar.<span class="gmail-"><br></span></div></div></div></div></blockquote><div><br></div><div>También se podría intentar sacar la información de los archivos en formato shp del catastro, si coinciden los identificadores de los building part no debería ser muy complicado, sino puede ser un culo.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote"><span class="gmail-"> <br><span><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote"><div><a href="http://datos.gob.es/sites/default/files/manual_descriptivo_shapefile.pdf" target="_blank">http://datos.gob.es/sites/defa<wbr>ult/files/manual_descriptivo_s<wbr>hapefile.pdf</a><br> </div><span class="gmail-m_-3291840817074339888m_5439705576939421392gmail-"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div>Entiendo que para los polígonos adyacentes se esta optando por la solución de usar áreas adyacentes que comparten los nodos. ¿Es esta la estructura de datos que queremos utilizar?<br></div></div></blockquote><div><br></div></span><div>No entiendo muy bien a que te refieres<br></div></div></div></div></div></div></blockquote><div><br></div></span><div>A la hora de reflejar polígonos adyacentes, se puede utilizar áreas que comparten los nodos (sistema que usa el programa ahora) o multipolígonos que compartan las vías que separan unas áreas de otras, aquí puedes ver un ejemplo[3]<br><br>[3]: <a href="http://www.openstreetmap.org/#map=19/41.64392/-0.88465" target="_blank">http://www.openstreetmap.org/#<wbr>map=19/41.64392/-0.88465</a><br></div><span></span><br></span></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote><div>Ah vale. Yo voto por la opción actual, compartir nodos y repetir segmentos. Lo de dibujar segmentos únicos y emplear múltiples relaciones me atrajo hace años pero creo que es mucho más difícil de comprender y mantener. Cuando quieres hacer un cambio es un follón y es muy fácil que se roma si le mete mano un "newby". Creo que generaríamos demasiadas relaciones y tendríamos rechazo en la lista imports.<br></div></div></div></div></blockquote><div><br></div><div>Personalmente me parece más dificil editar cuando tienes muchas áreas contiguas porque no hay manera de seleccionar la que quieres, sin embargo con los multipolígonos, es más fácil seleccionar al poder elegir en el menú que relación te interesa. También me parece más correcto topológicamente que usar vías superpuestas. Es verdad que hace años no gustó en imports, pero tampoco se insistió e igual han cambiado de parecer. Podemos seguir hablándolo más adelante.<br><br></div><div>Saludos,<br></div><div>Alejandro Suárez<br></div></div></div></div>