Sandaysoft

probably something missing from php.Even with debug=y i see a blank page.Any suggestions?

Ken, before I forget...

I have just discovered a W3C error in the 'include-style-switcher.php' script - looking back at old version of the script, the W3C error has been in the code 'undetected' since 2008 - I really do not know why it is showing now!

This is what is being displayed on the W3C Markup Validation Service page:
The error is either on line 190 or on line 193 (depending on the script file) and is part of the following lines of code:

if($use_onchange_submit == true) {
$string .= '<label for="CSSwidescreenOn">On</label> <input type="radio" id="CSSwidescreenOn" name="CSSwidescreen" value="1" '.$CSSwscreenOnChecked.' onchange="this.form.submit();" />
| <label for="CSSwidescreenOff">Off</label> <input type="radio" id="CSSwidescreen" id="CSSwidescreenOff" name="CSSwidescreen" value="0" '.$CSSwscreenOffChecked.' onchange="this.form.submit();" />';
}

To correct the W3C error, one needs to do a search for id="CSSwidescreen" and simply be deleted it from the line - the name="CSSwidescreen" is there for that purpose...

Well, that is a surprise. I'd been running the templates through W3C validation cleanly for many years, and it never pointed out that duplicate id= issue before (and didn't this morning when I checked it again). But.. you're correct, it does have two id= tags. I'll update the distributions later today.

Thanks!

It would be great if your updated ec-radar code to not use $_SERVER['DOCUMENT_ROOT'] could be incorporated too

Best regards,
Ken

Ken, I have been looking at both 'ec-radar.php' and 'GR3-radar-inc.php' to find out what modifications I made to both/either scripts so they are not forced to use a directory just off the root... I will confirm later on today or tomorrow.

As I think I mentioned/writing before, an Apache server installed on a Windows base computer does not produce the same information/results (path) for '$_SERVER['DOCUMENT_ROOT']' as it does under Linux. On my computer (Windows 7), the Apache root directory is named 'htdocs' - when using a browser, this is the topmost directory one can access. As I have been doing for years, all of my web installations are located in directories one level below (under) the root - the only files I have in that root directory are an 'index.html' and a hidden '.htaccess'. Then, there are a number of sub-root directories (one level below the root) which contain the files required for a particular web installation, such as, for example, the 'cumulus' sub-directory containing all the file needed to produce my 'Tzouhalem-Maple Bay - Cumulus Weather PHP' web pages, or the 'canada' sub-directory containing all the file needed to produce my 'Canada Multilingual Website with PHP & AJAX' web pages.

Correct me if my thinking is/was wrong, it is my understanding that the 'radar' directory should be located on the same level as both my 'cumulus' and 'canada' sub-directories, that is one level below the root directory. As it is now, I do not have any directory named 'radar' at the same level as both my 'cumulus' and 'canada' directories are located. I do have a few directories named 'radar' one level below my 'cumulus' and 'canada' directories, for example at the same level as the 'ajax-images' directory (inside the 'canada' directory).

So, with this 'weak' explanation, am I right in thinking that my 'radar' directories are not at root level?

I think I understand, and if so, then yes, your radar directories are not at the {root} level.

$_SERVER['DOCUMENT_ROOT'] . '/radar' would be at the document root.

What I'd found with both the ec-radar and gr3-radar scripts was an inconsistency in PHP implementations across the Linux and Windows platforms on the PHP function realpath(). According to the PHP docs, realpath() can take a messed up file path (with extra / and even \ ) and make it 'clean', so the code tried using that to make sure the file-path and URL-path were consistent. Windows IIS/PHP returned an unhelpful 'null' for realpath() while pretty much all Linux (and even Windows) Apache/PHP would do the right thing.

Here's the code in question and I'm open to suggestions on how to do this better ec-radar.php has while GR3-radar-inc.php has and it's that realpath() that screws up on Windows systems.
For the GR3-radar-inc.php, it's important that there is a 1:1 correspondence between the filesystem path and the URL path exist (which is not necessarily the case with IIS servers).

Best regards,
Ken

hi Ken
I have cumulus set yo use davis pressure tend trend is -0.021 cumulus is showing Falling Rapidly
ajak dashboard reads Falling Slowly
what needs changed ?
Beau

Beau,
The comparison is done in hPa/mb and (-0.021) inches of mercury = -0.71106 hectopascals

and < -0.7 hPa triggers this

if ((btrnd < -0.7) && (btrnd > -2.0)) { return(langBaroTrend[3]); }

var langBaroTrend = new Array (
"Steady", "Rising Slowly", "Rising Rapidly", "Falling Slowly", "Falling Rapidly");

and langBaroTrend[3] = 'Falling Slowly'

which fits with the definition of 'Slowly' for falling (between -0.7hPa and -2.0 hPa/hour)

Hi Ken
How wood I fix the 2 lines under Season Total: so it just 1 line
Thanks Beau

Ken, I will get back to you with this root and realpath stuff...

Ken is there something that can be done about that mix-match of information getting process by the code. Let me explain.

I have modified the 'ajax_get_barotrend' in my script to use the MET/BoM's 9 pressure trend conditions - I have even added 2 additional conditions to mine because I really really dislike being told (displayed) that the trend is steady when it is not at zero (and is showing a small trend variation when hovering over the arrow). In the canadian template set (primarily metric), I have no problem whatsoever with this new 'ajax_get_baroTrendMET' function and the 'ajax_genarrow' function. But, with the american templates (primarily imperial), that is all together another 'ball game'... The new 'ajax_get_baroTrendMET' work as expected, but the 'ajax_genarrow' reports no trend change (no arrow) when I know there is a variation in the trend. I understand it is because two different standards (ie: imperial and metric) are being used to produce the two results.

Here is what I am getting at... What if the internal operations of the scripts (all of them) were to be standardized to metric (which is, after all, the most used standard) - the weather data inputed into the script could be either imperial or metric - inside the script, the data would be processed directly (if it is metric) or converted to metric (if it is imperial) before being processed - the resulting weather data outputed out of the script could then be displayed in metric or converted to imperial. I know that will involve more processing within the code (some of your scripts are already doing that type of processing now) and possibly some lost of precision (not necessarily if 3-5 decimals are used), but that would also mean a consistency within the processed data and the resulted data:
- input imperial or metric;
- process in metric;
- output imperial or metric;

I am still working on streamlining the canadian scripts and templates (and, obviously, making them more and more incompatible with future releases of your template sets - I cannot accept the fact that some scripts and templates have not been updated in 2-3 years ... well, that is me... ) - one of my many modifications was to make the canadian scripts/templates primarily metric with the option of accepting imperial data - the data within the scripts/templates is being processed in metric (converted from imperial to metric when required) - the processed data is then displayed in metric or converted to imperial before being displayed. The few scripts that I have modified are working fine. I am still thinking of using the knot (I know it is an old measurement, but, yet, it is still being used by many people) as the standard for the wind speed processing, converting from both imperial and metric to the knot standard.

I know that people might/will disagree with my thinking, that my time could/should be better spent doing something else, that there is no need to 're-invent the wheel' but, hey, this is a learning experience/experiment...

The double lines are produced by the PHP code between lines 601 and 620 in the 'ajax-dashboard.php' script.

So that you understand what is being done in that part of the script...

The code between those lines is first checking for the number of days without rain (the '$dayswithnorain' variable) - Ken uses the Cumulus tag 'LastRainTipISO' which, on my system, contains the value '2011-02-09 10:26'.

The next part of the code checks for the number of days with rain (the '$dayswithrain' variable) - unfortunately, that variable has not been defined in either 'CUtags.txt/php' or 'CU-defs.php' scripts.

So, what is happening is that part of the code is true (ie: on my system, the number of days without rain variable containing the value 1) but the other part of the code is false (ie: on my system, the number of days with rain variable being empty - not only does it contain nothing, it does not even exist).

A request to open (create) a new row and column (ie: the <tr><td> elements - with a border underneath the column element) is being made in the first part of the code, but no data can be displayed and then a request to close the new row and column (ie: the </tr></td> elements) is being made. Thus producing a new row/column with a border at the bottom but with no data to be displayed.

To correct the display of the double line, one temporary solution would be to comment out everything between lines 604 and 620 inclusively.

Well, I thought you might make some comments in time for the relatively short beta testing, but that time has passed. Now you seem to be into reworking a lot of the code to match your own aesthetics for method and construction. I'm not sure how ultimately useful that will be to others, but if you're enjoying the exercise, then by all means, press on.

Regarding the idea to uniformly convert the station's chosen UOM set to metric, and then possibly back again I see as a possibly large waste of computing resources doing unnecessary conversions. When a person sets up their weather station, they generally adopt the units-of-measure in use in their country, and the weather station duitifully reports in those UOM. If the person publishes a weather website, it is likely to be in the same UOM as the station is using, so there's no need to convert things for display in PHP. Yes, in the AJAX scripts, conversions are routinely done as the various software have their own setup for UOM in the realtime files. For example, Weather-Display uses C,kts,hPa,mm for clientraw.txt,
VWS uses F,mph,inHg,in, Cumulus uses whatever the station units are set to (and includes the UOM in the realtime.txt).
So, no, I don't think a universal conversion to metric (C,km/h,hPa,mm) and maybe back is a useful addition to the template set.. it just causes unneeded overhead in the PHP presentation.

Regarding the fine structure of the wording for barometric pressure trend, the various weather software have their own english terms and generally use Steady, Rising, Falling (with optional modifiers Slowly or Rapidly). I couldn't find any reference available on the internet about the EC's definition of 8 possible text phrases with boundary range definitions. Do you have a link to share with that data?

As for "streamlining the Canadian scripts and templates", you may be doing that for your own amusement if you do indeed make them incompatible with the other template sets. In order to minimize the disparate number of parts to maintain, many of the parts are used for the same functions across the Canada, World and USA Base sets. Unless your changes would allow such cross-Base usage, I'd need to decline to use them for the same reasons discussed in prior posts.

I know (from your postings) that you really like dissecting and reassembling stuff to match your aesthetics, but that may not always be useful or helpful to others. I am a strong believer in the Keep-It-Simple approach when crafting programming projects for reuse by others, and since the templates are a macro-construction of distributed standalone-parts, that architecture is what I intend to preserve (for my own sanity in future maintenance efforts).

I completely agree -- if I write something that I expect others to use/plagerise/dissect I want to keep in nice and simple. I can personally write much tighter code for my own needs but with so many skill levels on the forum (and the web in general) I think it is much better to do our best to keep it simple; not always easy as a project grows arms and legs but we must try!

_________________
David
Contact Me

Hi ken i have been looking around an try learn what is this code used for

thanks Beau

Hi Beau,
Since Cumulus doesn't return a tag with the number of days since last rain (WD tag $dayswithnorain), but Cumulus does have a date/time of last tip of the rain gauge, we can use that code to calculate the number of days.

So:


checks to see we've got a valid ISO date in the field, and if so:


assigns that date/time to the WD variable $dateoflastrainalways (which the dashboard doesn't use, but someone else may find a use for it)


is the bulk of the calculation
1) take the first 10 characters of the ISO-Date (YYYY-MM-DD)
2) feed it to strtotime() to generate a Unix timestamp (number of seconds since Jan 1, 1970)
3) subtract that from current Unix timestamp
4) divide that remainder by 86400 (number of seconds per day)
5) take the interger value of that, and put it in $dayswithnorain

The CU-defs.php file contains the 'bridge code' to assign Cumulus data from the $WX[] array into WD named variables for use in the ajax-dashboard and ajax-gizmo. When a weather software doesn't provide a direct tag that can be used for the WD variable, then we can derive it from the other variables that are provided (or generate them from internal functions such as done for Beaufort, astronomy dates, etc.

Hope this helps...
Best regards,
Ken

Hi ken
I can i get $dayswithnorain on the dashboard?
but look ant my image a few post back an there no number of day without rain
an if you look her it show month but no number
also not here http://www.n9mfk.com/cu/
any idea beau