Hello all,
We want to offer locationless caches.
This type is doesn't need a coordinate and is not country bound. As an old TC user I know that possible fields shoot be chosen carefully. This make finding a cache on subject easier
Is it possible to code a page for this?
If needed I can offer a Db for all node who can insert the caches in the same Db. ( we still have a reserve ip on our server)
Locationless caches
-
OlofL
Our users started to use virtual caches for both virtual and locationless. The locationless are very popular and we have no plans to restrict this, but there are quite a few issues, the main problem is for the cache owner to remove bogus logs. Many cache owners have expressed that they feel pressure to not remove logs that seem to fulfill the found requirement but are not what the cache owner intended.
We have identified two distinct types of locationless, fixed and non fixed. A fixed locationless is a cache that the next visitor would expect to find exactly the same thing. This would be suitable for additional child waypoints associated with the log. The non-fixed is more of "document something volatile and where you found it".
En excellent example of the first type is "Locate a 4-winged windmill". En excellent example of the second type is "Find the animal that is the symbol for you state". This second specific example is clear and have not caused any problem (except picture stealing from the internet), but the non-fixed type is what is causing all the problems in judging whether the cache have really been found or if it is only a couch-log.
We have a draft for an icon for the locationless type and are working on adding child waypoints to a log.
As a site admin I think that the locationless is a real problem because they are causing irritation and friction among the users. But as a cacher I really like them. But as a site admin I would not recommend you allowing non-fixed and not recomment allowing additional logging requirement like the order of logs. I have one of those myself, "Signspotting", the users are expected to find traffic signs with increasing numbers in sequence starting from 1. Platespotting would be similiar but also non-fixed.
A full implementation for these would allow a special search beacuse as you say, they have no coordinate. But at the same time, we don't want to do the waymarking-thing and separate it into another site that no-one uses. Unfortunately the code behind the current searchpage is not something for the weak-hearted...
We have identified two distinct types of locationless, fixed and non fixed. A fixed locationless is a cache that the next visitor would expect to find exactly the same thing. This would be suitable for additional child waypoints associated with the log. The non-fixed is more of "document something volatile and where you found it".
En excellent example of the first type is "Locate a 4-winged windmill". En excellent example of the second type is "Find the animal that is the symbol for you state". This second specific example is clear and have not caused any problem (except picture stealing from the internet), but the non-fixed type is what is causing all the problems in judging whether the cache have really been found or if it is only a couch-log.
We have a draft for an icon for the locationless type and are working on adding child waypoints to a log.
As a site admin I think that the locationless is a real problem because they are causing irritation and friction among the users. But as a cacher I really like them. But as a site admin I would not recommend you allowing non-fixed and not recomment allowing additional logging requirement like the order of logs. I have one of those myself, "Signspotting", the users are expected to find traffic signs with increasing numbers in sequence starting from 1. Platespotting would be similiar but also non-fixed.
A full implementation for these would allow a special search beacuse as you say, they have no coordinate. But at the same time, we don't want to do the waymarking-thing and separate it into another site that no-one uses. Unfortunately the code behind the current searchpage is not something for the weak-hearted...