2008/7/16 Jody Garnett <[EMAIL PROTECTED]>:
> Here is the best quick intro I found with a google search:
> - http://www.onjava.com/pub/a/onjava/2004/04/21/declarative.html?page=last
thanks for that (I think I'll need to read it a couple more times for
it to sink in)
> The developers guide has som
Jody Garnett wrote:
> FeatureCollection
> - should we remove this until we have a working implementation?
>
I have removed GeoApi FeatureCollection; no sense keeping dead weight.
I would also like to make our FeatureCollection not extend
AbstractCollection; we talked about this but at the time
Michael Bedward wrote:
> 2008/7/16 Jody Garnett <[EMAIL PROTECTED]>:
>
>> links are provided at the package-info.java level
>>
>>
> I'm sure this is a dumb question but what does that bit mean Jody ? I
> ask because I'd like to document the raster to vector classes.
>
Not a worry; this
2008/7/16 Jody Garnett <[EMAIL PROTECTED]>:
> links are provided at the package-info.java level
>
I'm sure this is a dumb question but what does that bit mean Jody ? I
ask because I'd like to document the raster to vector classes.
Also (and this might be both dumb and trivial :) presently there
Supplied docs for org.opengis.feature.simple; I am not sure we can
justify a package for just two classes (especially since the type
factory now handles everything). In anycase added a diagram and
package.html description.
Jody
--
org.opengis.feature.type/package.html updated - removed all ideas,
future work and so on
- leaving only description of what is
- updated diagrams
FeatureCollection
- should we remove this until we have a working implementation?
Tim I went over the rest of the javadocs and did not see anything to
There have been a couple good conversations about the javadocs for:
- Deature, PropertyDescriptor - how to handle features that are not
"contained" - ie are top level types
- GeometryDescriptor / GeometryType - what does
getCoordianteReferenceSystem() mean
I am collecting this conversations in a
Apologies for the late reply. So you are correct, for well known schemas
the parser should not be accessing anything online... so i think this is
a bug.
Gabriel, do you have a test case or request to parse which will show
this issue?
Gabriel Roldán wrote:
> Hi Justin,
>
> I guess I should cre
Hi Ben,
I don't think there will be any issues moving them across. Technically
topp owns copyright on GeoServer code, but in cases such as these (and i
could be wrong here) topp is willing to give up copyright and assign it
to Geotools directly.
So i think the easiest path would be just to do
unsup/ecw can be removed in favor of unsup/imageio-ext-gdal
---
Key: GEOT-1921
URL: http://jira.codehaus.org/browse/GEOT-1921
Project: GeoTools
Issue Type: Sub-task
Components
unsup/mrsid can be removed in favor of unsup/imageio-ext-gdal
-
Key: GEOT-1920
URL: http://jira.codehaus.org/browse/GEOT-1920
Project: GeoTools
Issue Type: Sub-task
Compon
GroupingFeatureIterator3$MutableFeature does not provide value for
gsml:Borehole/sa:shape
-
Key: GEOT-1919
URL: http://jira.codehaus.org/browse/GEOT-1919
Project:
I am considering moving some of the community-schemas code base from
GeoServer to GeoTools. This raises several issues.
(1) Is there any copyright or licensing problem moving GeoServer code to
GeoTools?
(2) Which copyright headers should they use? Their original ones, or
should they be changed
13 matches
Mail list logo
