Geocaching Australia Development List

This page lists the development ideas for Geocaching Australia. If you want something added to this list, please post your request in the forum.

For changes to the Wiki, see the Wiki Development List.

Roadmap

Where are we heading?

Work on Backlog by your developers

caughtatwork

• Convert database from UTF8 to UTF8MB4 to address data storage characters sets.

On Hold

• Use output of a my query as a restriction list in Geocaching graphs:- Would it be possible to get stats on just the caches returned from a query? (think along the lines of setting a query in GSAK and then running FindStatGen) But this could be extended beyond just found caches. Could be used to answer questions along the lines of, of the caches in the zone x which has the most finds?, what percentage of SA's caches are micros?, In which month were the most events held?, Of the caches hidden by x and found by me what percentage are puzzles?, and so on... - Currently on hold pending architecture solution to request. As a query is specific to a user, different results will be produced depending on which query is used. The URL construction, if shared, will cause another user to see different results and may also leak sensitive information (such as home location) if not a public query. Public queries that use functions like found and not found will result in different outcomes and the static nature of the queries will result in a cached copy being show depending on the "last run today" and not refreshed.

Unorganised:

• What I would like to see is the descriptive naming of queries. ie found-caches-home100km.zip, rather than 1234.zip https://forum.geocaching.com.au/viewtopic.php?p=229149#p229149
• Use year(moment) rather than substring(moment,1,4) for improved selection criteria.
• Add year and year-month columns to geocache and log tables for improved selectability rather than trawl every record substringing the dates as you go,..
• Create a radar chart showing which degrees have or have not yet been found (All, GCA, dZ)
• Create a graph visualising relationships between geocachers (thickness of connection is strength of relationship) for one level of geocacher only.
• Create a graph visualising relationships between geocachers who have found the same geocaches on the same days and then their relationships creating a network of geocachers who have relationships to each other.
• Is it possible to add a API to edit/update a log? Because sometimes in the field you make mistakes and write a brief log you want to add to later. (mtrax)
• Investigate Create a Geocache page for speed and optimisation improvements.
• Reconfigure user tables to decouple from forum tables
• Rewrite all cache interactions as a single class
• Rewrite all log interactions as a single class which allows for configuration to allow for private logs such as "save specific notes for some GCA's (especially if they are multi-stepped or mysteries where you might want to be able to check the puzzle later on after you solved it earler."
• Enhance header to cater for responsive design and ads and competition banners
• Fix bounce handler
• I have recently started researching locationless caches and I frustration I found quite early on is that there are a fair number that aren't technically locationless. I'd love it if these type of locationless could have the state you need to be in to complete them added to the attributes. This way I would stop looking at the Queensland bus one, for example. . There need to be other ways to work out what locationless caches are about, so a text search needs to be allowed, or tagging to categorise them. I'd be looking for a whole of solution approach to locationless cache rather than piecemeal. Tag locationless caches
• NFC caches
• Add EPE to cache submission so finder can see how accurate the previous recording was. How to output in GPX file?
• Bulk/batch upload of logs - Have server notify you after it's all updated and processed.
• Improve Tag and Gallery visualisation
• Administrative Pages for Tags and Gallery, plus some stat generation
• Add state to http://wiki.geocaching.com.au/wiki/Cache_alerts to restrict caches to a stated state, even if it's inside the radius selected. i.e. Stops Tasmanian caches showing up in Victorian alerts. Trouble will occur for non-Australia cachers when their state won't be selectable. Want to try and keep the site as international as possible.
• Add functionality to alerts to stop alerts on moveables if already found. Should be able to make this user by user selection, but not cache by cache.
• Cacher specific galleries in new gallery system
• add more filters eg GCA only , cache-types to maps (along side found, owned, etc).
• Advanced" search options: (from search bar - not my query page) * Filter by cache type * Filter by cache owner * Filter by state
• HTML export from various cacher statistics pages (allow editing through FCK editor).
• Generate a GPX file based on the caches visible from a Google Map page.
• Allow cachers to add listing site prefixes to their ignore lists (like OX, OU, OK, GC, etc).
• When GeoArt is live, consider adding a "group" capability, like a GeoTour that you can use to view individual GeoArt collections. This is not the same as a tag as a tag would need to run through a MyQuery to extract and map whereas a GeoArt would be a separate list. Will be deferred until the volume of GeoArt is known and whether the collection is worthwhile to develop.

Rejected or not Required / Pursued

Ideas that have been proposed in the past but were rejected or did not progress at the time. These may always be brought up again in the future as times, minds and attitudes change with the influx of new players or the changing of the game over time.

• Codeword caches. As an add on to a cache you may be required to locate the codeword at the location. These may be too similar to virtual caches which have no box, history caches which require Q&A and not a box. Geocaching is about a box, not finding a codeword in a message on a plaque.

• Regular "Virtual" Event Activities _i.e. a scavenger hunt). A geocaching adventure where your location is independent of physical geocaches. A set of "requirements" is published in the event listing. The requirements are all virtual requirements in that they do not require a physical cache find, but virtual activities which can be achieved anywhere.

• Hunt the wocket (cache). A wocket is a cache. You have an event ... but it's a special event where people gather at a starting spot. There are 3 (or any number up to n depending on how many participants you have) special caches at the gathering spot. Each one with the organisers (need 1 organiser for each special cache (wocket)). The event starts. Each organiser heads off in a direction. They can be similar or different. 10 minutes later they stop and hide the geocache. They update the co-ordinates of their cache. The game is now on. Each of the teams at the event move towards a cache. They are not going to be in the same park, they're most likely a few km away by now. They will need to choose which one they head towards. They have 15 minutes to find the cache. The first person to find the cache gets 10 points. The next person gets 9, then 8, 7, 6 etc., until there are no more points to allocate or the time has expired. One you've found the cache you can head off to find one of the other in the game or you can wait. There's some strategy needed to decide how and where you are going. Your team cannot split up. After the 15 minutes is up the game piece moves on. Again a 10 minute travel time for the cache, hide and update the co-ords. The participants now have 15 minutes to get to the cache and collect some more points. After a few hours, the game is over and everyone gathers back at a central location for the rest of the event which is congratulating the winners (points are added up obviously), commiserating the losers, bitching about inaccurate co-ordinates or how much the rules of hunt the wocket suck.

• Geocaching Australia organises an Australia wide Rubber Duck Race. It's held in one town on a flowing body of water -- OR -- in each capital city. Permission is sought from the water owner (all capitals is going to be a logistical nightmare). People sponsor their way into the Rubber Duck Race for a nominal amount, (making numbers up), say $5.00. The winner, er, wins (something). The ducks are extracted from the body of water (including any who got lost along the way). The ducks are then released as movable Geocaching Australia Rubber Duck Geocaches. A few hundred identical Rubber Ducks are now available as Geocaching Australia geocaches. The race does not have to be along a river. The ducks could start at one event per state and then travel from that state. The duck further away from the start point when the game finishes is the winner.

• Dead Drop Caches http://wiki.opencaching.us/index.php/Dead_Drop_Caches

• Bit Caches http://wiki.opencaching.us/index.php/BIT_Caches

• Confluence caches - We are not restricted to just the degree confluence. If there are a number of degree confluences which are restricted by being on private property, we could increase the scope of the confluence caches by allowing a high frequency. e.g. Instead of just S37 E144 we could have S37 45 E144 45. Although that would increase the total number of possible confluences by a factor of 360 (60 x 60) to around 36,000. That seems a little over the top to me and I'd suspect that a significant number would be inaccessible as they would be on private property, especially in the urban areas. S37 10 E 144 10, S37 10 E 144 20, S37 10 E 144 20, etc would increase the CC's to around 8,000, again private property being most likely to kill a huge swathe of them.

• A Geocaching Australia version of the CITO event cache type. No traction and no interest.

• Geocaching Australia version of "challenge" caches. No traction and no interest.

• Geocaching Australia "Environment" cache. Better than a CITO by making the environment, not just cleaning it up. Small interest, no traction, no progress.

• Change the icons on the logs to a drop down list to save space / make look consistent.

• Integrate GPSBabel to support zillions of formats (GPSBabel is already integrated into the Route functionality and can be extended to cover any required format of data or use), so not required for any specific action.