creating schemas in postgis is nondeterministic in which spatial type is
entered into geometry_columns
--
Key: GEOT-3157
URL:
Michael Bedward ha scritto:
On 23 June 2010 17:21, Andrea Aime wrote:
Votes please :-)
I like the env function approach over yet more hints, but I'm probably biased
:)
Hmmm... the sponsor just told me he wants to have the sld param
expansion and the sql view paths separate so that he
Hmm, one parameter for layout AND data access ?
However, looking at geotools as a library, it is very unlucky to
introduce a new parameter passing mechanism. This is surly not what a
developer expects and will cause confusion. And one has to take care
to clean up all the values in the
christian.muel...@nvoe.at ha scritto:
Hmm, one parameter for layout AND data access ?
However, looking at geotools as a library, it is very unlucky to
introduce a new parameter passing mechanism. This is surly not what a
developer expects and will cause confusion. And one has to take
Sorry, some confusion in my brain today.
Rereading your mails I see that your sponsor wants two have 2
different param paths. I think this is the solution I voted for. ?
If it is, forget my proposal, I assumed vt AND sld use EnvFunction.
Sorry for the confusion.
Quoting Andrea Aime
christian.muel...@nvoe.at ha scritto:
Sorry, some confusion in my brain today.
Rereading your mails I see that your sponsor wants two have 2 different
param paths. I think this is the solution I voted for. ?
It is
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service
H i Ben, this discussion stopped without a result. What are your next steps ?
This message was sent using IMP, the Internet Messaging Program.
--
Hi,
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
This is not sane imho, grabbing a collection, getting the feature
iterator, iterating over the features are all occasions in which
you
Your are right here, but
1) This breaks the client code
2) The implemeters of FeatureCollection currently throw a runtime
exception in such situations (seen in ContentFeatureCollection), you
have to rewrite these methods too.
The biggest question is 1) regarding to applications in user
Inside Joke: This could be Bring Back FeatureReader
On 24/06/2010, at 11:59 PM, Andrea Aime wrote:
Hi,
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
This is not sane imho, grabbing
Around in circles we go :-P
FeatureReader is like an iterator that throws IOExceptions ... and users hated
it.
But yes I will consider it - we are trying for a much stronger sense of YOUR
ARE DOING IO BE CAREFUL and thrown exceptions really scream that to people
using a project. So although
Jody Garnett ha scritto:
Around in circles we go :-P
FeatureReader is like an iterator that throws IOExceptions ... and users
hated it.
Who besides James hated it? ;-)
But yes I will consider it - we are trying for a much stronger sense of
YOUR ARE DOING IO BE CAREFUL and thrown
I agree. In my opinion not just sticking with FeatureReader and
introducing FeatureIterator and Iterator really messed up the api.
What do you mean by bring back feature reader. Did it go away some how?
If we are going to fix the feature collection interface we could
deprecate iterator() and
Around in circles we go :-P
FeatureReader is like an iterator that throws IOExceptions ... and users
hated it.
Who besides James hated it? ;-)
Not sure I was too shy at the time; I do remember hating explaining it to
people repeatedly.
SimpleFeatureReader reader = null;
try {
Jody Garnett ha scritto:
Around in circles we go :-P FeatureReader is like an iterator
that throws IOExceptions ... and users hated it.
Who besides James hated it? ;-)
Not sure I was too shy at the time; I do remember hating explaining
it to people repeatedly.
SimpleFeatureReader reader =
On 24/06/10 20:53, christian.muel...@nvoe.at wrote:
H i Ben, this discussion stopped without a result. What are your next steps ?
No, it stopped with the result that my proposal to avoid HashMap was
rejected.
Blame has been fairly laid at the feet of anyone who expects stable
iteration order
On 24/06/10 21:59, Andrea Aime wrote:
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
I am a card-carrying checked exception hater. They have the effect of
leaking implementation details
On 24/06/10 21:59, Andrea Aime wrote:
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
They should also throw SQLException. And
On 25 June 2010 14:01, Ben Caradoc-Davies wrote:
[I'm going to hide under my desk until Andrea has cooled down.]
Don't imagine you'll be safe there Ben. A few weeks ago Andrea was on
the verge of nuking Sydney because of something Jody said.
This might be a dumb question (I don't know much
On 25/06/10 13:11, Michael Bedward wrote:
This might be a dumb question (I don't know much about Exception
handling) but isn't the least worst approach to the problem of
'leaking' implementation into interface to wrap IOException,
SQLException etc into some GeoTools exception class, e.g.
A big +1 one for this proposal, having our own
FeatureAccessException with a Constructor
FeatureAccessException(Exception ex).
The IOException drives me crazy, because in Java 5 there is no
constructor IOException(Exception ex), in Java 6 there is.
Getting a backend exception (e. g.
Ben Caradoc-Davies ha scritto:
On 24/06/10 21:59, Andrea Aime wrote:
looking at the feature collection and feature iterators interfaces again
I'm seeing another serious design mistake: they don't throw IOException
anywhere.
They should also throw SQLException. And
22 matches
Mail list logo
