GeoTools Blog from January, 2006

Jody had to take a breath after a long day, so here is the rest of the logs, after jody left it.

<desruisseaux> If they are strongly related, it may be easier to use the same branch?
<bnordgren> When coverage and feature were separate, we were grooming coverage_branch.
<bnordgren> they can be disjoint, as coverage will just inherit from Feature at the
<bnordgren> very end.
<Jody_> cholmes: I can post them now ...
<Jody_> can you add on the rest after I leave?
<cholmes> cool, thanks Jody_
<cholmes> Um, I'm probably taking off soon. Is there going to be much more?
<bnordgren> We still need to merge the new feature stuff on coverage_branch for final integration and testing prior to merging to trunk.
<bnordgren> (I'm just fishing, this isn't part of the meeting.)
<Jody_> well chris it is kind of up to geoserver, and byrce and your guys deadlines and plans
<groldan> Jody_: what is the plan to merge the community schema stuff regarding API? move back to geotools API or leave it as geoapi?
<Jody_> we want only one api for the feature model stuff - in geoapi.
<bnordgren> amen
<Jody_> I have tried to carefully arange it with justin so we can do this and not screw up.
<Jody_> aka expression just changed to work on Object
<groldan> cool
<Jody_> so we can run both for a little bit during the change over
<Jody_> (also need to go to object to act as constraints)
<Jody_> I am kinda sleepy and will miss speak, I wish justin was here as he knows how far he got.
<cholmes> Cool, it's all Justin on the details, the best I can do is say that Justin should have time to dig in to it.
<Polio> I gotta run, later folks
<Jody_> Cheers
<cholmes> Not sure where he went to though, I was actually supposed to chat with him after this.
<cholmes> see you Polio
<Jody_> he was in a coffee shop on batteries - I have the same battery and I am almost done
<bnordgren> Is Justin doing interfaces or implementation?
<groldan> so what should I concentrate on for tomorrows meeting? ISO19109 primer and what else?
<-- Polio has quit ("Chatzilla 0.9.68a Firefox 1.0.3/20050414")
<Jody_> he is trying to round up the implementations, and put them together
<Jody_> and ask us for help when they don't fit.
<groldan> (I still don't know what topics 3 and 4 was)
<Jody_> The primer
<Jody_> sorry got talking loggin into the site now
<bnordgren> #3/4 was feature/coverage model stuff.
<cholmes> Jody_ 3) GeoServer community schema timeline
<Jody_> aka what they are talking about now, who what when
<cholmes> bnordgren 4) Speak up about features/coverages or forever hold peace.
<Jody_> answer is apparently justin, now, merge hell
<groldan> yeah, I can figure it out...
<rgould> If the meeting is still going on, I have a quick item for the agenda..
<bnordgren> Are you participating in the impl at all Gabriel?
<groldan> I did the impl work in the branch. ultimately I was a bit dissapeared, but hoping to jump in again
<bnordgren> Good! We'll make sure there's room for you!
<bnordgren> I've got ideas about how to break the work up into atomic chunks to let people grab what they want.
<bnordgren> More by tomorrow.
<groldan> As I have finally a work plan at my daily work, I can schedule a couple hours a day for community stuff
<groldan> I was in a kind of chaos before
<cholmes> rgould - it seems to be stretching out. There are more people here now than when we started. So you can go ahead.
<bnordgren> Sweet!
--> robA (n=chatzill@CPE-60-228-33-250.nsw.bigpond.net.au) has joined #geotools
<cholmes> Hi Rob.
<robA> gday
<groldan> Hi Rob
<robA> Been reading Bryce's excellent papers..
<bnordgren> Gawrsh
<robA> short of sleep, high of appreciation
<bnordgren> Rgould had something a while back. Is he still with us?
<Jody_> (early logs posted, can someone supply the rest later please)
<rgould> Ok, well, it looks like I have started implementing org.opengis.layer.*
<rgould> I was looking for thoughts on where in the code base this should reside. Currently I am putting it in my WMS plugin.
<rgould> I was thinking of putting it where metadata.citation is, but that is in referencing and does not make sense to me.
<robA> I can answer some questions on "intent" of CoimplexFeatures or respond via email according to peoples wishes
<Jody_> (robA they are thinking of hitting the geoserver meeting tomorrow)
<desruisseaux> We could move metadata out of referencing if you think it is appropriate (so layer could live with it).
<Jody_> But they are all here now ... take your pick.
<Jody_> rgould - where does it make sense.
<Jody_> main?
<bnordgren> (the 2nd Geoserver meeting)
<rgould> I'm not sure. I was thinking probably main
<rgould> Maybe we need a geoapi-impl plug-in, but I think that might be silly
<robA> the 2nd one is hard for me... is 3am or something
<rgould> There was an idea thrown around earlier for an OWS plugin
<rgould> but I'm not sure if it would be a good idea for metadata.citation to live there
<rgould> and it is not a big deal if metadata.citation and layer don't live together
<Jody_> I am not sure I have an opionion, Martin wrote the citation bits.
<bnordgren> Could make a 19115 module. It doesn't depend on much.
<rgould> That might be a good idae
<rgould> idea
<cholmes> I feel like the intent of main is to be geoapi-impl...
<rgould> Except I'm not sure layer is part of 19115. Martin, do you know?
<cholmes> what's the objection to putting it in main?
<rgould> Chris I think you are right. Perhaps main is the best place for it then.
<bnordgren> (isn't the 2nd geoserver mtg an hour ago, tomorrow? What time now, Rob?)
<rgould> I don't have an objection, I was just looking for the best place for it
<desruisseaux> I don't think that layer is part of ISO 19115 (I don't remember to have see that there).
<rgould> ok
<rgould> I will put them in main then, as they are implemented.
<cholmes> Yeah, I'd say main, unless anyone thinks of a good reason not to. I don't know exactly what the code is doing. But when you said geoapi-impl, that just says 'main' to me, as that's the intent.
<Jody_> main - then. I am trying to go for main having default implementations of everything, interfaces that I wish were in geoapi go in our api directory.
<-- Helge has quit ("( www.nnscript.de :: NoNameScript 3.81 :: www.XLhost.de )")
<Jody_> implementations that directly wig off geoapi currently are in referencing
<Jody_> the rest is plug-ins.
<rgould> Perhaps the implementation of metadata.citation should move into main then?
<rgould> I see
<Jody_> or "referencing" should be turned into "standards"
<bnordgren> main depends on referencing. referencing is separable. THat's nice.
<desruisseaux> Metadata currently live in the same module than referencing because they depends each other (referencing uses Citation, and GeographicBoundingBoxImpl has slight transformation convenience methods).
<rgould> ok
<desruisseaux> As Bryce said, referencing is currently a standalone module. If metadata moved to main, it would introduces a dependency of referencing toward main.
<bnordgren> A circular dependency...
<desruisseaux> Right.
<robA> (7:40am)
<desruisseaux> Rob, we are in the same timezone?
<rgould> So that seems to be a different but related issue. I can move the opengis.layer code into main. (org.geotools.layer.*?)
<bnordgren> (I think the mtg would be a 6AM for you then. Ouch.)
<rgould> I agree that it would be nice to see GeoAPI implementations in main, but don't think it would be worth breaking up the depedencies for it
<desruisseaux> org.geotools.layer in main seems fine to me.
<bnordgren> good enuf. org.geotools.layer.
<rgould> ok. I will do that, and will leave metadata.citation alone.
<robA> layer is a "binding" concept - it binds filter, portrayal and metadata to data access service
<rgould> yes, this should be usable by all of them, I believe
<bnordgren> Well, I'm going to go start generating implementation class diagrams now
<bnordgren> unless someone what to chat about one of the primers
<Jody_> I am out of here for real now (my battery is almost done), byrce if you could do a sanity check with Rob I would appricate it.
<Jody_> Thanks all.
<bnordgren> l8r d00d
<-- Jody_ has quit ("Chatzilla 0.9.69.1 Firefox 1.5/2005111116")
<robA> The operations stuff is v.important... back to that later...
<robA> the "CommunitySchema" thing is exactly as you suggest in follow up email - in fact we derived the need for schema mapping from
<robA> looking at requirements of sev eralo domains.
<robA> We have been looking at how to manage application schemas as models and also factor them into reusable modules
<robA> And, strangely enough, we are now looking at how coverages and features relate to inform the abstraction layers in the model.
<robA> Current thought is that there are three layers in the model - phenomena, sampling regime and packaging.
<robA> Each layer supports sets of operations, "interfaces" if you like.
<groldan> (I'm out a few minutes while calming down my crying daughter)
<bnordgren> Can you define the layers?
<robA> am about to head to the UK for a workshop to look at modelling a domain (meteorology) where we intend to explore this
<robA> We need to look at how Feature Types can be managed (in a registry) and support polymorphism (i.e. implement multiple interfaces)
--> simone (n=chatzill@host150-221.pool80117.interbusiness.it) has joined #geotools
<robA> The game plan is to use the Observations and Measurements abstract model of phenomena,
<bnordgren> (hey simone)
<robA> then work out how coverage views, simple features etc are best defined as "lossy" views into the data space
<simone> (hey bryce)
<simone> (I made it late but I made it)
<robA> My suspicion is that we will need coverage/feature type abstract classes that relate to the underlying sampling regime.
<bnordgren> How is this different frm the '101/'109 model (meta meta: cognition; meta: codification; application: form; instance: data)?
<robA> We are starting with 109 and trying to see what happens when we define a domain
<bnordgren> Sounds like trying to tie in the uppoer levels with the lower ones.
<robA> Knowing what you can do with a data instance is the big issue.
<bnordgren> Yeah. I keep trying to make data plugins dumber, Jody wants them smarter.
<robA> So yes- we are trying to provide the upper levels with a common pattern that can be used to infer/declare operations
<robA> In this case, the smarts are stashed away inside a Feature Type registry, allowing dumb implementations
<bnordgren> I'm thinking you will quickly need to adopt an implementation platform to express the operations' behavior.
<bnordgren> Or are you thinking more of description than implementation?
<robA> Description, but more in the sense of "subscription"
<robA> i.e. a small number of common patterns that new Feature Types subscribe to.
<robA> (just like interfaces)
<bnordgren> Jody and I were talking about this about 2 hrs ago.
<robA> so you can go to the Feature Type registry and find out what can be done with the Features
<bnordgren> We expressed it in terms of "matching" a feature schema with known
<bnordgren> attributes and operations with
<bnordgren> a data-only feature instance wqhich holds the attributes. It could
<bnordgren> then be wrapped with the implementing featuretype.
<robA> yeah - been trying to catch up with the logs
<bnordgren> Perhaps the "matching process " could be guided by humans?
<robA> Anyway - I think I'm 100% with you here
<robA> the matching process needs to be by declaration IMHO
<robA> semantics never happens by accident
<bnordgren> There should definately be a "default" matching, but I'm thinking that
<robA> but if people can subscribe, they dont have to get descriptions right, its easier and more useful
<bnordgren> if a match fails, a human could provide a map from what is expected to what is present.
<robA> its all a matter of "governance" for Feature Type VCatalogs (FTC) IMHO
<robA> I think you are thinking about the implementation here?
<bnordgren> Oh yeah. I got implementation on the brain.
<robA> The ComplexFeatures was really nothing more that allowing the user (data service custodian) to imnplemet the mapping between internal scham and
<robA> the community schema
<robA> This meant supporting:
<robA> namespaces
<robA> (multiple per feature)
<robA> multiplicity of specific attributes
<robA> relationships between features of different types
<robA> complex properties
<robA> (NB relationship to a feature is technically a simple property - a reference)
<-- cholmes has quit (Read error: 110 (Connection timed out))
<bnordgren> Where does the mapping layer go?
<bnordgren> Seems like it's a controlling API for DataStores?
<robA> currently the implementation is the ComplexDataStore provides a mapping capability using Xpath
<robA> ComplexDataStore wraps existing data stores, using the new FeatureModel.
<bnordgren> ...simple features are passed right thru, complex features are related at a higher level...
<bnordgren> is that right?
<robA> New FM allows mappings from simple features to potentially more complex objects. In many cases its likely to be simply attribute name transaltion
<robA> old FM didnt allow different attributes to have different namespaces for example
<robA> new FM can be created from target schema, not storage implementation schema
<CIA-11> magnasound * r17791 udig/community/lavila/plugins/org.cgiar.cip.diva.diversityanalysis.autocorrelation.point/: Initial import.
<bnordgren> Ah yes, separate serialization of data and schema. This strikes me as important.
<bnordgren> (at least for defining relations among attributes).
<CIA-11> magnasound * r17792 udig/community/lavila/plugins/org.cgiar.cip.diva.diversityanalysis.autocorrelation.point/ (24 files in 14 dirs):
--> jdeolive (n=chatzill@d64-180-115-144.bchsia.telus.net) has joined #geotools
<bnordgren> My question is: this thin EMF wrapper I proposed supports namespaces,
<bnordgren> multiplicity, and relationships among features.
<bnordgren> So...is it possible to introspect using the newly proposed
<bnordgren> classes, or is the restriction imposed by the Descriptor notation
<bnordgren> keeping some unwieldy implementation detail in check?
<robA> At this level of detail I need to defer to Gabriel - I'm kinda occupied thinking about the processes for defining schemas
<robA> and just trying to funnel the user requirements to the hard core developers
<bnordgren> Ahhh. At this point, I don't see any clashes with what we're attempting to
<bnordgren> accomplish. It seems that we're on the same wavelength conceptually.
<bnordgren> What did you think of the specialization I proposed? (Gabriel)? Does
<bnordgren> this give you what you need?
<robA> Looks like it. Issue is the extent to which introspection is used to define feature types or support human controlled mapping
<groldan> sorry, I need to read it yet, could have an opinion for tomorrows meeting
<bnordgren> sounds good to me.
<bnordgren> What is your timeline?
<groldan> I should say I have no real timeline regarding this by now. Waiting for Robs setting up next phase really
<bnordgren> What is next phase? Integration to GT? Geoserver?
<groldan> that and community schema support for arcsde
<groldan> Am I right Rob?
--> cholmes (n=chatzill@c-67-188-227-17.hsd1.ca.comcast.net) has joined #geotools
<bnordgren> (Playing devil's advocate) coverages and features are typically stored in separate
<bnordgren> persistence files. By producing something which maps schemas from
<bnordgren> one target to another, it seems we
<robA> yes
<bnordgren> are exposed to the possibility of having both feature and coverage
<-- lavila has quit ()
<bnordgren> data in the same schema.
<robA> coverages are features...
<bnordgren> (Actually, just making the ability to create schemas causes this)
<bnordgren> Ahh, but can't store a grid into a shapefile efficiently.
<bnordgren> ...or vector data into a GeoTIFF.
<robA> No - but cant store an observation with metadata into a shapefile either
<robA> demote shapefile to a "packaging view" - lossy
<robA> same as a grid really
<bnordgren> Is there a facility for combining the data in complementary packaging
<bnordgren> views such that the whole view can be had---just in pieces?
<bnordgren> zipfile with geotiff and shapefile and GML and ...
<robA> This is not yet an implementation target, but thats the design principles we want to play with during Feature Type design
<-- desruisseaux has quit (Read error: 104 (Connection reset by peer))
<robA> right now, we just want to respect real data schemas with related features
--> desruisseaux (n=chatzill@193.51.249.162) has joined #geotools
<bnordgren> fair enough. IT seems that this adds another "exception" to data stores,
<bnordgren> though: Unimplemented FeatureType combination.
<robA> maybe its an issue of the operations that must be supported
<bnordgren> I thought of this because the MODIS MOD14 product has one HDF
<bnordgren> file input, but raster and vector data contents.
<bnordgren> (MOD14=Fire_
<robA> so its really UnimplementedOperation that would stop you from defining the feature type against a particular persistence implementation
<robA> So, you could load the Feature Type (maybe via a FTC that summarises the operations required for you neatly) and then it could match the operationms defined for the feature type with the datastore capabilityies.
<bnordgren> I'm not sure how that can be the case: operations themselves are not persisted.
<robA> Choose a grid coverage pacakgin view, and only grid based datastores would be offered during the mapping phase.
<bnordgren> so datastores should be able to advertise the types of data they know how to persist.
<robA> I think we would need an "operations" signature for each DS
<robA> at the moment its implicity the same for all
<bnordgren> only because gridcoverages are a completely separate animal.
<robA> why wouldnt you want to be able to extract features from a grid coverage?
<bnordgren> You mean define a featurestore that grabs something specific from...say a GeoTiff...and returns it as a vector or Record?
<robA> I.e. click on a displayed coverage to get the vector of dependent variables as a feature?
<bnordgren> Ahh. I'm talking datastores.
<robA> Also, coverages arent 2D - many are 4D really
<-- desruisseaux has quit (Read error: 131 (Connection reset by peer))
--> desruisseaux (n=chatzill@202-171-79-91.h16.canl.nc) has joined #geotools
<robA> And there are issues with assuming a regular grid for many applications
<-- desruisseaux has quit (Read error: 104 (Connection reset by peer))
--> desruisseaux (n=chatzill@193.51.249.162) has joined #geotools
<bnordgren> yes. I was still talking just the data store problem. Migrating from a coverage view to a feature collection view and back should be made to be easy.
<-- iant_ has quit ()
<robA> I think if the datastore can advertise what it supports, its easier to have partial implementations
<robA> Also means we can add new capabilities without having to change API and retrofit to all stores.
<bnordgren> that's about the only solution I can see.
<bnordgren> amen that last thing, brother!
<bnordgren> hey, you've been talking about feature catalogs. Do you have 19110?
<robA> got the DIS... i think its an IS now
<bnordgren> i think ur right.
<bnordgren> I don't have it, but '109 alludes to some very interesting topics in '110.
<robA> 19126 is the one I need to update - only got a hardcopy of last CD
<robA> 110 is quite consistent with your paper
<bnordgren> is your feature catalog going to be a '110 beast?
<robA> yep!
<robA> am thinking of mapping 110 onto ebRIM
<bnordgren> I gotta scrounge up some $$$ to get '110, it sounds like.
<robA> but interfaces are an open question
<bnordgren> what is ebRIM?
<robA> ebXML Regisry Information Model
<robA> a nice little meta model for handling relationships between managed entities
<bnordgren> does it work with non xml data?
<robA> and allowing them to form hierarchical taxonomies (or ontologies if you like)
<robA> yes - extrinsic objects can be anything
<bnordgren> isn't there a whole web ontology specification(s)? or are there a lot of them?
<robA> service interfaces for 110 registries is the open question - input welcome..
<robA> lots of them, weak governance models
<robA> i.e. there are lots of duplications in WSDL-S, RDF, OWL, etc without clean separation and much acrimonious debate
<robA> 135 is worth getting - it discusses management of registries. lean and sensible. (my favourite ISO spec!)
<bnordgren> do you think ebRIM is a good choice for serializing application schemas separately from data?
<robA> I need to take kids to school
<bnordgren> Ok, nice chatting. see you later.
<robA> IMHO, UML models, with component packages drawn from a rtegistry
<robA> and serialisation to XML schema + ebRIM to hold the schema objects together and provide access to the underlying semantics (polymorhpisms)
<robA> ciao

We had a meeting, everyone came, and the rest came late
Jody_ hello bryce!
bnordgren hello
Jody_ finally managed to read most of your document - nicely written
bnordgren thanks. I figured you'd be watching the race!
Jody_ (although the color coding does not work when printed for me )
Jody_ In durben?
bnordgren I think that's what you said you had planned.
Jody_ (Aside: uDig project made it into "print" http://www.nta.org/docs/NTAnewsJan06.pdf)
Jody_ Yes, that was sunday
Jody_ I am all back and sleepy now
Jody_ Darn canadian driver went off with 2 laps to go
bnordgren ouch
Jody_ It was fun, but when you attend these things you need to go watch it on tv after to see what happened.
bnordgren That kinda spoils it, donit?
CIA-11 bnordgren coverages_branch * r17789 geotools/trunk/gt/module/basictools/ (22 files in 6 dirs): coverages branch Added a basictools module to the coverages branch. This should contain some basic tools from ISO 19103 which depend on nothing else.
Jody_ So Bryce with feature model land - we are both wanting to go in the same direciton - EMF and the ability to not maintain everything. Have real Java Feature and dynamic data defined Features as well.
Jody_ I got a couple interesting points for you.
bnordgren I'm all ears.
Jody_ Let me find the right page:
Jody_ page 14
Jody_ Create instance from Schema
Jody_ the Feature Type Object shall act as a factory for FeatureInstance Objects.
Jody_ This is something we are trying not to do, and the answer
Jody_ ties in with your question for opperations
Jody_ We would like to devoice feature creation from the FeatureType.
Jody_ So that application programers can "teach" the GeoTools datastores how to create their own content (with there own opperations).
Jody_ Since the schema often comes from within the datastore, aka defined in a file or dabase headers, this kinda made sense to me.
Jody_ The other thing I was thinking (but have not written down)
bnordgren I've been banging my head on the operations thing.
Jody_ was that it would be nice to have more then the simple base FeatureType with the generic opperations.
Jody_ Kinda like you are thinking of having CoverageType, we can go through one of the "standard" FeatureType breakdowns and give people a running start ...
Jody_ I noticed, now that I am finally catching up (aka what you need) i would like to see how i can help.
bnordgren I'm coming around to thinking that in many cases, "operations" could
Jody_ 1st: does the split between FeatureType and FeatureFactory make sense? Can those stay orthogonal?
Jody_ 2nd: what have you tried already for opperations (so I don't waste your time)
bnordgren be a class which decorates an existing data-only feature.
Jody_ (aside: RobA read through your document and have a big thumbs up - said your opperations problem was "interesting")
bnordgren 1st:
bnordgren THere's a problem in that operations are going to require
bnordgren specific attributes with specific names..
Jody_ (Aside: cholmes - can you speak to robA's needs if we have anyquestions)
bnordgren THere needs to be some mechanism in place to associate an
cholmes Maybe? You may know them better than I.
bnordgren implementation of operations with the associated data attributes.
Jody_ Yes, hense my need to define them against specific interfaces (aka subclasses of FeatureType ... sure wish I had that formal breakdown I heard of)
Jody_ (cholmes: but I screw them up, I wish gabriel was here)
bnordgren In this case, it makes sence to have FeatureTypes produce Features.
bnordgren But we always have to recognize that in this case,
bnordgren operations may not be implemented. We may
bnordgren just have a description in the schema.
Jody_ I can see that, the FeatureTypes "own" the opperations, kinda like Class owns the methods.
Jody_ he he - an idea.
bnordgren This leads to the problem of "feature recognition"
Jody_ wonder if we could use a "mix-in" or "aspect" to tackle this bryce?
bnordgren where some mechanism should be able to recognize the attributes
Jody_ that is define these things sepeartely to the Schema's and let the "framework" merge em up for us on creation.
bnordgren of a "real" (data-generated) feature and match them to a
bnordgren predefined feature with an operation implementation.
Jody_ kind of like Spring, putting wrappers on otherwise innocent Beans inorder to modify opperations with pre/post conditions
bnordgren Yes. (now that I look up from my kbd.) That's what I think.
bnordgren Operations decorators with mapping attribute decorators.
bnordgren Should we let the meeting go on and cont. after?
bnordgren Who's runnnig the show here?
Jody_ I can see two good ways to do this: 1 - attach the opperations to WK FeatureTypes - there are specifications even though I cannot remember them. 2 - give the definition a "wild card" saying you shoudl attach yourself to any feature with attributeslikeinterstate= "",road=MultiLineString
Jody_ um Justin usually - we could volunteer chris
bnordgren My concern with "teaching" data stores about specialized features is that
Jody_ (thanks bryce)
bnordgren there are too many of them
bnordgren and every time you want to add a feature type you
bnordgren upgrade every compatible data store.
Jody_ well application programers need to get there own custom implementations out of geotools, that is how they add there platform specific functionality.
Jody_ Indeed often they are running a normal object model, and would like geotools to play with it - smae motification you have for liking EMF I belive.
bnordgren BTW: You can implement my proposed wrapper classes with plain Java reflection.
Jody_ I do understand your point, sorry I thought you were talking about the FeatureType / FeatureFactory split.
Jody_ you are correct - the well known deifnitions would be good starting points for application developers
bnordgren (I tangented)
Jody_ ooh - I radius
bnordgren Where's chris?
Jody_ cholmes - ping!
Jody_ (James used to have a buzzer that did wonders)
cholmes Hi
bnordgren You been shanghaied.
cholmes Anyone have items for an agenda?
Jody_ 1) Congrats to GeoServer !
Jody_ 2) Eclipsecon help needed (please)
Jody_ 3) GeoServer community schema timeline
bnordgren 4) Speak up about features/coverages or forever hold peace.
Jody_ (that is almost the same thing as #3)
bnordgren (but incl. covergaes)
bnordgren Geez, unless this gets livelier, I vote for 'jacking the meeting for #3/4
cholmes Oh, wait. Uh 5) geotools joining the open geospatial foundation...
bnordgren (is that the OGC or is that the new thing?)
cholmes They're having a meeting on saturday, that IanT and I are both attending. We will represent the interests of GeoTools, what we'd want out of a foundation.
bnordgren Got it. thx
groldan hi all
cholmes I can explain it all. We can move it to agenda 1), or wait till 5)...
cholmes Or you can go with 3/4 since we've got groldan here...
Jody_ 1. Congrats to GeoServer on the 1.3.0 release
Jody_ GeoTools 2.1.1 went out - thanks Justin. And uDig 1.0.6 went out as well.
Jody_ Not sure if anyone tested them all to gether but what the heck.
bnordgren Excellent!
acuster is uDig 1.0.6 handling tiff via geotools code, via ossim, or via its own code?
acuster (hey all, and congrats)
Jody_ Hi - OSSIM is a uDig 1.1 option, it is great but we lack some code on the OSSIM side to make it perfect.
Jody_ They cannot parse WKT CRS information (so we cannot tell them what to display unless we are in 4326)
Jody_ A: by geotools 2.1 geotools code (hardly works)
Jody_ uDig 1.1 uses geotools 2.2. geotools code which will display stuff at the cost of memory
acuster thanks
Jody_ Jesse_eichar - did I ge tthat right?
Jesse_eichar basically.
bnordgren You should be able to tune the memory usage via JAI, but that's a hole different topic.
Jody_ 2. Eclipse con help needed
bnordgren Simone's been beefing up GT geotiff in th ecoverage branch.
bnordgren (sorry go on)
bnordgren does that mean eclipse configuration?
Jody_ Yes we are waiting for anyone form WCS branch to tell us when we can use it.
Jody_ let me find the link
Jody_ http://www.eclipsecon.org/
cholmes convention
bnordgren You can use it when we merge it back into trunk.
cholmes what's the timeline on merging on to trunk?
bnordgren Oh. What are we doing at eclipsecon?
Jody_ We have nominated ourselves for a community award (made a video, made a summary, etc...)
Jody_ and refractions cannot send anyone
cholmes (uDig, not gt2)
Jody_ they have a scholarship for the entry fee
bnordgren Coverage merge to trunk after 19123 implemented. Cross fingers end Feb.
Jody_ so if anyone can attend this thing, and do a udig demo at a pavillion
Jody_ it would be really cool.
Jody_ bryce when that happens we will release a uDig based on it, and it cannot happen soon enough
Jody_ So that was a plea for help - next topic.
Jody_ Hi Justin, we were looking for anyone to go to eclipsecon and demo udig, you are taveling by then eh?
jdeolive when is it?
jdeolive and where?
bnordgren http://www.eclipsecon.org/
jdeolive yeah doesn't really work with my schedule
Jody_ they are paying the ticket (not the airfare)
Jody_ we should move onto the next topic - if you know of anyone send them to the email list.
bnordgren Should we do #5 first, so #3/4 can trail off the end of the meeting?
cholmes Sure.
Jody_ not really I am capping out at 1 hr so we cannot trail too long what is #5?
cholmes So a few months ago Autodesk and DM solutions announced 'The MapServer Foundation'...
cholmes http://mapserverfoundation.org/
cholmes Unforunately it sort of backfired for them. A small group of people signed NDA's, were convinced they were doing the right thing. But they announced and the wider mapserver community was kind of upset.
cholmes So now they're basically trying again, holding a meeting with a much wider group of 'stakeholders'
cholmes and attempting to form a more general open source geospatial foundation
cholmes http://mapserverfoundation.org/docs/index.html
cholmes I got invited for GeoServer. James got invited for GeoTools, but he's in the process of moving to australia. It looks like IanT is going to go in his place.
Jody_ (chris that link did not work)
cholmes what the foundation will actually do is sort of still up in the air, as is what projects will be a part of it.
cholmes http://mapserverfoundation.org/docs/index.html didn't?
cholmes works for me...
Jody_ Not found, the first link was okay
Jody_ okay this one works: http://mapserverfoundation.org/docs/
jdeolive didnt work for me either
Jody_ nice to see Allan on the list.
Jody_ So here is the question what do we need a foundation for?
Jody_ Is there anyting we want?
cholmes I met with James last week, and we discussed it a bit.
cholmes The one potential benefit is that if someone were to sue us, they'd sue the foundation instead of individual members of the PMC.
cholmes Basically it could help out with legal liability...
cholmes The other potential benefit is 'marketing'. That the foundation will be doing work on promoting open source geospatial, and thus if we're a part of it we get some free publicity.
Jody_ understood, on both counts.
bnordgren Any centralized infrastructure? People to push releases?
cholmes It also would be a nice opportunity to work more closely with some of the C based people, to maybe bridge that divide a bit.
bnordgren Web sites? SVN Servers?
Jody_ I would not mind seeing a reduced role for the PMC (I liked module maintainers the best). I think these things bounce back and forth, we will get more module maintainers when we stop changing the API
cholmes I think they're planning on infrastructure, since at the very least Autodesks to be open sourced product will need it.
cholmes But it would likely be opt-in, like we wouldn' tbe forced to change our infrastructure.
cholmes Indeed they might even allow projects to be a part of it even if they don't sign over copyright.
cholmes I don't think they would have any say in how we run our project. We'd just have to pick a few people to represent our interests as 'foundation members'.
cholmes We could have all module maintainers make up the 'project steering committee', and from that choose who to put in the foundation...
cholmes Or just keep the PMC around to just do things like represent us there, all decision making done by module maintainers.
bnordgren So their value added is a website with links to a bunch of open source geospatial projects.
cholmes But that question isn't too relevant to this discussion.
cholmes Yeah, and they'll probably set up booths at conferences, maybe do education material ect.
Jody_ that is what I would like (and we had some discussion about turning over the PMC in recent email ...)
bnordgren THere's an idea. Can they write tutorials? They could be an outside
bnordgren users doing q/a on releases.
cholmes Well, to some extent 'they' is 'us', if we decide to join.
Jody_ I am not really strongly against, or for the foundatoin thing.
Jody_ I would say yes, simply because it would be nice to meet additional projects.
cholmes But definitely some of the thoughts are to have stronger testing, almost 'certification'...
Jody_ We are meeting some of them via uDig but more would be fun ...
cholmes To guarantee that the code is high quality.
cholmes This is a good page on most of the current thoughts around it: http://mapserver.gis.umn.edu/community/foundation/background/
bnordgren Good plan (cert)
Jody_ I would certaintly like to clear ou Jira (we don't even keep up) and finish the feature model before locking things down for the long haul
cholmes Yeah, indeed I'd ideally like to see it take over one of the functions I hoped for with the opensdi list - just a place where you could get an idea of what other open source people might be starting up, so people could work together in the early stages.
acuster there's freegis.org
bnordgren (that's what I was thinking of too.)
cholmes Another thing I'd like to see in the long term is to make specs, but in a more open source collaboratoin model than the ogc model. That we could then hopefully turn in to real ogc specs.
acuster mapserver is similar to geoserver?
cholmes Yeah, except it doesn't work super well.
Jody_ that is why autodesk is replacing it
cholmes Yes, mapserver is similar to GeoServer. They're actually the more established open source web mapping engine.
Jody_ actually it is fast.
cholmes They do WMS well, we do WFS well. They don't do transactions, we're not as fast.
Jody_ but I have hopes for java when we start getting more cores
Jody_ okay I am way too tired.
cholmes No one's quite sure where autodesks' thing fits in... But they have money to sponser a foundation.
cholmes more cores?
Jody_ Processing cores
Jody_ I am losing it guys -
bnordgren I like that thought about making specs. THe flips side is that maybe the foundation could provide access to specs.
Jody_ 6). PMC Turnover
cholmes http://mapserver.gis.umn.edu/community/foundation/background/foundationtasks/
cholmes Yeah, that's another good thought that James brought up I think.
Jody_ Chris is treatening to retreat to the shadows, and I tried to nominate some of the more active types: Justin, Bryce, Jesse.
cholmes I'll definitely mention at the meeting the foundation having ogc membership. It should be only like $500 for non-voting OGC, and then members of the foundation would have access
cholmes I'd throw Simone in that too.
Jody_ okay
Jody_ cholmes - that would be killer.
bnordgren yeah. simone. definately!
Jody_ So I first of all have a suggestions, PMC is really turning into Module Maintainer of "main", combined with doing some of the grunt work to keep the project going.
cholmes So the overall opinion seems to be that joining wouldn't be a bad thing. As long as it's chill, doesn't involve us changing a whole lot, we'd like to be a part of it.
cholmes We can also wait and see how it turns out, let it run for a year, before considering joining.
Jody_ All of these people show evidence of a) caring about what happens to main b) sweat and tears (and docs, and releases, and helping users)
cholmes I just wanted to feel out any major concerns in joining, that might be able to change how the foundation would be formed, since it's still up in the air.
Jody_ I would rather be there from the start (and effect the course of things) then otherwise.
cholmes Ok. We should have pretty decent representation, with IanT, myself and Paul Ramsey. And I think it makes sense to have geotools join first, and then udig and geoserver to maybe wait a bit.
Jody_ I suppose I just don't want them to screw up, and if they had an OGC membership allowing us to get our developers access to some of the specs it would save us a lot of trouble. The legal thing is
Jody_ huge - but I don't know enough to comment.
cholmes As geoserver has a foundation behind it already, and udig has refractions.
Jody_ fair enough.
bnordgren OGC membership or TC/211 membership? In the US, INCITS/L1 is cheaper.
Jody_ that made no sense to me
cholmes Ideally I think both?
Jody_ Getting access to the ISO things would help me understand bryce it is true.
bnordgren Both is good!
Jody_ not sure how ISO woudl feel about that.
Jody_ Guys we have three mins left on the clock.
bnordgren Centralized document licensing.
bnordgren What else PMC?
iant_ hi?
Jody_ do we have enough to vote? No. Will we ever have enouigh to vote at this rate - no.
Jody_ So we have a catch-22, you need the PMC around to create a PMC. But you cannot create enough PMC without the PMC around.
bnordgren email ballot.
cholmes We should also maybe consider some people stepping down?
iant_ we can always vote on the list
cholmes Or turn them in to PMC-emeritus?
bnordgren good term.
bnordgren "alumni"
Jody_ he he
cholmes Yeah, it'd be good to continue to recognize those who have put in lots of hard work.
cholmes But who no longer really show up at irc meetings.
Jody_ we already keep track in the developers guide in the section on PMC
cholmes Like myself, IanS, ect.
bnordgren yeah, but it's not temporally resolved.
bnordgren It accumulates all contributors over time.
Jody_ an observation schema
bnordgren 19108.
Jody_ okay - I am heading out - thank you guys for the best meeting we have had in a long time.
Jody_ I will see some of you tomorrow at the geoserver meeting.
bnordgren When meet next?
iant_ did we have the discussion on the geospatial foundation?
Jody_ bryce - I will meet with you when you need me (has to be out of work hours as it is volunteer time for me).
bnordgren yup.
iant_ can someone mail me the logs - sorry I was late unavoidable delay
Jody_ I would be most happy if someone from GeoServer was along for the ride, preferably Justin or Gabriel
Jody_ Bryce can I ask you to send out an "IRC Breakout" meeting message, or we could just crash the geoserver meeting in 9 hours time.
bnordgren should be easy UR 9 hrs away. how about 1800 tomorrow your time?
bnordgren Let's crash.
groldan I would like to attend tomorrows second meeting
groldan first one is pretty early for me
acuster ciao all, thanks
Jody_ 2nd meeting, I can do that then - as long as I know ahead of time. And if gabriel is there I will be sure to show up !
bnordgren when is 2nd one?
Jody_ (Hi gabriel)
cholmes Hi Polio
Jody_ same time as this one - a day later.
groldan ok, I compromise so
Polio Hey Chris
bnordgren good for me. I'll be there.
Jody_ sweet.
bnordgren Gabriel, you read the 19109 primer?
groldan yeah, over the weekend, though not finished it
groldan I mean, I would need a second read
Jody_ Hi Polio, we missed the meeting - I am cool with retiring the SDO code, but I should probably talk to Paul Ramsey 1st ....
groldan but may be able to talk a bit about
cholmes I'll try to write up an email on the foundation stuff, as this was short notification and not all the PMC was able to make it. But like I said it's not like we're deciding to sign over IP right now in any way. I just want to be sure IanT and I can represent the interests of geotools in the formation.
bnordgren just checking. it will give us a good starting pt if everyone's read it.
bnordgren Martin!
groldan I have a hard copy at a side of my bed
desruisseaux Hello all
bnordgren does it put you to sleep? I was sleeping when I wrote it.
groldan he he, I was already tired
CIA-11 rgould * r17790 geotools/gt/plugin/wms/src/org/geotools/data/ows/StyleImpl.java: Oops.. forgot to commit new class
Jody_ okay - apparently we should of tried having the meeting an hour later
iant_ I only managed to glance through it but it looked good - I plan on reading it while en route to Chicago
Jody_ Hi Martin!
iant_ Jody - I'm still sure we agreed to have the meeting an hour later
bnordgren Well, need to start thinking schedules on my end and will probably
Jody_ really, I would of protested (it is late here). Let me check the developers guide ...
bnordgren be asking to find out who's doing what work on the features end of things.
Polio yah, this is noon PST ... always though it was now, (but happy to move an hour, we just need to communicate these things)
Jody_ I think it moves w/ daylight savings time. We had a "poll" by who showed up when in December and the 11 slot was the best attended.
iant_ I'm confused as I moved time zones - but all I can really remember is voting against midnight EST
bnordgren Martin, are you watching the feature/coverage coding or are you jumping in?
Jody_ http://docs.codehaus.org/display/GEOT/3.1+Internet+Relay+Chat
Polio oh, that explains why people aren't really around much when I've been showing up
Jody_ (they have been short efficient meetings )
desruisseaux I watched the discussion about Features, but I'm not familiar with that part. I have read yours great document about coverage, but did not take action yet. Is there a coding taking place right now? If yes, in which branch?
Jody_ I started coding in geoapi, but wanted to figure out what bryce needed before continuing.
bnordgren Do we want to implement both coverage and feature on the same branch
cholmes Hey, can someone post the logs?
bnordgren or merge?

• Downloads: 2.1.1
• Release Notes: GeoTools - Version 2.1.1

This release contains numerous bug fixes, see change log for
details. The uDig and GeoServer projects have been driving
bug fixes on the 2.1.x branch resulting in a very stable
2.1.1.

This release has been made in conjunction with uDig 1.0.6
and GeoServer 1.3.0.

Thanks to everyone for their hard work.

Congrats to Martin, Corey and Jody all of which have significant work appearing in this release.

• Downloads: 2.2-RC0
• Release Notes: GeoTools - Version 2.2-RC0
• Repository: http://maven.geotools.fr/repository
• Javadoc: http://javadoc.geotools.fr/

New in this Release

New with this releaes is a Maven 2 repository: users can refer to it for automatic download of Geotools JAR and dependencies in their Maven 2 projects!

Also new in this releaes is Filter 1.1 interfaces for sorting, FeatureCollection has obtained two new methods:

• sort( SortBy order ): FeatureList
• subCollection( Filter ): FeatureCollection

This release has also seen a vast improvement in the performance of the aggregate functions used by color brewer to generate styles based on your FeatureCollections.

Help us Help You!

This release is the first one build with Maven 2 instead of Maven 1. It may have some issues like forgotten dependencies. Please let us know any such issues you may encounter. We will try to fix any reported build-related issues for 2.2 final.

Issue Tracker:

We need volunteers to:

• make a release anouncement
• upload to source forge
• make a src release (this is a great oppertunity for someone to explore maven 2)

For more information on making a releaes please visit this page:

• How to cut a release

RnD Report

This represents the conclusion of the following RnD branches:

• Random Data Access
• FeatureVisitor & http://colorbrewer.org/ (we don't have an RnD page)

This is a release candidate, there is no scheduled RnD work remaining during the 2.2 timeline. We are clearing the decks to make way for improvments ot the Feature Model (aka Community Schema ) over the course of GeoTools 2.3.

Thanks to everyone for their hard work.

1. Release Update
2. GeoAPI - Feature / Covergage + EMF

<Jody_> (goes to get coffee, they have powdered coffee in this country. Kind of like training wheels on a motorbike...
<jdeolive> anyone have any agenda items
<jdeolive> 1) Release
<bnordgren> feature / emf / coverage
<Jody_> byrce yo ubetter tag in Jesse, although justin here can help w/ the code generation
<jdeolive> i also know my way around emf
<jdeolive> not as well as jesse mind you
<Jody_> and get the book
<Jody_> right agenda - I mostly want to know when 2.2 goes out, or at least goes branch, and when 2.3 goes crazy...
<bnordgren> I really wanted to get a handle on how you perceived the EMF/Feature
<bnordgren> integration? Just use EClass/Object inside GT?
<Jody_> oh dear, I better get that coffee ...
<bnordgren> We ca ntalk at a better time. I just wanted to get the ball rolling.
<Jody_> I am going to think about how to be articulate as they work through the agenda .. do we need to tag in chorner
<Jody_> (for release)
<chorner> M3 or 1.1?
<jdeolive> ok, i am a bit confused, so ...
<jdeolive> 1) Geotools Release 2.2
<jdeolive> last i heard martin was almost ready to go, just wanted permission to change some source tags or something
<jdeolive> last week he showed up a bit late so maybe he will do teh same this week
<jdeolive> does anyone else have anything about release?
<jdeolive> I have one
<Jody_> well is it ready? Martin asked module maintainers to check the blocking items in Jira.
<jdeolive> after we release, do we want to create a 2.2 branch, and go crazy on trunk (I think this was brought up before)
<jdeolive> or do we want to create a 2.3.x branch and merge onto trunk in controlled intervals
<jdeolive> ie expression, then filter, then feature, etc...
<iant_> My only care is that trunk builds most days
<bnordgren> Either way: develop on a branch and merge in a controlled fashion.
<jdeolive> agreed
<Jody_> controlled intervals, but we can only have 2: Expression/Filter and then Feature/FeatureType/Schema
<bnordgren> ...then coverage
<Jody_> byrce depending on your timelines you may want coverage to go first? I have yet to hear specific target dates out of geoserver for the community schema work ...
<bnordgren> End of Feb. coverage should be (better be) wrapped.
<bnordgren> Coverage should depend on Feature/FeatureType, but needs only form,
<bnordgren> not function.
<jdeolive> ok so getting back to release, lets wait to hear from martin
<Jody_> well I think martin is waiting for module maintainers to close their Jira issues (or put them off)
<jdeolive> we pretty much have started on the second
<jdeolive> 2) feature / emf / coverage
<jdeolive> in email?
<Jody_> no in jira, he wants them closed up, moved off, or bugs fixed (just like it was a release)
<jdeolive> no i mean did he ask in email, i have been following his emails and must have missed that
<jdeolive> last i heard he was set to go on RC1
<Jody_> I remember reading it, don't think it was a private email ...
<iant_> can someone give me a quick intro to what EMF is?
<Jody_> EclipseModelingFramework
<Jody_> java interfaces (or XMLSchema, or Object Model ) go in
<Jody_> and java code (very good code) comes out
<Jody_> the good part is it is stable in the face updates, ie wont lose your work.
<Jody_> Working with such a tool is a step towards "model driven design" where changing your
<Jody_> model is actually useful. So you end up doing it.
<bnordgren> (don't forget that you can build a type programmatically, w/o generating code.)
<Jody_> That is true, their "type system" is actually dynamic
<Jody_> almost method for method in agreenment with FeatureType / Feature (simple case)
<Jody_> where we have FeatureType they have EClass, Feature is EObject
<Jody_> getAttribute is eGet and so on
<Jody_> the tricky thing is because they generate code (using something called JET) they can generate out switch statements for the eGet / eSet implementations
<Jody_> so the performance is way better then reflection
<iant_> sounds good
<Jody_> very good
<bnordgren> wayy better than writing it myself.
<Jody_> It is very tempting to throw EMF at the XMLSchemas and let GeoAPI go hang....
<iant_> is there a good reference page I should check out?
<bnordgren> www.eclipse.org/EMF
<Jody_> sort of, I would recommend a book (there is a lot to take in)
<Jody_> byrce you did get a book right?
<bnordgren> oops, I think it's a small "emf"
<bnordgren> (no book yet. Wanted to make sure it was worth it. New edition coming out soon.)
<Jody_> Should also note that EMF (and JET) is not eclipse specific, they are normal java jars one can play with
<Jody_> So let me paint a picture
<Jody_> a motivation beyond bryce not working to hard
<Jody_> In JUMP (yes the evil) it is very easy to get your custom object model on a map
<bnordgren> (hey, that's good enough for me!)
<Jody_> this is something where geotools is horrible
<Jody_> I have tried for a year to get custom Feature instances out of our datastores, we are getting closer but we are not there yet.
<iant_> me too
<Jody_> Now in the case where the custom object model is based on EMF (very likely given how good it is)
<jdeolive> you guys might want to take this up over im if we want to keep the meeting to an hour
<Jody_> we can very quickly implement getAttribute based on eGet and not have to pay a performance overhead...
<Jody_> add in an adapter from EClass to FeatureType are we are good to go.
<Jody_> (that is it justin I am done)
<jdeolive> feel free to continue, no other agenda items, its just you were shaping up for a serious rant
<jdeolive>
<iant_> ok I'm on rhe right page now - I'll try to do some hard reading this week
<bnordgren> Given the adapter, I can roll on coverages. Just need the form to be stable.
<Jody_> Well the best thing you can do (anyone can do) is review the feature model as it lurches into the mainstream
<bnordgren> For more info why I looked at EMF, see my "Feature type" paper on the ISO 19123 page...
<iant_> I need a way to build XIMA docs for geoserver so this might be the way to go
<Jody_> It would be a good long term move for geotools, especially if geoapi balks at getting a new feature model. We would have no more reason to chase down that goal...
<Jody_> however if geoapi is willing to play ball, I would like to see how far they can go (I get more though reviews on geoapi interfaces) and it is nice to share that kind of pain
<jdeolive> i have a question
<jdeolive> could be silly
<jdeolive> but why use emf for geoapi if its all interfaces
<jdeolive> i mean isn't the big win interfaces to code in minutes
<jdeolive> or are we talking about the geotools implementation
<jdeolive> sorry, just been catching up on the email thread between you guys
<bnordgren> they are kinda tied together. THe interfaces specify the capabilities.
<bnordgren> For custom features which have methods, one must extend both
<Jody_> if we had EClass instead of FeatureType it would be very easy for people to generate, and interact with FeatureTypes from a varity of sources
<bnordgren> FeatureType and Feature to ensure that the data and the methods
<Jody_> You can make a EClass directly from an XMLSchema, no java code required (and use it)
<bnordgren> were synchronized. A lot of dumb template code.
<bnordgren> Also, via TC/211, you should be able to serialize the schema
<bnordgren> separately from instance objects.
<Jody_> kinda like WFS DescribefeatureType for schema and getFeatures for features eh?
<CIA-11> 03magnasound * r17710 10udig/community/lavila/plugins/org.cgiar.cip.diva.analysis.SelectRecordsbyQuery/src/org/cgiar/cip/diva/analysis/SelectRecordsbyQuery/SelectRecordsQueryUI.java:
<bnordgren> Yup.
<Jody_> byrce you will always have a hard sell on the ISO standards around here - because we never see them
<bnordgren> Ideally, I want to see custom Feature objects go from UML to GT
<Jody_> If you do want us to play (indeed I would not mind), you (or someone) will need to make interfaces in a venue like geoapi
<bnordgren> with no interaction.)
<Jody_> Kinda the cost of doing open source work, at least geoapi provides a venue
<bnordgren> 19123 is already in pending.
<bnordgren> all we need is implementation.
<Jody_> yes - and thanks
<bnordgren> OGC already straddles "freee" and "not free". It will pr4obably only
<bnordgren> get worse.
<Jody_> agreed
<bnordgren> (martin did 19123. I did squat.: )
<Jody_> in anycase agenda is done - I must sleep. EMF should work out, just ask for help when you get to adapaters (aka they are not listeners)
<bnordgren> Righto.
<jdeolive> alright, does anyone have anything else they want to bring up
<bnordgren> "Corrupt Content Alerts"
<bnordgren> anyone else get them?
<iant_> does anyone know where James logged into to get irc acess from work?
<Jody_> cholmes may know, he uses the same trick
<jdeolive> alright, thanks for the meeting guys

1. GeoSpatial Foundation
2. Release
3. PMC

<jeichar> Hey justin we're just making up an agenda.
<jeichar> You wanted to discuss the release.
<rschulz> 1) Foundation Discussion stuff
<jdeolive> cool
<jeichar> 2) Release discussion.
<jdeolive> 2) Release
<rschulz> 3) PMC membership (should probably be removed for me)
<jdeolive> alrighty, shall we start?
<jeichar> ok 1)
<jeichar> Rueben?
<rschulz> Well, from the email discussion, it looks like Chris H. and Paul R. will at least be attending and representing (or sticking up for) geotools
<jdeolive> what about ian T?
<jeichar> It looks like it from the last email.
<rschulz> I am not quite clear on how the proposed foundation would impact geotools, since I only saw this discussion last night.
<jdeolive> i would think the impact would be farily positive, it is an opportunity to open teh toolkit up to a farily signitifacnt audience
<jdeolive> however i am not familiar with the tech that autodesk / mapserver folks use
<jdeolive> dont think they are a java camp
<jeichar> I think they are in the C/C++ world
<rschulz> It has been a while since I used mapserver (they are C)
<jdeolive> thats what I thought
<jdeolive> i wish i new more about the scope of this meeting, or the actual agenda
<rschulz> They support ogc wms now (last I heard): does anyone know where the ogc fits in here?
<rschulz> I suspect James and Paul know what the agenda is
<jdeolive> not sure, i would guess that ogc specification will fall into discussion somewhere
<jdeolive> last i heard from paul the agenda was a bit unclear
<jdeolive> almost sounded like a brainstorming session of "ok, what is our plan going to be"
<jdeolive> perhaps come up with some sort of roadmap
<jdeolive> probably better to save the speculation and wait to hear from someone that goes
<rschulz> yes, we wouldn't want to start any rumours
<jdeolive> ha, good point
<jdeolive> when is the meeting, this upcoming weekend?
<jeichar> Youd have to check the mail. I think paul said february though.
<jeichar> February 4, 2006,
<jdeolive> oh so not for a little while, well lets keep our ears peeled and we then we can schedule an update on it at one the appropriate IRC meeting
<jdeolive> sooo, shall we move onto #2
<rschulz> sure
<jdeolive> 2) Release discussion
<jdeolive> so I am hoping to push the release button this week, both for 2.2, and 2.1.1
<jdeolive> this will be my first release so should be interesting
<jdeolive> rgould, you are release master arent you?
<rgould> Apparently
<jeichar> I won't have time to do the indexshapefile/shapefile merge. I just don't have time right now.
<rgould> I haven't done one in a while, but I don't think the process has changed
<jeichar> That'll have to be next release.
<rschulz> who will be using these (what versions are udig and geoserver using)?
<rgould> jdeolive, the release process page is very detailed, and is easily followed
<jdeolive> no problem, there will be plenty of action going on after this release gets out, and i think the plan is to start doing them a bit more frequently
<rgould> I always keep it updated whenever I make a release
<jeichar> udig will be using these
<jdeolive> udig is using 2.2 i beleive, geoserfver is using 2.1.1
<jdeolive> however geoserver is going on trunk after we release 1.3.0 at the end of this week
<rschulz> ok, shows you hom much time I have to follow stuff.
<jdeolive> rgould, cool yeah i glanced at them, they looked pretty good, i might have a few questions of just need a sanity check from you
<rgould> Yeah, no worries. I'll be around
<jdeolive> rschulz, no worries, at least you show up to the meetings
<jdeolive> this is where all the real stuff goes down
<jdeolive> alrighty, unless anyone has anything else about release?
<jdeolive> 3) PMC
<rschulz> Well, since I was voted to be a PMC member, I have had no time
<jdeolive> jody nominated jesse and I for PMC membership, but since we are half of the attendees i am not sure it will be a fair vote
<jeichar> maybe not.
<jdeolive> rschulz, i wouldn't worry too much about not being active, i beleive there is a desire to take power away from the PMC anyhow
<rgould> You need three PMC votes to become a PMC, right?
<jdeolive> most of the voting and decision making should be in the hands of the module maintainers anyhow
<rschulz> Right now, it does not appear that I will have more time until my thesis and some side work finish in spring or early summer
<jdeolive> well reuben, if you are comfortable answering email like you have been doing and attending the odd IRC meeting, that should be good enough
<jdeolive> but its up to you
<rschulz> Ok, hopefully I will have more time in the future.
<jdeolive> no problem
<jdeolive> so about PMC memebership for jesse and I, perhaps we can wait until a few other PMC members are around, Jody and Chris perhaps, is Martin D PMC?
<rgould> I believe so
<rschulz> It is very annoying. When I first looked at geotools, I had lots of time but did not know very much. Now I know some things and have a list of stuff I would like to see, but have no time.
<rschulz> yes Martin should be PMC
<jdeolive> alright, well its not high priority so it can wait
<rschulz> You two are honarary PMC anyway, with the amount of work you are doing.
<jdeolive> not sure that will stand after I break everything with the new feature model
<rschulz> Please update the tutorial, so I can learn about it when i have time
<jdeolive> will do, there is going to have to be a lot of docs about this one
<rschulz> what are the major changes?
<jdeolive> jody has come up with a entirley new type system which is capable of supporting complex data
<jdeolive> ie, not flat like the current model
<rschulz> oh, I remember now him mentioning this in vancouver last sept
<jdeolive> yup, right now the work has been done on a branch, and its time to come in, we need it for geoserfver
<jdeolive> which is why i get stuck with it
<rschulz> is there any datastore that can support storing complex features (besides gml)?
<jdeolive> gabriel has built a complex datastore which can do so
<jdeolive> it builds on top of the current data stores and ties them together in order to support complex data models
<jdeolive> however i think it really just only works with sql based data stores for now
<rschulz> cool, what is it called?
<jdeolive> complex data store
<jdeolive> one sec i can point you to docs
<jdeolive> http://docs.codehaus.org/display/GEOTOOLS/ComplexDataStore+Documentation
<rschulz> thanks
<jdeolive> so anything else from anyone?
<jdeolive> if not thanks for showing everybody
<rschulz> not me; the foundation stuff will need to be done by email
<jeichar> I'm done
<rschulz> thanks for moderating.
<jdeolive> cool, thanks guys

After a night hacking I have managed to restore our content.
You will notice a different look, this one is out of the box (and yes we need a smaller logo).
The developers guide is now in its own space: Home

Enjoy!

Meeting Time, Site Update
Tutorial Page Fixed
2.2 Release
2.1.1 Release
Codehaus Saga

 <rschulz> 2) wiki issue with tutorial page appears to have been solved - thanks to whoever fixed it
 <jdeolive> the meeting was supposed to be at 11, so we are pretty late
 <rschulz> 11 PST?
 <jdeolive> yup
 <jdeolive> not sure where it says that one the site
 <rschulz> the wiki says 11:30 pst, I will change it
 <jdeolive> one sec, maybe it is 11:30
 <jdeolive> actually no it was changed
 <jdeolive> 11 is good
 <rschulz> jody experimented with 12:00 pst before leaving, but we do not know if any change was adopted
 <rschulz> I will email the devel list tonight to sort out the time
 <rschulz> ok note written to myself, on to next topic?
 <jdeolive> good, thanks reuben
 <jdeolive> sure
 <jdeolive> i think we can thank jody for the fix
 <desruisseaux> Agenda topic proposal: Geotools 2.2 release?
 <jdeolive> good, you beat me to that one martin
 <jdeolive> 3) 2.2 Release
 <jdeolive> i think 2 is done, desruisseaux would you liek to start us off?
 <desruisseaux> I'm in the process of moving test files around, in the hope to get a smaller 2.2 source code download (and also a smaller SVN repository).
 <desruisseaux> I'm about to delete (in the next commit) the 50 Mb image and the 8 Mb zip file, and commented-out the test (in GeoTIFF and GTOPO30 modules) until someone put smaller images in place.
 <jdeolive> i beleive jody got the last change he wanted (moving rendering out) in as well
 <desruisseaux> Yes, renderer is in its own module and seems to work well.
 <jdeolive> good
 <desruisseaux> I'm also about to move many shape files in the sample-data module, and modified the test suite in order to pickup their shape files there. This avoid to copy the same shapefiles again and again, especially statepop which is used as a test file in many different modules.
 <jdeolive> so is there anything else that we are waiting on for 2.2 besided some reorganization?
 <desruisseaux> No. I hope to finish that in the next few days.
 <Jesse_eichar> Maybe merge indexed-shapefile into shapefile?
 <Jesse_eichar> so only 1 plugin?
 <desruisseaux> That would be very nice!! Do we have a volunter for that?
 <Jesse_eichar>
 <Jesse_eichar> sure
 <jdeolive> that would be nice, jesse do you have an estimate of how much work + risk
 -->| jgarnett (n=chatzill@mail.refractions.net) has joined #geotools
 -->| rgould (n=rgould@mail.refractions.net) has joined #geotools
 <jgarnett> (hi #) Codehaus - if it is not on already)
 <Jesse_eichar> It isn't a big job.  I would basically leave everything alone.  It is all packaged so the two plugins can be merged with no conflicts.
 <desruisseaux> Before to start any work on merging indexed-shapefile into shapefile, could you just wait that I commit my changes in the test suite? It should be done in the next few hours.
 <Jesse_eichar> I wouldn't start until tomorrow or the next day.
 <desruisseaux> Actually, my work is already done but I'm just unable to commit it right now because of a network problem.
 <desruisseaux> Okay, nice
 <jdeolive> ok so jesse why dont you email the list and describe your change, the turnaround time will give martin some time to commit his stuff
 <Jesse_eichar> ok
 <jgarnett> here is a silly idea of "Stuff before" 2.2.RC0 - did we want module/xml w/ dzwiers as module maintainer? He is not here but he may like the idea ... I recall he was unhappy w/ someof his work being placed in module/main
 <jdeolive> so shall i send the message to get the 2.2 release ball moving, and ask if anyone has any proposed changes to get in?
 <jdeolive> its too bad we met late, he probably was here
 <jdeolive> i would say unless you responds to what to get in, leave it as is
 <jdeolive> you = dzwiers
 <jgarnett> (BTW - I fixed the meeting time on the website)
 <jgarnett> Did you guys follow the codehaus saga?
 <jdeolive> can we stay on the 2.2 release topic, we can make that 4
 <jdeolive> 4) Codehaus Update
 <jgarnett> 5) 2.1.1.RC0
 <desruisseaux> I'm done with 2.2 topic. Just a lost not saying that when everything will be in place (shapefiles modules merged, maybe module/xml), I would like to add something like a @source $URL$ javadoc tag (or any other javadoc tag is someone has proposal).
 <desruisseaux> (typo: "just a last note saying...")
 <jdeolive> ok so if that is it I will send the proposed change message to the list, jesse can respond with the shapefile request, and we can get the release ball rolling perhaps early next week?
 <jgarnett> the @source tag sounds fine ... we can vote on it if you want?
 <desruisseaux> Well... If nobody object, I think that we can go without a vote?
 <rschulz> (I need to attend another meeting at ubc - I will read the logs tonight - bye)
 <jdeolive> bye reuben, thanks for attending
 <jgarnett> Um so where are we in the agenda? Done w/ 2.2.x?
 <desruisseaux> Done on my side.
 <jdeolive> yup, all done
 <jdeolive> so jody 4) Codehaus Saga Update
 <desruisseaux> I'm curious
 <jgarnett> Some of our pages were creted by a user (me actually) that was since deleted (they could not figure out permissions)
 <jgarnett> those pages now die with a null point exception.
 <jgarnett> Since I started the website the pages are the important ones Developers Guide and Tutorials
 <jgarnett> They have a bug report sent off to the makers of Confluence.
 <jgarnett> I may try hacking the "page layouts" so that the origional author is not written out (but I doubt that will save us).
 <jgarnett> I have made a page: DEVEL that has the same contents as "Developers Guide"
 <jgarnett> (note the page that is troubled is id 3111 - you can edit it by hand, just not look at it).
 <jgarnett> That is kind of - it. Nothing more that can be done. If we caught this when they updated we may have got them to delay ... but nobody on our side noticed.
 <jgarnett> Comments, suggestions, or anyone with an australian address that can bribe them with beer?
 <jgarnett> So yeah - we are scr*wed - and this agenda item is done.
 <jdeolive> alright, last agenda item 2.1.1.RC0
 <jgarnett> I am trying abuild on my new laptop, I will release it when done. Justin is looking into a Postgis test failure.
 <jdeolive> probably time this with 2.2.RC0?
 <jdeolive> should be fixed now
 <jgarnett> Well I will make it, you can try your GeoServer release on it? And we can make 2.1.1 with your final release ...
 <jgarnett> (just want to check that we can still release this thing ...)
 <jdeolive> that sounds good
 <jgarnett> Q: Last published meeting was Dec 19th - have we had no meetings since then?
 <jdeolive> alright i think that is it
 <jdeolive> the meeting proper can end now