Friday, September 24, 2004

 

Data Query Informal Followup

Andrea Aime: Anyway, I was looking for you to ask you about the code I've sent you (reprojection). Did you find it useful?
Jody Garnett: I have not had much of a chance to digest it - I did confirm that we are on the same track.
Jody Garnett: Also apparnetly RobA has sent chris a bunch of code along similar lines (more towards the Join side of things).
Jody Garnett: I need to read cholmes really long email and think about smunching all the code together.
Jody Garnett: The down side is David and I had a bit of a break last week to work on this; and our next one won't be for a couple of weeks.
Andrea Aime: Last time you where looking at a way to put all those concerns in Query in a general way if I understood properly... those are quite a lot of different things... it seems to me that the Query interface is going to grow unelss some clever solution is found...
Jody Garnett: So useful = yes, do I have a clue yet = not really.
Jody Garnett: But we are succeeding in making some decisions - like to have a Query interface rather than try to extend Expression (ie the Expr approach).
Andrea Aime: Hum... sounds good. They seem to be two logically separater concepts...
Jody Garnett: I really should use that nice Omondo plugin and make some comparitive UML diagrams for us to all talk about.
Jody Garnett: Yes - but I was very tempted to combine them since I want it all to reduce to the same SQL statement where possible.
Jody Garnett: The other thing that is bothering me is the Catalog 2.0 specification - it has a full Query language - also called Query. Complete with BNF syntax.
Andrea Aime: But an expression can be at most a where clause, whilst a Query object is more than a query itself (when reprojection kicks in, for example)
Jody Garnett: Translation I wonder if we need to think of a new word for our "NewQuery"
Andrea Aime: CatalogQuery and DataStoreQuery?
Jody Garnett: Yes - and then we have another category of "suggestions" like reprojection; that are kind of a hint (whenever you see a Geometry column wrap it in a extra reprojection function).
Jody Garnett: That was poorly worded - I was trying to say reprojection cross cuts the traditional SQL SELECT clause
Jody Garnett: Oh wait - it really is an "Aspect"
Andrea Aime: Well, reprojection is an order, not a suggestion... if the reprojection is not done, the client code won't be able to function properly
Jody Garnett: True but several bunches of code can have a go at implementing the order.
Jody Garnett: SQL encoding can have a go; or if that is not available as an "Aspect" of the current SQL Encoder postprocessing will have to provide one.
Andrea Aime: That's why we need parameters or we need to pass "transformer" objects to the query
Jody Garnett: ! - this is great - if I can define an "Aspect" abstraction we will have a cross cutting capability that will be able to handle more then just reprojection
Jody Garnett: This is exciting
Andrea Aime: Real cross cutting is got thru some form of interception or byte code generation... it simply see this as a parameter of some way to the query... it's does not fit the few things I've learned about aspect oriented programming
Andrea Aime: I mean, real cross cutting is transparent, and configurable, it's more than configuration parameters...
Jody Garnett: I was not thinking of Aspect in terms of Java language.
Andrea Aime: But the transformation concept could be interesting. A transformer could do some operation on the feature and the feature type, such as adding, removing or changing attributes, doing computations and the like.
Jody Garnett: But in terms of our NewQuery = Join / Query / Filter / Expression language.
Jody Garnett: Transformation may be a good name; the hard part if giving it a "pattern" so it knows when to trigger itself (ie splice itself into Expression processing).
Andrea Aime: One problematic aspect of this approach is that the Transformer provides a programmatic rather a declarative way of doing transformations, leaving less room for data store optimizations I guess. I mean, to optimize out a transformer you have to know it, do your own optimized query and remove it from the feature reader chaing
Jody Garnett: It is the fact that reprojection needs to inject itself into Expression processing that makes it a true Aspect in my mind.
Andrea Aime: I don't follow you... what part of reprojection deals with Expessions? It's not part of a Filter... maybe we are not speaking about the same thing
Jody Garnett: When an SQLEncoder is encoding the Expression (ie a form of evaluation) it needs to "know" that a the "reproject" order has been given. When ever it finds a GeometryExpression (or a AttributeExpression on a Geometry attribute) it needs to inject the reprojection function.
Jody Garnett: That would mark reprojection as being handled; so postprocess would not need to do the job.
Andrea Aime: This means that reprojection and cs forcing should be part of the Filter?
Jody Garnett: This is the design tradeoff that we have been struggling with.
Jody Garnett: If there was a well known "reproject" or "force cs" function that was common to all spatial implementations we would be done. But Postgis and Oracle use different function names for this process.
Jody Garnett: But both do supply it.
Andrea Aime: But it does not make much sense... a Filter is a way to select features.... not a way to transform things. What I mean, is that I would not look for reprojection capabilities in a class named Filter if I was a user...
Jody Garnett: If we only ever want to do this via postprocessing this would be easier.
Jody Garnett: Filter also is made up of Expression
Jody Garnett: And it is the Expression that defines the reproject function.
Jody Garnett: I am being literal here - if you want to use postgis reprojection right now with the existing DataStore that is how you would do it.
Andrea Aime: The expression is usually a boolean one... how do you enrich with cs handling capabilities
Jody Garnett: Can you bring up the following on your web browser:
Jody Garnett: http://svn.geotools.org/geotools/trunk/gt/ext/view/src/org/geotools/data/NewQuery.java
Jody Garnett: As a nested class QueryAs is defined
Jody Garnett: It provides a mapping from attributeName to an Expression
Andrea Aime: I see, it provides a way to perform in-query computation.
Jody Garnett: You can use this to define an attribute that you want.
Jody Garnett: We only used attributeName before.
Andrea Aime: I see, that would work.
Jody Garnett: No the datastores do inquery computation all the time - they ask for the Geometry as WKB or WKT for example.
Jody Garnett: The reprojection hint - just added another function call into that mix.
Andrea Aime: I was meaning, is a way for the user to ask for it.
Jody Garnett: Yes
Jody Garnett: http://svn.geotools.org/geotools/trunk/gt/ext/view/src/org/geotools/data/Join.java
Jody Garnett: extends NewQuery and allows these QueryAs expression to combine attributes from different sources in the same Expression.
Andrea Aime: You leave it up to the concrete subclasses to describe how to combine the various query results into one feature?
Jody Garnett: So when I think of Query in these terms - reprojection really does cross cut the process.
Jody Garnett: No it is just the javadocs have not been written.
Andrea Aime: Let's stick with a simple case. How do you define an equi-join with the Join class?
Jody Garnett: I think David assumed that AttributeTypes would not be shared between feature types.
Andrea Aime: What I miss, are the join conditions
Jody Garnett: I think this is the mathmatical representation of the join
Jody Garnett: You still need to provide your where clause (ie a Filter) to figure out your subset.
Jody Garnett: Filter is defined by NewQuery which Join extends.
Andrea Aime: Well, it's at best the mathematical representation of a cartesian product.... so you need a Filter... yes, ok, I see it
Andrea Aime: It would be probably nice to have some support to build up the most common join styles... like and equi-join
Andrea Aime: It's going to be a little verbose using only those interfaces
Jody Garnett: Andrea - I really should go and fix the build - they guys are smacking me in the back of the head because they can't work.
Jody Garnett: But we are on the same page w/ respect to this idea and the design problems.
Jody Garnett: I confess NewQuery/Join makes this a lot more clear then Expr ever did.
Andrea Aime: Ok, I'm going to let you work. And sorry for stealing your time
Jody Garnett: Not prob - we had a great idea.
Jody Garnett: I will see if I still think it is great tomorrow.
Andrea Aime:
Jody Garnett: I better capture and post this log
Jody Garnett: If that is all right

Monday, September 20, 2004

 

IRC Logs - September 20th

jive Nice find with the new testing site chris
Ian hi
jive Hi Ian
IanS hi
aaime Hi
cholmes Took me awhile to figure out what you were talking about. Yeah, that was a nice
tangible benefit to the conference I went to in Italy... I sent it awhile ago to Brock as
an alternative to cite, not sure if he ever looked into it.
cholmes They will probably release the source on the GeoServer site, which will be nice,
it's all java and servlet based.
aaime Chris, what's that?
jive Does anyone have any idea when codehaus will be back?
aaime I don't...
aaime Is there any topic list? Still waiting for someone?
cholmes WFS + WMS conformance tests, done by this ACE-GIS group. They're open source and
java, I put an announcement on the GeoServer front page, and Jody just mentioned it.
jive No topic list yet, I have been working on your reprojection stratagy object for
NewQuery/Join.
jive (ext/view module)
jive Feel free to start a list:
jive I wanted to do 1) JTS open issues for GT 2.0 (but Jira is down).
jeichar 2) Grabbing features as they run by the renderer
cholmes Argh, jira's down too? That was my big task for getting online today :(
jive That is okay chris we will enjoy your company.
jive 3) What is new with GeoServer / status of 2.0 release.
jive (See now you have something to do)
jive Okay lets start; if people have more ideas later we can add it into the mix.
jive 1) JTS open issues for GT 2.0
jive JTS = Jira
jive Jira is down - so 1) is kind of over.
cholmes (how about instead I download and play with uDig! :) )
jive Chris do you remember any issues that we coud fix up this week?
jive (Awe gee thanks)
jive I thought I saw some email about GIF encoding.
cholmes No, that was the whole point of me coming in to town to good internet today, to dig
through jira, I haven't looked at it in awhile...
cholmes That's in GeoServer land...
cholmes JAI does not support GIF rendering, someone found a client library that could do it.
cholmes Perhaps there's some way to have GeoTools support it, but the code for it is all in
GeoServer I believe.
* Abs|hiof has joined #geotools
aaime I see this better put on the client side, the geotools code deals with graphic
objects, how the BufferedImages are turned into files is something that should sit on the
application side, not in the libray (in my humble opinion)
jive Agreeded.
cholmes I agree as well.
jive (sigh) to day is not a good spelling day.
jeichar 2) Grabbing features as they run by the renderer
aaime Explain what you do mean... seems active rendering to me...
jeichar I'm starting to do edits and such in udig. And in the streaming world it is quicker
to grab features as they stream by. So Lite needs the stream of features, which it
currently gets, but the outside world also need them. Or so I see it.
jeichar Basically I need a way to get a hold of the feature stream. Maybe as a feature
listener or something.
aaime Adding a listener is possible, of course, but what does the listener should provide
you? The feature, and before or after rendering it?
jeichar I need the feature. I don't know at that it matter whether it needs to be before or
after. I think before would probably be better so if modifications need to be made before
rendering they can be done.
jive Maybe I can explain: jesse would like to renderer some features (ie selected features)
twice - onto two different rasters.
jeichar That's one case. Another is I want to query attributes in the features. Possibly
even set them.
aaime This is possible. But remember that's possible only in the lite renderer, if you need
such a structure, the j2d rendered gets definitely kicked out of the game (not good in my
opinion)
jeichar That's a good point.
jeichar Do you have another idea on how I can do selection. Currently I have a "dumb"
implementation. 2 renderers. One has a filter for all the selected features and the other
is the"not" filter.
jive I would like to try the separate raster for selection idea; if only for the immidate
feedback it would offer.
aaime I think the two layers are fine... you could also modify the styling on the fly...
aaime (I mean, one renderer, with style modifications for the selected features)
* jmacgill has joined #geotools
aaime The problem with selection is the same as with rendering: how do you guarantee that it
scales when the number of selected features increases ("select all", anyone?)
jive Understood; I have also tried to throw in the wrinkle of immidiate feedback.
jive So if we have the two rasters (everything & selected), we can perform raster copies
from one to the other to provide the feedback.
jive So select all would actually be a best case senario.
jeichar Hmm I think I see the differrence, we want the selected features to be rendered to a
seperate image from the non-selected features
jmacgill sorry all, only semi here - tied up with meeings. hope to be with you properly in
20mins if the session is still goin then
jive Part of the fun is we would like to not request the features twice.
jeichar I actually have 2 renderers each with 1 layer. the selected renderer/layer and the
non-selected renderer/layer.
jive Sure thing - enjoy your meeting james.
jeichar so 2 queries as well.
jmacgill (above works if selected features are not partialy covered by non-selected features)
jeichar I want 2 layers. 1 renderer and 2 destination images.
aaime I see, a event mechanism will allow you to draw on the fly... so you will "only" have
to keep a set of fids around
jive Actually we were hoping to capture selection as a Filter.
jeichar We use filters for selection. so it could be a bbox filter
jeichar but yes. you have the idea.
jive Ah this is fun; I suppose what we are asking is - how we can insert callback code into
the rendering process.
aaime Hum... may be nice... what if you provide user with a tool like "add to selection"
"remove from selection2
aaime 2 -> "
jive We could look to our FeatureCanvas friends for API inspiration (but I missed that
meeting today).
jive Add to Filter and remove from Filter.
aaime I see
jive Good old binary opperations.
aaime Yes, in mst cases it should perform well... nice and compact
jive I am totally open to suggestions - this is just the best idea we have had yet.
aaime I can add the event listener, I'm just wondering, with j2d we don't have attributes
any more, unless we keep them in the rendered geometry happily adding to the overall memory
consuption...
aaime This may not be a disaster with a spatial data cache around, nevertheless it limits
the amount of data that can be kept into memory
aaime I believe that ESRI tools can work without having the attributes around, and they load
them only on request...
jive Somewhere you must have a loop that cycles through the FeatureReader - I think we would
like a callback there?
jive This is fun; I wish I knew this code better.
aaime Jody, with Lite this is easy, I wasn't objecting on this. Yes, it can be done on the
feature reader. But with j2d you loop over just one time...
aaime (to load the data into memory)
aaime Which means you have to keep a set of selected FIDs (we can store them into the
rendered geometries too)
aaime Oh, one thing: I may be forced to loop over the feature reader more than once if I
have more than one feature type style applied to a single feature source
jive Ah yes - I was trying to supress that bit of knowledge.
jeichar ah that's how that is done. So it is slow to have many feature type styles per
feature type. Yes?
aaime It is slower, yes
aaime (since I basically reload all of the features again)
jive But conversly it is what they asked for.
jive Each style is kind of a mini layer.
jive (at least if you want the joins to work out)
aaime Well... more or less... it could be possible to use a buffered image to renderer the
second feature type style in one scan.
* hobu_work has joined #geotools
Ian I'm not sure that would help
jeichar Depending on how big the raster is
aaime Consider the case of painting a road with two lines, one thin and one wider. To get
the best results you have to use two feature type styles
jive keep going.
aaime This means that the features will be loaded two times.
aaime If you use two rules instead, there will be some defects on line crossings
jive Unless we used that even hook idea to draw each style into two different buffered
images and composite afterwords.
Ian and so the joins between the lines work
aaime That's better done in the lite renderer itself, since it's the code that should
interpret the styles
aaime Hopefully we can build a volatile or managed image instead of a plain bufferedImage in
order to get hardware acceleration on the extra layers too
jive I would be game to try these ideas, it could be that the selection information would
consist of registering another BufferedImage to be drawn with a Filter and Style.
jive We have some progress towards that as part of udig.
aaime Yes, that's what I was suggesting above: dynamic style change
jive Okay I was just not understanding at the time.
aaime Jody, don't say BufferedImage, since this class leads to performance damnation ;-)
jive PlanarImage
Ian what;
aaime Better try to use managed images and volatile images before falling back on the plain
old and slow BufferedImage
Ian what's wrong with BufferedImae?
aaime Ian, BufferedImage is not hardware accelerated, when you draw on that it's the CPU
that's doing the work, not your graphics card
jive Memory about a Meg per layer.
Ian ah -thats ok my machines don't have graphics heads mostly
aaime VolatileImage is hardware accelerated, provided with 1.4.0, but difficult to manage
(can disappear anytime)
aaime ManagedImage is a 1.5.0 new entry I guess, but it does not disappear under you feet
while working on it
jive I would actually like to spend some brain cycles making use of B&W rasters behind
*Image; and then using JAI to style the colour information as part of a VolitileImage
rendering stack.
jive Yes I am looking forward to it.
aaime Hu?
jive I am in JDK 1.4 right now; Jesse gets to work with 1.5.0
jive (he is on linux)
aaime No, I did not understand the B&W + JAI trick
Ian I may have missed this while my connection fell over, but for the selction problem
couldn't you store the actual map image and then render the selections over it - the way gt1
did?
jive Ah to reduce memory rather than style the colour information in as part of the draw
command. Draw to a black and white image and then as part of the JAI RenderOps stack that
combines everything add in the colour informaiton. The rendering stack will be fast when it
is rooted by a Volitile image.
aaime Hum... not sure I understand... that would work only if the layer uses really just one
colour...
jeichar That is similar to what we are doing. One limitations selection must be a solid
opaque color to over write it. I think mostly it is because we want to cheat and not have 2
queries to the datastore.
jive Yes that is the case; this falls under needless optimization.
jeichar We need 2 rasters, so we can change them as soon as selection changes. then we
query and redraw the selection so it shows the entire selected features.
* jmacgill_ has joined #geotools
jeichar the change is based on raster processing. but since we don't have feature data it
is a estimation of what features are selected.
jeichar the change is made for the users instant gratification. Then the full selection is
correctly rendered.
jeichar Often though. during a zoom both selected features and normal features must be
rerendered.
aaime Hum... you perform selections only on a "current" or "active" layer, right?
jeichar In this case we do not want to make 2 queries
* cholmes has quit IRC (Read error: 104 (Connection reset by peer))
jeichar No All layers can have a selection
jeichar I think...
jmacgill Typical solution would be to mark layers as - visible, editable, selectable
(toggle for each)
jeichar thats right.
* cholmes has joined #geotools
aaime Yet with a image manipulation tool you can select pixels...
jeichar Yes but that would not be the same as selecting features. A pixel is not a feature
is it?
aaime No, a pixel is a single value in a raster data. A value that can be modified.
End of #geotools buffer Mon Sep 20 13:37:28 2004Start of #geotools buffer: Mon Sep 20 14:45:27 2004* Now talking in #geotools
* Topic is 'www.geotools.org'
* Set by Abstract^ on Wed Jul 07 07:26:35
jive gday
jive Nice find with the new testing site chris
* Ian_T has joined #geotools
* jeichar has joined #geotools
* IanS has joined #geotools
Ian hi
jive Hi Ian
IanS hi
* aaime has joined #geotools
aaime Hi
cholmes Took me awhile to figure out what you were talking about. Yeah, that was a nice
tangible benefit to the conference I went to in Italy... I sent it awhile ago to Brock as
an alternative to cite, not sure if he ever looked into it.
cholmes They will probably release the source on the GeoServer site, which will be nice,
it's all java and servlet based.
aaime Chris, what's that?
jive Does anyone have any idea when codehaus will be back?
aaime I don't...
aaime Is there any topic list? Still waiting for someone?
cholmes WFS + WMS conformance tests, done by this ACE-GIS group. They're open source and
java, I put an announcement on the GeoServer front page, and Jody just mentioned it.
jive No topic list yet, I have been working on your reprojection stratagy object for
NewQuery/Join.
jive (ext/view module)
jive Feel free to start a list:
jive I wanted to do 1) JTS open issues for GT 2.0 (but Jira is down).
jeichar 2) Grabbing features as they run by the renderer
cholmes Argh, jira's down too? That was my big task for getting online today :(
jive That is okay chris we will enjoy your company.
jive 3) What is new with GeoServer / status of 2.0 release.
jive (See now you have something to do)
jive Okay lets start; if people have more ideas later we can add it into the mix.
jive 1) JTS open issues for GT 2.0
jive JTS = Jira
jive Jira is down - so 1) is kind of over.
cholmes (how about instead I download and play with uDig! :) )
jive Chris do you remember any issues that we coud fix up this week?
jive (Awe gee thanks)
jive I thought I saw some email about GIF encoding.
cholmes No, that was the whole point of me coming in to town to good internet today, to dig
through jira, I haven't looked at it in awhile...
cholmes That's in GeoServer land...
cholmes JAI does not support GIF rendering, someone found a client library that could do it.
cholmes Perhaps there's some way to have GeoTools support it, but the code for it is all in
GeoServer I believe.
* Abs|hiof has joined #geotools
aaime I see this better put on the client side, the geotools code deals with graphic
objects, how the BufferedImages are turned into files is something that should sit on the
application side, not in the libray (in my humble opinion)
jive Agreeded.
cholmes I agree as well.
jive (sigh) to day is not a good spelling day.
jeichar 2) Grabbing features as they run by the renderer
aaime Explain what you do mean... seems active rendering to me...
jeichar I'm starting to do edits and such in udig. And in the streaming world it is quicker
to grab features as they stream by. So Lite needs the stream of features, which it
currently gets, but the outside world also need them. Or so I see it.
jeichar Basically I need a way to get a hold of the feature stream. Maybe as a feature
listener or something.
aaime Adding a listener is possible, of course, but what does the listener should provide
you? The feature, and before or after rendering it?
jeichar I need the feature. I don't know at that it matter whether it needs to be before or
after. I think before would probably be better so if modifications need to be made before
rendering they can be done.
jive Maybe I can explain: jesse would like to renderer some features (ie selected features)
twice - onto two different rasters.
jeichar That's one case. Another is I want to query attributes in the features. Possibly
even set them.
aaime This is possible. But remember that's possible only in the lite renderer, if you need
such a structure, the j2d rendered gets definitely kicked out of the game (not good in my
opinion)
jeichar That's a good point.
jeichar Do you have another idea on how I can do selection. Currently I have a "dumb"
implementation. 2 renderers. One has a filter for all the selected features and the other
is the"not" filter.
jive I would like to try the separate raster for selection idea; if only for the immidate
feedback it would offer.
aaime I think the two layers are fine... you could also modify the styling on the fly...
aaime (I mean, one renderer, with style modifications for the selected features)
* jmacgill has joined #geotools
aaime The problem with selection is the same as with rendering: how do you guarantee that it
scales when the number of selected features increases ("select all", anyone?)
jive Understood; I have also tried to throw in the wrinkle of immidiate feedback.
jive So if we have the two rasters (everything & selected), we can perform raster copies
from one to the other to provide the feedback.
jive So select all would actually be a best case senario.
jeichar Hmm I think I see the differrence, we want the selected features to be rendered to a
seperate image from the non-selected features
jmacgill sorry all, only semi here - tied up with meeings. hope to be with you properly in
20mins if the session is still goin then
jive Part of the fun is we would like to not request the features twice.
jeichar I actually have 2 renderers each with 1 layer. the selected renderer/layer and the
non-selected renderer/layer.
jive Sure thing - enjoy your meeting james.
jeichar so 2 queries as well.
jmacgill (above works if selected features are not partialy covered by non-selected features)
jeichar I want 2 layers. 1 renderer and 2 destination images.
aaime I see, a event mechanism will allow you to draw on the fly... so you will "only" have
to keep a set of fids around
jive Actually we were hoping to capture selection as a Filter.
jeichar We use filters for selection. so it could be a bbox filter
jeichar but yes. you have the idea.
jive Ah this is fun; I suppose what we are asking is - how we can insert callback code into
the rendering process.
aaime Hum... may be nice... what if you provide user with a tool like "add to selection"
"remove from selection2
aaime 2 -> "
jive We could look to our FeatureCanvas friends for API inspiration (but I missed that
meeting today).
jive Add to Filter and remove from Filter.
aaime I see
jive Good old binary opperations.
aaime Yes, in mst cases it should perform well... nice and compact
jive I am totally open to suggestions - this is just the best idea we have had yet.
aaime I can add the event listener, I'm just wondering, with j2d we don't have attributes
any more, unless we keep them in the rendered geometry happily adding to the overall memory
consuption...
aaime This may not be a disaster with a spatial data cache around, nevertheless it limits
the amount of data that can be kept into memory
aaime I believe that ESRI tools can work without having the attributes around, and they load
them only on request...
jive Somewhere you must have a loop that cycles through the FeatureReader - I think we would
like a callback there?
jive This is fun; I wish I knew this code better.
aaime Jody, with Lite this is easy, I wasn't objecting on this. Yes, it can be done on the
feature reader. But with j2d you loop over just one time...
aaime (to load the data into memory)
aaime Which means you have to keep a set of selected FIDs (we can store them into the
rendered geometries too)
aaime Oh, one thing: I may be forced to loop over the feature reader more than once if I
have more than one feature type style applied to a single feature source
jive Ah yes - I was trying to supress that bit of knowledge.
jeichar ah that's how that is done. So it is slow to have many feature type styles per
feature type. Yes?
aaime It is slower, yes
aaime (since I basically reload all of the features again)
jive But conversly it is what they asked for.
jive Each style is kind of a mini layer.
jive (at least if you want the joins to work out)
aaime Well... more or less... it could be possible to use a buffered image to renderer the
second feature type style in one scan.
* hobu_work has joined #geotools
Ian I'm not sure that would help
jeichar Depending on how big the raster is
aaime Consider the case of painting a road with two lines, one thin and one wider. To get
the best results you have to use two feature type styles
jive keep going.
aaime This means that the features will be loaded two times.
aaime If you use two rules instead, there will be some defects on line crossings
jive Unless we used that even hook idea to draw each style into two different buffered
images and composite afterwords.
Ian and so the joins between the lines work
aaime That's better done in the lite renderer itself, since it's the code that should
interpret the styles
aaime Hopefully we can build a volatile or managed image instead of a plain bufferedImage in
order to get hardware acceleration on the extra layers too
jive I would be game to try these ideas, it could be that the selection information would
consist of registering another BufferedImage to be drawn with a Filter and Style.
jive We have some progress towards that as part of udig.
aaime Yes, that's what I was suggesting above: dynamic style change
jive Okay I was just not understanding at the time.
aaime Jody, don't say BufferedImage, since this class leads to performance damnation ;-)
jive PlanarImage
Ian what;
aaime Better try to use managed images and volatile images before falling back on the plain
old and slow BufferedImage
Ian what's wrong with BufferedImae?
aaime Ian, BufferedImage is not hardware accelerated, when you draw on that it's the CPU
that's doing the work, not your graphics card
jive Memory about a Meg per layer.
Ian ah -thats ok my machines don't have graphics heads mostly
aaime VolatileImage is hardware accelerated, provided with 1.4.0, but difficult to manage
(can disappear anytime)
aaime ManagedImage is a 1.5.0 new entry I guess, but it does not disappear under you feet
while working on it
jive I would actually like to spend some brain cycles making use of B&W rasters behind
*Image; and then using JAI to style the colour information as part of a VolitileImage
rendering stack.
jive Yes I am looking forward to it.
aaime Hu?
jive I am in JDK 1.4 right now; Jesse gets to work with 1.5.0
jive (he is on linux)
aaime No, I did not understand the B&W + JAI trick
Ian I may have missed this while my connection fell over, but for the selction problem
couldn't you store the actual map image and then render the selections over it - the way gt1
did?
jive Ah to reduce memory rather than style the colour information in as part of the draw
command. Draw to a black and white image and then as part of the JAI RenderOps stack that
combines everything add in the colour informaiton. The rendering stack will be fast when it
is rooted by a Volitile image.
aaime Hum... not sure I understand... that would work only if the layer uses really just one
colour...
jeichar That is similar to what we are doing. One limitations selection must be a solid
opaque color to over write it. I think mostly it is because we want to cheat and not have 2
queries to the datastore.
jive Yes that is the case; this falls under needless optimization.
jeichar We need 2 rasters, so we can change them as soon as selection changes. then we
query and redraw the selection so it shows the entire selected features.
* jmacgill_ has joined #geotools
jeichar the change is based on raster processing. but since we don't have feature data it
is a estimation of what features are selected.
jeichar the change is made for the users instant gratification. Then the full selection is
correctly rendered.
jeichar Often though. during a zoom both selected features and normal features must be
rerendered.
aaime Hum... you perform selections only on a "current" or "active" layer, right?
jeichar In this case we do not want to make 2 queries
* cholmes has quit IRC (Read error: 104 (Connection reset by peer))
jeichar No All layers can have a selection
jeichar I think...
aaime Hum... you're thinking that you cannot perform selections on raster data, right?
jmacgill Typical solution would be to mark layers as - visible, editable, selectable
(toggle for each)
jeichar thats right.
* cholmes has joined #geotools
aaime Yet with a image manipulation tool you can select pixels...
jeichar Yes but that would not be the same as selecting features. A pixel is not a feature
is it?
aaime No, a pixel is a single value in a raster data. A value that can be modified.
jeichar We have to ask what is desired when selections occur.
jeichar usually people want to operate on a feature set
aaime Or, you could be willing to perform some operation only on a subset of cells... you
could get away asking the user to provide a poligonal selection anyway...
aaime Maybe you could have a look at ERMapper, this should provide you with a set of
operations that a GIS can perform on raster data...
aaime (or IDRISI, as well)
aaime Anyway, being able to perform such operations is a plus, not something that can be
perceived as a basic operation. I think most people can live without them.
aaime Just don't forget they are possible and indeed sometimes useful
jeichar The plugin architecture would allow such a plugin to be made. But it would
probably(I could be wrong) be used in a seperate editing mode.
aaime Agreed
aaime So, to get back on track, we should:
jeichar but back to the problem. Should the rendering api be modified so different map
layers can be rendered to different buffered images?
jive Fun stuff - I was going to ask what API change we should request to lite renderer to
allow us to hook into the rendering process?
jive :-)
jive Event idea
jive BufferedImage with Filter and Style idea
jive Did I miss out on anything?
aaime I guess I prefer the latter.
jive Same
jeichar I agree
jive That was easy
jive How should we proceed?
aaime But I'd say, we use the multiple buffers only when there is more than one feature type
style for a single layer
aaime Or do you want the lite renderer to become a multithreaded beast capable of loading
multiple layers at the same time?
aaime I'd prefer not to, this can be achieved by an external wrapper if required
jeichar would it be a mode so that type of operation can be turned off. SOme users may not
want the extra memory usage.
aaime Also, the filter+style idea would allow us to keep j2d in the game
jive I was thinking we would add the API to try it out; and then LiteRenderer could switch
it's style rendering over to use multiple rasters later.
jive ++Yes
aaime Multiple raster does not mean multithread, yes?
jive Correct
aaime Then that's ok to me... Even if this means changing quite a bit the way lite loops
over the features...
jive The poor render is just being asked to draw the same Feature multiple times to
different rasters using different styles.
aaime Now it loops over layers, then feature type styles, the features, and for each
feature, over rules and symbolizers.
jive So we are reversing the loop over styles and the loop over features?
aaime What you ask is a bit different: loop over layers, for each set up a set of raster
renderes, one for each feature type style, and then read the features and inform them (or
just call them)
jive reverse is a bad word to use in the context of lists, we are swaping the order of these
two loops.
jeichar right now the process styler method is being called multiple times per layer?
aaime Yes, for each feature do a FeatureTypeStyleRenderer.render(feature)
jmacgill try not to break the zorder for features
jeichar right.
aaime It's just a matter of proper stacking of the feature type styles layers
aaime Jessie, only if there is more than one feature type style
jeichar that's right. It was what I meant
aaime Look at LiteRenderer2. The main loops are simple enough that you should be able to
understand how they work quickly
jeichar ok I am pretty familiar with this part of the code, I could make the changes if
you're feeling too busy. But it probably wouldn't be for a month or so. My 2 renderer
solution will work until the time comes for optimization.
aaime No problem. Yes, I'm quite busy these days...
aaime brb
jive Very nifty; just to be clear my priority is on the instant feedback (and we can still
acomplish that using the existing approach).
aaime I see. Is there any possibility that your mighty renderer infrastructure can become
part of gt2? ;-)
jive Sure!
aaime Oh, btw, it seems you still haven't looked into active rendering, right?
jive Actually I would like do as much of this work in gt2land as possible.
jeichar What do you mean by active rendering?
jive By active rendering you mean keeping Geometry+Style information in a cache?
jive J2D or FeatureCanvas ideas?
aaime No. IanS, you're the expert. Are you around?
IanS huh? yes
aaime Care to lecture us about active rendering? (Again)
jive BTW Most of the complexity of the UDIG rendering infrastructure is in choosing what data source
to use - everyuthing else is straight up using geotools to make an application.
IanS instead of rendering on the AWT thread, you render on your own thread
jeichar Oh yes that is what we're doing. We actually have a number of threads going.
jive ok? We are stuck in our own thread anyways.
IanS then you are active rendering
jive Whew that was easy
jive (especially since Jesse did the work)
aaime Do you mean that you start displaying the map before it's fully drawn?
aaime That's was part of the active rendering demo IanS showed us more than one year ago
jive Yes
aaime Oh... it's that already in udig 0.2?
jive (really need that quick feedback)
jive Yes.
aaime Super-cool. I need to try that beast out :-)
jive I would love to sort by line length - but everyone tells me I am crazy :-)
aaime You are ;-)
jmacgill your crazy
jive Okay I had that one coming.
aaime You asked for it ;-)
jive Speaking of crazy David Zwiers has the start of NewQuery and Join on svn for people to look at.
jive I am working on "GeometryBuilder" as a placeholder for Andrea's reprojection stratagy object.
jmacgill however... might I suggest low quality, semi random sampled rendering during pans that is dumped
when the user finaly stops moving (or zooming)
jive (NewQuery is crazy not David)
jmacgill i.e. switch anti-aliasing off, just do plain thin lines - no fills..
jmacgill had a drawing package that did this, was very nifty
jive I was thinking of throwing the raster around duing pans and zooms. Graphics card would make that quick.
Although I admire JUMPs renderer random feature idea.
aaime Is anti-aliasing on by default?
IanS no
jmacgill no idea, - would be nice to switch it on in a background thread once rendering had finished and
display that image if the used didn't do anything
* Ian_T has quit IRC (Connection timed out)
jive I was going to ask chris for 3) GeoServer / GT 2.0 update
jive Do you want to even bother chris since Jira is down?
cholmes I'm not sure, I'm pretty dissapointed that it's down, as I did a three hour commute today to play
with jira...
cholmes I think I will still try to release 1.2.2 tomorrow.
jive We have our handy Jira representative (cough James) here perhaps he can do something?
cholmes But it won't have a nice updated jira log, unless it comes back up.
jmacgill how long has jira been down?
jive codehaus has been down since 9 - 5 hours.
jive that is our homepage is down too
jive Andrea I was going to ask you to look at: http://svn.geotools.org/geotools/trunk/gt/ext/view/src/org/geo
tools/data/GeometryBuilder.java
aaime You have no mercy on me ;-)
jive There is no hury.
jive I was just trying to be helpful work out some of the issues from our IRC last week.
aaime I guess it would be better if I send you the classes that I've written and that are sitting on my disk?
jive (It was a very nice efficient IRC meeting for those who could not attend).
aaime Jody, I was kidding
jive Sure I will intergrate. These are all just placeholder until we get time to work on them.
aaime Anyway, do you want to have a look at those classes?
jive May be more efficient to send me what you have (I can confirm if we are on the same track or not).
aaime Ok, I'll send you every modified class in the main module
jive Thanks.
jive I am not sure we ever sent our two weeks till 2.0 email message out? Should I do now?
jive It really depends on your timing Chris.
cholmes Yeah, send it out now.
cholmes I'm going to try to release tomorrow...
cholmes If not tomorrow then next week for sure.
cholmes There will probably be a few more bug fixes on that branch, but they can be 2.0.1, ect.
jive I had kind of wanted to time 2.0 with your release ...
jive What is your GeoServer release number Chris (so I can mention it in the email message).
aaime Well, nice meeting, but the day is getting old for me... see you next meeting.
jive Thanks muchly
* aaime has left #geotools
cholmes 1.2.2
cholmes Not sure that I really want to wait two weeks.
jive Thanks.
cholmes I could wait a week, and spend the week on documentation
jive Well we said we would send the email message last week.
jive How about "One week till 2.0" :-)
cholmes But I do want something out soon, there's a decent number of nice fixes... speeding things up a lot,
WMS with postgis, postgis with wkb, oracle thick client...
jive Was there anything you *wanted* module maintainers todo? Readme.txt file?
cholmes Sounds good.
Torey Anyone here familiar w/deegree much?
jive Okay I will send that off.
jive I have looked over degree recently - but not actually worked with it.
Torey Okay
Torey I'm having SLD issues with it
* Martin has joined #geotools
jive geotools runs its own SLD classes, and GeoAPI recently invented some. Eventually we should all work
together.
jive Anything specific we could help with; not that I think I can help very much.
Torey Oh, I know
jive Hi Martin - I was unable to attend the GeoAPI meeting this morning.
Torey but does GeoTools' WMS support cascading with other WMSes yet?
Martin I was not at the GeoAPI meeting. neither. It is a little bit early for me...
cholmes No, not yet - GeoServer 1.3 will
cholmes (geoserver is geotool's wms)
Torey right
Torey but that's why I'm using deegree
Torey I'm using Geoserver's WFS
Torey oh that does remind me
Torey I think the DataSource GML service is broken
jive How so
Torey well
Torey first, when I set a .gml file as a data source (as opposed to a shape file or PostGIS source)
Torey it would complain about it -- e.g. no handle available
Torey I went and modified the META-INF/services/org.geotools...DataSource file to include the GMLDataSource
handler
Torey and then it began parsing it
Torey buuuut
Torey it still crapped out on parsing
jive Is this GML data store or gml datasource?
Torey lemme double check
jive GML Data Store is underdevelopment, and I thought GML DataSource was removed?
cholmes Nope, looks like it's still in there....
cholmes module/main/src/org/geotools/data/gml/GMLDataSource...
Torey DAtaSource
cholmes Doh.
jive I just removed the superclass DataSource; we really do hope to replace it with module/gml as soon as
possible.
cholmes It really started parsing? I don't think a DataSource should work with GeoServer...
cholmes Unless you're using version 1.0....
Torey I'm using 1.0
Torey and I tried 1.2
cholmes 1.2 didn't work?
Torey but I'm using 1.0 right now (I was using 1.2, but the specs for this project required 1.0)
Torey I don't think it did, but I can't remember
cholmes The specs required _GeoServer_ 1.0?
cholmes Or 1.0 of the WFS spec?
Torey Yeah :/
Torey 1.0 of the GeoServer
cholmes Why? That's silly. What project is this?
Torey it's for an IBM based project
Torey *shrug*
cholmes GMLDataSource is kind of a piece of shit, so it's not surprising it doesn't work.
Torey ah
Torey haha
cholmes We basically gave up on new GMLData development over a year ago.
cholmes As it was so crappy it just put us in a hole.
Torey but GMLDataStore works okay?
cholmes The parsing classes are decent, but the datasource is absolute shit.
Torey so GMLData* works
Torey err
Torey so GMLData* doesn't work?
cholmes I haven't tested it (GMLDataStore), but it's working in uDig...
jive GMLDataStore is the real deal but is very new. You need valid schemas to get it out of the
starting gate, and you need to give it a hint when encoding.
Torey b/c I just wound up writing a generic parser
cholmes I think it should be working pretty well. I'm planning on starting to use it in GeoServer
within a month.
Torey which worked "okay" for the demo purposes
Torey cool
cholmes The refractions crew just finished up a whole xml parsing framework for geotools.
Torey nice
cholmes Now supports wfs and gml.
cholmes Should do filter and style eventually.
cholmes I'd imagine that Jody is just being modest right now, I think it probably works pretty well.
cholmes I'd venture to say it definitely works better than GMLDataSource.
jive It does filter encoding (since we need to talk to GeoServer) but decoding will have to wait
for others.
Torey Ahh
jive Well I am also being modest because it is David's work (and he can brag about it himself).
IanS did you guys drop the Transformer classes from the encoding parts?
jive IanS you will have to talk to David on that one.
IanS nkay
cholmes (I second that, I haven' tlooked at it yet, but I think he may have, as I asked him about
it a bit, and I think he does have a new way of gml production)
jive If I understand you only need to supply a hint when things are ambigious (like encoding a
FeatureCollection when both the wfs and gml schemas are in scope).
jive I can pester him to join the meeting if you guys want to talk shop.
cholmes Are there any problems with them IanS? For 1.3 I'm going to use David's classes for
cascading wfs, and inserts, but am unsure if I want to replace the transformer based gml producer
jive I think using Davids XMLPrinter that you will have way less hinting to do. I knows the schemas
and can figure out most everything.
cholmes Ok, cool. I'll look into it as I go down that road.
IanS none that I know of
jive no idea -
jive I am not actually sure what they are.
jive I should probably grab the logs

Tuesday, September 14, 2004

 

Data Query Breakout IRC

Hi Everyone - thanks for attending todays breakout IRC.
What I really want to know is what needs doing?
* polio has joined #geotools
Hi David - I just got here myself.
heya
As I said, I hope I'll be able to stay but eletricity is playing games due to very bad wheater
My impression is "problem" is that we would all like to code something up to solve our problem
(reprojection, join, query) where as what we really need is a design.
I would settle for making sure I understand everyones problem, and then I can go away and write
up a design for us to consider.
Ok, nice
So Andrea - since you have intermintent power - why don't you go first.
Ok.
As you know, I've been working on reprojection lately
Since we are speaking about data sources and types, let's consider only reprojection at this
level
At the moment, we have optional parameters on the query that allow forcing a cs and another to
reproject to another
Forcing is not a problem, since it's really just a way to change the type of a feature and
saying: I know better than the data source and the cs of the geometry x is really myCs
Reprojecting is more complex, since it involves transforming the geometry
There are many ways to perform transformation, with different accuracy/speed/complexity
tradeoffs
So far there is no way to provide "reprojection hints" in the query
Okay so I think we have our first target.
I mean, for example, say which reprojection algorithm to use
And also parameters for this algorithms
Speaking of which we need to start making datastores return what they can of their coordinate
system, as I don't think we do that at all now...
And finally, is a reprojected feature read only?
Yes, we don't do it at all... at the moment to use reprojection you first have to force a CS
in, and then say which CS you want to reproject to
And I think that is point number two.
As I understand forcing the CRS is more than just a hack, when we actually have our datastores
returning CS information we will *still* need to force the issue.
Yes, since the datastore may not know (see shapefile) or the information may be simply wrong
Yes.
Okay I can work with that.
Just a bit of background for Query. It origionally comes from the WFS specification - yes?
Or is it our own invention.
Chris can you answer this one?
(I was not around when Query was invented so I don't know)
I think it does not come directly from WFS, but it's a way to put togheter the various
components of a WFS request
Okay cool.
It was inspired by WFS
Doh, I thought Query was introduced by you...
I don't think so?
Yeah, it was introduced by me, inspired by a WFS xml Query
Ah, sorry
Whew
Okay I suppose I am up next (from the emailed agenda).
The coordinate reprojection stuff is outside the scope of WFS query, but it is quite likely
that the next spec will include similar stuff.
We have been hacking DataStore very hard of late, introduced Catalog API (AbstractDatastore and
thus all DataStore implementations) now implement Catalog.
AbstractDatastore also "wraps" the Param information as a ParameterGroup (in the Martin/Geoapi
sense).
There is also considerable duplication and overlap between: FeatureView, FeatureResults &
FeatureSource & any of the RandomAccess APIs that have been proposed.
I would like to sort this out.
Sounds nice (I've not checked out 2.1 in awhile)
(target #3 for my list)
Before I turn the floor over: we currently have three places to squirl away hints
With Query, With Transaction and with DataStore Params.
(Although I kind of think we need a forth - with FeatureType)
(target #4 for my list)
Okay over to 2) Social Change progress) (robA or email proxy)
Do we have robA or any idea what those guys are up to? Chris?
RobA does not seem to be there...
That is why I was tagging Chris (poor chris)
Well I can try ...
My impression is that RobA is going for a deadline, and they have been making "custom"
datastores that our backed by direct SQL expresssions that perform joins.
Sorry, I was distracted.
Yes.
The goal was to make his custom datastores agree with whatever we do, so it can be slotted
cleanly into geoserver.
They're looking to pass the code off to us pretty soon, to hopefully do more generic cross
datastore joins
Direct SQL is nice and bad at the same time. Nince because you are using full power, bad since
it may be database dependent
I just was hoping for an update, and implementation details. Having code would be even better.
Still any solution we do for joins, looks like people will want hooks to intercept joins the
recognize and replace with custom code.
Yeah, I think Peter was going to pass it off soon.
Yes, definitely.
(Actually this really is not a bad idea, a similar thing may pay off in reprojection land).
This is known as the "blackboard" approach for any pattern guys out there.
Definitely not a GOF pattern...
Throw up data (like a request) up on a shared "blackboard" and various plugins get a go at
answering the question.
It is an alternative to splitting your application into layers (a bit more high level then a
design pattern).
http://c2.com/cgi/wiki?BlackboardMetaphor
Ah, it's in "pattern oriented software architecture"
Sorry to geek out for a bit - bad jody no cookie.
What is next ...
Right 3) Expr FeatureView
Expr is our origional scratching post for splitting up this problem. It is more successful as a
FilterFactory then anything else right now.
David has been harping on me about it not doing anything more then Filter/Expression - and he is
right. I just like the style of programming better, it is lazy in binding FeatureTypes to attribute
expressions (at which point it produces real Filter/Expression statements).
* cholmes has quit IRC (Read error: 104 (Connection reset by peer))
So even if we decide to persue Expr, it really should not replace Expression/Filter.
(Although Geoapi has some interfaces that might)
Expression and Filters, as Styles, are in fact very inconvenient to build....
Geoapi has just "produced" Expression Filter and Styles.
* cholmes has joined #geotools
I was horrified but don't have time to make geoapi and geotools play nice together.
They are going to look at what we have. And I have told them flat out to just take our SLD style
class.
(sorry, mozilla just ate it on me, missed the last few minutes)
Guys, get yourself Gaim, it works on Windows too ;-)
Does Gaim to IRC? I sometimes use it for IM.
I tried it once and couldn't quite get it to work...downloading now.
I use it for IRC only...
yah gaim does irc
So my first question is - are we missing anything?
I know we just covered a *lot* of ground, but I wanted to make sure something else is not going
jump out and grab me.
Thinking .... The only thing I can think of is this - DirectoryDataStore really should be recast
in terms of "FileFormats" rather than wrapping a bunch of DataStores as it does now.
I don't know exactly what kind of changes you want to propose, but make sure that they don't
impair the ability to cache features (to do it effectively)
I think some work could be done to improve the consistency within the expression/filter api as
well as to improve usability
I guess that expression and filter interfaces come from OGC, right?
Well I would kind of break the problem in two, make sure the geoapi Expression/Filter interfaces
are what we want. And then make Expr implement those interfaces - and then cut over.
yah, they match the schema specs for them
but i was thinking in terms of mutability (inconsistent)
We get Expr for ease of construction, and we have the interfaces to walk.
and was also thinking that some convinience methods / utilities might also be in order
David and I noticed that all the JDBC DataStores need to walk the Expression tree and place
things into two piles (that which I understand, and that which I post process)
Well, the only thing I'm thinking about, is that the Expr name sounds like a replacement for
Expression, and not a convenient way to build Expression and Filters
but do not think another set of classes would really make it easier as most pl would end up
learning another set of code
I think supporting this common use would be smart.
aaime -- agreed
Is it possible to call them ExpressionBuilder or FilterBuilder or something like this?
Maybe - although we will need something to implement the Filter interfaces.
It's usually not great to say "look, we have those classes but they are too difficult to deal
with, so use those other to build them up"... in fact you have to code less, but you have to learn
more (both the complex classes and the code that need to conveniently build objects)
I was under the impression we have interfaces, and it is an open question if we use a Factory,
Builder or Expr to build up something that implements those interfaces.
The open question is the real problem :-) Someone trying to learn the API has to learn all the
ways and then decide which one to use on a case by case basis...
I think the broader goal is to leverage any knoweldge of the standard they may have. That is
hopefully they only really to learn the construction.
Okay I would like to have only one way - my heart is not set on Expr.'
* cholmes has quit IRC (Read error: 104 (Connection reset by peer))
* cholmes has joined #geotools
Here is a link to geoapi filter: http://geoapi.sourceforge.net/snapshot/javadoc/org/opengis/filte
r/package-summary.html
Main difference is they have classes where we have constants (they told me they were going to
"Fix" this, and use enums)
Hum... I guess there is no way out... the Filter, Expression and Style objects are really
complex, thus difficult to build... so we need some convenience builders
Yeah that stuff does not look current.
* jmacgill wakes up
Do those interfaces come from some project, like Deegree, or they have been taken out of the
blue?
I think the blue, because we have not done a good job communicating what we have.
Same for the Styling interfaces.
As far as I know the geoapi ones came out of the blue
They only put the filter stuff in to support their sld package.
Well, our API is public, Deegree's one too so... it was just a download aways (ours is even
directly on the web...)
Agreed - I was annoyed :-(
They did a nice "best of" collabarative thing for the Feature api.
but sld/filter was a surprise.
I think sometimes they just dumped things in to hit deadlines
Probably best to consider them placehoaders
Probably best make sure they are really placeholders ;-)
:)
We could always make several jira tasks to map there stuff to ours...
I agree on spending some effort to be consistent with standards, but re-coding every interface
and all the client code is too much
Okay we are slowing down here - lets talk to martin and try and make sure both groups work
together.
I think I have everything I wanted to know - at the moment.
The only I kind of would like is direction on the first two items:
- Making DataStore support CRS
- Allowing Andrea to do forceCS and reprojection
I would hate to see Andrea slowed down while fuss away on a design.
We could however call it a day - what do you guys think?
sure, we got a good statr
*start
Jody, all I need is a consistent way to pass parameters to the reprojection code. And also,
maybe to get rid of getView and have
the getFeatureSource call do this
eventually by returning a FeatureSource instead of a FeatureStore
It's not so complex, just need to move the code from getView into the feature source building
code
and make sure every data store uses this
What parameters do you need pass in?
correct - need to pass in?
It depends on the algorithm... maybe it's best to pass the algorithm itself, that is, an object
that can do coordinate sequence reprojection
and fall back on a default if none is provided
Two ideas: A GeometryFactory and a GeoemtryMangler { public Geometry mangle( Geometry ) }
the GeometryMangler could do forceCS, reprojection or nothing.
I already have a GeometryTransformer object on my disk
What does it look like?
Interface wise - what are the methods.
But it works on Geometry only, not on the type
Wait, looking
(slow eclipse startup...)
I know - we would have to extend it: public CRS mangle( CRS );
Ok, here we go:
setMathTransform(MathTransform2D)
Geometry transform(Geometry g)
Right now the featureSource binding code is done by "typeName" not by Query.
setCoordinateSequenceTransformer(transformer)
Admittedly this cannot go on since we need at the very least namespace:typeName (thanks for
making life complicated David)
np
And it's a class, not an interface.
So I would not mind using getFeatureSource( Query ) rather than getFeatureSource( typeName )
So would the following be good:
But wait: the geometry transformer is not the variable part of the equation... it the way we
transform coordinate sequences that change
GeometryStratagy {
GeometryFactory factory()
CRS transform( CRS )
Geometry transform( Geometry )
}
I was thinking that you would have different implementations of Geometry transform( Geometry ) -
and MathTransform2d did not appear in my API at all.
Uhm... the factory should be the one contained in the geometry that needs to be transformed
Can you say that again?
I didn't get it.
Every Geometry object references the factory that built it
A reprojected Geometry should use the same factory as the original geometry (IMHO)
Ah - I was looking for a way to bootstrap the process - a way to force DataStore to use a user
supplied GeometryFactory.
(May not be a good idea)
The GeometryTransformer object is used in the ReprojectFeatureReader to perform the reprojection
No, I think it's a good idea instead. A very good one. But I also think that it's something
that comes before the reprojection (if any)
Okay I think we are on the right track here - I am just going to sum up:
1) Andrea will create class that Query can use to specifiy CS/reproject/Geometry factory and
submit it to the list
2) Jody will change getFeatureSource( typeName ) to getFeatureSource( Query ) -
getFeatureSource( typeName) will become a convience method.
3) Jody and David will try and come up with a plan for collapsing our many Feature* interfaces.
4) Directory Data Store will be looked at with respect to 3
I'll try. But I will need some assistance... Jody, can I contact you on IM when I'll do this?
And we can all try and work with GeoAPI to figure out Expression/Filter.
Yes.
Fine
I have plenty of thinking to do as well.
So Chris you were wondering when you would have a stable 2.1 branch - does this meeting answer
your question?
As far as I know this is the last RnD on the plate for 2.1.
Cool.
So any next big idea will go on 2.2, yes?
Yep - right now the only thing there is GeoAPI Geometry :-)
And then we're also doing JTS change over on 2.1?
yay, the big geometry shift
JTS change over? The CoordinateSequence stuff - I sure hope so.
I tried to follow that thread, can I get a quick summary of why it's so good?
Well, it seems that David is answering my e-mails with one week delay... so it will take quite
a bit of time
CoordinateSequence summary?
Part of 3) will be trying to come up with something smart for the random access / Index.
Martin you mean?
Martin Davis, yes, sorry
I get the impression his is working on it over the weekends.
his = he
Chirs, still wanting that summary?
* groldan has quit IRC (Remote closed the connection)
James can you collect these logs - I am having IRC issues.
Bye
fraid not - im idirect and using a command line client
Sigh
i got em
gaim :)
I will collect what I have.


Monday, September 13, 2004

 

IRC Logs - September 13th

cholmes Yeah, that's one thing I was going to ask about today, stability on the trunk. I've become damned spoiled lately being able to work on my stable branch, and would like to know when we might make another one.
jgarnett Hi Chris
cholmes Hi Jody
jgarnett Well I was going to talk about that - I am going to cut 2.1.M0 today.
aaime Jody might be quite interested in this too... Jody, we were speaking about the changes that will occur if we manage to get the coordinate sequence work into JTS
aaime and the trunk instability that will follow...
jgarnett Ah yes - that will be fun.
aaime It will be especially fun if after all the changes we get a considerable speed up... not that funny otherwise ;-)
jgarnett I am all for it - even with the trunk instability. I am more interested in when Martin and Coordinate Systems will finish up.
aaime Unfortunately Martin is not there... too bad, I wanted to ask him advice on how to test the coordinate system reprojectors...
jgarnett Speaking of your stable branch chris - can we call it Geotools 2.0?
aaime Anyway, on that topic I have questions for you too, if there is time. Let's say it's one of the topics for this evening...
aaime (evening, morning, night, whatever...)
cholmes Um, I've got a few more fixes to get in, but after I put out the next geoserver release I'll be about done with 2.0.x except for bug fixes.
cholmes (1.2.2, should be a week or two away).
cholmes I just did a few mysql fixes, and there may be a few others.
jgarnett Okay I would like to roll out Geotools 2.0 at the same time.
cholmes Sounds good, I'll let you know.
cholmes And then when might we get a fairly stable 2.1?
aaime Does anyone have plans on how to forward port the 2.0.x fixes to the trunk?
cholmes Yeah, I'll be more or less forced to do it when I move branches.
jgarnett We have two outstanding issues before it is even worth making a stable 2.1
cholmes I need all those fixes I put in for geoserver.
jgarnett CRS and reprojection
jgarnett Expr and FeatureType manipulation.
jgarnett I was hoping to talk abit about the second one today.
jgarnett Why don't we set up an agenda?
cholmes Ok, I can live with both of those, as I have a big interest in them, want them both for 1.3
cholmes sounds good.
jgarnett 1) GT 2.0
jgarnett 2) GT 2.1.M0
cholmes * ShapefileDataStoreFactory charSet parameter
aaime Feature reprojection and queries
aaime (did anyone see my e-mails on the devel list?)
polio xml -- module proposition
polio datastore api (end topic?)
polio codehaus -- news (rueben?)
jgarnett Jira
jgarnett Okay that is a lot
cholmes (Yeah, I'll send out my replies to your emails andrea, just read them offline this afternoon.)
jgarnett I am going to get rid of the first two right away.
aaime Nice
jgarnett 1) GT 2.0 - out in a couple of weeks to coincide with GeoServer 1.2.2.
jgarnett 2) GT 2.1.M0 - out this afternoon, coincide with UDIG 0.2
jgarnett Any questions?
cholmes I assume we're not going to try to do any code clean up for 2.0 ?
jgarnett GT 2.1.M0 will be the first release from the 2.1 branch (other than the nightly releases)
jgarnett Well we did do a code cull.
jgarnett What would you like for a code clean up?
cholmes I was thinking PMD, jalopy, checkstyle, ect.
jgarnett I could see running Jalopy again, at least to check headers for recent (c) header.
cholmes But I also don't have any real desires to do it, and don't think anyone else does.
cholmes Clover unit test coverage, ect. Basically the stuff no one likes doing...
jgarnett I hear you.
aaime Well, last time I've triead a maven:site on my PC it bombed out with a OutOfMemoryError with -Xmx512m... not nice...
jgarnett This is where we talk to the module maintainers.
cholmes Yeah, that's probably a good way to go - give people a bit of time to clean up their module if they like, and then just send it out...
jgarnett I can agree with that - do we want to be annoying about it - and turf any module that does not meet the "Standards" - Q does any module meet the standards?
aaime Well, now, whose going to clean up "main" ? ;-)
jmacgill hides
jgarnett Is this an inclusive "you have two weeks", and exclusive "you have two weeks"?
jgarnett That was quick.
aaime Really :-)
jgarnett No flies on James.
jgarnett Well chris let's give two weeks notice - the only module maintainers still on the hook for 2.0 are those that signed up for the ride.
aaime Well, I guess almost everybody would have to contribute... But are you able to perform a maven site on the main module?
jgarnett (If not they would of removed their module by now).
jgarnett I have never tried.
jgarnett I am able to run Jalopy and fix this mistakes.
cholmes I tried last week, but I was offline, so it quickly failed :(
aaime It's the only way I know to get all the reports
cholmes I remember I was able to run them for individual modules, and even individual tests....
cholmes I did a bunch of clean up for our first beta release.
jgarnett Are there instructions on how to run this program?
jgarnett I have been fixing comments on 2.1 (I am afraid I have not back ported all of these though).
aaime I was able me too, before the big main module was created...
aaime Jody, which program?
cholmes Ah, I haven't tried with the big main module.
jgarnett The build site?
cholmes 'maven site' I think
aaime Just type maven site in the module directory. But make sure your maven launch script sets up a big heap
aaime (I'm going to upgrade to 1 gig of RAM anyway, then I will be able to run it I guess...)
jgarnett Maybe I should rephrase these questions - does anyone have time to perform this level of work?
jgarnett (I can donate a day to the cause, but it is off the udig path so I should not spend more)
aaime If there is something glaring, yes, for the details, not, I'm already crucified enough ;-)
cholmes Probably not, and I'm inclined to say that it's not really worth any of our time. I spent more than a week for beta, and didn't feel it really did much good - would have been much better spent doing a week of devel work.
jgarnett I think that is the answer we are looking for - lets give our two weeks notice and release what we have. It will be the best gt 2.0 release ever after all.
cholmes Beta release got it to a good enough point, our code certainly isn't super sloppy, I think we just need to keep up high standards, which I feel we've done a decent job of recently.
jgarnett I will spend my day making sure the headers are correct and doing what I can.
jgarnett Okay - lets move on to that devel work :-)
cholmes The one thing to maybe improve is to make the current reports more prominent, maybe send them every once in awhile to module maintainers, so they can pick up the tasks at their leisure, not all at once, as that was really the problem for me that week.
jgarnett 2) GT 2.1 - I am releasing today
cholmes cool.
jgarnett I can't imagine that is a problem - the nightly builds have been keeping the trouble rate down.
jgarnett Does anyone have any questions or can we go on?
jmacgill v.cool
jgarnett 3) Shapefile DS charset
cholmes This came up on the gt2 users mailing list today.
jgarnett (James I may bug you about including demos in the release process - just not today)
cholmes I just want to make a factory param that lets users specify which char set they want to use, instead of the hard coded ISO-8859-1 that we have now.
jgarnett So we have a Jira issue for this, and chis is going to work on it?
cholmes Just wanted to check with shapefile people if that was ok (and take volunteers if anyone wants to, but I'm more than fine to do it, at least on 2.0.x and rol lforward when I move branches)
jgarnett It sounds like a fine idea.
cholmes Yeah, I'll submit it.
cholmes done
IanS i was searching earlier for how to find the localized (Default) charset, but was interrupted
jmacgill makes sense. (we could do with test shapefiles from people who want this support)
jmacgill esp 2byte char sets
aaime Doh... hello Ian, I did not notice you were with us :-)
cholmes Ah, that would be a good way to go. But even with that it might be nice to let users over ride their local?
IanS the restriction still remains for field names, they are constrained by 1 byte characters
IanS yes, overriding would be good for values, but again, not for fields
cholmes Ok, I think I was only going to change the code for the value.
cholmes That fixed the problem of the user who was having trouble.
jgarnett You may want to cut & paste some of this into the Jira bug description chris.
jgarnett 4) Reprojection and Query
cholmes ok
jgarnett This is a complicated topic - we may want to put it off to the end (to discuss with DataStore / Expr / Query )
aaime Ok
jgarnett 4) later :-)
jgarnett 5) xml/module
polio was thinking we might want to place the xml stuff in a module to avoid having it run in maven all the time
polio i see it getting larger as some of the ows and filter stuff migrates here
jgarnett Are you talking the code or just the tests.
cholmes What's the issue with it?
polio both the code and the test
jgarnett Well the test case takes a long time :-)
aaime Sorry, is the xml stuff in main now?
polio then we can test it independently
polio yes org.geotools.xml.*
cholmes I feel it's pretty 'main' stuff. Perhaps we should improve the testing mechanism to like only test it when needed.
polio I cannot see the difference between module/X and module/main
polio so was thinking or moving it to module/xml
aaime Nah... this would mean that the tests would be not run by most of the people and we would loose the testing over platform/jdk/whatever strangeness...
aaime I'd prefer to see it as a module as well
polio would still be part of a project build, just not when trying out a single module
jgarnett My understanding is that all module/* gets munched into the gt-main.jar at the end of the day?
jgarnett James: is this so?
cholmes Sounds fine to me, I've never quite understood exactly how the new module structure breaks down
aaime (or how the jars build up...)
jgarnett I keep hacking at it but james is the man with the plan.
jmacgill well I was
jmacgill but module has always been a bit of a mystery to me
jmacgill once everything that was an extention moved out of main
jmacgill the only think that should be left is main
jgarnett I think module/* --> James; plugin/x --> x.jar; ext/x --> x.jar and demo/x --> nowhere
cholmes But will parts of main then depend on module/xml - I think that's part of it, as stuff in main, like Filter parsers, ect., would have to depend on it.
jgarnett You may have a point.
jmacgill at the moment the build goes module/main -> main.jar
polio mmm, nope the filter parser would be part of the xml pacakge
polio that was one of the resons to split, all this parsing code could be seperated out
aaime We could set up a module just for the sake of testing like we did with the renderers (by the way, I hate those tests) but it's a bit ugly
cholmes So everything dealing with xml at all would require another jar? I feel like that goes against why we combined everything into main.
cholmes (not that I'm really against it, I never minded the split up jars that much)
polio it's only the code moving ... not another jar
jmacgill I could redo the build script so that every module was combined into a single jar
cholmes I think that's probably the way to go...
jmacgill I think that may have been the origional intention
jmacgill but some plugins/extentions got left behind as no one claimed them
jmacgill humm, looking now the only culprit is svgsupport (which is mine) and should be redone as a demo
jmacgill oh and utils, which should just die
cholmes Cool, let's do it then.
jgarnett Shall we make you Jira tasks James :-)
jmacgill stack em up
polio so, module/xml ok?
jgarnett Just a sec
jgarnett This would require jame to change the build so all module/* goes into main.jar, or plug-ins that use xml depend on module/xml
jgarnett David's original point (that xml is going to grow) is very valid.
jgarnett A lot of that growth can be handled as plugins (like w/ wfs datastore), but a lot needs to live with xml ( like filter).
jmacgill erk... actualy, not happy the more I think about this
cholmes It does sort of beg the question of what we split up though. Like should styling then go in its own module?
cholmes Or at the very least the styling parsing would have to live in xml...
jmacgill and before you know it we are back to where we were a few months back
jmacgill plugins should only have to depend on main
jmacgill so, main would have to be interface complete, with seperate modules providing implementations
jmacgill which adds a layer of abstraction that we probably don't want
aaime And for testing the build would have to depend on implemetations anyway (otherwise, no testing code can be run)
jmacgill whats the main driver for pulling out the xml code? size / time to run tests.. ?
aaime Both?
polio started thinking about it as chris was comenting on wanting filter ... and it's in the wfs code base
polio and noticed a fair number of advantages
polio basically did not think we wanted all the core interfaces clumped right beside the parsers ...
polio atleast I wasn't a fan of the idea
jmacgill I can live with it, but I think it would have to deploy it as a seperate jar
cholmes Yeah, I do like the sentiment, I'm just not sure about the actualy implementation, so we dont end up where we were before.
jmacgill would ext, plugins and demos have to depend on it directly (if at all) or would they still get all they needed from main's api ?
polio they would need to go directly if they need it on their classpath
jgarnett I have the impression that they would have not code dependency, but they would have a runtime dependency (schema implementation for filter needs to be discoverable on their classpath).
jmacgill and as runtime = test time... yeah, they kinda need it.
jgarnett So back to option 0) leave alone 1) module/xml and add dependncy for test 2) module/xml and modify build process
jmacgill I think 1 and 2 add complexity to a build process which we worked hard to simplify
jmacgill I favour 0 - but I'll think about ways to do selective testing
jgarnett Okay, is that fine with you David?
jgarnett Or do we need to do something about selective testing?
polio sure
cholmes I think we should revisit the issue, maybe someone could try splitting it out and see how it ends up, and if it points us down a path towards further messiness or if it can nicely stay by itself.
polio but I really don't like making my machine useless for 6 min to test
jgarnett I like option 4) selective testing the best.
jgarnett How can it be done?
aaime Package selectors? Marker interfaces?
polio and i don't think interfaces should be grouped with parsers ...
jmacgill we used to have an interface only module called core
jgarnett Yeah that seems a bit much.
jmacgill but no one liked that
jmacgill can I think on this for a week
polio sure, lets revisit it
jgarnett Well we are trying to offload our interfaces on to geoapi :-)
polio speak of the devil, he's here just in time
aaime What about keeping them in separate packages? Is it quite likely that we'll have multiple implementations? I have to ask since we have many splits between interface and implementation but some of them are useless...
jgarnett 6) Codehaus links for geotools.codehaus.org
cholmes Yeah, I was thinking of separate packages just now as well.
jgarnett Sorry aaime please continue.
polio I don't see it ... using the default implementations here
aaime Well, just create a "default" package inside the package that contains the interfaces then?
aaime (to hold the default implementation)
polio like org.geotools.filter.default
aaime Hum... I thought you were speaking of parsers...
jgarnett Actually we have a similar Jira task for data and gce right now
jgarnett Move all the data/* classes into sub packages, and leave the interfaces where they are.
polio nope, the parsers are instance of ..xml.schema.Schema and are in ..xml.wfs.WFSSchema ...
jgarnett (So I like the idea and am implementing it).
aaime Yeah, the data package is pretty messy now...
polio so parsers basically already have this, with packages actually spread across main + plugins
aaime I see... in fact having filter interfaces and implementaiton in the same package is not nice... the refactoring should not be that disruptive since the client code should use only interfaces and factories... Anyway, this is one place where I wonder if theinterface/implementa tion split is really useful...
polio the question is how far to go, should it be interfaces/factories/parsers/printers?
polio (all glumped together)
aaime Sorry, I did not really understood your last question...
jgarnett I think when you throw xml into the mix you have more the interface / factory
jgarnett you also have parsing and printing.
jgarnett Does everyone get their own subpackage? filter , filter.parser, filter.printer, filter.default
polio so do we put all four together .. split them out individually .. or some compromise, and if it's a compromise where
jgarnett Hmm this is good marterial for the developers guide.
polio so I was really asking if we should compromise the printing + parsing into the same directory (module/main) or should it be split into another dir (module/xml)
jmacgill filter.parser.default ... ?
aaime Hard question... probably needs to be solved on a case by case basis considering the number of classes/interfaces that would fall in each package...
jgarnett What are you talking about james?
jmacgill blethering
jmacgill ignore me
jgarnett It just is coming to a head for David since he is trying to inflict the same xml parsing on a whole bunch of code.
jgarnett (I kind of like filter|filter.default|filter.xml myself)
polio that would work too , can do .feature.xml for the gml schema too
aaime Sounds reasonable... filter.xml would be the package where filter parser/printers would be located, right?
polio yup
jgarnett Yeah - I like the idea +1 for me :-)
cholmes Sounds good, sld would eventually get the same construct, yes? +1
polio +1 (just so we know, these are the schemas for the framework)
polio yes chris
jmacgill +1
aaime Ok for me too...
jmacgill fraid I have to run
jgarnett Okay ...
IanS i as well, bye all
jgarnett 7) Jira
jgarnett I wanted to run through the open Jira tasks and update them.
aaime Bye
jgarnett Okay before eveyrone goes
jgarnett can we have a breakout IRC session on Expr Query?
jgarnett Please?
jgarnett David and I were going to try and "fix" the situtation this week.
aaime When? Not Wednesday...
jgarnett Thursday morning work?
cholmes I could do tomorrow, and maybe wednesday...
cholmes would be tough for me.
jgarnett Tuesday andrea?
cholmes I have to head back to my internetless island at some point :(
cholmes And we have no phone line yet.
jgarnett We are flexable
jgarnett Chris / Andrea work it out ?
aaime Tomorrow is ok... but can we do it at 19.00 Italian time?
jgarnett Ack need to figure out when that is
aaime (2 hours and a half before today's start)
jgarnett So same as geoapi meeting time?
jgarnett Okay
polio 10 am here, yup can do
cholmes I believe so, that's 14:00 my time I believe, shouldn't be a problem.
jgarnett Okay you guys rock - till tomorrow then.
aaime Ok
jgarnett I will gather up the logs and turn off the lights.
Martin_ Just a quick question Jody please
cholmes Send an email to the list about the expr meeting, ok?
aaime Squeak!! I need that reprojection question!
jgarnett Yep
Martin_ Were you there at the GeoAPI meeting? What was told today?
aaime What I told today ;-)
Martin_ (it is hard for me to be at GeoAPI meeting at this time, since it is now 4:00 AM for me)
cholmes Where are you Martin?
Martin_ New-Caledonia (near Australia)
jgarnett Wow
cholmes Wow. For awhile or just for a bit?
jgarnett We may have to juggle our meeting times around again (we did so to work with Sean last year).
Martin_ For a 2 years contract. After that, I think I will come back to europe
aaime 2 years!!!
jgarnett Martin_ we totally can juggle some Breakout IRC session around to work with you.
cholmes Awesome, that's really cool.
jgarnett Congrats BTW
cholmes Oh yeah, we forgot to talk about committer access for vpf people...
Martin_ It would be hard to find a better time, since it would be yet later for Andrea...
cholmes I think the guy who just signed out showed up for that.
cholmes And making jeff yutzler module maintainer
aaime Ah, great... well, he could say something before leaving ;-)
cholmes true...
jgarnett You had a question Martin?
aaime Anyway, it's ok for me to give jeff the module mantainer status... and then, he does not need our vote to give committer status to just that module to other people (or not?)
cholmes I think he still needs that vote. Actually I can wrap up that vote, we just need three positives...
Martin_ Talking about granting CVS access, maybe we should revisit our rule. It is hard for me to give any opinion on CVS access for many module since I have few knowledge of those module. Maybe we should find some voting process which are more "per module" based rather than a vote from member of all the project.
aaime You're right, but this means we need to have more than one maintainer per module I guess...
Martin_ For example a positive note from the module maintener and 2 contributors of that module.
Martin_ (typo: positive vote)
aaime Well, some modules don't have the luxury of having 1 maintainer + 2 contributors... I'd say, 1 positive from the maintainer and no negative for anybody else...
Martin_ Thats fine for me.
cholmes I think that's more or less how it works out now... Others take a positive from the maintainer to be a recommendation and vote appropriately
aaime Or at least 1 positive from the mantainer and no negative from the PMC members
jgarnett Sigh the PMC better vote on this and we will update the developers guide.
aaime Chris, yes, but the problem is, we still need to go thru the process and sometimes it's difficult to gather up the votes
jgarnett BTW I don't think this has been a issue yet - we have been good about having people attend an IRC meeting, and reviewing their code.
jgarnett So Martin_ did you have your question?
Martin_ All right for me. But maybe we may need to clarify the "per module" CVS right later as Geotools will continue to grown.
jgarnett We can also implement the per module svn right :-)
Martin_ Jody, yes. I just wanted to know what was discussed in the GeoAPI meeting (I think you were there?)
jgarnett Actually andrea was there too (thanks Andrea)
jgarnett Well the bosses were away so we got to talk to developers.
jgarnett Degree once again did not show up :-P
Martin_ :)
polio later gents
jgarnett Jesse & Andrea took turns expalinging the various gt2 renderers to our host.
cholmes Is everyone fine making Jeff module maintainer?
cholmes I'm sending an email right now. I see no downside to this, since that module has no module maintainer...
Martin_ Fine for me (I mean I see no objection)
jgarnett They have started to see the need for something similar to lite-renderer. Apparently that is what their Layer api was all about that appeared in geoapi recently.
aaime Well, basically we spoke about the feature canvas architecture and how it compares agains lite and j2d... lots of description, few comments on the merits
aaime Chris, I'm +1 for Jeff as module mantainer too
jgarnett They had not figured out a few things (like if Graphic is reprojected or not), the important thing for me was that they are working with us and are very interested in making something that doesn't suck.
jgarnett And I was glad Andrea was there to explain things (I never do a good job).
Martin_ Yes, Polexis guy seems pretty cooperative to me.
aaime Yep, the latter in particular is very important
aaime Yes... I was just wondering how making it by voice could made things easier...
jgarnett Actually what was good during the meeting (that never works in email) was the communication despite everyone using their own terms for the various abstractions.
jgarnett (although I know Andrea perfers email)
Martin_ Mail or IRC is a little bit easier for non-English speaker (at least for me)
jgarnett They asked a few questions about reprojection etc... how j2d works.
aaime Well, it wasn't difficult to understand what you said, but it was definitely more difficult to find the words to explain myself
Martin_ It would probably be nice if someday, we could meet in real.
aaime Nice? No. It would be awesome!
jgarnett We asked a few questions (like what a Graphic actually is), there is a large gap between what they think the GO-1 api is capable of and what they have communicated.
jgarnett Agreed it would be fun to meet you guys.
Martin_ Some OGC meeting may be the most natural place.
aaime Pretty much impossible unless someone funds our participation I guess
Martin_ Unless we organize our own meeting...
jgarnett Actually Paul asked if I wanted to go to an OGC meeting one of these days.
jgarnett So I may be up for that idea at somepoint.
aaime Jody, do they have a real implementation? I can't imagine they're only doing paperwork...
Martin_ As far as I know, they have wrapper around ESRI objects.
Martin_ (or something like that)
cholmes I may try to go the ogc meeting in Saudi Arabia in december of next year! :)
jgarnett I have not figured that out, they did imply several meetings ago that they may help geotools make a FeatureCanvas. Although now I think they know we have all the bits they are looking for.
cholmes (as I'll be in Zambia, which is sort of close...)
Martin_ OGC is going to do a meeting there?
cholmes The other ones are october in italy, june of 05 in stockholm, and may of 06 in orlando
aaime Italy? Where?
cholmes Pallanza (Verbania)
cholmes Oh wait, those are ISO, not OGC...
aaime Oh... not far from home then (200 km I guess)
aaime Ah!
cholmes OGC doesn't plan that far in advance...
Martin_ OGC usually plan a meeting in Europe twice a year.
cholmes Yeah, they do every three months, states and then europe, usually...
Martin_ 2 meeting in North America, and 2 meeting in Europe by year
jgarnett It will be fun to hear back from the latest OGC meeting
aaime Well, I'm starting to be really tired... the questions about query and reprojection, I'll made them tomorrow...
jgarnett ID vs Strings etc...
jgarnett Okay.

This page is powered by Blogger. Isn't yours?