On 26/09/12 16:58, Andrea Aime wrote:
On Wed, Sep 26, 2012 at 5:49 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au mailto:ben.caradoc-dav...@csiro.au wrote:
tb.setCRS(CRS.decode(EPSG:__4326, true))
I will push it if it resolves the issue.
I agree this should be the way to decode
On Wed, Sep 26, 2012 at 5:49 AM, Ben Caradoc-Davies
ben.caradoc-dav...@csiro.au wrote:
Justin,
all the test data is in longitude/latitude order (the roads set is similar
and labelled with Manhattan street names!). LabelObstacleTest was broken
because it was setting up the fixture data with:
Justin,
the change to MemoryDataStore getBounds [GEOT-4258] seems to flip the
axis order in LabelObstacleTest.testLineWithGraphicStroke. This
currently causes this test to fail if perceptualdiff is installed.
https://jira.codehaus.org/browse/GEOT-4268
Justin or Andrea, if this new behaviour is
Hmmm... I am not sure. As I understand it the patch is causing
DataStore.getBounds() to return a non null crs, using the one coming from
the feature type. So the issue may be the feature type for some reason is
returning a yx crs? The feature types can be added in a number of ways to
memory
The new output looks wrong to me. The test data lines2.txt looks like
longitude/latitude (e.g. -74.006489411824,40.736447976612), somewhere in
Manhattan (not Colorado Trail as labelled; if latitude/longitude it is
in Antarctica).
The envelope is:
ReferencedEnvelope[-74.006489411824 :
Justin,
all the test data is in longitude/latitude order (the roads set is
similar and labelled with Manhattan street names!). LabelObstacleTest
was broken because it was setting up the fixture data with:
SimpleFeatureTypeBuilder tb = ...
tb.setSRS(epsg:4326);
which does not force longitude
