Suggestion: display o-ordinate format alternatives
- CraigRat
- 850 or more found!!!
- Posts: 7015
- Joined: 23 August 04 3:17 pm
- Twitter: CraigRat
- Facebook: http://facebook.com/CraigRat
- Location: Launceston, TAS
- Contact:
Re: Suggestion: display o-ordinate format alternatives
I nominate this thread for the most bizzare brain hurting feature request thread EVER.
Kenny, can you check that the UTM position matches the proper format as far as location goes? It looks ok to me, but I have no idea if it is correct or not
Kenny, can you check that the UTM position matches the proper format as far as location goes? It looks ok to me, but I have no idea if it is correct or not
Re: Suggestion: display o-ordinate format alternatives
....gets out topo map of local area.......CraigRat wrote:I nominate this thread for the most bizzare brain hurting feature request thread EVER.
Kenny, can you check that the UTM position matches the proper format as far as location goes? It looks ok to me, but I have no idea if it is correct or not
Yep, I can report that the UTM co-ords of GA1688 are spot on. And yep, I would have to second that vote that this thread is very brain hurting, just to read!
- WazzaAndWenches
- 5000 or more caches found
- Posts: 395
- Joined: 08 April 07 10:28 pm
- Location: Echuca, Vic
Re: Suggestion: display o-ordinate format alternatives
UTM......Absolutely no use to me whatsoever. Why would anyone want to use that when the world revolves around dd mm.sss caching?caughtatwork wrote:Requested: 29 April 10 5:48 pm
Delivered: 29 April 10 8:13 pm
Elapsed: 2 hours 25 minutes.
All hail the CraigRat
BUT......Fantastic job CR - problem solved and solution installed within a very short time.
PS........Can someone politely shove this thread into the groudspeak forum just so we can stick it up the slooow commercialised yanks.
-
- 2700 or more caches found
- Posts: 1213
- Joined: 31 October 03 11:45 am
- Twitter: rhinogeo
- Location: Benalla, VIC
Re: Suggestion: display o-ordinate format alternatives
WazzaAndWenches wrote:UTM......Absolutely no use to me whatsoever. Why would anyone want to use that when the world revolves around dd mm.sss caching?
I found my first 5 caches using UTM and a dodgy eMap I borrowed from workPapa Bear_Left wrote:We used to use UTM all the time in the Good Old Days(tm), i.e. in the days before GPSrs had maps on them.
We noticed that the Sydways street directory had numbers on the grid that were the last few digits of the UTM coords, meaning that we could get the coords of the next waypoint of a multi or a puzzle and find out where it was without going to an Internet cafe or back home to look it up on a mapping website or program.
Given that just following the magic arrow in Sydney usually ends up with you in a cul-de-sac looking at water with no bridge to cross it, this was a major discovery!
The destruction book had gone missing so with UTM's direct correlation to metres, a compass and an idea from my old mate Pythagorus I could work out where I was in relation to the cache
Kids with mapping GPSrs these days don't appreciate how lucky they are
- CraigRat
- 850 or more found!!!
- Posts: 7015
- Joined: 23 August 04 3:17 pm
- Twitter: CraigRat
- Facebook: http://facebook.com/CraigRat
- Location: Launceston, TAS
- Contact:
Re: Suggestion: display o-ordinate format alternatives
The reason they appear slow is they fix the site the way we used to, by releasing different 'versions' with lots of changes in one hit.WazzaAndWenches wrote:PS........Can someone politely shove this thread into the groudspeak forum just so we can stick it up the slooow commercialised yanks.
The down side of this is that when you do that, you usually break as much stuff as you fix. It's not the way it should be done in this day and age.
We use a software versioning tool so if something we add breaks we can instantly go back to what was there before.....it's not rocket science.
I'm surprised they don't run with the "release early,release often" method, it makes them look like dinosaurs.
That's what I'd do if I was in charge (other than scrapping Premium Memberships )
- caughtatwork
- Posts: 17017
- Joined: 17 May 04 12:11 pm
- Location: Melbourne
- Contact:
Re: Suggestion: display o-ordinate format alternatives
Just to take this thread further off topic, Groundspeak appear to use a methodology (which is not actually a methodology) called Agile.
http://en.wikipedia.org/wiki/Agile_software_development
By their use of the terms sprint and scrum in various postings I'm pretty sure they use the Agile concept.
I presume from their recent movement to monthly releases, which is typical of an agile process, they moved from a standard waterfall approach.
In the web 2.0 world (I hate that term), 30-90 day releases in the way to go. What causes grief is a poor code base that requires extensive testing to ensure that other functionality doesn't break or get rolled back.
At GCA we have two primary developers, who have certain interests (and investment) in certain pieces of code. That means we can continue to rapidly develop new functionality and identify bugs easily.
Our codebase, while far from perfect is a mixture of OO and procedural code. Over time as we get time, we try to move it towards a more OO approach. Not strictly true objects, but functions work just as well. This means common functions can be changed easily and the impact ripples through everywhere that uses it. This is especially pertinent to thngs like kml and gpx generators. One piece of code that is used everywhere. Of course that means one bug ripples through the system.
The codebase at GC, again based on what has been posted in their forums, seems very adhoc and non-OO. This means you need to update multiple places to get the same functions correct in each different place.
It's obvious from some of their releases that they are slowly moving towards a more OO approach for their codebase which should allow less bugs and consistent functionality.
The functionality of GC and GCA is somewhat similar. The major difference is the language. GC is .net and SQLServer on IIS. GCA is php and MySQL on Apache. Even so, the functions we have are very similar.
In talking to someone at the Ballarat event today we go to talking about performance of the two sites. GCA has about 30,000 live caches in the database. GC has about 1,000,000. That's a 30 fold difference (give or take). Yet, we run in very different physical environment. GC has some 5 primary servers in a "round robin" fashion. GCA has 1. The difference in users unquantifiable. We certainly don't have the same numbers of concurrent users.
All in all, the two oragnisations are very different, with different needs and wants and capabilities. GCA can respond fast because we can. GC can't respond quite as fast because they have a different world to respond to.
http://en.wikipedia.org/wiki/Agile_software_development
By their use of the terms sprint and scrum in various postings I'm pretty sure they use the Agile concept.
I presume from their recent movement to monthly releases, which is typical of an agile process, they moved from a standard waterfall approach.
In the web 2.0 world (I hate that term), 30-90 day releases in the way to go. What causes grief is a poor code base that requires extensive testing to ensure that other functionality doesn't break or get rolled back.
At GCA we have two primary developers, who have certain interests (and investment) in certain pieces of code. That means we can continue to rapidly develop new functionality and identify bugs easily.
Our codebase, while far from perfect is a mixture of OO and procedural code. Over time as we get time, we try to move it towards a more OO approach. Not strictly true objects, but functions work just as well. This means common functions can be changed easily and the impact ripples through everywhere that uses it. This is especially pertinent to thngs like kml and gpx generators. One piece of code that is used everywhere. Of course that means one bug ripples through the system.
The codebase at GC, again based on what has been posted in their forums, seems very adhoc and non-OO. This means you need to update multiple places to get the same functions correct in each different place.
It's obvious from some of their releases that they are slowly moving towards a more OO approach for their codebase which should allow less bugs and consistent functionality.
The functionality of GC and GCA is somewhat similar. The major difference is the language. GC is .net and SQLServer on IIS. GCA is php and MySQL on Apache. Even so, the functions we have are very similar.
In talking to someone at the Ballarat event today we go to talking about performance of the two sites. GCA has about 30,000 live caches in the database. GC has about 1,000,000. That's a 30 fold difference (give or take). Yet, we run in very different physical environment. GC has some 5 primary servers in a "round robin" fashion. GCA has 1. The difference in users unquantifiable. We certainly don't have the same numbers of concurrent users.
All in all, the two oragnisations are very different, with different needs and wants and capabilities. GCA can respond fast because we can. GC can't respond quite as fast because they have a different world to respond to.
- kennythe1st
- Posts: 133
- Joined: 19 December 09 7:36 pm
- Location: nr Daylesford, VIC
- Contact:
Re: Suggestion: display o-ordinate format alternatives
I'll play brain dead for this response (my partner querying 'play'). Position is spot on thanks Craig. However the format would be more consistent with VicMap, MemoryMap and OziExplorer if in the format 55S 248095E 5884844NCraigRat wrote:I nominate this thread for the most bizzare brain hurting feature request thread EVER.
Kenny, can you check that the UTM position matches the proper format as far as location goes? It looks ok to me, but I have no idea if it is correct or not
I prefer the 55S 248095E 5884844N format firstly because it is easy to cut and paste to/from the 2 mapping softwares, secondly because I find it it is easier to relate to VicMaps and thirdly because it avoids an unnecessary 2 letters - over 27.75 years it makes time for one more cup of coffee.
WHY UTM?
Mainly because I use it in developing recreational maps that are based on VicMap data (Shape files). Being metre based also helps from time to time and that is where it comes in handy in geocaching. For example, it is difficult to get a good fix at one of my 10th Anniversary caches. Out in the open I get a great fix, pace into the cache and adjust my co-ords by that distance in that direction. And it is much easier to key in a two streams of numbers per co-ordinate than six.
I rest my case but I know the jury is stacked against me.
Kenny
- CraigRat
- 850 or more found!!!
- Posts: 7015
- Joined: 23 August 04 3:17 pm
- Twitter: CraigRat
- Facebook: http://facebook.com/CraigRat
- Location: Launceston, TAS
- Contact:
Re: Suggestion: display o-ordinate format alternatives
Changed!kennythe1st wrote:I prefer the 55S 248095E 5884844N format firstly because it is easy to cut and paste to/from the 2 mapping softwares, secondly because I find it it is easier to relate to VicMaps and thirdly because it avoids an unnecessary 2 letters - over 27.75 years it makes time for one more cup of coffee.
- kennythe1st
- Posts: 133
- Joined: 19 December 09 7:36 pm
- Location: nr Daylesford, VIC
- Contact:
Re: Suggestion: display o-ordinate format alternatives
So 'tis. That's sooo Agile CraigCraigRat wrote:Changed!kennythe1st wrote:I prefer the 55S 248095E 5884844N format firstly because it is easy to cut and paste to/from the 2 mapping softwares, secondly because I find it it is easier to relate to VicMaps and thirdly because it avoids an unnecessary 2 letters - over 27.75 years it makes time for one more cup of coffee.
btw after my previous post I was wondering why I have always used UTM and realised it probably came from my army days as a gun battery surveyor. That's going back a bit but I am fairly sure we were metric then - at 105mm, the guns certainly were.
Kenny
- GammaPiSigma
- 450 or more roots tripped over
- Posts: 227
- Joined: 23 May 04 7:46 pm
- Location: Campbelltown, NSW
Re: Suggestion: display o-ordinate format alternatives
You are not alone. A certain ex-cacher from my locale once told me that's how he worked out where caches were around Sydney way back in the early days.Papa Bear_Left wrote:We used to use UTM all the time in the Good Old Days(tm), i.e. in the days before GPSrs had maps on them.
We noticed that the Sydways street directory had numbers on the grid that were the last few digits of the UTM coords, meaning that we could get the coords of the next waypoint of a multi or a puzzle and find out where it was without going to an Internet cafe or back home to look it up on a mapping website or program...
Cheers,
Michael.
P.S. Sorry for the thread drift.
Re: Suggestion: display o-ordinate format alternatives
It seems it is safe to come back from Scouts now.
Well done!
There are circumstances in which I mix my coordinate formats (and even the datum) depending on which paper maps I have and what activities I am doing.
Well done!
There are circumstances in which I mix my coordinate formats (and even the datum) depending on which paper maps I have and what activities I am doing.
-
- 10000 or more caches found
- Posts: 151
- Joined: 03 May 03 12:56 pm
- Location: Christchurch, New Zealand
- Contact:
Re: Suggestion: display o-ordinate format alternatives
Correction - that is in fact dd mm.mmm - they are decimal minutes (mm.mmm). No seconds are harmed in the production of geocaching coordinatesWazzaAndWenches wrote:Why would anyone want to use that when the world revolves around dd mm.sss caching?