> This seems to argue for
> considering unresolved attributes permanently unresolved, which
would
> merit
> a different feature type.
>
>
>
> >>> I think this is not a new feature type, but maybe an error if you
dont
> >>> ask for everyhting you will need, may
Rob Atkinson ha scritto:
> I dont think we disagree - we're just looking from the problem from very
> different perspectives.
>
> I just dont like calling a database table or result-set a FeatureType.
> A feature is a representation of a real world concept defined by a
> community. I'm happy t
I dont think we disagree - we're just looking from the problem from very
different perspectives.
I just dont like calling a database table or result-set a FeatureType.
A feature is a representation of a real world concept defined by a
community. I'm happy to call it a "View", or maybe a better
Rob Atkinson ha scritto:
>
Do you think that "schema-assisted" object model mapping is a
>> reasonable
>>
compromise - as long as we have the extension points to extend the
schema with object libraries - such as GML primitives, coverage
primitives, custom operatio
Bryce L Nordgren ha scritto:
>
> Andrea Aime wrote on 12/29/2006 01:00:32 AM:
> "Schema assist" is not necessarily tied to GML. Drawing out your feature
> model in a UML class diagram with all the geospatial and non-geospatial
> attributes is known as an "application schema". This is a quite fl
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> First thing is, why are there two ways to compare FeatureTypes for
>> equality?
>> The first one is FeatureType.equals(xxx), the second one is
>> DataUtilities.compare(ft1, ft2).
>>
> Andrea, everything in DataUtilities were tools needed in the
Andrea Aime wrote:
> First thing is, why are there two ways to compare FeatureTypes for
> equality?
> The first one is FeatureType.equals(xxx), the second one is
> DataUtilities.compare(ft1, ft2).
>
Andrea, everything in DataUtilities were tools needed in the heat of the
moment to get the job
>>> Do you think that "schema-assisted" object model mapping is a
>>>
> reasonable
>
>>> compromise - as long as we have the extension points to extend the
>>> schema with object libraries - such as GML primitives, coverage
>>> primitives, custom operations
>>>
>> Guys, speaking f
Andrea Aime wrote on 12/29/2006 01:00:32 AM:
> Rob Atkinson ha scritto:
> ...
> > Do you think that "schema-assisted" object model mapping is a
reasonable
> > compromise - as long as we have the extension points to extend the
> > schema with object libraries - such as GML primitives, coverage
>
Rob Atkinson ha scritto:
...
>> Yes and no. The GeoAPI definition is in a no-man's land between modeling
>> with OO and modeling with XML Schema. It's not exactly
>> straightforward and
>> I have yet to figure out how this mixing will impact our code base.
>>
>> The GeoAPI model reflects the fac
> I agree. But the "real one" is the in-memory (OO) version, defined by both
> OGC and ISO. GML is a particular encoding of this OO model, and it
> disallows many things allowed by the XML Schema in order to conform to the
> OO schemas defined elsewhere ('107, '108, '110, '111...). It also cont
[EMAIL PROTECTED] wrote on 12/28/2006 02:41:12
PM:
> Well, all this depends on what a FeatureType is, semantically. The
> problem is that we have deviated from the ISO/GML definition to
> something more closely connected with an in-memory representation of a
> physical implementation. In some c
Well, all this depends on what a FeatureType is, semantically. The
problem is that we have deviated from the ISO/GML definition to
something more closely connected with an in-memory representation of a
physical implementation. In some cases this is a workable surrogate, but
what is the meaning
>
> Sure I can, but before I would like to have feedback from other people too.
> I've been away from Geotools quite a bit of time and some things changed
> in my absence, so I fear breaking stuff.
Makes perfect sense to me. I figure if I bring it to your attention
when you're also digging int
Saul Farber ha scritto:
> Oh yeah, if you work out your issues on this by applying changes to
> ReTypeFeatureReader and DefaultAttributeType.equals(), can you also take
> a look at the patches attached to my JIRA issues and see if you can work
> them in too?
Sure I can, but before I would like
Oh yeah, if you work out your issues on this by applying changes to
ReTypeFeatureReader and DefaultAttributeType.equals(), can you also take
a look at the patches attached to my JIRA issues and see if you can work
them in too?
thanks much!
--saul
Andrea Aime wrote:
> Hi all,
> I have a few que
Andrea,
I bumped against the ReTypeFeatureReader and FeatureType equality
recently. I don't think my issues were quite as general as yours are,
but here's what I came up with:
http://jira.codehaus.org/browse/GEOT-1080
and
http://jira.codehaus.org/browse/GEOT-1081
Here's the nabble thread:
htt
Hi all,
I have a few questions about a bug I've spotted in JDBC land.
First thing is, why are there two ways to compare FeatureTypes for
equality?
The first one is FeatureType.equals(xxx), the second one is
DataUtilities.compare(ft1, ft2).
Some places use the first, others the second, maybe in t
18 matches
Mail list logo
