+1
What I wonder is how would it can serialized/transformed in the future.
Here is a simple test I did with postgis 2.1
CREATE TABLE features ( feature_id INTEGER, feature_name VARCHAR);
SELECT AddGeometryColumn('features', 'feature_geom1', 4326, 'POINT', 2);
SELECT AddGeometryColumn('features', 'feature_geom2', 4326, 'POINT', 2);
INSERT INTO features(feature_id, feature_name, feature_geom1,
feature_geom2) VALUES (1, 'foo', ST_GeomFromText('POINT(20.0
20.0)',4326), ST_GeomFromText('POINT(21.0 21.0)',4326));
select feature_id, feature_name, ST_AsText(feature_geom1),
ST_AsText(feature_geom2) from features;
feature_id | feature_name | st_astext | st_astext
------------+--------------+--------------+--------------
1 | foo | POINT(20 20) | POINT(21 21)
(1 row)
GDAL 1.10.1
$ ogr2ogr -f "GeoJSON" foo.json PG:dbname=foobar features
$cat foo.json
{
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name":
"urn:ogc:def:crs:OGC:1.3:CRS84" } },
"features": [
{ "type": "Feature", "properties": { "feature_id": 1, "feature_name":
"foo" }, "geometry": { "type": "Point", "coordinates": [ 20.0, 20.0 ]
} }
]
}
GDAL takes the first point (feature_geom1) and silently discards the
second (feature_geom2)
Would it be good to create another class that has more constraints so
it would be easier to serialize or convert? I still think it is good
to have a DefaultFeature class that would be able to represent a row
from a table like "features"
Cheers,
Travis
On Mon, Feb 24, 2014 at 11:33 AM, Martin Desruisseaux
<[email protected]> wrote:
> Hello all
>
> Before to make proposal for the Shapefile reader, I would like to make some
> for the DefaultFeature class [1]. This class will be central to many future
> SIS developments. I would like to make it closer to ISO 19109, GML 3.2 and
> GeoAPI interfaces (while we will not implement GeoAPI right now).
>
> A Feature is basically a map of (key, value) pairs where the key are names
> and values can be any object. Compared to the current DefaultFeature
> interface, I propose the following changes:
>
> * Replace the getRecord() and setRecord() methods by:
> * getAttributeValue(String) : Object
> * setAttributeValue(String, Object)
> * Remove the getGeom() and setGeom() methods, which would be an attribute
> like any other.
>
> The reason for the later is that some kind of features may have no geometry,
> or more than one geometry with different name.
>
> The reason for the former is that the map type may not be Map<String,
> String>. It may be something like Map<Name, Value> or Collection<Property>,
> to be determined in a future version. But no matter the approach selected
> later, it would probably be possible the get/setAttributeValue(String, ...)
> methods as convenient methods.
>
> What do peoples thinks?
>
> Martin
>
> [1]
> https://builds.apache.org/job/sis-jdk7/site/apidocs/org/apache/sis/feature/DefaultFeature.html
>
