Work Location: Mancos, CO (see my wife's travel log).
Originally I had intended to add maps to show trip routes, and to integrate Google's new "directions" functionality. I found myself doing something that was a major irritation as a corporate software developer. I was rushing to add major new features in spite of the fact that there were bugs that needed to be fixed; small features that were needed to make the application easier to use; and code that needed to be redone to allow me to continue growing the application.
So, new plan: I will take the month of July to tidy up a bit before moving on to Big New Features. Heck, maybe I'll continue the cleanup into August. I have been accreting cruft for a year now.
When editing a Trip, clicking on a button to choose a location to replace the current one, or to set one before or after it, now also sets the current one as the Distance Origin. This makes it easier to find locations that are a specified distance from the current one.
A quotation mark in a location name prevented the map from displaying. Fixed.
Can now lock individual dates to prevent recomputation from changing them. This permits setting fixed-dates for selected events while still allowing the rest to automatically recompute.
For example, one might want to lock-in a starting date from the initial location, and lock-in an arrival date at the final destination. Then, it would be possible to freely add and remove destinations in between these two locations, and change stays and drive times, all without recomputation of in-between dates and times altering the starting and arrival dates.
A few more small fixes to make the application more useful or pleasant to use.
Change format: no longer one long column.
Publicly viewable trips are marked as such.
Can choose to see your own trips or other folks (but not both at the same time).
GPS Quality is now included in detail pages.
Clicking the email link on a location detail page now includes the park name as part of the address line.
Several false starts ... only thing useful is the start of a stylesheet for printing. Printed Location and Trip pages no longer waste space with menus.
No longer rely on Javascript "Are you sure?" dialog. An "are you sure" is now displayed in the edit page. This provides a safeguard even when Javascript is not turned on in a browser.
Removed 'Delete' button from trip details page. Now only shows up on the edit page.
When 'Delete' button is clicked, the edit page is redisplayed with an "are you sure" prompt and buttons to complete the deletion or cancel it. This is a bit safer than relying on a Javascript "are you sure" dialog that would not appear if Javascript were turned off in the browser.
Added a second login link: 'Login & Return'. This new link causes the page from which it was invoked to be displayed again after login. Very common action was to browse to a page I wanted to edit, then login so I can edit it, then have to renavigate back to the page I wanted to edit. This saves several steps.
Requesting details w/o supplying a location id redirects to the locations browse page. I kept doing this accidentally when diddling the url in the browser.
Entering an unknown city during creation of a new location now presents a menu of possible matches.
The location screen once again has a postal code field. The postal code is used to help figure out what city might be meant if the typed-in city does not exist in the validation database.
Refactored internals a bit to simplify and rationalize address validation and geo-coding.
Added test to prevent geo-coding on the full address to place the location at ridiculous distances from the city and state specified. Ocassionally Google geo-coding puts a location halfway across the continent from the specified city and state. Now if the geo-coded coordinates are more than 50 miles from the city/state/postalcode, we stick with the coordinates provided by our internal address validation.
Got rid of some of the server's deprecation warnings on startup.
Added check for valid toll free area code for the toll free phone number field. Area code must now be one of these: 800, 888, 877, 866.
Fixed placement of error messages for contact info fields so that only the area before the field with errors gets highlighted. Same for city/state/zip.
If one of the address lines contains "P.O. Box" (punctuation and whitespace stripped, uppercased), and the other does not, put the PO Box in address2 and the non-PO-Box text in address1. Address1 is used as street address for geo-coding purposes, and address2 for PO Box, suite, etc.
Fixed: In some cases if a postal code was not supplied, city was deemed unknown.
Added GPS coordinates sanity check. It is now an error to enter GPS coordinates that are more than 50 geographic miles from the city or postal code specified for the location.
When editing a location, entering an unknown city/state/postal combination produces a list of candidate cities. This list is now de-duplicated (i.e., all items in the list are unique).
When NOT logged in, you could browse other people's public trips. But if you logged in, you could not see other folks public trips. Now fixed: you can see other people's public trips whether you are logged in or not.
Bug Fix: The new GPS sanity checks compute a distance between the current coordinates of the location and the city/postal-code specified for it. If the same coordinates were used for both, and exception was thrown. This situation could happen when geo-coding of the location resulted in exactly the same data being used for the city and the default GPS of the location being edited.
When city, state/province, postal code, and country do not match or are unknown, a menu list of candidate cities is presented from which users may choose one.
These guesses are now presented more consistently. They had only been presented when a new location was created. They are now presented if these fields are changed at any time (i.e., the city, state/province, postal code, or country fields).
Guesses are now made from the most specific to the least specific until some predefined number of candidates is found or no more candidates can be generated. That is, all fields are used to find a match or candidates. If no match is found, or not enough candidates are found, then the postal code is used. If more matches are still needed, city and state are used. And so on.
These changes should help prevent getting stuck in a situation in which the address we get from some other source does not match locales known to our validation database, and we cannot guess what locales ARE known to the validation database.
Minor tweaks to Web Link section. Now displays source of weather report.
Bug Fix: Had been limiting GPS of a location to 50 miles or less from center of its postal code or state/province. This is way too small for some areas, such as Canada's Yukon Territory.