jira.codehaus.org

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What?s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
  • GeoTools
  • GEOT-216

Dreaming of improved Coordinate System Persistence mechanism

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: Wish Wish
  • Status: Closed Closed
  • Priority: Minor Minor
  • Resolution: Duplicate
  • Affects Version/s: 2.1.M0
  • Fix Version/s: None
  • Component/s: referencing
  • Labels:
    None

Description

Connecting to a live database of coordinate systems/projections is a heavyhanded way of providing persistence. First off, one must either be connected to the internet or install a database on one's own machine. Secondly, what happens if I have my own projection that I want to save? How do I access those projections the next time I run my program?

WKT, to the best of my knowledge, doesn't maintain authority name or code.

I'm just dreaming here. What I envision is some sort of CoordinateSystemAuthorityFactory implementation which uses an *.xml
file as a persistence mechanism. The EPSG factory would not have a write capability, but the UserDefined factory would.

There'd also need to be some sort of caching mechanism to maintain the most recently used coordinate systems (or components thereof) in memory.

The following dreams should be addressed:
1] Have access to the entire EPSG/other coordinate system database without a live connection.
2] Ability to construct own coordinate system from registered/standard components (like EPSG ellipsoids/datums).
3] Save (and name) one's own coordinate systems once they've been defined. (And load them back in when desired.)
4] Cache the most recently used CRSes for quick access.

Issue Links

depends upon

Wish - General wishlist item GEOT-46 Provides EPSG data in a java embedded database

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Task - A task that needs to be done. GEOT-176 Port the EPSG Authority Factory to the new GeoAPI interfaces

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
duplicates

New Feature - A new feature of the product, which has yet to be developed. GEOT-546 Berkeley DB (JE) Authority Factory Suite

  • Minor - Minor loss of function, or other problem where easy workaround is present.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • History
  • Activity
Hide
Permalink
Martin Desruisseaux added a comment - 16/Jul/04 4:10 AM
WKT has an AUTHORITY["name", "code"] entity which can be used for storing EPSG code. However, WKT has other limitation. For example it doesn't store information about the underlying coordinate system (cartesian, cylindrical, etc.), can't store comments, etc.

XML would be a better storage format, and actually is already part of OGC specification. I believe it is part of GML. XML parsing and formatting of coordinate reference system has not been implemented in Geotools simply because of a lack of human resources. It is going to be a fair amount of work, but this work will need to be done soon or later anyway.

EPSG database without live connection is the subject of GEOT-46 ("Provides EPSG data in java embedded database"). We would need a volunteer in order to push GEOT-46 ahead.

In the main time, a persistence mechanism available right now is serialization. This is not a very robust one since it may broke if we change the implementation, but is convenient for a cache mechanism for example.
Show
Martin Desruisseaux added a comment - 16/Jul/04 4:10 AM WKT has an AUTHORITY["name", "code"] entity which can be used for storing EPSG code. However, WKT has other limitation. For example it doesn't store information about the underlying coordinate system (cartesian, cylindrical, etc.), can't store comments, etc. XML would be a better storage format, and actually is already part of OGC specification. I believe it is part of GML. XML parsing and formatting of coordinate reference system has not been implemented in Geotools simply because of a lack of human resources. It is going to be a fair amount of work, but this work will need to be done soon or later anyway. EPSG database without live connection is the subject of GEOT-46 ("Provides EPSG data in java embedded database"). We would need a volunteer in order to push GEOT-46 ahead. In the main time, a persistence mechanism available right now is serialization. This is not a very robust one since it may broke if we change the implementation, but is convenient for a cache mechanism for example.
Hide
Permalink
Rueben Schulz added a comment - 20/Jul/04 12:26 AM
As Martin mentioned, GEOT-46 will solve your problem #1.

Problem #2 is already solved by the current EPSG authority factory, which allows you to create arbitray coordinate system objects from codes.

Problem #3 may be solved by adding write capabilities to Jody's CSEPSGFactory work. This is an Authority Factory backed by a simple text property file. See gt/ext/reprojection/src/org/geotools/cs.
Show
Rueben Schulz added a comment - 20/Jul/04 12:26 AM As Martin mentioned, GEOT-46 will solve your problem #1. Problem #2 is already solved by the current EPSG authority factory, which allows you to create arbitray coordinate system objects from codes. Problem #3 may be solved by adding write capabilities to Jody's CSEPSGFactory work. This is an Authority Factory backed by a simple text property file. See gt/ext/reprojection/src/org/geotools/cs.
Hide
Permalink
Martin Desruisseaux added a comment - 15/Jun/05 9:48 PM
Unassigned from me, since I do not plan further action after the embedded EPSG database using HSQL. We may consider closing the task as a duplicate of GEOT-546, which seems to be already underway.
Show
Martin Desruisseaux added a comment - 15/Jun/05 9:48 PM Unassigned from me, since I do not plan further action after the embedded EPSG database using HSQL. We may consider closing the task as a duplicate of GEOT-546, which seems to be already underway.

People

  • Assignee:
    Unassigned
    Reporter:
    Bryce Nordgren
Vote (0)
Watch (0)

Dates

  • Created:
    15/Jul/04 2:52 PM
    Updated:
    23/Feb/07 5:21 PM
    Resolved:
    23/Feb/07 5:21 PM
  • Atlassian JIRA (v5.0.4#731-sha1:3aa7374)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.