From: Martin D. <mar...@no...> - 2006-05-22 23:18:19
|
Openned a JIRA task http://jira.codehaus.org/browse/GEOT-854 Comments welcome (especially any implication that may come to your mind). Martin. |
From: Bryce L N. <bno...@fs...> - 2006-05-23 18:46:20
|
geo...@li... wrote on 05/22/2006 05:18:00 PM: > Openned a JIRA task > > http://jira.codehaus.org/browse/GEOT-854 > > > Comments welcome (especially any implication that may come to your mind). > > Martin. Done. Key points: 1] Addressing an encoding issue with an authority factory is now, and forever will be, a hack. Many hacks, actually. Everywhere in the code. 2] Distinguishing between reversed and correct encoding cannot be accomplished with software. This problem will never be solved programmatically. 3] GT should not be assuming _anything_ for the human who can _see_ that the axes are reversed. However, GT should make it easy for application writers to offer humans a minimum-effort way to adapt to well-understood broken data. 4] Address encoding issues with a polymorphic DataStore decorator which can substitute the incorrect CRS definition from the file with a correct definition of our choice. This constrains the modifications to a particular well defined class, forces application writers to take an action to "disbelieve" data, and makes it easy to do the "disbelieving" once it has been deemed necessary. All other modules, all other code, all other assumptions are specified according to ISO 19111/OGC Topic 2. 5] Invert #4 for writing broken data to be used with other broken (inferior) applications. |
From: Martin D. <mar...@no...> - 2006-05-23 22:25:12
|
Bryce L Nordgren a =E9crit : > 1] Addressing an encoding issue with an authority factory is now, and > forever will be, a hack. Many hacks, actually. Everywhere in the code= . I agree and hope to avoid such hack. The first step I'm considering is to= make Geotools referencing=20 code a little bit more "paranoiac", i.e. don't trust the authority code, = always check the axis (when=20 available) no matter what the authority code is. My first experiences with GEOT-854 show that misleading EPSG codes (i.e. = user-specified CRS that=20 claims to be an authority-specified CRS but actually uses different axis = order) leads to infinite=20 recursion loop in the referencing code until the application crash with a= StackOverflowError. I will=20 try to fix that - this is part of my "make Geotools paranoiac" strategy m= entioned above. We can make Geotools more robust to this axis order issue, but one proble= m is that we can't expect=20 users to be as paranoiac. The infinite recursion loop encounter in Geotoo= ls could happen in some=20 user code too. To make a short story, it was caused by CoordinateOperatio= nFactory receiving two CRS=20 with different axis order (the user CRS and the authority CRS), and invok= ing (indirectly) itself=20 again and again with the same CRS because they have the same authority co= de, in an attempt to find=20 the transformation path between those two CRS with the same authority cod= e but actually different. > 2] Distinguishing between reversed and correct encoding cannot be > accomplished with software. This problem will never be solved > programmatically. I agree too. But in the particular case of this issue, the axis swapping = is not random. It happen=20 (if I'm understanding correctly) for all data around the world used in th= e context of OGC WMS. If we agree than starting from now, "EPSG:whatever" should be understood = as being always=20 (longitude,latitude) axis order (as OGC decided recently in my understand= ing of a recent Jody's=20 mail), then it is a new authority factory derived from the previours "EPS= G" (to be renamed) one and=20 we get determined behavior. The problem is that in practice, we will have= the two interpretations of=20 "EPSG" floating around in the same application (at least because the EPSG= database used for creating=20 CoordinateOperation uses of course the original EPSG definition), leading= to the problem described=20 above. The work I'm currently doing in the referencing module is rather "= make Geotools paranoiac"=20 than "add some hacks". Martin. |
From: Bryce L N. <bno...@fs...> - 2006-05-23 23:04:09
|
Martin Desruisseaux <mar...@no...> wrote on 05/23/2006 04:24:55 PM: > If we agree than starting from now, "EPSG:whatever" should be > understood as being always > (longitude,latitude) axis order (as OGC decided recently in my > understanding of a recent Jody's > mail), then it is a new authority factory derived from the previours I wouldn't agree to that. Now we cannot handle data which correctly declares that it is EPSG:4326. Same problem different direction. Even if *I* agreed to that, *I* don't make data. For this to work, all data producers in the world need to agree to this convention. The source of the problem is "out in the world somewhere", is not party to this discussion, and hence will remain ignorant of any agreements made on this list. GT will continue to encounter both axes orderings using the same moniker, and it is not our place to decide which is right or wrong. GT _should_ make it easy to write an app. that lets a human choose the correct axes order regardless of what the file claims. > The work I'm currently doing in the referencing module is > rather "make Geotools paranoiac" > than "add some hacks". My point was that the CRS in the file does not have to be the CRS returned by the DataSource. The referencing module should not be involved, except perhaps to provide a DerivedCRS which swaps axes from the BaseCRS (...and returns a DerivedOperation which swaps axes, etc.). Every module except the Data Sources should trust that the CRS provided is accurate. Data Sources should adopt a convention of either trusting files or not trusting files, but honoring a human override in either case. But what it boils down to is: if we're solving this problem using the referencing module, it's a hack. (Even if it's a well-written hack) This problem needs to be addressed at the point data enters the system. Bryce |
From: Martin D. <mar...@no...> - 2006-05-24 01:35:46
|
Bryce L Nordgren a =E9crit : >> If we agree than starting from now, "EPSG:whatever" should be understo= od as being always >> (longitude,latitude) axis order (as OGC decided recently in my underst= anding of a recent >> Jody's mail), then it is a new authority factory derived from the prev= ious one >=20 > I wouldn't agree to that. Now we cannot handle data which correctly > declares that it is EPSG:4326. Same problem different direction. My understanding (please Jody correct me if I'm wrong) is that: 1) "EPSG:whatever =3D (longitude,latitude) axis order no matter what the = EPSG database said" is now a formal OGC decision, and every OGC-compliant data sources in= the world should comply with it. 2) About every OGC data sources in the world are already using the above-= cited convention, because of the (broken) way the OGC's WMS specification was wrote. Ac= tually, the above- cited OGC's decision was just a recognition of the current stade of a= ffair of most data in the world. 3) If a user wants to said "EPSG code like the EPSG database really inten= ted it to be", then the authority prefix is something else than "EPSG:". It is currently = a very verbose URL (for myself, I would really like something shorter. Maybe "OGP:" sinc= e it is the new name for the EPSG organisation?). Yes I agree, it is confusing. "EPSG" sho= uld means "the real EPSG database" and some other name should means "The modified EPSG da= tabase". Unfortunatly, in my understanding of Jody's email, OGC formaly decided the opposite= (and confusing) way arround. > My point was that the CRS in the file does not have to be the CRS retur= ned > by the DataSource. The referencing module should not be involved, exce= pt > perhaps to provide a DerivedCRS which swaps axes from the BaseCRS (...a= nd > returns a DerivedOperation which swaps axes, etc.). Every module excep= t > the Data Sources should trust that the CRS provided is accurate. I fully agree. What the referencing module is trying to provide is an aut= hority factory capable to=20 creates CRS from EPSG code as OGC (and current practice) said they should= be, which are not the way=20 the EPSG database said it should be. In other words, the "OGC" definition= take precedence over the=20 "EPSG" definition for the "EPSG" name space (yes I know, this is the conf= using above-cited stuff),=20 and a new name space need to be found for the real EPSG definition (curre= ntly URL according OGC, but=20 I find them too verbose). DataStores would use this factory, since it is now the standard. All code= everywhere in Geotools and=20 client side should trust that the CRS object is accurate, as you rightly = point out. However,=20 Geotools and client code should check the full CRS object - they should n= ot trust blindly the=20 authority code. In other words, never pass an authority code as a String = argument to a method;=20 always pass a full CRS object. There is a risk of confusion only if a CRS= is described by its=20 authority code only. Otherwise, everything should stay clean. Anyway, for now I plan to keep "EPSG:whatever" as "real EPSG" for now (de= spite OGC decision) and=20 users would have to invoke OrderedAxisAuthorityFactory.register("EPSG") e= xplicitly if they wants the=20 (longitude,latitude) axis order. Martin. |
From: Jody G. <jga...@re...> - 2006-05-24 11:46:51
|
Martin Desruisseaux wrote: > Bryce L Nordgren a =E9crit : >>> If we agree than starting from now, "EPSG:whatever" should be=20 >>> understood as being always >>> (longitude,latitude) axis order (as OGC decided recently in my=20 >>> understanding of a recent >>> Jody's mail), then it is a new authority factory derived from the=20 >>> previous one >> >> I wouldn't agree to that. Now we cannot handle data which correctly >> declares that it is EPSG:4326. Same problem different direction. > > My understanding (please Jody correct me if I'm wrong) is that: > > 1) "EPSG:whatever =3D (longitude,latitude) axis order no matter what th= e=20 > EPSG database said" > is now a formal OGC decision, and every OGC-compliant data sources=20 > in the world should > comply with it. OGC is sick of the problem, it is a political problem with no good=20 solution - as such I do not expect a formal decision from them. (It is not helpful for a standards body when the real world does not=20 want to agree). The OGC has *three* solutions on the table: - "EPSG:CODE" is in easting/northing order all the time for WMS (prior=20 to WMS 1.3.0 I admit - but WMS 1.3.0 is not being implemented because of=20 this issue). - "EPSG:CODE" is in the order of the EPSG database for WMS 1.3.0=20 (someone correct me if I am wrong) - URI - is in the order of the EPSG database The reason WMS 1.3.0 is more of a mess then usual is because it is a=20 joint release with ISO. I am trying to learn as I listen to the discussion, it seems the problem=20 comes from OGC services sending us just this String, if they were=20 sending us the real CoordinateReferenceSystem definition we would all be good? The=20 CoordinateReferenceSystem object does have enough information for everyon= e, including the renderer to work correctly? > 2) About every OGC data sources in the world are already using the=20 > above-cited convention, > because of the (broken) way the OGC's WMS specification was wrote.=20 > Actually, the above- > cited OGC's decision was just a recognition of the current stade of=20 > affair of most data > in the world. Got it. > 3) If a user wants to said "EPSG code like the EPSG database really=20 > intented it to be", then > the authority prefix is something else than "EPSG:". It is=20 > currently a very verbose URL > (for myself, I would really like something shorter. Maybe "OGP:"=20 > since it is the new name > for the EPSG organisation?). Yes I agree, it is confusing. "EPSG"=20 > should means "the real > EPSG database" and some other name should means "The modified EPSG=20 > database". Unfortunatly, > in my understanding of Jody's email, OGC formaly decided the=20 > opposite (and confusing) way > arround. Got it. And frankly the OGC could not claw back the use of "EPSG:CODE"=20 there is too much infrastructure deployed around their earlier specification. They did try (for WMS=20 1.3.0) changing their mind - but industry is ignoring them. Perhaps this is the reason someone is funding additional WMS cite tests=20 this time around? >> My point was that the CRS in the file does not have to be the CRS=20 >> returned >> by the DataSource. The referencing module should not be involved,=20 >> except >> perhaps to provide a DerivedCRS which swaps axes from the BaseCRS=20 >> (...and >> returns a DerivedOperation which swaps axes, etc.). Every module exce= pt >> the Data Sources should trust that the CRS provided is accurate. Yes! Please :-) And for a best practice I would like to see us encourage the URI syntax=20 in such things as code examples. But perhaps that is me playing politics and not=20 helping solve the problem? > I fully agree. What the referencing module is trying to provide is an=20 > authority factory capable to creates CRS from EPSG code as OGC (and=20 > current practice) said they should be, which are not the way the EPSG=20 > database said it should be. In other words, the "OGC" definition take=20 > precedence over the "EPSG" definition for the "EPSG" name space (yes I=20 > know, this is the confusing above-cited stuff), and a new name space=20 > need to be found for the real EPSG definition (currently URL according=20 > OGC, but I find them too verbose). > > DataStores would use this factory, since it is now the standard. All=20 > code everywhere in Geotools and client side should trust that the CRS=20 > object is accurate, as you rightly point out. However, Geotools and=20 > client code should check the full CRS object - they should not trust=20 > blindly the authority code. In other words, never pass an authority=20 > code as a String argument to a method; always pass a full CRS object.=20 > There is a risk of confusion only if a CRS is described by its=20 > authority code only. Otherwise, everything should stay clean. > > Anyway, for now I plan to keep "EPSG:whatever" as "real EPSG" for now=20 > (despite OGC decision) and users would have to invoke=20 > OrderedAxisAuthorityFactory.register("EPSG") explicitly if they wants=20 > the (longitude,latitude) axis order. Ack, for many DataStore implementors will need to invoke that=20 OrderedAxis thing all the time? But you are quite right that the=20 responsibility to make that assumption (and provide control over it) rests at the data store level. Cheers and that for the breakdown of the issues Martin, Jody |
From: Adrian C. <ac...@gm...> - 2006-05-24 14:14:32
|
Hey all, 1) Any chance for an eventual writeup? Can you all write up whatever solution you agree on, when you reach a consensus. I presume nothing will change for 2.2 since it's trying to find its keys to get out the door. If you have a plan for 2.3 and beyond (3.0), could you wiki it? I sort of know what's going on but not enough to understand how the changes will modify the codebase from the javadocs (2.2,2.3, geoapi) which I am currently reading. 2) Would it make sense to change EPSG_WKT to GEOTOOLS_WKT? It seems the WKT authority plugin is (1) a fork and (2) altered in terms of what axes are returned. Doesn't this make it a new data source with a parallel naming scheme to the EPSG data base but different results? Wouldn't changing the authority name help clarify its distinct status? Thanks, adrian |
From: Martin D. <mar...@no...> - 2006-05-25 08:05:54
|
Added a Wiki page about the axis order issue. I wrote it mostly from the = material found in various=20 emails from Paul, Jody, Bryce and others. http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue Note: the FORCE_LONGITUDE_FIRST_AXIS_ORDER hint is not yet implemented. T= his is a proposal that may=20 change according feedback received. Adrian Custer a =E9crit : (edited) > 2) Would it make sense to change plugin/gt2-epsg-wkt to plugin/gt2-geot= ools-wkt? >=20 > It seems the WKT authority plugin is (1) a fork and (2) altered > in terms of what axes are returned. Doesn't this make it a new > data source with a parallel naming scheme to the EPSG data base > but different results? Wouldn't changing the authority name hel= p > clarify its distinct status? Maybe. The gt2-epsg-wkt plugin was wrote at a time where gt2-epsg-hsql wa= s not functional. A=20 possible path that I would like to suggest is: - See if gt2-epsg-hsql (after the axis order issue is fixed) can meet the uDig and Geoserver needs. - Refactor gt2-epsg-wkt as something like "gt2-epsg-extension", because i= t contains CRS not defined in the official EPSG database (I assume that it was in ord= er to meet some client needs). All CRS defined in "gt2-epsg-hsql" would be removed fro= m "gt2-epsg-extension", so the later would contains only custom CRS. As the name imply, it wou= ld provide an extension to the usual EPSG database. Note: EPSG explicitly allows the addition of custom CRS in some specific = code range (I forgot the=20 code range). Martin. |
From: Bryce L N. <bno...@fs...> - 2006-05-25 14:53:18
|
geo...@li... wrote on 05/25/2006 02:05:48 AM: > Added a Wiki page about the axis order issue. I wrote it mostly from > the material found in various > emails from Paul, Jody, Bryce and others. > > http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue > > Note: the FORCE_LONGITUDE_FIRST_AXIS_ORDER hint is not yet > implemented. This is a proposal that may > change according feedback received. Geez, it's kinda hard to argue with that page since I got everything I wanted. :) Seriously, that page rocks! Way to go, Martin! I like the Hints approach, and I like the new name for the hint. Bryce |
From: Jody G. <jga...@re...> - 2006-05-25 15:00:27
|
Martin Desruisseaux wrote: > Added a Wiki page about the axis order issue. I wrote it mostly from > the material found in various emails from Paul, Jody, Bryce and others. > > http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue > > Note: the FORCE_LONGITUDE_FIRST_AXIS_ORDER hint is not yet > implemented. This is a proposal that may change according feedback > received. Thanks Martin that is great, If I could also add support for the silly URI the OGC has defined that would be swell, we will start running into them over the next while - and they have the advantage of naming the EPSG database they want to refer to. Jody |
From: Martin D. <mar...@no...> - 2006-05-26 11:05:28
|
Jody Garnett a =E9crit : > If I could also add support for the silly URI the OGC has defined that=20 > would be swell, we will start running into them over the next while -=20 I added a JIRA task. Could you check if the example given in this task ar= e the one you are looking=20 for please (I found those example in some OGC spec; forgot which one)? Or= add a comment if you were=20 looking for something different? http://jira.codehaus.org/browse/GEOT-859 Martin. |
From: Jody G. <jga...@re...> - 2006-05-28 17:25:29
|
Martin Desruisseaux wrote: > Jody Garnett a =E9crit : >> If I could also add support for the silly URI the OGC has defined=20 >> that would be swell, we will start running into them over the next=20 >> while -=20 > > I added a JIRA task. Could you check if the example given in this task=20 > are the one you are looking for please (I found those example in some=20 > OGC spec; forgot which one)? Or add a comment if you were looking for=20 > something different? > > http://jira.codehaus.org/browse/GEOT-859 Thanks, think I need to check out the WFS1.1 or WMS specifications (sigh= ). Jody |
From: Bryce L N. <bno...@fs...> - 2006-05-24 17:44:58
|
Jody Garnett <jga...@re...> wrote on 05/24/2006 05:46:32 AM: > OGC is sick of the problem, it is a political problem with no good > solution - as such I do not expect a formal decision from them. > (It is not helpful for a standards body when the real world does not > want to agree). This may not be worth much, but: My observation w.r.t. the relationship between OGC and ISO is that OGC tends to produce prototype standards. They make a first cut at a problem, get a "nominal" solution out there for people to implement and test, but in the process they cut some of the wrong corners (because you just don't know which things are important before you use them.) This particular problem exists because OGC cut the wrong corner, became too popular, and now can't un-cut the corner easily. Popular vs. Right. Right will still be right tomorrow, but popular might not still be popular. ISO, on the other hand, is more interested in building a coherent, vertically integrated suite of standards. They adapt some of the prototype standards, integrate some of the lessons learned, and produce something which "fits" with the rest of the standards better. They are somewhat concerned with maintaining compatibility with what currently exists, but the priority is to fix hacks and produce something which is well-designed at the single-standard and collection-of-standards level. Put another way, ISO seems to be "version 2.0.0" of OGC standards: major API change in some cases, but changes are for the good in the long run. Obviously, this causes "distress" during the transition. However, if you want to know what you'll need to support in five years, look to ISO's activity now. > The reason WMS 1.3.0 is more of a mess then usual is because it is a > joint release with ISO. See. :) Transition. Transition hard. The OGC is the new kid on the block, and makes newbie mistakes. EPSG has been doing geodesy since before the OGC formed and their axis order follows ISO 6709, published in 1983. OGC created this particular mess by ignoring ~20 years of "accepted best practice" when they started publishing standards in ~2000. Whoops. This particular discussion is perhaps the best argument for moving to "version 2.0.0/ISO" (WMS 1.3.0) with all available speed. > - "EPSG:CODE" is in the order of the EPSG database for WMS 1.3.0 > (someone correct me if I am wrong) You're right. From ISO 19128:2005 (WMS), published by ISO on 2005-11-23: "EXAMPLE EPSG:4326 refers to WGS 84 geographic latitude, then longitude. That is, in this CRS the x axis corresponds to latitude, and the y axis to longitude." > > 2) About every OGC data sources in the world are already using the > > above-cited convention, > > because of the (broken) way the OGC's WMS specification was wrote. > > Actually, the above- > > cited OGC's decision was just a recognition of the current stade of > > affair of most data > > in the world. > Got it. Add Jody's [confirmed] observation that WMS 1.3.0/ISO 19128 is the opposite decision to this quote. And Paul Ramsey's note that all future work will abandon the currently popular convention. During transition, we should handle both. We should plan on deprecating the currently popular convention in a 2-10 year time horizon. > Got it. And frankly the OGC could not claw back the use of "EPSG:CODE" > there is too much infrastructure > deployed around their earlier specification. They did try (for WMS > 1.3.0) changing their mind - but industry > is ignoring them. As to industry's stance: Eventually an update to the WMS spec will have a feature that every manager MUST HAVE. Some IT managers right now gotta have the latest version of everything. The first company to offer a WMS >= 1.3.0 solution which is backwards compatible with previous versions will trigger a lemming landslide. Give industry a transition path and they'll grab it. Do OGC web services report the version of the spec they implement? That could be used to apply the correct interpretation of "EPSG:CODE". (now != future) > > I fully agree. What the referencing module is trying to provide is an > > authority factory capable to creates CRS from EPSG code as OGC (and > > current practice) said they should be, which are not the way the EPSG > > database said it should be. In other words, the "OGC" definition take > > precedence over the "EPSG" definition for the "EPSG" name space (yes I > > know, this is the confusing above-cited stuff), and a new name space > > need to be found for the real EPSG definition (currently URL according > > OGC, but I find them too verbose). I do not think it is appropriate to state that the OGC has made a decision on this topic. They say one thing in WMS 1.3.0/ISO 19128 and apparently they say another in previous WMS versions, and a letter or report or some other place. Rather, it is probably appropriate to say that OGC has made "both" decisions. Paul Ramsey's quote indicates that their decision is to conform to the ~23 year old practice for all future work. I would argue that OGC's inability to make a _single_ decision on this topic, coupled with their break from 23 years of best practice, plus the fact that this is definately relevant only to web services and perhaps not to features serialized to GML or some other format, and finally, their desire to "do the right (opposite) thing" from now on, speaks to the need for an adaptation layer for the EPSG namespace. I suggest that the EPSGAuthorityFactory should represent the EPSG's definitions. A middleware layer could take on the task of bidirectional authority name translation for old versions of OGC web services. This middleware should affect only the authority name, not the CRS definition. Our internal "URI" or "CRS" or "Geotools" authority namespace would hide the "real" CRS name. Or we could just make an axes swapper CRS adapter. Whatever we come up with is temporary and will be deprecated within 10 years. The thing that bothers me most is that I'm really not clear about whether the OGC's advice on this matter (such as it is) extends beyond web services to other things CRS is used for. I don't think our referencing module should be locked into one _application of_ referencing (OWS), and this seems to be the risk we're running. This middleware could be generalized to the notion of a "namespace convention translator". Using middleware, we can implement WMS 1.3.0 and previous versions with the same base code. > Ack, for many DataStore implementors will need to invoke that > OrderedAxis thing all the time? But you are quite right that the > responsibility to make that assumption > (and provide control over it) rests at the data store level. I think if we take the middleware approach, the DataStore implementors will have to apply an appropriate namespace translator or axes swapper to the CRS. Most important: you can have defaults, but a human programmer or end-user should be able to override them. The Human can tell if the axes are backwards, and the Human can read the natural language metadata. They need the power to correct an inappropriate default. I hate computers which automatically do the wrong thing and offer no way to make them do the right thing. Bryce |
From: Rob A. <ro...@so...> - 2006-05-24 22:02:59
|
Bryce L Nordgren wrote: > Jody Garnett <jga...@re...> wrote on 05/24/2006 05:46:32 AM: > > >> OGC is sick of the problem, it is a political problem with no good >> solution - as such I do not expect a formal decision from them. >> (It is not helpful for a standards body when the real world does not >> want to agree). >> > > This may not be worth much, but: > > My observation w.r.t. the relationship between OGC and ISO is that OGC > tends to produce prototype standards. OGC has adopted ISO to replace its own "abstract specification" stack. In some cases that means co-branding common specifications that OGC works on (common team members being a regular occurence). * ISO has started adopting implementation specifications - notably WMS and GML - not sure really the reasoning here, other than ISO's role of codifying "best practice". * ISO has a 5-year cycle, so OGC will always be the experimental end. I agree that ISO's standards tend to be a thought out and coherent - in practice I do all my work using the ISO models and then apply OGC as appropriate, but not at the expense of breaking the ISO models. The problem in all these things is actually resourcing deployment of a registry so you can become an authority. EPSG did this, in a vacuum, and though its model is slightly broken (representation and definition mixed). Its the resolution of the authority issue as well as implementation practice we're all waiting on. Rob A > They make a first cut at a problem, > get a "nominal" solution out there for people to implement and test, but in > the process they cut some of the wrong corners (because you just don't know > which things are important before you use them.) This particular problem > exists because OGC cut the wrong corner, became too popular, and now can't > un-cut the corner easily. Popular vs. Right. Right will still be right > tomorrow, but popular might not still be popular. > > ISO, on the other hand, is more interested in building a coherent, > vertically integrated suite of standards. They adapt some of the prototype > standards, integrate some of the lessons learned, and produce something > which "fits" with the rest of the standards better. They are somewhat > concerned with maintaining compatibility with what currently exists, but > the priority is to fix hacks and produce something which is well-designed > at the single-standard and collection-of-standards level. > > Put another way, ISO seems to be "version 2.0.0" of OGC standards: major > API change in some cases, but changes are for the good in the long run. > Obviously, this causes "distress" during the transition. However, if you > want to know what you'll need to support in five years, look to ISO's > activity now. > > >> The reason WMS 1.3.0 is more of a mess then usual is because it is a >> joint release with ISO. >> > > See. :) Transition. Transition hard. > > The OGC is the new kid on the block, and makes newbie mistakes. EPSG has > been doing geodesy since before the OGC formed and their axis order follows > ISO 6709, published in 1983. OGC created this particular mess by ignoring > ~20 years of "accepted best practice" when they started publishing > standards in ~2000. Whoops. > > This particular discussion is perhaps the best argument for moving to > "version 2.0.0/ISO" (WMS 1.3.0) with all available speed. > > >> - "EPSG:CODE" is in the order of the EPSG database for WMS 1.3.0 >> (someone correct me if I am wrong) >> > > You're right. From ISO 19128:2005 (WMS), published by ISO on 2005-11-23: > > "EXAMPLE EPSG:4326 refers to WGS 84 geographic latitude, then longitude. > That is, in this CRS the x axis corresponds to latitude, and the y axis to > longitude." > > >>> 2) About every OGC data sources in the world are already using the >>> above-cited convention, >>> because of the (broken) way the OGC's WMS specification was wrote. >>> Actually, the above- >>> cited OGC's decision was just a recognition of the current stade of >>> affair of most data >>> in the world. >>> >> Got it. >> > > Add Jody's [confirmed] observation that WMS 1.3.0/ISO 19128 is the opposite > decision to this quote. And Paul Ramsey's note that all future work will > abandon the currently popular convention. During transition, we should > handle both. We should plan on deprecating the currently popular > convention in a 2-10 year time horizon. > > >> Got it. And frankly the OGC could not claw back the use of "EPSG:CODE" >> there is too much infrastructure >> deployed around their earlier specification. They did try (for WMS >> 1.3.0) changing their mind - but industry >> is ignoring them. >> > > As to industry's stance: Eventually an update to the WMS spec will have a > feature that every manager MUST HAVE. Some IT managers right now gotta > have the latest version of everything. The first company to offer a WMS >= > 1.3.0 solution which is backwards compatible with previous versions will > trigger a lemming landslide. Give industry a transition path and they'll > grab it. > > Do OGC web services report the version of the spec they implement? That > could be used to apply the correct interpretation of "EPSG:CODE". > > (now != future) > > >>> I fully agree. What the referencing module is trying to provide is an >>> authority factory capable to creates CRS from EPSG code as OGC (and >>> current practice) said they should be, which are not the way the EPSG >>> database said it should be. In other words, the "OGC" definition take >>> precedence over the "EPSG" definition for the "EPSG" name space (yes I >>> know, this is the confusing above-cited stuff), and a new name space >>> need to be found for the real EPSG definition (currently URL according >>> OGC, but I find them too verbose). >>> > > I do not think it is appropriate to state that the OGC has made a decision > on this topic. They say one thing in WMS 1.3.0/ISO 19128 and apparently > they say another in previous WMS versions, and a letter or report or some > other place. Rather, it is probably appropriate to say that OGC has made > "both" decisions. Paul Ramsey's quote indicates that their decision is to > conform to the ~23 year old practice for all future work. > > I would argue that OGC's inability to make a _single_ decision on this > topic, coupled with their break from 23 years of best practice, plus the > fact that this is definately relevant only to web services and perhaps not > to features serialized to GML or some other format, and finally, their > desire to "do the right (opposite) thing" from now on, speaks to the need > for an adaptation layer for the EPSG namespace. > > I suggest that the EPSGAuthorityFactory should represent the EPSG's > definitions. A middleware layer could take on the task of bidirectional > authority name translation for old versions of OGC web services. This > middleware should affect only the authority name, not the CRS definition. > Our internal "URI" or "CRS" or "Geotools" authority namespace would hide > the "real" CRS name. Or we could just make an axes swapper CRS adapter. > Whatever we come up with is temporary and will be deprecated within 10 > years. > > The thing that bothers me most is that I'm really not clear about whether > the OGC's advice on this matter (such as it is) extends beyond web services > to other things CRS is used for. I don't think our referencing module > should be locked into one _application of_ referencing (OWS), and this > seems to be the risk we're running. > > This middleware could be generalized to the notion of a "namespace > convention translator". Using middleware, we can implement WMS 1.3.0 and > previous versions with the same base code. > > >> Ack, for many DataStore implementors will need to invoke that >> OrderedAxis thing all the time? But you are quite right that the >> responsibility to make that assumption >> (and provide control over it) rests at the data store level. >> > > I think if we take the middleware approach, the DataStore implementors will > have to apply an appropriate namespace translator or axes swapper to the > CRS. Most important: you can have defaults, but a human programmer or > end-user should be able to override them. The Human can tell if the axes > are backwards, and the Human can read the natural language metadata. They > need the power to correct an inappropriate default. > > I hate computers which automatically do the wrong thing and offer no way to > make them do the right thing. > > Bryce > > > > ------------------------------------------------------- > All the advantages of Linux Managed Hosting--Without the Cost and Risk! > Fully trained technicians. The highest number of Red Hat certifications in > the hosting industry. Fanatical Support. Click to learn more > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642 > _______________________________________________ > Geotools-devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel > |
From: Martin D. <mar...@no...> - 2006-05-25 03:17:26
|
Thanks Jody, Bryce, Paul and everyone for your input. So the best compromise I can imagine right now is: * CRS created from EPSG codes will still as specified in the EPSG database (i.e. latitude,longitude axis order) by default. The EPSG factories stay basically unchanged - no hack. * Users need to be able to force (longitude,latitude) axis order on a case- by-case basis. It must be entirely under user control - the referencing module will never swap axis without user request. It is up to the user (or to the DataStore implementor) to decide if the DataStore in use requires such axis swapping or not. * Deprecate the OrderedAxisAuthorityFactory.register(String) method, because it has a system-wide effect: it violate the "case-by-case" requirement above. Note that the OrderedAxisAuthorityFactory class itself will still in use. * Introduce a new hint in the org.geotools.factory package: Hints.FORCE_ORDERED_AXIS. * If a user want to create CRS from EPSG codes with (longitude,latitude) axis order, he must provides explicitly the above-cited hint when requesting for a CRSAuthorityFactory: Hints hints = new Hints(Hints.FORCE_ORDERED_AXIS, Boolean.TRUE); CRSAuthorityFactory factory = FactoryFinder.getCRSAuthorityFactory("EPSG", hints); If the FORCE_ORDERED_AXIS hint is not provided, the default value if Boolean.FALSE. Under the hood, when Hints.FORCE_ORDERED_AXIS is set to Boolean.TRUE, Geotools's FactoryFinder will just returns the standard EPSG factory wrapped in a OrderedAxisAuthorityFactory instance. * Maybe add a CRS.decode(String code, boolean forceOrderedAxis) convenience method. * As Jody pointed out, all CRS arguments should be CoordinateReferenceSystem objects, never a plain String, in order to avoid ambiguity. The referencing module should be able to handle correctly CoordinateReferenceSystem objects in all cases, no matter what the axis order is, as long as axis are correctly defined in the CRS object. * The potentially dangerous side-effect is that the same running JVM may have different CRS with different axis order while claiming the same EPSG code. It can lead to some errors like StackOverflowError in non-cautious code. The referencing module has been made more robust (GEOT-854). However, I'm not sure if the same kind of error may occurs in client code. * Changes will be applied on the trunk (toward 2.3 release) only. The changes seems a little bit too significant to me for the 2.2 branch. Does it make sense? Martin. |
From: Adrian C. <ac...@gm...> - 2006-05-25 05:13:55
|
Hey all, I'm *totally* not competent to judge the proposal so this is not about content but about presentation. FORCE_ORDERED_AXIS seems like a *terrible* name. (1) We are having this discussion because there is no inherent ORDER. (2) The issue is the order of 2 axes not a single axis. Would it not be possible to use a name for the constant with *LONGLAT* or *LONGITUDE_FIRST* in it instead of *ORDERED*? FORCE_LONGITUDE_FIRST_AXIS_ORDER is long but descriptive. (AXIS in this last case is singular because the word acts as an adjective.) Also, in the interests of completeness for some day where someone wants to do the opposite, do we provide the opposite hint *LATLONG* or does providing this mean that someone will use it instead of doing some "correct" approach? These are ideas, and probably not sensible ones at that since I don't understand the problem. I'm offline for the next week so this is my parting shot---you are rid of me. I hope you manage to kill this thread before I return. Good luck! ;-) --adrian |
From: Martin D. <mar...@no...> - 2006-05-25 06:36:05
|
Adrian Custer a =E9crit : > FORCE_LONGITUDE_FIRST_AXIS_ORDER is long but descriptive. I'm fine with that name. Lets use it (if peoples agree with the Hint appr= oach). > Also, in the interests of completeness for some day where someone wants > to do the opposite, do we provide the opposite hint *LATLONG* or does > providing this mean that someone will use it instead of doing some > "correct" approach? We could add a FORCE_LATITUDE_FIRST_AXIS_ORDER hint if there is a need fo= r that, but I don't think=20 that we have such need at this time (and it is not clear to my why this n= eed would appears in the=20 future). So it may be better to avoid adding more complexity to the refer= encing module until such a=20 need appears. Martin. |
From: Simone G. <sim...@gm...> - 2006-05-29 12:53:06
|
Ciao Martin, ciao a tutti, I would like to expose some thougths about the proposed solution. I read and understood all objections and concerns stated by different people in these set of emails. My objection is (do not yell at me please...) that we are not solving the problem or at least not the problem I stated at the beginning of this thread. I think this solution looks promising in the mid term, but I see a big problem if try to look at the short term (1-2 months). Let's look at the actual GeoTools-GeoServer supposing that the proposed solution is in place. If we remove epsg-wkt from classpath and we drop epsg-hsql things will not work again (especially if you try to reproject). This does not surprise for various reasons. 1>I do not have any control on the plugins and if one plugin (for example shapefile) is not making use of the proposed HINT things will not be as expected due to the axes swap. This means that if I substitute epsg-wkt with epsg:hsql I will get coordinates in the wrong CRS. I frankly doubt that in the short term we will ever be able to align all the codebase with this HINT. 2>I have to go look all over the GeoTools-GeoServer code to track down all the places where that HINT should have been used. It is not just about Referencing or plugins, I am also talking about for example the Renderer. This applies also to all the applications built upon geotools where a CRS is instantiate using the EPSG:CODE fashion. In all and every module/plugin/app where the epsg-wkt has been used if you just drop the epsg-hsql you will run into a lot of troubles unless you have been really really careful with checking the axis order. If you ever made the assumption (wrong assumption but you might have made it) to get always coords as easting,northing nothing will not work anymore. >>Conclusion For the above mentioned reasons as a short short term hack I would have really loved to see the refactor of OrderedForgotTheNameAuthority. I know it has a system wide effect but it is really what I would like to have as a hack!!! If you have to make an hack make it visible and consistent therefore when you will remove it nothing will change in the rest of the code. If we go with the proposed solution we will have probably to change many plugins, modules and applications built on top of them, which will bring confusion and bugs (hopefully not), just to substitute epsg-wkt. Frankly, If I were a user with an application built on top of GeoTools I would NEVER drop epsg-wkt for epsg-hsql and change all my code around it. I would rather use something that guarantee that my codebase wil continue to work so that I can start removing all the wrong assumptions I made and get aligned with the correct codeline. That *something* would be a system wide switch as I proposed with the refactor of the old authority (and as also someone else before me proposed since OrderedBlahBlahAuthority was the answer to some user's question, it did not fall from the sky see http://jira.codehaus.org/browse/GEOT-694). It is worth to point out that this quick hack would not clash with the solution proposed by Martin that is btw elegant and correct but would be more like a transition thing to help people remove wrong assumption from their applications. Once we are sure that all geotools codebase is using Martin's HINT we could deprecate and then remove the OrderedBlahBlahAuthority. I think (and many people say this as well ) that one of the most annoying things of Geotools and of Open Source Software in general is that it changes too much!! (correct Bryce?). You write your app now and in 6 months if you recompile nothing will work (I am being a bit pessimistic sorry). So my proposal is: 1>Martin's HINT is correct and more than welcome(I would say mid.-term solution). 2>Quick awful bad dirty system wide hack to help people (module maintainers and external applications) check their code and make it stronger. This would be the refactoring of OrderedForgotTheNameAuthority. 3>Have all the module maintainers review their code looking for wrong assumptions to be removed (mid term). 4>URI based authority (mid-term to long term solution). I hope that this contribution from me is of help. I always try to suggest what I believe would make Geotools more popular and accepted. Simone. On 5/25/06, Martin Desruisseaux <mar...@no...> wrote: > Thanks Jody, Bryce, Paul and everyone for your input. > > So the best compromise I can imagine right now is: > > * CRS created from EPSG codes will still as specified in the EPSG datab= ase > (i.e. latitude,longitude axis order) by default. The EPSG factories s= tay > basically unchanged - no hack. > > * Users need to be able to force (longitude,latitude) axis order on a c= ase- > by-case basis. It must be entirely under user control - the referenci= ng > module will never swap axis without user request. It is up to the use= r > (or to the DataStore implementor) to decide if the DataStore in use r= equires > such axis swapping or not. > > * Deprecate the OrderedAxisAuthorityFactory.register(String) method, be= cause > it has a system-wide effect: it violate the "case-by-case" requiremen= t above. > Note that the OrderedAxisAuthorityFactory class itself will still in = use. > > * Introduce a new hint in the org.geotools.factory package: Hints.FORCE= _ORDERED_AXIS. > > * If a user want to create CRS from EPSG codes with (longitude,latitude= ) axis > order, he must provides explicitly the above-cited hint when requesti= ng for > a CRSAuthorityFactory: > > Hints hints =3D new Hints(Hints.FORCE_ORDERED_AXIS, Boolean.TRUE); > CRSAuthorityFactory factory =3D FactoryFinder.getCRSAuthorityFactor= y("EPSG", hints); > > If the FORCE_ORDERED_AXIS hint is not provided, the default value if = Boolean.FALSE. > Under the hood, when Hints.FORCE_ORDERED_AXIS is set to Boolean.TRUE,= Geotools's > FactoryFinder will just returns the standard EPSG factory wrapped in = a > OrderedAxisAuthorityFactory instance. > > * Maybe add a CRS.decode(String code, boolean forceOrderedAxis) conveni= ence method. > > * As Jody pointed out, all CRS arguments should be CoordinateReferenceS= ystem objects, > never a plain String, in order to avoid ambiguity. The referencing mo= dule should be > able to handle correctly CoordinateReferenceSystem objects in all cas= es, no matter > what the axis order is, as long as axis are correctly defined in the = CRS object. > > * The potentially dangerous side-effect is that the same running JVM ma= y have different > CRS with different axis order while claiming the same EPSG code. It c= an lead to some > errors like StackOverflowError in non-cautious code. The referencing = module has been > made more robust (GEOT-854). However, I'm not sure if the same kind o= f error may occurs > in client code. > > * Changes will be applied on the trunk (toward 2.3 release) only. The c= hanges seems a > little bit too significant to me for the 2.2 branch. > > Does it make sense? > > Martin. > --=20 =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0 Simone Giannecchini Software Engineer Freelance Consultant http://simboss.wordpress.com/ =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0 |
From: Martin D. <mar...@no...> - 2006-05-29 13:17:18
|
Simone Giannecchini a =E9crit : > I would like to expose some thougths about the proposed solution. > [...snip...] OrderedAxisAuthorityFactory is not going to be removed. Even with the Hin= t proposal, it still the=20 class performing the work under the hood, so this class is there to stay.= The=20 OrderedAxisAuthorityFactory.register("EPSG") method is not removed neithe= r; it is just deprecated in=20 favor of the case-by-case approach. We may undeprecate this particular me= thod if it appears that it=20 is going to stay there for a while. Martin. |
From: Simone G. <sim...@gm...> - 2006-05-29 13:20:33
|
That would be good for me as long as I do not get the "modified axis" metadata but the EPSG plain name. Since the registration has a system wide effect it should not clash with anything else. I hope I made my point clearly. Simone. On 5/29/06, Martin Desruisseaux <mar...@no...> wrote: > Simone Giannecchini a =E9crit : > > I would like to expose some thougths about the proposed solution. > > [...snip...] > > OrderedAxisAuthorityFactory is not going to be removed. Even with the Hin= t proposal, it still the > class performing the work under the hood, so this class is there to stay.= The > OrderedAxisAuthorityFactory.register("EPSG") method is not removed neithe= r; it is just deprecated in > favor of the case-by-case approach. We may undeprecate this particular me= thod if it appears that it > is going to stay there for a while. > > Martin. > --=20 =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0 Simone Giannecchini Software Engineer Freelance Consultant http://simboss.wordpress.com/ =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0 |
From: Justin D. <jde...@op...> - 2006-05-29 13:26:44
|
Hi folks, I would imagine that this will be a topic of discussion at tonights IRC=20 meeting. I know Martin came up with someone but there seems to be more=20 to this issue. Could someone please summarize so that poor souls like myself can follow=20 at tonights meeting. Thanks. -Justin Simone Giannecchini wrote: > That would be good for me as long as I do not get the "modified axis" > metadata but the EPSG plain name. Since the registration has a system > wide effect it should not clash with anything else. >=20 > I hope I made my point clearly. >=20 > Simone. >=20 > On 5/29/06, Martin Desruisseaux <mar...@no...> wro= te: >=20 >> Simone Giannecchini a =E9crit : >> > I would like to expose some thougths about the proposed solution. >> > [...snip...] >> >> OrderedAxisAuthorityFactory is not going to be removed. Even with the=20 >> Hint proposal, it still the >> class performing the work under the hood, so this class is there to=20 >> stay. The >> OrderedAxisAuthorityFactory.register("EPSG") method is not removed=20 >> neither; it is just deprecated in >> favor of the case-by-case approach. We may undeprecate this particular= =20 >> method if it appears that it >> is going to stay there for a while. >> >> Martin. >> >=20 >=20 --=20 Justin Deoliveira The Open Planning Project jde...@op... |
From: Martin D. <mar...@no...> - 2006-05-29 13:36:28
|
Justin Deoliveira a =E9crit : > Could someone please summarize so that poor souls like myself can follo= w=20 > at tonights meeting. A wiki page was started there: http://docs.codehaus.org/display/GEOTOOLS/= The+axis+order+issue (may=20 need to be completed...) Martin |
From: Jody G. <jga...@re...> - 2006-05-29 13:55:50
|
Martin Desruisseaux wrote: > Justin Deoliveira a =E9crit : >> Could someone please summarize so that poor souls like myself can=20 >> follow at tonights meeting. > A wiki page was started there:=20 > http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue (may=20 > need to be completed...) Thanks martin, let me try ... The page above represents: - a great breakdown of the problem - a proposed solutions using a HINT - guidelines for what geotools developers should do There are three outstanding requests 1- SHORT-TERM: the request for a "EPSG:code" authority that can be used=20 short term as a replacement for epsg-wkt 2- MEDIUM-TERM: the request for a "URI....epsg/6.1/code" authority that=20 can be used with WMS 1.3 and new GML3 work 3- MEDIUM-TERM: provide someway for client code to "tweak" the CRS used=20 at the datastore level (ie where data is read) Request 1: is needed today, it feels the same need as epsg-wkt, and=20 would probably used by uDig and GeoServer in the next available release Request 2: is just something I want, so I have clear example code that=20 nobody can get confused over Request 3: is probably going to need to wait for your FeatureModel=20 improvements where DataStore could be injected by a CRSFactory If I have missed out on any requests let me know... Jody |
From: Jody G. <jga...@re...> - 2006-05-29 14:15:07
|
Jody Garnett wrote: >>> Could someone please summarize so that poor souls like myself can >>> follow at tonights meeting. >> A wiki page was started there: >> http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue (may >> need to be completed...) > Thanks martin, let me try ... > Bleah tried to update the page but the email was clearer, can someone else have a kick at this? |
From: Simone G. <sim...@gm...> - 2006-05-29 14:51:24
|
I would take a look here http://docs.codehaus.org/display/GEOTOOLS/The+axis+order+issue?focusedComme= ntId=3D53165#comment-53165 in case you haven't yet. Simone. On 5/29/06, Justin Deoliveira <jde...@op...> wrote: > Hi folks, > > I would imagine that this will be a topic of discussion at tonights IRC > meeting. I know Martin came up with someone but there seems to be more > to this issue. > > Could someone please summarize so that poor souls like myself can follow > at tonights meeting. > > Thanks. > > -Justin > > Simone Giannecchini wrote: > > That would be good for me as long as I do not get the "modified axis" > > metadata but the EPSG plain name. Since the registration has a system > > wide effect it should not clash with anything else. > > > > I hope I made my point clearly. > > > > Simone. > > > > On 5/29/06, Martin Desruisseaux <mar...@no...> wro= te: > > > >> Simone Giannecchini a =E9crit : > >> > I would like to expose some thougths about the proposed solution. > >> > [...snip...] > >> > >> OrderedAxisAuthorityFactory is not going to be removed. Even with the > >> Hint proposal, it still the > >> class performing the work under the hood, so this class is there to > >> stay. The > >> OrderedAxisAuthorityFactory.register("EPSG") method is not removed > >> neither; it is just deprecated in > >> favor of the case-by-case approach. We may undeprecate this particular > >> method if it appears that it > >> is going to stay there for a while. > >> > >> Martin. > >> > > > > > > > -- > Justin Deoliveira > The Open Planning Project > jde...@op... > --=20 =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0 Simone Giannecchini Software Engineer Freelance Consultant http://simboss.wordpress.com/ =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0= =B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0=B0 |