Release Notes 4/21/09

[+stevefash]

...

One suggestion for the maps page. Is there any way you can make the scrollwheel zoom in/out when the mouse is over the map? It makes it a lot easier to move and and zoom in/out on the map. It works on maps.google.com.

...

 

You can double-click to zoom in and right-mouse-button-double-click to zoom out on the Geocaching.com Google maps page. It works great and it's quicker than using the zoom slider.

[+deejay44]

I will add my disappointment at the loss of th GE kml I guess its a case of the powers that be cant be bothered if only a few use it (and that is a suprise as it is a very usefull tool).

[+supertbone]

I rarely used the GE KML so I am not concerned about it.

[+gof1]

I rarely used the GE KML so I am not concerned about it.

 

So, what feature is going away next? Is it going to be one you use and enjoy?

[+Cache O'Plenty]

I must have been in the 200 also as I used it quite often. It wasn't the accuracy issue for me since I only wanted to see cache density anyway. From there, I'd develop PQs for the areas I wanted to visit.

 

I'm planning to visit Washington DC in two weeks and used the KML to work up the planning.

 

Fortunately, the KML I have still works but I'm sure it will expire soon.

 

Is the KML available somewhere else?

[+Lil Devil]

how do I use the built in maps to do that when you don't know of any caches in the area in the first place?

Go to the search page, enter the coords or zip code you want to look at, click "search" and on the resulting page, click the button.

 

Huh? A server is more than hardware - it is also software. Perhaps the Microsoft model is not one that works well for such a busy place. Would not this place have been better served using Linux & PHP right from the start?

Microsoft/ASP.net and Linux/PHP are just tools. Either set in the hands of a capable programmer can accomplish the same thing. Jeremy himself has admitted that he was not the best programmer in the world when he built this website as a hobby. But he has hired good people and they continue to improve the site just fine. The problem is that the sport/addiction has grown faster than they could keep up.

 

... and Get this forum on its own Box.

It's already on it's own box. Again, the problem is software. IPB doesn't scale well to a community of this size, which is why Groundspeak has stated in another thread that they will be upgrading to Community Server at some point.

[+beejay&esskay]

I must have been in the 200 also as I used it quite often.

 

 

I wonder about the validity of the "200" value. Since only a small subset of the site users post here...but it seems that quite a few have already stated they used the KML.

[+Frank Broughton]

how do I use the built in maps to do that when you don't know of any caches in the area in the first place?

Go to the search page, enter the coords or zip code you want to look at, click "search" and on the resulting page, click the button.

 

Huh? A server is more than hardware - it is also software. Perhaps the Microsoft model is not one that works well for such a busy place. Would not this place have been better served using Linux & PHP right from the start?

Microsoft/ASP.net and Linux/PHP are just tools. Either set in the hands of a capable programmer can accomplish the same thing. Jeremy himself has admitted that he was not the best programmer in the world when he built this website as a hobby. But he has hired good people and they continue to improve the site just fine. The problem is that the sport/addiction has grown faster than they could keep up.

 

... and Get this forum on its own Box.

It's already on it's own box. Again, the problem is software. IPB doesn't scale well to a community of this size, which is why Groundspeak has stated in another thread that they will be upgrading to Community Server at some point.

 

Very good answers Lil Devil - thanks. Indeed this forum is begging for an update. Glad to know it is on its own box. Sorry if I sounded condescending. Being in Washington and all I guess the Microsoft tie in is appropriate.

 

Funny thing while trying to send this post I get this error:

 

IPB WARNING [2] mysql_connect(): Can't create a new thread (errno 12). If you are not out of available memory, you can consult the manual for a possible OS-dependent bug (Line: 131 of \ips_kernel\class_db_mysql.php) font-family:arial,sans-serif; font-size:11px; }

 

There appears to be an error with the database.

You can try to refresh the page by clicking

here

.

 

Error Returned

SQL error: Can't create a new thread (errno 12). If you are not out of available memory, you can consult the manual for a possible OS-dependent bug SQL error code: Date: Wednesday 22nd of April 2009 12:15:07 PM

We apologise for any inconvenience

 

[+Great Scott!]

Really dissapointed with the discontinuation of the Google Earth KML overlay - I used it to identify caches when I go on holiday - Will be in the New Forest area and used it to find caches around where we will be staying - how do I use the built in maps to do that when you don't know of any caches in the area in the first place? Then will be in Washington DC and have the same problem??

 

I've always used the map on any cache page for screening other areas for caches. Clicking on the map opens a new map page. Then zoom the map out and and drag the map with the cursor. When I get to the area I want to view, I start double clicking to zoom in (or use the zoom bar) Change to satellite view and it's basically the same as google earth. Only better because the caches don't jump around when you move the map.

[+spotter/g]

I like the Geocaching Logo on the printer friendly pages, I really liked when there was Signal with a cache on the page. I also miss when the pages had the small icon that listed the direction and distance from my home coordinates. I haven't been able to check, but I also liked when a user posted a waypoint correction in a log that it printed with the printer friendly pages.

 

Thank you for all your hard work!

[LordEd]

It has never been a hardware issue. Unfortunately there are problems that can't be solved by throwing money at them.

...I bet you'd love to try. Spreading the database across a couple of 10-drive 15k RPM RAID 1+0 drive arrays and adding a few TB (terabytes, not travel bugs) of memory would work wonders.

Edited April 22, 2009 by LordEd

[+Markwell]

Will be in the New Forest area and used it to find caches around where we will be staying - how do I use the built in maps to do that when you don't know of any caches in the area in the first place? Then will be in Washington DC and have the same problem??

 

I'm confused (not hard to do!).

 

If I'm traveling somewhere and want to see the caches along the way, I can use the route functionality to get me a pretty good listing of caches within 5 miles of my route. I can view the PQ results on Google Earth from the GPX.

 

If I'm going to be in a certain area and want to see what's in the area, I can go to the Advanced Seek Page and key in an address, town, zip code in the top address line, or even more precise coordinates below, and click the Map It icon on the search results. When I typed in District of Columbia for the address at the top with a radius of 10 miles, I got this page. When I click the "Map It" icon, I get this page.

 

If I wanted the closest 500 caches to downtown Washington D.C., I could do a Pocket Query based on the coordiantes in that url: .../map/default.aspx?lat=38.90598&lng=-77.03342.

 

If I wanted more than 500 caches, I could (within a fairly short time) write a series of pocket queries:

Caches within 30 miles placed between Jan 01 1994 and Apr 01 2005 (494 caches)

Caches within 30 miles placed between Apr 02 2005 and Aug 01 2006 (469 caches)

Caches within 30 miles placed between Aug 02 2006 and Jul 01 2007 (473 caches)

Caches within 30 miles placed between Jul 02 2007 and Mar 01 2008 (477 caches)

Caches within 30 miles placed between Mar 02 2008 and Aug 26 2008 (484 caches)

Caches within 30 miles placed between Aug 27 2008 and Mar 13 2009 (498 caches)

Caches within 30 miles placed between Mar 14 2009 and Dec 31 2010 (077 caches)

Yea - it's more than 5 PQs, but you can get them 3 each on two days. Then you have all 2,972 caches within 30 miles of downtown Washington DC, and can open the file on the Google Earth. If you're more selective on the types of caches (container size, difficulty, terrain, cache type) you could probably get that down to one day's worth of pocket queries. Reduce the distance, and you've definitely got it down.

 

Then plop the GPX files into Google Earth and you're set.

 

While the Google Earth functionality was convenient, it seems to have two major drawbacks and I remember one minor drawback.

Minor Drawback: Having to figure out how to turn off the auto-refresh so you didn't run out of "page views" at the end of the day.

Major Drawback #2: Intentional Randomness of coordinates

Major Drawback #1: Site usability (grinding it to a halt)

 

When you consider that the KML is looking at the area against 1.2 million entries in the system (GC1QD0Z was published today and has an ID of 1210117) I can see where there's a problem determining if the caches are nearby and thus included in the view on the KML, etc., etc. It was essentially doing a mini-pocket query with each view AND randomizing the coordinates. Users could do this all day long with 150(?) refreshes a day. No wonder this was grinding it to a halt.

 

I'm sorry that the functionality that everyone seems to be missing was the one that was killing the site's usability. I do know that the loss of a functionality seems like something is being taken away, but I believe the programmers seriously weighed the costs and benefits before doing something this drastic.

[+StarBrand]

It has never been a hardware issue. Unfortunately there are problems that can't be solved by throwing money at them.

...I bet you'd love to try. Spreading the database across a couple of 10-drive 15k RPM RAID 1+0 drive arrays and adding a few TB (terabytes, not travel bugs) of memory would work wonders.

You are assuming they don't do this already..........

[GOF and Bacall]

Really dissapointed with the discontinuation of the Google Earth KML overlay - I used it to identify caches when I go on holiday - Will be in the New Forest area and used it to find caches around where we will be staying - how do I use the built in maps to do that when you don't know of any caches in the area in the first place? Then will be in Washington DC and have the same problem??

 

I've always used the map on any cache page for screening other areas for caches. Clicking on the map opens a new map page. Then zoom the map out and and drag the map with the cursor. When I get to the area I want to view, I start double clicking to zoom in (or use the zoom bar) Change to satellite view and it's basically the same as google earth. Only better because the caches don't jump around when you move the map.

 

Once again the broad view isn't there. The 500 cache barrier gets in the way.

[GOF and Bacall]

Will be in the New Forest area and used it to find caches around where we will be staying - how do I use the built in maps to do that when you don't know of any caches in the area in the first place? Then will be in Washington DC and have the same problem??

 

I'm confused (not hard to do!).

 

If I'm traveling somewhere and want to see the caches along the way, I can use the route functionality to get me a pretty good listing of caches within 5 miles of my route. I can view the PQ results on Google Earth from the GPX.

 

If I'm going to be in a certain area and want to see what's in the area, I can go to the Advanced Seek Page and key in an address, town, zip code in the top address line, or even more precise coordinates below, and click the Map It icon on the search results. When I typed in District of Columbia for the address at the top with a radius of 10 miles, I got this page. When I click the "Map It" icon, I get this page.

 

If I wanted the closest 500 caches to downtown Washington D.C., I could do a Pocket Query based on the coordiantes in that url: .../map/default.aspx?lat=38.90598&lng=-77.03342.

 

If I wanted more than 500 caches, I could (within a fairly short time) write a series of pocket queries:

Caches within 30 miles placed between Jan 01 1994 and Apr 01 2005 (494 caches)

Caches within 30 miles placed between Apr 02 2005 and Aug 01 2006 (469 caches)

Caches within 30 miles placed between Aug 02 2006 and Jul 01 2007 (473 caches)

Caches within 30 miles placed between Jul 02 2007 and Mar 01 2008 (477 caches)

Caches within 30 miles placed between Mar 02 2008 and Aug 26 2008 (484 caches)

Caches within 30 miles placed between Aug 27 2008 and Mar 13 2009 (498 caches)

Caches within 30 miles placed between Mar 14 2009 and Dec 31 2010 (077 caches)

Yea - it's more than 5 PQs, but you can get them 3 each on two days. Then you have all 2,972 caches within 30 miles of downtown Washington DC, and can open the file on the Google Earth. If you're more selective on the types of caches (container size, difficulty, terrain, cache type) you could probably get that down to one day's worth of pocket queries. Reduce the distance, and you've definitely got it down.

 

Then plop the GPX files into Google Earth and you're set.

 

While the Google Earth functionality was convenient, it seems to have two major drawbacks and I remember one minor drawback.

Minor Drawback: Having to figure out how to turn off the auto-refresh so you didn't run out of "page views" at the end of the day.

Major Drawback #2: Intentional Randomness of coordinates

Major Drawback #1: Site usability (grinding it to a halt)

 

When you consider that the KML is looking at the area against 1.2 million entries in the system (GC1QD0Z was published today and has an ID of 1210117) I can see where there's a problem determining if the caches are nearby and thus included in the view on the KML, etc., etc. It was essentially doing a mini-pocket query with each view AND randomizing the coordinates. Users could do this all day long with 150(?) refreshes a day. No wonder this was grinding it to a halt.

 

I'm sorry that the functionality that everyone seems to be missing was the one that was killing the site's usability. I do know that the loss of a functionality seems like something is being taken away, but I believe the programmers seriously weighed the costs and benefits before doing something this drastic.

 

Yes, we can do a bunch of work manipulating our PQs to get enough info to replicate the results. Still doesn't mean we won't miss the easy way. We'll see how much the site improves.

 

Is it such a horrible thing that we will miss a feature we enjoyed? Oh well, we're out numbered. I guess we should just go away and not bother the rest of you.

 

How about something a bit more useful and constructive. I don't know if this is even feasible as I'm computer challenged. Is there a way that the 500 cache limit can be doubled for the maps? It isn't a cure but it would help ease the withdrawal.

[+Prime Suspect]

Really dissapointed with the discontinuation of the Google Earth KML overlay - I used it to identify caches when I go on holiday - Will be in the New Forest area and used it to find caches around where we will be staying - how do I use the built in maps to do that when you don't know of any caches in the area in the first place? Then will be in Washington DC and have the same problem??

Go to the Find a Cache page. Select District of Columbia from the Local State Page selector. Select Washington City. When the list comes up, click on the Map It icon. Enjoy!

[+intolerable]

Can't get the broad view that was available the other way. If you back the view out on the maps you end up with an exceeded 500 caches message. In Google Earth it would show fewer caches but maintain relative densities. Cities showed more caches that rural areas. A good overview that you could then zoom into.

 

Also was very nice being able to use the other features of Google Earth, such as planning routes, seeing the terrain, being able to view any number of overlays, all at once.

[+edscott]

If it is the 500 cache limit that is the major problem, then allowing additional filtering when specifying the map could ease that problem. The ability to hide or select caches based on size and/or difficulty would be a useful tool for me.

[+Sir Lamorak]

I too was one of the 200 that used KML and Google Maps to locate caches in an area that I might visit. It will be missed but I can understand that it could have been resource hungry. Being from Canada I was unsure that the current google maps would work........but they do. It does seem to be a faster, I just don't seem to get the detail that I did with the KML files. EI being able to centre from a camp ground.

[GOF and Bacall]

Can't get the broad view that was available the other way. If you back the view out on the maps you end up with an exceeded 500 caches message. In Google Earth it would show fewer caches but maintain relative densities. Cities showed more caches that rural areas. A good overview that you could then zoom into.

 

Also was very nice being able to use the other features of Google Earth, such as planning routes, seeing the terrain, being able to view any number of overlays, all at once.

 

Good points. The broad view was just my example of a use that won't be filler by the other maps.

[CoyoteRed]

If it is the 500 cache limit that is the major problem, then allowing additional filtering when specifying the map could ease that problem. The ability to hide or select caches based on size and/or difficulty would be a useful tool for me.

You're right.

 

Instead of getting rid of the feature, I'd upgrade it:

• Allow filtering of the types, sizes, and ratings similar to that of a PQ.
  
• Make it "On Refresh" only so every move doesn't hit the server.
  
• Don't limit the return to only the window, but the nearest total as specified in the options. This would mean that you wouldn't need to hit the server as often.
  
• Make the returns ordered from the center of the window so you're not missing caches within the window if the return goes beyond the limit like it did previously.
  
• GET RID OF THE FUDGE FACTOR!
  

The biggest problem though is getting past the Groundspeak mentality of data protection. The "fudge factor" is product of that. I believe one of the highest priorities for getting rid of the KML feature was solving this very issue: how to provide quick serving of data while protecting the data. The return on investment for solving this problem simply wasn't worth it.

[+Corey]

The "fudge factor" made sense when the KML was at a static location on the website and thus could be accessed by anyone. For a while now, requests go through buildnetworkkml.aspx which presumably requires log-in.

 

I'm having trouble seeing how it would be less efficient than the Google Maps interface.

They seem to both involve:

• Client sends viewing rectangle to server
  
• Server returns names, IDs, types of caches within that window
  

For Google Earth, the server does have to wrap the data in the proper KML. That shouldn't be processor-intensive; some structure has to be given to the data returned for Google Maps requests as well.

Then there's the randomization. That could be coded inefficiently, but I believe it's really unnecessary.

[+tysonb]

".......and the performance hit to the site....." Seriously?! Sheesh, get another server already or upgrade the current one(s). Weak, very weak.

[Keystone]

".......and the performance hit to the site....." Seriously?! Sheesh, get another server already or upgrade the current one(s). Weak, very weak.

Your post demonstrates a lack of knowledge about Groundspeak's server configuration, among other things. It would have been fine to simply express your disappointment and disagreement.

 

From the Forum Guidelines:

 

Forum courtesy: Please treat Groundspeak, its employees, volunteers, fellow community members, and guests on these boards with courtesy and respect.

 

If you cannot post constructively and respectfully, don't post. Thank you.

[+Lil Devil]

".......and the performance hit to the site....." Seriously?! Sheesh, get another server already or upgrade the current one(s). Weak, very weak.

Your post demonstrates a lack of knowledge about Groundspeak's server configuration, among other things. It would have been fine to simply express your disappointment and disagreement.

Can't blame him for lack of knowledge about the servers (but yeah he could have said it better). It's been a few years since Groundspeak has said publicly what they have. Unfortunately I'm not allowed to say, but as a reviewer I've heard a bit about the servers and they are impressive pieces of hardware. I laugh every time someone says to throw more hardware at the problem because what they have is already so powerful. I've heard Jeremy talk about loads on the servers and how various software improvements have lowered the CPU usage. None are anywhere near capacity. (Except maybe the forum box.) The problem now really is in the software, and they're continually working on that.

[+Labrador Wild Man]

I always have a good read of the release notes,i do hope one day they would update the T/B My Inventore ie a drop down so i have all my unkown loctions out of the way or something better.

 

well just a thought.

 

Labrador Wild Man

[+Frank Broughton]

None are anywhere near capacity. (Except maybe the forum box.) The problem now really is in the software, and they're continually working on that.

 

These days bandwidth, RAM and HD space are so cheap there should never be a shortage of that in any internet server. CPU the same, now software, all these hooks all over the place take big hits in the data bases. That is where the improvements need to take place. Can it be done properly in a Windows environment? That is the big question Lil Devil - has this been debated at headquarters?

 

Do not get me wrong, I am very happy with the service I get for my $30 a year. I am just wondering outloud and fishing for some tech info about the place.

Edited April 25, 2009 by Frank Broughton

[+uxorious]

Another bug they may need to fix is whatever software that tells you how much something is used. The idea that only 200 people used KLM is ridiculous. I know several people that used it, and I know a very small, tiny number of the total cache population.

 

I am one of those "old" people that do not like change, but if KLM was giving more problems than benefits then I guess I can find a new system to search for maps.

[+Plan - B]

Can't get the broad view that was available the other way. If you back the view out on the maps you end up with an exceeded 500 caches message. In Google Earth it would show fewer caches but maintain relative densities. Cities showed more caches that rural areas. A good overview that you could then zoom into.

 

Also was very nice being able to use the other features of Google Earth, such as planning routes, seeing the terrain, being able to view any number of overlays, all at once.

 

Good points. The broad view was just my example of a use that won't be filler by the other maps.

 

It worked great for hiding as well. You could take a quick look and see about basic proximity issues, area terrain, if there is a nice group of trees to hide you cache in and what the access to the site is like. You just can't do all that with the google maps set up. I'll gonna miss google earth as well.

[+larryc43230]

It worked great for hiding as well. You could take a quick look and see about basic proximity issues, area terrain, if there is a nice group of trees to hide you cache in and what the access to the site is like. You just can't do all that with the google maps set up. I'll gonna miss google earth as well.

Just to be clear, nothing at all has happened with Google Earth, it's only the method that has to be changed. I've never used that downloaded KML; I order up a pocket query for the area I'm interested in, then import that GPX file into Google Earth. It's much more accurate (doesn't have the randomization added in), and still works fine.

 

--Larry

[+BCandMsKitty]

I'm gonna miss the Google Earth KML. I guess I was one of the 200. I used that constantly. I'm gonna need to learn some new trick.

 

Yeah .. me too.

[+takssista]

I'm sad about seeing the Google Earth kml feature go. As I said in another related post, I can't believe only 200 worldwide used it regularly.

 

My planning depended on it, and I tried using the embedded map feature on the site, but it isn't as easy to use: I had to manually drag the location to the city where I'm standing (from the US to Wester Europe) and even then, the plugin wouldn't finish parsing the caches.

 

IMHO, it's a bad bad move, and I'm sorely dissapointed with Groundspeak for killing that superb app.

[+jtbrady01]

I'm confused. Everyone's talking about the Google Earth KML. Is this the same thing as the "Find Caches Along a Route" feature?

[+takssista]

It is (was?) a file you added to your Google Earth that enabled you to see caches wherever you zoomed in (with a 500 cache limit, which was more than enough, IMHO).

[+jtbrady01]

Okay, I think I did that once to see what it was about. Now if they can get my emails to work on the threads I'm subscribed to I'll be happy.

Edited April 26, 2009 by jtbrady01

[+Sahara M]

I just wanted to register my disappointment at the removal of the google earth feature. I found it useful to assess if the terrain of the caches in an area seemed suitable for us now all caches are done with a pushchair in tow - especially as many users do not mark their caches as buggy friendly when they are! I know I don't get to cache as often as some so maybe I am not counted as one of the 'regular users', but I was a regular user of this whenever I was planning to go caching and will sorely miss this function.

[+RadioKrafter]

Thank you for all the hard work!!

Edited April 27, 2009 by RadioKrafter

[+renruts]

Hey guys, appreciate the updates and continued work being put forth to make the site better. I too am disappointed with the loss of the kml network, although can understand the need to reduce the footprint for scalability issues...

 

What I would like to see is Groundspeak take a step back and look at the current model, and the new proposed model and really consider breaking some of the bounds of todays quazi stagnate computing model, and move to an even more pervasive model that influences and harnesses infocentricity. Unfortunately I think this will require a lot of thought and a geographically distributed architecture...

 

The organizational models developed over twenty years ago—windows, folders, relational databases, etc just do not seem to lend themselves very well to todays massive data structures.

 

Once again guys appreciate the continuing efforts to make our geocaching logistics experiences more pleasurable.

[+tozainamboku]

Hey guys, appreciate the updates and continued work being put forth to make the site better. I too am disappointed with the loss of the kml network, although can understand the need to reduce the footprint for scalability issues...

 

What I would like to see is Groundspeak take a step back and look at the current model, and the new proposed model and really consider breaking some of the bounds of todays quazi stagnate computing model, and move to an even more pervasive model that influences and harnesses infocentricity. Unfortunately I think this will require a lot of thought and a geographically distributed architecture...

 

The organizational models developed over twenty years ago—windows, folders, relational databases, etc just do not seem to lend themselves very well to todays massive data structures.

 

Once again guys appreciate the continuing efforts to make our geocaching logistics experiences more pleasurable.

Why do I feel like I'm reading a Dilbert strip?

[+StarBrand]

Hey guys, appreciate the updates and continued work being put forth to make the site better. I too am disappointed with the loss of the kml network, although can understand the need to reduce the footprint for scalability issues...

 

What I would like to see is Groundspeak take a step back and look at the current model, and the new proposed model and really consider breaking some of the bounds of todays quazi stagnate computing model, and move to an even more pervasive model that influences and harnesses infocentricity. Unfortunately I think this will require a lot of thought and a geographically distributed architecture...

 

The organizational models developed over twenty years ago—windows, folders, relational databases, etc just do not seem to lend themselves very well to todays massive data structures.

 

Once again guys appreciate the continuing efforts to make our geocaching logistics experiences more pleasurable.

Why do I feel like I'm reading a Dilbert strip?

Wow! the Pointy Haired Boss's fingerprints are all over that one.

 

In layman's terms please?? (I have 20+ years in computer repair/programming and database management and I still can't read it)

[+gof1]

Judging by the condition of this floor I'm thinking someone is using this place to breed cattle.

[+renruts]

Hey guys... sorry about that. Without a bit of understanding of pervasive computing it may be a bit fuzzy, but here are some principles of infocentricity which lays the ground work...

 

Information-centric design places primacy on the information itself to support direct interaction between people and information. That is, it gives users direct, hands-on contact with objects that represent the information they will view and manipulate to perform their work. Information is represented as first-class objects that can reside and be manipulated in visualizations, user interfaces, on desktops, in briefing materials, or anywhere else people elect to place it. This is different from the common application-centric UI, where manipulation is through an application and is constrained by file formats. Ultimately, infocentricity is concerned with usability (i.e., it is user-centered) in that it reduces the complexity and restrictions created when people can’t access information directly. It empowers users to capitalize on the skills they already have in manipulating and re-purposing objects in the real world, so they don’t have to learn new skills defined by some application designer. Real infocentric design will eliminate the mechanics of running and coordinating applications and working with file system metaphors in order to interact with information. It allows the users get their hands on the data.

 

Here are three basic principles for understanding and creating an infocentric UI:

1. Foundation. An information-centric user interface relies on a solid information architecture that also drives the system architecture. (i.e., you can’t just build infocentricity on top of any old foundation). Design teams must focus first on things as the primary information currency of the system. With this focus, they must develop an IA that the whole team will refer to. In the underlying system design, all information objects are fundamentally similar, making an infocentric UI possible.

 

2. Representation. Visually representing information in the user interface will establish the perception of objectness in the user’s mental model. All information is represented in the form of discrete virtual objects—as things. Distinct objects of information should have a discernible outline that separates them from the graphical world around them. An information-centric visualization is not so much drawn as it is composed—made up of arrangements of things.

 

3. Interaction. The interaction will adhere to an interaction physics. Whenever possible, infocentric UIs should derive their behaviors from UI physics, as opposed to “just so” rules-of-thumb. As I use it here, “physics” means simply a set of behavioral rules with no exceptions. So in the UI, the interaction physics calls for direct manipulation of information.

 

These three principles can make information centricity seem deceptively simple. As with anything, however, the challenges lie in the detailed execution...

Edited April 27, 2009 by renruts

[+renruts]

StarBrand, Wikipedia calls it Ubiquitous computing versus pervasive, here is their link: http://en.wikipedia.org/wiki/Ubiquitous_computing.

 

Sorry for derailing the topic for a moment...

[+beejay&esskay]

StarBrand, Wikipedia calls it Ubiquitous computing versus pervasive, here is their link: http://en.wikipedia.org/wiki/Ubiquitous_computing.

 

Sorry for derailing the topic for a moment...

 

You should probably start a new thread to explore this further.

[+spoxox]

... only about 200 users regularly (emphasis mine) accessed the Google Earth KML....

 

I regularly used the Google Earth KML every time I traveled, which was infrequent. Very disappointed with this.

 

Relevance to thread waning...but as these fixes are performance matters, perhaps a slightly long-winded performance question fits: Also very curious about the rationale behind the decision to keep operational details private. None of my business, of course, but if the reasoning is available somewhere I'd be interested to read it. My guess is other profit options are in place or planned that would mandate keeping trade secrets. Of course, with constant performance issues, perhaps the product isn't yet salable. All of which begs the question: with the open source model certainly well established, is there ever any thought put to tapping a larger resource in the search for solutions? Presumably, DBs are replicated and partitioned globally; we hear servers and network capacity are computationally powerful.... As an IT pro, I can't help but speculate about the bottleneck(s).

[+Abraxas]

... only about 200 users regularly (emphasis mine) accessed the Google Earth KML....

 

I regularly used the Google Earth KML every time I traveled, which was infrequent. Very disappointed with this.

 

Indeed. I'm sitting at a conference in Montreal. I spun Google Earth over to Montreal, then zoomed down to the area around my hotel and turned on my Google Earth plug in. Nothing. Then I found this thread. Very sad!

 

It's true, as people have said, that you can using zip codes or search Canadian provinces, but Groundspeak's plug-in was one of the best Google Earth apps I'd ever seen. In my case, I know I'm going to visit a few places in Canada and NE US. I could look up zip codes or tool around finding them on the integrated map, but using Google Earth is so much easier because I can see the topography along with the general cache location. So it wasn't just convenient, it was useful for gauging hard terrain caches.

 

But, you get what you pay for, so there's nothing to complain about. I would like to lodge another vote for bringing back this fine feature. How about requiring a manual refresh it (i.e. disable the streaming queries when the window is moved). That would greatly lower the server pull, and yet give virtually the same functionality that we've come to love. Just a thought. . .

 

Abraxas

[+LightHouseSeekers]

Not sure if this belongs here or I if should start a new topic.

RE: Field Note Upload. The last few times I did this it gave the not before date as "01/01/0001". Previously it was whenever the last upload was made. ie: 04/27/2009

[+Markwell]

For those still writing in this thread regarding the KML, please see Nate's post here.

[+gof1]

Yes. Lets take it over here where it's easier to ignore.

[+Crow-T-Robot]

Since they don't want to talk about the KML issue in this thread, how about switching gears and figuring out why the travel bug mileage still doesn't update automatically.

 

Bruce