Westacular
-
Posts
65 -
Joined
-
Last visited
Posts posted by Westacular
-
-
Heh. Curious.
There's a system in place for submitting edits to places on Google Maps, that get passed through some sort of moderation/verification before being approved. If you look on the zoo's POI pop-up on Google Maps, there's a "Show All Edits" link. One of the things it seems you can do with this is add additional names to places, or names in other languages.
Skimming through the edit history, it looks like what happened was there was a big edit to the item a month ago that added/corrected a bunch of information, and changed the classification of the name in various languages, and somehow the name with the language set to English was deleted but not re-added in this process:
Changed on May 11, 2011 5:23amApproved |
Name
Deleted: Toronto Zoo (French, type: Obscure)
Deleted: トロント動物園 (Japanese, type: )
Deleted: Зоопарк Торонто (Russian, type: )
Deleted: 多伦多动物园 (Chinese (China), type: )
Deleted: 多倫多動物園 (Chinese (Taiwan), type: )
Deleted: Toronto Zoo (English, type: Obscure)
Added: Toronto Zoo (German, type: Preferred)
Added: Toronto Zoo (Turkish, type: Preferred)
Added: Toronto Zoo (French, type: Preferred)
Added: トロント動物園 (Japanese, type: Preferred)
Added: Зоопарк Торонто (Russian, type: Preferred)
I'm not quite sure if this was some clever vandalism or an honest mistake. There's a couple week-old "pending" edits to switch it back to the English name.
-
I decided to repackage this and instructed the program to skip .author and .DS_Store files. Pretty sure they are not necessary - the torrent is being streamed by my Windows server and MacOS likes to sprinkle dot files on network filesystems.
.DS_Store files are created by Finder; they store any custom display attributes for the folder, much like Desktop.ini in Windows. Definitely don't need to be in the torrent. I'm not familiar with .author but it almost certainly just contains some other local metadata/cache and also shouldn't be in the torrent.
There's a hidden setting you can use to stop .DS_Store files from being written to network volumes: http://support.apple.com/kb/ht1629
-
The calendar checks for updates based on your settings (under Mail etc -> Fetch New Data). It doesn't push, so it's the fetch schedule options that apply here. I'd recommend setting this calendar to "manual"; if it's only updated a couple times a week, there's no sense checking in the background every hour. The manual setting is a bit of a misnomer, in my opinion: it just means that it will automatically check for an update only when you load Calendar, and not in the background.
No, it won't show notifications for new events. They'll just quietly show up on the calendar. (You could use premium member email notifications + Boxcar to get a parallel stream of push notifications for event caches as they're published)
-
No simple/automatic way: event listings don't have a structured way of recording specific times; you have to read the descriptions.
Awesome job! I've wondered for a long time why Groundspeak isn't doing this themselves.
A few questions/comments:
Is the location field only based on the county name? I ask because I notice some Ontario events listed as being in Brantford, ON -- Brantford is a city; its county name is Brant. That might be a bug in your county data.
For any event in southern Ontario, the distances from Thunder Bay and Sault Ste-Marie are useless for getting a rough sense of location. (For northern Ontario, though, they're probably a good choice.) For extra reference points, off the top of my head, I'd say the next two cities that might be most helpful for rough triangulation are Sudbury and London.
-
I do have utorrent...but when I click on your link I get the same page...all letters numbers and symbols.
Empty your cache and try again
OR
Try in a different browser you didn't use earlier
OR
Right-click on the link and choose "Save as...", make sure the extension is .torrent and not .torrent.html, then open that file
OR
If it still opens in the browser as garbled text, hit Refresh, and your browser might offer to download it instead
OR
Do what rovers3 said
Basically: ibycus's web server was telling your browser to treat the torrent file as text, which the browser can display directly, rather than an exotic file type that the browser can't display directly and must therefore download. He's fixed that problem, BUT, your browser is still remembering the value from before he fixed it. Any of the above will correct or avoid that issue.
-
Excellent! I look forward to checking this out.
One note, however: your web server is sending the .torrent file with the mime-type "text/html", causing most browsers to display it as text instead of handling it normally. The correct mime-type is "application/x-bittorrent".
-
I'm aware of one, but it's in Burlington -- completely the opposite corner of the GTA from what you're remembering. There could be another one out that way, though.
-
One general trick I do when I know I'm going to want to geotag the photos is to take a photo of the GPS screen at some point, with it showing the time (including seconds).
This lets me later go back and adjust the time for each photo, en masse, to remove the offset between the camera's time and the GPS's time. (Lightroom is once again handy for this.) It makes for more accurate geotagging, and it's also a handy way to note if you've forgotten to account for timezones or DST.
This isn't really necessary if you manually sync you camera clock to the time on your GPS in advance, but ... that is something I usually forget about until halfway through a trip, and I've already taken a few hundred photos with no clue as to the state of my camera's clock.
-
I've used a bunch of things over the years -- lately I've been using Jeffrey Friedl's GPS plugin for Lightroom. It works nicely since I tend to import photos into Lightroom first and only later do I go back and geotag them. Could be smoother, but it does what I need it to do, and it's donationware.
-
Because it would be too tricky to decide where to place it on the grid?
-
Hmm, the website is now showing the $8 price as starting on Tuesday.
-
Tempting... thought it's a shame that their Kitchener store (for me) is in the most distant, most inconvenient non-rural location that exists within Kitchener or Waterloo city limits.
-
Actually... QLandkarte is multiplatform and its developers actively maintain versions on Windows and OS X. I haven't played with it on a Mac, and it's almost certainly not suitable for the less technically inclined, but it is another option.
-
On the flip side:
The .GMAP format that Garmin's Mac apps require is actually the *only* format in which Garmin has been shipping its DVD-based maps for the past couple years. There's nothing Mac-specific about it; all of Garmin's Windows tools handle this format without problem. Probably safe to guess its the *preferred* format and the reason Garmin hasn't bothered supporting the older IMG tile format on the Mac is that they're trying to migrate away from it in their desktop software. (Hardware units, of course, still depend on having the data packed together in monolithic IMG files.)
... But the new .GMAP format is not actually that different. Garmin's IMG is a structure for packing multiple subfiles together, where the different types of subfiles describe different aspects of the map data. The .gmap format uses these exact same subfiles, it just packages them differently.
Specifically: A .gmap map is a folder that contains the same old TDB, TYP, etc files for the mapset, along with an Info.xml file describing the contents, and in place of hundreds of IMG files, you have hundreds of directories that each contain the different subfiles that were formerly within that IMG file. All the conversion process really does is alter some header data and split these subfiles apart.
The OpenStreetMap folks have made their own python tool for doing the conversion, but it's buggy and dependent on the structure of the IMG set that their other tools output -- I tried it with Ibycus Topo just now and it choked.
-
The same goes for no trespassing signs. I have seen a few caches receive complaints about crossing no trespassing signs or jumping a fence. There very well could be another way in that does not require trespassing or fence jumping. I hate to see logs from a cacher that posts that they crossed several no trespassing signs to get the the cache, claimed their smiley, and then complained about it.
Off-topic a bit, but: I ran into a similar problem a bunch when I was in California recently; I encountered lots of caches on trails at the top of hills, where the base of the hill is almost completely surrounded by a labyrinthine subdivision with no gaps between houses... and yet, no child waypoints or any other indication of parking or a trailhead.
My view is that in any case where "no trespassing" signs is an issue (or, indeed, any case where the cache can or should only be accessed from a particular direction which isn't immediately obvious if you try to drive up to the cache) there should be some text and/or child waypoints indicating the direction from which to approach the cache.
I know there's some cache owners out there who want part of the challenge to be finding the necessary trail or approach, but if that's the case, there should be clear indications of it in the cache description. Locations that are girded by "No Trespassing" signs aren't appropriate for this sort of hide.
It feels like there's in a gap when it comes to reports these situations. Missing details from the listing (usually) don't pose problems that warrant a NM or NA log. Simply describing you concern (and maybe posting a coord that should be added) in a note or log helps, but if the cache owner doesn't act on that, it will gradually disappear from notice.
One idea: Allow cachers to submit child waypoints to a listing, so all an owner needs to do is click "approve" to have it added.
-
Other than parking lot caches
That's kinda the key issue, though, isn't it? A parking lot seem like a public space (on private property), but some are more public than others.
There's a difference between a Tim Horton's lot, and the parking at a private office building or industrial park. For the former, there's an expectation that random people will come and go as they please at all hours of the day; for the latter, strangers or anyone who falls outside a fairly narrow pattern of coming and going is viewed with suspicion.
-
LOL @ your Needs Archived log, NP.
Some bomb squads are equipped with portable X-rays scanners -- I doubt Orillia or Timmins are, but Peel Region might be. There are risks in the X-rays detonating the bomb, though. With something outdoors and just the size of a micro they might have thought it not worth the trouble and jumped straight to the controlled detonation.
-
"Satellite view" is a bit of a misnomer, since the high-resolution images are actually stitched together from aerial photo surveys. Google licenses these images from various sources, and updates them every few years, depending on the area. It's patchwork. You use the "report a problem" link in the bottom corner to request updated images in cases where the photo does not reflect the current reality. (Also cases where the road data is missing or incorrect.) They might not fix it instantly, but it will at least help them keep track of what to prioritize in their updates.
If you look at the data using Google Earth, it will actually tell you when the photographs were taken. The Niagara Falls images are mostly from 2005 and 2002.
-
Ooh! Good idea for a placement. Wish I could help, but I'm not really equipped to at the moment. If all else fails, you could wait for winter and go out on the ice? (This doesn't solve the maintenance question, though.)
-
It teaches children about responsibility (trading fairly, respecting others property and the environment)
These are divorce lawyers he's dealing with. To their minds, trading fairly and respecting others' property IS extremely immature.
-
I'd sure like to have a release before the weekend, we'll see how it goes. There's been a lot of work going on behind the scenes, particularly with a large section of submitted data and the TYP file to improve visibility on the topo maps and Oregon units. You may not like the TYP file I'm using -- what you see below is what's on my GPS at the moment. Feedback is welcome of course.
Keep your C:\ONTTRAILS\1033E.TYP file in case you want to revert to the TYP file from the last version.
In the mean time, here's my current mapset --- a "beta" if you will for Garmin users, that should fill in the gap.
Img file for Colorado/Oregon/Dakota
These links will remain active until the "full" version is launched.
I'm really liking this new style. Distinctive and very easy to read (on my Oregon 300) but it also manages to avoid getting in the way of other map details.
-
If you assume that caches are placed randomly (and that the entire area is viable for cache placements) then the probable limit is 25-28 per square kilometer. Of course, normally the entire area isn't viable, so the practical limit on density is somewhat less than that.
hmm, sounds like a challenge..
Which part? Meeting that number, or exceeding it?
I was curious and actually ran some quick simulations that revealed 25-28 as the distribution -- I remembered a bit of code I have sitting around that, although written for another purpose, works well to provide a quick and dirty answer to this question. It's basically just dropping circles of a given radius onto random-but-allowable spots a plane until there isn't space for any more. On a 1000-by-1000 m grid, where the centre of each circle must be at least 160 m from any other, that no-more-space limit was consistently reached at between 25 and 28 circles. If the locations are planned/coordinated in advance, you could squeeze a few more in.
As to an entire square kilometer being viable for hiding spots, I was imagining an urban area (ie, where cache density is actually an issue), where buildings and private property could lead to certain "holes" in the cache layout that would be unfillable. If you had a 1x1 km block of unrestricted, public-use forest, then filling it to the cache-radius capacity might not be so difficult.
-
Maybe my math is wrong. Need someone to double check.
194 per KM?
Unless you're looking at a spot with an insanely high cluster of virtuals and mysteries, your math has to be wrong -- the 161 m limit puts a cap of 36 per square kilometer on cache density. And even that is quite contrived, depending on a precise grid spacing between all of the caches.
If you assume that caches are placed randomly (and that the entire area is viable for cache placements) then the probable limit is 25-28 per square kilometer. Of course, normally the entire area isn't viable, so the practical limit on density is somewhat less than that.
-
I like to look at it this way. Would the cache you're about to place be of interest to someone from out of town for any reason than 'just another smiley?' If the answer is no, that's probably one cache beyond the optimal for that area.
Sadly, that seems to be exactly what a lot of people are looking for. Drive-up, hike 2 metres, lift the skirt. Repeat. Makes me nauseous. Can't understand why anybody who cares a whit for real geocaching would ever hide one of these lame things.
When you're just starting out, there's a certain rush that comes with the novelty of finding something hidden in a public space like that. That novelty wears off at different rates for different people... and people have similarly differing standards for the amount of originality that should go into a hide.
Lamp posts offer a sort of low-hanging, urban fruit that can help get newbies started. They're not my preference, either, and we could probably do with less of them, but at the same time I'm hesitant about calling any one interpretation of the game as "real geocaching".
Does WAAS work in Canada or not?
in Canada
Posted
True. Doug mixed up the details, however:
1) WAAS relies on ground-based reference stations to provide relevant correction data for different regions. There weren't any active in Canada until 2007. Prior to that, much of northern and eastern Canada effectively weren't covered.
2) Geostationary satellites necessarily orbit above the equator. As you move north, the apparent elevation of the satellite gets closer to the horizon, and the signal becomes harder to receive (and, if you're not in a plane, more likely to be blocked by local terrain). Compared to the original two satellites, the current ones (2 became active in 2007 and a third in 2010) have stronger signals, and are positioned at better longitudes for covering Canada.
The conclusion stands: In Canada, the general usefulness of WAAS is much better now than it was pre-2007.
Useful links:
"WASS IN CANADA"
The FAA's WAAS Test Team Website, which has a number of interesting real-time maps and graphs like the one ky.m.guy posted.