EPSG factories and their returned objects

[Matthias Basler-2]

Hi developers, hi Martin.

For several of my geowidgets I need EPSG factries as "CRSAuthorityFactory"
implementations. The intend is to show a list of available objects, for example
CRS, to the user. This is done in uDig (map properties), which is instantaneous:
The user doesn't have to wait. I tried the very same with a slightly modified
version in GeoWidgets and it took two seconds for the CRSs alone ... and I need
to query several kinds of objects (-> 19 secs total, inacceptable).

A closer look a the code differences revealed that uDig gets a
"EPSGCRSAuthorityFactory",
calls factory.getAuthorityCodes(CoordinateReferenceSystem.class);
and uses the returned 2707 objects without any further check.

I get a "DefaultFactory",
also call factory.getAuthorityCodes(CoordinateReferenceSystem.class);
get 3534 (with HSQL) resp. 3325 (with Access) objects back in no time and check
each and every one if it can be instantiated, which takes some seconds. Indeed,
several objects fail this check ... so it is not in vain.

The reason for the difference is that uDig uses the WKT plugin while I need the
metadata only offered by Access or HSQL databases.

Question 1:
  Why do they return a different number of Codes? Is this, because the WKT
  based factory only contains objects that can indeed be instantiated?

The point is that I have the choice: On the one hand also show "invalid" objects
to the user (which, when the user selects them, will not work). On the other
hand spend a few seconds testing every returned EPSG code. A dilemma.

Question 2:
  Would it be possible to enhance the DefaultFactory to do some kind of
  (quicker!) check internally and return only objects that can indeed be
  instantiated. Maybe use a "validOnly" hint or sth. similar.

If not, what other solution are there to reduce the time, given the constraints
that I need the metadata (not offered by WKT) and that I don't want to show
invalid objects to the user.

Matthias Basler
[hidden email]

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Martin Desruisseaux-2]

Matthias Basler a écrit :
> I get a "DefaultFactory", also call factory.getAuthorityCodes(CoordinateReferenceSystem.class);
> get 3534 (with HSQL) resp. 3325 (with Access) objects back in no time and check
> each and every one if it can be instantiated, which takes some seconds. Indeed,
> several objects fail this check ... so it is not in vain.

Note that HSQL and Access should returns an identical amount of object. If the number are not the
same, this is probably because HSQL and Access are connected to different EPSG database versions.
Current epsg-hsql plugin uses EPSG version 6.8.

Getting the list of codes with factory.getAuthorityCodes(...) should be reasonably fast.
Instantiating each object is likely to be costly, no matter which EPSG factory is used (HSQL, Access
or even the WKT one). It is also likely to consume a fair amount of memory.


> Question 1:
>   Why do they return a different number of Codes? Is this, because the WKT
>   based factory only contains objects that can indeed be instantiated?

No. There is some objects in the WKT factory that can't be instantiated as well. The WKT based
factory is a subset of the EPSG database derived indirectly from Proj4 (the original properties file
was not created specifically for the Geotools project). It also contains some supplemental codes not
found in the official EPSG database, and the axis order are not the same. Actually, epsg-wkt.jar is
a particular factory which is a slight departure from the official EPSG database.


> Question 2:
>   Would it be possible to enhance the DefaultFactory to do some kind of
>   (quicker!) check internally and return only objects that can indeed be
>   instantiated. Maybe use a "validOnly" hint or sth. similar.

It would be hard to guess if a CRS can be instantiated before to try it. I don't see any other
solution at this time other than try all CRS only once for ever, and write the list of valid codes
in some text file. A problem is that it may depends on user configuration (available plugins in the
class path, existence of JAI installation, etc.).


        Martin.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Matthias Basler-2]

> Note that HSQL and Access should returns an identical amount of object. I=
> f the number are not the=20
> same, this is probably because HSQL and Access are connected to different=
>  EPSG database versions.=20
> Current epsg-hsql plugin uses EPSG version 6.8.

Yup. I have EPSG6.6 registereed as "EPSG". But I don't mind that difference.

> Getting the list of codes with factory.getAuthorityCodes(...) should be r=
> easonably fast.=20

Agree. It is near-instantaneous.

> Instantiating each object is likely to be costly, no matter which EPSG fa=
> ctory is used (HSQL, Access=20
> or even the WKT one). It is also likely to consume a fair amount of memor=
> y.

I don't keep the objects in memory. So memory should not be the problem. But
time is...

> It would be hard to guess if a CRS can be instantiated before to try it. =
> I don't see any other=20
> solution at this time other than try all CRS only once for ever, and writ=
> e the list of valid codes=20
> in some text file. A problem is that it may depends on user configuration=
>  (available plugins in the=20
> class path, existence of JAI installation, etc.).

Yes, I guessed this, but I don't like it too much as well. It is hard, but not
impossible, to detect configuration changes.

Another workaround (for an application) would be do the checkung in the
background on application start and hope that it is done when the user needs
the CRS list.

A third possibility is to do sth. like certain help systems do: If they are
called for the first time, open a progress dialog: "Perparing referencing
objects...", do the check, store the invalid objects into a file and next time
read the file.

Guess I will test the last one. Thanks.

Matthias Basler
[hidden email]

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Matthias Basler-2]

Hi developers, hi Martin.

Related to my first mail:

Keeping a list (in a file) of invalid referencing objects would work, but there
is one more thing that implies the need to instantiate every single CRS object:
It is the need to optionally restrict my search to 2D or 3D CRS.

An EPSG database query could easily restrict the result set to 2D or 3D objects,
since f.e. the "COORD_REF_SYS_KIND" column distinguishes between "projected2D",
"geographic3D" a.s.o.
The problem is that the AuthorityFactory:getAuthorityCodes() function does not
support any kind of additional hints, like "2D" or "3D" or maybe spatial
restrictions (sth. like "... where 'area' contains 'Germany'"). In the end this
means that I have to instantiate the referencing objects in order to sort out
those I don't need ... which is plainly inefficient, given that the info is
already in the database.

Question 1:
  Is there already ANY means of telling an authority factory to return 2D
  or 3D CRS and CS only? I couldn't find anything related in the code,
  but maybe I've overlooked something.

Question 2:
  If not, would you think that it would be possible to add hints to
  either this specific "getAuthorityCodes()" method or alternatively to
  FactoryFinder.getCRSAuthorityFactory("EPSG", hints); //$NON-NLS-1$
  (The latter one would not require interface changes. It would then
  return a factory that produced only 2D or only 3D objects. Why not...)

P.S. Yes, I asked a somewhat similar question half a year ago, but it is just
now that I realize how big the speed impact is.

Matthias Basler
[hidden email]

----------------------------------------------------------------
This mail was sent through http://webmail.uni-jena.de


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Jody Garnett]

Matthias Basler wrote:

> Hi developers, hi Martin.
>
> Related to my first mail:
>
> Keeping a list (in a file) of invalid referencing objects would work, but there
> is one more thing that implies the need to instantiate every single CRS object:
> It is the need to optionally restrict my search to 2D or 3D CRS.
>
> An EPSG database query could easily restrict the result set to 2D or 3D objects,
> since f.e. the "COORD_REF_SYS_KIND" column distinguishes between "projected2D",
> "geographic3D" a.s.o.
> The problem is that the AuthorityFactory:getAuthorityCodes() function does not
> support any kind of additional hints, like "2D" or "3D" or maybe spatial
> restrictions (sth. like "... where 'area' contains 'Germany'"). In the end this
> means that I have to instantiate the referencing objects in order to sort out
> those I don't need ... which is plainly inefficient, given that the info is
> already in the database.
>
> Question 1:
>   Is there already ANY means of telling an authority factory to return 2D
>   or 3D CRS and CS only? I couldn't find anything related in the code,
>   but maybe I've overlooked something.
>  

On geotools 2.3 you could allow for this with a Filter. Accepting the
filter and turning it into an hsql query on one side, and using
a JXPath implementation to query the CRS data structures (as java beans)
on the other..
> Question 2:
>   If not, would you think that it would be possible to add hints to
>   either this specific "getAuthorityCodes()" method or alternatively to
>   FactoryFinder.getCRSAuthorityFactory("EPSG", hints); //$NON-NLS-1$
>   (The latter one would not require interface changes. It would then
>   return a factory that produced only 2D or only 3D objects. Why not...)
Both those options could work, the second would be less work.
Jody



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

[Martin Desruisseaux-2]

Matthias Basler a écrit :
> The problem is that the AuthorityFactory:getAuthorityCodes() function does not
> support any kind of additional hints, like "2D" or "3D" or maybe spatial
> restrictions (sth. like "... where 'area' contains 'Germany'").

We would have to figure out an API in order to specify shuch hint. Allowing user to specify a SQL
"WHERE" clause may not be the most appropriate way, since not all factories are SQL backed. We could
consider something like regular expression however.

A suggest to open a JIRA task for those improvements.

> Question 1:
>   Is there already ANY means of telling an authority factory to return 2D
>   or 3D CRS and CS only? I couldn't find anything related in the code,
>   but maybe I've overlooked something.

Not at this time.


> Question 2:
>   If not, would you think that it would be possible to add hints to
>   either this specific "getAuthorityCodes()" method or alternatively to
>   FactoryFinder.getCRSAuthorityFactory("EPSG", hints);
>   (The latter one would not require interface changes. It would then
>   return a factory that produced only 2D or only 3D objects. Why not...)

Yes, we can consider that. As said previously, a first step is to figure out an API (avoiding SQL
instruction if possible).

        Martin.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
<a href="http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642">http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel