Saul Farber wrote:
> 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?
Not quite, on trunk we have introduced the PropertyAccessor interface,
w
Hi all,
The BasicFidMapper return a new fid using a UID. In gml / filter, a fid
is defined to be an NCName. My problem is the string representation of a
UID does not form a valid NCName.
So I would like to modify the returned UID slighly so that:
1. It does not contain any non alpha numeric char
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
ArcSDE Geometry Encoder doesn't like null geometry-attributenames
-
Key: GEOT-1066
URL: http://jira.codehaus.org/browse/GEOT-1066
Project: GeoTools
Issue Type: Bug
Com
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
inter
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, th
Jesse Eichar wrote:
>> I am concerned that with the two week window we would not be able to
>> respond quickly enough to the kind of problems encountered over
>> GeoTools 2.4 development. Need to emphasis that that "collaboration"
>> is needed rather then "veto"; so the GeoServer style +1, -1, +
On 12-Dec-06, at 2:54 PM, Jody Garnett wrote:
> Hi Jesse I like your plan
>
> One thing we had trouble with here (http://docs.codehaus.org/
> display/GEOTOOLS/Expression+Improvements) is the discussion of
> alternatives hanging around after the final options have been
> chosen. With you
Hi Jesse I like your plan
One thing we had trouble with here
(http://docs.codehaus.org/display/GEOTOOLS/Expression+Improvements) is
the discussion of alternatives hanging around after the final options
have been chosen. With your "plan" discussion & notification happens on
Jira - leaving
I meant a geoapi branch, not geotools. Geotools trunk is already on
geoapi trunk. Geotools 2.3.x however is built off of geoapi 2.1-M1. Some
recent changes to geoapi prevent us from building 2.3.x against geoapi
trunk.
-Justin
Rob Atkinson wrote:
> Shouldnt we do this on 2.4 (currently trunk?) in
So the plan so far:
1. Create a Wiki page on the proposal
2. Create a JIRA for the proposal with a link to the Wiki page
3. Jira should be blocker and be in the Proposal category
4. Wiki page should provide link to its associated JIRA (include Jira?)
4. If the Jira is not discussed within 2 w
Begin forwarded message:
From: Jesse Eichar <[EMAIL PROTECTED]>
Date: December 12, 2006 2:03:47 PM PST (CA)
To: Andrea Aime <[EMAIL PROTECTED]>
Subject: Re: [Geotools-devel] DataAccess conversation
On 12-Dec-06, at 1:11 PM, Andrea Aime wrote:
Jesse Eichar ha scritto:
I agree with you Chr
Jesse Eichar ha scritto:
>> I agree with you Chris we need some sort of process for making changes
>> to Geotools. Seems to me there keeps being issues where someone sends
>> an email out about some change, nobody is really interested except for
>> that person so everyone just ignores it... T
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061212151241Lbuild.23
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chanc
Shouldnt we do this on 2.4 (currently trunk?) instead of a new branch?
Martin Desruisseaux wrote:
> Justin Deoliveira a écrit :
>
>> As per my discussion with Martin in IRC yesterday I looked at making
>> 2.3.x compile against geoapi trunk. However, its more work then I
>> initially thought, it
Large Shapefile Storage Exception
-
Key: GEOT-1065
URL: http://jira.codehaus.org/browse/GEOT-1065
Project: GeoTools
Issue Type: Improvement
Components: data shapefile
Affects Versions: 2.2.1
Begin forwarded message:
From: Jesse Eichar <[EMAIL PROTECTED]>
Date: December 12, 2006 11:06:25 AM PST (CA)
To: Chris Holmes <[EMAIL PROTECTED]>
Subject: Re: [Geotools-devel] DataAccess conversation
I agree with you Chris we need some sort of process for making
changes to Geotools. Seems
View results here ->
http://geo.openplans.org:9090/buildresults/geotools-trunk?log=log20061212134401
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to shar
This makes a lot of sense.
But just about every time we've tried to design something in GeoTools
that we didn't have a concrete use case for we've failed. So I'd like
to see these interfaces actually be super classes for GridCoverage and
FeatureSource. And maybe from there figure out metadat
As I understand it at least part of the motivation for these
interfaces is to provide interfaces for the common parts of all GIS
APIs. Consider the similarities between GridCoverage, Feature and
Topology models.
These interfaces provide a way of obtaining the common information
between th
Thanks Andrea for the email documenting what you will accept. I am not
sure exactly what I will accept yet - but will think on it for later.
Andrea Aime wrote:
>>> Andrea GeoServer (and generating GML) is not my only concern here; I
>>> would like to open the door to rich content beyond our feat
Jody Garnett ha scritto:
> Andrea Aime wrote:
> IMHO we will not be able to make everyone happy this time around
> (because to do so would be to ask too much - ie FM, update datastores,
> complex feature branch salvaged etc...), I would rather ensure we
> removed as many obstacles to the FM rol
Justin Deoliveira a écrit :
> As per my discussion with Martin in IRC yesterday I looked at making
> 2.3.x compile against geoapi trunk. However, its more work then I
> initially thought, its not just the additional method on Expression
> itself, there are a number of over changes:
>
> 1. The Feat
Andrea Aime wrote:
> Nope, when you're rendering you're using just the "flat", simple part
> of it, or you would not be able to use it, no?
no.
You can actually choose to render your content based on attributes of
things they are related to etc...
>> Andrea GeoServer (and generating GML) is not m
Andrea Aime ha scritto:
> Jody Garnett ha scritto:
>>> Why, instead of simply returning a useless "Object", can't we return
>>> something that implements an interfaces that _looks like_ Feature type?
>>> Maybe something that can list all "simple" properties around, those that
>>> geotools is able
Jody Garnett ha scritto:
> Thanks for the detailed feedback Andrea going to try to field these
> quickly before my workday...
>> DataAccess
>> -
>>
>> The interface does not say anything about being able to provide
>> read only or read write accessors. I see that there's a Store
>>
Thanks for the detailed feedback Andrea going to try to field these
quickly before my workday...
> DataAccess
> -
>
> The interface does not say anything about being able to provide
> read only or read write accessors. I see that there's a Store
> interface that extends Source, but
Hi all,
As per my discussion with Martin in IRC yesterday I looked at making
2.3.x compile against geoapi trunk. However, its more work then I
initially thought, its not just the additional method on Expression
itself, there are a number of over changes:
1. The FeatureId interface has been totall
Found the other page:
- http://docs.codehaus.org/display/GEOTOOLS/New+Data+Access+API
Tomas wanted the content moved from JPox (as it does not really impact
him very much).
Chris I forgot one on for the llist of things that are not Features:
Metadata.
Note there are many more problems with Dat
Wegert a écrit :
> Maybe by creating all available CRS and checking each created CRS...if it's
> equal to the CRS created by WKT.
Yeah... There is unfortunatly no API right now for fetching the EPSG code from
a
WKT, so looping over all possible CRS is the only way currently provided.
However if
Maybe by creating all available CRS and checking each created CRS...if it's
equal to the CRS created by WKT.
This will create an array with all available CRS:
> CoordinateReferenceSystem[] cache;
>
>
> int progress = 0;
>
> int maximum = 1;
>
> if (cache == null) {
>
>
Andrea,
OK. I started over. (ty for addressing my install question).
I create a new Data connection, using these steps.
. Stores: (I connected to my local postgres table) and the connection seemed
fine. (the column in my table that contains geometry that I want to see is
called "geometry"). I ca
On 12/11/06, Jody Garnett <[EMAIL PROTECTED]> wrote:
> IanT is the module maintainer for MapPane, given the number of questions
> on the user list unsupported seems a fair call.
sorry I'm abit swamped at the moment, plus there is no connectivity at
the OGC meeting this week. MapPane should probab
Hi,
I'm wondering if there's any way, given a wkt definition
of a CRS, to check if there's any EPSG code that matches
the same definition (the name at least).
Cheers
Andrea
-
Take Surveys. Earn Cash. Influence the Future of I
On Mon, 2006-12-11 at 22:04 -0500, Chris Holmes wrote:
> I'm happy to volunteer. I could co-volunteer with acuster, or let him
> have it, and just play the role of 'the board member'.
>
> Chris
Go Chris go! I'm not in a physical situation stable enough to take this
on right now so better that C
On Tue, 2006-12-12 at 15:37 +0100, Andrea Aime wrote:
> Adrian Custer ha scritto:
> > Martin,
> >
> > If you want to redeploy a clean 2.3.0 it looks like you could do the
> > same thing Andrea did.
>
> Yeah, sourceforge upload system is a mess, the trick of chaning the file
> name allows to chan
Adrian Custer ha scritto:
> Martin,
>
> If you want to redeploy a clean 2.3.0 it looks like you could do the
> same thing Andrea did.
Yeah, sourceforge upload system is a mess, the trick of chaning the file
name allows to change a failed upload...
Cheers
Andrea
Martin,
If you want to redeploy a clean 2.3.0 it looks like you could do the
same thing Andrea did.
--adrian
On Tue, 2006-12-12 at 09:43 +0100, Andrea Aime wrote:
> Justin Deoliveira ha scritto:
> >
> > Andrea Aime wrote:
> >> Martin Desruisseaux ha scritto:
> >>> Andrea Aime a écrit :
> *
>
> > Object /*Description*/ describe();
> >
> > Seems to be an abstraction of getFeatureType().
>
> Indeed, although it could be Class, FeatureType, EClass etc as needed.
> Simboss what does GridCoverage have by way of description?
>
something that for some reason I'm holding myself to comment
Tim Schreiner ha scritto:
> Andrea,
>
> OK. I started over. (ty for addressing my install question).
>
> I create a new Data connection, using these steps.
>
> . Stores: (I connected to my local postgres table) and the connection seemed
> fine. (the column in my table that contains geometry that
Hi,
and here is my feedback.
As I see, you want to provide data in its native format, assuming
that you can build appropriate property accessors in order to play
with whatever is returned.
The touted benefits of this are, apparently, that it makes it easier
to link whatever data you have already
Thomas Marti (HSR) ha scritto:
> Hi Justin
>
> Thanks for your input. The link to the existing API is, that at a later stage
> DataStore should extend DataAccess, FeatureSource should extend Source, etc.
> If
> you want to see an example of an implementation of the new interfaces have a
> look
Streamline current release process
--
Key: GEOT-1064
URL: http://jira.codehaus.org/browse/GEOT-1064
Project: GeoTools
Issue Type: Improvement
Components: doc
Reporter: Andrea Aime
Justin Deoliveira ha scritto:
>
> Andrea Aime wrote:
>> Martin Desruisseaux ha scritto:
>>> Andrea Aime a écrit :
* to fix this, is it simply ok to checkout the 2.2.2 tag,
build and do a mvn deploy?
>>> I think that it work. It should overwrite the 2.2.2 JARs files.
>>>
* since t
44 matches
Mail list logo
