[Geotools-devel] Test failure in WorldImageWriterTest
Hey martin, I've got a test failure in WorldImageWriterTest that I think I've isolated. You have a second to hop on irc:#geotools and work through it with me? --saul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] gt2-wms StreamingParser-based wmsv1_1_1 configuration committed to 2.4.x (not yet working on trunk)
Hey all, I've committed a gt2-xml-xsd based wms v1_1_1 configuration/bindings to the 2.4.x geotools branch. It's not actually used by any internal code in geotools right now, but it's an option for anyone who is parsing WMS v1_1_1 capabilities documents and doesn't want to use the gt2-xml (GTXML) parser. I found that I could shrink the jar dependencies of a client app by about 1 megabyte (of a 7-8 total MB download) by dropping the GTXML parser, so I implemented this WMS v1_1_1 configuration so that I could just use one XML parser in my client code, rather than two different ones in different places. I've got an initial port to gt-trunk, but it's not working yet. When I get it working I'll post it. Note: WMS v1_1_1 doesn't actually include any schemas...so I used TRANG to convert the WMS v1_1_1 DTD to a schema, checked the content-model and then generated the bindings from that. If you know how to use the StreamingParser all you need to do is build gt-2.4.x in your eclipse IDE, include the gt2-wms project in that build, then do a subtype-heirarchy view on the org.geotools.xml.Configuration class. You'll catch the WMSV1_1_1Configuration class pretty quickly, and can use it like any other configuration (as long as gt2-wms.jar is on your classpath). If you don't know how to use the streamingparser, then this won't help you much either way! Comments/bug-reports much appreciated. --saul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Test failure in WorldImageWriterTest
The issue (which was fixed with a commit yesterday) was just that the
WorldImageWriter was always using the format "png" to write the image
world file, ignoring its own "extension" parameter in the metadata
writing method.
Patch in revision 28699 was:
---
modules/plugin/image/src/main/java/org/geotools/gce/image/WorldImageWriter.java
(revision 28698)
+++
modules/plugin/image/src/main/java/org/geotools/gce/image/WorldImageWriter.java
(working copy)
@@ -300,8 +300,7 @@
//
final StringBuffer buff = new StringBuffer(baseFile);
// looking for another extension
- final Set ext=WorldImageFormat.getWorldExtension(format
-
.getWriteParameters().parameter("format").stringValue());
+ final Set
ext=WorldImageFormat.getWorldExtension(this.extension);
final Iterator it=ext.iterator();
if(!it.hasNext())
throw new DataSourceException("Unable to parse
extension "+extension);
All tests are passing for me now...and Hudson too, I guess.
--saul
On Fri, 2008-01-11 at 12:32 +0100, Simone Giannecchini wrote:
> CIao guys,
> daniele is working on other things these hence you can send an email
> here so that I will be ble to try and fix the issue.
>
> Simone.
>
> On Jan 11, 2008 12:29 PM, Andrea Aime <[EMAIL PROTECTED]> wrote:
> > Martin Desruisseaux ha scritto:
> > > Hello Saul
> > >
> > > Saul Farber a écrit :
> > >> I've got a test failure in WorldImageWriterTest that I think I've
> > >> isolated. You have a second to hop on irc:#geotools and work through it
> > >> with me?
> > >
> > > I'm not the author of WorlImageReader/Writer... Is the failure related to
> > > metadata, referencing or "core" coverage module? Otherwise, maybe Simone
> > > or
> > > Andrea (I don't remember which one wrote WorlImageWriter) would be more
> > > helpful.
> >
> > According to svn log WorldImageWriter has been modified a few days ago
> > by Daniele Romagnoli, which I'm cc'ing.
> > Yet, at least on trunk, the image module is building for me.
> > Can you provide more information about the test failure?
> >
> > Cheers
> > Andrea
> >
> >
> > -
> > Check out the new SourceForge.net Marketplace.
> > It's the best place to buy or sell services for
> > just about anything Open Source.
> > http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
> > ___
> > Geotools-devel mailing list
> > Geotools-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geotools-devel
> >
>
>
>
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Hudson does not cover gt2 2.4.x and... guess what?
Mea culpa! Sorry to make those commits and then disappear for a week's vacation. I'll double-check all this tomorrow in the morning when I'm in front of my dev environment. --saul On Tue, 2008-01-15 at 12:07 -0800, Justin Deoliveira wrote: > Ha... figures. This time around I decided not to set up geotools 2.4.x > since its supposed to be more or less "stable"... The rationale being > that having a build tool handle one geotools build is strain enough... > having two going might just be what is pushing them over the edge. > However I am quite happy with how hudson is performing so lets give it a > shot. > > > Andrea Aime wrote: > > The build on 2.4.x is broken, allelujah :) > > Here is the test failure I'm seeing (seems to be somewhat > > related to Saul's recent activity on the wms module): > > > > [INFO] > > > > [INFO] Building Web Map Server client > > [INFO]task-segment: [clean, install] > > [INFO] > > > > [INFO] [clean:clean] > > [INFO] Deleting directory > > C:\progetti\geotools\2.4.x\modules\plugin\wms\target > > [INFO] Deleting directory > > C:\progetti\geotools\2.4.x\modules\plugin\wms\target\classes > > [INFO] Deleting directory > > C:\progetti\geotools\2.4.x\modules\plugin\wms\target\test-classes > > [INFO] Deleting directory > > C:\progetti\geotools\2.4.x\modules\plugin\wms\target\site > > [INFO] [resources:resources] > > [INFO] Using default encoding to copy filtered resources. > > [INFO] [compiler:compile] > > [INFO] Compiling 97 source files to > > C:\progetti\geotools\2.4.x\modules\plugin\wms\target\classes > > [INFO] [resources:testResources] > > [INFO] Using default encoding to copy filtered resources. > > [INFO] [compiler:testCompile] > > [INFO] Compiling 15 source files to > > C:\progetti\geotools\2.4.x\modules\plugin\wms\target\test-classes > > [INFO] [surefire:test] > > [INFO] Surefire report directory: > > C:\progetti\geotools\2.4.x\modules\plugin\wms\target\surefire-reports > > --- > > T E S T S > > --- > > Running org.geotools.data.wms.test.ServersTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec > > Running org.geotools.data.wms.test.GetCapabilitiesRequestTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.031 sec > > Running org.geotools.data.wms.test.StreamingParserWMSV1_1_1OnlineTest > > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 21.032 > > sec <<< FAILURE! > > Running org.geotools.data.wms.WMSUtilsTest > > Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.765 sec > > Running org.geotools.data.wms.test.AbstractGetMapRequestTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec > > Running org.geotools.data.ows.test.LayerInheritanceTest > > Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.437 sec > > > > and: > > > > --- > > Test set: org.geotools.data.wms.test.StreamingParserWMSV1_1_1OnlineTest > > --- > > Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 21.032 > > sec <<< FAILURE! > > testStreamingWMSV1_1_1Configuration(org.geotools.data.wms.test.StreamingParserWMSV1_1_1OnlineTest) > > > > Time elapsed: 21.016 sec <<< ERROR! > > java.net.ConnectException: Connection timed out: connect > > at java.net.PlainSocketImpl.socketConnect(Native Method) > > at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:305) > > at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:171) > > at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:158) > > at java.net.Socket.connect(Socket.java:461) > > at java.net.Socket.connect(Socket.java:411) > > at sun.net.NetworkClient.doConnect(NetworkClient.java:139) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:402) > > at sun.net.www.http.HttpClient.openServer(HttpClient.java:618) > > at sun.net.www.http.HttpClient.(HttpClient.java:306) > > at sun.net.www.http.HttpClient.(HttpClient.java:267) > > at sun.net.www.http.HttpClient.New(HttpClient.java:339) > > at sun.net.www.http.HttpClient.New(HttpClient.java:320) > > at sun.net.www.http.HttpClient.New(HttpClient.java:315) > > at > > sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:521) > > at > > sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:498) > > at > > sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:626) > > at java.net.URL.openStream(URL.java:913) > > at > > org.geotools.data.wms.test.StreamingParserWMSV1_1_1OnlineTest.test
Re: [Geotools-devel] Trunk branch or direct modifications
Can you maintain the OWS5-based changes as diffs? Or can you promise to merge in changes from the trunk to your branch every day or something? --saul On Wed, 2008-01-23 at 20:35 +0100, Andrea Aime wrote: > Andrea Aime ha scritto: > > Hi guys, > > I need to make some some SLD experiments for the > > OGC OWS5 branch. Basically I need to add stuff > > to the TextSymbolizer interface (extra attributes) > > so that text symbolizer can better drive KML generation, > > and then modify the SLD parser to parse a slightly > > extended schema. > > > > It should not be such a big modification, but it may > > or may not stay there long term depending on how > > OWS5 work goes, as I said, it's a set of experiments. > > > > So what do you think, should I open a branch for this > > kind of work (and branch gs as a consequence) or > > can I stay on trunk? > > As an alternative, I can try to make a full fledged > proposal with a general idea of what extra stuff > I'm going to add to TextSymbolizer. > > Cheers > Andrea > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] RasterSymbolizer support, and extension of SLDs RasterSymbolizer definitions...
Hey all, I couldn't let Andrea get away with poking at standard SLD support in geotools all by himself! I'd also like to support a slight extension to the SLD spec, too. Specifically, the SLD spec only supports two "contrast enhancement" techniques for rasters. I'd like to also support some variants of the normalization technique, as well as the "standard" (or min-max) normalization technique. Specifically, I'd like to support SLD XML like this: Basically, I'd like to add support for the optional "standardDeviations=float" attribute on the Normalize tag. If anyone's interested in the details, I can fill you in on IRC about what exactly the difference between a "regular" normalization and a "standard-deviation" normalization is, but here's a visual example: http://maps.massgis.state.ma.us/~sfarber/contrast_stretching/ Any thoughts/concerns/comments/encouragement about the SLD extension part of this plan? Separately, I'm hoping to get the RasterSymbolizer support committed to 2.4.x and trunk right after 2.4.0 goes out the door. But the merge from the 2.4.x_rs branch is proving to be more of a pain than previously hoped! --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Trunk branch or direct modifications
Well, I usually do this for medium-length "deviations from trunk". "patch -p0 < patch" and "patch -p0 -R < patch" do a good job of merging and un-merging my changes. I tend to unmerge my changes, svn update and then re-merge my changes each morning. Any failed patch hunks are places that would have been conflicts in an SVN merge (generally) so I just resolve them manually and then re-create my patch. I suppose this becomes really hard if you're tracking more than one set of changes (particularly if they interfere with each other, like the UpdateGSAction.java changes I was tracking the other week). Anyway, that's what I do when my changes are all part of a "unified whole" and they fit nicely inside a patch. In any case, I'd support your staying on trunk if there's any option of doing so. Merging and branching are a pain, and it's easy to have stuff get left "out there" or get stressful at times when it's most needed. --saul On Thu, 2008-01-24 at 08:29 +0100, Andrea Aime wrote: > Saul Farber ha scritto: > > Can you maintain the OWS5-based changes as diffs? > > Hum... no, I don't think so. That may make development > even messier than having multiple branches. Are you used > to work this way? How do you approach the problem of > keeping diffs around, removing them, readding them, > sharing with other developers? > > > Or can you promise to > > merge in changes from the trunk to your branch every day or something? > > Neither, I would have to branch geoserver as well to follow > the gt2 branch. Wheter I'll be able to keep both in synch > with the rest of developers remains to be seen. > > Cheers > Andrea > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Test failures on 2.4.x
Hey all, I'm getting test failures in the org.geotools.referencing.operation.transform.WarpTransformTest class Any ideas? I thought it might be my local mods, but I've just checked out a clean copy of 2.4.x from svn, and the failures are there too. --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Test failures on 2.4.x
Hey, that completely fixed it! So, err, should I commit this fix to 2.4.x? This would force everyone to upgrade to a recent JAI snapshot...is that a bad thing (there have probably been big improvements!) thoughts? Martin? --saul On Thu, 2008-01-24 at 18:18 +0100, Daniele Romagnoli wrote: > Hi Saul, > I have encountered a similar problem in the past but I have easy > solved it, thanks to Martin. > I post here the useful Martin's reply on such a topic: > > > > GeoTools WarpTransform2D has a workaround for a JAI bug. Maybe the JAI > bug has > been fixed now, in which case the workaround need to be removed? If > you want, > could you try the following please? > > * In org.geotools.referencing > .operation.transform.WarpTransform2D, > delete or comment-out all the lines 214 to 235 (on trunk - not > sure about the line numbers on 2.4.x branch. The code should be > flagged by comments). > > * Tests again with th build snapshot. > > > > Let me know if it was helpful. > > Best regards, > Daniele > > > On Jan 24, 2008 5:59 PM, Saul Farber <[EMAIL PROTECTED]> wrote: > Hey all, > > I'm getting test failures in the > org.geotools.referencing.operation.transform.WarpTransformTest > class > > Any ideas? I thought it might be my local mods, but I've just > checked > out a clean copy of 2.4.x from svn, and the failures are there > too. > > --saul > > > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > -- > --- > Eng. Daniele Romagnoli > Software Engineer > > GeoSolutions S.A.S. > Via Carignoni 51 > 55041 Camaiore (LU) > Italy > > phone: +39 0584983027 > fax: +39 0584983027 > mob: +39 328 0559267 > > > http://www.geo-solutions.it > > --- > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] RasterSymbolizer support on 2.4.x and trunk
Hey all, I've opened http://jira.codehaus.org/browse/GEOT-1691 Attached to the JIRA are a tarball (to be unrolled from the root of your 2.4.x checkout directory) and a patchfile. Both are required parts of the changes. Anyone who has a chance to try out the patch and/or review the code would be much appreciated. Geoserver doesn't need to be modified...just use some of the awesomeness of RasterSymbolizer and you'll get the results for free. I'd like to get this work applied to 2.4.x right after 2.4.0 goes out the door, and I can commit my time to doing that (heck, it's all there and passing tests.) I'd also like to get this applied to trunk as soon as possible, but I can't commit my time to that just yet (although I *may* be able to get to it eventually). Is there anyone else out there who'd like to bring this stuff to trunk? It's good stuff...allows for awesome raster processing and the code is all there and done and everything. In fact, I haven't even tried just doing a big-ol "patch -p0 < patchfile" and seeing if it works (I was too afraid), so it may be easy to apply! If there is enough concern about this, I'm willing to help the GeoSolutions crowd put together a proposal page, but there is zero api breakage, and only a slight amount of api additions (all within standards) so I don't think there should be any reason for a more heavyweight process. Comments and suggestions welcome. In the absence of any concerns, I'll plan to apply to 2.4.x as soon as 2.4.0 goes out the door. thanks all, --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] RasterSymbolizer support on 2.4.x and trunk
Simone, Cool, all your comments make much sense! Shall we hop on IRC and do a little planning breakout? I'm curious to know how I can be of the most help while getting the way the least amount! I'll hop on IRC real quick and post back whatever we work out. --saul On Fri, 2008-01-25 at 20:58 +0100, Simone Giannecchini wrote: > Ciao Saul, > sorry to have been silent on this so far... > > I am inline below some comments. > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Test failure on gt-trunk?
I'm getting a test failure in org.geotools.xs.bindings.XSQNameBindingTest.java as of today (didn't happen yesterday) Anyone else seeing it? I poked around in the test a bit, but didn't see anything obvious. --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Still getting consistent test failure in org.geotools.xs.bindings.XSQNameBindingTest
mvn -U clean install gives me a failure in that method. I cleared out every maven dependency of that module (xsd/core) and ran it again...same effect. anyone else seen this test failure? --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] online tests being run these days?
Hey all, Are online tests being run these days? I assume that the hudson build server isn't running them as they're probably really extensive. I'd love to integrate the ArcSDE test suite into running online tests so we can get that feedback to the public list. If someone can let me know the setup then I can start to try and get that stuff off the ground. --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] missing .wkt files for ArcSDE tests?
Hey gabriel, Any chance you've forgotten to commit the .wkt files referenced in GeometryBuilderTest.java? I'm trying to track them down, but can't seem to find them in geotools anywhere. Am I looking in the wrong spot? thanks much! --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] WMS Binding question
Good morning Jody, It took me about 3 days to get up to speed on the xml-xsd parser, and to implement bindings that read an xml document and generated the appropriate domain objects. I'll share my EXTREMELY LIMITED AND DEFINITELY INCOMPLETE/POSSIBLY INACCURATE analysis of what I've figured out from using the various xmlschema binding frameworks I've used in my career. First, note that there are two parts to java-ifying an XML-schema based model: generating java domain objects--the actual objects that you're trying to parse the XML "into"--and generating some classes/code which does said parsing (often called "marshalling" or "unmarshalling"). The different technologies you list below do different parts of this, some making one or the other part optional. JAXB: generates domain objects from schema, and provides a "smart" parser/marshaller that reads XML documents and turns them into the generated domain objects. Often the domain objects "feel" like the XML they were generated from. As will all big technologies, you can get JAXB to do anything (*just* the marshalling, *just* the domain object generation, cut your hair, wash your car), so your mileage/abilities with JAXB will vary depending on the amount of time you put into it. XDO and XML-XSD: these are purely "marshalling" technologies. XML-XSD has some cool extensions allowing you to auto-marshall to a generated EMF model of domain objects. One criticism of the EMF domain objects is that they definitely "feel" very EMFy. XStream: I have zero hands-on experience with this one. I think Justin played extensively with this technology a while ago, so he might have more advice. There's also XMLBeans, which is fairly similar to JAXB, but might be so old that it's fallen out of favor with anyone sane. Good luck jody! --saul On Mon, 2008-03-03 at 17:19 -0800, Jody Garnett wrote: > Morning Saul; > > I am looking at the WPS specification (a lot to like actually) and > considering the various options for handling the XML side of things. A > lot of technologies are around these days: > - Martin is using JAXB for metadata > - We use the "XDO" parser for GML2 > - Gabriel is working on the binding side of things for WFS 1.1 / GML3 > - XStream gets a lot of good press > - and so on ... > > How long did it take you to do up bindings for WMS (and are we ever > going to ditch the "XDO" bindings?). > It feels like doing bindings for WPS is overkill; but their is GML in > the mix so ... > Jody > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] WMS Binding question
Quote away! And feel free to refactor/copy into a post on your blog. I'd keep a blog, but it's hard enough to remember to eat during the day...let alone get content up into a blog! --saul On Tue, 2008-03-04 at 09:25 -0800, Jody Garnett wrote: > Thanks Saul; now if only you had a blog to post that on - it is > certainly the kind of background information a lot of us would find > useful. Can I quote some of this for the user guide? > > Jody > > Good morning Jody, > > > > It took me about 3 days to get up to speed on the xml-xsd parser, and to > > implement bindings that read an xml document and generated the > > appropriate domain objects. > > > > I'll share my EXTREMELY LIMITED AND DEFINITELY INCOMPLETE/POSSIBLY > > INACCURATE analysis of what I've figured out from using the various > > xmlschema binding frameworks I've used in my career. > > > > First, note that there are two parts to java-ifying an XML-schema based > > model: generating java domain objects--the actual objects that you're > > trying to parse the XML "into"--and generating some classes/code which > > does said parsing (often called "marshalling" or "unmarshalling"). > > The different technologies you list below do different parts of this, > > some making one or the other part optional. > > > > JAXB: generates domain objects from schema, and provides a "smart" > > parser/marshaller that reads XML documents and turns them into the > > generated domain objects. Often the domain objects "feel" like the XML > > they were generated from. As will all big technologies, you can get > > JAXB to do anything (*just* the marshalling, *just* the domain object > > generation, cut your hair, wash your car), so your mileage/abilities > > with JAXB will vary depending on the amount of time you put into it. > > > > XDO and XML-XSD: these are purely "marshalling" technologies. XML-XSD > > has some cool extensions allowing you to auto-marshall to a generated > > EMF model of domain objects. One criticism of the EMF domain objects is > > that they definitely "feel" very EMFy. > > > > XStream: I have zero hands-on experience with this one. I think Justin > > played extensively with this technology a while ago, so he might have > > more advice. > > > > There's also XMLBeans, which is fairly similar to JAXB, but might be so > > old that it's fallen out of favor with anyone sane. > > > > > > Good luck jody! > > --saul > > > > > > > > > > > > > > > > On Mon, 2008-03-03 at 17:19 -0800, Jody Garnett wrote: > > > >> Morning Saul; > >> > >> I am looking at the WPS specification (a lot to like actually) and > >> considering the various options for handling the XML side of things. A > >> lot of technologies are around these days: > >> - Martin is using JAXB for metadata > >> - We use the "XDO" parser for GML2 > >> - Gabriel is working on the binding side of things for WFS 1.1 / GML3 > >> - XStream gets a lot of good press > >> - and so on ... > >> > >> How long did it take you to do up bindings for WMS (and are we ever > >> going to ditch the "XDO" bindings?). > >> It feels like doing bindings for WPS is overkill; but their is GML in > >> the mix so ... > >> Jody > >> > >> - > >> This SF.net email is sponsored by: Microsoft > >> Defy all challenges. Microsoft(R) Visual Studio 2008. > >> http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > >> ___ > >> Geotools-devel mailing list > >> Geotools-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > >> > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Maven group for dummy modules?
Hey all, I'm a little hesitant to move the sde-dummy code away from the sde module. It is true that it's only used (currently) for building, but why does that mean that we should move it away from its current home? I guess I just think that the sde-dummy module isn't really of any general use, except to the arcsde-datastore module. the jaxb-dummy module, however, *may* be of use to many plugins, so perhaps it could have a more general location? Is there a more convincing argument for "move the sde-dummy module" than, "there are other dummy modules that are more broadly useful, and we should put them all together"? --saul On Thu, 2008-03-13 at 18:16 +0100, Martin Desruisseaux wrote: > Jody Garnett a écrit : > > Go for it martin; although you may find that moving the sde dummy code > > is a bit of fun; I seem to recall some profile madness being used to > > determine if dummy jars were used or not? > > I would do this part only after the "gt2-prefix removal" work then... > > Martin > > - > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDE versioned tables
Gabriel, Jody, Yes, I'm working with ArcSDE on trunk so I'll be sure to run the test suite. Also, gabriel: Justin was able to connect to SDE from geo without problem. Could it have been a general test failure (something leaving connections open and the pool running out) rather than a failure to connect to sde? If so, you should be able to test against arcsde at massgis with no problem. --saul On Thu, 2008-03-13 at 12:45 -0700, Jody Garnett wrote: > I am also working on ArcSDE; going to experiment with a "one connection" > policy and see what I can manage. > Jody > > Hi Saul, > > > > I've been hacking hard at the arcsde datastore (trunk) to make it able to > > edit > > the default version when a table is versioned. > > > > I'd be cool if you, or any other one working on trunk with sde access, > > could > > do some testing like through geoserver or udig trunks, in order to catch up > > early on any error I may have introduced > > > > Btw, now I'm working in backporting the arcsde plugin from trunk to 2.4.x. > > That's meant to provide the huge amount of improvements in trunk for > > geoserver 1.6. Though it's being a painfull process due to the differencies > > in the feature model between trunk and 2.4.x... :( > > > > Best regards, > > > > Gabriel > > > > - > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2008. > > http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ > > ___ > > Geotools-devel mailing list > > Geotools-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Maven group for dummy modules?
Hmm, ok. I'll buy it. That makes sense to me.
Can we (as you suggested, martin) roll this move into the whole "remove
the gt2- prefix" change that we're doing later?
--saul
On Thu, 2008-03-13 at 20:44 +0100, Martin Desruisseaux wrote:
> Saul Farber a écrit :
> > I'm a little hesitant to move the sde-dummy code away from the sde
> > module. It is true that it's only used (currently) for building, but
> > why does that mean that we should move it away from its current home?
> >
> > I guess I just think that the sde-dummy module isn't really of any
> > general use, except to the arcsde-datastore module. the jaxb-dummy
> > module, however, *may* be of use to many plugins, so perhaps it could
> > have a more general location?
>
> Actually the rational is not general use. The way I saw the directory
> structure is:
>
>- build: Everything needed for building, no matter if of general use of
> not.
>- modules: All GeoTools code to be included in releases (minus
> unsupported).
>
> The "build" directory already contains other stuff that are very specific to
> a
> particular module, for example "modules/extension/openoffice".
>
> By putting "arcsde-dummy" in "modules", you inherit the Maven definitions
> from
> the parent pom.xml (assuming we don't trink Maven config, which is possible).
> Inherited definition includes javadoc settings, assembly and the like, which
> may
> not be what we intented (we don't want arcsde-dummy to appears in javadoc or
> to
> be included in assemblies).
>
> The Maven directory layout is not to be understood in the sense of
> "package-privated" like Java, but rather in the sense of class hierarchy
> (subdirectories inherits the behavior from their parent directory).
>
> If "arcsde-dummy" was defined in "build" instead, it would inherit from a
> parent
> pom.xml better suited for dummy modules, without javadoc or assembly
> instructions. It would clearly appears in a "dummy" directory in the Maven
> repository, instead of looking like a real GeoTools module as it currently is
> ("gt2-sde-dummy" in http://maven.geotools.fr/repository/org/geotools/).
>
>
> Martin
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] building with jdk1.6.0_04 on linux-x86 fails in xsd-core module
I think it's due to a conflict or bug in the included jaxb jars (in the 1.6.0 jdk distribution). Failure is in the XSQNameBindingTest test. Building with jdk 1.5.0_14 works like a charm. Anyone else have this problem? --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Asking for feedback on SLD RasterSymbolizer support
Simone, Martin, I'm actually butting up against this very issue right now. I've got a float-denominated elevation-model raster with values that are "geophysics" values, not image values. From what I can tell, in order to handle float-backed rasters, java wants the floats to be normalized (mapped into the interval [0.0,1.0]) in some manner. So I've got raw data with no colormodel. I can jam all the float samples into a DataBufferFloat, but the resulting BufferedImage is basically un-drawable in an ARGB way in its raw form. I'd LOVE to hear what you guys come up with. If I can punt this "unrenderable" float-backed coverage over to RasterSymbolizerSupport and have it "normalize" (what I think you called option 2, simone) and then map to AGray and paint the coverage, I'd be really happy. --saul > I am not talking about raster with IndexColorModel, I should have > probably pointed that out. > Typical exmple would be elevation data, which is most part of the time > store in rasters with single band of type short which cannot be > visualized direclty. > > - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] ArcSde class name standardization
Hey gabriel (and anyone else interested),
Do you think we should go with "ArcSdeXXX" or "ArcSDEXXX" for class
names? Also, when should that prefix be applied, and when shouldn't it?
For example, we've got the following classes:
FidReader.java
SdeRow.java
Should these be "ArcS{de,DE}FidReader" and "ArcS{de,DE}Row"?
My preference:
* I don't care one way or the other on the "ArcSDE" vs "ArcSde" thing,
just that we do it consistently (hrm, why do I feel so anal about that?
I'm not sure, perhaps I need therapy...).
* I feel like "utility" or "helper" classes that are internal to the
API could live without the prefix, but that all outward-facing classes
should have the prefix.
Your thoughts?
--saul
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Fun with arcsde session
Jody, Sorry to be so silent as you and Gabriel work through the arcsde issues. I'm not sure what to make of these errors. It could be that someone has arcmap open and has that layer locked that way. However, when the arcsde plugin dies in the middle of a test (say with one of those SeExceptions below) there's often buggy code in the test suite that doesn't return the connection to the (global) pool before the test dies. In this case you'll have one prior test fail, tie up the connections, and then you'll get a ton of "timeout waiting for idle connection" errors. These latter errors are spurious. Also, my general hint on ArcSDE debugging/coding is that ArcSDE is actually fairly well coded and seems to work fairly consistently. The java api does most of what it needs to do, and is used internally by several production ESRI products. So your comment about "my test suite is faster than my connection" isn't impossible, but in my view it's unlikely (although you're much closer to the real info than I am!) Threading issues (which you are exploring explicitly!) does seem to be well worked out, as long as you use the API the 'right' way. Where 'right' means follow documentation that is possibly nonexistent, and likely old or written using the C version of the API. All of this said, the documentation and "design" of the jsde API range from planetarily catastrophic to galactically FUBAR. It's clearly a c api that's been ported in fits and starts, and by different people, with different pay grades and education levels. I'm very happy about the following things that you and Gabriel have worked out, by the way: * "Command Queue-ing" a la HibernateTemplate * An "sde session" ide (a la hibernate) I'm a little nervous, but holding my tongue about the following things that you've worked out: * re-writing the entire sde-connection-facing portion of the API (which will touch almost all classes) * any mention of 'abstracting' the jsde api away from the plugin. This one in particular makes me really scratch my head...but since it looks like no-ones trying to take this on, I don't need to warn anyone against it! Good luck jody. Get some caffeine and a big whiteboard and a punching bag or something. later on, --saul On Tue, 2008-04-15 at 15:53 -0700, Jody Garnett wrote: > Here are the kinds of errors reported > > > > ArcSDE Error Number: -21 > > Error Description : SPECIFIED LAYER IS USE BY ANOTHER USER. > > > > ArcSDE Error Number: -19 > > Error Description : SPECIFIED LAYER ALREADY EXISTS. > > Extended Error Description : Error executing stored procedure > > sde.layers_util.insert_layer > > Extended Error Description : ORA-20019: Layer 829 already exists. > > > > WARNING: Out of connections: Timeout waiting for idle object > > java.util.NoSuchElementException: Timeout waiting for idle object > > > My reading of this is that maven testing is much faster than my arcsde > instance. > Jody > > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Project name template for eclipse:eclipse... does it work for you?
andrea, this command worked for me on trunk in the last few days: mvn -Dmaven.test.skip -Declipse.projectNameTemplate="1.6.x-[artifactId]" eclipse:clean eclipse:eclipse could it be the 'eclipse.' in front of the projectNameTemplate? --saul On Wed, 2008-04-16 at 15:08 +0200, Andrea Aime wrote: > Hi, > I'm trying to recreated the geotools projects as suggested > by the wiki at: > > http://docs.codehaus.org/display/GEOT/2.5.8+Maven+Eclipse+Plugin+Goals > > But the names generated are still plain, prefix-less. > To make extra sure I run the following: > mvn eclipse:clean > mvn eclipse:eclipse -DprojectNameTemplate=[groupId].[artifactId] > > I also tried to upgrade the eclipse plugin dependency to 2.5.1, no > luck either... projects keep on being generated without following > the name template. (I checked the .project file contents, there > is no prefix). > > Did anyone have better luck than me? I'm stuck, I cannot reload > anymore geotools in the same eclipse workspace where I have > my geoserver sources... > > Cheers > Andrea > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] FID into TXT Language (CQL Extension)
Indeed. '#' can be troublesome in web requests (if not escaped
properly).
Also, it shouldn't matter what the "ID" character is in CQL ('@','#',
etc.) as long as there is a way to 'escape' that character when it
appears as a part of the query. I.e., if there's a '\#' character pair,
then that's treated as a literal #, not as an ID specifier, no?
--saul
On Wed, 2008-04-16 at 16:43 -0700, Jody Garnett wrote:
> Andrea and Chris we were talking about this a bit yesterday on email
>
> As CQL is used often in GeoServer I would like to check if "#road.1"
> syntax be okay encoded in a GET URL? Or should we ask Mauricio to use a
> different symbol - "@road.1,@road.2" etc...
>
> Jody
> > Hi, we was preparing the land to extend CQL. You could see the scope in the
> > following link:
> >
> > http://docs.codehaus.org/display/GEOTOOLS/TXT+Language+Analysis
> >
> > Now I have some doubt about the ID Predicate, that is:
> >
> > #road.1, #road.2, #road.47
> >
> > As you can see it is a sequence of "fids" preceded by "#" and separated by
> >
> > comma (","). Then the fid can not contain "#" or ",". Is this a valid
> > hypothesis for all DBMS?
> >
> > Some samples are:
> >
> > sample 1: #15521.3566
> > sample 2: #fid-_df58120_11814e5d8b3__7ffb
> >
> > More details in the following junit
> >
> > http://svn.geotools.org/geotools/trunk/gt/modules/library/cql/src/test/java/org/geotools/filter/text/txt/TXTTest.java
> >
> > well, we need more samples to assure that the language could parse all fids.
> >
> > comments?
> >
> >
>
>
> -
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
> ___
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] RasterSymbolizer proposal (again :-) )
I've read the proposal, and it looks really good to me. I'm trying to get rastersymbolizer-required raster types built into ArcSDE on trunk, so I'm really hoping that this proposal passes and I can get those working soon. All you PMC folks...vote! Let's get this one rolling. --saul On Thu, 2008-04-17 at 01:04 +0200, Simone Giannecchini wrote: > Hi guys, > I have finally finished with the refactor of the RasterSymbolizer > support classes. More details here > http://docs.codehaus.org/display/GEOTOOLS/Raster+Symbolizer+support, > code in inside the 2.4.x-rs branch. > > I have splitted the work in two parts, one implements a new piecewise > operation for JAI, the other part apply a ColorMap to a generic > raster. > > I am ready to start porting to trunk hence I would like to ask PMC > votes on this. > > > Simone. > - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] hudson is freaking cool
Just a heads up to anyone who doesn't know: hudson is freaking cool. And it's great that TOPP hosts the public hudson build server for geotools. Thanks everyone at TOPP. I broke the build, and as I try to fix it, it's really valuable to be able to look at the remote maven output so easily. --saul - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Dancing with pom.xml: next step
Martin, Can you try it on your local copy and see if it works? Then if it all works with maven 2.0.9 and no pluginRepository sections, we can consider the question more fully...as there will be concrete benefits and costs. --saul On Sun, 2008-04-20 at 23:40 +0200, Martin Desruisseaux wrote: > Andrea Aime a écrit : > > I don't have any specific issue with upgrading to 2.0.9 provided it > > works ;) (past history shows that maven is full of surprises... as Jody > > wisely said some days ago "when it works... it's magic... and when it > > does not... it's magic too! :) "). > > Yes, sometime I wonder if Maven is black or white magic... My hope is > precisely > that relying on the plugin versions selected by Maven developpers for 2.0.9 > would solve magically some issues like aggregated javadoc (I may be > dreaming... > but in the past changing pluging versions worked sometime). > > Martin > > - > This SF.net email is sponsored by the 2008 JavaOne(SM) Conference > Don't miss this year's exciting event. There's still time to save $100. > Use priority code J8TL2D2. > http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDE state of play
Cool. Glad you were able to get things testing jody.
Re: arcsdepyramidtest -- yes, that's a problem. I'll get that fixed as
soon as I'm back in front of my dev station (thursday).
Re: the filter tests failing and the use of calendar...I'll reply to
that email seperately.
--saul
On Fri, 2008-04-25 at 14:36 -0700, Jody Garnett wrote:
> I finally have an ArcSDE of my own to run the tests against ... and a
> list of 19 failures.
>
> ArcSDEPyramidTest (2 failures)
> - testArcSDEPyramidFourBand() - can you supply a better example for the
> connection settings? The test cases asks for a "fourbandtable" property
> which is not supplied.
>
> Many tests seem to fail based on differences in test environment;
> refering to layers that don't exist (like SDE.SDE.JAKARTA for example),
> or entries in the property file that don't exist in the committed
> samples ("fourbandtable" etc..).
>
> How should we handle this?
> Jody
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDE state of play, some mistakes due to new feature model handling of Date converations
> About date.. Saul, is calendar really needed? I understand the binding should > be either Date or javax.sql.TimeStamp and Calendar provides just a proper way > to deal with dates, but its not a data object itself? > Two things: 1) calendar (confusingly) *is* a data object itself. It's a data object with a current date, time *and* calendar rules representation. 2) do we need to use calendar? I guess I'm less sure about that one. I think calendar is used because that's what SDE requires internally: http://edndoc.esri.com/arcsde/9.2/api/japi/docs/com/esri/sde/sdk/client/SeDate.html And also what SDE returns from a Date column in the db: http://edndoc.esri.com/arcsde/9.2/api/japi/docs/com/esri/sde/sdk/client/SeRow.html#getTime(int) My preference would be to continue to use Calendar, unless there's a compelling reason not to do so. Let me know what you guys find out. --saul - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] maven 2.0.9 and 'cascaded' pom.xml profile version expansion
Whew, that's a mouthful.
So I found a bug/issue with maven 2.0.9 today.
I have the following pom structure:
geoserver/web/pom.xml -> triggers profile to include
gt-arcsde/datastore/pom.xml
in gt-arcsde/datastore/pom.xml a profile is activated to include an
extra jar
in the 'include that extra jar' the version string uses a property (
${sde.version} ) that was used to activate the profile, this property is
NOT properly expanded (and is actually ignored, reverting to the
default) in maven 2.0.9, but this structure works just fine in 2.0.8 or
lower.
Just a heads up that there are some weirdnesses in maven 2.0.9 in the
border cases. For now I've hard-coded the version of the pulled-in jar
in the profile (which makes sense anyway) but otherwise I'd have to
build with 2.0.8 or lower.
--saul
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] ArcSDE sde-managed rowid columns, NSTRING column types and connection pools
Hey gabriel, jody (and others interested in the arcsde datastore!) I've been working through a local fire here on my end with a partially successful upgrade from sde 9.1 to sde 9.2, and I've run into a few weirdnesses with the latest geoserver 1.6.x (geotools 2.4.x) releases. 1) It seems that SDE-managed rowid column support is missing on the insert code-path again. In 'getInsertableColumnNames()' there's no skipping of the SeRegistration().getRowIdColumnName() so the code happily tries to insert into OBJECTID type columns. This is bad, as it means that anyone using geoserver to edit live ArcSDE instances to which they connect with ArcMAP (most everyone, really) won't be able to do any WFS-T insert-ing on those tables. I put together a quickie patch, but I haven't committed yet as jgarnett advised me that you were doing a back-port of the trunk SDE work to 1.6.x gabriel...is that right? If so, I'd love to help knock it around a bit when you're done. 2) I ran into the connection pool issue that we chatted about today gabriel (see http://jira.codehaus.org/browse/GEOS-1963). I also patched around this by simply commenting out the 'connectionPool.close()' call in ArcSDEDataStore.dispose() Not so much a fix as a hack, but again, I didn't commit...it just gets me up and running locally (sort-of). 3) It seems that ArcSDE 9.2 is very aggressive about using NSTRING where it used to use STRING. I've never seen NSTRING working before, and it appears that you can't 'row.setString()' on a STRING, but instead you have to 'row.setNString()' on an NSTRING. I haven't fixed it yet, but I'll try to look at it later this week. If anyone else has the time to go and do the 3-line fix for that (split the if statement at ArcSDEFeatureWriter.java 642 and call setNString in the right cases) that would be awesome. Otherwise I'll get to it on Friday when I'm back in the office. I'm also going to get a chance to see the new SDE command-queueing stuff in action when I port the GCE stuff to use it on trunk starting on Friday (hopefully). You'll hear more from me on that front soon. thanks all, --saul - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDE command queue backport and switch on trunk
Gabriel, I totally understand that the command-queue stuff needs to move forward. I'm willing to put some time into the gce stuff, but it would be great if the gce tests were doing everything the are supposed to be doing (namely, telling us whether or not the build is working!) Then we could all have a sense of exactly what needs to get done, and when we actually *are* done. The GCE tests do currently load their own data, so maybe I just need to play with them and document exactly how to run them to see if everyone can get the same set of output. In any case, I think it would be great to move gce to the new command queue work...can you do the deprecation cycle instead of the full 'hiding' move for now? Then I'll go through and give it a shot next week, hopefully? thanks much gabriel, --saul - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDEPyramid
Gabriel,
I think level zero (the "base" level of a raster) is i ==0
Level one (the "next up" level of a raster) is sometimes skipped because
it's only 1/4 the size, and on-the-fly interpolation of the interesting
area can be faster than the space saved by the level-one pyramid area.
I could be wrong though!
--saul
Gabriel Roldan wrote:
> Hey Saul,
>
> I'm having a bit of trouble understanding the usage of ArcSDEPyramid, may be
> you can bring some light :)
>
> I'm pretty sure I've come to an exception in ArcSDEPyramid constructor last
> week with a raster dataset for which skipLevelOne was set to false.
>
> My question is regarding the following snippet in the constructor:
>
> for (int i = 0; i < numLevels; i++) {
> if (i == 1 && rasterAttributes.skipLevelOne()) {
> continue;
> }
> ..
>
> shouldn't it be like this:
> if (i == 0 && rasterAttributes.skipLevelOne())
>
> Cheers
>
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDEPyramid
Gabriel,
That sounds 100% fine to me.
--saul
Gabriel Roldan wrote:
btw, I'm moving the ArcSDEPyramid and ArcSDEPyramidLevel classes from the
org.geotools.arcsde.gce package to the org.geotools.arcsde.gce.imageio package
as I think they better fit there. Otherwise we end up with cyclic dependencies
on those packages and the org.geotools.arcsde.gce package interface seems
overloaded with unneeded clutter to me, where it should only contain the
Format and Coverage2DReader implementations, and the last one being package
visible, so the org.geotools.arcsde.gce package interface is just the Format
class. Does it seem good?
Cheers,
gabriel
On Friday 23 January 2009 15:55:46 Gabriel Roldan wrote:
Hey Saul,
I'm having a bit of trouble understanding the usage of ArcSDEPyramid, may
be you can bring some light :)
I'm pretty sure I've come to an exception in ArcSDEPyramid constructor last
week with a raster dataset for which skipLevelOne was set to false.
My question is regarding the following snippet in the constructor:
for (int i = 0; i < numLevels; i++) {
if (i == 1 && rasterAttributes.skipLevelOne()) {
continue;
}
..
shouldn't it be like this:
if (i == 0 && rasterAttributes.skipLevelOne())
Cheers
--
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDE GCE may go JAI
> I understand. My approach is as follows > > - we pick up the correct pyramid level before issueing the request > just as its being done now, then instruct JAI to request always the > image at index 0. this allows a single query to carry over all the > tiles for the chosen level, and jai sees it as a single raw image. > > Then our custom ImageInputStream, wrapped by a RawImageInputStream > > with the appropriate image layout should do the trick. > > So far I've been able to read any combination of pixel format and > number of bands. Writing the result to a tiff image gdalinfo reports > all the bands. Testing up to seven bands. > > The problem is with the image layout, cause with more than one band > the image produced is a mix up of tiles from the different bands, > quite psycodelic. I'm under the impression that the correct > combination of interleave type for the SeQuery and jai's image layout > should do the trick though. > > Does that make any sense? > Makes sense to me. That was the part that I had trouble with, so if you've got it working with a single SeQuery, that should solve the performance problems I was seeing. > > > > > That said, I think all the problems that I ran into could definitely be > > > worked around by someone smarter/more JAI knowledgeable than I, and > I think > > > that JAI has the potential to provide lots of good > support-infrastructure > > > that we've needed to write ourselves in the ArcSDE module. If your > spike > > > is going well and you're getting good performance out of it, I think > it's > > > probably a good idea to go the JAI route. > > > > > > I'll defer to the other JAI experts on the list for better technical > > > opinions on JAI, but I'm interested to hear/see more about the > JAI+ArcSDE > > > spike's progress. > > > > > I of course didn't run any perf comparison yet. I'm more interested in > being able to support any combination of pixel type and number of > bands in a straightforward way by now. Yet, I don't foresee any > considerable perf regression, since the way the ImageInputStream works > is by calling SeRasterTile.getTileData() which returns the raw byte[] > containing both the data packaged as bytes for the given pixel format > plus the bitmask data. > > Question for you Saul: it seems if a tile is completely blank then it > may contain no data at all, right? which may explain some missing > tiles when I zoom in to some of the newly supported formats (16bit-u I > think). > > Cheers, > > Gabriel > Yeah, the performance issues I had were around the creation of multiple SeQuerys for one image request, so if you're past that step then you should be good. As for the completely blank tiles...yes, I believe the size of the response to "SeRasterTile.getPixelData()" will be a zero-length array if/when the tile doesn't contain any data. getNumPixels() should also return zero, I believe. --saul -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ArcSDE raster suppor refurbished, concept check and call for review
Gabriel, I think the move to JAI is *awesome*. I haven't looked at the code specifically yet, but I really like that you've offloaded the implementation details that can be handled by JAI to code that doesn't need to be supported inside geotools. There's a little on the LZERO_ORIGIN_TILE parameter here http://docs.codehaus.org/display/GEOTDOC/ArcSDE+Raster+Support but the deeper explanation is below: In ArcSDE 9.1 or below, when you load a raster using a sequence of tiles the *first* tile that you load gets to be the "0,0" tile, and the raster "origin" is set to the lower-left corner of that tile. This is unmodifiable after the raster is created. When querying a raster, one needs to know the x/y location of the upper-left tile and then work out the actual tiles to be queried based on the requested world-extent. On raster pyramid levels 1 or above, the x/y position of the 0,0 tile is trustworthy and will be the upper-left tile in the raster. However, at level zero, there can be a problem in this specific case: * You're using ArcSDE 9.1 or below * You didn't set a raster_origin point before loading the raster * You loaded the raster using a sequence of files (probably .tif files) and you didn't load the upper-left tile as the FIRST tile If the above three conditions are true, then the ArcSDE Java API will happily tell you that the level zero 0,0 tile is at the upper-left of the raster, but when you actually ask for that tile, you'll find out that at level zero the 0,0 tile is the FIRST TILE LOADED. Therefore, in order to access tiles above or to the left of the first tile loaded, you would need to trick ArcSDE into fetching you data from "negatively indexed" tiles, but the Jsde api doesn't allow negatively indexed queries, so that's out. This means that the data that is above or to the left of the first loaded tile is unavalaible at level zero, and you have to return level 1 (or 2, if skipLevelOne is set) data instead. The LZERO_ORIGIN_TILE parameter allows you to tell geotools exactly which tile is the "first loaded" tile so that queries of tiles above or to the left of that tile at level zero can be returned with level 1 or 2 data. This is a "filed and known" bug in the JSDE api, and in ArcSDE 9.2 or above you can re-set the raster origin using "sderaster -o ..." which I believe recalculates the various tables that cause this problem. I'd say that unless you have just such a setup to test against, I wouldn't worry about keeping support for the LZERO_ORIGIN_TILE parameter. If someone can come up with an sde raster that has this, err, "issue" and they can reproduce the problem, then all the code is in-place to support the fix...but without a working example it's a tough thing to code. hope that help gabriel, --saul Gabriel Roldan wrote: Hi guys, As you know I've been working on refurbishing the geotools arcsde module to support more raster formats. In the process, I've found the previous Saul work invaluable to understand how the arcsde raster api works, started adding support for some specific formats (16-bit unsigned, 32-bit float, 8bit-u colormapped) following the initial Saul's design. As a parallel inspiration I started spiking how to better integrate with JAI. It turned out to be easier than expected (once I learned a lot, remember I'm a newbie in gce land). In the end, I refactored a lot of code and come up with a new design, which makes use of an ImageInputStream implementation that reads arcsde tiles and is wrapped by a RawImageInputStream. So far so good, we have now a single raw arcsde raster format reader to rule them all. So, I would like to kindly ask you to answer a couple questions, before I go forward in wraping up the work and backporting to 2.5.x. - Saul: what is the intended use of the LZERO_ORIGIN_TILE parameter? I would need to check if it still applies. - All: I would love a concept check on the following explanation of the new workings of the module, and even a bit of a code review would be highly appreciated. Though there may be still a couple rough edges, I think I could make good use of your higher experience with gce to early catch on conceptual missunderstandings or technical mistakes. * How it used to work: Given a read request to the GT arcsde AbstractGridCoverage2DReader implementation: 1- connect to the raster table and gather raster layout and metadata information 2- create a BufferedImage compatible with the raster format, backed by the appropriate colormodel and samplemodel, and with the requested dimensions. Fail if there's no support for the raster's format and number of bands. 3- find out the most appropriate pyramid level to fullfill the requested extent and image dimension, as well as the matching tiles. 4- look up for a specific ArcSdeRasterReader(tm) for the given pixel depth and number of bands. 5- start fetching the raster tiles, for each tile, pass it to the ArcSdeRasterReader, together with the targ
[Geotools-devel] SDE Concurrency patch
Hey all, I've identified a nasty concurrency issue in the arcsde DataStore. I'm attaching a patch, but it's basically a one-liner. A brief explanation: Every SDE "stream" object (query, update, etc.) is based on an SDE connection, and if more than one "stream" object (SeStreamOp derived class) is constructed with the same underlying connection object, and then they're both pushed to do anything with the underlying connection (for an SeQuery, that'd be "execute()", for an SeUpdate that'd be "update()", etc.) bad things will happen. Generally the underlying connection object just locks up, causing the map being rendered to simply hang. I think there's a logical error in the ArcSDEQuery class, in the getSeQuery() method. The finally block at the end releases the connection that was just used to create the SeQuery object, and then returns the SeQuery object to the calling method. Presumably the calling method then uses the SeQuery.execute() method, and the underlying connection will likely then be re-handed out and re-used...causing a deadlock. I've commented out the releaseConnection() call. What should I do to file this as an official bug and patch? --saul --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Re: Who are we?
Saul Farber, GIS web developer/architect for the State (err, Commonwealth) of Massachusetts GIS office. Working on an super scalable, super inexpensive geoserver based web-services infrastructure to serve the state's gis web services needs. --saul --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] VOTE - label "shield" streaming renderer patch
Ian, First off, I get the geotools-devel list in digest form, so pardon the non-threaded reply. As for the label-placement/graphics automagic: Dave's label placement code was originally written solely for text. It has specific code and a specific datamodel (DTOs and method signatures) that expected text and only text. The SLD that activated that code only accepted the SLD-standard XML for labels, which itself allows only for text-based labeling. I modified his label code, and the SLD parser to accept a element in an appropriate place and to handle it in a somewhat-intuitive manner. The only other point-based graphics code that existed was code which allowed one to use a PointSymbolizer on a Line Geometry, which simply placed exactly one Graphic at the mid-point of every line segment. This is not what the labeler does. Since I needed the graphic to appear exactly at the same point as the label to get all the good stuff that labeling gives (grouping/non-grouping, spaceAround support, offsets, rotation, halos, etc...what I believe we're referring to as the "automagical" stuff) I simply extended the labeler to take a tag and to render it underneath the label. I changed the DTO's and the method signatures to handle an extra graphic as well as text, rather than only text. Does this clear up what the patch does and why it was motivated? Let me know if that's unclear! --saul > Um Ian, I doubt Dave's label placement code is error. My understanding > is that Label Placement is a bit of a "magic occurs here" issue, and > fleshing out the boundary allowing SLD authors to interact with a > placement algorithm is probably a good thing. I didn't say Dave's label placing code was in error. I think the need for this patch occurs because the label placement code will move text symbolizers automagically but not the associated graphic. May be Saul could confirm my understanding is correct? Ian -- Ian Turton http://www.geotools.org --- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Geotools-ArcSDE patch to enable geotools FID <-> SDE-managed RowID Column. Also enables null geometries
Hello geotools developers, I've submitted a patch against the 2.1.x branch head which causes geotools to attempt to use the sde-reported "rowid" column for a particular table as the FID for featuretypes based on that table. The particular itch this scratches for me was that I wanted to support tables which had "null" geometries, and the current sde code used the SeShape object to determine the fid, which was unfortunately not present in my table. To do this I wrapped the generic AttributeType schema objects in ArcSDEAttributeType objects which were simply pass-thrus that tracked an extra attribute, "isFeatureIdAttribute". In an earlier email about namespaces in ArcSDE featuretypes I noted that the ArcSDE adapter builds its own featureType schema cache, rather than sharing the geoserver ones. Since this "rowid column" stuff is figured out at the ArcSDE level (and in the "scope" of the ArcSDEAdapter's copy of the featureType schema), but the FID is written out in the "scope" of the geotools client's query schema (geoserver's copy in this case) the name of the rowid column is figured out and communicated from the first scope to the second. I guess this isn't optimal. It seems like the best way would be for there to be some kind of a global featuretype cache, and for every geotools-related module/application to be able to fetch from that same global featuretype cache, including annotating the featuretypes within the cache in just these kinds of ways. Since geoserver is currently tied to the 2.1.x geotools branch, and my primary motivation is geoserver, I've patched the 2.1.x branch. But when geoserver moves to 2.2.x I'll forward-port this patch (along with some other ones) and maybe try to round up some time to approach the "global featuretype cache" problem better. Comments/feedback on the patch are welcome! --saul --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] 'Like' filters and the default SQLEncoder
Hello all,
So I'm creating a community-mapbuilder application, and I think to
myself, "hey, I'll have a 'search' feature here'.
I create the page, have it submit a filter like this to my SDE-backed
geoserver featureCollection:
STREET_NAME
%MAIN%
However, it gives me back EVERY feature in the collection.
Hmm. I try a few different things, but while it's definitely getting
the LIKE filter into its internal Query representation: (here's a log
snippit)
[FINE] org.vfny.geoserver.wfs.responses.FeatureResponse - Query is
Query []
feature type: massgis:GISDATA.NAVTEQRDS_ARC
filter: [ ST_NAME is like %MAIN% ]
[properties: ST_NAME]
To gt2: Query: []
feature type: GISDATA.NAVTEQRDS_ARC
filter: [ ST_NAME is like %MAIN% ]
[properties: ST_NAME]
It's just NOT working.
So I delve a bit deeper, and have the ArcSDEQuery tell me what filter
it's using. In getSeSQLConstruct() there's a test like this (around
line 983):
if (!Filter.NONE.equals(sqlFilter)) {
...get the where clause for this query...
}
So I added an else to this if statement like so:
else {
LOGGER.warning("Filter was 'FILTER.NONE'");
}
Lo-and-behold, the line "Filter was 'FILTER.NONE'" appears in my log.
Weird! This is totally a supported filter as far as SDE is
concerned...why wouldn't it be showing up?
So I trace back and up through the geotools stack, and discover than in
the base-class org.geotools.filter.SQLEncoder on line 175 (also in
GT-2.2.x, by the way) the method "createFilterCapabilities()" creates
the default filter capabilities for a generic SQL encoder...and *doesn't
include* LIKE as a supported filter.
I went and added the line:
capabilities.addType(AbstractFilter.LIKE);
to that method, and everything worked just fine for me.
After all that, my question is as follows:
* Is this intentional? Is 'LIKE' excluded from the default filter
capabilities because some query engines just don't support 'LIKE' at
all? Or is this an oversight?
If it's an oversight, I can provide a patch to 2.2.x and 2.1.x
quickly...it's a one-liner.
If it's NOT an oversight, I can provide a patch to 2.2.x and 2.1.x to
get SDE support for LIKE filters, because (after all) it *does* in-fact
support them.
Anyone else bumped into this?
--saul
---
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Minor typo on trunk prevents compilation
In module/main/src/org/geotools/gml/SubHandler.java, there's an extra "*/" on line 16, double-closing a comment. This prevents compilation. Easy fix, just thought a commiter should know. thanks! --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Problem with wkb4j-1.0-RC1.jar
Hey all, I've successfully built an up-to-date geotools-2.2.x branch (currently RC5). Maven is very cool. I've also successfully built an up-to-date geoserver trunk. I then went to deploy my geoserver war file, and got the following exception when deploying it inside Tomcat: ... java.lang.IllegalArgumentException: log4j,openmap,postgis,jts,junitperf,junit,postgresql-Extension-Name ... I narrowed it down to the fact that the MANIFEST.MF inside the wkb4j jar file that's hosted at both maven.geotools.fr (seems to be the one pulled from gt-trunk) and at http://lists.refractions.net/m2 (seems to be the one pulled from gt-2.2.x) includes the line: *Extension-List: log4j,openmap,postgis,jts,junitperf,junit,postgresql* From what I understand from here: http://java.sun.com/j2se/1.5.0/docs/guide/jar/jar.html and here: http://java.sun.com/j2se/1.5.0/docs/guide/extensions/versioning.html this should instead read: *Extension-List: log4j openmap postgis jts junitperf junit postgresql* (spaces instead of commas). However, when I rebuilt the jar with exactly that change to the Extension-List attribute, I got a silent error from Tomcat (even worse). This copy of wkb4j has been around for a long time (I verified that the same problems were in the MANIFEST.MF file in the version released on sourceforge in 2003), so I can't imagine I'm the first person to run across this. Anyone else having this problem, or is it confined to linux+tomcat+java 1.5? --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Weirdness in SQLEncoder.java in 2.2.x?
On lines 184 and 185 in SQLEncoder.java are the following lines (revision 20608...head on the 2.2.x branch). capabilities.addType((long) 12345); capabilities.addType((long) -12345); These lines caused the arcsde module's SQLEncoderSDE class (which inherits the base-class createFilterCapabilities method) to act incorrectly, as the bitmask for supported filters was set to accept BBOX filters. Are these lines intentional? Commenting them out fixed my problem, and they don't make a whole lot of sense to me at first glance. --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [Geoserver-devel] Speeding up gif/png serving
Seems to me that one solution could be to have a per-layer 'cache' of a representative color-map. I.e., on the first request of a particular layer, a full color-reduction (using an expensive algorithm) is used. Then the calculated color-map is attached to that layer and cached. For future requests, the cached color-map is used. This idea could be expanded in a number of ways. 1) Rather than simply using the *first* request to generate the sample color-map, you could have a "learning mode" and a "production mode". When a layer is in "learning mode", its color-map is constantly refined, based on each image...resulting in as accurate a static color-map as possible for all viewed maps. In "production mode", the static color-map is used for all requests. Note that for most vector layers styled with SLD, you don't need to do learning-mode at all, as all colors are available for pre-populating the color-map. (although anti-aliasing would need to be 'learned'). 2) It's possible that for many geoserver instances, most layers are repeatedly requested in a particular 'stack' (i.e, most clients are map-oriented, not layer-oriented). You could expand the color-reduction caching to include one map for a particular SET of layers, rather than just one layer. This way commonly used combinations of layers (for particular clients) get the biggest speed boosts, while less-frequently used combos aren't optimized and don't waste space with their cached color-maps. Thoughts? --saul Andrea Aime wrote: > David Blasby ha scritto: >> I thought about this problem before -- the main issue is that the >> anti-aliasing causes a lot of "extra" colours to be created. >> >> The original colour reduction algorithm was to find the first 256 >> colours in the image and use those colours in the colour map. This >> completely failed to work after antialiasing was turned on - images >> went from 16 colours to 6,000! >> > > Another problem occurs when you add a coverage on the background, SLD > won't tell you which colors are there in a satellite image. > > Cheers > Andrea > > - > Using Tomcat but need to do more? Need to support web services, security? > Get stuff done quickly with pre-integrated technology to make your job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > ___ > Geoserver-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/geoserver-devel > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Problem with FilterCapabilities.ALL/.NONE on trunk/2.2.x
Hey all, I think there may be a serious problem with the FilterCapabilities.ALL and FilterCapabilities.NONE implementation on the trunk and 2.2.x branch. I could be way off here though...so some feedback would be great. As I understand it, a FilterCapabilities object represents the different sorts of filters that a given SQLEncoder can unpack. So, for example, if a datastore can't do spatial bbox queries, then its sqlencoder would not include the SPATIAL_BBOX flag in its filterCapabilities. This whole she-bang is implemented as a bitmask. From lines 53 down to about 157, a whole list of different operators are defined, and then assigned to a bit (via the left-shift operator). So, for example, the following 32-bit binary number: 0001 represents a filterCapabilities that supports SPATIAL_BBOX and nothing else. Similarly, the following 32-bit number: 00010001 represents a filterCapabilities that supports SPATIAL_BBOX and LIKE, and nothing else. etc. The problem is that ALL and NONE are implemented as integers, and their binary representations clobber the actual intended filter capabilities for the capabilities objects to which they're added. Check out this exmample: FilterCapabilities f = new FilterCapabilities(); f.addType(FilterCapabilities.NONE); This does the following (in the addType() method): ops = ops | type; i.e. ops = 12345 | type; i.e. (by converting 12345 to binary) ops = 1100111001 | type; In the end, calling f.addType(FilterCapabilities.NONE) creates a filter which claims to support: * SPATIAL_BBOX (0x01) * SPATIAL_INTERSECT (0x01<<3) * SPATIAL_TOUCHES (0x01<<4) * SPATIAL_CROSSES (0x01<<5) * BETWEEN (0x01<<12) * CHECK (0x01<<13) I confirmed this with a unit test. FilterCapabilities.ALL probably does something even more wacky, because Java probably stores negative longs as two's-compliments in binary. All of this is to say, that ALL and NONE are actually different flags that need to be added to the list of bit-shifted flags. Does any of this make sense? I've attached a FilterCapabiilities patch that fixes the trunk, and can do so for 2.2.x as well if needed. --saul Index: /home/ENV/sfarber/dev/geotools/geotools-trunk/module/main/src/org/geotools/filter/FilterCapabilities.java === --- /home/ENV/sfarber/dev/geotools/geotools-trunk/module/main/src/org/geotools/filter/FilterCapabilities.java (revision 20947) +++ /home/ENV/sfarber/dev/geotools/geotools-trunk/module/main/src/org/geotools/filter/FilterCapabilities.java (working copy) @@ -35,16 +35,6 @@ * Mask for no operation */ public static final long NO_OP = 0; - -/** - * Mask for Filter.NONE - */ -public static final long NONE = 12345; - -/** - * Mask for Filter.ALL - */ -public static final long ALL = -12345; // spatial masks /** @@ -135,6 +125,16 @@ public static final long LOGIC_NOT = 0x01<<24; public static final long LOGIC_OR = 0x01<<25; + +/** + * Mask for Filter.NONE + */ +public static final long NONE = 0x01<<26; + +/** + * Mask for Filter.ALL + */ +public static final long ALL = 0x01<<27; /** * Scalar Mask for logical operation - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Coverage streamingrenderer error
Hey all,
I'm going to have to leave this one till monday, but I'm having a
problem rendering a geotiff coverage via the 1.4.x_merge_wcs branch off
of trunk.
Everything sets up just fine, the GeoTiffReader is wrapped up in a
FeatureCollection with two attributes ("geom" and "grid") and that
FeatureCollection is wrapped up in a CollectionDataStore.
However, when AbstractDataStore goes to create a reader for the
collection (via AbstractDataStore.getFeatureReader(Query, typename))
somehowe the internal reader's version of the type is different than the
AbstractDataStores 'remembered' type.
getSchema() in the abstractdatastore claims it's {'grid','geom'}
reader.getFeatureType() in abstractdatastore.getFeatureReader() claims
it's {'geom','grid'}
This causes a "ReTypeFeatureReader" to be created, and since the
ReTypeFeatureReader can't deep-copy the "grid" object (nor should it!)
the rendering fails.
I'm still ramping up on the internal gt feature model, so my keeping
track of all the threads is a bit of slow going. AbstractDataStore vs
AbstractFeatureStore vs AbstractFeatureSource takes me about the times
to go though and get right, etc.
Can anyone tell me where the featureType would be getting re-created?
One possibility is in DefaultFeatureResults, where depending on the
query, DefaultFeatureResults might subType the featureType...
Any ideas?
--saul
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [Geoserver-devel] Coverage streamingrenderer error
I figured out a bit more, but now I'm definitely leaving!
The problem is much much simpler than I would think.
I'm probably just using a bogus SLD for my coverage, but in the portion
of StreamingRenderer that figures out which attributes to request, it's
mis-calculating the attributes to query. It figures that my style
requires the "grid" attribute, then automatically appends the "geom"
attribute to the end (since it's the geometry attribute for the
feature). This "inverts" the featureType in the query, which causes the
createSubType call.
What's the right SLD to put in for a coverage?
--saul
Saul Farber wrote:
> Hey all,
>
> I'm going to have to leave this one till monday, but I'm having a
> problem rendering a geotiff coverage via the 1.4.x_merge_wcs branch off
> of trunk.
>
> Everything sets up just fine, the GeoTiffReader is wrapped up in a
> FeatureCollection with two attributes ("geom" and "grid") and that
> FeatureCollection is wrapped up in a CollectionDataStore.
>
> However, when AbstractDataStore goes to create a reader for the
> collection (via AbstractDataStore.getFeatureReader(Query, typename))
> somehowe the internal reader's version of the type is different than the
> AbstractDataStores 'remembered' type.
>
> getSchema() in the abstractdatastore claims it's {'grid','geom'}
>
> reader.getFeatureType() in abstractdatastore.getFeatureReader() claims
> it's {'geom','grid'}
>
>
> This causes a "ReTypeFeatureReader" to be created, and since the
> ReTypeFeatureReader can't deep-copy the "grid" object (nor should it!)
> the rendering fails.
>
>
> I'm still ramping up on the internal gt feature model, so my keeping
> track of all the threads is a bit of slow going. AbstractDataStore vs
> AbstractFeatureStore vs AbstractFeatureSource takes me about the times
> to go though and get right, etc.
>
> Can anyone tell me where the featureType would be getting re-created?
> One possibility is in DefaultFeatureResults, where depending on the
> query, DefaultFeatureResults might subType the featureType...
>
> Any ideas?
>
> --saul
>
> -
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> ___
> Geoserver-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/geoserver-devel
>
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Trunk main module build broken, patch attached
Getting around 1.5's built-in concurrency, someone switched back to the EDU.oswego.concurrent jars. However, the relevant pom.xml files don't reference that jar, so the build fales at Diff.java. Here's a patch which fixes that. --- Index: pom.xml === --- pom.xml (revision 21051) +++ pom.xml (working copy) @@ -493,6 +493,12 @@ 1.6 + + + edu.oswego + concurrent + 1.3.4 + Index: module/main/pom.xml === --- module/main/pom.xml (revision 21051) +++ module/main/pom.xml (working copy) @@ -221,6 +221,10 @@ jsde_concurrent + + edu.oswego + concurrent + --- --saul - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] SDE Dummy jars possible problem...
Hey all,
Just had a thought while looking through the SDE dummy jars.
Anywhere that one uses a construct like this:
public static final int TYPE_SMALLINT = 0;
For example, in SeColumnDefinition.java, I *think* java compiles the
value of a public static final right into the code. I.e. if
there were two files like this:
public ClassA {
public static final int CONSTANT = 0;
}
and
public ClassA {
public static final int CONSTANT = 1;
}
And one compiled both of these class files into jars, and then compiled
the following program twice:
package org.depends.on.bad.java;
public ClassAUser {
public static void main(String[] args) {
if (ClassA.CONSTANT == 0)
System.out.println("ClassA.CONSTANT is Zero");
}
}
The above "if" statement is calculated at COMPILE-TIME, not runtime, and
so you'll get a fixed answer, no matter which ClassA you put on the
classpath. Here's some sample output:
[EMAIL PROTECTED] compilerTest $ javac -cp classAZERO.jar \
ClassAUser.java
[EMAIL PROTECTED] compilerTest $ java -cp classAZERO.jar:. \ ClassAUser
ClassA.CONSTANT is Zero
[EMAIL PROTECTED] compilerTest $ java -cp classAONE.jar:. \ ClassAUser
ClassA.CONSTANT is Zero
[EMAIL PROTECTED] compilerTest $
[EMAIL PROTECTED] compilerTest $
[EMAIL PROTECTED] compilerTest $ javac -cp classAONE.jar \
ClassAUser.java
[EMAIL PROTECTED] compilerTest $ java -cp classAZERO.jar:. \ ClassAUser
[EMAIL PROTECTED] compilerTest $ java -cp classAONE.jar:. \ ClassAUser
[EMAIL PROTECTED] compilerTest $
Hmmm...that's bad. This means that if we don't have the "public static
final int TYPE_SHAPE" set to exactly the same integer as the SDE API, we
won't be able to do drop-in replacement. Things will compile, but
anything based on a public constant (mostly shape type discovery and
such) won't work correctly unless one *compiles* the code with the SDE jars.
I wonder if I can get around this by changing the variables from public
static final to just "public static".
Then we might trick the compiler into not doing compile-time evaluation
of those constants.
Let me check...
Yes! It works.
Ok, so I'd suggest that we remove the "final" modifier from all the
public static constants in the SDE Java API dummy sources. Otherwise
stuff won't really work the way we want it to!
--saul
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Path for moving 'arcsde' to 'supported'
Jody, Chris, Justin, I've been following your discussion of the db2 and oracle modules, and thought I'd chime in. I've been chatting with Gabriel, and I'd like arcsde to be a supported module too, and will work to do so. There are *many* things on this path, but one that is particularly relevant to your latest discussion is getting arcsde covered by unit tests. I have access to an ArcSDE 9.1 instance that can be used by an automated testing environment. I just need to coordinate with whoever's running the cruise-control server to get the right source IP and enable access from that IP to our server. Once that bit is in place, at least Gabriel and I will have the motivation to make sure the arcsde tests are passing! Does this make sense, and is it something that's do-able? --saul - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Path for moving 'arcsde' to 'supported'
Cool. Also, I need to know the IP address of the TOPP cruise-control continuous build server. As well as the refractions nightly build server. Our SDE server is behind a firewall, and our network security personnel will need the source ip addresses of connecting machines in order to allow connections to traverse the firewall. --saul Justin Deoliveira wrote: > Hi Saul, > > This is great. To move forward we need: > > 1. Gabriel to set up the arcsde online tests. I dont see any of them > marked as "online". From the looks of it there seems to be a property > file we can edit to point at Saul's ip. > > 2. I need to upload the real arcsde jdbc jar onto the topp server and > add the online flag to the maven build. > > -Justin > > > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Path for moving 'arcsde' to 'supported'
Great, the request is in to our IT folks. We'll see how fast the bureaucracy around here moves now... Justin, you might try telnet-ing to port 5151 from the geo.openplans.org box to test it sometime in an hour or two. --saul Justin Deoliveira wrote: > Cool, the topp server is 64.147.114.68 ( geo.openplans.org ). > > -Justin > - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] ArcSDE patch for 2.3.x branch and gt-trunk
Gabriel (and other arcsde folks!)
I'm attaching a patch that deals with four JIRA issues. The two
versions are exactly the same, one just works with trunk paths, the
other with 2.3.x paths.
Jira issues http://jira.codehaus.org/browse/GEOT-1007 and
http://jira.codehaus.org/browse/GEOT-1006
Easy ones. Both describe improvements made with this patch.
http://jira.codehaus.org/browse/GEOT-986 (and dependent geoserver JIRA
http://jira.codehaus.org/browse/GEOS-747)
Logging sql in SDE is hard, and mostly impossible to do. The comments
say exactly why. This patch gets a *little* further by showing which
portions of the gt filter are getting set to which parts of the SDE
query. At least it will tip you off to the fact that your query is not
getting sent to the db at all.
It also prints the SQL for the "where-clause" (non-spatial) portion of
the SDE query.
Can you give feedback and (if you don't have any objections) apply to
2.3.x and trunk gabriel? Thanks!
I'm working on porting this to 2.2.x as well. I'll post that later.
--saul
Index: plugin/arcsde/datastore/src/org/geotools/filter/SQLEncoderSDE.java
===
--- plugin/arcsde/datastore/src/org/geotools/filter/SQLEncoderSDE.java (revision 22550)
+++ plugin/arcsde/datastore/src/org/geotools/filter/SQLEncoderSDE.java (working copy)
@@ -101,6 +101,7 @@
capabilities.addType(FilterCapabilities.FID);
capabilities.addType(FilterCapabilities.NONE);
capabilities.addType(FilterCapabilities.ALL);
+capabilities.addType(FilterCapabilities.LIKE);
return capabilities;
}
Index: plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEDataStore.java
===
--- plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEDataStore.java (revision 22550)
+++ plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEDataStore.java (working copy)
@@ -18,10 +18,8 @@
import java.io.IOException;
import java.net.URI;
-import java.net.URISyntaxException;
import java.util.ArrayList;
import java.util.HashMap;
-import java.util.Iterator;
import java.util.List;
import java.util.Map;
import java.util.logging.Level;
@@ -846,8 +844,20 @@
*/
protected Envelope getBounds(Query query) throws IOException {
LOGGER.info("getBounds");
-
-Envelope ev = ArcSDEQuery.calculateQueryExtent(this, query);
+
+Envelope ev;
+if (query.getFilter() == null || query.getFilter().equals(Filter.NONE)) {
+ LOGGER.fine("getting bounds of entire layer. Using optimized SDE call.");
+ // we're really asking for a bounds of the WHOLE layer,
+ // let's just ask SDE metadata for that, rather than doing an expensive query
+ SeLayer thisLayer = this.connectionPool.getSdeLayer(query.getTypeName());
+ SeExtent extent = thisLayer.getExtent();
+ ev = new Envelope(extent.getMinX(), extent.getMaxX(),
+extent.getMinY(), extent.getMaxY());
+} else {
+ ev = ArcSDEQuery.calculateQueryExtent(this, query);
+}
+
LOGGER.info("bounds: " + ev);
return ev;
Index: plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEAttributeReader.java
===
--- plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEAttributeReader.java (revision 22550)
+++ plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEAttributeReader.java (working copy)
@@ -201,7 +201,8 @@
throw new DataSourceException("Unable to reliably determine an FID column for this table, so we defaulted to using the '" + featureIDAttributeName +"' column. But it was null, leaving us no FID for this feature.");
} else {
this.currentFid = Long.parseLong(value.toString());
- LOGGER.fine("Fetched fid " + this.currentFid + " from column " + featureIDAttributeName);
+ if (LOGGER.isLoggable(Level.FINER))
+ LOGGER.finer("Fetched fid " + this.currentFid + " from column " + featureIDAttributeName);
continue;
}
}
Index: plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEQuery.java
===
--- plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEQuery.java (revision 22550)
+++ plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEQuery.java (working copy)
@@ -243,7 +243,7 @@
}
if (!hasFIDColumn) {
- LOGGER.warning("No FID attribute was contained in your query. Appending the discovered one to the list of columns to be fetched.");
+ LOGGER.info("No FID attribute was contained in your query. Appending the discovered one to the list of columns to be fetched.");
for (int i = 0; i < schema.getAttributeCount(); i++) {
AttributeType
[Geotools-devel] ArcSDE speed and logging patch for gt 2.2.x
See previous post for details of patch. Attached is gt-2.2.x compatible
patch.
--saul
Index: plugin/arcsde/datastore/src/org/geotools/filter/SQLEncoderSDE.java
===
--- plugin/arcsde/datastore/src/org/geotools/filter/SQLEncoderSDE.java (revision 22555)
+++ plugin/arcsde/datastore/src/org/geotools/filter/SQLEncoderSDE.java (working copy)
@@ -101,6 +101,7 @@
capabilities.addType(FilterCapabilities.FID);
capabilities.addType(FilterCapabilities.NONE);
capabilities.addType(FilterCapabilities.ALL);
+capabilities.addType(FilterCapabilities.LIKE);
return capabilities;
}
Index: plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEDataStore.java
===
--- plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEDataStore.java (revision 22555)
+++ plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEDataStore.java (working copy)
@@ -839,8 +839,20 @@
*/
protected Envelope getBounds(Query query) throws IOException {
LOGGER.info("getBounds");
-
-Envelope ev = ArcSDEQuery.calculateQueryExtent(this, query);
+
+Envelope ev;
+if (query.getFilter() == null || query.getFilter().equals(Filter.NONE)) {
+ LOGGER.fine("getting bounds of entire layer. Using optimized SDE call.");
+ // we're really asking for a bounds of the WHOLE layer,
+ // let's just ask SDE metadata for that, rather than doing an expensive query
+ SeLayer thisLayer = this.connectionPool.getSdeLayer(query.getTypeName());
+ SeExtent extent = thisLayer.getExtent();
+ ev = new Envelope(extent.getMinX(), extent.getMaxX(),
+extent.getMinY(), extent.getMaxY());
+} else {
+ ev = ArcSDEQuery.calculateQueryExtent(this, query);
+}
+
LOGGER.info("bounds: " + ev);
return ev;
Index: plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEQuery.java
===
--- plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEQuery.java (revision 22555)
+++ plugin/arcsde/datastore/src/org/geotools/data/arcsde/ArcSDEQuery.java (working copy)
@@ -240,7 +240,7 @@
}
if (!hasFIDColumn) {
- LOGGER.warning("No FID attribute was contained in your query. Appending the discovered one to the list of columns to be fetched.");
+ LOGGER.info("No FID attribute was contained in your query. Appending the discovered one to the list of columns to be fetched.");
for (int i = 0; i < schema.getAttributeCount(); i++) {
AttributeType type = schema.getAttributeType(i);
if (type instanceof ArcSDEAttributeType) {
@@ -248,7 +248,7 @@
String[] newQCols = new String[queryColumns.length + 1];
System.arraycopy(queryColumns, 0, newQCols, 0, queryColumns.length);
newQCols[queryColumns.length] = type.getName();
- LOGGER.warning("Appendend " + newQCols[queryColumns.length] + " to column list.");
+ LOGGER.fine("Appendend " + newQCols[queryColumns.length] + " to column list.");
queryColumns = newQCols;
break;
}
@@ -340,8 +340,8 @@
if (LOGGER.isLoggable(Level.FINE)) {
LOGGER.fine("constructing new sql query with connection: "
+ connection + ", propnames: "
-+ java.util.Arrays.asList(propertyNames) + " sqlConstruct: "
-+ this.filters.getSeSqlConstruct());
++ java.util.Arrays.asList(propertyNames) + " sqlConstruct where clause: '"
++ this.filters.getSeSqlConstruct().getWhere());
}
SeQuery query = connection.createQuery(propertyNames,
@@ -929,6 +929,9 @@
unpacker.unPackAND(this.sourceFilter);
this.sqlFilter = unpacker.getSupported();
+
+if (LOGGER.isLoggable(Level.FINE) && sqlFilter != null)
+ LOGGER.fine("SQL portion of SDE Query: '" + sqlFilter + "'");
Filter remainingFilter = unpacker.getUnSupported();
@@ -936,7 +939,12 @@
unpacker.unPackAND(remainingFilter);
this.geometryFilter = unpacker.getSupported();
+if (LOGGER.isLoggable(Level.FINE) && geometryFilter != null)
+ LOGGER.fine("Spatial-Filter portion of SDE Query: '" + geometryFilter + "'");
+
this.unsupportedFilter = unpacker.getUnSupported();
+if (LOGGER.isLoggable(Level.FINE) && unsupportedFilter != null)
+ LOGGER.fine("Unsupported (and therefore ignored) portion of SDE Query: '" + unsupportedFilter + "'");
}
/**
-
Using Tomcat but need to do more?
[Geotools-devel] PropertyIsNotEqualTo and GeoAPI 2.1 snapshot
Hey geotools wizards, I was recently setting up some examples for some users of our new 1.5.x based geoserver install, and came across an example that used to work, but no longer does. It was an SLD layer with a UserStyle with a filter like: http://www.opengis.net/ogc";> COUNTY BARNSTABLE COUNTY MIDDLESEX Unfortunately it didn't work. I think the culprit is that IsNotEqualToImpl throws an UnsupportedOperationException in its accept() method, because org.opengis.filter.FilterVisitor doesn't have a visit(PropertyIsNotEqualTo,Object) method. Is this an oversight, or is there some specification-based reason why PropertyIsNotEqualTo is omitted from the geoapi snapshot? There's even a note in the code from Justin saying something like, "Do we need a PropertyIsNotEqualTo interface?" It's worth noting that PropertyIsNotEqualTo is an extraneous operation, as you can re-write any "PropertyIsNotEqualTo" as a "Not->PropertyIsEqualTo". Of course, by this logic, "Or" is likewise extraneous as NAND gives you the complete space of boolean logic, right? I can re-write the Filter XML -> internal rep parser to generate "NOT->PropertyIsEqualTo" constructs, rather than using the PropertyIsNotEqualTo construct, but this seems like a lot of work if it's an oversight. Any chance a new version of geoapi that fixes this is out there somewhere and that someone might be committing it to gt-2.3.x anytime soon? Thanks all! --saul - SF.net email is sponsored by: A Better Job is Waiting for You - Find it Now. Check out Slashdot's new job board. Browse through tons of technical jobs posted by companies looking to hire people just like you. http://jobs.slashdot.org/ ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] PropertyIsNotEqualTo and GeoAPI 2.1 snapshot
Gah! Well, it's fairly critical mostly because I've got a *lot* of SLD sitting around that uses != filters. And, I suppose, because this is a non-trivial problem with the 1.5.x branch. I mean, if geoserver 1.5.x is ever to be released while based on 2.3.x, then this problem will need to be fixed at some point. I poked a bit at changing the geotools FilterFactory to generate a Not(PropertyIsEqualTo) for a != filterType, but that's not going anywhere because "Not" isn't a CompareFilter...nor should it be. I guess I could cook up an isNotEqualToImpl that got around this, but somehow I think it would be pretty ugly. On the other hand, it's not your job to bail me out of switching prematurely to a developers version of Geoserver..this is what I get! Instead of having you rollback all those changes, make the fix, do the tag and then re-apply all the changes, how about this (I'll call it suggestion 1): * Sync your local copy to the date you made the 2.1-M1 cut * Create a branch from that point, calling the branch "2.1-M1" * Apply the patch to that branch and re-release 2.1-M1. * Send the "ping of death" to anyone that tries to develop anything against that orphan branch, directing them to send their efforts to trunk. Worst case scenario, we can use the 2.1-M1 branch for critical-path fixes supporting 2.3.x. That way you don't have to rollback and re-apply all those changes and yet we still get a working 2.3.x branch. Would that be less work? The alternative (I'll call it suggestion 2) is that if you can just give me the date you cut 2.1-M1, I can work out a fix and just make my own "non-standard" 2.1-M1 jar, even posting it if you want. That way you don't have to do any work because someone else screwed up! thanks, --saul Justin Deoliveira wrote: > Hi Saul, > > Yes, you are correct, and this interface was indeed just recently added > to geoapi. Unfortunately the fix requires a change to geoapi > FilterVisitor. Which brings us to another issue. > > Geootols 2.3.x seems to build against geoapi 2.1-M1 which from what I > can tell has no tag in the geoapi repository. I am to blame for this, I > must have forgotten to do this when i made the geoapi release. > > Unfortunately there have been some recent geoapi changes which would > break geotools 2.3.x, so moving 2.3.x to geoapi trunk isn't really an > option. > > So... to make a long story short here is what we have two options. > > Option 1: Create a geoapi 2.1-M1 tag, and roll back the recent changes > from trunk, then apply the patch to fix the PropertyIsNotEqualTo. > > Option 2: Fix on geoapi trunk and geotools trunk and wait for 2.4 to > pick up the fix. > > If this is a crucial fix for you Saul I can make some time this week to > apply the fix via option 1. Regardless i have thrown together a jira bug > for it. > > http://jira.codehaus.org/browse/GEOT-1021 > > -Justin > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] PropertyIsNotEqualTo and GeoAPI 2.1 snapshot
Justin,
Just a heads up that I went and did "suggestion 2" on my own, figuring
September 15th as the 2.1-M1 cut date from the folder age in the
refractions maven repo. $ svn update -r {2006-09-15}
With just the one fix in FilterVisitor.java to the 2.1-M1 code, I cut a
local release of 2.1-M1, made the appropriate changes in geotools
(IsNotEqualToImpl.java, FilterVisitorFilterWrapper.java) and now
everything works swimmingly. works as expected.
If you're not up for a big re-release and you're content with the 2.1-M1
jars otherwise (and their permanent relationship to 2.3.x?) I can post
the modified geoapi-nogenerics-2.1-M1.jar, along with the patch to the
appropriate revision, if its of any use to you.
Of course, unless said modified jar file gets put into the maven repo,
the fix can't be applied to 2.3.x, so if this is all too much work I can
just do my thing quietly and not bug anyone!
Thanks for steering me into the right places Justin.
--saul
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] PropertyIsNotEqualTo and GeoAPI 2.1 snapshot
Apparently we're thinking at the same speed. Would it help you any to have .patch files to run against the 2.1-M1 branch, or is it trivial enough that you can do it by hand? Let me know if I can help. --saul Justin Deoliveira wrote: > Hi Saul, > > I can create the 2.1-M1 branch in geoapi and apply the patch which will > fix the problem. There aren't many active geotools developers with > geoapi access ( i believe myself, jody, cory, and martin ), so if we can > call agree that we will create the branch only for this emergency fix, > then that should work fine. And since 2.3.x is going stable there > shouldn't be a need for any more geoapi development for it. > > -Justin > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GEOT-1037
Hey all, Ran into something funny the other day. I've explained it in JIRA (http://jira.codehaus.org/browse/GEOT-1037) and have included a patch to fix that specific problem. But perhaps I mis-understand something about how filter parsing works... I was surprised to see that "new Short((short)1).equals(new Integer(1))" returns false...is anyone else? --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] GEOT-1037
Jody, Cool. Thanks for the info on how the Literal semi-typing system works on trunk. Clearly that fixes this problem for gt-2.4.x-based solutions. However, I'm not sure I understand how this problem might be fixed on the 2.3.x branch. Your second comment notes that a geoAPI change would be required to backport the full set of expression improvements to 2.3.x, so I'm guessing that idea is out. Still, this issue means that for those using ArcSDE with geoserver 1.5.x (to get rasters), filters are "broken" in a pretty specific sense. Clearly at some point geoserver will move to gt-2.4.x, and this issue will go away...but it's not clear to me when that might be. In the mean time, do you think there's a clean way to resolve this issue for the 2.3.x branch so that folks using the 1.5.x branch of geoserver with ArcSDE can get working "java.lang.Short" filters without having to patch geotools themselves? --saul Jody Garnett wrote: > Added a comment to your issue explaining how this was solved on trunk. > Your specific test case we be a nice addition; and we can always use a > code review. > For more details please check out: > - http://docs.codehaus.org/display/GEOTOOLS/Expression+Improvements > Jody - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] For 2.3.0 release need to triage the JIRA bugs
I've got two in there. One is this: http://jira.codehaus.org/browse/GEOT-803 This is resolved and fixed on 2.3.x. I think it's just open because it was unclear whether it made it to 2.3.x, when geoserver was still in 2.1.x. The other is this: http://jira.codehaus.org/browse/GEOT-1025 Should be a straightforward patch application. Sometimes SDE flakes out. This makes sure GT fails gracefully. --saul Adrian Custer wrote: > Hey all, > > We currently have 46 bugs outstanding on 2.3.x. Since we are going to > release 2.3.0 on friday, could you all work through the list and triage > the bugs, bumping what needs to be bumped to 2.4? We originally thought > that 2.3.x was going to be more significant than what it has now turned > out to be. > > http://jira.codehaus.org/secure/IssueNavigator.jspa?pid=10270&fixfor=12442 > > thanks, > adrian - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] GEOT-1037 for 2.3.0 release
Just a quick check on this (closed) issue. I'm not sure that I understand how this got resolved. As best I can tell, the fix is in the new typing system in trunk (2.4.x), but there was no specific fix for 2.3.x. Since this affects 2.3.0, and I think it's a pretty significant bug (certainly bit me hard!), what's the call on my patch? There's logic already in the class to cover the 'new Long(1) != new Integer(1)' case, this just extends it to cover the BigInteger and Short cases. Should I re-open the JIRA issue, or is this one not that important? --saul > > In the mean time, do you think there's a clean way to resolve this issue > for the 2.3.x branch so that folks using the 1.5.x branch of geoserver > with ArcSDE can get working "java.lang.Short" filters without having to > patch geotools themselves? > > --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] [jira] Commented: (GEOT-1050) fid attribute is 'missing' as a feature-attribute
Gabriel, Sure, I'll poke at the complex-features branch stuff later today. As for the schema invalidity issue: When you create a geoserver featuretype, it generates XML schema (based on the feature schema) which includes the sde-managed rowid field. Since that field isn't ever present on actual output, one either has to modify the schema to make the sde-managed rowid field optional (minoccurs=0) or one has to modify the schema by hand. I suppose the other option is to change the code so that the feature schema generated by such an SDE layer doesn't include the rowid column. But I'm not sure what I think about that. I guess it's tricky...do you want the FID to be in two places (a little confusing) or in just one (unexpected if you wanted to, say, *edit* the fid. How would having the FID-attribute not exist as a feature attribute be handled for WFS-T inserts? Can one specify on a "Transaction" request exactly which FID you expect your feature to be inserted with? Does that make any sense to you? What do you think? --saul Gabriel Roldán (JIRA) wrote: > [ http://jira.codehaus.org/browse/GEOT-1050?page=comments#action_81541 ] > > Gabriel Roldán commented on GEOT-1050: > -- > > Saul, I'm not sure the arcsde managed row-id column should appear as a normal > attribute. At least as long as its value is automatically added by arcsde on > an insert. > > What do you mean by causing schema invalidity? > > Also, if you could take an hour, would you be so kind of taking a look at the > stuff in the geotools complex-features branch that allows arcsde plugin to > have different fid strategies based on how the table is settled up? I would > very like your impression about that, since I'm planning to port it to trunk > on my vacation week next month > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] SDE complex-features port to trunk
Hey gabriel, I had a chance to go through your SDE datastore code on complex features, and I'm really impressed. Lots of great ideas, and I really like the FIDReader stuff to support a more general approach to fetching FIDs from sde rows. I have a couple of comments, which I'll try to put in decreasing order of importance. 1) The current FIDReader solves the problem of how to get a good FID out of a feature quite nicely. However, FIDReader isn't used in the SQLEncoderSDE class at all, so while your FID might be excellently *returned*, FID filters won't generally query the FID column correctly. Did I overlook some logic in the code somewhere on that one? 2) The work on "inproccess" sde views is really cool. Thinking about how to return FIDs on a view is tough...but how about instead of just punting the question (FIDReader.NULL_READER) one created a "composite" fid? Take the FIDs from each of the underlying tables, and put a ":" or "-" inbetween them all. the SQLEncoderSDE part of that (where you break out the "composite" FID back into the query) would be a bit tricky, I suppose. 3) There have been a few little patches to the ArcSDE datastore code since complex-features went in. Like some optimizations to the common case of getting the layer extent for the whole layer (getLayerExtent with null query) and handling dead connections (like if the SeQuery object poops out in the middle of a query), so we should make sure those get merged into the port. 4) Would you consider back-porting from trunk to 2.3.x when it's on trunk? 5) Doesn't this strategy do the opposite of what we were discussing yesterday? I mean, if the OBJECTID column is the sde-managed row-id column, doesn't this implementation return OBJECTID as an attribute *and* as the FID? I'm really excited to see this stuff make it to trunk (and hopefully 2.3.x!) --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] negotiating for scheduled releases
I'm sure everyone's typing madly right now! I also wrote a long one, but have distilled it here. Pros: GSIP#6 is clearly a good idea. Why is gt-trunk out there if not to be used? Cons: Having many branches of code around makes bugs really hard to close because you have to patch the same damn thing once for each branch. Suggestion: * Have a running branch of geoserver which tracks gt-trunk. *not* geoserver-trunk, but a different branch, perhaps called "geoserver-gt-trunk-sync". coupled with * Constantly svn merge geoserver-trunk into geoserver-gt-trunk-sync, and then make necessary changes to compile against gt-trunk. This way you have an always-up-to-date patch (svn diff > gs-trunk-to-gt-trunk.patch) taking gs-trunk to gt-trunk. The hard part is that geotools often leads geoserver. It's true that geotools risks going in the "wrong" direction, but geotools is often the leader here. More folks tracking ISO/OGC standards in gt than geoserver, for sure! --saul Jody Garnett wrote: > What I would like to do is have GeoServer trunk and uDig trunk track > GeoTools trunk. GeoServer is the more important of these two for the > following reasons: > - the project is driving current development with WCS and OWS4 > - it has a valued safety net in the form of CITE tests that may catch > errors our own test cases do not > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] negotiating for scheduled releases
> I am actually hoping this reduces code branches ... both for geotools > and geoserver. So what do you see as the geoserver branch/functionality structure? Leaving aside legacy branches that get only bugfix treatment (1.3.x, soonish 1.4.x), how can geoserver lay out its braches to meet its functionality requirements? Perhaps think what Andrea would say about stability before suggesting that gs-trunk would work well on gt-trunk (without re-thinking how gt-trunk is currently a big old R&D experiment) >> >> * Have a running branch of geoserver which tracks gt-trunk. *not* >> geoserver-trunk, but a different branch, perhaps called >> "geoserver-gt-trunk-sync". > I am not sure that suggestion (which occurred to me as well) is quite > strong enough - we are operating with this right now except the branch > of geoserver is called OWS4. Sort-of. Except that OWS4 is just a one-man experiment. geoserver-track-gttrunk (better name, I think) would need to be more actively developed...perhaps with a cruisecontrol so that folks knew when it was busted. >> coupled with >> >> * Constantly svn merge geoserver-trunk into geoserver-gt-trunk-sync, >> and then make necessary changes to compile against gt-trunk. This way >> you have an always-up-to-date patch (svn diff > >> gs-trunk-to-gt-trunk.patch) taking gs-trunk to gt-trunk. > Darn that hurt my brain; will try and talk myself through that after a > break. I think it's my bad names that got you bogged down! It's simpler than I wrote it, I think. The idea is that geoserver's "real" development would go on against geoserver-trunk, which is based on some kind of stable geotools. Then a "forward-port" of geoserver-trunk would be maintained which tracked the changes to geoserver-trunk required to make it run against geotools-trunk. When someone wants to bring any *new* geoserver development into the forward-port, they can just svn merge the trunk to their branch. Once they've got everything sorted out (if there are any problems) then the difference between geoserver-trunk and the forward-port (as retreived by "svn diff forward-port") are exactly what's needed to make geoserver-trunk work against geotools-trunk. >> The hard part is that geotools often leads geoserver. It's true that >> geotools risks going in the "wrong" direction, but geotools is often >> the leader here. More folks tracking ISO/OGC standards in gt than >> geoserver, for sure! > Interesting; this conflicts with my recent experience - GeoTools is > changing right now in order to facilitate GeoServer development (the > fact that this development is scattered across GeoServer branches is a > different problem). Yeah, it's true. There's lots of people doing lots of crazy stuff right now. It would be cool if there was a less scary/treacherous/scattered way of letting geoserver/geotools work together. But hey, at least there's no more geoserver-specific geotools code in the geoserver svn repository, right? Didn't that happen for a bit? --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] negotiating for scheduled releases
Ok, so I just re-read my words below. Perhaps this is a slightly too convoluted process to adopt as a legit development procedure. I still think it would technically work, but I'm less sure of it than I was when I thought of it. Maybe it's a good band-aid, but it's still just a band-aid over the bigger problem that GSIP#6 is trying to get the Geoserver PMC to address. --saul > > I think it's my bad names that got you bogged down! It's simpler than I > wrote it, I think. The idea is that geoserver's "real" development > would go on against geoserver-trunk, which is based on some kind of > stable geotools. Then a "forward-port" of geoserver-trunk would be > maintained which tracked the changes to geoserver-trunk required to make > it run against geotools-trunk. > > When someone wants to bring any *new* geoserver development into the > forward-port, they can just svn merge the trunk to their branch. Once > they've got everything sorted out (if there are any problems) then the > difference between geoserver-trunk and the forward-port (as retreived by > "svn diff forward-port") are exactly what's needed to make > geoserver-trunk work against geotools-trunk. > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Building ArcSDE 2.2.x plugin
I think that's a good idea. Geoserver has been providing a seperate download of the gt2-arcsde plugin for those who want it, but now that there's a dummy API it doesn't seem that there's any reason not to have it in the build. --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Error rendering ArcSDE
Jesse, I'll build with the latest 2.2.x jars and see if I have the same problem, but it definitely looks like a problem with your jsde jars. Do you have all three of them in your webapps/lib directory and can you confirm the version (and maybe an sha1 checksum to see if I have the same ones?) I've got copies of 9.0SP2 and 9.1 kicking around, so I can test with a couple different versions. --saul Jesse Eichar wrote: > I'm using ArcSDE built from 2.2.x, 2.2.3-SNAPSHOT to be exact. > > Does this stack trace mean anything. Maybe I have the wrong jsde-sdk > jar? I believe I have the 9.0 jar. What verison should I use? > > Caused by: java.lang.NoSuchFieldError: SE_OPTIMIZE > at > org.geotools.data.arcsde.ArcSDEQuery.createSeQueryForFetch(ArcSDEQuery.java:361) > at org.geotools.data.arcsde.ArcSDEQuery.getSeQuery(ArcSDEQuery.java:299) > at org.geotools.data.arcsde.ArcSDEQuery.execute(ArcSDEQuery.java:663) > at > org.geotools.data.arcsde.ArcSDEDataStore.getFeatureReader(ArcSDEDataStore.java:541) > at - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Error rendering ArcSDE
Jesse, Sorry this took me so long! I'm trying with the latest build of 2.2.x (2.2.3-SNAPSHOT + some kind of weirdness in the maven repo right now involving lots of downloaded 2.2.2 jars) and geoserver-1.4.x. First try: using jars from maven.geotools.fr (http://maven.geotools.fr/repository/com/esri/). I.e., these are what you get if you just uncomment the right bits of the poms and hit "maven install" sha1sums (in case you're not sure if your jars are the same): 4673061758f9954932c112a6b10674ee6dc81400 jsde_concurrent-9.0.jar 54b6d676c7c0e076b33153d4f81834894dcbfc6e jsde_jpe_sdk-9.0.jar bfc6aaa478ffd5debac15e8a4b1bbd28ec10f6c3 jsde_sdk-9.0.jar First try results: I made a new featuretype out of one of my database tables, and used the built-in mapbuilder client to render it. Looked fine. Second try: using jars from the SDE 9.1 developer kit cd install (i.e., I untarred their developer kit install tarfile from the cd and used the jar files) sha1sums 82d325a45f7653bb687f3e41122ae764279b77ee jsde91_sdk.jar 839fdd339295d71844cf9bad7f16652ab6e390f7 jpe91_sdk.jar Second try results: I made the same featuretype out of one of my database tables, and used the built-in mapbuilder client to render it. Looked fine. Not sure what's up jesse, but you might try the sde jars from maven.geotools.fr. Those worked fine for me. Note that your problem seems to be a Java problem...not an SDE problem. Did you compile your own gt2-arcsde plugin jarfile? --saul Jesse Eichar wrote: > I used some version 9.0 jars but I don't know exactly what version. > Please let me know what you find out. > > Jesse > On 7-Dec-06, at 8:30 AM, Saul Farber wrote: > >> Jesse, >> >> I'll build with the latest 2.2.x jars and see if I have the same >> problem, but it definitely looks like a problem with your jsde jars. >> Do you have all three of them in your webapps/lib directory and can >> you confirm the version (and maybe an sha1 checksum to see if I have >> the same ones?) >> >> I've got copies of 9.0SP2 and 9.1 kicking around, so I can test with a >> couple different versions. >> >> --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Error rendering ArcSDE
I updated and everything built to 2.2.3-SNAPSHOT like a charm. Thanks Gabriel! --saul Gabriel Roldán wrote: > fixed the poms in 2.2.x land, > you should just update and get it building ok. > > bug me if not. > > regards, > > gabriel - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Error rendering ArcSDE
Hmm...I think you figured out the issue on the udig list, but I'll answer here for completeness. I'm pretty sure that I compiled against the "real" jars, and that your issue is due to compiling against the "dummy" jars and then inserting the "real" jars in at runtime. Apparently this switch-er-oo works in geoserver, but not in eclipse. Weird! --saul Jesse Eichar wrote: > HI Saul, > > Did you compile the gt2 arcsde jar against the "real" jars or the dummy > jar? I have tried a zillion different permutations now but I realize > that I compiled against the dummy jar. > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Confirming Jesse's ArcSDE bug
Hey all, I can confirm that there's a bug in the dummy_api resulting in the following scenario: 1) You compile and install gt-2.2.x without modifying any poms 2) You compile and install gs-1.4.x without modifying any poms 3) You copy the gt2-arcsde-2.2.3-SNAPSHOT.jar file into the gs-1.4.x/WEB-INF/lib folder 4) You copy the jsde_sdk jars into the gs/WEB-INF/lib folder RESULT: Any attempt to get data from the arcsde datastore results in a Caused by: java.lang.NoSuchFieldError: SE_OPTIMIZE at org.geotools.data.arcsde.ArcSDEQuery.createSeQueryForFetch(ArcSDEQuery.java:361) error. The current workaround is this: before starting step 1, change the plugins/arcsde/datastore/pom.xml file to NOT reference the dummy api, and INSTEAD reference the com.esri.jsde_jpe_sdk, com.esri.jsde_concurrent and com.esri.jsde_sdk poms from the maven.geotools.fr site. They'll download just fine, and then you can continue on and everything will work. I'll create a JIRA issue for this and figure out how to fix the dummy api so that this doesn't happen. --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] 2.3.x/ext/coverage_development/imageio/pom.xml still depends on gt2-referencing 2.3.0-RC1
Hey coverage guys, I had trouble building 2.3.x just now because the imageio pom.xml file was still referencing gt2-referencing-2.3.0-RC1-SNAPSHOT I updated it to 2.3.1-SNAPSHOT and everything built ok. Is there a reason for that, or is it just a bug from the 2.3.0 release? thanks! --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] What does a filter with a null geometry attribute name mean?
Hey all, So I hit the "query" button in mapbuilder to query a WFS layer on my local geoserver today, and it sent this query: ...request=GetFeature&typeName=myType&bbox=218275.63947042226,936408.9274414809,218278.7081292169,936411.9961368284 This blew up in the GeometryEncoderSDE. Basically, the encoder was looking for an expression with a left and a right, where one was the to-be-tested-against geometry, and the other was the propertyname describing which geometry to do the testing with from the feature. However, the above query generated a query that looked like this. filter: [ null intersects POLYGON ((my long polygon here)) To fix this, I just want to know if this is the way this request is "supposed" to be encoded (i.e., is this something that *should* be fixed in the GeometryEncoderSDE) or if this is something funky going on in geoserver/geotools parsing of the Filter XML into an internal Filter. I *think* (from an earlier set of emails) that this is the proper way that this filter should be encoded, and that it's up to the query encoder for each datastore to interpret "null" as the geometry attribute name for itself. I'll create a JIRA issue for this, since it's stopping mapbuilder from querying geoserver 1.5.x due to geotools 2.3.x. I've got a fix that I'll attach to the JIRA which solves the issue if indeed what I think is correct. Otherwise I'll do it whatever the right way is. Also, I assume this isn't an issue on trunk due to some disambiguation or another, but I'm mostly interested in what the fix should be for 2.3.x right now. Thanks! --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] What does a filter with a null geometry attribute name mean?
Ahh, so you mean that in the filterXML -> filterImpl parser you've used "getDefaultGeometry()" or something to parse this filter correctly for *all* datastores...not just leaving it to each to decide? How is this handled in SLD--where I leave the explicit geometry out of my rendering rules all the time? Any chance you can back-port your fix to 2.3.x, or tell me what class it was in so I can do so? thanks! --saul Justin Deoliveira wrote: > I just ran up against this in my wfs 1.1 work. And the answer i got from > the wfs spec gods is that if the only filter that is allowed to not > specify an attribute name is BBOX. All other filters must specify an > property name. > > Note however that on trunk this is fixed. A "null" property name is > interpreted as being the default geometry. > > -Justin > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] What does a filter with a null geometry attribute name mean?
Great! That means that this is just an inconsistency in the 2.3.x SDE api, and my "fix" (treating a null as the default geometry) is the right thing to do. In gt2-trunk, there's no problem, so my patch is only relevant to 2.2.x and 2.3.x. I'll update JIRA to reflect this so that the patch can get applied. --saul > > As far as I know in 2.2.x all datastore I've seen treat null geometry > as the default geometry in every occasion. > Are we sure we want to change this? > > Cheers > Andrea > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request commit access for Saul Farber
Rasters on SDE keep being my "next" priority. I've got it on my schedule to get rolling on it early next week. You'll know when I get started because of the flood of incredibly long emails to the list! --saul Simone Giannecchini wrote: > btw Saul, what about the arcsde raster plugin we talked about some > time ago? Do you have any news on that? > > Regards, > Simone. > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Trunk isn't headless?
Cory, I think you can use the "-Djava.awt.headless=true" flag on the JVM to simulate the java2d graphics environment. If you need something with a more complete java.awt.Graphics implementation, PJA (a pure java graphics environment with no need for an X11 server) is available. --saul Cory Horner wrote: > Hey guys, > > I'm fixing up our build box, and am seeing the trunk build failing with > the following... any thoughts? > > Thanks, > Cory. > > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request commit access for Saul Farber
Hmm...I can confirm receipt of emails, but having trouble confirming with a checkout. Is there a different SVN url for r/w checkouts of the gt tree? I tried the following, and it worked (which means something is wrong, right? My password isn't 'garbage' so it should have failed, no?) svn co http://gtsvn.refractions.net/geotools/branches/2.3.x --username=saul.farber --password=garbage Or does it just checkout anonymously to start, and then confirm your p/w when you try and commit? --saul Justin Deoliveira wrote: > Already done, Saul, can you confirm? > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request commit access for Saul Farber
Ok, then I'll confirm 90% right now, and confirm 100% that it works when I get a chance to commit something. --saul > > this latter, > --adrian >> --saul >> - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] ReTypeFeatureReader use
Hey all, I'm trying to fix InlineFeature support in Geoserver, and I tracked the problem down to a lack of CRS info on the created DataStore. Basically, the StreamingRenderer didn't know which CRS to use to render the inline-supplied data, so it didn't get rendered at all. Fixing up a few things to get the CRS to appear in the MemoryDataStore got everything working ok for those folks who declare the SRS on their inline features GML, but some folks don't do that. I figured it would be a nice default to assume that they mean their features to be in the SRS of the WMS bbox (i.e. the "target" SRS for rendering). So I set about trying to figure out how to take a MemoryDataStore that has a featuretype.DefaultGeometry.CRS == null, and re-make it into a MemoryDataStore that has a featuretype.DefaultGeometry.CRS == bboxcrs. Re-creating the featuretype was fairly easy (using the FeatureTypeBuilder), the problem was moving the features from the old store to the new. Here was my attempt: //Step 1 -- create a query to fetch all the features from the // old store Query q = new DefaultQuery(build.getName(), Filter.NONE); //Step 2 -- get a featurereader from the old store FeatureReader ilReader = ul.getInlineFeatureDatastore().getFeatureReader(q,Transaction.AUTO_COMMIT); //Step 3 -- fill the new store up with re-typed features? MemoryDataStore reTypedDS = new MemoryDataStore(new ReTypeFeatureReader(ilReader,newFeatureType)); Problem is that this fails in the ReTypeFeatureReader. It seems that the retypefeaturereader is really a "re-order" featureReader. I.e., it fails if, for example, the attributetype of "SHAPE" in the original featureType is different from the attributetype of "SHAPE" in the target featuretype. See line 104 in ReTypeFeatureReader. Is this by design? Is ReTypeFeatureReader really just meant to re-order elements in the featuretype? I just want to re-type from one compatible featureType (with a getDefaultGeometry() == null) to another (with a getDefaultGeometry() == something). --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ReTypeFeatureReader use
Ok, here's a re-thinking of this problem. ReTypeFeatureReader was really a "ReOrderFeatureReader" because it used the same "equals()" call to determine whether the featureTypes were really the same *and* to determine whether they were "compatible" or maybe "retype-able". So the question is, what sorts of similarities do two attributeTypes have to have to each other in order to be "ReType" compatible? Well, minimum: 1 they must have the same name (otherwise there's no way to create a mapping). 2 they need to have similar cardinalities. 3 their underlying types should be compatible I.e. newType.getType().isInstance(origType.getType()) should return true. 4 they should have the same 'nillability' I'm not totally sure about 2 and 4. This all came up because I decided to override "equals()" in the GeometricAttributeType class so that two GeometricAttributeTypes weren't the same if their CRS were different. This meant that my use of ReTypeFeatureReader was a non-reordering, type-compatible retyping, but used the same "equals()" call to determine whether the featuretypes were the same (they aren't) and whether they are compatible (they *are). Any thoughts on this? By the way, I got the list 1-4 from the code in DefaultAttributeType.equals(), which is what was being called currently. This just makes explicit what we're checking for when we mean "compatible". --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ReTypeFeatureReader use
Cool. Totally makes sense now. Feel a little stupid for reading "newType.numAtts() > oldType.numAtts" as "newType.numAtts() != oldType.numatts()" In any case, with a few fixes that I put into ReTypeFeatureReader, it does everything it used to do, and now covers a slightly more general case (of "casting" featureTypes, rather than just subsetting them). So now comes the dilemma: 1 Clearly the new FM solves my problem (re-creating a datastore with just a different GeometryAttributeType) 2 The new FM is not available to Geoserver right now, and without something that solves the #1, I can't do the nice thing that I want to do in Geoserver. So should I do all the gathering-up work to make this into a legit patch to 2.3.x so that I can fix inlinefeatures in geoserver? Or do I leave this one be and just have people be required to put an SRS on their inlinefeatures in wms requests? The touched files in geotools, by the way, are: module/main/src/org/geotools/styling/SLDInlineFeatureParser.java -- correctly determine the CRS when creating inline featuretypes, if that info is available (in the "srsName" attribute) module/main/src/org/geotools/feature/type/GeometricAttributeType.java -- override "equals()" to make two GeometricAttributeTypes which have different CRSs actually be unequal module/main/src/org/geotools/data/ReTypeFeatureReader.java check that 'casted' attributeTypes are compatible, rather than equal. Thoughts guys? I'd really like to see "kind" or "nice" support for inlinefeatures in geoserver, but I respect that there's not much love for fixing up and testing the old FM right now. --saul > > Which is to say in perhaps more clear terms that the primary purpsose of > the retype feature reader is actually _not_ to reorder elements, it's > more to return a limited subset of the properties. Since we didn't have > a way to say in the featureType that 'this attribute isn't requested' > (we had 'this is null', but not requested is a different thing), we just > made a new stub featureType on the fly... > > C > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Request commit access for Saul Farber
Done and done. Confirming that I can commit to the ArcSDE module. --saul Gabriel Roldán wrote: > How about applying http://jira.codehaus.org/browse/GEOT-1025 on 2.3 and trunk > yourself? > > btw, welcome and god bless you for helping with this beast :) > > Gabriel > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] ReTypeFeatureReader use
But of course! This was really three bugs all rolled up into one, so I created three jiras, and attached testcases to two of them. ReTypeFeatureReaderTest is the one that addresses this thread. See http://jira.codehaus.org/browse/GEOT-1080 --saul Jody Garnett wrote: > Saul we must limp before we can run ... bring on the patch. The test > cases will be useful during the switch to the new FM (you do have test > cases as part of your patch ;-) ). > > Jody > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] FeatureType equality (and troubles in JDBC land)
Andrea, I bumped against the ReTypeFeatureReader and FeatureType equality recently. I don't think my issues were quite as general as yours are, but here's what I came up with: http://jira.codehaus.org/browse/GEOT-1080 and http://jira.codehaus.org/browse/GEOT-1081 Here's the nabble thread: http://www.nabble.com/ReTypeFeatureReader-use-tf2861074.html#a7994674 Also see my take on your questions inline: > First thing is, why are there two ways to compare FeatureTypes for > equality? > The first one is FeatureType.equals(xxx), the second one is > DataUtilities.compare(ft1, ft2). > Some places use the first, others the second, maybe in the same > algorithm (bad idea...). Yeah, no good if they do the same thing. > Second, why DefaultAttributeType.equals(...) does not take into > account the restriction when evaluating equality? Equality between AttributeTypes seems to be only partially implemented. Probably just to support some specific functionality. As seen in my JIRA issue above, I found a case where two GeometricAttributeTypes with different CRS's were being considered equal. Probably noone had run into the issue before. > > Finally, the bug. If I invoke getFeatureReader(FeatureType > requestedType, Filter filter, Transaction t) on a JDBC data store > and requestedType is a subset of the datastore's schema, I'm > guaranteed to get an exception from the ReTypeFeatureReader, > since the method builds a query that already extracts the > requested attributes but... there is a but in my opinion. > > What if the requested type had different restrictions on attributes? > Would it be ok to return a feature reader sporting a feature type > that's different (restrictions wise) from the one requested? > Depending on the application, the answer may well be no, because > the coder expects restrictions to operate on the returned features > as requested, no? See the other JIRA issue above. I think "ReType" is a bad name for the "ReTypeFeatureReader". Maybe "SubsetFeatureReader" or something. It's not really re-typing features, it's just returning a subset of their (flat) attributes. I *think*! --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] FeatureType equality (and troubles in JDBC land)
Oh yeah, if you work out your issues on this by applying changes to ReTypeFeatureReader and DefaultAttributeType.equals(), can you also take a look at the patches attached to my JIRA issues and see if you can work them in too? thanks much! --saul Andrea Aime wrote: > Hi all, > I have a few questions about a bug I've spotted in JDBC land. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] FeatureType equality (and troubles in JDBC land)
> > Sure I can, but before I would like to have feedback from other people too. > I've been away from Geotools quite a bit of time and some things changed > in my absence, so I fear breaking stuff. Makes perfect sense to me. I figure if I bring it to your attention when you're also digging into the same code, I have a better chance of getting some quality review-time from more people. > Anyways, my new policy is, ask, then if nobody complain, do. If nobody > answers this before January 15 I'll do the changes (ok, that's a lot > of time, the trouble is, these day many people may be away in vacation). > > Oh, if I forget, send me a reminder :-) Will-do. - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Using ImageIO via JAI (vs. directly)
Hey Simone,
I've read through the ArcGrid raster example as well as other
documentation, and I'm pretty clear on why and how to create an ImageIO
plugin. It'll take a little "stretching" of the traditional semantics
of the model to make it fit pulling images from a database, but it seems
that the API was largely designed to do this.
My one question is about this line in ArcGridReader.java:
RenderedOp asciiCoverage = JAI.create("ImageRead", pbjImageRead, hints);
I understand what this does, but I'm just curious as to why you decided
to do it *this* way. Couldn't you have just as easily called this
(assuming that you'd created an appropriate ImageReadParam object)?
readerSPI.createReaderInstance().read(imageIndex, param);
Is that one "JAI" line the "JAI special sauce" that links the whole
thing into the wacky world of JAI? Is that the line that gives you
cached image tiles, stream-able PlanarImages and all the other JAI
goodness that you mentioned in our breakout a while ago (link below)?
http://docs.codehaus.org/display/GEOS/2006/07/27/Breakout+Coverage+Plugin+IRC+meeting+7-27-2006
Not that this really changes any implementation details for me, just
curious about that bit.
Thanks,
--saul
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Long-lived ImageReaders
Hey simone, (ccing geotools-devel for posterity) Quick question: when we chatted earlier I said that I was creating "short-lived" ImageReaders (err, ArcSDE raster ImageReader subclasses) and throwing them away from request to request, but in order to do that I'm discarding the ability of the ImageIO api to have a reader with multiple images inside it. In addition, each time I create a reader I have to pass in a bunch of information over and over again, and in the end it's creating the exact same ImageReader object over and over again, just calling it with different read() parameters. Is there a particular reason not to create the ImageReader (subclass) once, and just use it over and over again within a JAI.create() call each time? In the end it'd be something like this: One ArcSDEGridCoverageReader per ArcSDE raster "source" (multi-leveled, pyramided, tiled image) as created and cached by geoserver. One ArcSDEImageReader per ArcSDEGridCoverageReader (as created and cached by the initial ArcSDEGridCoverageReader) One PlanarImage created from the above ImageReader per image request. I guess I just need to make sure that my ImageReader is threadsafe, as someone could make two requests simultaneously and I'd need to make sure that the read() method in my ImageReader could be called twice at the same time. Or is there stuff in the abstract ImageReader parent class that is inherently not threadsafe such that I should avoid this approach? --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Long-lived ImageReaders
Jody Garnett wrote: > Saul this API (ImageReaders) kind of is what you want to make it to be; Not quite sure what you mean here...do you mean that the javax.imageio.ImageReader class (the ImageReader I'm referring to below) is an open-ended enough API that one can write a new ImageIO plugin (an ImageReader subclass) in any number of ways? Or do you mean that the API as defined in modules/coverage (I think you referred to it as GCE below) is open-ended enough that making a new reader/format is kind-of amorphous? > > I have proposed an alternative DataAccess thing with an eye towards > rasters, but currently most applications are skipping GCE and making new > Formats directly. I would personally try and stuff as much information > into the Format as possible and then create a Reader as needed. What do you mean when you say "skipping GCE"? I'm not sure I know what GCE is if it's not the creation of a Format, Factory and Reader (by extending AbstractGridFormat, AGFFactory and AbstractGridCoverage2DReader). Is there another way of creating a coverage plugin? Is that GCE? As for "create a reader as needed" I'm a little confused by that. It could mean: 1) "create a concrete subclass of AbstractGridCoverage2DReader as needed" I'm not sure I get to make a call on this, as geoserver simply creates one GridCoverageReader for each configured coverage and then calls "read(extent, imagesize)" each time it wants a coverage image. I don't really get to choose when to create a GridCoverageReader, I just have to return a "long-lived" one. 2) "create a concrete subclass of javax.imageio.ImageReader as needed" This is one I get to make a call on, but I'd really like (for simplicity's and sanity's sake!) to make exactly one of these for each AbstractGridCoverage2DReader that's created. The question is whether there's something in the superclass that would prevent me from doing this...since AbstractGridCoverage2DReader is threadsafe (and commonly called from a multi-threaded context) then this would mean that my javax.imageio.ImageReader subclass would need to be threadsafe as well. I can guarantee this within my OWN javax.imageio.ImageReader.read() method but I can't necessarily guarantee it within the general ImageReader class. The javadocs caution USERS of ImageReader plugins to not assume that a given ImageReader is threadsafe, but as I'm implementing my own and I know that *my* code is threadsafe...I wonder if I can assume that I'm allowed to use my own object in a threaded context. Hmm...I'm not sure I could have explained #2 in a more complicated way, but hopefully it got through! > > For the information that varies *all* the time we should make sure that > that is passed in as an object (or array of objects) to your read method. I hadn't realized there was more than one way of creating a raster plugin to geotools, but just to clarify, I was really asking about implementation strategies as they concern the (confusingly similarly named!) javax.imageio.ImageReader and javax.imageio.spi.ImageReaderSpi and their interaction with the JAI imageio->PlanarImage operator "ImageRead". My question was really about imageio and JAI, not so much geotools So are we talking about the same thing? Thanks jody! --saul > Jody > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Long-lived ImageReaders
Jody Garnett wrote: > Saul Farber wrote: >> Jody Garnett wrote: >>> Saul this API (ImageReaders) kind of is what you want to make it to be; >> Or do you mean that the API as defined in modules/coverage (I think >> you referred to it as GCE below) is open-ended enough that making a >> new reader/format is kind-of amorphous? > I was meaning that the GeoTools code here does not really have champion; > so if you want to lock things down to the point you can reuse your > readers then I am pretty sure everyone will be open to the idea. Cool this all makes more sense then. So far the geotools interfaces/APIs make total sense to me and the only changing that needs to be done is up in Geoserver land. > Right now people often skip the GridCoverageExchange class and go right > to the factory (or even implementations). I think our source code > examples show this technique in use. Yeah, I'm just basically copying the ArcGrid reader. it's very cleanly documented and used. > I was thinking of GridCoverageReader - this method takes an object > defining the source: > - > http://javadoc.geotools.fr/2.3/org/geotools/data/coverage/grid/file/FileSystemGridCoverageExchange.html#getReader(java.lang.Object) > > That object can be an array if you have a bunch of stuff you set all the > time Exactly. This is exactly what I'm doing now...the only change is that geoserver needs to allow storing the source as something other than a String. But this is exactly what I do right now. > > You can then reserve the read method for the things that only very on > each call: > - > http://javadoc.geotools.fr/2.3/org/geotools/gce/geotiff/GeoTiffReader.html#read(org.opengis.parameter.GeneralParameterValue[]) > And this is what geoserver does, exactly. Calls read with the things that change (requested image size, requested image extent) each time. > I am going to have to bow out here as I am too far away from the details > to be useful. > Jody You're more than useful, you've give me great confidence that I'm on the right path! Sorry about the confusion between "Reader" and "Reader". It's a killer! --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Any chance of an IRC chat tomorrow sometime?
I've got some questions (hopefully quick!) about Category and GridSampleDimension. Specifically about how I should create categories for a stored photo...it's both geophysics (as in it is actually what's on the ground) and it's the true sample values (as in it's actually what's in the coverage). Somehow I'm getting a problem converting from one to the other when the RasterSupport.recolor() method is called. If you're busy (seems like everyone's got you in their sights right now!) that's cool. I'll figure it out eventually! thanks, --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Any chance of an IRC chat tomorrow sometime?
Hrm. Perhaps that email would have been more clear if I'd have explicitly addressed it to Simone G. For clarification, I meant is there any chance of a quick chat with Simone...or anyone else who can fill me in on Category, GridSampleDimension and getting coverages rendered correctly by the GridCoverageRenderer! sorry for any confusion. --saul Saul Farber wrote: > I've got some questions (hopefully quick!) about Category and > GridSampleDimension. Specifically about how I should create categories > for a stored photo...it's both geophysics (as in it is actually what's > on the ground) and it's the true sample values (as in it's actually > what's in the coverage). > > Somehow I'm getting a problem converting from one to the other when the > RasterSupport.recolor() method is called. > > If you're busy (seems like everyone's got you in their sights right > now!) that's cool. I'll figure it out eventually! > > thanks, > --saul > - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] udig trunk on trunk finding problems as grid coverage reader support changes?
Jody, I think it's well understood that having most of the good coverage support/work on 2.3.x is unideal right now, but I'm surprised that you're just coming across this issue for the first time right now. As I understand it Simone and Alessio targeted 2.3.x back when 2.4.x was still a gleam in the PMC's eyes. There was a 1.4.x_merge_wcs geoserver branch which became GS 1.5.x which has always targeted 2.3.x. I have to admit I wasn't paying full attention to the gt branches right then, but I think 1.4.x peeled off (leaving gs-trunk/1.5.x as a WCS version) right about the time that 2.3.x peeled off of gt-trunk (leaving gt-trunk/2.4.x as a not-targeted-by-any-geoserver version). In any case, I'm sure everyone would love it if the 2.3.x coverage work moved forward to trunk, but since most of the coverage work is motivated by having raster data available through geoserver, we're stuck at 2.3.x till gs-trunk-on-trunk comes around and is stable enough to deploy. All of which is to state my opinion on two things: 1) Having all the GCE work targeting 2.3.x is unideal, but the only currently workable solution for those interested in actually serving raster data through geoserver. 2) Moving the GCE work to gt-trunk is necessary, but blocks on a *usable* gs-trunk-on-trunk and the time to port the GCE work to 2.4.x. --saul Jody Garnett wrote: > The goal here is to make sure trunk is stable (and suitable); if there > is a tone of changes and improvements lurking on 2.3.x then we have a > different set of troubles ... > Cheers, > Jody - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] commons-collections version
Justin, > Gabriel: Is it an option to upgrade the commons-pool library to 1.3? I've bumped against the commons-pool-in-arcsde code lately (refactoring ArcSDE pooling for ArcSDE GCE support) and I didn't think there would be any problem with upgrading to commons-pool-1.3. So I did it (changed the local pom.xml version reference in my 2.3.x checkout) and rebuilt gt2 and geoserver-1.5.x. Everything worked fine with the rebuild using commons-pool-1.3, and from my recent brush against the code, that makes sense. So I'd say that it's safe to upgrade to 1.3, but I'd definitely love to hear Gabriel confirm that for sure! --saul - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
