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 . <jvenegasp...@gmail.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" <nrami...@rosario.gov.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 . <jvenegasp...@gmail.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 <gher...@fmed.uba.ar>
escribió:
----- Mensaje original -----
> De: "Néstor Ramires" <nrami...@rosario.gov.ar>
> Para: pgsql-es-ayuda@postgresql.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@postgresql.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@postgresql.org)
Para cambiar tu suscripci�n:
http://www.postgresql.org/mailpref/pgsql-es-ayuda
