On 14/06/10 14:52, Andrea Aime wrote:
I also see code that has just been commented out like in
FeatureSourceMapLayer, bad practice... well, unless you noted down
all the code that you've commented out and will remove it later.
That will be one of the last things I do; remember up to now is a
On 14/06/2010, at 4:52 PM, Andrea Aime wrote:
Jody Garnett ha scritto:
Please don't add a layer.dispose() method, resources to be disposed
are harder to use so let's limit the usage of dispose/close methods
to cases where it's really necessary to do so (file, streams,
database connections
Jody Garnett ha scritto:
On 14/06/2010, at 4:52 PM, Andrea Aime wrote:
Jody Garnett ha scritto:
Please don't add a layer.dispose() method, resources to be
disposed are harder to use so let's limit the usage of
dispose/close methods to cases where it's really necessary to
do so (file,
Jody Garnett ha scritto:
Only thing I would add is Geometry parameters.
Oh right, roger that.
There is a common way to package up geometry provided by the WPS
implementations like 52N. It is basically a small schema that allows a single
geometry element to be passed in or out of a process.
Jody Garnett ha scritto:
Only thing I would add is Geometry parameters.
Oh, and what about Feature parameters?
There is one example process that deals with the single
feature... having a hard time deciding whether it's just
a bad idea and feature collections should suffice, or
if there is an
I am going to wait for Jim to answer that one; i can see the use for it if you
are writing a super specific process for a custom deployment (something like
fetch me the PDF reports for this county; and you pass in the county).
But here is the thing; in these cases the user has already defined a
I think in this case a decision will need to be made; who to trust epsg
database or oracle.
May need an additional connection parameter on this one :-(
Personally I would trust oracle and make sure the datastore was able to create
a crs from the oracle SRID.
Only if that fails would you have
Ben Caradoc-Davies ha scritto:
Derrick is still waiting on a response to this Oracle problem:
In a nutshell, MDSYS.USER_SDO_GEOM_METADATA can have both EPSG codes and
Oracle SRIDs in the SRID column. This can cause the first attempt to
resolve the code to fail, and Derrick wants your
Andrea Aime ha scritto:
However I tried the example from an online documentation I've found:
(http://youngcow.net/doc/oracle10g/appdev.102/b14255/sdo_cs_ref.htm#CHDIEJHH)
SELECT SDO_CS.MAP_ORACLE_SRID_TO_EPSG(82361) FROM DUAL;
Forgot to say that the above one worked and returned 23038...
Add expression support for ExternalGraphic format tag
-
Key: GEOT-3139
URL: http://jira.codehaus.org/browse/GEOT-3139
Project: GeoTools
Issue Type: Bug
Components: core render
Just verified on a windows machine with no local changes.
Jody
On 15/06/2010, at 12:35 PM, Ben Caradoc-Davies wrote:
[Switched to the dev list]
Ooh, this might be a bad test. I assumed that the app-schema schema is first
in the list, as the schemas are now supposed to be sorted in
Build failure in AppSchemaConfigurationTest on Windows
--
Key: GEOT-3140
URL: http://jira.codehaus.org/browse/GEOT-3140
Project: GeoTools
Issue Type: Bug
Components: data
Aieee. Have a look at gt-xsd-core Schemas:114.
HashSet. Platform randomisation, not deterministic behaviour across
platforms.
I now promise to complete my rant HashMap Considered Harmful and to
send it to this list. This will be followed by my proposal for the Great
HashMap Purge of 2010.
On
See open source is a two step process: complain first and then fix :-)
Step 2 is always the hardest.
Checking your fix now.
Jody
On 15/06/2010, at 1:02 PM, Ben Caradoc-Davies wrote:
Aieee. Have a look at gt-xsd-core Schemas:114.
HashSet. Platform randomisation, not deterministic behaviour
+1, This would be great. At the moment I simply ignore IBM/OpenJDK
builds, its like playing Russian roulette. The builds have no chance
to succeed.
Quoting Ben Caradoc-Davies ben.caradoc-dav...@csiro.au:
Aieee. Have a look at gt-xsd-core Schemas:114.
HashSet. Platform randomisation, not
[This affects GeoServer too, but I'd rather avoid a cross-list post.]
Synopsis:
- HashMap has platform-dependent iteration order.
- Use LinkedHashMap to make iteration order consistent across platforms.
- Same rule applies for HashSet: replace with LinkedHashSet.
HashMap uses key hashCodes to
So I have a few votes in - and a few reviews (thanks!)
• Andrea Aime
• +1 Ben Caradoc-Davies
• Christian Mueller
• Ian Turton
• Justin Deoliveira
• +1 Jody Garnett
• Michael Bedward
• +0 Simone Giannecchini
The proposal page [1] has
Can we arrange for maven to yell at us when HashMap is used?
Ben I have been known to use a couple of the other Map implementations; such as
ConcurrentHashMap (and we also have our own WeakHashMap) - we may need to check
if these implementations suffer the same weaknesses as HashMap.
Jody
On
On 15/06/10 13:25, Jody Garnett wrote:
Can we arrange for maven to yell at us when HashMap is used?
I do not think we should do this ,as there are legitimate occasions
where HashMap may be used for performance, particularly when we have
many insertions, one iteration, and iteration order is
On 15/06/10 13:27, derrick.w...@csiro.au wrote:
With regards to EPSG: 23038.
The canonical source for EPSG codes is here:
http://epsg-registry.org/
This also lists 23038.
--
Ben Caradoc-Davies ben.caradoc-dav...@csiro.au
Software Engineering Team Leader
CSIRO Earth Science and Resource
20 matches
Mail list logo
