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 realt
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 uni
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
obvious
Paul 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 them may have a
road layer. I would make the restriction that within a category you
can't have two
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 s
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
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. (For
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 curren
>
> 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
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:
>
>>
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 wrapper.
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
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 commons-
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
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?
I
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
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 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 name
This all seems like a lot of extra complexity to support something that
at the moment is really only your own use case. Perhaps you should
publish this as a plugin for now, and if it gets used a lot then the
JUMP project can think about incorporating it in the core.
Paul Austin wrote:
> Hi Mar
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
propert
Yes, I'm afraid I agree with Martin. I was just mulling over a
tactful way to say it. I hate to see a general-purpose mechanism put
in for a specific purpose. It just seem to beg for abuse.
regards,
Larry
On 6/11/07, Martin Davis <[EMAIL PROTECTED]> wrote:
> Paul,
>
> It sounds like (a) named
Paul,
It sounds like (a) named Feature Schemas are a pretty specialized use
case (I certainly have never had the need for them in all my JUMP
projects, and (b) you aren't proposing to provide any functionality to
expose them to JUMP users.
In this case, I wonder whether there's a real need to
Hi Larry,
At the moment the FeatureSchema is designed just to allow you to get the
list of attributes for a feature. If you want to know the "type" of
feature you are dealing with you have to know the layer the feature is
in to get the "type" of the feature. I would say that 99% of the time
the na
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 ha
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 sc
Martin,
If the FeatureSchema class could be extended to have a name property,
with a getName (and maybe a setName) with a default constructor and a
constructor that takes the name as an argument then that would be great.
As we have default constructor existing code won't break as the name is
optio
27 matches
Mail list logo
