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 attributeslike[interstate= "",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?

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