We should return to the list on this one; I just sent private emails
yesterday in order not to annoy the list with a patch. If I was not so
sleepy i would of attached it to a JIRA (do we have a JIRA?).
Update for the list: We have made some progress with policing the
internal construction of a UR
Hi Martin, Hi Justin,
Thanks for reply! I would prefer the way to extend the Element class with an
pullOptionalString method analogous to the pullOptionalElement one. I created a
patch for the two classes : Element and Parser itself. I guess for further
discussion we should comment the issue (i
ParserException in AUTHORITHY element if code is not annotated
--
Key: GEOT-2578
URL: http://jira.codehaus.org/browse/GEOT-2578
Project: GeoTools
Issue Type: Bug
Component
+0 from me once again
Michael
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Move support for xlink from jdbc-ng/h2 to app schema
Key: GEOT-2577
URL: http://jira.codehaus.org/browse/GEOT-2577
Project: GeoTools
Issue Type: Improvement
Components: data jdbc
Hi Emily,
Emily Gouge wrote:
> Thanks for the info Justin. (Sorry I'm slow getting back to you; I was
> away last week).
>
> If I work at implementing this can I bug you for help and ask you to
> review the work as I go along? I'm sure I'll need some advice on how to
> do things properly.
Ye
Agreed on making the parser more lax. I can think of a different couple
of ways to patch it though. One would be to have a fallback like:
final String code = null;
try {
code = element.pullString("code");
}
catch( ParseException e ) {
code = element.pullInteger("code")
}
However to make
It extracts a database into your temp directory; if you are in a high
security sandbox you (such as an applet) you may need to use the
epsg-wkt plugin instead. Details on this choice in the user guide.
Jody
On Tue, Jun 30, 2009 at 5:30 AM, Alexander
Weidauer wrote:
> -BEGIN PGP SIGNED MESSAGE
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear List,
I use geotools 2.5.5 under Suse Linux 10.2 64Bit and within the netbeans
IDE.
I try to get a simple code running, but always get errors by
initialization the epsg system.
1. Is there a explanation how this mechanism works inside of geotoo
Thanks for the info Justin. (Sorry I'm slow getting back to you; I was
away last week).
If I work at implementing this can I bug you for help and ask you to
review the work as I go along? I'm sure I'll need some advice on how to
do things properly.
Lastly - how do we define a "Safe Conversio
Have eclipse put its class files on its own directory instead of the default
maven one
--
Key: GEOT-2576
URL: http://jira.codehaus.org/browse/GEOT-2576
Project: GeoTo
Hello Martin
sounds good in to accept the two different "coding" styles for the authority
parameter. Would you change the Parser code or should i create an issue an
attach a patch? Thanks so far,
Frank
>
> Frank Gasdorf a écrit :
> > But I got a ParseExcpetion for the AUTHORITY Parameter:
> >
All tests pass; the evil the evil.
Michael I will try and send you a patch; it is not pretty but it
works. If you like it you can commit it tomorrow.
Jody
On Tue, Jun 30, 2009 at 1:39 AM, Jody Garnett wrote:
> Okay so I have started being able to patch these problems (and am
> getting more test
Okay so I have started being able to patch these problems (and am
getting more test cases to pass):
1. file.toURI()
2. check result; if it contains "+" symbols; unpack; replace; repack into URI
3. change to URL
I am going to wrap this up in a DataUtilities method; this method
should later take int
Bug to fix file.toURL() - not fixed
- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4273532
Bug to deprecate file.toURL() with replacement file.toURI().toURL()
- http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6179468
So what is left? File.toURI().toURL() does not handle the wacka wacka
Justin Deoliveira ha scritto:
> I can think of one minor downside. At times I run across errors when
> building with maven, but not with eclipse. But debugging the problem is
> hard because it involves firing up a remote debug session.
Setting up a remote debug session is not that hard nowadays,
I can think of one minor downside. At times I run across errors when
building with maven, but not with eclipse. But debugging the problem is
hard because it involves firing up a remote debug session.
However sometimes what i do is compile with maven, and then directly run
with eclipse without r
Hello again,
I found a very interesting document about wkt-problems
(http://home.gdal.org/projects/opengis/wktproblems.html). In the examples we
can see two different uses of the Authority Element, one with annotation marks
for the code and one without.
What do you think about making the parser
Thanks for the added detail; is it an actual DataAccess? Or a stand
alone thing
If it is going to be an actual DataAccess it would kind of need the
xpath maping stuff as part of its configuration. In anycase that is
just my curiosity speaking - it sounds like an interesting component.
Hello,
I created a GIS application using the ESRI soap Services and stumbled a bit.
From a layer I get the WKT per soap request for the reference system and I
would like to use the wkt to transform into a corrdinate reference system the
user have chosen.
But I got a ParseExcpetion for the AUTH
Hi Andrea:
This one got lost in the noise; I am also in favour of this patch. The
only thing I can think to add is a small note in the developers guide
to the effect that geotools will target the "bin" directory.
Jody
On 29/06/2009, at 2:24 AM, Andrea Aime wrote:
> Hi all,
> for a few days
writing features on table with no geometry fails
Key: GEOT-2575
URL: http://jira.codehaus.org/browse/GEOT-2575
Project: GeoTools
Issue Type: Bug
Components: data jdbc-ng
Affects
Hi Andrea:
Decoding the URLs is where we spent most of our URLUtils testing pain;
I have asked Andrea Antonello and Jesse to chime in since they have
both spent a lot of time staring at this problem and testing on
multiple platforms.
Jody
On Mon, Jun 29, 2009 at 7:21 PM, Andrea Aime wrote:
> Mic
Michael Bedward ha scritto:
>> The patch is for 2.5.x
>>
>
> Ah, OK. I missed that, sorry.
>
> To double check I reverted the patch then manually fixed all of the
> plain toURL calls in the shapefile module. Makes no difference.
Maybe it's happening on the other direction then, from url to Fil
> The patch is for 2.5.x
>
Ah, OK. I missed that, sorry.
To double check I reverted the patch then manually fixed all of the
plain toURL calls in the shapefile module. Makes no difference.
Michael
--
_
Michael Bedward ha scritto:
> The patch doesn't seem to make any difference to the shapefile test failures
> :-(
Ouch
> Also, there are several out of date file references in the patch.
The patch is for 2.5.x
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight f
The patch doesn't seem to make any difference to the shapefile test failures :-(
Also, there are several out of date file references in the patch.
Michael
--
___
Geotools-devel
Justin Deoliveira ha scritto:
> Chiming in late, +1 on the change. The question is how to ensure that
> developers do not revert to the deprecated behavior, I myself did know
> that toURL() was an issue. I guess diligent review and a big stick :) A
> convenience method probably won't be of much
Chiming in late, +1 on the change. The question is how to ensure that
developers do not revert to the deprecated behavior, I myself did know
that toURL() was an issue. I guess diligent review and a big stick :) A
convenience method probably won't be of much help either since it is
still another
> Not sure. It would be interesting if you could apply the patch attached
> to the jira to your checkout and see if it works any better for you thought
will do
--
___
Geotools-d
Michael Bedward ha scritto:
> I'm trying to understand this problem. If I do this:
>
> File f = File.createTempFile("test-shp", ".shp");
> URL url1 = f.toURL();
> System.out.println(url1);
> URL url2 = f.toURI().toURL();
> System.out.println(url2);
>
> I get output like this:
> file:/var/folders
I'm trying to understand this problem. If I do this:
File f = File.createTempFile("test-shp", ".shp");
URL url1 = f.toURL();
System.out.println(url1);
URL url2 = f.toURI().toURL();
System.out.println(url2);
I get output like this:
file:/var/folders/bS/bSZ9Hxj+Fr40rwgVRfAAvU+++TI/-Tmp-/test-shp42
Francesco Izzi ha scritto:
> Hi all,
> I tried building in the branch and the trunk of Geotools but both failed.
>
> java -version
> java version "1.5.0_19"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-304)
> Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode, sha
Hi all,
I tried building in the branch and the trunk of Geotools but both failed.
java -version
java version "1.5.0_19"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_19-b02-304)
Java HotSpot(TM) Client VM (build 1.5.0_19-137, mixed mode, sharing)
I run "mvn clean install":
...
fid filter may be ambiguous if there's an actual attribute named ID
---
Key: GEOT-2574
URL: http://jira.codehaus.org/browse/GEOT-2574
Project: GeoTools
Issue Type: Improvement
The thread described trouble with "+" being used in temp filenames and
comming out as a " " when not intended
.
The solutions were:
- change the temp file directory using a java property
- create a extra symbolic link so that the"wrong" path worked out
- to handle file toURL as toURI().toURL() as p
>> Hrm - I do see what you are talking about; the instructions on that page
>> are not the best.
>
> Jody,
> sometimes I wondering if you really read my mails ;-)
Well at least I am good enough to check up on what you said and feel
stupid later :-( Usually if I have not checked your references it
37 matches
Mail list logo
