Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
El 11 de mayo de 2012 07:59, Cruz Enrique Borges cruz.bor...@deusto.esescribió: Los dos primeros son montes en los que estoy de acuerdo habría que juntar las parcelas porque no tiene sentido. En el último, tendremos que hacerlo pero no sigue sin gustarme tener que hacerlo. En ese caso HAY separación física importante (aunque falten muchas) y me parece muy interesante tener esa información. Aquí el problema es que, vía catastro, esa separación será un way sin etiquetar, en lugar de una valla, un muro, o lo que sea que haya. Vamos, que quizá lo que hay que hacer es hacer un repositorio de ficheros OSM que contengan todas estas separaciones sin etiquetar para que el OSMero local que sepa de primera mano que hay algo separando dos terruños (o el OSMero que lo vea mediante ortofoto) utilice las fronteras de catastro para mapear dichas separaciones físicas. Yo me refería a esto [4], [5]. Y estoy de acuerdo en que es MY complicado de hacer. [4] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-11%2000:05:27 .png [5] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-11%2000:13:09 .png Esto si que no me parece correcto de ninguna de las maneras. Si lo que hay debajo es un cortafuegos, pista forestal, camino de cabras o sendero, tiene que estar marcado. De hecho, me parece que el JOSM se quejaría con un warning del tipo vías superpuestas o algo así. Completamente de acuerdo: en el catastro tenemos los caminos (o al menos, las fronteras de los mismos). No adelantamos nada uniendo ambos márgenes: la simplificación en este caso no es demasiado alta. De resto, creo que ya tenemos implementado la reducción de nodos con los siguientes resultados: - en aldeaseca se zampa alrededor de 1000 y evita que algunas vías se fusionen por error) - en el vajol más de lo mismo - en medio cudello casca miserablemente - en abenojar parece que lo hace todo correcto. Ahora estamos implementando la fusión de parcelas y constru con los mismos tags. Nótese que traerá como bonus la parelización del algoritmo :) ¡Estupendo! -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- David Marín Carreño dav...@gmail.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
On Viernes, 11 de mayo de 2012 09:07:58 David Marín Carreño escribió: El 11 de mayo de 2012 07:59, Cruz Enrique Borges cruz.bor...@deusto.esescribió: Los dos primeros son montes en los que estoy de acuerdo habría que juntar las parcelas porque no tiene sentido. En el último, tendremos que hacerlo pero no sigue sin gustarme tener que hacerlo. En ese caso HAY separación física importante (aunque falten muchas) y me parece muy interesante tener esa información. Aquí el problema es que, vía catastro, esa separación será un way sin etiquetar, en lugar de una valla, un muro, o lo que sea que haya. Vamos, que quizá lo que hay que hacer es hacer un repositorio de ficheros OSM que contengan todas estas separaciones sin etiquetar para que el OSMero local que sepa de primera mano que hay algo separando dos terruños (o el OSMero que lo vea mediante ortofoto) utilice las fronteras de catastro para mapear dichas separaciones físicas. Con la nueva arquitectura que estamos planteando, podemos guardar masas o polígonos rústicos por separado. Con lo cual el OSMero puede generar un fichero con las subdivisiones y otro sin ellas, cargar ambas capas en JOSM y decidir al gusto cuales se quedan y cuales no :) -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
En mi modesta opinión pienso que Cruz tiene razon que ha de ser una opción de configuración, aunque no representrará la realidad legal. En rustica incluso puede ser lo mas acertado, pero en urbana no creo que sea lo mas conveniente. Pepe - Original Message - From: Cruz Enrique Borges cruz.bor...@deusto.es To: Discusión en Español de OpenStreetMap talk-es@openstreetmap.org Sent: Wednesday, May 09, 2012 10:20 AM Subject: Re: [Talk-es][CATASTRO] Simplificación de geometría de las constru. On Miércoles, 9 de mayo de 2012 10:05:52 Matías Taborda Barroso escribió: Hola. Estoy de acuerdo en que la cantidad de información es enorme y probablemente de poco interés, pero decir que no hay límites físicos entre parcelas y/o subparcelas es muy discutible por no decir falso directamente. Como decía aquel, puedo prometer y prometo que.. todo depende. Lo que está claro es que cada comunidad, pueblo, región, etc es un mundo. Aquí en Extremadura, en varios pueblos que he probado, te puedo asegurar que hay cientos e incluso miles de hectáreas que tienen un uso igual e incluso mismo propietario y están separados en parcelas sin ningún tipo de separación física (Montes de eucaliptos pertenecientes a la administración de varios centenares de hectáreas y catastro las divide en pequeñas parcelas). Yo creo que lo mejor va a ser que la agrupación de parcelas en rústico se haga vía opción en el config, para que el usuario decida. Lo que no termino de ver de ninguna de las maneras es lo de agrupar parcelas en urbano y/o parcelas en rústico que no estén juntas/separadas par una vía de agua/pista forestal o equivalente. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
1 Simplificación en rústico sí. En urbano, de entrada, no. Y veamos qué nos cuenta la lista de imports ante un fichero OSM así generado. El 10/05/2012 10:15, pcvalverde pcvalve...@gmail.com escribió: En mi modesta opinión pienso que Cruz tiene razon que ha de ser una opción de configuración, aunque no representrará la realidad legal. En rustica incluso puede ser lo mas acertado, pero en urbana no creo que sea lo mas conveniente. Pepe - Original Message - From: Cruz Enrique Borges cruz.bor...@deusto.es To: Discusión en Español de OpenStreetMap talk-es@openstreetmap.org Sent: Wednesday, May 09, 2012 10:20 AM Subject: Re: [Talk-es][CATASTRO] Simplificación de geometría de las constru. On Miércoles, 9 de mayo de 2012 10:05:52 Matías Taborda Barroso escribió: Hola. Estoy de acuerdo en que la cantidad de información es enorme y probablemente de poco interés, pero decir que no hay límites físicos entre parcelas y/o subparcelas es muy discutible por no decir falso directamente. Como decía aquel, puedo prometer y prometo que.. todo depende. Lo que está claro es que cada comunidad, pueblo, región, etc es un mundo. Aquí en Extremadura, en varios pueblos que he probado, te puedo asegurar que hay cientos e incluso miles de hectáreas que tienen un uso igual e incluso mismo propietario y están separados en parcelas sin ningún tipo de separación física (Montes de eucaliptos pertenecientes a la administración de varios centenares de hectáreas y catastro las divide en pequeñas parcelas). Yo creo que lo mejor va a ser que la agrupación de parcelas en rústico se haga vía opción en el config, para que el usuario decida. Lo que no termino de ver de ninguna de las maneras es lo de agrupar parcelas en urbano y/o parcelas en rústico que no estén juntas/separadas par una vía de agua/pista forestal o equivalente. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
Hola El día 9 de mayo de 2012 07:11, Cruz Enrique Borges cruz.bor...@deusto.es escribió: Perder la referencia catastral sería una catástrofe si pretendes actualizar luego esos datos automáticamente. Estoy de acuerdo contigo. Yo no digo que sea conveniente juntar parcelas. Lo que digo es que puestos a simplificar los edificios o juntar parcelas me quedo con lo segundo. De todas formas, por los mensajes que he visto, casi todo el mundo está de acuerdo en juntar parcelas que tengan el mismo uso en el caso de rústica y en ese caso vas a perder las referencias catastrales si o si. Además, yo no he visto muchas parcela que no esté separada por una valla, muro o similar. Es más, en ciudades, juntar las parcelas no te ayudaría nada, la geometría de la parcela y la de la construcción son la misma en la gran mayoría de los casos. Pues precisamente por eso. Si coinciden son redundantes Por otro lado, lo mismo se aplica a los usos del suelo en la parte rústica. Hay una miriada de miniparcelas en sitios como Canarias o Galicia que reflejan los distintos propietarios del terreno, pero sólo se diferencian en la referencia catastral. Los bordes de estas parcelas no reflejan necesariamente muros u otros límites físicos, por lo menos aquí en Canarias, Me extraña MUCHO eso que dices, ¿de que isla eres? ¿Has estado en la Gomera? ¿has visto las terrazas que hay allí? De hecho, uno de los pueblos con los que hacemos las pruebas es Los Realejos (Tenerife) que es de donde nací y para mi sorpresa ¡¡¡Faltan Terrazas!!! Yo también soy de Tenerife. Te paso tres pantallazos del municipio de Buenavista [1], [2], [3]. En los dos primeros no hay ninguna correlación con nada físico, en el tercero parece haber un poco de correlación con bancales, pero con poca precisión y faltan muchos. Las lindes generalmente se marcan con manchas de cal o una higuera o una fila de piteras y están más en la cabeza de los viejos del lugar que en el Catastro. [1] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-10%2023:38:40.png [2] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-10%2023:42:06.png [3] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-10%2023:40:42.png Estoy de acuerdo en que la cantidad de información es enorme y probablemente de poco interés, pero decir que no hay límites físicos entre parcelas y/o subparcelas es muy discutible por no decir falso directamente. Pues me puedo hartar de pasarte pantallazos como los de antes en varios municipios. o sea que no tienen mucho interés. Yo fusionaría polígonos con un mismo landuse aunque se pierda la referencia catastral, como ya han dicho varios. Con esos dos pasos, el número de relaciones, nodos y vías tendría que bajar bastante. Finalmente, un paso más para reducir información redundante sería fusionar parcelas con un mismo landuse que serían adyacentes si no fuera por que alguna vía las atraviesa. Es decir, en lugar de muchos polígonos residenciales por cada manzana con espacios en blanco a lo largo de las calles, fusionarlos todos en uno. Lo digo sobre todo por los bosques, en lugar de ser un polígono sencillo, si está atravesado por una pista (por poner un ejemplo) se divide en dos polígonos a cada lado de la pista. Como la precisión del eje de las vías deja bastante que desear, si la pista ya existe en OSM y está dibujada con mejor precisión, habrá que corregir los bordes del bosque para que se adapten (un curro) o fusionar los polígonos en uno solo. Lo segundo es más sencillo y queda mucho más fácil de editar. En caso de modificar la pista sólo hay que corregir sus nodos, no los suyos y los de los bordes de la parcela. Esto es fácil de hacer a mano, aunque supongo que será un rollo implementarlo. En cualquier caso, de esta forma se eliminarían nodos innecesarios y relaciones. Esto no se si lo he entendido bien. ¿Dices de juntar todos los polígonos que tengan el mismo landuse aunque tengan vías de por medio? ¿esto está bien hecho? Tema aparte que va a ser MUY complicado de hacer. Yo me refería a esto [4], [5]. Y estoy de acuerdo en que es MY complicado de hacer. [4] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-11%2000:05:27.png [5] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-11%2000:13:09.png Saludos ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
Pues precisamente por eso. Si coinciden son redundantes Pero es que ahora mismo ya estamos quitando (vía relación) esa coincidencia. El ejemplo más claro es con aldeaseca o con el vajol. Parcela y Contru suelen coincidir y además todos los edificios tienen una altura. [1] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-10%2023:38:40 .png [2] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-10%2023:42:06 .png [3] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-10%2023:40:42 .png Los dos primeros son montes en los que estoy de acuerdo habría que juntar las parcelas porque no tiene sentido. En el último, tendremos que hacerlo pero no sigue sin gustarme tener que hacerlo. En ese caso HAY separación física importante (aunque falten muchas) y me parece muy interesante tener esa información. Yo me refería a esto [4], [5]. Y estoy de acuerdo en que es MY complicado de hacer. [4] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-11%2000:05:27 .png [5] http://javiersanp.dhis.org/cat2osm/Pantallazo%20del%202012-05-11%2000:13:09 .png Esto si que no me parece correcto de ninguna de las maneras. Si lo que hay debajo es un cortafuegos, pista forestal, camino de cabras o sendero, tiene que estar marcado. De hecho, me parece que el JOSM se quejaría con un warning del tipo vías superpuestas o algo así. En todos los casos, la mayor dificultad está en saber que pedazos hay que juntar, una vez hecho, es trivial juntarlos (se calcula la envolvente convexa y se heredan los tags). Sobre este tema, la verdad es que me gustaría leer más opiniones. De resto, creo que ya tenemos implementado la reducción de nodos con los siguientes resultados: - en aldeaseca se zampa alrededor de 1000 y evita que algunas vías se fusionen por error) - en el vajol más de lo mismo - en medio cudello casca miserablemente - en abenojar parece que lo hace todo correcto. Ahora estamos implementando la fusión de parcelas y constru con los mismos tags. Nótese que traerá como bonus la parelización del algoritmo :) -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
On Martes, 8 de mayo de 2012 21:35:50 Javier Sánchez escribió: Hola Estamos centrándonos en los edificios, pero me parece que también habría que mirar los multipolígonos (relaciones) de landuse=residential que siempre acompañan a los edificios. Puestos a reducir información, una opción podría ser fusionar todas las parcelas adyacentes que tengan el mismo uso (residential, greenfield, etc). La información que perderíamos sería la referencia catastral de cada parcela, pero disminuiría enormemente el número de relaciones. Al fin y al cabo, la referencia catastral es un dato ajeno a las etiquetas OSM y siempre se puede consultar en Catastro. Prefiero perder información por ese lado que por los edificios. Perder la referencia catastral sería una catástrofe si pretendes actualizar luego esos datos automáticamente. Además, yo no he visto muchas parcela que no esté separada por una valla, muro o similar. Es más, en ciudades, juntar las parcelas no te ayudaría nada, la geometría de la parcela y la de la construcción son la misma en la gran mayoría de los casos. Por otro lado, lo mismo se aplica a los usos del suelo en la parte rústica. Hay una miriada de miniparcelas en sitios como Canarias o Galicia que reflejan los distintos propietarios del terreno, pero sólo se diferencian en la referencia catastral. Los bordes de estas parcelas no reflejan necesariamente muros u otros límites físicos, por lo menos aquí en Canarias, Me extraña MUCHO eso que dices, ¿de que isla eres? ¿Has estado en la Gomera? ¿has visto las terrazas que hay allí? De hecho, uno de los pueblos con los que hacemos las pruebas es Los Realejos (Tenerife) que es de donde nací y para mi sorpresa ¡¡¡Faltan Terrazas!!! Estoy de acuerdo en que la cantidad de información es enorme y probablemente de poco interés, pero decir que no hay límites físicos entre parcelas y/o subparcelas es muy discutible por no decir falso directamente. o sea que no tienen mucho interés. Yo fusionaría polígonos con un mismo landuse aunque se pierda la referencia catastral, como ya han dicho varios. Con esos dos pasos, el número de relaciones, nodos y vías tendría que bajar bastante. Finalmente, un paso más para reducir información redundante sería fusionar parcelas con un mismo landuse que serían adyacentes si no fuera por que alguna vía las atraviesa. Es decir, en lugar de muchos polígonos residenciales por cada manzana con espacios en blanco a lo largo de las calles, fusionarlos todos en uno. Lo digo sobre todo por los bosques, en lugar de ser un polígono sencillo, si está atravesado por una pista (por poner un ejemplo) se divide en dos polígonos a cada lado de la pista. Como la precisión del eje de las vías deja bastante que desear, si la pista ya existe en OSM y está dibujada con mejor precisión, habrá que corregir los bordes del bosque para que se adapten (un curro) o fusionar los polígonos en uno solo. Lo segundo es más sencillo y queda mucho más fácil de editar. En caso de modificar la pista sólo hay que corregir sus nodos, no los suyos y los de los bordes de la parcela. Esto es fácil de hacer a mano, aunque supongo que será un rollo implementarlo. En cualquier caso, de esta forma se eliminarían nodos innecesarios y relaciones. Esto no se si lo he entendido bien. ¿Dices de juntar todos los polígonos que tengan el mismo landuse aunque tengan vías de por medio? ¿esto está bien hecho? Tema aparte que va a ser MUY complicado de hacer. No se si me he explicado. Si no lo he conseguido me dicen y mando alguna imagen para aclararlo. Saludos. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
Hola. Estoy de acuerdo en que la cantidad de información es enorme y probablemente de poco interés, pero decir que no hay límites físicos entre parcelas y/o subparcelas es muy discutible por no decir falso directamente. Como decía aquel, puedo prometer y prometo que.. todo depende. Lo que está claro es que cada comunidad, pueblo, región, etc es un mundo. Aquí en Extremadura, en varios pueblos que he probado, te puedo asegurar que hay cientos e incluso miles de hectáreas que tienen un uso igual e incluso mismo propietario y están separados en parcelas sin ningún tipo de separación física (Montes de eucaliptos pertenecientes a la administración de varios centenares de hectáreas y catastro las divide en pequeñas parcelas). Volvemos a lo de siempre, SÓLO el usuario local podrá decidir que parcelas adyacentes podrán unirse o no. Complicado. Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Leyendo todas las opiniones, propongo esta solución de compromiso, que pienso podría ser aceptada por todos: 1) Construcciones: Crearlas usando vías, tal y como hace el catastro francés (si allí fue aceptado, debe serlo aquí, ¿no?). Pero ojo, no usando masas, sinó haciendo uno para cada efificación separada. Es decir, si hay una hilera de edificios consecutivos, se ve cada uno de ellos, no una masa única. Las razones aquí son de peso. No sólo es que en la mayor parte del mundo ya se hace esto ( http://osm.org/go/0BOd8haLl-- , http://osm.org/go/0D0YngwD3- , http://osm.org/go/euu4j_A3L-- , etc.), sinó que tener los edificios separados facilita enormemente la colocación de POI's por usuarios con pocos conocimientos, que son los más numerosos. Un walking-paper sin tener las casas separadas es mucho más complicado de cubrir que si tenemos sus límites. Naturalmente, tener los números de policía es un plus. Aparte de hacer las edificaciones con vías (es decir, a la francesa), se pueden simplificar eliminando aleros y otros (no deberían, en cambio, eliminarse los patios de luces (en ese caso, habría que hacer relación para ese edificio concreto), pues así constan también en import de catastro francés (ver http://osm.org/go/0BOd8haLl-- )). Es decir, hacer contrucciones sólo el contorno exterior usando vías, no relaciones. En caso de haber patios interiores, incluírlos y hacer contrucción como relación. En cuanto al 3D, no presentaría (creo) problema. Son sólo 3 etiquetas más que acompañan cada edificio: building:height, building:min_height y building:levels, que se pueden poner en valores medios ó extremos de conjunto de edificio, como ya propuse en correo anterior. 2) Parcelas: Aquí se pueden eliminar números de policía, pues no son muy útiles, y en zonas de norte (Galicia en concreto), aparecen a miles, dado el carácter minifundista de la zona. Todas las parcelas consecutivas que tengan mismo tipo de cultivo se unen en una masa, pero sería una pena no usar las posibilidades de osm de distinguir diferentes tipos de uso de la tierra (landuse) (me pregunto entonces para qué están). Además de esto, se puliría el código para eliminar nodos intermedios en vías rectas. No sé qué opinais de esto. A mí, sinceramente, lo que me parece más preocupante es lo de no distinguir entre edificios consecutivos. En todo caso, mi propuesta sería consensuar una solución mínima, modificar el cat2osm, con todo el tiempo y tranquilidad que haga falta, sin prisas, para luego testear sobre diferentes escenarios: ayuntamientos pequeños y grandes, urbanos y rurales, del norte (minifundista) y del centro/sur (latifundista), etc. Así podríamos presentar un resultado depurado y espero que aceptable a imports. Un saludo. On 07/05/12 22:37, David wrote: El 7 de mayo de 2012 21:33, Jaime Crespo jy...@jynus.com mailto:jy...@jynus.com escribió: El 07/05/2012 20:01, Rafael Avila Coya ravilac...@gmail.com mailto:ravilac...@gmail.com escribió: On 07/05/12 18:59, Cruz Enrique Borges Hernández wrote: Buenas A la vista de lo que han comentado en la lista de import la última vez (y que nos han recordado amablemente este fin de semana) le hemos estado dando un par de vueltas ander y yo al tema. Hemos rellenado un par de issue en el tracker con las cosas que pensamos hacer cuando tengamos un rato. De todas formas, hay unas cuantas cuestiones que creo que es preferible discutirlas en la lista para que nos queden claras: Yo no estoy al tanto de los detalles en lo que a la discusión con imports se refiere, pero daré mi opinión. 1º Relaciones en geometrías compartidas. Jaime nos contó muy insistentemente que las geometrías compartidas por más de un edificio deben de construirse como una relación (tal y como estamos haciendo ahora mismo). Sin embargo, en París, se ha hecho Os recuerdo que en Girona se importaron como relaciones. superponiendo la vía y solo compartiendo los nodos. Esto lleva a que en algunos sitios hayan vías duplicadas, pero reduce el número de relaciones enormemente. Esto último ha sido una de las grandes pegas que nos han puesto en la lista de imports, con lo cual está mi duda. ¿Estamos haciéndolo bien? ¿no será mejor duplicar en algunos casos las vías con tal de que queden reduzcamos el número de relaciones? Yo insisto en que no entiendo qué problemas hay con las relaciones. Están ahí para algo, ¿no? Podría ponerse la pega de que es más fácil crear una hilera de casas adosadas usando vías que se superponen en las paredes de separación, pero son una solución cutre si se la compara a hacerlo con relaciones. Entre otras ventajas, las relaciones permiten reutilizar cada uno de los segmentos para futuras necesidades. Es, por lo tanto (y en mi opinión), una solución más elegante. Si la respuesta es que son muchas relaciones, no la entiendo, y creedme que lo intento. Si yo estoy de acuerdo. Aquí el problema está en
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
On 07/05/12 18:59, Cruz Enrique Borges Hernández wrote: Buenas A la vista de lo que han comentado en la lista de import la última vez (y que nos han recordado amablemente este fin de semana) le hemos estado dando un par de vueltas ander y yo al tema. Hemos rellenado un par de issue en el tracker con las cosas que pensamos hacer cuando tengamos un rato. De todas formas, hay unas cuantas cuestiones que creo que es preferible discutirlas en la lista para que nos queden claras: Yo no estoy al tanto de los detalles en lo que a la discusión con imports se refiere, pero daré mi opinión. 1º Relaciones en geometrías compartidas. Jaime nos contó muy insistentemente que las geometrías compartidas por más de un edificio deben de construirse como una relación (tal y como estamos haciendo ahora mismo). Sin embargo, en París, se ha hecho superponiendo la vía y solo compartiendo los nodos. Esto lleva a que en algunos sitios hayan vías duplicadas, pero reduce el número de relaciones enormemente. Esto último ha sido una de las grandes pegas que nos han puesto en la lista de imports, con lo cual está mi duda. ¿Estamos haciéndolo bien? ¿no será mejor duplicar en algunos casos las vías con tal de que queden reduzcamos el número de relaciones? Yo insisto en que no entiendo qué problemas hay con las relaciones. Están ahí para algo, ¿no? Podría ponerse la pega de que es más fácil crear una hilera de casas adosadas usando vías que se superponen en las paredes de separación, pero son una solución cutre si se la compara a hacerlo con relaciones. Entre otras ventajas, las relaciones permiten reutilizar cada uno de los segmentos para futuras necesidades. Es, por lo tanto (y en mi opinión), una solución más elegante. Si la respuesta es que son muchas relaciones, no la entiendo, y creedme que lo intento. 2º OSM-2.5D Ahora mismo estamos aprovechando toda la información que podemos de las alturas de los edificios. Esto provoca que se tengan que hacer una barbaridad de relaciones para tener en cuenta aleros, tejados, balcones, etc. Cómo aún no está nada claro el tema del 2.5D en osm, se podría incluir la referencia catastral en las constru y simplificarlas poniendo solo la unión de todas las geometrías de ese edificio. Con esto reducimos el número de relaciones otra vez más y si en algún momento queda claro como va a funcionar el 2.5D sólo hay que eliminar las geometrías con una referencia catastral y sustituirla por las que tenga la info 2.5D.La pregunta es, ¿nos peleamos por el 2.5D o simplificamos y ya lo haremos más adelante? La pega, que también sería válida para el punto 1º, es: ¿será fácil/viable incorporar esos datos más adelante? Anteayer envié un e-mail de respuesta en el hilo Bloqueo catastro_pontevedra que quizá no llegó a la lista por llevar adjunto un archivo de 2.2M (no sabía que el máximo eran 100k). En el proponía alguna alternativa de simplificación, que vuelvo a escribir aquí: -- En el issue 23 [se refiere a mejoras en cat2osm] pones [Cruz Enrique] que se podría renunciar a tags 3D. ¿Te refieres con eso a tags como building:height, building:min_height y building:levels? Si es así creo que sería mala idea, pues dejaría a proyectos como osm3D sin posibilidad de usarlos.[Como alternativa menos buena, aunque más simple] En caso de que cada parte del edificio tuviese diferentes valores para esos tags, se podría elegir un valor único para todo el edificio y para cada uno de esos tags. Por ejemplo, para el building:min_height se podría elegir el mínimo de ellos, para building:height se podría elegir el que resultase ser máximo, o un valor medio, y para building:levels el que resultase máximo. Habría que ver las distintas posibilidades complejas que se pueden dar. En todo caso, hay que tener en cuenta que se perdería info. Otra posibilidad sería eliminar (unir) aquellas partes que tienen tags 3D idénticos, y mantener separados los que no. Esto no haría perder info, y sí sería aceptable por todos, sin ninguna duda. --- Pero repito la gran duda: si se optan por soluciones como vías superpuestas como alternativa a usar relaciones, y si simplifican edificaciones perdiendo info. 3D (ó 2.5D), ¿sería fácil hacer más adelante una actualización/mejora, o habría que reacer todo de nuevo? ¡El trabajo ya es enorme en sí mismo, para aún pensar en una segunda fase! 3º Simplificación de cultivos. La otra pata es la simplificación de cultivos que tengan los mismos tags, aquí habría que hacer lo mismo que con las constru, solo que en vez de agrupar por parcelas, hay que hacerlo por tipo de cultivo. En esta poca discusión puede haber. Pues nada, ya nos direis. Unir parcelas consecutivas que comparten mismo cultivo no es mala idea de todo. A bote pronto, la única información que se podría perder es la línea de separación entre parcelas, que se puede etiquetar como barrier=wall,hedge,fence, etc., según proceda y con datos sobre el terreno, en este caso. No sería una
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
El 7 de mayo de 2012 18:59, Cruz Enrique Borges Hernández cruz.bor...@deusto.es escribió: Buenas 1º Relaciones en geometrías compartidas. Jaime nos contó muy insistentemente que las geometrías compartidas por más de un edificio deben de construirse como una relación (tal y como estamos haciendo ahora mismo). Sin embargo, en París, se ha hecho superponiendo la vía y solo compartiendo los nodos. Esto lleva a que en algunos sitios hayan vías duplicadas, pero reduce el número de relaciones enormemente. Esto último ha sido una de las grandes pegas que nos han puesto en la lista de imports, con lo cual está mi duda. ¿Estamos haciéndolo bien? ¿no será mejor duplicar en algunos casos las vías con tal de que queden reduzcamos el número de relaciones? Quizá sea adecuado antes de tomar una decisión al respecto proponer a la lista de imports un fichero .osm generado, pero con la simplificación en la parte rural, que creo que es la más necesaria. Al fin y al cabo, la parte urbana se ha hecho *como debe hacerse*. Otro tema es lo del OSM-2.5D... 2º OSM-2.5D Ahora mismo estamos aprovechando toda la información que podemos de las alturas de los edificios. Esto provoca que se tengan que hacer una barbaridad de relaciones para tener en cuenta aleros, tejados, balcones, etc. Cómo aún no está nada claro el tema del 2.5D en osm, se podría incluir la referencia catastral en las constru y simplificarlas poniendo solo la unión de todas las geometrías de ese edificio. Con esto reducimos el número de relaciones otra vez más y si en algún momento queda claro como va a funcionar el 2.5D sólo hay que eliminar las geometrías con una referencia catastral y sustituirla por las que tenga la info 2.5D.La pregunta es, ¿nos peleamos por el 2.5D o simplificamos y ya lo haremos más adelante? Si la idea es *simplificar* quizá aquí podríamos dejar el esfuerzo del 2.5D para más adelante, subiendo por ahora sólo la silueta exterior de cada edificio (quizá con su altura máxima como altura de todo el edificio) con su referencia catastral para, en el futuro, cuando las herramientas que permitan manejar relaciones de manera ágil y masiva estén disponibles, proceder a realizar la importación de los datos 2.5D... 3º Simplificación de cultivos. La otra pata es la simplificación de cultivos que tengan los mismos tags, aquí habría que hacer lo mismo que con las constru, solo que en vez de agrupar por parcelas, hay que hacerlo por tipo de cultivo. En esta poca discusión puede haber. Esto creo que es obligado. Pues nada, ya nos direis. -- Cruz Enrique Borges Hernández Email: cruz.bor...@deusto.es DeustoTech Energy Telefono: 944139000 ext.2052 Avda. Universidades, 24 48007 Bilbao, Spain ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- David Marín Carreño dav...@gmail.com ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
El 07/05/2012 20:01, Rafael Avila Coya ravilac...@gmail.com escribió: On 07/05/12 18:59, Cruz Enrique Borges Hernández wrote: Buenas A la vista de lo que han comentado en la lista de import la última vez (y que nos han recordado amablemente este fin de semana) le hemos estado dando un par de vueltas ander y yo al tema. Hemos rellenado un par de issue en el tracker con las cosas que pensamos hacer cuando tengamos un rato. De todas formas, hay unas cuantas cuestiones que creo que es preferible discutirlas en la lista para que nos queden claras: Yo no estoy al tanto de los detalles en lo que a la discusión con imports se refiere, pero daré mi opinión. 1º Relaciones en geometrías compartidas. Jaime nos contó muy insistentemente que las geometrías compartidas por más de un edificio deben de construirse como una relación (tal y como estamos haciendo ahora mismo). Sin embargo, en París, se ha hecho Os recuerdo que en Girona se importaron como relaciones. superponiendo la vía y solo compartiendo los nodos. Esto lleva a que en algunos sitios hayan vías duplicadas, pero reduce el número de relaciones enormemente. Esto último ha sido una de las grandes pegas que nos han puesto en la lista de imports, con lo cual está mi duda. ¿Estamos haciéndolo bien? ¿no será mejor duplicar en algunos casos las vías con tal de que queden reduzcamos el número de relaciones? Yo insisto en que no entiendo qué problemas hay con las relaciones. Están ahí para algo, ¿no? Podría ponerse la pega de que es más fácil crear una hilera de casas adosadas usando vías que se superponen en las paredes de separación, pero son una solución cutre si se la compara a hacerlo con relaciones. Entre otras ventajas, las relaciones permiten reutilizar cada uno de los segmentos para futuras necesidades. Es, por lo tanto (y en mi opinión), una solución más elegante. Si la respuesta es que son muchas relaciones, no la entiendo, y creedme que lo intento. Si yo estoy de acuerdo. Aquí el problema está en que el cómo deberían de hacerse las cosas bien choca con lo que el servidor pueda soportar y lo que los editores permiten editar fácilmente (aunque yo lo llamaría lo que el limitado editor potlatch2 no puede hacer). Lo discutís con imports... 2º OSM-2.5D Ahora mismo estamos aprovechando toda la información que podemos de las alturas de los edificios. Esto provoca que se tengan que hacer una barbaridad de relaciones para tener en cuenta aleros, tejados, balcones, etc. Cómo aún no está nada claro el tema del 2.5D en osm, se podría incluir la referencia catastral en las constru y simplificarlas poniendo solo la unión de todas las geometrías de ese edificio. Con esto reducimos el número de relaciones otra vez más y si en algún momento queda claro como va a funcionar el 2.5D sólo hay que eliminar las geometrías con una referencia catastral y sustituirla por las que tenga la info 2.5D.La pregunta es, ¿nos peleamos por el 2.5D o simplificamos y ya lo haremos más adelante? La pega, que también sería válida para el punto 1º, es: ¿será fácil/viable incorporar esos datos más adelante? Anteayer envié un e-mail de respuesta en el hilo Bloqueo catastro_pontevedra que quizá no llegó a la lista por llevar adjunto un archivo de 2.2M (no sabía que el máximo eran 100k). En el proponía alguna alternativa de simplificación, que vuelvo a escribir aquí: -- En el issue 23 [se refiere a mejoras en cat2osm] pones [Cruz Enrique] que se podría renunciar a tags 3D. ¿Te refieres con eso a tags como building:height, building:min_height y building:levels? Si es así creo que sería mala idea, pues dejaría a proyectos como osm3D sin posibilidad de usarlos.[Como alternativa menos buena, aunque más simple] En caso de que cada parte del edificio tuviese diferentes valores para esos tags, se podría elegir un valor único para todo el edificio y para cada uno de esos tags. Por ejemplo, para el building:min_height se podría elegir el mínimo de ellos, para building:height se podría elegir el que resultase ser máximo, o un valor medio, y para building:levels el que resultase máximo. Habría que ver las distintas posibilidades complejas que se pueden dar. En todo caso, hay que tener en cuenta que se perdería info. Otra posibilidad sería eliminar (unir) aquellas partes que tienen tags 3D idénticos, y mantener separados los que no. Esto no haría perder info, y sí sería aceptable por todos, sin ninguna duda. --- Pero repito la gran duda: si se optan por soluciones como vías superpuestas como alternativa a usar relaciones, y si simplifican edificaciones perdiendo info. 3D (ó 2.5D), ¿sería fácil hacer más adelante una actualización/mejora, o habría que reacer todo de nuevo? ¡El trabajo ya es enorme en sí mismo, para aún pensar en una segunda fase! 3º Simplificación de cultivos. La otra pata es la simplificación de cultivos que tengan los mismos tags, aquí habría
Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.
El 7 de mayo de 2012 21:33, Jaime Crespo jy...@jynus.com escribió: El 07/05/2012 20:01, Rafael Avila Coya ravilac...@gmail.com escribió: On 07/05/12 18:59, Cruz Enrique Borges Hernández wrote: Buenas A la vista de lo que han comentado en la lista de import la última vez (y que nos han recordado amablemente este fin de semana) le hemos estado dando un par de vueltas ander y yo al tema. Hemos rellenado un par de issue en el tracker con las cosas que pensamos hacer cuando tengamos un rato. De todas formas, hay unas cuantas cuestiones que creo que es preferible discutirlas en la lista para que nos queden claras: Yo no estoy al tanto de los detalles en lo que a la discusión con imports se refiere, pero daré mi opinión. 1º Relaciones en geometrías compartidas. Jaime nos contó muy insistentemente que las geometrías compartidas por más de un edificio deben de construirse como una relación (tal y como estamos haciendo ahora mismo). Sin embargo, en París, se ha hecho Os recuerdo que en Girona se importaron como relaciones. superponiendo la vía y solo compartiendo los nodos. Esto lleva a que en algunos sitios hayan vías duplicadas, pero reduce el número de relaciones enormemente. Esto último ha sido una de las grandes pegas que nos han puesto en la lista de imports, con lo cual está mi duda. ¿Estamos haciéndolo bien? ¿no será mejor duplicar en algunos casos las vías con tal de que queden reduzcamos el número de relaciones? Yo insisto en que no entiendo qué problemas hay con las relaciones. Están ahí para algo, ¿no? Podría ponerse la pega de que es más fácil crear una hilera de casas adosadas usando vías que se superponen en las paredes de separación, pero son una solución cutre si se la compara a hacerlo con relaciones. Entre otras ventajas, las relaciones permiten reutilizar cada uno de los segmentos para futuras necesidades. Es, por lo tanto (y en mi opinión), una solución más elegante. Si la respuesta es que son muchas relaciones, no la entiendo, y creedme que lo intento. Si yo estoy de acuerdo. Aquí el problema está en que el cómo deberían de hacerse las cosas bien choca con lo que el servidor pueda soportar y lo que los editores permiten editar fácilmente (aunque yo lo llamaría lo que el limitado editor potlatch2 no puede hacer). Lo discutís con imports... 2º OSM-2.5D Ahora mismo estamos aprovechando toda la información que podemos de las alturas de los edificios. Esto provoca que se tengan que hacer una barbaridad de relaciones para tener en cuenta aleros, tejados, balcones, etc. Cómo aún no está nada claro el tema del 2.5D en osm, se podría incluir la referencia catastral en las constru y simplificarlas poniendo solo la unión de todas las geometrías de ese edificio. Con esto reducimos el número de relaciones otra vez más y si en algún momento queda claro como va a funcionar el 2.5D sólo hay que eliminar las geometrías con una referencia catastral y sustituirla por las que tenga la info 2.5D.La pregunta es, ¿nos peleamos por el 2.5D o simplificamos y ya lo haremos más adelante? La pega, que también sería válida para el punto 1º, es: ¿será fácil/viable incorporar esos datos más adelante? Anteayer envié un e-mail de respuesta en el hilo Bloqueo catastro_pontevedra que quizá no llegó a la lista por llevar adjunto un archivo de 2.2M (no sabía que el máximo eran 100k). En el proponía alguna alternativa de simplificación, que vuelvo a escribir aquí: -- En el issue 23 [se refiere a mejoras en cat2osm] pones [Cruz Enrique] que se podría renunciar a tags 3D. ¿Te refieres con eso a tags como building:height, building:min_height y building:levels? Si es así creo que sería mala idea, pues dejaría a proyectos como osm3D sin posibilidad de usarlos.[Como alternativa menos buena, aunque más simple] En caso de que cada parte del edificio tuviese diferentes valores para esos tags, se podría elegir un valor único para todo el edificio y para cada uno de esos tags. Por ejemplo, para el building:min_height se podría elegir el mínimo de ellos, para building:height se podría elegir el que resultase ser máximo, o un valor medio, y para building:levels el que resultase máximo. Habría que ver las distintas posibilidades complejas que se pueden dar. En todo caso, hay que tener en cuenta que se perdería info. Otra posibilidad sería eliminar (unir) aquellas partes que tienen tags 3D idénticos, y mantener separados los que no. Esto no haría perder info, y sí sería aceptable por todos, sin ninguna duda. --- Pero repito la gran duda: si se optan por soluciones como vías superpuestas como alternativa a usar relaciones, y si simplifican edificaciones perdiendo info. 3D (ó 2.5D), ¿sería fácil hacer más adelante una actualización/mejora, o habría que reacer todo de nuevo? ¡El trabajo ya es enorme en sí mismo,
