geowolf wrote
> This issue is common to all stores, you give them a feature type, they
> cannot
> abide to the names 1:1 because of internal limitations (e.g., Oracle makes
> everything uppercase, SDO adds a prefix, shapefile cuts the attribute
> names),
> then you run add features with a collectin that does not match the
> target feature type, and something does not get copied.
> In your case it's the geometry, but there is no special treatment, any
> other
> attribute would follow the same destiny after the copy.

Thanks a lot.
What you wrote allowed me to understand where the bug really lies. It is not
in the copying procedure as I thought before. It is in creating the target
workspace.

When I execute the code:

Map<String, Serializable> params = new HashMap<String, Serializable>(2);
params.put(ShapefileDataStoreFactory.URLP.key, new File(workspacePath,
shapefileName + ".shp").toURI().toURL());
params.put(ShapefileDataStoreFactory.CREATE_SPATIAL_INDEX.key,
Boolean.TRUE);
ShapefileDataStore target = (ShapefileDataStore)
shapefileDataStoreFactory.createNewDataStore(params);
target.createSchema(sourceType);

,where sourceType is the schema of the datastore that I read data from,
I get a target datastore that has 'the_geom' instead of 'SHAPE'.
And this looks like it causes the whole mess.

Shapefiles are not required to have 'the_geom' as their geometry name. And
if a user wants to create a datastore with strictly specified name, the
geotools library should not decide for him/her what names should be given.
Beacuse as you can see - it causes errors.

If anyone has the same problems as I do, here is a piece of code that solved
the problem. I know it is not nice, but gives a workaround for this bug:

private SimpleFeatureCollection copyFeatures(SimpleFeatureCollection
sourceCollection, SimpleFeatureType targetType) throws IOException {
        List<SimpleFeature> resultFeatures = new ArrayList<>();

        List<String> sourceFieldNames =
sourceCollection.getSchema().getAttributeDescriptors().stream().map(a ->
a.getLocalName()).collect(toList());

        SimpleFeatureIterator featureIterator = sourceCollection.features();
        int featureId = 1;
        while (featureIterator.hasNext()) {
            SimpleFeature f = featureIterator.next();
            List values = new ArrayList();

            for (AttributeDescriptor attr :
targetType.getAttributeDescriptors()) {
                if (sourceFieldNames.contains(attr.getLocalName())) {
                    values.add(f.getAttribute(attr.getLocalName()));
                } else if
(attr.getLocalName().equals(targetType.getGeometryDescriptor().getLocalName()))
{
                    values.add(f.getDefaultGeometry());
                }
                // in other case ignore the filed (although if the target
schemawas build based on the source schema, then this should never happen)
            }

            resultFeatures.add(new SimpleFeatureImpl(values, targetType, new
FeatureIdImpl(String.valueOf(featureId++))));
        }

        return new ListFeatureCollection(targetType, resultFeatures);
    }



--
View this message in context: 
http://osgeo-org.1560.x6.nabble.com/Exporting-data-to-SHP-ignores-the-geometry-tp5185002p5185649.html
Sent from the geotools-gt2-users mailing list archive at Nabble.com.

------------------------------------------------------------------------------
Dive into the World of Parallel Programming. The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net/
_______________________________________________
GeoTools-GT2-Users mailing list
GeoTools-GT2-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to