for me you posts get even more complicated. ;)
but what i like to say is (although i don't want to weak up sleeping
dogs), that i don't realy see a point against a name for a feature
collection if it is not a compulsory property that must be set.
At least i don't see how it could harm the
I must weigh in with Paul on this one guys. I see a lot of potential
uses for uniquely identifying FeatureSchemas. I guess that I would
call this a FeatureType. If you are curious about the applications of
defining and uniquely identifying FeatureTypes just take a look at the
ESRI Geodatabase.
I would disagree on the point about not allowing two layers with the
same name in a Project. Consider the case where you load in two
Multi-Layer files for different mapsheets, each one of them may have a
road layer. I would make the restriction that within a category you
can't have two layers with
mhm.. i dont realy understand
are we talking about a featureType or a FeatureSchema-Name.
The first is (as far as i remember) used by Pirol.. if somebody wants to
have a look on it.. for images, trianguations or so? .. see
PirolFeatureCollectionRoleTypes.java
I found the idea quite useful. But
So how do you disambiguate these layers in plugin dropdowns which show
layer names?
Paul Austin wrote:
I would disagree on the point about not allowing two layers with the
same name in a Project. Consider the case where you load in two
Multi-Layer files for different mapsheets, each one of
FeatureType seems like a good name for this.
It does seem like this could be added without too much risk right now,
with very little semantics or functionality around it (other than what
Paul is presumably building).
I guess if there's a real need for this functionality it will become
I've been thinking about this, and now I am really confused!
I think I can summarize my confusion by saying this:
I don't think we will need to introduce a uniquely identified
FeatureSchema and/or a FeatureType if we introduce a restriction for
unique Layers. (Or at least a way to associate a
Martin wrote: They certainly follow
the relational paradigm pretty closely, which will make Landon happy
8^) Me too, actually - I don't have anything against the relational
paradigm, and it's certainly a lot more battle-hardened than the object
DBMS world.
It's not that I am a fan of the
Hi Paul,
Just a few questions regarding the FeatureSchema Name, since I'm
unable to come up with the use case myself. I can see that it is
simpler to look at the Name than to compare all of the attributeNames
individually, but I would hate to make that assumption and then find
that the user
Hi Martin,
The reason I'm proposing to include them is for the new Attribute View
that I'd like to have as a core OpenJump view. With the attribute view
it uses my new Builder framework for displaying the features and this
supports nested features just by the virtue of having a value for a
Hi Paul and Larry,
Just few questions I wonder about naming schemas :
- What really needs to be named, FeatureSchema or FeatureCollection ?
- Will it be possible to have two different names for identical schemas
(it should) ?
- Will it be possible to have two different schemas with identical
Michaël,
1. It is the FeatureSchema that needs to be named as this is the only
thing a Feature has reference to.
2. Yes you can have different names for two different FeatureSchema
instances that share the same attribute names and types, consider say a
simple data set that has road and river and
Good questions, Michael, especially the one about having different
schemas with the same name. I suspect Paul's code would work fine in
this case, but it is an important philosophical point which should be
thought out fully before going far down this road.
Michaël Michaud wrote:
Hi Paul and
So how does your TableAttributeView handle the situation where two
different FeatureSchemas have the same name? Isn't it going to make
assumptions about how to handle the schema based on the name? Or -
perhaps it's just displaying the name, and doesn't expect any other
semantics around it?
Martin,
Does JUMP currently have any introspection code to get a property from
an object by a name, something like commons-beanutils. If it does I can
use introspection to see if the FeatureSchema has a name property if
it does use that rather than requiring it on the FeatureSchema class.
BTW I
Not sure what you mean - you mean retrieve an attribute from a Feature
by name? If so, yup. Otherwise, it has whatever java reflection provides.
Paul Austin wrote:
Martin,
Does JUMP currently have any introspection code to get a property from
an object by a name, something like
Something like this, rather than having to do all the class.getMethod stuff
String name = PropertyUtils.getProperty(featureSchema, name);
Paul
Martin Davis wrote:
Not sure what you mean - you mean retrieve an attribute from a Feature
by name? If so, yup. Otherwise, it has whatever java
Martin,
My new detail view page actually uses the Layer to group things by name
at the moment using the InfoModel as used by the existing geometry and
table views.
I agree that having a name space as name is important and in fact I have
that in my underlying model that I wrap with a JUMP
I get it. Nope, but sounds like a good thing in jump.util (or some
appropriate subpackage)
Paul Austin wrote:
Something like this, rather than having to do all the class.getMethod stuff
String name = PropertyUtils.getProperty(featureSchema, name);
Paul
Martin Davis wrote:
Not sure
I think that FeatureSchema instances would be local to the data source
used to load the layer (e.g. file or database connection), within the
scope of that names should be unique.
Hmm... seems to me this would then require all code that depended on
name uniqueness to then be aware of the
hei Paul,
mhm.. if you write the function (that also supports empty names)
this should be possible to include if Michael and Larry agree
stefan
btw. although you are following specific interests, and changes to the
core need to be discussed it is open to you to join the jpp-team
Paul Austin
21 matches
Mail list logo
