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 first. This was unnoticed until the
MemoryDataStore fix by Sebastian Graca [GEOT-4257]. I am testing a patch
that changes LabelObstacleTest to use:
tb.setCRS(CRS.decode("EPSG:4326", true))
I will push it if it resolves the issue.
Kind regards,
Ben.
On 26/09/12 11:24, Ben Caradoc-Davies wrote:
> 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 : -73.995774954312, 40.730909351849
> : 40.740632177853]
>
> but the envelope CRS is latitude/longitude:
>
> GEOGCS["WGS 84",
> DATUM["World Geodetic System 1984",
> SPHEROID["WGS 84", 6378137.0, 298.257223563,
> AUTHORITY["EPSG","7030"]],
> AUTHORITY["EPSG","6326"]],
> PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
> UNIT["degree", 0.017453292519943295],
> AXIS["Geodetic latitude", NORTH],
> AXIS["Geodetic longitude", EAST],
> AUTHORITY["EPSG","4326"]]
>
> This looks wrong, as if the axes are being flipped in the data.
>
> On 25/09/12 22:51, Justin Deoliveira wrote:
>> 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 datastore so I guess we will have to look at this
>> specific case and see if (a) there is a flip occurring when it shouldn't
>> be or (b) determine if the test was broken before and the flip is the
>> correct action.
>>
>> On Tue, Sep 25, 2012 at 1:21 AM, Ben Caradoc-Davies
>> <ben.caradoc-dav...@csiro.au <mailto:ben.caradoc-dav...@csiro.au>> wrote:
>>
>> 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
>> <https://jira.codehaus.org/browse/GEOT-4268>
>>
>> Justin or Andrea, if this new behaviour is correct, please let me
>> know so I can fix the build for those with perceptualdiff by
>> updating the reference image.
>>
>> Kind regards,
>>
>> --
>> Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
>> Software Engineer
>> CSIRO Earth Science and Resource Engineering
>> Australian Resources Research Centre
>>
>>
>>
>>
>> --
>> Justin Deoliveira
>> OpenGeo - http://opengeo.org
>> Enterprise support for open source geospatial.
>>
>
--
Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
