opencaching.com

CoyoteRed · Joined: 18 Sep 2003 Posts: 220

We need a way to prevent/reduce collisions of ID and waypoint--two things I forgot in my other post--will go a fix that.

I propose starting at 2,000,000,000 and incrementing by 1,000. This way there won't be a collision in programs like Watcher with caches from GC.com

I'll claim base at 2,000,000,000!

As for waypoints, I figure just use it more like CB handles, only one in an area and if there is a dispute, work it out amongst yourselves.

What I mean is, the first 4 characters are like a callsign--I'll be using SNCR. The second two digits are alpha numeric. 0-9 and A-Z. I don't think you'd be able to enforce exclusions of any letters, so probably no need to even go there. So, my caches would be from SNCR00 through SNCRxx whatever base 36 is for 1000. That should be more than enough.

This scheme allows for individuals and teams, but also small cache hosting services.

CR

hmarq · Site Admin Joined: 15 Sep 2003 Posts: 351

The way I was thinking is a little different ... though not set in stone.

The site generating the extract will generate the waypoint id ... which may or may not be what the original site's waypoint id is ... this eliminates the collision issue as a single sequence is used for assigning the id internally.

For example, the caches here would be prefixed OC regardless of their origin, if I slurp all of navicaches first, they may become OC0001 through OCxxxx, their 'source' is attribute 'navicache' and internally I maintain the original waypoint name/number ... resynching then becomes a matter of searching based on source/original waypoint id, but for folks getting an extract from opencaching there would be a consistent waypoint format.

... so then you move on to geocache underground, slurp all those pages in using a spider, assign an OC waypoint to them a source of 'underground' and proceed along the same lines ... the update scripts would need to be modularized to process XML, crawl pages, take .NET feeds etc, but when someone searches or gets an XML/GPX feed from opencaching, the waypoint info is consistent and a 'source' attribute is added to the namespace that would extend GPX

As long as the source and original waypoint is included in any extract (or advanced search parameter) provided to sister sites, the same method syndicates well too.

That eliminates the need to assign address space to each user placing caches; which honestly would be a nightmare to maintain (for anyone, not just me) as you'd need a yet another 'authority' to allocate address space ... yuck.

robertlipe · Joined: 17 Sep 2003 Posts: 15

Please don't propogate that mistake.

Exposing record numbers to the user as THE way to identify a record is a bad idea. Fussing about name prefixes and length limits is silly - this should totally be done on the client side. Expose where the record came from (navicache,etc) and the name (which may or may not be unique) and let the client side software work it from there. Only it will know the "optimal" naming characteristics (character sets, length, etc.) and uniqueness requirements for any given target.

hmarq · Site Admin Joined: 15 Sep 2003 Posts: 351

Hmm, maybe I didn't say this right ...

Record numbers are a whole differnt thing that the world will never see, but unless there is rewrites of client software and they are adopted/upgraded, waypoint collision is a distinct possibility as I don't know of any client software processing a 'source' field as part of the data stream ... doesn't mean it won't happen.

I was just thowing out that aggregating sites should try and standardize the data regardless of it's source.