I have packaged up a property file based EPSG CoordinateSystemAuthorityFactory (what a name!) and a copy of the CoordianteSystemAUTOAuthoryFacotry into geotools ext/reprojection.
These classes use the old CoordianteSystem classes, rather than the new CoordinateReferenceSystem interfaces. Hopefully Martin will help us make the change over when the time comes.
I will be using this in GeoServer to support reprojection for bounding box calculations. And more agressively for DataStores that do not respect the Query CoordinateSystem parameters (that is all of them). I am hoping to jar over to GeoServer directly, since it does not depend on Martin's new GeoAPI interfaces (only the legacy opengis jars).
Right now org.geotools.reprojection.ReprojectionService makes use of the following (bad?) assumption:
- codes that start with EPSG will be serived by an "EPSG" Authority
- codes that start with AUTO will be serived by an "AUTO" Authority
On reading Martin's comments I get the impression that CoordinateSystemAUTOFactory should return "geotools" as the authority (or possibly "OGC" since we implemented their WMS Appendix F on the subject).
When we update the CoordinateSystemAuthortyFactory to use the CRS interfaces can we also look into either extending the API to provide a canProcess( code ) method. I am more interested in processing codes then I am in authority.
I have packaged up a property file based EPSG CoordinateSystemAuthorityFactory (what a name!) and a copy of the CoordianteSystemAUTOAuthoryFacotry into geotools ext/reprojection.
These classes use the old CoordianteSystem classes, rather than the new CoordinateReferenceSystem interfaces. Hopefully Martin will help us make the change over when the time comes.
I will be using this in GeoServer to support reprojection for bounding box calculations. And more agressively for DataStores that do not respect the Query CoordinateSystem parameters (that is all of them). I am hoping to jar over to GeoServer directly, since it does not depend on Martin's new GeoAPI interfaces (only the legacy opengis jars).
Apparently I am wrong, we will need to figure out if we want to track geotools as part of 1.2.0 or 1.3.0
I am going to try an upgrade right now, and will report back how it goes.
I will be using this in GeoServer to support reprojection for bounding box calculations. And more agressively for DataStores that do not respect the Query CoordinateSystem parameters (that is all of them). I am hoping to jar over to GeoServer directly, since it does not depend on Martin's new GeoAPI interfaces (only the legacy opengis jars).
Apparently I am wrong, we will need to figure out if we want to track geotools as part of 1.2.0 or 1.3.0
I am going to try an upgrade right now, and will report back how it goes.
Well GeoServer builds against the current gt2 codebase, with upgrades for vecmath-1.3, geoapi-1.0.0, opengis-legacy-0.1
So the questions is use GeoServer to debug Geotools in the 1.2.0 timeframe or in the 1.3.0 timeframe?
Actually maybe it is not a question as we need fid-exp to fix serious GeoServer bugs...
I have packaged up a property file based EPSG CoordinateSystemAuthorityFactory (what a name!) and a copy of the CoordianteSystemAUTOAuthoryFacotry into geotools ext/reprojection.
Just for information: does anyone tried the other path: provides the EPSG database as an embeded database (using HSQL or something like that)? See:
It would contains much more informations with less space than WKT, and may use less memory as well. The implementation in ext/reprojection read the full property file; it is not going to scale a lot (there is more than 3000 CRS in the EPSG database). The implementation backed by a database engine (currently available in Geotools) read only the needed informations.
Some transformations will not be possible with a property file of WKTs. For example the "TOWGS84" entity has to many limitations which will prevent transformation for many CRS.
Right now org.geotools.reprojection.ReprojectionService makes use of the following (bad?) assumption:
- codes that start with EPSG will be serived by an "EPSG" Authority
- codes that start with AUTO will be serived by an "AUTO" Authority
No, it is not bad assumption. It is exactly what OGC specifies if my memory serve me right.
On reading Martin's comments I get the impression that CoordinateSystemAUTOFactory should return "geotools" as the authority (or possibly "OGC" since we implemented their WMS Appendix F on the subject).
I should clarify the comments then.
- "EPSG" is the authority which control the code in this namespace.
- "Geotools" is the implementor.
In the new interfaces, there is a 'getAuthority()' and a 'getVendor()' methods.
Jody Garnett a écrit :
> I have packaged up a property file based EPSG
> CoordinateSystemAuthorityFactory (what a name!) and a copy of the
> CoordianteSystemAUTOAuthoryFacotry into geotools ext/reprojection.
Just for information: does anyone tried the other path: provides the
EPSG database as an embeded database (using HSQL or something like
that)? See:
It would contains much more informations with less space than WKT,
and
may use less memory as well. The implementation in ext/reprojection
read
the full property file; it is not going to scale a lot (there is more
than 3000 CRS in the EPSG database). The implementation backed by a
database engine (currently available in Geotools) read only the
needed
informations.
Not yet. I would like to eventually, to make it an extra option that
users of geoserver could download if they wanted full support. Right
now the idea is to just support a few, and users can then modify their
wkt files to add the ones that they want. And hopefully we can make
this all seamless - I would also like to see an option to just connect
to a postgis db that has all the crs information as well, since many
geoserver users are using postgis, and it's easy to just install the
definitions there, and then they wouldn't have to reduplicate that info
in hsql or wkt files. Granted I need to look into this more, I'm not
sure exactly how the postgis stuff works, I just remembered being able
to add a whole bunch of epsg definitions by just running a sql file.
> I have packaged up a property file based EPSG
> CoordinateSystemAuthorityFactory (what a name!) and a copy of the
> CoordianteSystemAUTOAuthoryFacotry into geotools ext/reprojection.
>
> These classes use the old CoordianteSystem classes, rather than the
> new CoordinateReferenceSystem interfaces. Hopefully Martin will
help
> us make the change over when the time comes.
>
> I will be using this in GeoServer to support reprojection for
bounding
> box calculations. And more agressively for DataStores that do not
> respect the Query CoordinateSystem parameters (that is all of
them). I
> am hoping to jar over to GeoServer directly, since it does not
depend
> on Martin's new GeoAPI interfaces (only the legacy opengis jars).
Apparently I am wrong, we will need to figure out if we want to track
geotools as part of 1.2.0 or 1.3.0
My thinking at the moment is just throw it on a branch, and if things
get nasty we hold off on merging, shake out the bugs with a 1.3.0. If
things look good and easy we can merge in for 1.2.0. Does that work?
Then we can also see where things fall with fid-exp.
Okay now we are playing with fire! I am going to start a gt-merge branch ...
Here is the pan:
- grab the new jars from Geotools (I will copy them from individual "maven jar:install" commands as "maven createRelease" will no longer work)
- update build.xml to grab the maven genarted jars
- drag over ext/reprojection (with assocaited 700k properties file)
- make the "Generatge Bounding Box" button work
This should put it a happy place going forward, and Chris can decide what to call the result (1.2.0 rc2 or 1.3.0 beta).
Cheers,
Jody
Apparently I am wrong, we will need to figure out if we want to track
geotools as part of 1.2.0 or 1.3.0
My thinking at the moment is just throw it on a branch, and if things
get nasty we hold off on merging, shake out the bugs with a 1.3.0. If
things look good and easy we can merge in for 1.2.0. Does that work? Then we can also see where things fall with fid-exp.
Quick update before the weekend...(I am CCing geotools since this is mostly about the post module merge status).
Here is the plan:
- grab the new jars from Geotools (I will copy them from individual "maven jar:install" commands as "maven createRelease" will no longer work)
I have done this and everything works except:
- Startup: the gt validation module is no longer reading UserBasic
[Fatal Error] :1:87: The prefix "xs" for attribute "xs:schemaLocation" associated with an element type "plugin" is not bound.
org.geotools.validation.xml.ValidationException: Cannot parse the inputSource: Cannot configure the parser.
at org.geotools.validation.xml.XMLReader.readPlugIn(XMLReader.java:88)
at org.geotools.validation.xml.XMLReader.loadPlugIns(XMLReader.java:378)
at org.vfny.geoserver.global.GeoServerPlugIn.init(GeoServerPlugIn.java:126)
- Demo: UserBasicdemo getFeatureBetween dies with a Filter Parser Exception
<ServiceException locator="org.vfny.geoserver.requests.readers.XmlRequestReader">
XML getFeature request SAX parsing error: org.xml.sax.SAXException: Attempted to construct illegal filter: Got to the end state of an incomplete filter, current state is LowerBoundary
at org.geotools.filter.FilterFilter.endElement(FilterFilter.java:310)
So I am not sure if these things ever worked or if these are problems that have not been reported to the list.
> Here is the plan:
> - grab the new jars from Geotools (I will copy them from individual
> "maven jar:install" commands as "maven createRelease" will no longer
> work)
I have done this and everything works except:
- Startup: the gt validation module is no longer reading UserBasic
I just reported this: http://jira.codehaus.org/browse/GEOS-175
I've never touched validation stuff, really, so i'm not sure about the
problem, if anyone has a quick fix then throw it up on cvs. It sounds
like one of the files is just a bit wrong...
- Demo: UserBasicdemo getFeatureBetween dies with a Filter Parser Exception
Yeah, I'm half way done with that. I need to figure out what the problem
is. I committed to remind me to do so, and it doesn't actually prevent
the build or anything.
So I am not sure if these things ever worked or if these are problems
that have not been reported to the list.
Thanks Jody. Hopefully we can get fid-exp in soon and put out a release.
ThougH I've got quite a few little tasks on my plate. Things are looking
promising though.
