[Geotools-devel] [jira] Created: (GEOT-3128) Remove direct references to ThreadedEpsgFactory
Remove direct references to ThreadedEpsgFactory --- Key: GEOT-3128 URL: http://jira.codehaus.org/browse/GEOT-3128 Project: GeoTools Issue Type: Sub-task Reporter: Jody Garnett -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3127) ThreadedEpsgFactory getAuthorityCodes
ThreadedEpsgFactory getAuthorityCodes - Key: GEOT-3127 URL: http://jira.codehaus.org/browse/GEOT-3127 Project: GeoTools Issue Type: Sub-task Reporter: Jody Garnett -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3126) ForcedAxisOrder fix for AbstractEpsgMediator
ForcedAxisOrder fix for AbstractEpsgMediator Key: GEOT-3126 URL: http://jira.codehaus.org/browse/GEOT-3126 Project: GeoTools Issue Type: Sub-task Reporter: Jody Garnett -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3125) Update HsqlWpsgDatabase to use EPSG 7.5.0
Update HsqlWpsgDatabase to use EPSG 7.5.0 - Key: GEOT-3125 URL: http://jira.codehaus.org/browse/GEOT-3125 Project: GeoTools Issue Type: Sub-task Affects Versions: 2.7-M1 Reporter: Jody Garnett Assignee: Andrea Aime Fix For: 2.7-M1 Attachments: geot-3125.patch The attached patch updates HSqlEpsgDatabase to use the code from ThreadedHsqlEpsgFactory - and changes ThreadedHsqlEpsgFactory to call the moved methods. Andrea can you review and apply this patch at your earlier connivence so we no longer have this duplication. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3124) Reports of Deadlock
Reports of Deadlock --- Key: GEOT-3124 URL: http://jira.codehaus.org/browse/GEOT-3124 Project: GeoTools Issue Type: Sub-task Reporter: Jody Garnett -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3123) Add Find functionality to AbstractEpsgMediator
Add Find functionality to AbstractEpsgMediator -- Key: GEOT-3123 URL: http://jira.codehaus.org/browse/GEOT-3123 Project: GeoTools Issue Type: Sub-task Components: core referencing Affects Versions: 2.7-M1 Reporter: Jody Garnett Fix For: 2.7-M1 Find functionality initially not suported; corrected by extending AbstractAuthorityFactory and adding a finder that is aware of an "findCache" ObjectCache to AbstractCachedAuthorityFactory. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Reopened: (GEOT-3116) Upgrade EPSG database to version 7.5
[ http://jira.codehaus.org/browse/GEOT-3116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jody Garnett reopened GEOT-3116: The update was not clean for me; after the update I have several test failures when I run the tests from eclipse. These were not present yesterday prior to the update. CRSTest.testWestDirection - Unknown axis direction: "South along 10'W" DefaultFacotryTest.testCreation - Unknown axis direction: "Geocenter > equator/0'E" Indeed I was sure I had messed things up when trying to update HsqlEpsgDatabase in my own checkout; but I have now confirmed the above two problems on a fresh checkout of GeoTools on a separate machine. > Upgrade EPSG database to version 7.5 > > > Key: GEOT-3116 > URL: http://jira.codehaus.org/browse/GEOT-3116 > Project: GeoTools > Issue Type: Improvement >Affects Versions: 2.7-M1 >Reporter: Andrea Aime >Assignee: Andrea Aime > Fix For: 2.6.5, 2.7-M1 > > > Update both the HSQL and H2 databases -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] So how does app schema resolver work?
On 01/06/2010, at 1:08 PM, Ben Caradoc-Davies wrote:
> On 01/06/10 10:40, Jody Garnett wrote:
>> I thought I would take a look at app schema resolver to see how it is used;
>> thus far looking at test cases I cannot see how to bundle my own schema up
>> in jar form.
>
> Please see the GS user manual:
> http://docs.geoserver.org/trunk/en/user/data/app-schema/app-schema-resolution.html#classpath
>
> Examples of how to make schema jars using maven are in
> modules/unsupported/app-schema/app-schema-packages subdirectories.
>
> The full documentation of the path convention is in the javadoc for
> AppSchemaResolver.getSimpleHttpresourcePath(URI).
Thanks that is the link I was missing; will add a jumping off point in geotools
pointing there.
I also noted the description of the module was missing from the pom.xml - I am
not sure we are running mvn site these days so perhaps it is not that important?
>> I also cannot find any docs on the geotools site. I am fine if you want to
>> have the build of your configuration instructions on the geoserver site; the
>> requirement for a page showing a code example is still in place. And is a
>> good opportunity to link to where ever you are storing documentation.
>
> Can we use the new doc framework? It will be much easier to manage code
> examples written in sphinx.
We quickly covered this prior to justin's current proposal - the was between a
single doc directory; or a doc directory per module depending on how we want to
run things.
So we will need to sort out how to organise the user guide so that it can be
used by people to document their modules. My focus will be on the initial
welcome material in the short term.
Do you have any suggestions or ideas?
I would consider starting out by replacing the current module matrix page
(which also does not list any app schema modules) with rst files.
> The best classpath example is AppSchemaConfigurationTest.classpath . Creating
> a Configuration is the central step. Note that real use must add a GML 3.1
> GMLConfiguration as a dependency in the constructor. Yes, this should go in
> the library user manual (which I think is your meaning in asking this
> question).
As part of moving to supported we needed one wiki page with a code example :-)
So where should we put app schema (and how many plugins are marked. Currently
they are still in unsupported so I will put a placeholder there with the code
you provided.
>
>/**
> * Test we can {...@link Schemas#findSchemas(Configuration)} with
> classpath only.
> */
>@Test
>public void classpath() {
>Configuration configuration = new
> AppSchemaConfiguration("urn:cgi:xmlns:CGI:GeoSciML:2.0",
> "http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd";, new
> AppSchemaResolver());
>SchemaIndex schemaIndex = Schemas.findSchemas(configuration);
>Assert.assertEquals(3, schemaIndex.getSchemas().length);
>String schemaLocation =
> schemaIndex.getSchemas()[0].getSchemaLocation();
>Assert.assertTrue(schemaLocation.startsWith("jar:file:"));
>Assert.assertTrue(schemaLocation.endsWith("geosciml.xsd"));
> }
>
> Kind regards,
>
> --
> Ben Caradoc-Davies
> Software Engineering Team Leader
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] So how does app schema resolver work?
On 01/06/10 10:40, Jody Garnett wrote:
> I thought I would take a look at app schema resolver to see how it is used;
> thus far looking at test cases I cannot see how to bundle my own schema up in
> jar form.
Please see the GS user manual:
http://docs.geoserver.org/trunk/en/user/data/app-schema/app-schema-resolution.html#classpath
Examples of how to make schema jars using maven are in
modules/unsupported/app-schema/app-schema-packages subdirectories.
The full documentation of the path convention is in the javadoc for
AppSchemaResolver.getSimpleHttpresourcePath(URI).
> I also cannot find any docs on the geotools site. I am fine if you want to
> have the build of your configuration instructions on the geoserver site; the
> requirement for a page showing a code example is still in place. And is a
> good opportunity to link to where ever you are storing documentation.
Can we use the new doc framework? It will be much easier to manage code
examples written in sphinx.
The best classpath example is AppSchemaConfigurationTest.classpath .
Creating a Configuration is the central step. Note that real use must
add a GML 3.1 GMLConfiguration as a dependency in the constructor. Yes,
this should go in the library user manual (which I think is your meaning
in asking this question).
/**
* Test we can {...@link Schemas#findSchemas(Configuration)} with
classpath only.
*/
@Test
public void classpath() {
Configuration configuration = new
AppSchemaConfiguration("urn:cgi:xmlns:CGI:GeoSciML:2.0",
"http://www.geosciml.org/geosciml/2.0/xsd/geosciml.xsd";, new
AppSchemaResolver());
SchemaIndex schemaIndex = Schemas.findSchemas(configuration);
Assert.assertEquals(3, schemaIndex.getSchemas().length);
String schemaLocation =
schemaIndex.getSchemas()[0].getSchemaLocation();
Assert.assertTrue(schemaLocation.startsWith("jar:file:"));
Assert.assertTrue(schemaLocation.endsWith("geosciml.xsd"));
}
Kind regards,
--
Ben Caradoc-Davies
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] So how does app schema resolver work?
Afternoon: I thought I would take a look at app schema resolver to see how it is used; thus far looking at test cases I cannot see how to bundle my own schema up in jar form. I also cannot find any docs on the geotools site. I am fine if you want to have the build of your configuration instructions on the geoserver site; the requirement for a page showing a code example is still in place. And is a good opportunity to link to where ever you are storing documentation. Jody -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] parsing gml
So what did you do to make featurecollection encoding/decoding work for GeoServer WPS? I would like to do the same thing myself for some of the process test cases. Jody On 01/06/2010, at 12:47 AM, Justin Deoliveira wrote: > Yeah, the gtxml method is horrible from a IDE point of view. One thing I > always planned to do was add shortcut classes: > > GMLParser/GMLEncoder > FilterParser/FilterEncoder > etc... > > On 10-05-31 12:44 AM, Jody Garnett wrote: >> Time has come for me to tackle one of Micaheal's requests from a couple >> months ago ... How do we parse/encode GML. >> >> To start with I have asked a few co-workers that have tried GeoTools parsing >> lately. Mostly I got a list of ways that do not work. Interestingly they all >> share an approach in common ... >> >> Typing in the IDE and using command completion to come up with things like: >> - GMLParsing - this is actual a demo of how to parse using GMLConfiguration >> - FeatureCollectionParser - actually part of the implementation of WFS 1.1.0 >> - GML configuration for GML2 extending XSD >> - GML configuration for GML3 extending XSD >> - GML configuration for GML3.2 extending XSD >> - GML configuration for WCS extending XSD >> - GMLParsingUtils - used internally by the GML2 bindings >> - GMLFeatureCollection - returned by WFS 1.0 implementation from FCBuffer >> - etc... >> >> So the only thing I can do in these cases is improve the javadocs to point >> people in the correct direction. >> >> Jody >> -- >> >> ___ >> Geotools-devel mailing list >> Geotools-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > -- > Justin Deoliveira > OpenGeo - http://opengeo.org > Enterprise support for open source geospatial. > > -- > > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: documentation
+1 Simone. --- Ing. Simone Giannecchini GeoSolutions S.A.S. Founder - Software Engineer Via Carignoni 51 55041 Camaiore (LU) Italy phone: +39 0584983027 fax: +39 0584983027 mob:+39 333 8128928 http://www.geo-solutions.it http://geo-solutions.blogspot.com/ http://www.linkedin.com/in/simonegiannecchini http://twitter.com/simogeo --- On Mon, May 31, 2010 at 7:37 PM, Ian Turton wrote: > +1 for me > > Ian > -- > Ian Turton > > -- > > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel > -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Proposal: documentation
+1 for me Ian -- Ian Turton -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] PMC: using existing FIDs during feature insertion
+1 nice work. I don't have a strong opinion on name as both make sense. I guess I would lean toward "user provided" as well. On 10-05-29 4:44 AM, Andrea Aime wrote: > Hi, > following last week discussion I cooked up a formal proposal to allow > GeoTools 2.6.x and trunk to use existing fids during feature insertion. > You can find it here: > > http://docs.codehaus.org/display/GEOTOOLS/Allow+inserts+to+use+existing+feature+ID > > The proposal is open for voting > > Cheers > Andrea > -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] parsing gml
Yeah, the gtxml method is horrible from a IDE point of view. One thing I always planned to do was add shortcut classes: GMLParser/GMLEncoder FilterParser/FilterEncoder etc... On 10-05-31 12:44 AM, Jody Garnett wrote: > Time has come for me to tackle one of Micaheal's requests from a couple > months ago ... How do we parse/encode GML. > > To start with I have asked a few co-workers that have tried GeoTools parsing > lately. Mostly I got a list of ways that do not work. Interestingly they all > share an approach in common ... > > Typing in the IDE and using command completion to come up with things like: > - GMLParsing - this is actual a demo of how to parse using GMLConfiguration > - FeatureCollectionParser - actually part of the implementation of WFS 1.1.0 > - GML configuration for GML2 extending XSD > - GML configuration for GML3 extending XSD > - GML configuration for GML3.2 extending XSD > - GML configuration for WCS extending XSD > - GMLParsingUtils - used internally by the GML2 bindings > - GMLFeatureCollection - returned by WFS 1.0 implementation from FCBuffer > - etc... > > So the only thing I can do in these cases is improve the javadocs to point > people in the correct direction. > > Jody > -- > > ___ > Geotools-devel mailing list > Geotools-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/geotools-devel -- Justin Deoliveira OpenGeo - http://opengeo.org Enterprise support for open source geospatial. -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3122) Extend the property identifier rule to allow defining propery name between doble quote
Extend the property identifier rule to allow defining propery name between
doble quote
--
Key: GEOT-3122
URL: http://jira.codehaus.org/browse/GEOT-3122
Project: GeoTools
Issue Type: Improvement
Components: core cql
Affects Versions: 2.6.4
Reporter: Mauricio Pazos
Nowadays, it is not possible to use an ECQL/CQL language keyword as field
identifier. By example
LIKE > 1 <<< is not a valid sentence.
In SQL, the way to save this problem is to define the filed identifier between
double quote. By example
CREATE TABLE test
(
"LIKE" integer
)
Then you can ask for
LIKE" > 1
We will adopt the SQL convention for the CQL/ECQL language. This criteria will
solve the problem of field defined with local set of character. By Example
CREATE TABLE test
{
"nación" character varying
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
--
___
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [jira] Created: (GEOT-3121) Support for vectorizing very large rasters
Support for vectorizing very large rasters -- Key: GEOT-3121 URL: http://jira.codehaus.org/browse/GEOT-3121 Project: GeoTools Issue Type: Improvement Reporter: Michael Bedward Assignee: Michael Bedward Priority: Minor RasterToVectorProcess accumulates line segments in memory as it processes the input grid coverage and then passes them to JTS Polygonizer en masse. When vectorizing all boundaries in a very large coverage the line segments can exhaust available memory before the process is completed. The following is one idea for addressing this: # Modify RasterToVectorProcess to return a DataStore instead of a FeatureCollection. # Allow the user to provide a DataStore to use as the destination and a name to assign to the destination SimpleFeatureType. If not provided a new DataStore will be created and a default name used. # Process the input raster in sections based on tiles or some number of rows (rows might be safest). # The line segments generated in each section are polygonized to create new SimpleFeatures which are added to the destination DataStore. # In the case of raster regions extending beyond the boundaries of an input section, temporary edges are added so that valid polygons can be created. The location of these edges is recorded so that the resulting features can be merged as a final step in the process. I don't know if the above is the best approach. Comments welcome ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] parsing gml
A few more for the mix: - GMLReader - this is the jts reader - XmlSimpleFeatureParser - StreamingParserFeatureReader On 31/05/2010, at 4:44 PM, Jody Garnett wrote: > Time has come for me to tackle one of Micaheal's requests from a couple > months ago ... How do we parse/encode GML. > > To start with I have asked a few co-workers that have tried GeoTools parsing > lately. Mostly I got a list of ways that do not work. Interestingly they all > share an approach in common ... > > Typing in the IDE and using command completion to come up with things like: > - GMLParsing - this is actual a demo of how to parse using GMLConfiguration > - FeatureCollectionParser - actually part of the implementation of WFS 1.1.0 > - GML configuration for GML2 extending XSD > - GML configuration for GML3 extending XSD > - GML configuration for GML3.2 extending XSD > - GML configuration for WCS extending XSD > - GMLParsingUtils - used internally by the GML2 bindings > - GMLFeatureCollection - returned by WFS 1.0 implementation from FCBuffer > - etc... > > So the only thing I can do in these cases is improve the javadocs to point > people in the correct direction. > > Jody -- ___ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
