| 63 | | || 41 || || || || || |
| 64 | | || 42 || || || || || |
| 65 | | || 43 || || || || || |
| 66 | | || 44 || || || || || |
| 67 | | || 45 || || || || || |
| 68 | | || 46 || || || || || |
| 69 | | || 47 || || || || || |
| 70 | | || 48 || || || || || |
| 71 | | || 49 || || || || || |
| | 63 | || 41 || ||Configuration ||The way that !GeoNetwork handles timeouts to remote requests is not configurable. Action: In GeoNetwork, timeout on remote requests e.g. WMS, should be configurable via the administration interface.|| || |
| | 64 | || 42 || ||Project management / sandbox strategy||Developments in "sand boxes" are not pushed back into the trunk in a timely manner. Action: The PSC should publish and enforce tighter processes relating to sandboxes. If possible, all sand box developments should be pushed back into the trunk in a predetermined time period (this should be a condition of being granted permission to set up a sandbox). If the sand box feature can't be pushed into the trunk because the trunk code doesn't have the capability (e.g. Pluggable profiles, pluggable skins) then priority should be given to developing that capability in the trunk so that the sand box feature can be included into the trunk (relates to project management comment/observation above). || || |
| | 65 | || 43 || ||Customization||!GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins. Action: !GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code. || || |
| | 66 | || 44 || ||Installer / Application server||There is no (installer) option to choose Tomcat as an alternative to Jetty. Comment: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation. Action: !GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container. Jetty should continue to be the default. || || |
| | 67 | || 45 || ||Parent/child policy ||Parent/child/sibling bidirectional navigation for metadata records Finding the parent or child of given record is painful Action: Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity. For example, listing all children under the parent and presenting this within a collapsed tree GUI component. Perhaps provide a way to limit results to only parents and toggle this option on/off. || || |
| | 68 | || 46 || ||Search||Community is seeking a way to deal with varying granularity of metadata records, such that fine scale records don’t swamp fewer broad scale records. Many fine scale records (highly granular) make the metadata system more powerful (useful). Being forced to limit granularity only as a work around for basic search result presentation/visualisation would be a shame. || || |
| | 69 | || 47 || || Vocab / Thesaurus||Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. || || |
| | 70 | || 48 || ||Reusable Objects || Reusable (Controlled) Objects, allow fields to be reusable. Currently, if a user were to enter multiple records, for each record that user would have to re-enter “owner” their details. Worse, if that person’s details were to change, they remain the same in old records for which they have edited. The person’s details should be held as a managed object for which all records reference. This would allow the updating of details be reflected in each record that uses them - see the fragment harvesting of contact info above.|| || |
| | 71 | || 49 || ||HTTPS support || HTTPS support. Currently all logins to !GeoNetwork are going unsecured through HTTP and the GN configuration doesn’t allow the use of HTTPS enabling account sniffing attacks.|| || |
| | 72 | || 50 || ||CRS management || EPSG code data from external service Action: At the moment EPSG codes have to be entered manually, but external online services are available with that data. GN should utilize this.||François works on that recently? || |
| | 73 | || 51 || || Hierarchical keywords|| Keywords from external vocabularies should utilize hierarchical broader/narrower structures to ease searching capability.|| || |
| | 74 | || 52 || ||Indexation enhancement|| Using Apache Tika to index content from files attached to metadata records in !GeoNetwork?|| || |
| | 75 | || 53 || ||Indexation enhancement || Replace Lucene interface in GN with Apache Solr?|| || |
| | 76 | || 54 || ||Schema management || !SchemaManager - redesign proposed by Mathieu: * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks?|| || |
| | 77 | || 55 || || Multi-editing || Attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk. || || |
| | 78 | || 56 || ||Customization || Improve CSS management, clean CSS file and references to unused styles, replacing tables by divs, discuss on [wiki:ThemeCustomization]|| || |
| | 79 | || 57 || ||Maven migration ||Move to Maven as described here : [wiki:Maven] ||Mathieu (major) || |
| | 80 | || 58 || ||Settings management || While at it can we change the code so that you can save settings from the GUI even if not all expected settings are present in your database?|| || |
| | 81 | || XX || || || || || |
| 81 | | |
| 82 | | * The way that !GeoNetwork handles timeouts to remote requests is not configurable. Action: In GeoNetwork, timeout on remote requests e.g. WMS, should be configurable via the administration interface. |
| 83 | | |
| 84 | | * Developments in "sand boxes" are not pushed back into the trunk in a timely manner. Action: The PSC should publish and enforce tighter processes relating to sandboxes. If possible, all sand box developments should be pushed back into the trunk in a predetermined time period (this should be a condition of being granted permission to set up a sandbox). If the sand box feature can't be pushed into the trunk because the trunk code doesn't have the capability (e.g. Pluggable profiles, pluggable skins) then priority should be given to developing that capability in the trunk so that the sand box feature can be included into the trunk (relates to project management comment/observation above). |
| 85 | | |
| 86 | | * !GeoNetwork is not distributed with multiple skins and it does not allow pluggable skins. Action: !GeoNetwork should be released with multiple skins that can be optionally selected and are pluggable. These skins should be easily modified for an organisation’s needs and not be contained within the XSL or Java code. |
| 87 | | |
| 88 | | * There is no (installer) option to choose Tomcat as an alternative to Jetty. Comment: The current situation reflects GeoNetwork’s origins, particularly its funding bodies. Adding Tomcat and supporting it would require fixing some current defects - a good thing. But it would be a lot of work to maintain it, in particular, it would significantly increase the time required for testing and release preparation. Action: !GeoNetwork should use the existing BlueNet MEST Tomcat configuration to provide an option within the installer to choose Tomcat instead of Jetty as the servlet container. Jetty should continue to be the default. |
| 89 | | |
| 90 | | * Parent/child/sibling bidirectional navigation for metadata records Finding the parent or child of given record is painful Action: Use of parent/child/sibling metadata records in the search results as a way to cope with varying levels of record granularity. For example, listing all children under the parent and presenting this within a collapsed tree GUI component. Perhaps provide a way to limit results to only parents and toggle this option on/off. |
| 91 | | |
| 92 | | * Community is seeking a way to deal with varying granularity of metadata records, such that fine scale records don’t swamp fewer broad scale records. Many fine scale records (highly granular) make the metadata system more powerful (useful). Being forced to limit granularity only as a work around for basic search result presentation/visualisation would be a shame. |
| 93 | | |
| 94 | | * Support for external vocabulary services Vocab services are becoming more common and an ability to connect to a custodians vocab service would be beneficial and reduce duplication and creation of stale vocabs/ thesauruses in GN. Action: An interface is required to query for vocab definitions from external sources. |
| 95 | | |
| 96 | | * Reusable (Controlled) Objects, allow fields to be reusable. Currently, if a user were to enter multiple records, for each record that user would have to re-enter “owner” their details. Worse, if that person’s details were to change, they remain the same in old records for which they have edited. The person’s details should be held as a managed object for which all records reference. This would allow the updating of details be reflected in each record that uses them - see the fragment harvesting of contact info above. |
| 97 | | |
| 98 | | * HTTPS support. Currently all logins to !GeoNetwork are going unsecured through HTTP and the GN configuration doesn’t allow the use of HTTPS enabling account sniffing attacks. |
| 99 | | |
| 100 | | * EPSG code data from external service Action: At the moment EPSG codes have to be entered manually, but external online services are available with that data. GN should utilize this. |
| 101 | | |
| 102 | | * Hierarchical keywords. Keywords from external vocabularies should utilize hierarchical broader/narrower structures to ease searching capability. |
| 103 | | |
| 104 | | ---- |
| 105 | | |
| 106 | | * Using Apache Tika to index content from files attached to metadata records in !GeoNetwork? |
| 107 | | |
| 108 | | * Replace Lucene interface in GN with Apache Solr? |
| 109 | | |
| 110 | | * !SchemaManager - redesign proposed by Mathieu: |
| 111 | | * use org.geonetwork.utils.xsd.XSD in the project "geonetwork-services-ebrim" to read schemas and query contents for driving the editor |
| 112 | | * GN uses a number of schemas for validation purposes eg. in OAI, could these be managed by schemamanager so that they do not need to be retrieved from net? |
| 113 | | * sometimes a document may introduce a new schema eg. !ListSets response in OAI harvester can introduce the oai_dc schema eg. when harvesting jOAI - if we need to validate these responses then creating a validator with a file based schema will cause the validation to fail as the schema is not present on disk, alternative to is create a validator with no file based schema which means that all schemas will be obtained from the net but use an entityResolver object to intercept those which are local so as to avoid unnecessary retrieval or perhaps use a Java Cache System (JCS) instance to cache all schemas locally like XLinks? |
| 114 | | |
| 115 | | * Multi-editing - attempting to introduce the ability to edit more than one document makes existing trunk interface confusing eg. editing documents in tabs both of which have login details. Things get out of sync - what to do? Maybe something like BlueNetMEST which is based on one window - the main search window (tabs for remote, advanced and mapviewer) with search results - editing/viewing by clicking on title opens editor/viewer in new window (multiediting is supported), clicking any of the menu options on main screen uses modalbox dialog and separate windows to keep search interface and results window untouched, log out/log in closes all editor/viewer windows to close, if editing in progress log out not allowed - this is not perfect but might be a way of thinking about how to introduce things like multiediting to trunk. |
| 116 | | |
| 117 | | * Improve CSS management, clean CSS file and references to unused styles, replacing tables by divs, discuss on [wiki:ThemeCustomization] |
| 118 | | |
| 119 | | * Move to Maven as described here : [wiki:Maven] |
| 120 | | |
| 121 | | More 'way out' stuff :-)? |
| 122 | | |
| | 87 | * More 'way out' stuff :-)? |
| 124 | | |
| 125 | | |
| 126 | | |
| | 89 | * Verbal annotations for !YouTube videos - verbal annotations for metadata records? |
| | 90 | * CouchDB to hold metadata documents, couchdb-lucene to build lucene indexes, geocouch for spatial queries? Could couchdb be worth investigating further? |
| | 91 | * !GeoNetwork should be to metadata and data management as iTunes is to managing music or !TimeMachine is to backup? ie. we have a great engine what about building the 'killer' interface? who would do this? |
