swisstierrascolombia / ladm_col Goto Github PK

1. LA_Interesado está definido como clase abstracta
   En la prueba de conformidad para el nivel 1 A.2.4 en la norma ISO 19.152:2012 se dice que "si se implementa LA_Party", se debe asegurar que existe al menos una clase conforme con la definición de LA_Party (OJO, la versión AENOR que hemos comprado, traducción al español de la versión inglesa de la norma Europea del CEN EN ISO 19152, contiene un error de traducción, donde se asegura que para que pase la prueba de conformidad la clase LA_Party, debe comprobarse la implementación de ¡¡LA_BAUnit!!)

Pues bien, la clase LA_Party de LADM no está definida como clase abstracta, por tanto, la definición en el esquema de aplicación (LADM-COL) no debe considerarse conforme.

CONSIDERACIÓN: dado que la norma dice que debe existir al menos una clase conforme con la definición de LA_Party, podrían tomarse las clases extendidas desde la abstracta LA_Interesados, en concreto la de interesados naturales y la de jurídicos, como clases como clases conformes. No obstante, se quiere poner aquí toda la temática a discutir.

2. El atributo "type" de LA_Party es obligatorio.
   En el esquema de aplicación, este atributo se ha definido como "Tipo", también obligatorio, pero tal y como está definido el paquete de Interesados, es innecesario.
   Efectivamente, en el paquete existen dos clases, interesado natural y jurídico, que hacen innecesaria la presencia del atributo en cuestión (Tipo), que a su vez no puede eliminarse porque si no LA_Party no pasaría la prueba de conformidad, el paquete no sería conforme y por tanto, el perfil tampoco lo sería en el nivel 1.

3. LADM no está pensado para gestionar datos de los interesados (ver introducción de la ISO 19152)
   Se están incluyendo como parte del perfil LADM-COL clases cuyo objetivo es gestionar datos de interesados. Esta estructura, además, es la que causa que la clase de interesados del esquema de aplicación colombiano esté definida como abstracta y que el atributo obligatorio "Tipo" pierda sentido.

EN CONCLUSIÓN:
Para que el perfil colombiano sea conforme a la norma, en el nivel 1 (y por tanto en los superiores), es preciso una definición conforme de la clase que representa a LA_Party. Esto implica que debe ser una clase concreta y contener el atributo Tipo como obligatorio.
Para conseguir esto, debe cambiarse la estructura de gestión de datos de interesados.
Para ello, se propone crear una estructura ajena a LADM, lo cual no sólo permitiría conseguir lo anterior, si no además cumplir con la premisa de que LADM no está pensado para gestionar esos datos.

Actualmente el modelo contempla una relación de 1 a muchos desde LA_Agrupacion_Interesados, pero pueden existir casos en los cuales hayan varias Agrupaciones de interesados donde un interesado natural o jurídico haga parte. Sería bueno contemplar una relación de muchos a muchos para que el modelo acepte esta particularidad.

Actualmente se encuentra así:

Podría estar así:

Buenas tardes, por mas que intento subir la memoria asignada al jar ili2pg-4.6.1.jar desde model baker no me deja y el XTF que intento importar es muy pesado (2GB) .

log:
"C:\Program Files (x86)\Common Files\Oracle\Java\javapath\java.exe" -jar C:\Users\Jonhatan\AppData\Roaming\QGIS\QGIS3\profiles\default\python\plugins\QgisModelBaker\libili2db\bin\ili2pg-4.6.1\ili2pg-4.6.1.jar --import --dbhost localhost --dbport 5432 --dbusr postgres --dbpwd ****** --dbdatabase PREDIUM --dbschema ric_bello --coalesceCatalogueRef --createEnumTabs --createNumChecks --createUnique --createFk --createFkIdx --coalesceMultiSurface --coalesceMultiLine --coalesceMultiPoint --coalesceArray --beautifyEnumDispName --createGeomIdx --createMetaInfo --expandMultilingual --createTypeConstraint --createEnumTabsWithId --createTidCol --importTid --smart2Inheritance --strokeArcs --defaultSrsCode 2056 --modeldir "E:\BACKUP 2016\MODELO LADM_COL\UML RIC" E:/CINTELI/BELLO/XTF_BELLO_2022_10_31.xtf
Info: dburl jdbc:postgresql://localhost:5432/PREDIUM
Info: dbusr
Info: ili2pg-4.6.1-63db90def1260a503f0f2d4cb846686cd4851184
Info: ili2c-5.2.3-3ec7a10e9bacc87e149a14a7f11a6035e0481c69
Info: iox-ili-1.21.8-a6aee68136447c0616995e56888fa9c7ef362a77
Info: java.version 1.8.0_311
Info: user.name
Info: maxMemory 253440 KB
Info: currentTime 2023-03-02 16:07:22
Info: dbschema <ric_bello>
Info: dburl jdbc:postgresql://localhost:5432/PREDIUM
Info: dbusr
Info: databaseProduct
Info: databaseVersion <14.1>
Info: driverName
Info: driverVersion <42.2.18.jre6>
Info: postGISVersion <POSTGIS="3.1.4 3.1.4" [EXTENSION] PGSQL="140" GEOS="3.9.1-CAPI-1.14.1" PROJ="7.1.1" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 (Internal)" TOPOLOGY>
Info: compile models...
Info: lookup model <Modelo_Aplicacion_LADMCOL_RIC_V0_1> 2.3 in repository <E:\BACKUP 2016\MODELO LADM_COL\UML RIC/>
line 1:1: unexpected token: PK
Warning: E:\BACKUP 2016\MODELO LADM_COL\UML RIC\UML RIC.ili: failed to scan file (unexpected char: 0x3); file ignored
Info: lookup model <ISO19107_PLANAS_V3_0> 2.3 in repository <E:\BACKUP 2016\MODELO LADM_COL\UML RIC/>
Info: lookup model <LADM_COL_V3_1> 2.3 in repository <E:\BACKUP 2016\MODELO LADM_COL\UML RIC/>
Info: ilifile <E:\BACKUP 2016\MODELO LADM_COL\UML RIC\ISO19107_PLANAS_V3_0.ili>
Info: ilifile <E:\BACKUP 2016\MODELO LADM_COL\UML RIC\LADM_COL_V3_1.ili>
Info: ilifile <E:\BACKUP 2016\MODELO LADM_COL\UML RIC\Modelo_Aplicacion_LADMCOL_RIC_V0_1.ili>
Info: process data file...
Info: data <E:/CINTELI/BELLO/XTF_BELLO_2022_10_31.xtf>
Info: assume unknown external objects
Info: first validation pass...
Info: Basket Modelo_Aplicacion_LADMCOL_RIC_V0_1.RIC(oid Modelo_Aplicacion_LADMCOL_RIC_V0_1.RIC)...
Exception in thread "main"
java.lang.OutOfMemoryError: Java heap space
at java.util.Arrays.copyOf(Unknown Source)
at java.io.ByteArrayOutputStream.grow(Unknown Source)
at java.io.ByteArrayOutputStream.ensureCapacity(Unknown Source)
at java.io.ByteArrayOutputStream.write(Unknown Source)
at java.io.OutputStream.write(Unknown Source)
at ch.ehi.iox.objpool.impl.btree.BTree.getNode(BTree.java:107)
at ch.ehi.iox.objpool.impl.btree.BTree.search(BTree.java:201)
at ch.ehi.iox.objpool.impl.btree.BTree.search(BTree.java:201)
at ch.ehi.iox.objpool.impl.btree.BTree.get(BTree.java:184)
at ch.ehi.iox.objpool.impl.BTreeImpl.containsKey(BTreeImpl.java:89)
at ch.interlis.iox_j.validator.LinkPool.increaseCounter(LinkPool.java:61)
at ch.interlis.iox_j.validator.LinkPool.addLink(LinkPool.java:37)
at ch.interlis.iox_j.validator.Validator.validateObject(Validator.java:3224)
at ch.interlis.iox_j.validator.Validator.validate(Validator.java:352)
at ch.ehi.ili2db.fromxtf.TransferFromXtf.doit(TransferFromXtf.java:618)
at ch.ehi.ili2db.base.Ili2db.transferFromXtf(Ili2db.java:2335)
at ch.ehi.ili2db.base.Ili2db.runUpdate(Ili2db.java:743)
at ch.ehi.ili2db.base.Ili2db.run(Ili2db.java:209)
at ch.ehi.ili2db.AbstractMain.domain(AbstractMain.java:639)
at ch.ehi.ili2pg.PgMain.main(PgMain.java:72)
Finished (1)

buenas tardes, tengo esta duda, llega esta observación, pero la tabla fuente espacial y fuente administrativa contiene datos, se adjunta foto con las tablas.

Buen día, quisiera que por favor me indicaran a qué se refiere la clase Ofertas Mercado Inmobiliario, dado que no me queda claro si se trata de la existencia de oferta de venta o arriendo en el predio a levantar o si son ofertas de predios con características similares a este y que luego puedan usarse en la determinación de su avalúo.

Agradezco su atención.

Para efectos de no generar inconsistencias en el diligenciamiento de este atributo, considero que podría cambiarse el tipo de dato de Booleano por un dominio donde se encuentre: Formal e Informal.

Actualmente el modelo permite el almacenamiento del atributo nombre en las clases relacionadas con interesados; ya sea por medio del atributo "Razon_Social" de la clase "Interesado_Juridico", de los diferentes atributos concernientes al nombre en la clase "Interesado_Natural" o del atributo "Nombre" en la clase abstracta LA_Interesado. Pero en los casos en los que un interesado cambia su nombre o razón social, no existe una forma de asociar el nuevo nombre al registro del interesado en cuestión, ya que esto es posible mapearlo con el modelo actual, únicamente usando la herencia de la clase "ObjetoVersionado", lo que quiere decir crear un nuevo registro y finalizar la vida util del anterior.

Me parece que este comportamiento puede mejorarse, al asociar un interesado natural o juridico con una clase que contenga los datos del nombre del interesado y pueda guardar su histórico. Por lo tanto esta relación debe tener cardinalidad 1..* y la clase debe heredar de ObjetoVersionado, tal como se muestra a continuación:

De esta manera sería posible hacer cambios en el nombre del interesado, se tendría acceso a su histórico de cambios y siempre estarían asociados al mismo registro de Interesado sin tener que crear uno nuevo.