Gml:identifier was introduced for stable id. Gml:id is really meant for
reference with the response document but WFS blurred the line with its
getbyid.
So it comes down to implementation contracts between service and clients...
force ids to be stable, mirror in gml:identifier and allow wfs call
) and how impressed I have been with the ongoing energy,
commitment, and especially community-minded teamwork you guys have managed
to sustain.
+1 million.
Rob Atkinson
On 19 March 2015 at 08:08, Jody Garnett jody.garn...@gmail.com wrote:
Managed to review, had a couple questions about
Hi Justin,
part of the semantics of a SQL join is that it may return multiple
rows per feature (row in joined table) - one for each possible join.
The examples dont cover this case, because of disjoint nature of
parks, but if you had for example parks within parks then you would
get multiple hits
-solutions.it wrote:
On Thu, Nov 18, 2010 at 7:00 AM, Rob Atkinson robatkinson...@gmail.com
wrote:
App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues
App-schema allows clients to use style sheets to deal with responses.
(Because its a known schema, a stylesheet can be published and used to
render it. I have build clients with catalogues of stylesheets for
each feature type - and no way would it be worth bother with ad-hoc
flat schemas). We
Andrea - you are da man!
Awesome work, and great communications too - I reckon someone could
follow your little experiment and write an open-source community
best-practice case study around it.
On both FeatureCollections and the renderer - I think we ought to aim
for having a general solution
Its great having Andrea starting to exercise this thing. And a WMS
would be awesome - it always seems to get pushed down the priority
list but is really vital for community acceptance IMHO. And
architecturally, supporting a metadata-rich response to a
GetFeatureInfo makes a lot of sense.
You
I dont see that it should be impossible to support a converter in the
binding - generally speaking we ought to be able have a mechanism that
allows us to drop in capabilities to handle any native data type we
encounter for a complexAttribute. Rather than a function that converts
a specific JTS
I mean inverse functions are a priority for me when I get back to the
geotools codebase :-) - but I do think they will rapidly become a
point of pain for mappings of local identifiers to gml:names too :-)
Rob
On Tue, Oct 5, 2010 at 4:54 PM, Rob Atkinson robatkinson...@gmail.com wrote:
I dont
Nothing wrong with HashMap - not a weakness - its behaviour is
implicit in the hashing algorithm. Its simply using the wrong tool for
a job :-)
The problem with observation is you see what you want to see, Grasshopper :-)
Modern programmers learn about frameworks - old fashioned ones with
There's a fundamental problem with technology-specific introspection
to create interoperability contracts.
Basically, you are bound by the specific persistence platform _and_
your specific introspection mechanism (and whatever modes you wish
to complicate it with). So if you introspect for one
you need the application-schema support
see http://docs.geoserver.org/2.0.0/user/data/app-schema/index.html
Rob Atkinson
On Fri, Apr 30, 2010 at 12:15 AM, Amador Antonio Cuenca
sphi0...@gmail.com wrote:
I've the follow code, but I can't add multiple geometries because my
SimpleFeatureType
Agreed, they will be hints for JDBC for DataStore, but app-schema
would probably need to treat them as explict configuration, which
might then subsequently need to be smuggled as hints to the underlying
JDBC store. As you say, shouldnt affect the proposal but we may want
to update app-schema
Are you trying to connect to a property file directly - not setting
the data store to point to an XML config/mapping file which then
references the property file?
On Mon, Apr 12, 2010 at 3:46 PM, Jody Garnett jody.garn...@gmail.com wrote:
Hi Ben:
As mentioned I am hooking app schema and others
This is a fairly important issue - you guys have much greater
familiarity than I do with the internal assumptions - but it strikes
me that the public ID and the internal table primary key are
fundamentally different things, and we're trying to collapse them into
a single concept.
Simply, I think
Hi Andrea
can you provide a bit more information about the circumstances that a
gml:id needs to be externally provided?
The reason I ask is that there is some debate about the whole nature
of feature ids.
The semantics of gml:name is an id provided by named party (the
attribute codeSpace is
evil man!
Actually, you've pretty much described the extension to app-schema Ben
and I have discussed, and I was going to have a play with once I'd
gort a coupel of other jobs out of the way...
Our idea was to create an inverse mapping using substitution
parameters - which is pretty much what
I see Gabriel is in the loop - this functionality sounds similar to
the sql-datastore module included in the 1.6 community-schemas
dependencies - can we get an analysis of how this new initiative
compares - and if its equivalent (or more complete) work with Ben to
ensure we have some unit tests
This did occur to me - but I thought I'd stick with the first issue -
can we dump sql-datastore and also have user-defined native sql
procedures exposed as filter functions?
On Tue, Mar 23, 2010 at 12:53 PM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
On 19/03/10 22:22, Andrea Aime
Hi Jacqui
just a quick note to pick up on something - (I havent looked deeper
into the particular circumstances)
setting the Namespace to null is different from not preserving the
prefix. Technically,. the prefix is bound to the namespace in the
instance document - there really should be no
Atkinson
Assignee: Rob Atkinson
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
for any
capabilities designed to support these, so it would be good to have an
instance example to play with.
Regards
Rob Atkinson
On Fri, Sep 25, 2009 at 3:51 AM, Jody Garnett jody.garn...@gmail.com wrote:
I don't understand what you mean with using an java.util.Map to store the
complex information
I dont know where Ben got to, but there is _already_ an implementation
for this extension for simple feature types - I need to extend this
ability to map to ComplexAttrImpl to complex types, including GML
types normally bound directly to JTS implementations...
Rob
On Mon, Sep 14, 2009 at 11:26
Sitting here with the Guru... one of the GML editors, Simon Cox I got
some useful insight into this pattern:
1) it is an encoding artefact, not part of the model (as already argued)
2) the pattern separates the role from the data type - and makes each
explicit - so you get a role name, then an
quick - pre-dawn jet-lagged response - I'll re-read after breakfast
and coffee ..
Thanks Justin - this sounds great - well done. How can we get a look
at the solution so far?
Once we have an approach to maintaining the code the AusScope team can
kick in to worry about handling the wierd cases.
The constructor takes a CollectionProperties which is hard coded to
Collections.EMPTY_LIST.
In the patch I attached was an experimental modification to GMLSchema
: I've updated this and attached it separately so it uses Attribute
not Property, now Jody has made the PropertyImpl abstract.
Ther
+1 from me too,
this is really useful piece of investment
Well done!
rob
On Wed, Sep 2, 2009 at 7:49 AM, Simone
Giannecchinisimone.giannecch...@geo-solutions.it wrote:
+1 from me as well
Simone.
---
Ing. Simone Giannecchini
GeoSolutions
one.
So I am still a bit unclear on what you would like to see happen? For now I
will make a milestone release and hope you can sort things out later in the
week?
Jody
On 23/08/2009, at 7:11 PM, Rob Atkinson wrote:
yes - at some length, and I think I tried every remotely possible
+1
On Wed, Jul 22, 2009 at 2:19 PM, Ben
Caradoc-Daviesben.caradoc-dav...@csiro.au wrote:
Ben Caradoc-Davies wrote:
I nominate Russell Petty for commit rights to the GeoTools repository,
for the purposes of submitting and maintaining the webservices module,
(as a submodule in the app-schema
+1
+1 also on escalating the logging level. End users (this usually
means deployers to Geoserver) should never have to worry about
anything below Warning level, and things at warning level or above
should only be things they really need to care about.
rob
On Mon, Jul 20, 2009 at 5:54 PM,
3d.
While we are at it, at some stage we'd like to see support for ISO
topology at some stage, so the solution should not close that door.
Rob Atkinson
On Wed, Jul 8, 2009 at 8:09 AM, Jody Garnettjody.garn...@gmail.com wrote:
Andrea has done a good job setting up a collaboration opportunity
seems to have come good again..
On Thu, Jul 2, 2009 at 2:28 PM, Ben
Caradoc-Daviesben.caradoc-dav...@csiro.au wrote:
RobA and I are both seeing this:
svn: Commit failed (details follow):
svn: connection refused by the server
svn: OPTIONS request failed on
GML bindings
Key: GEOT-2505
URL: http://jira.codehaus.org/browse/GEOT-2505
Project: GeoTools
Issue Type: Bug
Components: ext xml-xsd
Affects Versions: 2.6-M2
Reporter: Rob Atkinson
Assignee
re geometryless module - it is in use by people using the 1.6 complex
schema support. I dont plan to do anything else with it: I hope to
retire it completely by using the app-schema support for complex data
types and the ability to handle SQL dialects in the jdbc-ng stack. It
has the status of a
As a community member (and not putting myself forward here!) I'm very
happy to see the level of available expertise and interest, and would
like to thank you all for efforts and being willing to step up.
I do have a question regarding the Geotoolkit issue - or rather the
strategy for managing the
Great to see the progress, and such constructive support from the community.
I'm not so sure I like the sound of moving the SimpleFeatureType out
of the hierarchy, though I suppose it does implement the
GeneralFeature API...
(warning - rhetorical question) Why do we want a SimpleFeature at all?
Attribute order is in fact important. ISO have specified a
implementation hint - aka a UML tag - for attribute order. Simon Cox
tells me is a technically mandatory part of the meta-model for
features - I'll chase dow the reference if anyone cares that much :-)
.
Rob
On Sat, Feb 28, 2009 at 3:15
+1 Martin,
it would be great for the current round of development to be able to
propose changes if needed to the realtively-new-and-untested ISO
Feature interfaces in a more flexible environment than the stable
components.
Governance right-sizing is a Good Thing.
rob
On Tue, Feb 17, 2009 at
+1 from me too.
On Tue, Feb 10, 2009 at 1:07 PM, rini.angre...@csiro.au wrote:
Hi Jody,
Thank's for the vote. I've completed the contributor agreement and will send
it as soon as possible.
I think the developers guide is good. The project conventions, especially,
have some useful tips that
We're fairly close to the EU agenda within the application schemas
support - which is fairly well supported in Geotools, not yet yet in
geoserver. - most of the application schemas we are using as test case
and business drivers international efforts that will be adopted by
INSPIRE (eg GeoSciML) or
Thanks Justin,
I couldnt work out how to generate this myself, and I had interpreted
your previous comment that we may be able to put an adaptor up.
Hopefully you found the hack resources I put together to remove the
dependencies - I totally agree with this approach - GML3.2 is just
broken IMHO!
Hi
CSIRO's contributor agreement is meant to cover myself and Ben
Caradoc-Davies,already committers. we will ask for others if an when
appropriate.
i have created an account robatkinson on OSGeo
Rob
On Sat, Dec 13, 2008 at 9:46 AM, Adrian Custer acus...@gmail.com wrote:
Hey Jody,
In case
Of course it will all get fun when we start exercising Features, and
in particular Coverages (ISO, not 2d simple coverages)
I can confirm I will represent CSIRO on the SWG
Rob Atkinson
On Fri, Dec 5, 2008 at 3:36 AM, Adrian Custer [EMAIL PROTECTED] wrote:
Hey all,
Perhaps to clarify things
GML 3.2 bindings
Key: GEOT-2180
URL: http://jira.codehaus.org/browse/GEOT-2180
Project: GeoTools
Issue Type: New Feature
Components: ext xml-xsd
Affects Versions: 2.6-M0
Reporter: Rob Atkinson
well, good to know I wasnt going crazy alone...
it sounds to me we need a maven guru to work up a solution then we can
delegate the application of the solution to the module maintainers.
a thought, for poking fun at:
If we started with the core of GeoTools, the GeoTools developers would
start
Ben Caradoc-Davies wrote:
Jody,
Rob Atkinson suggested to me that uDig might be able to load
DataAccessFactory implementations such as AppSchemaDataAccessFactory
via SPI. Do you expect it to support these?
We have some units tests such as this that demonstrate the
AppSchemaDataAccess
Every day we seem to build all modules from scratch - regardless of
whether they have changed - which seems to mean you have to either do
a full mvn install orust as bad, a full download every day you make a
change.
In particular, you cant just build a module you care about and then be
alerted
So you are saying I should look at creating a gml:Name handler while
I'm in the core of xsd-gml and have Justin's attention to review it?
I will then have to back out the hack from app-schemas
Rob
On Thu, Nov 20, 2008 at 1:54 PM, Ben Caradoc-Davies
[EMAIL PROTECTED] wrote:
Rob Atkinson wrote
amount of clutter.
So the question is how do we proceed with implementing the new bindings. You
said alot of the 3.1 bindings can be reused, which is great. Are there any
that can't be reused?
-Justin
Rob Atkinson wrote:
Hi Justin,
I did an experiment and hacked xsd-gml3 to use a gml3.2 test
Hi Justin,
I did an experiment and hacked xsd-gml3 to use a gml3.2 test case, and
it looks like the bindings for gml 3.1.1 are basically re-usable for
gml3.2 support. I know we'll need a new binding (gml:identifier,
basically a gml:name)
it seems that its the tests which are most heavily bound
database columns intoa geometry object is
just a special case of a complex data type.
Will address via JIRA as our thinking progresses.
Regards
Rob Atkinson
On Thu, Nov 13, 2008 at 1:44 PM, [EMAIL PROTECTED] wrote:
Hi,
I found a problem building this package:
GeoTools\modules\unsupported
Thanks guys.
mvn worked fine with Java 1.5, Eclipse still not happy with Java 1.5
Compatibility mode, but builds the project allright.
I commented the JIRA task, note that the WKT being used in the test
is ambiguous, so maybe there is a simple iterator thing lurking
somewhere?
Rob
On Tue, Nov
its community
application schemas, and CSIRO Land Water will be using Geoserver
application schemas (ideally via trunk) to test the Hydrography
theme. Anybody else interested or involved in this please contact me
at [EMAIL PROTECTED]
Rob Atkinson
On Mon, Nov 10, 2008 at 7:12 PM, Adrian Custer
Components: core main
Affects Versions: 2.6-M0
Reporter: Rob Atkinson
Assignee: Jody Garnett
Attachments: HashSet.patch
HashSet does not gaurantee order of iteration, so tests that check an encoded
output cannot use HashSet of Features, but must use a LinkedHashSet
HI
am having difficuly getting geotools trunk epsg-hsql module to pass
its test suite, and it may be more obvious to someone what the problem
is.
I get a few failures:
Test set: org.geotools.referencing.factory.epsg.DefaultFactoryTest
Fantastic news.
I'll look to get the geometryless module into supported status around
this - my only blocker at the moment is the lack of the functionality
currently wrapped in sql-datastore (under 2.4
./unsupported/community-schemas/sql-datastore) in JDBC. Gabriel did
this work and I extended
: Improvement
Components: ext xml-xsd
Reporter: Rob Atkinson
Assignee: Justin Deoliveira
Data types such as gml:DirectPositionType have a DoubleList binding.
In the case of single dimensional coordinate systems it is desirable to be able
to supply a single value
support in Geotools
2.5 to implement s-57 faithfully - though you may simply extract a simple
features level 0 profile (think shapefile or old Geotools DataStore) from
the S-57 data model for certain operations and rendering.
Regards
Rob Atkinson
On Fri, Jul 18, 2008 at 5:56 AM, Davis Ford [EMAIL
,
Davis
On Thu, Jul 17, 2008 at 7:49 PM, Rob Atkinson [EMAIL PROTECTED]
wrote:
Hi David,
Am not aware of an s-57 support activities, but there is a reasonable
prospect that the community-schema support agenda slowly coming to the
mainstream will support the upcoming S-100 (a replacement
(GIS) world view.
--adrian
On Fri, 2008-07-04 at 11:53 +1000, Rob Atkinson wrote:
Performance is important, but as IT history shows, its not the fastest
software or hardware that wins the race, it the one that best meets
people's needs and capacity to use it, and usually this is perception
Hopefully I'm not speaking out of school here, but to remind one and all of
the position previously, CSIRO is engaged in a project to bring eResearch
infrastructure to a community of practice, and is funded to support this for
a three year period. We expect to have one or two developers, but at
Performance is important, but as IT history shows, its not the fastest
software or hardware that wins the race, it the one that best meets people's
needs and capacity to use it, and usually this is perception based - will I
get sacked or promoted for using it?
GIS paradigms are fundamentally
for
you. The vast majority of geo-referenced business data is in multiple tables
with point locations, or references to named features. Geometryless was
designed to enable the former. Getting SQL-datastore extensions into the
core would enable them all.
Regards
Rob Atkinson
On Sat, Jun 28, 2008
a deployable tool. Until we get a chance to play with this, we
probably wont have too much useful insight into GeoTools 3.0, but we may be
worth considering when requirements and resources are being sought.
Rob Atkinson
On Sat, Jun 28, 2008 at 1:41 PM, Jody Garnett [EMAIL PROTECTED]
wrote:
Martin
I (in Australia) had to bow out when it became a 5am meeting (3am in Perth)
! 7am was theoretically possible in summer, but I found I was on the road
virtually all summer -literally travelling every week but about 3, and when
I was at home family breakfasts came higher priority as the result.
I can no longer build this without JAI ( i could a while back).
I though we'd established that we didnt need native JAI?
Rob A
[INFO] Surefire report directory:
C:\repos\geotools\trunk\modules\library\covera
ge\target\surefire-reports
---
T
(StereographicUSGS.java:175)
at
org.geotools.referencing.operation.projection.ObliqueStereographic.inverseTransformNormalized(ObliqueStereographic.java:180)
RA
On Tue, Jun 24, 2008 at 12:41 PM, Jody Garnett [EMAIL PROTECTED]
wrote:
Rob Atkinson wrote:
I can no longer build this without JAI ( i could a while
I too had the problem on geotools 2.4, not on trunk. (Using Java 1.5)
Its in a hardcoded unit test, so the developer has no way of sorting
anything - it simply needs to pass reliably :-0
what is the officieal position on what versions of java work for 2.4? Is it
limited to 1.4 still?
RA
On
so whats the status of this:
the test fails and has broken the build at the moment : for me and everyone?
if there is a fix planned, when and who ? can we expedite this by having a
go and submitting a patch?
Rob
On Fri, May 30, 2008 at 9:21 AM, Justin Deoliveira [EMAIL PROTECTED]
wrote:
I
On Sat, May 24, 2008 at 4:45 PM, Jody Garnett [EMAIL PROTECTED]
wrote:
Hi Rob; you did not install your JDK with international lanaguage support;
I keep fixing this error to not be fatal but it always seems to get people.
hmm - i never made a choice _not_ to install language support. And it
after repeated svn, mvn -u clean, remove and re-checkout I get some
consistent failures building gt2.4
shapefile test fails with:
---
Test set: org.geotools.data.shapefile.ShapefileDataStoreTest
Its not very appropriate... yes we need to support complex types, but its
really all about the stability of the contract between service and client.
Surely the JIRA should match the packaging in the code?
Rob a
On Mon, May 5, 2008 at 11:38 AM, Ben Caradoc-Davies
[EMAIL PROTECTED] wrote:
edges off the process.
Regards
Rob Atkinson
Interoperability Architect
CSIRO, Australia
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go
It would be nice if we could migrate current Feature to SimpleFeature,
but maybe the best alternative is to call the new model something that
reflects the point - GeneralFeature, FlexibleFeature,
CompleteFeature, FullFeature, GenericFeature, etc
I dont know enough to choose between the
Hi, (mainly justin I expect)
in xml-xsd, the Encoder class, when encoding a feature the following
method gets called:
encode( Object object, QName name, ContentHandler handler)
which I've followed in eclipse debugger to
and for the case of the gml:id of the feature,
executor.getChildObject()
I'm not aware of anyone raising this issue, and cannot comment on it
from personal knowledge.
I'll try to dig a little deeper and see what the provenance of the
19125 spec is, but I'd think that the starting point would be the OGC
contact (is this Chris?). OGC has a liaison with ISO TC211, but
FYI we used gt-xml extensively to create feature types from community
schemas - i.e. schemas that form part of an interoperability contract with
a user. These tend not to be as simple as making up a single namespace and
spitting out your column names :-)
But they are potentially useful to a
Surely the problem is that length is not a meaningful restriction on
a floating point number...
no amount of logic can resolve an inconsistency in your starting
assumptions, maybe you need to validate the validation rules first!
RA
On Nov 23, 2007 2:56 AM, Gabriel Roldán [EMAIL PROTECTED]
wouldnt
getCode(authority:URN)
be more flexible, and potentially allow future plugin of authority handling.
there is nothing fundamentally special about EPSG from a programmatic sense.
RA
On Nov 19, 2007 10:32 AM, Justin Deoliveira [EMAIL PROTECTED] wrote:
Hi all,
A while back i asked for
Actually, GML2 could handle complex features just fine, just the
implementations were all built around simple features.
GML3 modularised GML, and then added a whole bunch of modules. And it
changed a few things
fromt the release:
GML Version 3.1.0 adds new geometries, is more compliant with the
This gets to an issue thats been bothering me for some time - the separation
of concerns with geotools. Generally speaking, there are some operations
that require a trivial view of business data, such as rendering to a map,
and others that require manipulation of the data, and others that require
Adrian custer wrote:
Does anyone know if there is a way to isolate certain object types when
adding them to content management systems (repositories) so their actual
storage can be determined. Is the ebRIM profile for GIS going to isolate
the big geospatial data to let it be stored in a
to see how the UN SDI and INSPIRE
activities, with these governance issues in the frame, evolve over time.
Rob Atkinson
Adrian Custer wrote:
Hey all,
I'm slogging through the various catalog specs: it's all hard going for
little return so far (I'm in the abstract levels still). One question
1 hour later would be great for me too.
On 11/3/07, Simone Giannecchini [EMAIL PROTECTED] wrote:
Hi list,
for me moving the meeting one hour later would dbe much better.
Ciao,
Simone.
On Nov 1, 2007 6:31 PM, Martin Desruisseaux
[EMAIL PROTECTED] wrote:
Andrea Aime a écrit :
this
I think it would be a good thing, provided it was something that non PMC
members could see the discussion.
Rob A
On 10/16/07, Jody Garnett [EMAIL PROTECTED] wrote:
We had a request (from seven) to set up a PMC email list; there are a
couple good reasons to do this...
- we sometimes loose
Observations and Measurements, SensorML and SensorWebEnablement (SWE)
schems from the OGC.
Please advise if you need more info at this stage. Sorry I wasdnt
watching gt-users - probably wont do this until the modules are reayd
for supported status.
Regards
Rob Atkinson
Andrea Aime wrote
Justin's solution seems the most elegant - i.e. this is simply an encoding
issue at both the source and XML output end.
The other option we have in the community-schemas stuff is to bind a node to
a specfic data type, which is something we will _always_ need to do where
schemas use generic types
Guys, feeling your pain...
One place where ISO models (not the text specifications) can be accessed
is via the HollowWorld ISO data modelling framework at
https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/HollowWorld
(requires the Enterprise Architect viewer - see links on site, or
On the Xpath front...
fully implementing xpath seems an unecessary burden, but partial
implementation has its issues.
The OGC allows xpath in the Filter specification, stating
In order to handle property references in a consistent manner, a filter
expression processor must use the subset of
I'm actually knee deep in this stuff right now (geoserver's reference to
schemas) so I can try to keep track of fixing this in the geoserver-trunk
codebase.
Hey Saul, ( Justin)
have been working on aspects of this stuff too, since we access cached
copies of schemas in order to derive a
ahh - this is serius issue in the specifications front...
I think the behaviour is correct.
The OGC specifies that the urn: referenced coordinate systems should
always be interpreted as Lon/lat order, in conformance to the EPSG
definition - though they dont also specify that it should be in
Rob Atkinson wrote:
ahh - this is serius issue in the specifications front...
I think the behaviour is correct.
The OGC specifies that the urn: referenced coordinate systems should
always be interpreted as Lon/lat order,
oops - i meant lat/lon - getting tripped up myself...
in conformance
I had a goal to implement datastore for Oracle Spatial based on GeoTools
architecture and interfaces to be used for direct access to Oracle database
from UDIG. GeoTools' standard implementation is very narrow and not
appropriate for high customization - I mean customization for data model
being
about this at all.
Its well accepted that JDBC is in need of a rebuild, I am keen to see we
have a complete set of requirements understood before the redesign.
Rob
Vitali Diatchkov wrote:
-Original Message-
From: Rob Atkinson [mailto:[EMAIL PROTECTED]
Sent: Friday, August 17, 2007 1:07
Cool, just a few last comments, confirming your analysis.
What I see here. Hibernate do not know a priori about how to bind hierarchy
of objects to relational model. We should configure it (through XML or
annotations) and charge the framework with such configuration. Is complex
feature type a
Hi Justin,
am having some difficulty getting gtxml to parse a schema, - it fails to
find included schemas deep in the schema nesting. The file is there,
and the schema validates OK.
the message is
[geotools.xml] - Could not resolve schema location:
temporalAggregates.xsd to physical
* The only thing new in coverageio and coverageio-netcdf unsupported
modules at this time is the XML schema for geographic metadata in rasters,
in the spirit of GML in JPEG 2000 OGC specification. There is no new
Java API at this time. There is a bunch of support classes for
Thanks Martin, excellent explanation.
I'm very comfortable with what you propose - and I hope this explanation
makes it clearer for everyone - I suspect not many would have had the
time or motivation to try to see basic the implications.
If my understanding is right, you are proposing a
Cutting branches to support bug fixes from a stable place makes sense.
Adding new functionality from this point is more problematic - the
overhead of testing stuff against a branch and the trunk is high, and
having the trunk orphaned again is a recipe for frustration and delay.
My own
on
http://docs.codehaus.org/display/GEOTOOLS/Data+Access+API+for+ISO+Coverage+and+ISO+Feature
? with regards to this task?
What is the overlap between the planned work and the gt2-fm module
created - are you planning to use this or re-implement something
equivalent?
Rob Atkinson
!DSPAM
1 - 100 of 188 matches
Mail list logo
