Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-11 Por tema Cruz Enrique Borges 
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
> 
> escribió:
> > 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.

2012-05-11 Por tema David Marín Carreño 
El 11 de mayo de 2012 07:59, Cruz Enrique Borges
escribió:

> 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 
___
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.

2012-05-10 Por tema Cruz Enrique Borges 
> 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.

2012-05-10 Por tema Javier Sánchez 
Hola

El día 9 de mayo de 2012 07:11, Cruz Enrique Borges
 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.

2012-05-10 Por tema David Marín Carreño 
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"  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" 
> 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.

2012-05-10 Por tema pcvalverde 
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" 

To: "Discusión en Español de OpenStreetMap" 
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.

2012-05-09 Por tema Cruz Enrique Borges 
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

Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-09 Por tema Matías Taborda Barroso 
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.

2012-05-08 Por tema Cruz Enrique Borges 
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.

2012-05-08 Por tema Rafael Avila Coya 
Yo entiendo bien lo que dices y estoy de acuerdo en todo ello.

Me parece excelente idea lo de unir landuses a ambos lados de vía
cuando coinciden, para reducir aún más las relaciones. Aunque, como
dices, no sé si será factible... Ya dirán los desarrolladores de cat2osm.

Lo de unir parcelas adyacentes con landuse igual debería, por
coherencia, incluir las residenciales, también está claro.

Un saludo.

On 08/05/12 22:35, Javier Sánchez wrote:
> 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.
> 
> 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, 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.
> 
> No se si me he explicado. Si no lo he conseguido me dicen y mando 
> alguna imagen para aclararlo.
> 
> Saludos.
> 
> El día 8 de mayo de 2012 12:57, Jorge Sanz Sanfructuoso 
>  escribió:
>> 
>> 
>> El 8 de mayo de 2012 13:37, Rafael Avila Coya
>>  escribió:
>> 
>>> -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.
>> 
>> 
>> La idea de esto es para quitar relaciones y al final no las
>> quitas. En los pueblos no tanto pero en ciudades si dibujas los
>> patios interiores al final la mayor parte de los edificios siguen
>> teniendo una relación así que lo veo absurdo. En Salamanca lo
>> po

Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-08 Por tema Javier Sánchez 
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.

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, 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.

No se si me he explicado. Si no lo he conseguido me dicen y mando
alguna imagen para aclararlo.

Saludos.

El día 8 de mayo de 2012 12:57, Jorge Sanz Sanfructuoso
 escribió:
>
>
> El 8 de mayo de 2012 13:37, Rafael Avila Coya 
> escribió:
>
>> -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.
>
>
> La idea de esto es para quitar relaciones y al final no las quitas. En los
> pueblos no tanto pero en ciudades si dibujas los patios interiores al final
> la mayor parte de los edificios siguen teniendo una relación así que lo veo
> absurdo. En Salamanca lo podeis ver
> http://www.openstreetmap.org/?lat=40.972785&lon=-5.658122&zoom=18&layers=M
> que lo estado haciendo a mano todo con relaciones pero si mirais una gran
> cantidad de edificios tienen patios interiores. Si tienes que hacer las
> relaciones igualmente ya se hacen bien hechas no a medias.
>
>>
>>
>> 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.
>
>
> No he visto lo de impor

Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-08 Por tema Jorge Sanz Sanfructuoso 
El 8 de mayo de 2012 13:37, Rafael Avila Coya escribió:

> -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.
>

La idea de esto es para quitar relaciones y al final no las quitas. En los
pueblos no tanto pero en ciudades si dibujas los patios interiores al final
la mayor parte de los edificios siguen teniendo una relación así que lo veo
absurdo. En Salamanca lo podeis ver
http://www.openstreetmap.org/?lat=40.972785&lon=-5.658122&zoom=18&layers=Mque
lo estado haciendo a mano todo con relaciones pero si mirais una gran
cantidad de edificios tienen patios interiores. Si tienes que hacer las
relaciones igualmente ya se hacen bien hechas no a medias.


>
> 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.
>

No he visto lo de imports porque el ingles no es para mi pero creo que van
mas los tiros por las relaciones del 3D y no de los edificios en si. En
Girona se hizo con relaciones y no tubieron pegas y ahi estan los datos sin
problemas. Yo iria mas por mirar la posibilidad de quitar alerones y
disminuir el numero de datos del 3D con esas 3 etiquetas en la misma
relación que el edificio. Con eso creo que deberían quitar las pegas de las
relaciones.

>
> 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  > > escribió:
> >
> >
> > El 07/05/2012 20:01, "Rafael Avila Coya"  > > 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
> >>>

Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-08 Por tema Rafael Avila Coya 
-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  > escribió:
> 
> 
> El 07/05/2012 20:01, "Rafael Avila Coya"  > 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",

Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-07 Por tema David 
El 7 de mayo de 2012 21:33, Jaime Crespo  escribió:

>
> El 07/05/2012 20:01, "Rafael Avila Coya"  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

Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-07 Por tema Jaime Crespo 
El 07/05/2012 20:01, "Rafael Avila Coya"  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!
>
> >
> >

Re: [Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-07 Por tema Jorge Sanz Sanfructuoso 
El lunes 7 de mayo de 2012, Cruz Enrique Borges Hernández escribió:

> 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:
>
> 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?
>
>
Como ya han dicho otros creo que lo correcto son las relaciones. Que la
otra manera es mas facil para principiantes en OSM? Pues si pero hay que
buscar lo mas correcto no lo facil. Ademas si es complicado parte es culpa
del editor JOSM o el que se use no de los datos.


> 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?


Esto ya es mas discutible. Yo tengo unas ganas enormes de tener edificios
en 3 dimensiones y si se puede soy patidario de ponerlo. Pero tambien es
verdad que no esta claro este tema. Pero tambien como han dicho si no se
suben ahora estos datos y hay que subirlos despues seria trabajo doble y ya
bastante trabajo hay de primeras.
 Si se empeñan en quitar relaciones estas son las que se deberian quitar,
son las unicas que puedo considerar que sobran ya que el 3D no esta todavia
correctamente implantado.

>
> 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.


En este caso creo que es necesario totalmente y luego ya a mano la gente de
la zona que dibuje vallas, muros... Cuando los vea insitu.

>
> 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
>


-- 
Jorge Sanz Sanfructuoso - Sanchi
Blog http://blog.jorgesanzs.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.

2012-05-07 Por tema David Marín Carreño 
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 
___
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.

2012-05-07 Por tema Rafael Avila Coya 
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

[Talk-es] [CATASTRO] Simplificación de geometría de las constru.

2012-05-07 Por tema Cruz Enrique Borges Hernández 
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:

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?

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?

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.

-- 
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