GeoTools : 4 November 22nd

Conversation with #geotools at 2004-11-22 11:15:50 on polio@irc.freenode.net (irc)
(11:15:50) : The topic for #geotools is: www.geotools.org
(11:37:51) jeichar ~jeichar@mail.refractions.net entered the room.
(11:38:28) polio: james will be a couple min yet .. his linux box is down, we are finding him a portal
(11:44:52) ianT_ ~ian@spr2-leed1-5-0-cust234.seac.broadband.ntl.com entered the room.
(11:47:58) polio: should we start without james ... it's taking a bit to find him a machine for him to login to
(11:48:58) polio: I know jesse would like to ask for permission to hack at lite2 on a branch to enable reprojection
(11:49:54) jmacgill ~jmacgill@mail.refractions.net entered the room.
(11:50:08) jmacgill: hi all
(11:50:17) jmacgill: sorry I'm late, server troubles
(11:50:33) polio: just started an agenda
(11:50:33) jeichar: there is reprojection but I want to fix problems as I come against them. I can merge when I have it working better.
(11:51:40) jeichar: Basically I want to make a branch and work on Lite2 for a while
(11:52:02) jeichar: It still has bugs relating to reprojection and I want to experiment around for a while with it.
(11:52:23) jmacgill: I'm always happy to see branches, provided they have a limited lifespan
(11:52:36) jeichar: Sure this one would be around a week.
(11:53:37) jeichar: So if every one agrees. I will make a branch and next week we can talk about the changes I made. yes?
(11:53:47) jmacgill: sounds good to me
(11:53:50) polio: sounds good to me
(11:53:52) jeichar: ok
(11:55:11) polio: james did you have any agenda items? though we should also address chris' email ... or the list of proposed changes to DS, but maybe postpone a week for him to be here?
(11:56:16) polio: also a heads up that we (jody when he's back and I) will be investigating more about metadata for udig, and posible implications for udig
(11:56:23) polio: *implications for geotools
(11:56:56) polio: so we may (havn't figured anything out yet) have a proposal along those lines too
(11:57:42) jmacgill: yeah, its a shame ChrisH is not here this week
(11:57:57) jmacgill: however, it might be worh looking at where we are up to
(11:58:14) jmacgill: you mentioned oin an email having a list of changes you might pottentialy commit?
(11:58:47) polio: yes, it was about 2 weeks back (you comented on the first half), there were about 11 proposed changes
(11:59:40) polio: Subject: org.geotools.data - Refactoring
(12:00:18) polio: 13 changes, originally sent nov. 2nd
(12:00:33) jmacgill: ok, got it
(12:01:27) jmacgill: howm any of them still stand after debate?
(12:02:09) polio: think a couple were resolved (featureType and namespace)
(12:02:27) polio: we didn't talk about them all either (trying to recall ...)
(12:04:14) polio: for example the first point (datastoretest) was undecided as the method in which maven tested classes was unclear
(12:04:41) jmacgill: I can clarify that
(12:04:56) jmacgill: test resources are ONLY available to the module in which they exist
(12:05:12) jmacgill: so test src code can not be used by other modules
(12:05:33) polio: ok, then that one is shot down for the moment
(12:06:24) jmacgill: I think we were all happy to see DataSourceMetadataEntiy go
(12:06:46) polio: it's already gone
(12:07:12) polio: 3) repository ... chris had some concerns over that
(12:07:25) polio: doh, can't read ... it's still there
(12:07:59) polio: 4) chris agreed
(12:08:05) jmacgill: the proposed solution for repository was to move it to a plugin of its own
(12:08:17) jmacgill: then have validation depend on it it
(12:08:31) polio: cool, that works
(12:08:38) polio: in module, ext, or plugin
(12:08:54) polio: validation is in ext
(12:09:08) jmacgill: put it in ext as well then
(12:09:15) polio: k
(12:09:38) polio: FeatureView
(12:10:07) polio: this may be taken care of in the future by the latest development in Geoapi
(12:10:22) jmacgill: ah, from one of Chris' comments
(12:10:28) jmacgill: Although I think we want to go in this direction .. we are not there yet
(12:10:28) jmacgill: > so should not be in main ... maybe in a spike.
(12:10:30) jmacgill: Agreed, perhaps same place as the repository stuff?
(12:10:46) polio: yup, can do
(12:11:08) jmacgill: ok, make a new ext called 'experimental' and put repository and featureviwe in it
(12:11:31) polio: ok
(12:11:35) jmacgill: that way we have have a spike like thing as part of the normal src tree
(12:11:54) polio: should we put Extent and .geotools.expr there too?
(12:12:22) jmacgill: sounds good to me
(12:13:04) polio: 7) lets leave this for now (renaming the exception) as it break backwards compatability
(12:13:56) polio: 11) is done
(12:14:27) polio: 13) – deprecation of lowlevel can't be done yet as we do not have a plan for chris
(12:15:08) jmacgill: I think we should leave the code open for now, but promote the FeatureCollections approach
(12:15:13) polio: 10) adding a throws clause to canProcess mackes sense, and I don't think this will have a huge impact on backwards compatibility
(12:15:18) jmacgill: eventualy the normal api will = geoapi
(12:15:42) polio: yes, that's my thinking so don't see it as a worthwhile effort
(12:16:13) polio: 12) also falls under this thinking
(12:16:54) jmacgill: 12 caused a rewite if i recall correctlyu
(12:17:59) polio: I would think about adding the throws clause though, was a question from a user that made me think about that
(12:17:59) polio: yes, 12 involved some substantial work, also breaking the api significantly between 2.0 and 2.1
(12:18:48) jmacgill: the main use case for canProcess is a itteration over the DataStores
(12:19:26) jmacgill: the exception should only occure if the data store is the ONLY one which could/should respond AND something has gone wrong
(12:19:34) polio: yes, the question is whether the connection io error should be masked, or returned for the user
(12:20:05) polio: yah, your second case involves just calling the constructor
(12:20:44) polio: I can both reasons to keep it the exceptiono internal, and to make it exteernal
(12:20:46) jmacgill: as long as the setCause() (check name) method on the new exception is called with the root excepetion I don't see a problem
(12:22:03) polio: yah, I think we can leave this as is the more I think about it
(12:23:39) jmacgill: ok
(12:24:16) jmacgill: so whats left.. starting to evolve FeatureCollection?
(12:24:51) polio: I would wait for that to go through geoapi first
(12:25:13) jmacgill: ok, ChrisD is putting forwards new UML today
(12:25:49) polio: yes, I would expect that they will have it accepted into geoapi within the week
(12:26:42) jmacgill: have you seen the new ones yet?
(12:26:44) polio: but I don't see us having the developer resources to switch every thing over in the next month, so might want to start on this gradually, for example a DS wrapper
(12:27:00) polio: I saw them friday, but not today yet
(12:27:23) jmacgill: where were Fridays posted?
(12:27:41) polio: I was writing on email + confluence friday
(12:30:22) jmacgill: ok. weak point for me at the moment is FeatureType being able to describe the allowable contents of a featurecollection
(12:30:54) jmacgill: in GML are the members of a FC in an attribute? if so does it have a standard name
(12:31:24) polio: mmm, they are just elements
(12:31:51) polio: well, the elements must extend AbstractFeature
(12:32:03) polio: but that's about the only requirement
(12:32:17) jmacgill: whats an elelment (vs a attribute?)
(12:32:52) polio: an element is a child node in the tree, vs a value in the node of the tree
(12:34:06) polio: oh, do you mean 'attribute' as in geotools attribute?
(12:34:18) jmacgill: yeah
(12:34:39) polio: oh, yah they are the same ... and xml element is equivalent to an object
(12:34:57) polio: but a geotools attribute could be an abstractFeature
(12:35:13) jmacgill: i.e. can we define a schma for FeatureCollection > attribute called featureMember> type ->Feature min/mix, nullable ...
(12:36:09) polio: yes you can, if you extend the definition of a featureCollection (like WFS does) you may do this
(12:36:40) polio: WFS requires a bbox child, and any number of abstractFeatures
(12:37:16) polio: but I could have a mcgill FC definition that has exactly three james features, and 16 chris features)
(12:38:00) jmacgill: and thats all doable inside the FeatureType defn (or at least it should be)
(12:38:01) polio: that said, I have only seen additional types added in that were required, and an unbounded set of abstractFeatures
(12:38:47) polio: yes, basically there is no difference between a String and a Feature as a geotools attrbiute in gml
(12:39:26) polio: so the concept of declaring two attributes (id, name) of a feature could both either be features or strings
(12:40:46) polio: and a set of keywords isn't that different from a set or landmarks (features)
(12:41:50) jmacgill: ok, lets see what ChrisD comes up with
(12:41:59) polio: ok, sounds good
(12:42:00) jmacgill: lets hope its close to what we need
(12:42:12) polio: yup, hope so
(12:42:28) polio: I have to run though
(12:43:25) jmacgill: ok, wihtout Jody or ChrisH, and with polio heading off.. I think we may well be done for the day