Red Dwarf, maybe your feed reader is having trouble identifying non-new items ... or maybe i! are tweaking it still and it's slightly different each time? Can I clarify that you're actually getting repeated entries for the same cache in your feed reader?
- Rog
rss feed - beta testing [closed]
-
Mind Socket
- Posts: 1329
- Joined: 29 March 03 6:04 pm
- Location: Gladesville, Sydney
- Contact:
red dwarf: the feed is designed to feed the lastest 25 caches that fit the criteria. our understanding is that it is up to the news aggregator at the client end to work out which ones it has seen before. otherwise the central server would need to know what it's sent to each individual user, which is impossible without a login. it could be that your rss reader is having trouble identifying duplicates. perhaps we need to put in an explicit timestamp tag or other unique identifier to help it along. what rss reader are you using?
mind socket: we haven't been tweaking in the last few days until just now when we added an xml content header. so now when you open the feed in a browser, it's formatted nicely!
mind socket: we haven't been tweaking in the last few days until just now when we added an xml content header. so now when you open the feed in a browser, it's formatted nicely!
-
Two Goth Geeks
- 50 or more caches found
- Posts: 281
- Joined: 05 April 03 7:02 pm
- Twitter: TwoGothGeeks
- Location: Sydney, Australia
- Contact:
-
Richary
- 8000 or more caches found
- Posts: 4189
- Joined: 04 February 04 10:55 pm
- Location: Waitara, Sydney
I've noticed it can be a little behind. I'm getting the SA feed (and checked - every 60 minutes!) - but for example there were two new caches popped up since learly ast night that appeared on the gc.com latest SA caches page this morning but the RSS feed didn't get them until I logged back in this afternoon.
new user-configurable feed + other updates
we've added a user-configurable rss feed which allows you to get a feed of all new caches within a certain distance around a point
two use it, you'll need two parameters: the centre, which is a waypoint in the system, and a radius in kilometres
for example: http://geocaching.com.au/rss/user.rss?c ... &radius=30 will give you a feed of new caches around i!4: Metro which was in Hyde Park Sydney.
for your convenience, the feed includes the distance and bearing of each cache from your centre location.
bug: to keep the database query fast, the query doesn't search a circle, it searches a box, and the box is simply the number of kilometres converted to nautical miles and then to a square lat/lon range. ie it's not super accurate. do not sue us if you specify 30km and it missed out on a virgin cache 29.9km away.
we have also made some other minor updates:
- layout changed to reflect the mobile geocaching australia layout
- australian feed now tells you what state the cache is in
- long descriptions are no longer published - these were making the feed quite large. if you want the long description, it's one click away. let us know if this is a pain in the neck
- co-ordinate displays now have a leading zero for single-digit minutes
red dwarf, are you still having the problem? if so, what reader are you using?
richary, the reason for it being a little behind is that the feed into geocaching.com.au is only daily. hence our promise that there will be nothing different every 10 minutes of the day and night!
two use it, you'll need two parameters: the centre, which is a waypoint in the system, and a radius in kilometres
for example: http://geocaching.com.au/rss/user.rss?c ... &radius=30 will give you a feed of new caches around i!4: Metro which was in Hyde Park Sydney.
for your convenience, the feed includes the distance and bearing of each cache from your centre location.
bug: to keep the database query fast, the query doesn't search a circle, it searches a box, and the box is simply the number of kilometres converted to nautical miles and then to a square lat/lon range. ie it's not super accurate. do not sue us if you specify 30km and it missed out on a virgin cache 29.9km away.
we have also made some other minor updates:
- layout changed to reflect the mobile geocaching australia layout
- australian feed now tells you what state the cache is in
- long descriptions are no longer published - these were making the feed quite large. if you want the long description, it's one click away. let us know if this is a pain in the neck
- co-ordinate displays now have a leading zero for single-digit minutes
red dwarf, are you still having the problem? if so, what reader are you using?
richary, the reason for it being a little behind is that the feed into geocaching.com.au is only daily. hence our promise that there will be nothing different every 10 minutes of the day and night!
-
Two Goth Geeks
- 50 or more caches found
- Posts: 281
- Joined: 05 April 03 7:02 pm
- Twitter: TwoGothGeeks
- Location: Sydney, Australia
- Contact:
a nice intro on rss is available at pc world
we have blocked a SA and a QLD ip because they were sampling the feed every 10 or 20 minutes. sorry to be a pain but we are trying to keep the bandwidth down and want to avoid the rss feeds turning into dripping taps. we know people aren't doing it intentionally. it looks like we need to write some code to detect it and send an error message until they reset to every hour.
we also did some minor changes this morning to better display accented and other special characters that some people are using. if you see some oddities that are not displaying correctly, please let us know.
red dwarf, we've installed RSSReader and can't reproduce your problem. please let us know if it happens again
we have blocked a SA and a QLD ip because they were sampling the feed every 10 or 20 minutes. sorry to be a pain but we are trying to keep the bandwidth down and want to avoid the rss feeds turning into dripping taps. we know people aren't doing it intentionally. it looks like we need to write some code to detect it and send an error message until they reset to every hour.
we also did some minor changes this morning to better display accented and other special characters that some people are using. if you see some oddities that are not displaying correctly, please let us know.
red dwarf, we've installed RSSReader and can't reproduce your problem. please let us know if it happens again
-
caughtatwork
- Posts: 17016
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
cache locations
we've modified the RSS feed to show the postcode area the cache is in. in cities, this is a usually a suburb. in other areas, it's the name of the town or greater region.
positives:
- an easy way to understand where the cache is
negatives:
- the change will cause most RSS readers to think these are new caches. you can either ignore the old ones or clear your RSS reader's old headlines
risks:
- we're doing this based on postcode, so there's a chance that it will identify caches as being in mail sorting centres, etc! let us know if you spot some bizarre ones
- we had to do some changes at the back-end to make this work, so it may trigger some other bug... err features. let us know if you see anything strange
positives:
- an easy way to understand where the cache is
negatives:
- the change will cause most RSS readers to think these are new caches. you can either ignore the old ones or clear your RSS reader's old headlines
risks:
- we're doing this based on postcode, so there's a chance that it will identify caches as being in mail sorting centres, etc! let us know if you spot some bizarre ones
- we had to do some changes at the back-end to make this work, so it may trigger some other bug... err features. let us know if you see anything strange
-
caughtatwork
- Posts: 17016
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Not quite bizzare, but something a little astray.
http://www.geocaching.com/seek/cache_de ... ?wp=GCJWC8
Because I can
by Uncle Jiffy on 30 June 2004
GCJWC8
Deer Park, Vic
http://www.geocaching.com/seek/cache_de ... ?wp=GCJWCA
Ping Pong
by Uncle Jiffy on 2 July 2004
GCJWCA
Sydenham, Vic
These are about about 500 meters from each other, both in the same postcode area of Sydenham (3037), but are showing up as different suburbs.
Deer Park (3023) is quite a distance away and in between there is St. Albans (3021).
As I said, not necessarily bizzare, but somewhat out of the ordinary.
http://www.geocaching.com/seek/cache_de ... ?wp=GCJWC8
Because I can
by Uncle Jiffy on 30 June 2004
GCJWC8
Deer Park, Vic
http://www.geocaching.com/seek/cache_de ... ?wp=GCJWCA
Ping Pong
by Uncle Jiffy on 2 July 2004
GCJWCA
Sydenham, Vic
These are about about 500 meters from each other, both in the same postcode area of Sydenham (3037), but are showing up as different suburbs.
Deer Park (3023) is quite a distance away and in between there is St. Albans (3021).
As I said, not necessarily bizzare, but somewhat out of the ordinary.
well spotted! it's highlighted to us the deficiencies of a quick-n-dirty routine we are using
we don't have accurate postcode boundary maps, but we do have coordinates which we have assumed are roughly the centre of the postcode area. at first glance we thought that this issue was simply due to the caches being slightly closer to the centre of one postcode than another.
however, on investigation, the cause is our quick-n-dirty "nearest point" routine. a nearest point routine is quite CPU-intensive because you need to compare the point in question with every point in the postcode database. rather than do the proper trig calculations to get the exact distance, we simply did a quick calculation of trying to minimise lat1-lat2 + lon1-lon2 where 1 is the cache and 2 is every possible postcode. we didn't even do any pythagorean stuff. we knew this would give rough results, but didn't think it would matter with such supposedly large areas like postcodes. boy were we wrong!
here's the caches you mentioned, with a list of nearby postcode regions. the list is ordered by the quick-n-dirty algorithm. note how sydenham is the first on the list for ping pong, but second for because i can. the difference is the difference in algorithms. the quick-n-dirty algorithm doesn't take into account that the lines of longitude squash together as you go further towards the pole. now look at the distances in kilometres. these are calculated using a trig algorithm, which seems to give more sensible answers. (we don't know the area, but it seems to concur with what you were saying.)
GCJWCA: Ping Pong:
Sydenham: 2.7km NW
Deer Park: 4.3km S
Keilor: 5.2km E
Albion: 6.6km SE
Tullamarine: 8km E
GCJWC8: Because I can:
Deer Park: 4km S
Sydenham: 3.1km NW
Keilor: 4.8km E
Albion: 6.1km SE
Tullamarine: 7.7km E
so, what are we going to do? to keep the speed up, we'll do a three-step process to get the nearest postcode area. firstly, narrow down the postcode database to the nearest half a degree either way. secondly, apply the quick-n-dirty routine and pick the closest ten postcodes according to that. thirdly, apply the full trig functions to those ten to determine the closest cache.
wow, all that just to work out where a cache is!
we don't have accurate postcode boundary maps, but we do have coordinates which we have assumed are roughly the centre of the postcode area. at first glance we thought that this issue was simply due to the caches being slightly closer to the centre of one postcode than another.
however, on investigation, the cause is our quick-n-dirty "nearest point" routine. a nearest point routine is quite CPU-intensive because you need to compare the point in question with every point in the postcode database. rather than do the proper trig calculations to get the exact distance, we simply did a quick calculation of trying to minimise lat1-lat2 + lon1-lon2 where 1 is the cache and 2 is every possible postcode. we didn't even do any pythagorean stuff. we knew this would give rough results, but didn't think it would matter with such supposedly large areas like postcodes. boy were we wrong!
here's the caches you mentioned, with a list of nearby postcode regions. the list is ordered by the quick-n-dirty algorithm. note how sydenham is the first on the list for ping pong, but second for because i can. the difference is the difference in algorithms. the quick-n-dirty algorithm doesn't take into account that the lines of longitude squash together as you go further towards the pole. now look at the distances in kilometres. these are calculated using a trig algorithm, which seems to give more sensible answers. (we don't know the area, but it seems to concur with what you were saying.)
GCJWCA: Ping Pong:
Sydenham: 2.7km NW
Deer Park: 4.3km S
Keilor: 5.2km E
Albion: 6.6km SE
Tullamarine: 8km E
GCJWC8: Because I can:
Deer Park: 4km S
Sydenham: 3.1km NW
Keilor: 4.8km E
Albion: 6.1km SE
Tullamarine: 7.7km E
so, what are we going to do? to keep the speed up, we'll do a three-step process to get the nearest postcode area. firstly, narrow down the postcode database to the nearest half a degree either way. secondly, apply the quick-n-dirty routine and pick the closest ten postcodes according to that. thirdly, apply the full trig functions to those ten to determine the closest cache.
wow, all that just to work out where a cache is!
-
caughtatwork
- Posts: 17016
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Interesting problem you ran into.
I understood most of what you explained and then go lost (but that's kind of normal).
I appreciate your efforts in going to the trouble to work it all out. It makes life easier when at a quick glance you can see if it's close enough to rush to or not.
Just another quick question (while I'm here).
In the RSS feed which I parse onto my webpage (rather than go the rss reader route), the file (http://geocaching.com.au/rss/vic.rss) has a field <description> which contains markup and all of the information sort of blobbed in together.
I'm interested to understand your thought process in providing the field with markup in it vs. providing the information in different fields and letting the end user make the markup decisions.
eg.
Description may have:
<description><center><b>MichaelÂ’s not Noahs ARC</b> <br>by Mr.Coffee on 6 July 2004 <br>GCJX3H <p>Narre Warren, Vic <br>S 38& 1.187 E 145& 18.075<p>Difficulty: 1 <br>Terrain: 1 <br>Type: Multi-Cache <br>Container: Other </center><p>This Cache is a gentle stroll or a nice swim.</description>
As an RSS / XML feed why doesn't this come out something like:
<title>MichaelÂ’s not Noahs ARC</title>
<owner>by Mr.Coffee</owner>
<placed> on 6 July 2004</placed>
<waypoint>GCJX3H</waypoint>
<location>Narre Warren, Vic</location>
<bearing>S 38& 1.187 E 145& 18.075</bearing>
<difficulty>1</difficulty>
<terrain>1</terrain>
<type>Multi-Cache</type>
<container>Other</container>
<description>This Cache is a gentle stroll or a nice swim.</description>
Not saying you have to change it, but I am interested in the thought process.
It may be that I'm used to a feed that gets parsed onto a web page rather than an rss reader, so I'm unused to seeing the markup in the blob on information rather than getting individual fields which I can then choose to markup as I deem necessary.
Again, no criticism, I think you guys do a great job in getting info to us.
Regards.
caughtatwork.
I understood most of what you explained and then go lost (but that's kind of normal).
I appreciate your efforts in going to the trouble to work it all out. It makes life easier when at a quick glance you can see if it's close enough to rush to or not.
Just another quick question (while I'm here).
In the RSS feed which I parse onto my webpage (rather than go the rss reader route), the file (http://geocaching.com.au/rss/vic.rss) has a field <description> which contains markup and all of the information sort of blobbed in together.
I'm interested to understand your thought process in providing the field with markup in it vs. providing the information in different fields and letting the end user make the markup decisions.
eg.
Description may have:
<description><center><b>MichaelÂ’s not Noahs ARC</b> <br>by Mr.Coffee on 6 July 2004 <br>GCJX3H <p>Narre Warren, Vic <br>S 38& 1.187 E 145& 18.075<p>Difficulty: 1 <br>Terrain: 1 <br>Type: Multi-Cache <br>Container: Other </center><p>This Cache is a gentle stroll or a nice swim.</description>
As an RSS / XML feed why doesn't this come out something like:
<title>MichaelÂ’s not Noahs ARC</title>
<owner>by Mr.Coffee</owner>
<placed> on 6 July 2004</placed>
<waypoint>GCJX3H</waypoint>
<location>Narre Warren, Vic</location>
<bearing>S 38& 1.187 E 145& 18.075</bearing>
<difficulty>1</difficulty>
<terrain>1</terrain>
<type>Multi-Cache</type>
<container>Other</container>
<description>This Cache is a gentle stroll or a nice swim.</description>
Not saying you have to change it, but I am interested in the thought process.
It may be that I'm used to a feed that gets parsed onto a web page rather than an rss reader, so I'm unused to seeing the markup in the blob on information rather than getting individual fields which I can then choose to markup as I deem necessary.
Again, no criticism, I think you guys do a great job in getting info to us.
Regards.
caughtatwork.
-
Mind Socket
- Posts: 1329
- Joined: 29 March 03 6:04 pm
- Location: Gladesville, Sydney
- Contact:
RSS does not provide for custom tags like those listed. There has to be a link, description etc.
If you want that sort of information in separate fields, your best bet is get GPX files (the synergistic official defacto standard XML for geocachers
) from geocaching.com (premium membership required) or from a site like roblisa.
- Rog
If you want that sort of information in separate fields, your best bet is get GPX files (the synergistic official defacto standard XML for geocachers
) from geocaching.com (premium membership required) or from a site like roblisa.- Rog