[Gvsig_usuarios] Edición de DBF.
Francisco José Peñarrubia
fpenarru en gmail.com
Lun Dic 17 09:53:44 CET 2007
Hola Ximo. (Perdón al resto de usuarios por el tema de este correo,
sería más propio de la lista de desarrolladors)
Hay librerías para leer y escribir DBF dentro de gvSIG. Además, las
puedes usar desde fuera de gvSIG, casi aisladas del todo, o con las
dependencias de FMap, o dentro de gvSIG.
En el modo más aislado, tendrás la dependencia de IverUtiles.jar y las
librerías dbf.jar y dbfWriter.jar que hay en
gvSIG/extensiones/com.iver.cit.gvsig/drivers/dbf.
Mira las clases DBaseFileWriterNIO y DBaseFile.java.
En el modo más integrado con FMap y gvSIG, necesitarás GDBMS, y FMap
como mínimo, más las otras que te he dicho.
Mira las clases DBFDriver y DbfWriter.
Un ejemplo pequeñito de uso:
DbaseFile driver = new DbaseFile();
String dbfPath = "c:/0libro.dbf";
File myFile = new File(dbfPath);
try {
// Abrimos el fichero
driver.open(myFile);
driver.setFieldValue(1,0, new Integer(54));
System.out.println("Valor nuevo:" +
driver.getStringFieldValue(1,0));
driver.close();
}
catch (Exception e)
{
e.printStackTrace();
}
Con eso editas la fila 1 y el campo 0 de una tabla, escribiendo un 54.
Ojo con los tipos de campos, etc.
Un ejemplo más integrado con FMap:
DBFDriver driver = new DBFDriver();
File myFile = new File("c:/0libro.dbf");
try {
// Abrimos el fichero
driver.open(myFile);
// Comprobamos que tenemos acceso de escritura.
if (driver.canSaveEdits())
{
// Creamos el nuevo campo
FieldDescription dateField = new FieldDescription();
dateField.setFieldName("Date");
dateField.setFieldType(Types.VARCHAR);
dateField.setFieldLength(20);
// Creamos un array con el nuevo campo
ITableDefinition tableDef = driver.getTableDefinition();
FieldDescription[] oldFields = tableDef.getFieldsDesc();
int numOldFields = oldFields.length;
FieldDescription[] newFields = new
FieldDescription[numOldFields + 1];
System.arraycopy(oldFields, 0, newFields, 0, numOldFields);
newFields[numOldFields] = dateField;
tableDef.setFieldsDesc(newFields);
driver.initialize(tableDef);
driver.preProcess();
Value[] att = new Value[newFields.length];
Calendar today = Calendar.getInstance();
for (int i=0; i < driver.getRowCount(); i++)
{
for (int j=0; j < numOldFields; j++)
{
att[j] = driver.getFieldValue(i, j);
}
att[numOldFields] =
ValueFactory.createValue(today.getTime().toLocaleString());
DefaultRow row = new DefaultRow(att);
DefaultRowEdited edRow = new DefaultRowEdited(row,
DefaultRowEdited.STATUS_MODIFIED, i);
driver.process(edRow);
}
driver.postProcess();
System.out.println("Fichero modificado");
}
else
{
System.err.println("El fichero no tiene permiso de
edición");
}
driver.close();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (EditionException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (DriverException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
Espero que te sirva.
Saludos.
Fran Peñarrubia.
Joaquín Izquierdo Roger escribió:
> ¡Gracias!
>
> Bueno, un comentario rápido pero creo que ya es hora de que me apunte
> a la lista de desarrolladores...
> Pues empecé con SAX, pero descubrí jDOM y como ví que efectivamente
> era facilito lo he hecho con
> eso, aunque no se tragaba las 100 megas, así que leo el archivo de
> texto "a mano" y extraigo registro a
> registro (con cada registro hago un subdocumento XML que paso al jDOM
> para extraer los campos
> usando el XPath que lleva integrado).
> Pero gracias con tus sugerencias, miraré KXML y Castor, si el objetivo
> final es integrar esto en gvSIG
> será cosa de usar las librerías que ya vengan con la distribución.
> Estoy empezando con Java, y lógicamente el problema no es la sintaxis
> o el paradigma de programación,
> sino saber qué tienes disponible, con centenares de paquetes y miles
> de objetos listos para usar en la
> distribución estándar vas un poco perdido, eso sin entrar en las
> librerías de terceros...
>
> Bien, definitivamente creo que me paso a la lista de desarrolladores,
> aunque ahora mismo no me vaya
> a poner a escrbir plug-ins para gvSIG, será mejor empezar a usar las
> mismas tecnologías del proyecto
> para facilitar la integración en un futuro.
>
> Si se puede contestar rápido... ¿DBF con jdbc y a base de SQL y
> compañía? ¿o hay librerías
> específicas?
>
> ¡Saludos!
>
>
> Jorge Sanz escribió:
>>
>> Hola,
>>
>> bueno este es un tema que caería mejor en la lista de
>> desarrolladores, pero vaya, ahí van mis dos centimicos sobre acceso a
>> XML en java.
>>
>> Joaquín en gvSIG se trabaja en general con KXML[1] como biblioteca
>> java para parsear XMLs, una vez pillado el punto es bastante sencillo
>> y realmente rápido por lo que dudo que tengas problemas en el parseo
>> del XML.
>>
>> Otra opción que tienes para transformar XML a texto plano es utilizar
>> transformaciones XSLT[2], no es sencillo, pero supongo que generar
>> texto plano debe de ser de lo más fácil en esa tecnología.
>>
>> Una tercera tecnología que puedes utilizar (y en gvSIG también se
>> emplea) es Castor[3]. Si tienes el esquema XSD de los ficheros XML de
>> catastro con Castor puedes generar de forma automatizada el parser
>> (marshaller si no me equivoco en terminología Castor) y una vez hecho
>> esto, parsear el XML es realmente trivial. En este caso el problema
>> puede ser el rendimiento, 100MB es mucho y no sé como iría, pero creo
>> que vale la pena intentarlo por el pequeño esfuerzo que significa
>> intentarlo.
>>
>> Y la última opción es JDOM[4], tampoco te va a dar un rendimiento muy
>> bueno, pero es muy sencillo de utilizar y tal vez te sirva también
>> para salir del paso.
>>
>> Seguro que hay muchas más, a ver si alguien más opina sobre este
>> asunto (y aprendo un poco :P)
>>
>> En cuanto a generar DBF, en gvSIG se trabaja *mucho* con DBF por
>> razones obvias (shapes) y seguro que en esta lista (o mejor en la de
>> desarrollo) te pueden echar un cable.
>>
>> En fin, yo te animaría a que te "atrevas" a programar esto con gvSIG,
>> una vez montado el entorno de desarrollo (eclipse) y el espacio de
>> trabajo de gvSIG (los fuentes) vas a tener toneladas de código en el
>> que ver cosas como las que quieres hacer y más. Es sólo cuestión de
>> encontrar dónde está, y en eso te podemos echar un cable ;)
>>
>> Un saludo
>> [1]http://kxml.sourceforge.net/
>> [2]http://en.wikipedia.org/wiki/XSL_Transformations
>> [3]http://www.castor.org/
>> [4]http://www.jdom.org/
>>
>> Jorge Gaspar Sanz Salinas
>> Ingeniero en Geodesia y Cartografía
>> Prodevelop S.L. - Valencia - España
>> Tlf.: 96.351.06.12 - Fax: 96.351.09.68
>> jsanz[en]prodevelop[punto]es
>> http://www.prodevelop.es
>>
>>
>>
>> -----Mensaje original-----
>> De: gvsig_usuarios-bounces en runas.cap.gva.es en nombre de Joaquín
>> Izquierdo Roger
>> Enviado el: jue 13/12/2007 8:46
>> Para: Lista de Usuarios de gvSIG
>> Asunto: Re: [Gvsig_usuarios] Datos catastrales ¿se pueden o podrían
>> importar en gvsig?
>>
>> Hola Antonio, una cosa, deberías haber cambiado el asunto en tu
>> primera consulta, ahora ya te
>> he visto ;-)
>>
>> Yo trabajo en el ayuntamiento de Benicàssim, así que también tenemos
>> esta problemática.
>> Yo estoy en urbanismo pero la cartografía base suele ser la de catastro.
>>
>> Bueno, nosotros leemos el padrón por dos lados, por uno lo lee
>> Rentas, utilizando la aplicación
>> de TAO, que seguramente te sonará, ¿no tenéis algo parecido? Si
>> tenéis algo así se puede por
>> ejemplo hacer una exportación a una base de datos externa, a mí me lo
>> pasaban en Microsoft
>> Access (TAO usaba Access como frot-end, aunque la base de datos la
>> tenemos en Oracle),
>> y yo me lo pasaba a dBase para manejarlo en el ArcView 3 o el gvSIG.
>> Si tenéis una empresa externa que os saque los recibos del IBI, o lo
>> lleva Diputación, ellos de
>> alguna manera tendrán que leer las cintas de Catastro, podríais
>> pedirles que cuando hagan
>> una importación os pasen una exportación a un formato que podáis
>> manejar.
>>
>> Por otro lado como lo de TAO modifica un poco los datos, por su
>> "modelo-ciudad", acabé
>> programándome un importador en ArcView3, pero sólo funciona para los
>> archivos en
>> formato texto plano, ahora que las nuevas versiones vendrán en XML la
>> cosa va a cambiar
>> radicalmente. Ya tenía hecho el importador a DBF del PAD versión
>> 27/12/2006 (van cambiando
>> el formato cada dos por tres), que en realidad aunque sólo sea un
>> fichero son dos tablas
>> diferentes: las unidades de urbana (sólo manejo urbana) del Padrón (o
>> cargos) y la tabla de
>> titulares catastrales, pues en las nuevas versiones ya se contempla
>> la posibilidad de almacenar
>> varios titulares para un solo cargo.
>>
>> Me disponía a crear el programa para importar las 7 tablas de la FIN,
>> pero decidimos dejar el
>> proyecto porque precisamente entre el año pasado y este hemos tenido
>> una revisión catastral
>> global, con lo que quedaron paralizadas las altas, y encima en medio
>> del proceso iba a producirse
>> el cambio de formatos de intercambio a XML, y además se van a
>> producir mejoras en la
>> Oficina Virtual para que los ayuntamientos hagamos intercambios con
>> Catastro, así que estamos
>> a la espectativa de ver cómo se desarrollan estos cambios, de hecho
>> la semana que viene tenemos
>> reunión en la Delegación de Castellón de Catastro para hablar de
>> estos temas.
>>
>> Ahora estoy mirando Java (en el cual soy un neófito) y gestión de XML
>> gigantes (¡el XML que
>> me han pasado de pruebas es de más de 100 megas!, y eso sólo es el
>> padrón, la FIN no me la
>> quiero imaginar) y pretendo crear un conversor XML->fichero plano
>> para luego crear el DBF
>> desde Arcview con lo que ya tengo hecho, más adelante estudiaré el
>> tema de generar
>> directamente los DBF desde Java, pero primero procesar el XML, poco a
>> poco.
>> La idea del Java es con miras a un posible integración con gvSIG,
>> pero eso vendría al final,
>> y ahora aún estamos con "la revisión de la revisión".
>>
>> Así que así está el tema, ¿tu PADURB 2006 es XML o aún texto plano?
>> Si es el formato en
>> texto plano del 27/12/06 y tienes ArcView 3 mándame un mail y
>> hablamos del tema...
>>
>> ¡Saludos!
>>
>>
>>
>>
>>
>>
>> Antonio Garcia escribió:
>>
>> No se si me he explicado bien:
>> Me han enviado de catastro los ficheros vectoriales:
>> en formato shp y FICC.
>> y en alfanumérico: (los datos de los titulares
>> catastrales) en formato finurb y padrus, padrus.
>> Tengo entendido que los ficheros finurb, han modificado de
>> formato de finurb98 a finurb2006.
>> ¿Con que programa podría leer los datos alfanuméricos
>> finurb, padrus o padrurb? ya que quiero cruzar los datos shp o FICC
>> (que los exporto a cad) con los titulares catastrales.
>> Saludos,
>> ---------------------------------
>> Antonio García Benlloch
>> Ingeniero Técnico en Topografía
>> Ingeniero en Geodesia y Cartografía
>> Ayuntamiento de Bétera.
>> C/ José Gascón Sirera, 9
>> C.P.: 46117 Bétera, (Valencia, Spain)
>> Teléfono: 961600351 Extensión: 166
>> Fax: 961690924
>> Correo electrónico: topografo en betera-ayto.com
>> Páginas web:
>> www.betera.es <http://www.betera.es/>
>> www.btsig.es <http://www.btsig.es/>
>>
>> ________________________________
>>
>> From: angarben en hotmail.com
>> To: gvsig_usuarios en runas.cap.gva.es
>> Date: Tue, 11 Dec 2007 21:06:10 +0000
>> Subject: [Gvsig_usuarios] Datos catastrales ¿se
>> pueden o podrían importar en gvsig?
>> Hola, alguien puede
>> decirme como puedo convertir los datos catastrales procedentes del
>> fichero Finurb o bien padrus o padurb. Estos son formatos oficiales
>> de catastro.
>> ¿Podría gvsig cargar en un futuro
>> estos formatos? Estaría genial.
>> Quiero cruzar los titulares
>> catastrales con sus parcelas para la obtención de titulares por zona
>> Tengo entendido que con software de
>> autodesk es posible y por lo visto geopista también lo hace. Pero no
>> tengo ninguno estos softwares.
>> ¿Existe algún programa que edite esos
>> datos y los transfome a una base de datos de Access, por ejemplo?
>> Saludos,
>> ---------------------------------
>> Antonio García Benlloch
>> Ingeniero Técnico en Topografía
>> Ingeniero en Geodesia y Cartografía
>> Ayuntamiento de Bétera.
>> C/ José Gascón Sirera, 9
>> C.P.: 46117 Bétera, (Valencia, Spain)
>> Teléfono: 961600351 Extensión: 166
>> Fax: 961690924
>> Correo electrónico: topografo en betera-ayto.com
>> Páginas web:
>> www.betera.es <http://www.betera.es/>
>> www.btsig.es <http://www.btsig.es/>
>>
>> ________________________________
>>
>> Sigue al minuto las principales noticias de tu ciudad
>> MSN Deportes <http://deportes.es.msn.com/>
>>
>> ________________________________
>>
>> Sigue de cerca las últimas tendencias y lo que más rompe MSN
>> Vídeo <http://video.msn.com/video.aspx?mkt=es-es>
>> ________________________________
>>
>>
>> _______________________________________________
>> gvSIG_usuarios mailing list
>> gvSIG_usuarios en runas.cap.gva.es
>> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> gvSIG_usuarios mailing list
>> gvSIG_usuarios en runas.cap.gva.es
>> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>>
> _______________________________________________
> gvSIG_usuarios mailing list
> gvSIG_usuarios en runas.cap.gva.es
> http://runas.cap.gva.es/mailman/listinfo/gvsig_usuarios
>
Más información sobre la lista de distribución gvSIG_usuarios