Start of #geotools buffer: Mon Oct 11 14:46:19 2004 * Now talking in #geotools
- Topic is 'www.geotools.org'
- Set by Abs|hiof on Sat Oct 09 16:10:46
<jive> Happy thanksgiving (most refractions types won't be here today)
<cholmes> Is it actually thanksgiving, or is it for columbus day? Like the day columbus
<jmacgill> Thanksgivings in November? no?
<cholmes> Because it's a holiday in brazil too, and I'm wondering if it's all because of
<cholmes> yeah, in the us, t-day is in nov.
<jive> We are not sure
<jive> I always thought it was just the harvest holiday most cultures have ...
<jive> ... thanks for the food. Everyone try and bulk up for the cold winter.
<jive> (Or maybe that is the Canadian take on it).
<jive> Hey I was right - points for the non-native born Canadian.
<TheSteve0> even better http://www.canada.com/national/features/thanksgiving/history.html
- jeichar has joined #geotools
<jive> Hi jesse - they are talking about that holiday we are avoiding today (
<jmacgill> Sorry about my absence over the last couple of weeks...
<jive> Hi James.
<jmacgill> do we have pending adgenda items?
<jive> I got a couple of things
<cholmes> 2.0 release.
<jive> 1) 2.1.M1 - I would like to send this out tomorrow
<jive> 3) data work progress.
<jmacgill> any chance Martin will be here this week?
<jive> I am not sure there is much to say about 2.1.M1 - it is going to be a normal release.
Just sticking a version number on what we have now (so UDIG 0.4 can point to it).
<jive> He is in a different timezone. He often shows up about 2pm when the meeting is winding
<jmacgill> have you tried a maven build against the content of the src archive?
<ianT> I found a problem with the build - the grid coverage tests fail if you have spaces in
your dir names
<jmacgill> not again! arrgh
<jive> I tell you what - I will ask paul to put spaces in the name of the nightly build
<jive> That will learn us.
<ianT> basically URIs can't have spaces in them
<jive> What do we do?
<ianT> I'm not sure - shapefile manages with out breaking
<jmacgill> can have spaces, just need to encode them first
<jmacgill> TestData does the hard work of encoding and decoding the strings
<jmacgill> mind you, thats URLs not URIs
<ianT> hang on - let me find the code
<ianT> OK FSCatalogTest in init()
<ianT> f=new File(new URI(URLDecoder.decode(resource.toString(),"UTF-8")));
<ianT> not quite clear as to why we decode an URL to build a URI to build a file from
<jmacgill> That does seem mad
<jive> oh know is that our code jesse :-P
<jeichar> uh oh
<jive> Looks like we are failing a code review ....
<ianT> IOExchangeTest fails for much the same reason
<jeichar> hmmm.. I'll look into it you guys
<jeichar> it looks like I didn't know what I was doing... what am I supposed to be doing?
<jive> I think you are supposed to be using TestData
<jive> Although we may need to add a URI based method for you.
<jive> I can help, lets make a Jira task and go on with the meeting.
<jeichar> It is, No problem I'll figure it out. I know more now than then
- jeichar has left #geotools
- jeichar has joined #geotools
<jive> 1) 2.1.M1
<jive> I cannot think of much to say.
<jive> Anyone want me to hold off on release? I keep having to update the README.txt but other
than that the release process looks sane.
<jmacgill> as long as the src version builds out of the box I'm happy
<jive> James any maven stuff I should be aware of? We have had some feedback on our src
downloads this last week.
<jive> (they don't work).
<jive> Should I just not provide a src download until we fix the problem(s)?
<jive> jmacgill: ping?
<jive> Seems this issue is dead.
<jive> cholmes: 2) 2.0 release
<jmacgill> sorry, distracted... sign
<jmacgill> sigh even.
<cholmes> I think James and I were going to try to get it out on thursday?
<cholmes> I believe it's pretty good to go. I just want help to make sure I don't mess it up,
as I haven't done a gt2 release in a long time.
<jive> Did you guys want to look into the src release issues before then? I imagine the 2.0
release will see widespread src download.
<cholmes> I think we also might spend a bit of time widely announcing the release for once.
<cholmes> Get some more interest, hopefully attract a few more good developers
<jive> (we tried to update Jira last week, but more work remains to be done).
<jive> Agreed - 2.0 is going to be a great release.
<jmacgill> I'll do a clean 2.0 checkout tomorrow and try to build it from scratch.
<jive> I think more to the point download 2.0.RC1 and try and build from the src download.
Email had a list of what did not work.
<jive> But we still may be missing things.
<jive> I have a bit of a "break" this week - milestone release tomorrow. So I can help out a
bit on thursday.
<jive> Actually I will help out all thursday, even if it is just writing docs.
<cholmes> Cool, we'll have a day of it on thursday then.
<jmacgill> ok, will check the 2.0.RC1 - I suspect it is as you suggested, down to missing
module list files.
<ianT> I did a clean checkout and build on Sat, went OK some hassle with GeoApi-Snapshot
<jive> check out of 2.0.x?
<jive> There is no way that should be using the GeoAPI-snapshot
<ianT> I think so
<jmacgill> I thought it had its own date stamped version?
<jive> me too
<jive> perhaps nobody told maven
<jive> Added these as a checklist to: http://jira.codehaus.org/browse/GEOT-247
<jive> The last thing on the agenda was a update on data progress.
<jive> Basically David and I have looked at what is going on, and talked a bit with Andrea.
<jive> And we can see a couple areas that can be improved:
<jive> 1) We have 5 different ideas all heading in the same direction. NewQuery/FeatureReader/Fe
atureView/QueryResults and Indexed/RandomAccess support
<jive> oh and OpperationsAPI
<cholmes> I've been mulling over data stuff, for complex objects - I should try to write them
up, as they aren't fully fleshed out.
<jive> They all seem to want a bundle of code that does something. So far 1) process Features
2) Process FeatureType 3) Reverse Process Filter.
<jive> We are going to think about these things on Wedneday (write down all the suggestions)
and try and distill a plan.
<jive> The other thing is Map/Param/ParameterValue/ISO19119
<jive> basically we have several creation ideas, and UDIG is actually having some requirements
(File/URL based creation with little interaction).
<jive> The creation issues may be helped by treating Files differently then a Database.
Something similar to the GCE Format. Note: FeatureReader/Writer and FeatureSoruce/Store/Lockin
g would remain fixed.
<jive> So for a progress report that is about done.
<jive> Translation: we will think wednesday and try and write up an idea or two.
<jive> Or maybe I should ask for feedback via email.
<jive> Or stunned silience.
<jeichar> stunned silence
<jive> thank you
<cholmes> Feedback on email is probably better
- Martin has joined #geotools
<jmacgill> sorry, bolting office door shut
<jmacgill> So, are you planning to use the new Pram code thourgh the DataStore and be rid of
the evil HashMap of properties for good?
<jive> Well this is the thing - we do have ParameterValue now. I kind of wanted to look at the
ISO 19119 classes before I did anything drastic.
<jive> But in actually use I find that I really want less parameters as part of initial
creation. Often just a single URL or File.
<jive> But the Map idea really is not working. Most examples just access a ShapefileDataStore
directly, do some boilerplate construction code, and get the FeatureSource. And only then do
they start their work.
<jive> If you look at our demos hardly anyone uses DataStoreFactoryFinder. GeoServer does, but
if tries to use the new fileformats it will be in for a nasty shock. Have of them take a
single "directory" as a parameter. And take it successfully, returning an empty list of
<jive> So we ahve some work to do.
<jive> ahve = have (sorry)
<cholmes> I'm going to be in for a nasty shock with fileformats?
<jmacgill> whats the shock?
<jive> Well in the database land we often have a "dbtype" that must be a fixed constant.
<jive> the file formats never agreed on a "filetype".
<jmacgill> and why should they?
<jmacgill> they were based on header peeking
<jmacgill> i.e. they should try and load the file at the URL
<jive> I would have to look again - I did not see them header peeking.
<cholmes> they were based on file suffix, not header peeking.
<jmacgill> depends on teh format
<jive> May of them followed my example of taking in a "directory".
<jmacgill> shapefiles HAVE to have a .shp extention
<jive> And then having typeNames for each file of there type in the directory.
<jive> I know shapefile quite correctly always ignored my example.
<jive> It has been a couple weeks since I looked at this stuff.
<jive> TigerDataStoreFactory for example is happy with any old directory and does not support
<jmacgill> I though there was a directory data source who's job it was to ping the
<jive> Well we tried to set that up, but it did not go anywhere.
<jmacgill> true, we need some form of consolidation
<jive> The DataStore idea ended up making its own plugin to support detection (suffix and mime
<cholmes> Yeah, I'd also like to see the jdbc factory stuff be in a hierarchy
<jive> FileSystemGCE has a FormatFactory plugin.
<cholmes> Rob's done some interesting work in geometryless...
<jive> I am not sure I know the jdbc factory stuff chris.
<cholmes> that sort of begs a refactoring of jdbc datastore and their factories
<jive> I see - I would like to know more.
<jive> I would like Andrea's concept of FID mapping to be a bit more explicit.
<jive> Can we promote that up into the API (rather than just for JDBCDataStores?)
<cholmes> And I think it should also be expanded to more generic object mapping
<jive> WFS also had namespace explicitly thrown into the mix (or it would not function).
<cholmes> So my 'address' object can be mapped to street, name, zip code.
<cholmes> In a proper attribute hierarchy (and returned gml)
<cholmes> Yeah, there's a lot of stuff that jdbc datastores do in the same way, that should all be in one
<jive> oh that hurt. Chris have you followed the GeoAPI feature model at all lately?
<cholmes> Not DataStores, DataStoreFactories
<cholmes> sorry, I mispoke
<jive> They started doing something like that for defining feature id.
<cholmes> Andrea did it for defining a featureid too.
<cholmes> Or at least put the hooks in for it.
<jive> You can see why I want to write all this stuff down; so many people having very similar ideas.
<cholmes> But yeah, each jdbc concrete datastore really should just be a set of strategies and a driver...
<cholmes> With the geometryless at the top, where you could plug in your own strategy and driver.
<jive> I would like to have a similar construct for AbstractDataStore.
<cholmes> Ok, I'll try to get at least some of my thoughts written up by wednesday or so.
<jive> On the bright side it does work if you supply a FeatureReader, and does even more if you supply
a FeatureWriter. This is something I really like about the design - low inital cost to producing
<jive> Thanks chris that would be great.
<jive> So James any words of wisdom before we start off the week? I am looking forward to releasing 2.0
with you can chris.
<jmacgill> me too
<jmacgill> but no, no wisdom from me today
<jive> BTW I just had that "no spaces in the filename" bug bite me.
<jive> Thanks for the catch IanT
<jive> (and fix Jesse)
<ianT> no probs
<jive> BTW Confluence has fixed the render bug they had for blog posts, and jira listings.
<Martin> What other topic on the agenda? I would like a quite discussion about how to merge recent CRS
change to head.
<jive> I am still going to attach IRC logs as actual pages though
<jive> (our screen scrubbger can't handle the blogs).
<Martin> (type: quite --> quick)
<jive> We are done the agenda.
<Martin> (typo: type --> typo)
<jive> 4) CRS changes
<Martin> There is GeoAPI change, which would probably requires adjustment in some module.
<Martin> IdentifiedObject.getName().toString(null) --> IdentifiedObject.getName().getCode()
<Martin> org.geotools.util.InternationalString --> org.geotools.util.GrowableInternationalString
<Martin> Since I need to update ibiblio and performs the SVN commit before to test Maven, the build could
be broken for a few hours for main (until my test revel the point that I may have forget)
<jive> Can you datestamp the current GeoAPI-SNAPSHOT?
<jive> UDIG/2.0.M1 needs to refer to it.
<Martin> We can do that. Or I can wait after udig. What is the better solution?
<jive> I should know what you are talking about with IdentifiedObject/internationalString but I don't see
it right now.
<jive> No we need a datestamped GeoAPI. It is part of making a release.
<jive> I can keep it on the list server if you want.
<jive> Maven now checks there.
<jive> I just did this last time, did you ever decide on a date stamp format?
<Martin> Can I send you the geoapi.jar and lets you update the list server? Then I would commit the code
when I have yours okay?
<jive> You can use it - http://lists.refractions.net/geotools/geoapi/jars
<jive> use your same login as per svn
<jive> It is a webdav folder, both windows and linux support mounting of such.
<jive> I can just copy what is there now. But the question is what should I rename it to?
<jive> geoapi-SNAPSHOT-20041011.jar ?
<jive> what do you like?
<cholmes> the latter
<Martin> geoapi-1.1.0alpha2.jar ?
<jive> 2.1.M1 will download that by name
<jive> I don't know what it is either.
<Martin> The datestamp is okay, no problem.
<jive> The dates in that geoapi-1.1.0alpha.jar are all 6/24/2004 BTW
<jive> So as far as I know you are clear to go ahead with your changes on trunk.
<Martin> We should probable rename it as geoapi-20050624.jar and update the dependencies.
<jive> Can you explain them to me though since I am trying to keep up with your code.
<Martin> Okay, I will update the trunk and fix main as fast as I can.
<jive> I will rename it to geoapi-20040624.jar
<Martin> I will post a mail with a summary of changes after the commit.
<jive> done - but it will remain the other way on ibliblio - unless James steps in.
<jive> I should ask - is the list server working out for everyone?
<Martin> Do we need ibiblio again, or can we get ride of it?
<jive> I have noticed the speed increase.
<jive> Well right now it is a back up ... as far as I know.
<jive> I don't even know where to look for the changes...
<jive> ah here it is build.properties
<jive> So martin - you are just doing some renames?
<Martin> Would be nice to simplify that to a single location. Having inconsistent repository may be a
cause of strange bug...
<jive> What is GrowableInternationalString?
<jive> Best ask James - I try and leave maven up to him.
<Martin> There is a little bit of rename, but also some more change. For example the toString(null) -->
getCode() change is not a method rename. It come from the fact that the return type of
IdentifiedObject.getName() changed from InternationalString to Identifier.
<jive> Darn that is going to break some client code.
<Martin> org.geotools.util.InternationalString is now an abstract class with 3 implementations. The
GrowableInternationalString is the implementation of what was old.geotools.util.InternationalString.
<jive> Especially for DataStore creation. UDIG only uses parameters now
<jive> But that is why it is 0.4
<Martin> Yes I know. This is why the merge is really not simple and why I wouild like to commit as soon
as I can.
<jive> I assume this is part of the solution to your GenericName questions.
<Martin> But the InternationalString --> Identifier change was planned since April. It is pas of the
changes votes as the OGC meeting at Southampton.
<Martin> (typo: pas --> part)
<Martin> (typo: changes voted at the OGC...)
<jive> 2.1.M1 is now switched over to geoapi-20041011.jar
<Martin> Also some more question about parameter (not for immediate fix, but for longer term)
<jive> (I am just looking at project.xml files and wondering what to do with <versions>)
<Martin> ISO 19111 said that maximumOccurs is always 1 for ParameterValue. It may be different than 1
only for ParameterValueGroup.
<jive> I know
<Martin> In current Geotools implementation, this restriction was relaxed.
<jive> in the geoapi spec too (last time I looked)
<Martin> However, if we enforce it in geotools implementation, it would avoid a complication in the API.
<Martin> E.g. ParameterGroup.parameter(String) never need to returns multiple object for the same name.
<jive> allowing optional parameters makes parsing in objects (with out associated parameterValue) a
<Martin> Would you be okay with that?
<jive> The API would make sense, it would match the spec.
<jive> It would foce datastore implementators to group username/password as an optional thing (which is
nice an explicit) either both or one is needed.
<jive> Do I get a separate nillable
<jive> The other way of making things optional.
<jive> Yeah I would be okay with this - it would make that ParameterGroupDescriptor.create() easier to
<jive> so +1 from me.
<jive> Besides don't you need to do what the spec says ?
<Martin> The idea is that with this restriction, I don't think we need a 'add(ParameterValue)' method.
You know that I would like to avoid to lets the user create ParameterValue himself; I would like to
lets ParameterDescriptor control ParameterValue creation.
<jive> Yes I saw that right away.
<jive> Still need an add( ParameterGroup )
<Martin> So instead of 'add(ParameterValue)', we could use 'parameter(String).setValue(...)'
<jive> but you knew that.
<Martin> Yes, ParameterGroup is an other problem. I'm not sure how to handle it.
<jive> well I think add( ParameterGroup ) is what is needed? or are you thinking add( String,
- ianT has quit IRC
<jive> or ParameterGroup add( ParameterGroup ) where if you put in null it will make one for you?
<Martin> Maybe split it in two methods:
<jive> ok: create( String ) and add( Group )
<Martin> groups(String) returns a Set<ParameterGroup>
<Martin> addGroup(String) create a new group and returns it, so the user can edit it.
<Martin> Again, the idean is to specify the group by name and lets ParameterDescriptorGroup to create it
itself, if needed.
<jive> Oh idea
<jive> ParameterGroupDescriptor.create( String ) makes one does not add it
<jive> ParameterValueGroup.add( Group ) adds it
<jive> groups( String ) looks good.
<jive> Note one DataStore uses groups a lot.
<jive> Oh darn it uses optional parameter values as well
<Martin> Using group is nice, but
<Martin> do you need an add(Group) method? Why addGroup(String) would not work?
<jive> WMS uses a parameter group called layers, layers is defined as having an optional ParameterValue
for each possible layer the server provides. The value of these parameterValues is the style used to
render the layer.
<jive> The ParameterDescriptor of those values has a set of the available styles.
<jive> So we need those parameter values to be optional.
<Martin> Yes, this is not a problem; they still optional
<Martin> I mean, they are declared in ParameterDescriptorGroup as optional, isn't it?
<jive> No no - in that parameter group layers (that is no optional)
<jive> there are a bunch of parameter values that are optional.
<jive> The order that they occur in the group will be significant - it indicates rendering order.
<jive> We could go for the double head fake. Layers is a parameter group made up of optional
<Martin> ParameterValueGroup.addGroup(String) would create a new ParameterValueGroup filled only with
mandatory parameter. Optional parameters would be created only when needed, if needed, with
ParameterValueGroup.parameter(String) where 'ParameterValueGroup' is the subgroup included in the other
<Martin> But ParameterValue can be optional! Only 'maximumOccurs' must be 1. 'minimumOccurs' can be 0 or
<jive> Sigh I get it.
<jive> My bad.
<jive> Okay that still works then.
<jive> Martin I am in a really bad way trying to figure out ISO19119.
<Martin> What is ISO 19119 about?
<jive> My best bet so far is to make you an out of date set of classess based on an old DTD.
<jive> Service metadata. I need it to make Catalog go.
<jive> You do ISO19115 - geographic metadata. I need ISO 19119 to describe WMS/WFS/WRS including their
DCP (Distributed Connection Parameters).
<jive> All the OGC specs refer to this beast but I cann't find an xsd file, or a UML diagram.
<jive> My best plan is to hack against very old information and hope the geoapi list can correct my
<jive> I have updated your geoapi-SNAPSHOT.jar
<jive> (so trunk is now broken)
<jive> I was going to get back to work soon
<Martin> Thank Jody. I will commit the code soon.
<jive> Any thing else guys?
<jive> I can post the logs ...
<Martin> Going back to work now. Bye all
End of #geotools buffer Mon Oct 11 14:46:19 2004