Hi Simone,
I'm in agreement that this issue needs to be resolved. The problem
is that I'm not 100% sure how to solve the problem. Do you have a
suggestion? I apologize if you have put you suggestion in this
email, I must have missed it.
Jesse
On 19-May-06, at 8:51 AM, Simone Giannecchini wrote:
> Hi list,
> this email is a follow-up of an informat chat I had with Jody a
couple
> of days ago about a problem I might have found which has
consequences
> for the use of all EPSG Authorities, Rendering and initially
> Shapefile.
> This issue is a BLOCKER issue for merging back to trunk, I hope at
> least Jesse, Martin and Dave will give some feedback and propose
> solutions.
>
> Here is the thing.
>> Antefact<
> Me and Alessio always use the EPSG-HSQL or EPSG-Postgresql as
> authority data source, we neve use the epsg-wkt.
>
>> Problem<
> I have developed a coverage plugin which is able to read and put
> together a mosaic of image. It uses a shapefile as a catalog
storing
> for each image, the envelope as the geometry of the shape itself
and
> the location of the image on disk.
>
> When I connect to the catalog shapefile using EPSG:4326 Lat,Lon
as a
> CRS (the originating images where in WGS84 as well) and I try to
get
> the envelope of the loaded features, I get a JTS envelope with
lon,lat
> values while the CRS is Lat,Lon.
>
> Is this the expected behaviour, is this a bug, is this stupid me
> asking useless questions?
>
> Should I assume that features in EPSG:4326 are always Lon,Lat
even if
> the CRS claims to be Lat,Lon?
> Should I assume that features are ALWAYS lon,lat?
>
> This last question comes specifically adter having worked for a
while
> on the streaming renderer where most methods assume that the
envelope
> are ALWAYS lon,lat. Just take a look as an instance to the helper
> methods in the RenderUtilities class and you will see what I mean.
>
>> Consequences<
> This issue greatly impact the StreamingRenderer for example and
> reprojections as well. If I use EPSG-HSQL and I try to reproject an
> envelope got from a set of features, results are pretty
unpredictable
> depdending on the axis order of the CRS.
>
>> Objective<
> I would like to know what the maintainers of the various features
> modules think about what I said, especially if I should always
expect
> to see features in lon,lat for EPSG:4326.
>
>> Comments<
> Jody pointed out that EPSG:4326 in OGC context should always be
> lon,lat and suggested to write an authorithy to handle that. I
think
> it is a good solution in the mdeium term but not in the short term,
> therefore I propose a quick hack for the short term and the
authority
> for the mid-long term. He was also proposing on using the OGC
new way
> for asking CRS, which is by URI.
>
>
> Martin already implemented the OrderedAxisAuthorityFactory which
> should take care of this. I used it and I have to say that it works
> fine except that if I ask for an EPSG:4326 crs it gives,
correctly, a
> lon,lat WGS84 but with no identifiers related to EPSG, so
basically it
> is just a simple WGS84 geographic CRS with lon,lat axis and no
> authorithy identification. This is not suitable for most use
cases in
> GeoServer since I need the Authority in order to be able to use the
> code in GetCapabilities and such.
> Point is that if I ask an EPSG:4326 CRS, I want an EPSG:4326 CRS, I
> find strange that I get instead something that, at least
formally, is
> not EPSG:4326 ( I hope I made my point clearly, but I doubt it).
> I think that with some adjustmens this OrderedAxisAuthorityFactory
> could act as what Jody needed, we would just have to add suport for
> URI.
>
> David is going to refactor the streaming renderer shortly, I
think it
> would be worth to tackle this problem before he start doing his
job,
> which btw is great since performances of the StreamingRenderer has
> improved a lot.
>
> Grazie,
> Simone.
