christian.muel...@nvoe.at wrote:
This is an interesting thread, so I want to spend my 2 cents.
1) I am astonished about discussing to check a build on SUN SDK 6
http://gis.linux4all.at/hudson32
http://gis.linux4all.at/hudson64
Everybody can look at it, developers knowing the credentials
Andrea Aime wrote:
christian.muel...@nvoe.at wrote:
This is an interesting thread, so I want to spend my 2 cents.
1) I am astonished about discussing to check a build on SUN SDK 6
http://gis.linux4all.at/hudson32
http://gis.linux4all.at/hudson64
Everybody can look at it, developers
Just had a quick look at the users' poll to see if anyone had voted.
11 votes in so far with more for than against.
Michael
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE
Do you have a blank in your build path. ?
Exception in thread main java.lang.NoClassDefFoundError: 32/tmp
The absolute path is
/home/hudson 32/tmp
I am sure if I remove the blank, this bug will disappear. But I can
remember that it was a wish to have blanks in the build path.
The 64 bit
christian.muel...@nvoe.at wrote:
Do you have a blank in your build path. ?
Exception in thread main java.lang.NoClassDefFoundError: 32/tmp
The absolute path is
/home/hudson 32/tmp
I am sure if I remove the blank, this bug will disappear. But I can
remember that it was a wish to have
Hi,
the current gt-process module is giving me a little of a headache
in that if you want the API you get also some default processes:
org.geotools.process.literal.BufferFactory
org.geotools.process.literal.IntersectionFactory
org.geotools.process.literal.UnionFactory
Hi Andrea:
I think some of the simple things (like double addition) could be placed into
test/ or made into an example. Do you want to move it into test/ for now just
to hide it from geoserver WPS?
Other then that it seems that ProcessFactory supports a list of Names; is that
our grouping we
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2771/changes
Changes:
[jive] GML encoder/decoder
--
[...truncated 3278 lines...]
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.028 sec
Running
Had a good session hacking on:
- http://docs.codehaus.org/display/GEOTOOLS/MapContext+Refactor
Resulting in a pretty picture and some sample code that I will form into a
patch (or commit?)
Surprises:
- The approach for replacing DefaultMapLayer is working
- MapContext has code and events around
Hi Jody, in Russia very popular GIS programm is InGeo (
http://www.integro.ru/projects/gis/main_gis.htm), so to use geotools and
geoserver in our work and add more usability in russia there are need to
support is format.
and i want to develop this module for us
InGeo use any relational DBs like
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2772/changes
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the
Sounds great :-)
Do you have any questions on where to start?
Question for you - does InGeo support JDBC? Or does it have a custom API like
ArcSDE?
Depending on your answer I will try and direct you to good example to learn
from :-)
Thoughts:
- There is an old datastore tutorial that goes
Евгений Лазарев wrote:
Hi Jody, in Russia very popular GIS programm is InGeo
(http://www.integro.ru/projects/gis/main_gis.htm), so to use geotools
and geoserver in our work and add more usability in russia there are
need to support is format.
and i want to develop this module for us
Hi Jody, sounds good to me.
Cheers,
Gabriel
On 6/7/10 2:21 AM, Jody Garnett wrote:
Hi Gabriel:
Grabbing some code out of wfs module:
- I have picked up toSimpleFeatureType mentioned above; and migrated to
DataUtilities.simple( FeatureType )
- EmfAppSchemaParser taking a copy to xml; hiding
You should try and keep these dicusssions on the email list (or you will just
need to repeat yourself :-) ).
Jody
On 08/06/2010, at 2:55 AM, Евгений Лазарев wrote:
hi,
yes inGeo use jdbc
db is trivial relational db with custom spatial index implementation, so i
already browsing sql
Hi Mathieu:
I am going to have some time this week to go over your ideas and turn them into
a proposal. Are you set up for editing on the wiki? We had some trouble with
Jira being broken into and a lot of the passwords have been reset; so even if
you had access before you should check.
Jody
MapContext Refractor
Key: GEOT-3136
URL: http://jira.codehaus.org/browse/GEOT-3136
Project: GeoTools
Issue Type: Improvement
Components: core render
Affects Versions: 2.7-M1
Reporter: Jody
Proposal is established enough to be voted on; I will be working on this over
several evenings this week with this weekend targeted for the first commit.
- http://docs.codehaus.org/display/GEOTOOLS/MapContext+Refactor
- http://jira.codehaus.org/browse/GEOT-3136 (Initial patch showing the api;
The interfaces would move to gt-api; but yes you are correct.
I was hoping for a firm thumbs up when Andrea and Michael (and others) were
happy with the interface before considering how best to integrate.
Jody
On 08/06/2010, at 11:14 AM, Michael Bedward wrote:
Hi Andrea, Jody,
If the
On 7 June 2010 18:53, Andrea Aime aa...@opengeo.org wrote:
Aha, I see, so it's a legitimate bug.
Sigh... that module has no maintainer...
I could put my hand up for the maven/javadoc module. I got to know it
when getting the @source tag processing to work.
I'm happy to stand back if there
Hi Scott / Jim:
I think I have my first good cut of FeatureCollection parsing in gt-xml ready
for you to try out.
This solution allows a FeatureCollection to be produced - even in cases where
the schema does not work out very well - or cannot be found.
The trick was that the parser does not
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2773/changes
Changes:
[jive] GML supports parsing now
--
[...truncated 3443 lines...]
WARNING: Could find type for feature in the schema, generating type from
feature.
Jun 7, 2010 11:14:52 PM
On 04/06/10 22:12, Joachim Van der Auwera wrote:
Considering that java5 is still just the previous version (even if it is
already a couple years old),
Six years.
I would not require java6 unless there is a
very compelling reason.
(1) It is a pain in the arse to get the Java 5 JDK.
(2)
+1
On 04/06/10 17:18, Andrea Aime wrote:
Hi,
quick informal poll. What about switching the current trunk to Java 6?
Would you be pro? Against? Don't care?
I would be pro.
Cheers
Andrea
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineering Team Leader
CSIRO Earth
+1. Changes look sensible.
One suggestion: any chance of calling the Map class something else? It
will cause confusion both in code and in discussion.
Kind regards,
Ben.
On 08/06/10 08:15, Jody Garnett wrote:
Proposal is established enough to be voted on; I will be working on this over
Christian, you are a champion. I was sure it was your Hudson with spaces
in the build path. Well done.
On 07/06/10 16:47, christian.muel...@nvoe.at wrote:
Do you have a blank in your build path. ?
Exception in thread main java.lang.NoClassDefFoundError: 32/tmp
The absolute path is
On 04/06/10 19:27, Mathieu Baudier wrote:
I built GeoTools trunk recently (for the OSGi project we are trying to
set up with Jody) on a OpenJdk 6 b16 on CentOS 5.5 x86_64 and it went
very smoothly.
Did you build with -Dall?
is stupidly dependent on hash iteration order, though other times
MapLayerCollection? That is the best I have been able to come up with,
so perhaps Map is not so bad after all ... :-)
I suppose this is an instance of misused mathematical/compsci jargon
finally being used for its original purpose.
On 08/06/10 12:44, Jody Garnett wrote:
There is a chance; do
See http://hudson.opengeo.org/hudson/job/geotools-trunk/2774/changes
--
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the
29 matches
Mail list logo
