Hey all,
When you settle on your design, will there be a document explaining it?
I'm not following this thread closely enough to see what's being/been
decided but would like to understand the global factory design at the
end.
--adrian
---
I would like to keep API interface only ...
Martin has been moving other glue code to metadata
Jody
> Yeah we can, it has been something i have been meaning to do. I was
> thinking to maintain backwards compatability it could be hte last
> effort, a call to Converters.convert( ... ).
>
> One
Yeah we can, it has been something i have been meaning to do. I was
thinking to maintain backwards compatability it could be hte last
effort, a call to Converters.convert( ... ).
One problem though is that the converter stuff all lives in main. We
would have to move it to api to pull it off.
-Jus
Martin Desruisseaux wrote:
> Jody Garnett a écrit :
>> I wrote some initial instructions on the developers guide, I see
>> Jesse has updated them a bit - but the level
>> of detail required for planning is missing. I am not sure exactly
>> what is going on and how much is global?
>
> You means th
Jody Garnett a écrit :
> I wrote some initial instructions on the developers guide, I see Jesse
> has updated them a bit - but the level
> of detail required for planning is missing. I am not sure exactly what
> is going on and how much is global?
You means this page?
http://docs.codehaus.org/d
Question for Justin ... this functionality of Param is one of the cases
where we do "conversion".
Can we (at least on trunk) make use of the same code you set up for
literal parsing?
Nice patch however :-)
Jody
> Hi,
> I committed a patch to 2.3.x that allows parameters
> to parse a space separa
Hi,
I committed a patch to 2.3.x that allows parameters
to parse a space separated string into an array, that
is an extension to the already available ability to
parse strings to numbers and dates using reflection.
If someone minds checking it, I would be glad :-)
It's needed to make Geoserver han
Directory data store conflicts with property data store
---
Key: GEOT-1198
URL: http://jira.codehaus.org/browse/GEOT-1198
Project: GeoTools
Issue Type: Improvement
Components: dat
DataStoreFactorySpi.Param should be able to parse delimited strings into arrays
---
Key: GEOT-1197
URL: http://jira.codehaus.org/browse/GEOT-1197
Project: GeoTools
I
Thanks Martin:
Reviewing changes now.
And thanks for putting up with me on this one, I am trying to sort these
things out before I run into a deadline (and am forced into a quick
decision).
Martin Desruisseaux wrote:
> Commited the following changes on trunk as of revision 24765:
>
> * Added a
Justin Deoliveira wrote:
> I have submitted a patch for http://jira.codehaus.org/browse/GEOT-906
> which deals with how the sld parser handles whitespace for property
> names and css parameters.
>
> The patch is written against 2.3.x, and I have supplied a test case for
> it as well. If ok with it
In proj there is file called EPSG with mappings between epsg codes and
proj4 parameters.
How to do this in general is another story...
Simone.
On 3/15/07, Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
> Adrian Custer a écrit :
> > Is there a method or approach from which we can go from
> > Fea
Adrian Custer a écrit :
> Is there a method or approach from which we can go from
> Feature.getDefaultGeometry().getCRS()
> to a String object of Proj4 commands describing the equivalent
> Coord.Ref.System?
There is nothing in current Geotools for formatting or parsing a Proj4 strings.
I don't kn
Hey Martin, everyone,
Is there a method or approach from which we can go from
Feature.getDefaultGeometry().getCRS()
to a String object of Proj4 commands describing the equivalent
Coord.Ref.System?
The R statistical language has a spatial package (called 'sp') that uses
a String of proj4 commands
14 matches
Mail list logo
