Re: [pgsql-es-ayuda] Topología Aplicada

Hola
Si, esa solución también la pensé (aún no la probé)
El circuito sería actualizar "la línea" (única o redundada para cada 'feature' manifestado por ahora en una tabla de tipo línea predio_ln; particular_ln; forestal_ln; mineral_ln) y a partir de esa actualización de geometría replicarlo en cada feature y construir (o reconstruir) los polígonos forestal, mineral, particular, predio; de los cuales la línea actualizada forma parte. En resumen actualizar la geometría de una línea y actualizar todos los elemento de los cuales esa línea forma parte.
En mi caso, sólo una categoría de líneas predio_ln tiene atributos, el resto es sólo gráfico de apoyo para poder construir los polígonos de cada categoría. De todas maneras, sería genial poder extenderlo por si aparecen más líneas con atributos.

En MicroStation la línea es única (similar, con sus salvedades, al modelo de OpenStreetMap) con uno o varios 'features' asignados y con ninguno, uno, o varias asociaciones a tablas. Por ello estoy buscando, dentro de Postgis, el hecho de no tener duplicada la geometría de un elemento (es lo que entiendo por lo que mencionas como "redundancia") en tantas tablas, ya que en definitiva la línea, como elemento geométrico, es la misma, tiene las mismas coordenadas que posteriormente formarán parte de uno o varios polígonos también. Para mi caso, los polígonos son los que tienen más atributos.

Gracias por el interés, sigo buscando alguna solución, si se les ocurre algo más, será bienvenido.
Saludos

En Fri, 21 Apr 2017 10:09:27 -0300, jvenegasperu . <jvenegasperu(at)gmail(dot)com> escribió:

> En ese caso seria una tabla de líneas y una tabla intermedia para unirla
> con las categorías solo que en mi caso no logre la actualización de los
> campos desde una vista que se muestre en el editor geométrico en mi caso
> qgis el otro detalle es que en mi experiencia cuando se trabaja en qgis
> desde vistas el performance es muy pobre yo cuando necesito vistas uso
> vistas materializadas que se actualizan cada par de horas y la edición en
> qgis siempre es sobre una tabla directamente así puedo editar geometría y
> datos muy rápido hay usuarios que editan las tablas directamente y otros
> que mirar las vistas materializadas el caso que planteas de una sola tabla
> y categorías lo pense y al final decidí redundancia de datos en diferentes
> tablas ya que me da mejor experiencia de usuario y no es una simple linea a
> la que despues se le actualiza datos en otra tabla unido por un código
> quizá con vistas y gvsig funcione y asi evitas la redundancia yo me decidí
> por qgis por su plugins de edición así q tuve q tomar la opción de la
> redundancia actualizando con el trigger q te comente si te funciona con
> gvsig y vistas por favor comenta como me interesaría intentar aunque sea
> como prueba de laboratorio ya que no lo logre con qgis la lectura de la
> vista era súper lento y la edición desde la vista siempre me dio error tras
> error que no pude solucionar en cambio con la redundancia funciona bastante
> bien
>
> El 21 abr. 2017 06:58, "Néstor Ramires" <nramire1(at)rosario(dot)gov(dot)ar> escribió:
>
>> Hola
>> Es exactamente eso, con el agregado de que la tabla (capa) de entrada
>> puede ser cualquiera de las tres, cuatro o más, dependiendo de la categoría
>> a que pertenezca la línea.
>> Por eso, estuve pensando en una unica tabla de lineas y luego crear tipo
>> vistas con cada clasificación. De esa manera el dato de geometría (Que
>> luego se editará con algún software gráfico gvsig, Qgis) sólo se "tocaría"
>> una vez.
>> Gracias por la punta. Si tienen alguna otra sugerencia será bienvenida.
>> Saludos
>>
>>
>> En Thu, 20 Apr 2017 16:48:07 -0300, jvenegasperu . <jvenegasperu(at)gmail(dot)com>
>> escribió:
>>
>> Nestor
>>>
>>> si estoy entendiendo bien lo que quieres hacer es que si tu modificas la
>>> geometria de la tabla forestal_ln se modifique tambien las geometrias de
>>> las demas tablas particular_ln, mineral_ln por un id o campo en comun etc
>>>
>>> Si ese es tu objetivo eso lo resuelves simplemente colocando un trigger en
>>> la tabla forestal_ln y dentro que te modifique las demas tablas que
>>> necesites, algo como
>>>
>>> CREATE TRIGGER nombre_XXXXXXXXXX
>>> BEFORE UPDATE OF the_geom -- este es el nombre de tu campo geometria
>>> ON forestal_ln -- es el nombre de tu tabla que tiene el campo geometria
>>> FOR EACH ROW -- por cada registro
>>> EXECUTE PROCEDURE nombre_xxxxxx(); -- nombre de la funcion que
>>> ejecutaras
>>> y donde colocaras los updates de las tablas que quieres modificar.
>>>
>>> la razon de hacer un <BEFORE UPDATE OF the_geom" > es que el trigger se
>>> ejecute solo cuando se modifique el campo geometria si solo colocas before
>>> update si alguien cambia un campo alfanumerico tambien se ejecutara la
>>> función y podria comenzar a convertirse en algo costoso.
>>>
>>> saludos
>>>
>>> Espero haber entendido lo que quieres hacer.
>>>
>>>
>>>
>>>
>>>
>>>
>>> El 20 de abril de 2017, 12:07, Gerardo Herzig <gherzig(at)fmed(dot)uba(dot)ar>
>>> escribió:
>>>
>>>
>>>>
>>>> ----- Mensaje original -----
>>>> > De: "Néstor Ramires" <nramire1(at)rosario(dot)gov(dot)ar>
>>>> > Para: pgsql-es-ayuda(at)postgresql(dot)org
>>>> > Enviados: Jueves, 20 de Abril 2017 11:35:30
>>>> > Asunto: [pgsql-es-ayuda] Topología Aplicada
>>>> >
>>>> >
>>>> > Hola. Ante todo, vengo de trabajar en MicroStation Geographics, mi
>>>> > intención es migrar toda la información a una base de datos postgis
>>>> > y en ese tramo se me presentó este problema.
>>>> >
>>>>
>>>> Creo que tendras mejor suerte probando en un foro de postgis. Por ej:
>>>> http://lists.osgeo.org/mailman/listinfo/postgis-users (foro oficial)
>>>>
>>>> Saludos,
>>>> Gerardo
>>>>
>>>> -
>>>> Enviado a la lista de correo pgsql-es-ayuda (
>>>> pgsql-es-ayuda(at)postgresql(dot)org
>>>> )
>>>> Para cambiar tu suscripción:
>>>> http://www.postgresql.org/mailpref/pgsql-es-ayuda
>>>>
>>>>
>>>
>>>

-
Enviado a la lista de correo pgsql-es-ayuda (pgsql-es-ayuda(at)postgresql(dot)org)
Para cambiar tu suscripcin:
http://www.postgresql.org/mailpref/pgsql-es-ayuda