Martin,
I meant only map from a single FeatureSchema to another FeatureSchema.
For some cases you would also need a registry that would get the feature
mapper instances from one feature schema to another feature schema.
This framework is useful where you want to convert a data set with 50
featur
Yep, makes sense.
Er - don't you mean that the FeatureMapper would map a Feature with one
schema into a Feature with a different schema? Not sure what you mean by
"This interface would be defined to work with a single schema".
Personally I have only rarely needed this level of generalization in
Martin,
For the feature mapper I think we would need an interface that would
define the contract of mapping from one feature to another. This
interface would be defined to work with a single schema.
public interface FeatureMapper {
Feature convert(Feature feature);
}
There would be a default
Yep, the schema mapper concept is what I had in mind for a "utility
class". It might be useful to have this in the Feature model package,
if it's general-purpose.
Paul Austin wrote:
> Hi Martin,
>
> Just a note on point 4, a feature without a schema is a Map not a
> List, I guess what I mean a
Hi Martin,
Just a note on point 4, a feature without a schema is a Map not a List,
I guess what I mean a feature without a schema, is a feature where the
schema can be dynamically defined using the semantics of a Map.
Although recently I have come with the concept of a schema mapper,
which us
Some comments:
1. The IDs in JUMP were really intended to be for internal system use
only, in order to give Features a unique identity. This capability is
currently barely used (which is a good thing!), but I think it should be
preserved as is (since this is the more memory, design and processi
There is almost too much good stuff going on around here to keep up with. :]
Paul wrote: "I agree if the open source GIS community can agree on a
single in memory Java representation for geographic features that
would make all the tools more interoperable."
You should definitely get more involved
The reason I was thinking of Object type for Ids is that then you could
use a Long, Integer or String for the feature ID depending on the type
of data. I normally use Long but some models may use String based
globally unique ids, I wouldn't want to use String for numeric fields
all the time.
O
Stefan,
POJO is a Plain Old Java Object so when you see that it means the
property value can be any Java object, we don't have to know how to
handle it but some models may require the data to be persevered.
A feature without a schema is basically just a Map of property names to
values, rather
Hi Paul,
1. Do you really need Object type for ids (I think ids are Strings in
GeoTools - don't know if there is performance penality compared to int
ids, or some cases where a genaral Object type is needed)
2/3. If I can remember, GeoTools complex feature model fulfill 2 and 3
requirements, an
hei..
i did not read all the stuff before until now... but..
your suggestions are nice..
but if i think what all need to be changed (especially in terms of
avoiding errors).. i don't know?
but maybe it is more simple than i thought if one can simply add some
feature properties such as Attribtut
I agree if the open source GIS community can agree on a single in
memory Java representation for geographic features that would make all
the tools more interoperable. Right now I'm using my own schema and
feature model but would prefer not to maintain that in the future. Here
are the requiremen
12 matches
Mail list logo
