Cumulus Support

beteljuice wrote:You need to 'scrape' the MoonDay number or image from one of the many sites that provide that sort of thing

I did wonder why this wasn't the solution in the first place. It seemed rather perverse to me to be getting Cumulus to upload this 'moon day' number to a web site, to then scrape it off the web site to a desktop app, when the figure is already available on the web.

I'm also somewhat bemused by this repeated suggestion that it would all be much simpler if Cumulus had a <#moonday> web tag. If it's hard to arrive at this number in the first place, where am I expected to get it from?

beteljuice wrote:This is not good !

I do agree!

beteljuice wrote:I suspect the 'page scraper' would NOT see any image or text created by the JavaScript, and would only be able to see the js itself.

That was exactly my suspicion to start with. Hence my preferring a <#lunarday> webtag, as that would actually be able to work.

beteljuice wrote:You need to 'scrape' the MoonDay number or image from one of the many sites that provide that sort of thing through a server-side script (eg. php). Some sites allow it, other frown upon scrapers.

Lucky thing is, it's my site, and I'm being very lenient with myself

beteljuice wrote:If your server allows php, it would be better for you to get a freebie script that returns exactly what you want and scrape-your-own

Well yes, that's what I am doing so far.

beteljuice wrote:It's been interesting though

Yeah, there were even some interesting philosophical bits in there that kept on cropping up!

beteljuice wrote:BTW - Isn't a lunar month less than 30 days ...

generally about 29 and a bit maximum from most reports I've read so far. Can go as low as - ugh, senior moment, can't remember.

beteljuice wrote:... so all this code is ...... only any good for a 30 image selection

That's fine in this case.

I'm thinking I may have to scrap the idea and take out the images and replace them with one of a pine cone and another of seaweed, and then I could just pretend the whole Zambretti business does not exist either!

beteljuice wrote:BTW - Isn't a lunar month less than 30 days ...
... so all this code is ...... only any good for a 30 image selection

That is what I was trying to say, basing your images on the day of the lunation is not a good idea as the length of a lunation varies. What you have done is translate the 100% into a 'standard' 30 day range of images. My suggestion is to base the images on the percentage illumination in the first place!

steve wrote:

beteljuice wrote:You need to 'scrape' the MoonDay number or image from one of the many sites that provide that sort of thing

I did wonder why this wasn't the solution in the first place.

I've found lots of sites that tell you how you might calculate it, many that offer calendars and charts, some that want you to sign up for all sorts of doubtful things along the way of getting to the number. I've not yet seen one that just comes up with the number as a matter of routine. And while I don't mind scraping my own site, scraping that of another almost always ends up becoming broken as some will go to extraordinary lengths to dislike the practice.

steve wrote: It seemed rather perverse to me to be getting Cumulus to upload this 'moon day' number to a web site, to then scrape it off the web site to a desktop app, when the figure is already available on the web.

Samurize can use the plugin to scrape from the web, but can't scrape from the machine, so I was simply being practical and doing the only thing that actually worked, perverse or otherwise.

steve wrote:I'm also somewhat bemused by this repeated suggestion that it would all be much simpler if Cumulus had a <#moonday> web tag. If it's hard to arrive at this number in the first place, where am I expected to get it from?

I had this idea in my head that you might have it already to be drawing the moon image from Cumulus as you do. I had no idea you had no idea what the lunar day was, I guess I assumed you might need to know that to draw what you do, but I now suspect that has to be a bad assumption on my part.

Flying Eye wrote:I had this idea in my head that you might have it already to be drawing the moon image from Cumulus as you do. I had no idea you had no idea what the lunar day was, I guess I assumed you might need to know that to draw what you do, but I now suspect that has to be a bad assumption on my part.

The moon image which Cumulus provides is a third-party component; I put it on the form and it just works. I get the 'percent illuminated' figure from an astronomical functions library which doesn't have a function for lunar day.

mcrossley wrote:

beteljuice wrote:BTW - Isn't a lunar month less than 30 days ...
... so all this code is ...... only any good for a 30 image selection

That is what I was trying to say, basing your images on the day of the lunation is not a good idea as the length of a lunation varies. What you have done is translate the 100% into a 'standard' 30 day range of images. My suggestion is to base the images on the percentage illumination in the first place!

That is why I originally asked you how many images you required. Since I'd be the one getting them to exist, I'd have to render them, but I'd have to know how many to render otherwise there is no reasonable way to make it happen.

However it now seems this is not going to be possible at all, because there is a data disconnect which I had not foreseen, and which appears to be insurmountable. I guess this makes the whole thing academic by now.

Anyway, thanks one and all for trying.

steve wrote:

Flying Eye wrote:I had this idea in my head that you might have it already to be drawing the moon image from Cumulus as you do. I had no idea you had no idea what the lunar day was, I guess I assumed you might need to know that to draw what you do, but I now suspect that has to be a bad assumption on my part.

The moon image which Cumulus provides is a third-party component; I put it on the form and it just works. I get the 'percent illuminated' figure from an astronomical functions library which doesn't have a function for lunar day.

Ah, right, thanks for the clarification, I understand now.

When I was coding (many moons ago!), I used to have a book that I sought out and purchased. It dealt with making astronomical calculations of all sorts, first in theory then as a sample code for BBC Basic, and of course that worked enough to show the principal and then a stab at the practice in each case.

It was very good and happily at a very reasonable price indeed! I'm going to guess it's out of print today and I can't even recall the name of it or the author by now, let alone if it's still to be unpacked form the last house move or whether it was lost. I shall keep my eyes peeled in case I find something of use though. I'm petty sure this one would have been in the book though, as it would have been a pretty basic building block that some of the more challenging stuff would have used for some of the trickier calculations.

UPDATE: well, I'll be damned! http://www.amazon.co.uk/Astronomy-Perso ... 355&sr=1-2 Still there, and still reasonable!

Flying Eye wrote:That is why I originally asked you how many images you required. Since I'd be the one getting them to exist, I'd have to render them, but I'd have to know how many to render otherwise there is no reasonable way to make it happen.

Well that would be rather up to wouldn't it? Do you want the image to change for every 20% increment in illumination, or 10%, or 5%, or 1%!
When I did something like this I actually used the lunar selenic col-longitude (0-359 degrees) - because I was interested in the position of the terminator on the surface rather than the illuminated fraction - and created a pre-baked image for every 2 degrees - 180 images in all!

mcrossley wrote:

Flying Eye wrote:That is why I originally asked you how many images you required. Since I'd be the one getting them to exist, I'd have to render them, but I'd have to know how many to render otherwise there is no reasonable way to make it happen.

Well that would be rather up to wouldn't it? Do you want the image to change for every 20% increment in illumination, or 10%, or 5%, or 1%!
When I did something like this I actually used the lunar selenic col-longitude (0-359 degrees) - because I was interested in the position of the terminator on the surface rather than the illuminated fraction - and created a pre-baked image for every 2 degrees - 180 images in all!

Wow! That's a bit too much for me these days; I'm a bear of small brain, and as a consequence have to keep it simple and realistic for my given abilities, which is why I was happy with the 30 images!

I'm pretty sure I am not clever enough by a pretty large margin for that sort of approach. And there you were a few posts back being concerned about things getting slightly more complex. Well, that certainly appears to have happened for me! I had better try to find another way.

Thanks for the thought though.

I've added a <#MoonAge> web tag in build 1016. No guarantees as to how accurate it is, but it should be 'close enough'.

steve wrote:I've added a <#MoonAge> web tag in build 1016. No guarantees as to how accurate it is, but it should be 'close enough'.

How can I thank you enough?

I've got some backing up to do then I''ll install it and give it a try out!

You know you timed that rather well, to say the least; it's been a very discouraging week this week, nearly every little thing I tried to do involving the weather station has been taxing to the limit - until seeing this, this evening, I was seriously looking at what alternatives I might go with. Mostly it was about issues with the reliability and quality control of Fine Offset products. When the notification came in I was actually looking at and assessing wireless thermometers on Amazon! Yes, that close to going another simpler route!

Thanks once again Steve, it's quite remarkable that you were able to find a solution so quickly!

OK, so here is how it looks right now:



It seems to be tracking about right, I'll keep an eye on it as it all progresses. I've renumbered the images for FM on 14th, does that seem about right given what you came up with? Or would 15th perhaps be more sensible?

Either way, what a great outcome!

So, just the Zambretti thing to figure out now! I may have worked out a plan for that, but making it become reality is quite likely going to be a slightly longer haul!

Once both solutions seem to be working and settled down, I'll probably start modelling and rendering.

This tag is greatly appreciated!

Yes, I think 14 will probably hit the day of the full moon.

It's just a library function that I've found, I don't know how it works.

OK, 14th is fine here, so we'll see what happens, looks like it'll be fine.

Given you don't know how it works, what you produced is all the more astonishing!

The power in those webtags is great, even using the ancient technology in Samurize I've now got a handy visual output for the weather station, and since I've now got it using a text file directly to disk from Cumulus and directly from disk via a bit of lucky "trying it on" in Samurize, well, once that happened it all became remarkably responsive! So, while it's technically still scraping, it's doing it from the hard drive instead of the web, and the lack of lag is now pretty impressive, the updates are now very crisp indeed.

Thank you very much indeed!