From: G. M. <glo...@gm...> - 2008-03-05 18:59:42
|
2008/3/5, Jody Garnett <jga...@re...>: > > Gloria Muñoz wrote: > > Hey all, > > First of all sorry!this email is a bit long :( > > Longer is better; often it is the details that are important. Thanks, now I feel better! > I keep trying to simplify the information stored in a shapefile to > > improve the transmission of this kind of data. > > Okay; so the biggest thing to do is call the various JTS simplification > functions right? Most of the data is usually geometric and you can throw > away what you are not using (at a given scale). In fact I've still haven't used that, but I'm thinking of it. > One action I've done is to separate a shapefile in two files; one > > which contains only integer numbers and another which contains only > > the floating-point numbers of that shapefile. My aim is to > > simplificate the doubles file and then join the two separates files in > > a new single shapefile smaller than the original one. > > I am not quite sure which way you are doing the separation: > - row split - are you taking all the rows with say "attribute=X" where X > is a whole integer? and then all the rows where "attribute=X" is a float? > - column split - are you taking all the columns that are integers into > one file; and all the columns that are floats into another files? > > Please not that if you were sending the data out via WFS you could > request *only* the columns that are needed for the operation being used; > also gziped GML can get very very small. If transmission size is the > problem you may find this useful. I assume you are already making a zip > file out of your shapefile shp, shx and dbf files? Yes, I'm trying different compression techniques(gzip, bzip2, fpc..) Some systems can get > by without the shx file (since it is only an index); not sure where > geotools fits with that - at the very least you do not have to include > the qnx file. I'm doing the simplification absolutely by hand because I didn't find anything that really likes me in javadoc. What I'm doing is to read the .SHP file (with DataInputStream), element by element following the ESRI specification (similar to ShapefileReader) and then create the two separated files using DataOutputStream or RandomAccessFile. After that I make some transformations an then join them in a new .SHP and create the new .SHX too. Do you think it is a bad idea? Am I doing it in a "dumb" way? > I can visualize the new shapefile created when I convert the doubles > > in long integers but I'm having problems with the visualization of the > > data when I convert the file of doubles in a file of integers of 32 > bits. > > I've tested the new file .shp and the new file .shx and they are > > correct but when I try to visualize the new shapefile I've got the > > next error: > > > > Exception in thread "main" java.io.IOException: Dbf has extra record > > at > > org.geotools.data.shapefile.ShapefileDataStore$Reader.hasNext( > ShapefileDataStore.java:422) > > at > > org.geotools.data.FIDFeatureReader.hasNext(FIDFeatureReader.java:133) > > at > > org.geotools.renderer.j2d.RenderedLayerFactory.create( > RenderedLayerFactory.java:221) > > at > > org.geotools.renderer.j2d.StyledMapRenderer.addLayer( > StyledMapRenderer.java:182) > > at > > org.geotools.renderer.j2d.StyledMapRenderer.setMapContext( > StyledMapRenderer.java:129) > > at > > org.geotools.gui.swing.StyledMapPane.setMapContext(StyledMapPane.java > :114) > > at mapViewer.showMapPane(mapViewer.java:179) > > at mapViewer.main(mapViewer.java:94) > > > > I'm using geotools 2.0 and the code mapViewer.java (* @author Martin > > Desruisseaux ; * @version $Id: MapViewer.java,v 1.5 2004/04/10 > > 16:03:18 aaime Exp $) for the visualization. > > It is going to be very hard to find someone to help you way back on > GeoTools 2.0; can you upgrade to GeoTools 2.2 where at least some active > developers are? I know this is a problem but my project is trying to help to another application already implemented with Geotools 2.0 so I think that maybe could be a problem if I use Geotools 2.2, couldn't be? > Have I to create a new file .dbf too? Can anybody tell me what could > > be the problem? > > That would make sense to me; the dbf file is where the attribute data is > stored. > > Jody > I'm not sure if it is necessary because according to the ESRI specification if the number of records in both files (new and old shapefile) is the same, the older .DBF file should serve, but I don't know the exact structure of the .DBF file. Thanks..and sorry about my english... |