Pursuant to this conversation, I have fixed all FeatureWriter
implementations in geotools to conform to the same behavior for next() and
hasNext().
See https://github.com/geotools/geotools/pull/689
Torben
On Wed, Jan 14, 2015 at 5:53 PM, Jody Garnett jody.garn...@gmail.com
wrote:
I would mimic
I have done so.
Regards
Niels
On 15-01-15 18:21, Sampo Savolainen wrote:
Hi,
Can you push the rebased branch so I can test the exact same version?
Sampo
On Jan 15, 2015 5:37 PM, Niels Charlier ni...@scitus.be wrote:
Hello Sampo,
I cannot reproduce this error. I have rebased everything.
Hi,
Can you push the rebased branch so I can test the exact same version?
Sampo
On Jan 15, 2015 5:37 PM, Niels Charlier ni...@scitus.be wrote:
Hello Sampo,
I cannot reproduce this error. I have rebased everything. I can use the
mentioned file to create a datastore in geoserver.
Regards,
Hello Sampo,
I cannot reproduce this error. I have rebased everything. I can use the
mentioned file to create a datastore in geoserver.
Regards,
Niels
On 15-01-15 12:02, Sampo Savolainen wrote:
Hi,
This should happen when adding a wfs-ng store using the mentioned test
GetCapabilities file.
While migrating MemoryDataStore to extend ContentDataStore, I have
discovered that ContentDataStore does not conform to the Geotools query API:
Query has two CRS variables:
coordinateSystem;
The coordinate system to apply to features retrieved by this Query.
This denotes a request to
See http://ares.opengeo.org/jenkins/job/geotools-master/520/changes
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
In order to fix the problems with ContentFeatureSource, changes are
required to ContentFeatureSource.getBounds(Query) and
ContentFeatureSource.getReader(Query). Fixing getBounds is relatively easy,
but it looks like getReader is a bit more difficult.
Basic reprojection is handled by
AbstractDataStore had a ForceCoordinateSystemIterator
https://github.com/geotools/geotools/blob/master/modules/library/main/src/main/java/org/geotools/data/crs/ForceCoordinateSystemIterator.java
and
there is a ForceCoordinateSystemFeatureReader
The tests assume your locale for the timezone, which I think is the problem
- for anyone East of me it will work but could well fail for people to the
West :-)
Ian
On Wed Jan 14 2015 at 11:05:20 PM Jody Garnett jody.garn...@gmail.com
wrote:
Got no real insight here Ian. The one using a Data
Hello everyone,
I need to modifiy an existing function or create a new one in order to set
dynamically color of a polygon with features as data input. I tried some
things but I can't test them because I can't compile them. Well I can
compile but the new function doesn't appear in geoserver
Hi,
This should happen when adding a wfs-ng store using the mentioned test
GetCapabilities file. If it works for you, then I guess something goes
wrong when rebasing the branch.
Sampo
On Thu, Jan 15, 2015 at 12:42 PM, Niels Charlier ni...@scitus.be wrote:
Hello Sampo,
Can you clarify
Title: Message Title
Ian Turton created an issue
See http://ares.opengeo.org/jenkins/job/geotools-master/519/changes
Changes:
[lago.88] [GEOT-4965] Enable/Disable Advanced Projection Handling for the
GridCoverageRenderer
--
[...truncated 133422 lines...]
[ERROR]
13 matches
Mail list logo
