[Geotools-devel] (no subject)
Martin Desruisseaux wrote: [EMAIL PROTECTED] a écrit : Okay, its there now. I had awful problem moving the changes from 2.2.x to trunk. Thanks, it seems to compile file now. I noticed the addition of the following dependency: import EDU.oswego.cs.dl.util.concurrent.ConcurrentHashMap; Is it appropriate if I had the following comment? // TODO: replace by java.util.concurrent.ConcurrentHashMap // when we will be allowed to target J2SE 1.5. I dont know anything about this -- where is it used? dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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=lnkkid0709bid3057dat1642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Alessio Fabiani wrote: Hi all, this would be nice for me: http://timeanddate.com/worldclock/fixedtime.html?day=1month=5year=2006hour=22min=0sec=0p1=37 This sounds like a good time for me (monday 1:00pm). I'll be back in vancouver. If its easier for martin to attend, we could move it forward or back by 1/2 (or a whole) hour. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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=lnkkid=120709bid=263057dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] (no subject)
Martin Desruisseaux wrote: gt/module/render/src/org/geotools/renderer/lite/LiteShape2.java:[62,16] cannot find symbol symbol : class LineIterator2 location: class org.geotools.renderer.lite.LiteShape2 Okay, its there now. I had awful problem moving the changes from 2.2.x to trunk. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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=lnkkid=120709bid=263057dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-832) shapefile -- cannot build
shapefile -- cannot build -- Key: GEOT-832 URL: http://jira.codehaus.org/browse/GEOT-832 Project: GeoTools Type: Bug Components: shapefile Environment: xp/laptop (slow HD) Reporter: dblasby Assigned to: Ian Wolfe Schneider Priority: Blocker maven jar:install or mvn install in plugin/shapefile causes the following exception in org.geotools.data.shapefile.ShapefileReadWriteTest: Testcase: testConcurrentReadWrite(org.geotools.data.shapefile.ShapefileReadWriteTest): Caused an ERROR C:\DOCUME~1\DAVIDB~1\LOCALS~1\Temp\test-shp39360.prj (The requested operation cannot be performed on a file with a user-mapped section open) java.io.FileNotFoundException: C:\DOCUME~1\DAVIDB~1\LOCALS~1\Temp\test-shp39360.prj (The requested operation cannot be performed on a file with a user-mapped section open) at java.io.FileOutputStream.open(Native Method) at java.io.FileOutputStream.init(FileOutputStream.java:179) at java.io.FileOutputStream.init(FileOutputStream.java:131) at org.geotools.data.shapefile.ShapefileDataStore.copyAndDelete(ShapefileDataStore.java:1109) at org.geotools.data.shapefile.ShapefileDataStore.createSchema(ShapefileDataStore.java:802) at org.geotools.data.shapefile.ShapefileReadWriteTest.test(ShapefileReadWriteTest.java:174) at org.geotools.data.shapefile.ShapefileReadWriteTest.test(ShapefileReadWriteTest.java:152) at org.geotools.data.shapefile.ShapefileReadWriteTest.testConcurrentReadWrite(ShapefileReadWriteTest.java:132) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] org.geotools.filter.function
Cool, I just need to make a simple mod to the template. #getValue() on the filter/expression api has been deprecated so I need to chagne over to the correct method. Okay, should be easy then - let me know if there's anything confusing there. While you are looking there - jody made a request to change the name of the generated class files. They're currently all of the form FilterFunction_intersection and jody didnt like the _ in the filename/classname. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Moving to TOPP confluence (Geoserver and Geotools)
TOPP is likely getting a confluence license and setting up a machine to run it. I was thinking of moving the Geoserver wiki over to it. The codehaus confluence (where its hosted currently) is kinda slow and I find it difficult/frustrating to edit (or read) pages due to the lag. Hosting it ourselves will speed this up and hopefully encourage people to document. We're more than willing to also put Geotools on it and, because geoserver and geotools share a lot of documentation, it makes sense to keep them together. I was think we should continue having JIRA and SVN on codehaus, and only move the wikis over. The wiki's have an export/import command so this shouldnt be an issue. What do you think? dave ps. Jody -- you put udig on its own confluence so I'd like to hear your experience. -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] 2.2.x not building (shapefile)
This is a bit of a pain It passes fine on my windows box. I think it is a configuration dependent or maybe speed dependent. I will see if I can recreate the issue. I'm running on a Windows XP Laptop, which means the hard disk is a bit slow. Perhaps try copying a large set of files while running the tests? dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Geotools 2.2.x -- new stable branch?
I've been talking to several people about the 2.2.x branch and the 2.3 trunk. From what I've managed to gather, it appears that most of the big changes are happening on branches and will be (very soon) merging in trunk. These merge-ins will be the 2.3 release. Soon after that - I'm sure - development for 2.4 will start. The consensus seems to be about 6 months before you can really trust 2.3. I am looking forward to it coming together and being solid. The 2.2.x branch was started a little while ago. There wasn't any real fan-fare to it - the announcement was I took the liberty of creating the 2.2.x branch.. I was skeptical about its trustworthiness, but after putting several people several people under the Bright White Light, they all said that its good. I know that myself (and others) spent a lot of time moving all the 2.1.x fixes forward to trunk so they would be in this release. Apparently, not much has happened on 2.2.x (the old trunk) in the last few months except bug fixes. The people using it seem to all think its good (if anyone disagrees - please speak up). I've also seen several people (including myself) concerned about API shifts and lack of maintenance. So, why don't we setup a new stable branch? Currently, the stable branch is 2.1.x. I'd like to see a place where we can continue improvements where we're not getting our toes stepped on. So, I'm proposing making 2.2.x the 'official' stable branch. I think this just requires getting an official consensus, but I think we just need to define what we mean by the 'official stable branch.' Here's some ideas: 1. have a big advertisement on the geotools front page that announces 2.2.x as the 'official stable branch' 2. encourage (especially new) users to use the official stable branch 3. encourage users to report bugs against this version 4. encourage users to submit patches against this version 5. recommend people who need to make more substantive changes to use the unstable (2.3) version and warn them of the implications. This means the 'official stable branch' isn't something we create and then immediately forget about - its 'supported'. The most controversial points will be what changes are allowed to take place on the stable branch? Obviously things like changing the feature model isn't in scope for the stable branch, but I'd still like to see people able to add/fix things. The plan would be to keep the 2.2.x branch the stable branch until 2.3 is solid and ready to be the new stable. The biggest problem is going to be moving changes on the 2.2.x branch forward to trunk. This was extremely difficult with 2.1.x, and I'm betting its going to be quite difficult with 2.2-2.3. But, I think the 2.3 changes are going to be focused enough that we can really work on improving a lot of places around the edges. I think we should really define where the changes are taking place on 2.3 so we don't step on each other. With a few rules and good communication, I think we can minimize the pain of moving the changes forward. What think? If geotools does make 2.2.x the 'new official stable branch' then I'm willing to put the time into make a Geoserver 1.3.0-Experimental release for people to test the current geoserver with the new geotools stable branch. Once we've had a few people give it a good kick and done some in-depth testing (and they all give two thumbs up), we'll make that the new Geoserver trunk (then start looking at the geoserver 1.4.x changes). (This is, assuming (confirmed by a few people), that most of the 2.1.x-2.2.x changes are 'syntactical' as opposed to 'conceptual'.) I'm quite worried that if geotools doesn't have a supported stable branch that we're going to get ourselves in trouble. I also think that having official stability will encourage new users, bug reports, bug fixes, and documentation. We really need that! Dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Looking for 19107 implementation
Dont know much (basically nothing) about these guys, but it appears they are doing a 19107 implementation. http://oxygene-project.sourceforge.net/ dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Re: [Geoserver-devel] Postgis + WKB4J
No, and I think it _should_ be using the modified jar. It contains a few needed fixes, and the maintainer of the wkb4j stuff has disappeared. JTS has a WKB parser in it (i think since 1.6) -- might be worth switching to it as its actually being maintained. Check out JTS's io package. Apparently there is an Oracle SDO STRUCT parser in JTS 1.7 too. And you MUST use the modified WKB4J jar -- the offical WKB4J converts all your coordinates to floats (instead of keeping them as doubles). dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] trunk -- gridcoveragerenderering
I've been trying to figure out why the trunk build is failing for me. The GridCoverageRenderingTests are failing. It seems to be caused by Do not know how to deep copy the org.geotools.coverage.grid.GridCoverage2D in DefaultAttributeType#duplicate(). I also noticed that the raster symbolizer style ignores the geometry name property. The default style has geom as the name, but the code always looks for grid. I just made changes that changed the order of querying a bit in the StreamingRenderer so that it can optimize. I dont think this would have broken the Grid rendering stuff (I debugged and everything looks good). dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] So, have we given up maintaining 2.1.x??
I'm still trying to improve the rendering style stuff, but I'm finding that there are so many API differences (and people running automatic code style programs) between 2.1.x and trunk that I'm spending almost all my time moving changes over. I mean, it takes significantly longer to move the changes over than it takes to actually do the changes in the first place. The truth of the matter is that I really dont want to make any improvements anymore because its just too painful. I thought the entire idea behind the streaming rendering was that we would keep 2.1.x aligned with trunk. REMEMBER - EVERY API CHANGE YOU MAKE MEANS I HAVE TO SPEND SEVERAL HOURS OF WORK ALIGNING THINGS. Plus more hours keeping changes aligning for every future change too. Should we: 1. just say ha ha - fooled you for the people doing rendering (and other modules) on 2.1.x. This pretty much means we're calling 2.1.x a fork. 2. Actually try to announce, vote, and transition API changes. 3. insert your 3rd option dave PS. And *please* don't auto-format code anymore! -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [Geoserver-devel] how does geoserver handle time zones?
There are known issues with time/date in geotools. I've attached your comment to: http://jira.codehaus.org/browse/GEOS-378 Basically, the way geotools handles date/time attributes is a bit 'weak'. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Jalopy and headers
Jody, I'm not sure what you're saying, but running jalopy (or anything that mangles the code) isnt a very good idea. Running Jalopy kills history -- and makes branch-to-branch maintainance difficult. I had to waste a good chunk of a day merging changes in StreamingRenderer.java from 2.1.x to trunk (and back) because someone ran something that changed almost every line of code in the class. Chris ran jalopy on something in Geoserver and I just gave up trying to figure out what had changed (unfortunately his jalopy commit also had code changes in it). I'm FIRMLY -1 ; unless someone can argue that those two applications of jalopy-like stuff will actually save more than a days of someone's time (+ extra time for how frustrating futile it is to sort through 10,000 changes). And this is *just* one java file. Running it for 3,000 files better save 10 people years! dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [Geoserver-devel] Re: data dir
If you look in src\org\vfny\geoserver\util\SLDValidator.java line about 180, you'll see: File schemaFile = new File(GeoserverDataDirectory .getGeoserverDataDirectory(servContext), /data/capabilities/sld/GetMap.xsd); which would explain why its not finding the schema files! If you're interested in how the schema validation workings, head down to line 210 and you'll see the main function. The only thing intestesting in the whole file are these lines: parser.setFeature(http://xml.org/sax/features/validation;, true); parser.setFeature(http://apache.org/xml/features/validation/schema;, true); parser.setFeature(http://apache.org/xml/features/validation/schema-full-checking;, false); parser.setProperty(http://apache.org/xml/properties/schema/external-noNamespaceSchemaLocation;, SchemaUrl); parser.setProperty(http://apache.org/xml/properties/schema/external-schemaLocation;, http://www.opengis.net/sld + SchemaUrl); These lines: 1. tell the parser to validate the XML document vs the schema 2. does not validate the schema (the GML schema is *not* valid. This is an OGC blunder) 3. tells the validator that the tags without a namespace are actually SLD tags. 4. tells the validator to 'override' the SLD schema that a user may include with the one inside geoserver. -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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://ads.osdn.com/?ad_id=7637alloc_id=16865op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] StreamingRenderer -- requests too many geom columns (+style visitor)
I noticed that the lite/streaming renderer makes some bad assumptions when you try to render a feature type with multiple geometries in it. For example, I have a Postgis database with 261 rows (one for each country in the world). It has 4 geometry columns in it, one for varying degrees of generalization: gen_full -- ungeneralized data (81mb) gen1 -- 25mb gen2 -- 10mb gen3 -- 2mb I then choose which geometry column by using MinScaleDenominator/MaxScaleDenominator in my SLD file. So far, everything is great. But, Geotools makes a little boo-boo in Lite/StreamRenderer#findStyleAttributes(). It adds ALL the geometry columns (and GRID columns) to the list of requested attributes. The JDBC driver pre-fetches 200 rows, so I get an out-of-memory error even though I'm only rendering about 2mb of data! NOTE: 200 rows is basically the entire dataset, so its loading about 81+25+10+2 megs = 128 megs of data! Here's the code comment on this: /* * GR: if as result of sae.getAttributeNames() ftsAttributes already contains geometry * attribue names, they gets duplicated, wich produces an error in AbstracDatastore when * trying to create a derivate FeatureType. So I'll add the default geometry only if it is * not already present, but: should all the geometric attributes be added by default? I will * add them, but don't really know what's the expected behavior */ ... //ALX: For rasters I need even the grid attribute. The reason this was done was because, in SLD, you dont have to explicity declare a reference to the default geometry. For example, this symbolizer has an 'invisible' reference to the default geometry: PolygonSymbolizer Fill ... /Fill /PolygonSymbolizer This one has a direct reference to a geometry (could be the default geometry, could be a secondary geometry): PolygonSymbolizer GeometryPropertyNamemygeometry/PropertyName/Geometry Fill ... /Fill /PolygonSymbolizer I imagine there is a 'default' GRID-geometry for the RasterSymbolizer too. A simple way of dealing with is to have the style visitor have a flag for defaultGeometryUsed and defaultGridUsed. Then, instead of adding all geometrygrid types to the Query we only add the explicitly referenced ones (Geometry.../Geometry) and add in the default Geometry Grid property if (1) it wasnt already explicitly referenced and (2) the appropriate flag was set in the style visiting. This will cut down the Query so its only pulling in geometry/grid columns that it explictly needs. I dont think this will affect anyone - but someone could have code that relies on this incorrect behavior. Any code that does this should just make the style visitor know about their invisible need of a column. IS THIS GOING TO AFFECT ANYONE? dave PS. Has anyone investigated what happens if you're not using the default geometry, and you require coordinate reprojection? -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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=7628alloc_id=16845op=click ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] SVN problems?
Okay, Chris Holmes seemed to have this problem in Zambia. Its apparently because the ISP's squid configuration isnt correct (or, more accurately, the default squid config is wrong). The Geoserver one is working because its svn://... instead of http://. http://subversion.tigris.org/faq.html What if I'm behind a proxy? dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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] SVN problems?
I'm trying to work with the SVN archive now that its back, but I keep getting problems: update -r HEAD C:/eclipse/workspace/trunk RA layer request failed svn: REPORT request failed on '/!svn/vcc/default' svn: The REPORT request returned invalid XML in the response: XML parse error at line 1: mismatched tag (/!svn/vcc/default) update -r HEAD C:/eclipse/workspace/g2_2_1_x RA layer request failed svn: REPORT request failed on '/!svn/vcc/default' svn: The REPORT request returned invalid XML in the response: XML parse error at line 1: mismatched tag (/!svn/vcc/default) Is there something wrong with the SVN repository? I'm not having any problems with the geoserver SVN (on codehaus). I'm using the latest version of subclipe. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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: [Geotools-gt2-users] Styling external graphic based on feature attribute
Anybody had a chance to formulate an answer to this one yet? .. In other words, the graphic that should be used to render the feature would be something like http://somehost/somepath?id=fid Unfortunately, the SLD spec does not allow for this - it only allows for a simple xlink:simpleLink instead of one that you could build up. You could, however, modify the SLD parser and renderers to do something like this; it would be a medium-difficulty thing to do this. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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] trunk -- referencing-2.2.x.jar download problem
When I try to build main, I get this error: -- C:\eclipse\WORKSP~1\trunk\gt\module\mainmaven jar:install __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.2 Attempting to download referencing-2.2.x.jar. WARNING: Failed to download referencing-2.2.x.jar. The build cannot continue because of the following unsatisfied dependency: referencing-2.2.x.jar Total time: 10 seconds Finished at: Thu Oct 20 00:37:58 PDT 2005 - Is this something to do with me or are other having this problem? This is a brand new checkout of trunk. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] PostGIS features issue
Alessio, I fixed GEOT-734 (this issue) on branch and trunk. I'm unable to compile trunk at the moment, but it should be working... Could you check to make sure its working for you? dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] trunk -- referencing-2.2.x.jar download problem
I figured this out - I just had to do a full build. Silly me. I was just confused when it said that it had problems downloading something when it meant I needed to build it... dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Postgis test take 10 minutes!! (PostgisDataStoreAPIOnlineTest)
James/Paul, Does the auto-testing (ie. paul's nightly build and james' on-commit testing) do the full test? I just want to make sure that the test are actually being run somewhere! I just changed one line of the postgis driver (to put quotes around a column name), and it took over an hour to run the tests. I pay for the internet by the minute!! dave ps. I'm in thailand, but my internet connections is reasonable - usually 20k/s, but with high latency. Martin said it took him 20 minutes. -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-733) shapefile -- multiple transactions corrupt
shapefile -- multiple transactions corrupt -- Key: GEOT-733 URL: http://jira.codehaus.org/browse/GEOT-733 Project: GeoTools Type: Bug Components: shapefile Reporter: dblasby Assigned to: Ian Wolfe Schneider [EMAIL PROTECTED]: My question is how will they scale with multiple users? I wanted to deploy using the shapefile configured GeoServer, but I started noticing problems when using it with multiple clients. Sometimes a shapefile would get corrupted and contain duplicate entries. The main advantage to using this configuration is that it is easier to distribute. If I went with PostGIS, I would need to do some remote administration, which is difficult for this application. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] Re: [Geoserver-users] shapefiles getting corrupted
This is obviously a *BIG* problem if shapefiles are no longer transactionally safe. I setup a geotools bug: http://jira.codehaus.org/browse/GEOT-733 dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [Geoserver-devel] PostGIS features issue
Looks like the postgis datastore fid-mapper isnt quoting its column names. I made this bug report: http://jira.codehaus.org/browse/GEOT-734 I'll take a quick look at it. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] SLDStyleFactory TextStyle2D -- issues
I was attempting to write documentation for label placement (plus fix all the inconsistencies with the spec), and I noticed some problems with the SLDStyleFactory and TextStyle2D. It turns out the SLDStyleFactory is actually trying to do [poor] label placement (see around line 570)! This also results in a loss of information if you're using a LinePlacement element in your SLD. 1. remove the placement code from SLDStyleFactory! 2. get rid of the AbsoluteLineDisplacement stuff and replace it with something that represents PointPlacement/LinePlacement elements in the TextSymbolizer. The current implementation seems to try to convert a LinePlacement and an actual line into a PointPlacement (and setting the AbsoluteLineDisplacement flag)!! This should be done by the real labeling code. This change could affect the j2d renderer as it appears to use the AbsoluteLineDisplacement flag. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [udig-devel] Re: Proposals: Topology
I think Martin Davis (JTS) is wanting to add a bunch of coverage topology operations to JTS/JCS/JUMP. There's already a some in JCS (Java Conflation Suite) and JUMP. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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] LiteRenderer questions.
Alessio, I dont know anything about the Raster stuff, but you should be using StreamingRenderer instead of LiteRenderer. There's only a few minor differences between StreamingRenderer and LiteRenderer. StreamingRenderer is the new LiteRenderer, and is the one that people in the future will be maintaining. Switching over to it should be almost trivial. See the documentation at the top of lite.Renderer.java or GTRenderer.java interfaces. dave -- This mail sent through IMP: https://webmail.limegroup.com/ --- 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
