+1 on being pragmatic and explicit!
IMHO, I think we should carry two (or more) peices of metadata instead
of just the CRS definition:
1) projectionDefinitionSource="EPSG:4326" // source of projection
definition (independent of serialisation formatting)
2) axisFormat=X,Y
3) numberFormat=DD // DMS is usually actually specified in EPSG!
Note that the last two are FORMATTING choices, used when outputting data
The definition for the data store may need to mirror these, to specify
what happens when inputting data into the feature model.
NB we have the general case again where we need to map the (hidden)
native input data store to the interoperable output format.
And just food for thought....
Of course, SRS need not be coordinates - you could conceivably have a
named set of geographies as a referencing system.
This would actually be kind of cute- some phD student should do this one
day : you could wrap one data store (e.g. countries) in an authority
factory and use it to render a datastore containing only attributes.
You woudl still need exactly the same metadata for output, but the input
data store metadata would need to add metadata for the gazetteer being used.
Simone Giannecchini wrote:
On 5/22/06, Adrian Custer <[EMAIL PROTECTED]> wrote:
On Mon, 2006-05-22 at 14:58 +0200, Simone Giannecchini wrote:
> Very often people ship data saying this is EPSG:4326, meaning lon,lat
> and not lat,lon.
>
> I would suggest the following two steps solution which should make
> everyone happy (or unhappy which would basically be the same :-) ).
>
> 1>Refactor OrderedAxisAuthorityFactory as follows:
> -Use a name similar to OGCOrderedAxisAuthorityFactory to state
> clearly what this is
No, No, NO! Please!
If the issue is LatLong vs. LongLat, can't you make this clear in the
names instead of creating the hidden assumption OGC is one and EPGS is
the other? I don't pretend to understand yet what's going on but you
seem to be needlessly hiding what users need to know. Any reason you
can't have the Factory be
LatlongOrderedAxisFactory
and
Longlat...
if that's what the factory is for? Hmmm, maybe I'm wrong and you are
trying to say ""whatever OGC is doing this month" rather than "in the
OGC order which is presumed to be ...".
Honestly, I don't get what you are trying to say :-). I am not hiding
anything in this proposal, quite the opposite. This proposal is trying
to say what follows:
"Until the time we find a why to remove discrepancies between EPSG
database and OGC (and also common) practice, we should give the user a
hook to ask spatial reference objects as they would expect, that is
LON,LAT and not LAT,LON".
I am not hiding anything, the user, check the next lines, will
EXPLICTLY ask for the axes-reversal behaviour, hence he will have know
what he is going to do. This means that the user/developer will be
aware of the issue and he will be aware of the solution he will get.
I will try to clarify further the proposal I made before. First I
think that a quick look at the following page would be helpful in
order to understand what OrderedAxisAuthorityFactory does and how ti
work.
http://udig.refractions.net/docs/api-geotools/org/geotools/referencing/factory/OrderedAxisAuthorityFactory.html
This is the base to start the work for getting spatial reference
objects (CRS and such) ALWAYS in lon,lat.
Despite the fact that this authority gives ALWAYS CRSs in lon,lat it
also takes some others actions, as I pointed out before, on the
metadata.
I think that as a base solution we should refactor this class a bit,
maybe call it WhateverTheNameYouWantButGiveMeCRSWithLonLat, in order
to have it act the way we would expect, that is lon,lat.
As Jody said, it seems to be very difficult to propose solutions for
the axes issue. Mine could be wrong of course, but I am sure we should
try to find one.
Have not anybody noticed that both GeoServer and Udig DO NOT use
EPSG-hsql or EPSG-access but they still use the old epsg-wkt factory?
Maybe this is because if you use the other two you will get lat,lon
CRSs.
I am just trying to find a solution since I running into this problem
every 5 minutes in both GeoServer and Geotools.
Simone.
PS Please Martin, tell us something :-).
And, since this issue comes up all the time, can someone who groks it
cut and paste the mails into a wiki prototype of the eventual canonical
explanation? The issues span history, crs data sources, interfaces, and
user code. The topic therefore needs to be spelled out completely if
people are going to really get it.
--a
-------------------------------------------------------
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&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
