Hi Saul,
good catch.
my preference would be to get rid of the prefix as much as possible. On the
bright side all the classes in the module except the datastore and gce
factory implementations are to be considered private, and even those two ones
are since SPI takes care for us, so we shouldn'
Saul Farber wrote:
> * I don't care one way or the other on the "ArcSDE" vs "ArcSde" thing,
> just that we do it consistently (hrm, why do I feel so anal about that?
> I'm not sure, perhaps I need therapy...).
>
Think the java class naming conventions lean in favour of ArcSDE (since
SDE stands
Hey gabriel (and anyone else interested),
Do you think we should go with "ArcSdeXXX" or "ArcSDEXXX" for class
names? Also, when should that prefix be applied, and when shouldn't it?
For example, we've got the following classes:
FidReader.java
SdeRow.java
Should these be "ArcS{de,DE}FidReader" a
Just a quick comment because we were confused here:
>> Understood; the only remaining attraction I have to the idea is
>> defining a factory so we could intercept requests to external
>> graphics and handle them locally as an optimization I guess.
> I lost you there. How is this any better than r
Jody Garnett ha scritto:
> Thanks Andrea; this is the kind of thing I should of looked up :-(
>>> The Java API is using an Expression there? Darn. Well Andrea we can
>>> also honestly use ExternalGraphic
>>> it has the ability to supply vendor specific parameters that are
>>> expressions (and thi
Thanks Andrea; this is the kind of thing I should of looked up :-(
>> The Java API is using an Expression there? Darn. Well Andrea we can
>> also honestly use ExternalGraphic
>> it has the ability to supply vendor specific parameters that are
>> expressions (and this is already used in our projec
Jody Garnett ha scritto:
> Andrea Aime wrote:
>> To tell the truth, the well known name is an xs:string, so we would
>> not be allowed to use an expression there either, but at least
>> the xml is using an element for that SLD part, so it's easy to extend
>> it to use an expression, whilst the exte
Andrea Aime wrote:
> To tell the truth, the well known name is an xs:string, so we would
> not be allowed to use an expression there either, but at least
> the xml is using an element for that SLD part, so it's easy to extend
> it to use an expression, whilst the external graphics url is an
> attr
Crop operation is unable to crop rotated coverages properly
---
Key: GEOT-1763
URL: http://jira.codehaus.org/browse/GEOT-1763
Project: GeoTools
Issue Type: Bug
Components: cor
GridCoverageRenderer does not handle rotate coverages properly anymore
--
Key: GEOT-1762
URL: http://jira.codehaus.org/browse/GEOT-1762
Project: GeoTools
Issue Type: Bug
Found this on another email list:
> If you attend just one GIS conference in 2008, make it FOSS4G 2008! It
> promises to be the highlight of your year.
>
> The 2008 Free and Open Source Software for Geospatial (FOSS4G)
> conference, incorporating GISSA 2008, is on the horizon.
>
> WHERE: Cape Town
Daniele Romagnoli ha scritto:
> Hi list,
> We have setup a wiki page related to the proposed module:
> ImageIO-EXT-GDAL. (A module to improve GeoTools raster data access
> capabilities leveraging on ImageIO-EXT project which is mainly based on
> GDAL)
> http://docs.codehaus.org/display/GEOTOOLS/
I did some investingation on the math and it seems correct to me (there
was a little typo in the forward conversion, so I have just updated the
patch attached to the jira issue).
>
> The problem is not in the latitude of origin, but in the lack of the
> TOWGS84 parameter. The projection library w
theunsgis ha scritto:
> I everyone
Hi. Sorry for the late response.
> sorry for the long explanation , but i would like to give as much detail i
> can to get the
> right message across.
>
> I would like to implement a plug-in for Well known Icons.
> The challenge started when you investigated h
Hi list,
We have setup a wiki page related to the proposed module: ImageIO-EXT-GDAL.
(A module to improve GeoTools raster data access capabilities leveraging on
ImageIO-EXT project which is mainly based on GDAL)
http://docs.codehaus.org/display/GEOTOOLS/ImageIO-EXT+GDAL
I have finally fixed some m
Mauro Bartolomeoli ha scritto:
>
>
> Andrea Aime wrote:
>> Mauro Bartolomeoli ha scritto:
>>> We are working on an Italy Cadastre importer, and we are thinking to
>>> use udig to view the produced data, so we are going to need a CRS to
>>> attach to Cassini-Soldner projected data.
>>> It's not
render Line feature shapefile fails
---
Key: GEOT-1761
URL: http://jira.codehaus.org/browse/GEOT-1761
Project: GeoTools
Issue Type: Bug
Affects Versions: 2.4.1
Environment: Win XP, Java 1.6.0_5,
Andrea Aime wrote:
> Mauro Bartolomeoli ha scritto:
>> We are working on an Italy Cadastre importer, and we are thinking to
>> use udig to view the produced data, so we are going to need a CRS to
>> attach to Cassini-Soldner projected data.
>> It's not widely tested and not very accurate (the e
Saul Farber a écrit :
> I've got a float-denominated elevation-model raster with values that are
> "geophysics" values, not image values. From what I can tell, in order
> to handle float-backed rasters, java wants the floats to be normalized
> (mapped into the interval [0.0,1.0]) in some manner.
19 matches
Mail list logo
