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
Labels: