[Geoserver-devel] Blocking Issue affecting CRS, features and streaming renderer.

GeoServer GeoServer Developer
1

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.

2

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.

3

Ciao Jesse,
before talking about a solution, I would first like to have some
answers from the module mantainers of the features plugins to thee two
questions:

1>Can I assume that features in EPSG:4326 are always Lon,Lat even if
the CRS claims to be Lat,Lon as it happens with EPSG-HSQL authority?
2>Can I assume that features are ALWAYS lon,lat?

Thanks guys,

Simone.
On 5/19/06, Jesse Eichar <jeichar@anonymised.com> wrote:

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.

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

4

Simone,

On May 19, 2006, at 11:26 AM, Simone Giannecchini wrote:

Ciao Jesse,
before talking about a solution, I would first like to have some
answers from the module mantainers of the features plugins to thee two
questions:

1>Can I assume that features in EPSG:4326 are always Lon,Lat even if
the CRS claims to be Lat,Lon as it happens with EPSG-HSQL authority?

Question for you: how do you define the CRS of your Shapefile? The problem here is not the CRS definition, it is the fact that your Shapefile probably stores the data on disk at lon/lat. And then you tell the datastore via your CRS definition (EPSG:4326) that it is lat/lon. Maybe you should use the "official" EPSG number of "WGS 84 with reversed axes" which is, wait for it... 63266405. You can tell they added these entries under duress, can't you?

2>Can I assume that features are ALWAYS lon,lat?

Well, it seems best to assume the features are always in the order you say they are. When you say they are 4326, you are saying that they are lat/lon. So stop saying that :slight_smile:

It is worth noting that a plain .prj file with a simple WKT description of WGS 84 will work perfectly well, because the default interpretation of WKT in geotools, if axis order is *not* specified is to use an x/y (lon/lat) ordering (thanks Martin!)

Paul

Thanks guys,

Simone.
On 5/19/06, Jesse Eichar <jeichar@anonymised.com> wrote:

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.

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

5

Just for fun, here's the record for 63266405:

coord_ref_sys_code | 63266405
coord_ref_sys_name | WGS 84 (deg)
area_of_use_code | 1262
coord_ref_sys_kind | geographic 2D
coord_sys_code | 6405
datum_code |
source_geogcrs_code | 4326
projection_conv_code | 101
cmpd_horizcrs_code |
cmpd_vertcrs_code |
crs_scope | Used by the GPS satellite navigation system. Recommended
coordinate axis representation for computer interchange.
remarks | See CRS code 4326 for recommended coordinate axis represe
ntation for the human interface.
information_source | EPSG
data_source | EPSG
revision_date | 2002-11-22
change_id |
show_crs | 0
deprecated | 1

Unfortunately it has a deprecated flag! I don't know *what* they expect people to use for WGS84 data in Lon/Lat order now...

P.

On May 19, 2006, at 1:21 PM, Paul Ramsey wrote:

Simone,

On May 19, 2006, at 11:26 AM, Simone Giannecchini wrote:

Ciao Jesse,
before talking about a solution, I would first like to have some
answers from the module mantainers of the features plugins to thee two
questions:

1>Can I assume that features in EPSG:4326 are always Lon,Lat even if
the CRS claims to be Lat,Lon as it happens with EPSG-HSQL authority?

Question for you: how do you define the CRS of your Shapefile? The problem here is not the CRS definition, it is the fact that your Shapefile probably stores the data on disk at lon/lat. And then you tell the datastore via your CRS definition (EPSG:4326) that it is lat/lon. Maybe you should use the "official" EPSG number of "WGS 84 with reversed axes" which is, wait for it... 63266405. You can tell they added these entries under duress, can't you?

2>Can I assume that features are ALWAYS lon,lat?

Well, it seems best to assume the features are always in the order you say they are. When you say they are 4326, you are saying that they are lat/lon. So stop saying that :slight_smile:

It is worth noting that a plain .prj file with a simple WKT description of WGS 84 will work perfectly well, because the default interpretation of WKT in geotools, if axis order is *not* specified is to use an x/y (lon/lat) ordering (thanks Martin!)

Paul

Thanks guys,

Simone.
On 5/19/06, Jesse Eichar <jeichar@anonymised.com> wrote:

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.

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

6

Simone Giannecchini a écrit :

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.

The lack of authority identification is intentional. My interpretation was that if OrderedAxisAuthorityFactory modifies the axis order, it would be incorrect to claim that the returned CRS is EPSG:4326. So OrderedAxisAuthorityFactory intentionally remove the authority identification before to returns the transformed CRS. However, if it is a problem, we may revisit that (or make it optional). But we would still have a philosophical issue: is it correct to keep an "EPSG:4326" identification on something that is not anymore EPSG:4326 (well, not strictly speaking - I realize that common usage still call that EPSG:4326).

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.

I can' resist to the tentation to remind that J2D-render was handling correctly axis swapping for years (but lack Feature and Style support, I admit)...

  Martin.

7

Jesse Eichar wrote:

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.

If I can be so bold, here is the solution I was aiming for:
1. trust the CRS to be correct when looking at features data or rendering etc...
2. allow the user to specify the CRS unambiguously - produce the two needed authority factories so they can do this:
- "EPSG:4326" means "wms style", in the ordinate order ready to draw on the screen (x first, y second)
- "http://www.opengis.net/gml/*srs*/*epsg*.xml/#4326&quot; means EPSG database style, in the ordinate order indicated in the EPSG database

Please do not insert hacks through out the code base to cover up from what is really a specification error - make our library good and give users the tools they need to be explicit.

Cheers,
Jody

8

Ciao Martin, thanks for the reply,

On 5/20/06, Martin Desruisseaux <martin.desruisseaux@anonymised.com> wrote:

Simone Giannecchini a écrit :
> 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.

The lack of authority identification is intentional. My interpretation was that if
OrderedAxisAuthorityFactory modifies the axis order, it would be incorrect to >claim that the
returned CRS is EPSG:4326. So OrderedAxisAuthorityFactory intentionally >remove the authority
identification before to returns the transformed CRS. However, if it is a problem, >we may revisit
that (or make it optional). But we would still have a philosophical issue: is it >correct to keep an
"EPSG:4326" identification on something that is not anymore EPSG:4326 (well, >not strictly speaking -
I realize that common usage still call that EPSG:4326).

Well, I looked up the code of that class and I noticed that you strip
some info and change some other when reordering the axis. This actions
are understandable but I am more concerned with what common practice
and OGC says about this thing. I am pretty sure that in gdal (which
uses Proj) EPSG:4326 is lon,lat as expected, moreover Jody told me
that OGC, after a long debat, now states that EPSG:4326 is lon,lat and
not lat,lon as EPSG db (please Jody help me here).
What I suggest is having an authority that tries to follow OGC
convention and common convention and probably without making it the
default one (although I personally would like to do it), in order to
have CRSs behave as expected: if I ask EPSG:4326 I would like to see
lon,lat instead of lat,lon and, morevoer, once I get this crs and I
ask for the code I want to get 4326 not "modified axis whatever" :slight_smile: .

> 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.

I can' resist to the tentation to remind that J2D-render was handling correctly axis swapping for
years (but lack Feature and Style support, I admit)...

Do not worry Martin, I am looking at the code of the J2DRenderer and I
am also looking at the new classes you are developing in order to
remove any possible wrong assumption regarding the axes order in
StremingRenderer, but the issue we are discussin here is affecting us
all, feature, coverage and renderers. No matter how careful you are
with checking axes order, if the axes order is wrong you'll neve make
things right.

Good news is, I might have found a guy to do his master thesis on
advanced geospatial rendering. I would like to reuse your experience,
the GO1 code, the old J2DRenderer code and a bit of my experience. He
should start in september, let's hope tht we get this thing going.

Simone.

       Martin.

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

9

Simone Giannecchini wrote:

Well, I looked up the code of that class and I noticed that you strip
some info and change some other when reordering the axis. This actions
are understandable but I am more concerned with what common practice
and OGC says about this thing. I am pretty sure that in gdal (which
uses Proj) EPSG:4326 is lon,lat as expected, moreover Jody told me
that OGC, after a long debat, now states that EPSG:4326 is lon,lat and
not lat,lon as EPSG db (please Jody help me here).

I think you will find my last email is explicit on the topic, let me know if
you need more help beyond that?

Cheers,
Jody

10

Ahh yes - dont we always get into trouble when we get poor separation of concerns!

The problem is that axis order is a representation issue, and the rest of the CRS is a definition of the geometry.

The use of the EPSG code as (an) authority to carry the definition for OGC protocol usage was independent of the serialisation of axis order. Some time after this practice (defensible) was established, and demonstrated pragmatic utility, a number of OGC heavyweights decided that we needed to take the whole representation + definition semantics and change (almost) everything.

The issues - it doent match actual practice (at the time, we now how a mixture I suspect) and WMS BBOX was somehow exempted.

The solution might have been trivial - declare that the representation was to be ignored, in favour of consistent lon/lat, and allow for an optional explicit representational syntax to be declared in the protocol where representations matter. SRS= axis_order= microformat=DMS

CRS:84 I think has been defined by the OGC - maybe we lobby for an effort to move all existing WMS services to supporting it.

Rob A

Paul Ramsey wrote:

Just for fun, here's the record for 63266405:

coord_ref_sys_code | 63266405
coord_ref_sys_name | WGS 84 (deg)
area_of_use_code | 1262
coord_ref_sys_kind | geographic 2D
coord_sys_code | 6405
datum_code |
source_geogcrs_code | 4326
projection_conv_code | 101
cmpd_horizcrs_code |
cmpd_vertcrs_code |
crs_scope | Used by the GPS satellite navigation system. Recommended
coordinate axis representation for computer interchange.
remarks | See CRS code 4326 for recommended coordinate axis represe
ntation for the human interface.
information_source | EPSG
data_source | EPSG
revision_date | 2002-11-22
change_id |
show_crs | 0
deprecated | 1

Unfortunately it has a deprecated flag! I don't know *what* they expect people to use for WGS84 data in Lon/Lat order now...

P.

On May 19, 2006, at 1:21 PM, Paul Ramsey wrote:

Simone,

On May 19, 2006, at 11:26 AM, Simone Giannecchini wrote:

Ciao Jesse,
before talking about a solution, I would first like to have some
answers from the module mantainers of the features plugins to thee two
questions:

1>Can I assume that features in EPSG:4326 are always Lon,Lat even if
the CRS claims to be Lat,Lon as it happens with EPSG-HSQL authority?

Question for you: how do you define the CRS of your Shapefile? The problem here is not the CRS definition, it is the fact that your Shapefile probably stores the data on disk at lon/lat. And then you tell the datastore via your CRS definition (EPSG:4326) that it is lat/lon. Maybe you should use the "official" EPSG number of "WGS 84 with reversed axes" which is, wait for it... 63266405. You can tell they added these entries under duress, can't you?

2>Can I assume that features are ALWAYS lon,lat?

Well, it seems best to assume the features are always in the order you say they are. When you say they are 4326, you are saying that they are lat/lon. So stop saying that :slight_smile:

It is worth noting that a plain .prj file with a simple WKT description of WGS 84 will work perfectly well, because the default interpretation of WKT in geotools, if axis order is *not* specified is to use an x/y (lon/lat) ordering (thanks Martin!)

Paul

Thanks guys,

Simone.
On 5/19/06, Jesse Eichar <jeichar@anonymised.com> wrote:

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.

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd_______________________________________________

Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

11

Ciao Jody,
let me summarize as you did:
1>I absolutely agree. As Martin pointed out we should NEVER make any
assumptions on the axes order but lawys inspect it int the data we are
managing and behave coherently.

Having different CRS definitions in different authorities is of course
a big problems since at that point, even if you do not tae any
assumptions on how the data is organized, you might run into problems
since the axis order itself could not match the data organization.
Hence we need to have coherent CRS definitions at least in the same
field of usage.

2>I agree, and especially for the first one it should be use to do
that modifying a bit the OrderedAxisAuthorityFactory we already have.

A not on hacks. I personally hate hacks and I really would love to
tackle problems once for all and in a coherent way. This is why I
started this discussion bugging everybody around.
My opinion is that if we want to solve this issue we need to get
everydoy who is interested to express his opinion in order to avoid
using hacks!

I am pretty sure that in the ends putting in place an initial solution
will be simple, but again, we need to have everybody knows about the
problem and the solution, otherwise nobody will exploit the solution
itself.

I hope I made my point clearly :-).

SImone.

On 5/20/06, Jody Garnett <jgarnett@anonymised.com> wrote:

Jesse Eichar wrote:
> 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.
If I can be so bold, here is the solution I was aiming for:
1. trust the CRS to be correct when looking at features data or
rendering etc...
2. allow the user to specify the CRS unambiguously - produce the two
needed authority factories so they can do this:
- "EPSG:4326" means "wms style", in the ordinate order ready to draw on
the screen (x first, y second)
- "http://www.opengis.net/gml/*srs*/*epsg*.xml/#4326&quot; means EPSG
database style, in the ordinate order indicated in the EPSG database

Please do not insert hacks through out the code base to cover up from
what is really a specification error - make our library good and give
users the tools they need to be explicit.

Cheers,
Jody

--
°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°
Simone Giannecchini
Software Engineer
Freelance Consultant

http://simboss.wordpress.com/

°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°°

12

On 5/20/06, Jody Garnett <jgarnett@...12...> wrote:

Jesse Eichar wrote:
> 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.
If I can be so bold, here is the solution I was aiming for:
1. trust the CRS to be correct when looking at features data or
rendering etc...

Sure, although at the moment we work to agree on what is "correct".

2. allow the user to specify the CRS unambiguously - produce the two
needed authority factories so they can do this:
- "EPSG:4326" means "wms style", in the ordinate order ready to draw on
the screen (x first, y second)

I am in agreement here. A lot of mapping applications expect
longitude first, latitude second, leading us to think in terms of
intuitive x,y order (not lat/lon).

Alex

13

Rob Atkinson a écrit :

CRS:84 I think has been defined by the OGC - maybe we lobby for an effort to move all existing WMS services to supporting it.

As a side note, "CRS:27", "CRS:83" and "CRS:84" are supported straight into module/referencing since Geotools 2.2. They are equivalent to "NAD27", "NAD83" and "WGS84" respectively, but with (longitude, latitude) axis order (as specified by OGC).

So a workaround maybe applicable right now is to use "CRS:84" instead of "EPSG:4326" when someone wants a "WGS 84" CRS with (longitude, latitude) axis order.

  Martin.

14

Simone Giannecchini a écrit :

Good news is, I might have found a guy to do his master thesis on
advanced geospatial rendering. I would like to reuse your experience,
the GO1 code, the old J2DRenderer code and a bit of my experience. He
should start in september, let's hope tht we get this thing going.

Very nice! As a side note, we might have (really not sure - still under discussion) some students working on a 3D renderer in the comming year. 2D and 3D renderers would be really two different beasts (but hopefully both built on top of the same interfaces), so they should not overlaps.

  Martin.

15

Simone Giannecchini a écrit :

I am pretty sure that in gdal (which
uses Proj) EPSG:4326 is lon,lat as expected, moreover Jody told me
that OGC, after a long debat, now states that EPSG:4326 is lon,lat and
not lat,lon as EPSG db (please Jody help me here).

If this is an OGC decision, then the EPSG factory needs to be updated in order to comply with it. Does someone has a link to the OGC decision? (the last OGC meeting I attended was in september 2005; at that time, such decision was not yet taken. I would like to see if OGC make some recommandations like (longitude,latitude) order optional in some cases, or mandatory in all cases, etc.).

What I suggest is having an authority that tries to follow OGC
convention and common convention and probably without making it the
default one (although I personally would like to do it), in order to
have CRSs behave as expected: if I ask EPSG:4326 I would like to see
lon,lat instead of lat,lon and, morevoer, once I get this crs and I
ask for the code I want to get 4326 not "modified axis whatever" :slight_smile: .

A problem is that, even if "EPSG:4326" as (longitude,latitude) is consistent with OGC, it is inconsistent with other tables in the EPSG database like "Coordinate_Operations", which may lead to some problems. If a user looks into the "Coordinate_Operations" table from the EPSG database for a transformation path from "EPSG:4326" to "EPSG:whateber" - or in GeoAPI words, if he invokes

   CoordinateOperationAuthorityFactory.createFromCoordinateReferenceSystemCodes("4326", "whatever");

then the user get a CoordinateOperation from "4326" to "whatever" built from the information provided in the EPSG database. But of course, the coordinate operations defined in EPSG are consistent with the EPSG definitions of CRS, which are inconsistent with the user CRS if axis order were inverted.

Well - we could make the referencing module yet more complex by switching the CoordinateOperation axis as well as CRS. But similar burden may apply to every users wanting to look into the EPSG database by themself. The removal of the authority code was an attempt to avoid misleading such users.

There is some proposals in no particular order. Lets see which one may work the best:

1) Always use (longitude,latitude) axis order and keep authority code unchanged (e.g. "EPSG:4326").

2) Change the authority code into something easy to parse (but non-standard), e.g. "WGS:EPSG:4326",
    in order to avoid the above-cited confusion risk but still allowing applications to get the
    authority code. Keep all other properties (e.g. the plain English name) unchanged.

3) Creates GeographicCRS with (latitude,longitude) axis as specified in the EPSG database, and
    wrap them into a DerivedCRS with (longitude,latitude) axis order with same properties
    (including same EPSG code).

        pros: - Users can know if the CRS is as defined in the EPSG database or a modified CRS by
                checking 'if (crs instanceof GeographicCRS)' or 'if (crs instanceof DerivedCRS)',
                even if the CRS has the same EPSG code. DerivedCRS already exists in Geotools, and
                the "DerivedCRS" name is rather explicit. So the distinction between "original" and
                "modified" CRS would be obvious on a programmatic point of view, while using the same
                authority code.

              - If the CRS is a DerivedCRS, users can get the original CRS with (latitude,longitude)
                axis order by invoking DerivedCRS.getBaseCRS(). This capability is not available with
                proposals #1 and 2 above.

        cons: - A (longitude,latitude) CRS is not immediately visible as a GeographicCRS to users.
                Users need to be aware of this GeographicCRS / DerivedCRS usage, which would be (I
                guess) non-standard. Note: if we feel that this aproach is the best one, maybe we
                could submit an explicit GeoAPI interface (as a DerivedCRS sub-interface) to OGC.

  Martin.

16

Martin Desruisseaux wrote:

Simone Giannecchini a écrit :

Good news is, I might have found a guy to do his master thesis on
advanced geospatial rendering. I would like to reuse your experience,
the GO1 code, the old J2DRenderer code and a bit of my experience. He
should start in september, let's hope tht we get this thing going.

Very nice! As a side note, we might have (really not sure - still under discussion) some students working on a 3D renderer in the comming year. 2D and 3D renderers would be really two different beasts (but hopefully both built on top of the same interfaces), so they should not overlaps.

We have a SoC application set up to do a 3D renderer based off of the uDig rendering model. So perhaps we can combine forces or have your students take over the work?

Jody

17

Martin Desruisseaux wrote:

Simone Giannecchini a écrit :

I am pretty sure that in gdal (which
uses Proj) EPSG:4326 is lon,lat as expected, moreover Jody told me
that OGC, after a long debat, now states that EPSG:4326 is lon,lat and
not lat,lon as EPSG db (please Jody help me here).

If this is an OGC decision, then the EPSG factory needs to be updated in order to comply with it. Does someone has a link to the OGC decision? (the last OGC meeting I attended was in september 2005; at that time, such decision was not yet taken. I would like to see if OGC make some recommandations like (longitude,latitude) order optional in some cases, or mandatory in all cases, etc.).

It was a decision for OWS-3, I am not sure if the papers were published from that yet. It was the solution that annoyed everyone but was fair and allowed a path forward while maintaining compatibility with all but one WMS in the wild.

Jody