Good day!
Has anyone noticed that kweather applet doesn't update weather data anymore since some weeks?
More exactly, weather data for "Berlin-Tegel". Kweather comes obviously with a database from which you can choose your location (airport). For Berlin that used to be "Berlin-Tegel" and "Berlin-Tempelhof" (which is dead since 2009). I checked with "Braunschweig" and it shows actual current data.
Last time that happened the URL for retrieving the data had changed on the part of the server (noaa.gov). This URL was hardcoded in the source of the software and one of the developers had to change it (Tim did that) and it worked again since.
The National Oceanic and Atmospheric Administration of the U.S. Department of Commerce offers a lot of services on nws.noaa.gov where the local weather data used to be served as single html pages which were named according to their respective ICAO-Codes (airport IDs).
I suspect they again changed something, but I couldn't find anything relevant on their homepage in a couple of minutes.
"QCLCD ASCII Files are no longer available. Please use the Global-Hourly File Access link above."
I don't know what "QCLCD" means. I'm only guessing here anyway.
Maybe only kweather's database of available airport weather stations needs to be updated…
Kind regards, Stefan
On Wednesday 06 January 2021 05:12:56 Stefan Krusche via tde-users wrote:
Good day!
Has anyone noticed that kweather applet doesn't update weather data anymore since some weeks?
More exactly, weather data for "Berlin-Tegel". Kweather comes obviously with a database from which you can choose your location (airport). For Berlin that used to be "Berlin-Tegel" and "Berlin-Tempelhof" (which is dead since 2009). I checked with "Braunschweig" and it shows actual current data.
Last time that happened the URL for retrieving the data had changed on the part of the server (noaa.gov). This URL was hardcoded in the source of the software and one of the developers had to change it (Tim did that) and it worked again since.
The National Oceanic and Atmospheric Administration of the U.S. Department of Commerce offers a lot of services on nws.noaa.gov where the local weather data used to be served as single html pages which were named according to their respective ICAO-Codes (airport IDs).
I suspect they again changed something, but I couldn't find anything relevant on their homepage in a couple of minutes.
"QCLCD ASCII Files are no longer available. Please use the Global-Hourly File Access link above."
I don't know what "QCLCD" means. I'm only guessing here anyway.
Maybe only kweather's database of available airport weather stations needs to be updated…
I know this is zip help, but I had a similar problem 6 months back, and a phone call to the airport in question got it fixed the next week. Nobody there was aware it had stopped working. I'm using the weather pluggin for gkrellm, which uses that same data src system, in this case KCKB. They may not even be aware its not working at your site.
This is not a high bandwidth system so give it 30+ minutes to update after you set a new ICAO id.
Kind regards, Stefan ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinity desktop.org
Cheers, Gene Heskett
Am Mittwoch, 6. Januar 2021 schrieb Gene Heskett via tde-users:
I know this is zip help, but I had a similar problem 6 months back,
/^^^^^^^^ What is that ^ ? :-)
and a phone call to the airport in question got it fixed the next week. Nobody there was aware it had stopped working. I'm using the weather pluggin for gkrellm, which uses that same data src system, in this case KCKB. They may not even be aware its not working at your site.
Wait a minute, yeah, they recently shut down Berlin-Tegel Airport which I haven't noticed even though I live here. That must be the reason why NOAA doesn't have any actual weather data of that station anymore.
By the time they switched off the weather station of airport Berlin-Tempelhof, or NOAA stopped retrieving data off it because Tempelhof airport had been shut down, no more updates happened. But the data of 3th July 2009, the latest that were updated, are still available when kweather points to that station. NOAA still has the html page with that latest data for Berlin-Tempelhof on their server. I looked at it by the time. It's just a directory with hundreds of files with names like "EDDI.html" or, in your case, "KCKB.html".
Still, I get data for Berlin-Tegel shown from 9th Nov 2020, which is the latest update I got. So then the EDDT.html page for Tegel must still be there, but isn't updated anymore, I guess.
The problem therefore lies in kweather itself. It only offers a list with (only) less than 30 airport weather stations across Germany, two of which are Berlin-Tegel and Berlin-Tempelhof. Both have been shut down and NOAA doesn't get current weather data for those no more.
Meaning kweather needs to be updated. There is a new airport Berlin-Schöneberg (BER) which probably has its weather data represented by NOAA as EDDB.html (not checked). But one can not configure kweather to use that…
In .trinity/share/config/KWeatherServicerc there's only one entry. I added "EDDB" manually to try to make kweather show that but it doesn't.
[WEATHERSTATIONS] stations=EDDB,EDDI,EDDT,EDVE
This entry presumably tells kweather which of the stations out of its data base to show to choose from but not which to actually use.
Thanks for the hint, Gene.
Kind regards, Stefan
On Wednesday 06 January 2021 06:14:45 am Stefan Krusche via tde-users wrote:
Am Mittwoch, 6. Januar 2021 schrieb Gene Heskett via tde-users:
I know this is zip help, but I had a similar problem 6 months back,
/^^^^^^^^What is that ^ ? :-)
zip, nada, nothing
"zip help" means roughly "doesn't help at all."
"zip all" is another English (US?) derivitive roughtly equals "nothing."
HTH, Michael
Am Mittwoch, 6. Januar 2021 schrieb Michael via tde-users:
On Wednesday 06 January 2021 06:14:45 am Stefan Krusche via tde-users
wrote:
Am Mittwoch, 6. Januar 2021 schrieb Gene Heskett via tde-users:
I know this is zip help, but I had a similar problem 6 months back,
/^^^^^^^^What is that ^ ? :-)
zip, nada, nothing
"zip help" means roughly "doesn't help at all."
"zip all" is another English (US?) derivitive roughtly equals "nothing."
Thanks! Stefan
On Wednesday 06 January 2021 11:54:26 Stefan Krusche via tde-users wrote:
Am Mittwoch, 6. Januar 2021 schrieb Michael via tde-users:
On Wednesday 06 January 2021 06:14:45 am Stefan Krusche via tde-users
wrote:
Am Mittwoch, 6. Januar 2021 schrieb Gene Heskett via tde-users:
I know this is zip help, but I had a similar problem 6 months back,
/^^^^^^^^What is that ^ ? :-)
zip, nada, nothing
"zip help" means roughly "doesn't help at all."
"zip all" is another English (US?) derivitive roughtly equals "nothing."
And I can see from the echo's that I should have typed "zero" or "no", the slang language does not translate well. My apologies.
Thanks! Stefan ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinity desktop.org
Cheers, Gene Heskett
Am Donnerstag, 7. Januar 2021 schrieb Gene Heskett via tde-users:
On Wednesday 06 January 2021 11:54:26 Stefan Krusche via tde-users
wrote:
Am Mittwoch, 6. Januar 2021 schrieb Michael via tde-users:
On Wednesday 06 January 2021 06:14:45 am Stefan Krusche via tde-users
wrote:
Am Mittwoch, 6. Januar 2021 schrieb Gene Heskett via tde-users:
I know this is zip help, but I had a similar problem 6 months back,
/^^^^^^^^What is that ^ ? :-)
zip, nada, nothing
"zip help" means roughly "doesn't help at all."
"zip all" is another English (US?) derivitive roughtly equals "nothing."
And I can see from the echo's that I should have typed "zero" or "no", the slang language does not translate well. My apologies.
That's all right, Gene, I gladly educate myself.
Cheers, Stefan
On Thursday 07 January 2021 04:04:29 Stefan Krusche via tde-users wrote:
Am Donnerstag, 7. Januar 2021 schrieb Gene Heskett via tde-users:
On Wednesday 06 January 2021 11:54:26 Stefan Krusche via tde-users
wrote:
Am Mittwoch, 6. Januar 2021 schrieb Michael via tde-users:
On Wednesday 06 January 2021 06:14:45 am Stefan Krusche via tde-users
wrote:
Am Mittwoch, 6. Januar 2021 schrieb Gene Heskett via tde-users:
I know this is zip help, but I had a similar problem 6 months back,
/^^^^^^^^What is that ^ ? :-)
zip, nada, nothing
"zip help" means roughly "doesn't help at all."
"zip all" is another English (US?) derivitive roughtly equals "nothing."
And I can see from the echo's that I should have typed "zero" or "no", the slang language does not translate well. My apologies.
That's all right, Gene, I gladly educate myself.
I do too but English is my first and only language since I have only a grammer school official education. My electronics education since then is entirely self taught and extends all the way into relativity.
Its too darned easy to forget that many on this list, or any of them for that matter, do not speak/write English as a first language. And what I might think is cute or funny, may not be understood as such by folks whose first language is not English. I'll try to do better.
But old habits are hard to break, when you're already 86.
Take care and stay well Stefan.
Cheers, Gene Heskett
Am Mittwoch, 6. Januar 2021 schrieb Stefan Krusche via tde-users:
In .trinity/share/config/KWeatherServicerc there's only one entry. I added "EDDB" manually to try to make kweather show that but it doesn't.
Of course, this is wrong as you already can see below.
[WEATHERSTATIONS] stations=EDDB,EDDI,EDDT,EDVE
This entry presumably tells kweather which of the stations out of its data base to show to choose from but not which to actually use.
It tells KWeatherService for which station weather data are to be retrieved. These are listed in the config dialog window of weather_applet as "Chosen stations".
Stefan
Am Mittwoch, 6. Januar 2021 schrieb Stefan Krusche via tde-users:
Good day!
Has anyone noticed that kweather applet doesn't update weather data anymore since some weeks?
More exactly, weather data for "Berlin-Tegel".
That's alright. Tegel has been shut down recently. I didn't know.
Maybe only kweather's database of available airport weather stations needs to be updated…
I had a look into it…
$ grep Berlin /opt/trinity/share/apps/kweatherservice/stations.dat EDDB;10;385;Berlin-Schoenefeld;;Germany;6;52-23N;013-31E;52-23N;013-31E;47;50;P EDDI;10;384;Berlin-Tempelhof;;Germany;6;52-28N;013-24E;52-29N;013-25E;50;49;P EDDT;10;382;Berlin-Tegel;;Germany;6;52-34N;013-19E;;;37;37; KBML;72;616;Berlin, Berlin Municipal Airport;NH;United States;4;44-34-34N;071-10-43W;44-34-41N;071-10-49W;353;345;
Now the question is: why does Berlin-Schönefeld not show up in the list which kweather offers to choose stations from?
BTW, is there any documentation of the format of this file? Is it also retrieved from noaa.gov? Or created dynamically?
Kind regards, Stefan
Stefan Krusche via tde-users wrote:
I had a look into it…
$ grep Berlin /opt/trinity/share/apps/kweatherservice/stations.dat
EDDB;10;385;Berlin-Schoenefeld;;Germany;6;52-23N;013-31E;52-23N;013-31E;47;50;P
EDDI;10;384;Berlin-Tempelhof;;Germany;6;52-28N;013-24E;52-29N;013-25E;50;49;P
EDDT;10;382;Berlin-Tegel;;Germany;6;52-34N;013-19E;;;37;37; KBML;72;616;Berlin, Berlin Municipal Airport;NH;United States;4;44-34-34N;071-10-43W;44-34-41N;071-10-49W;353;345;
Now the question is: why does Berlin-Schönefeld not show up in the list which kweather offers to choose stations from?
BTW, is there any documentation of the format of this file? Is it also retrieved from noaa.gov? Or created dynamically?
Better look into the code. The code uses
https://tgftp.nws.noaa.gov/data/observations/metar/stations/
and whatever your mapping is - so it might be we need update for a mapping for Berlin if the DB @noaa.gov was updated.
I have no idea what corresponds to Berlin-Schoenefeld. Is Berlin-Schoenefeld the new airport there? I heard lately in the news they managed to finish and open it, but not exactly sure which is the new one.
and may be we have to check the date of the data and display a warning if it is not recent enough.
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Wed, 06 Jan 2021 20:52:13 +0100 deloptes deloptes@gmail.com wrote:
Stefan Krusche via tde-users wrote:
I had a look into it…
$ grep Berlin /opt/trinity/share/apps/kweatherservice/stations.dat
EDDB;10;385;Berlin-Schoenefeld;;Germany;6;52-23N;013-31E;52-23N;013-31E;47;50;P
EDDI;10;384;Berlin-Tempelhof;;Germany;6;52-28N;013-24E;52-29N;013-25E;50;49;P
EDDT;10;382;Berlin-Tegel;;Germany;6;52-34N;013-19E;;;37;37; KBML;72;616;Berlin, Berlin Municipal Airport;NH;United States;4;44-34-34N;071-10-43W;44-34-41N;071-10-49W;353;345;
Now the question is: why does Berlin-Schönefeld not show up in the list which kweather offers to choose stations from?
BTW, is there any documentation of the format of this file? Is it also retrieved from noaa.gov? Or created dynamically?
Better look into the code. The code uses
https://tgftp.nws.noaa.gov/data/observations/metar/stations/
and whatever your mapping is - so it might be we need update for a mapping for Berlin if the DB @noaa.gov was updated.
I have no idea what corresponds to Berlin-Schoenefeld. Is Berlin-Schoenefeld the new airport there? I heard lately in the news they managed to finish and open it, but not exactly sure which is the new one.
and may be we have to check the date of the data and display a warning if it is not recent enough.
A quick check of Wikipedia shows that Berlin Schönefeld is now part of Berlin Brandenburg Airport (the "new airport"), which has inherited Schönefeld's ICAO code but has a different IATA code.
The first element of the lines in the stations.dat file is the airport or weather station ICAO code, second and third seem to be the WMO ID code, fourth is city, fifth is US state (if the location is in the US), sixth is country, seventh I'm not sure of (possibly a numeric code for "continent" or similar), 8-11 are location (latitude and longitude), 12-13 are probably elevation (min-max? above sea level, in meters), and I'm not sure about the trailing slot that sometimes has a P in it (it may have something to do with whether or not the station is permanently manned, but not all countries seem to use it). The file is stored verbatim in git, so it isn't being created programmatically and might easily be out-of-date.
The important identifiers are probably the first three slots. Since Schönefeld and Brandenburg both have ICAO code EDDB, it's possible that it's the WMO code that needs to be changed from 10385 to whatever Brandenburg's been issued, if it's different. Or it may just be that the system is confused by the existence of what are technically two different entities using EDDB as ICAO code—I don't think those codes are usually reissued.
E. Liddell
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
E. Liddell wrote:
A quick check of Wikipedia shows that Berlin Schönefeld is now part of Berlin Brandenburg Airport (the "new airport"), which has inherited Schönefeld's ICAO code but has a different IATA code.
The first element of the lines in the stations.dat file is the airport or weather station ICAO code, second and third seem to be the WMO ID code, fourth is city, fifth is US state (if the location is in the US), sixth is country, seventh I'm not sure of (possibly a numeric code for "continent" or similar), 8-11 are location (latitude and longitude), 12-13 are probably elevation (min-max? above sea level, in meters), and I'm not sure about the trailing slot that sometimes has a P in it (it may have something to do with whether or not the station is permanently manned, but not all countries seem to use it). The file is stored verbatim in git, so it isn't being created programmatically and might easily be out-of-date
Am Mittwoch, 6. Januar 2021 schrieb E. Liddell via tde-users:
On Wed, 06 Jan 2021 20:52:13 +0100
deloptes deloptes@gmail.com wrote:
Stefan Krusche via tde-users wrote: I have no idea what corresponds to Berlin-Schoenefeld. Is Berlin-Schoenefeld the new airport there? I heard lately in the news they managed to finish and open it, but not exactly sure which is the new one.
and may be we have to check the date of the data and display a warning if it is not recent enough.
A quick check of Wikipedia shows that Berlin Schönefeld is now part of Berlin Brandenburg Airport (the "new airport"), which has inherited Schönefeld's ICAO code but has a different IATA code.
That's right. It is the same, enhanced and modernized airport.
The first element of the lines in the stations.dat file is the airport or weather station ICAO code, second and third seem to be the WMO ID code, fourth is city, fifth is US state (if the location is in the US), sixth is country, seventh I'm not sure of (possibly a numeric code for "continent" or similar), 8-11 are location (latitude and longitude), 12-13 are probably elevation (min-max? above sea level, in meters), and I'm not sure about the trailing slot that sometimes has a P in it (it may have something to do with whether or not the station is permanently manned, but not all countries seem to use it). The file is stored verbatim in git, so it isn't being created programmatically and might easily be out-of-date.
Great. Thank you for the input.
I think only the first field is the relevant identifier because the source of data is hosted on noaa.gov in html files which identify with just that ICAO code (e.g.: "EDDB.html"). I checked that a couple of years ago.
Also, in stations.dat there are many entries which only have "--;---;" in field two and three. And that doesn't seem to be the reason that many entries are not shown in the GUI dialog of kweather because most of those have these WMO IDs. (For the reader's convenience, it's: World Meteorological Organization).
The important identifiers are probably the first three slots. Since Schönefeld and Brandenburg both have ICAO code EDDB, it's possible that it's the WMO code that needs to be changed from 10385 to whatever Brandenburg's been issued, if it's different.
I think the entry for Berlin-Schönefeld is good as it is. It works after I applied deloptes' idea to edit
.trinity/share/config/weather_panelappletrc
which contains the variable which instructs kweather to show the data reported of that particular weather station.
Cheers, Stefan
On Wed, 06 Jan 2021 20:52:13 +0100 deloptes deloptes@gmail.com wrote:
Also, deloptes, you're still posting to the old list.
E. Liddell
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
E. Liddell wrote:
Also, deloptes, you're still posting to the old list.
Yes, sorry - still on the todo list :/ It looks so complicated ... I have to read again what Slavek wrote and see how I can do this without loosing much time and the ability to read/post. I use knode BTW. I was thinking I have done it, but it seems I've not ... may be I had to unsubscribe the old list ... we'll see
is it a big problem? (you can answer also in private)
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thu, 07 Jan 2021 01:40:06 +0100 deloptes deloptes@gmail.com wrote:
E. Liddell wrote:
Also, deloptes, you're still posting to the old list.
Yes, sorry - still on the todo list :/ It looks so complicated ... I have to read again what Slavek wrote and see how I can do this without loosing much time and the ability to read/post. I use knode BTW. I was thinking I have done it, but it seems I've not ... may be I had to unsubscribe the old list ... we'll see
is it a big problem? (you can answer also in private)
Not a *big* problem, but I don't know if people subscribed only to the new list are able to see your messages. You shouldn't have to unsubscribe from the old list to register with the new (since I get mail from both) unless your mail setup is very strange.
(Mail from the old list is also a minor persistent irritant for me personally, as, for historical reasons, I have *two* addresses subscribed to the old list and so get duplicate mail from it. No one still on the old list = no duplicate mail for me to deal with. That's what keeps drawing the origin of your messages to my attention.)
E. Liddell
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thursday 07 of January 2021 23:26:41 E. Liddell via tde-users wrote:
On Thu, 07 Jan 2021 01:40:06 +0100
deloptes deloptes@gmail.com wrote:
E. Liddell wrote:
Also, deloptes, you're still posting to the old list.
Yes, sorry - still on the todo list :/ It looks so complicated ... I have to read again what Slavek wrote and see how I can do this without loosing much time and the ability to read/post. I use knode BTW. I was thinking I have done it, but it seems I've not ... may be I had to unsubscribe the old list ... we'll see
is it a big problem? (you can answer also in private)
Not a *big* problem, but I don't know if people subscribed only to the new list are able to see your messages. You shouldn't have to unsubscribe from the old list to register with the new (since I get mail from both) unless your mail setup is very strange.
(Mail from the old list is also a minor persistent irritant for me personally, as, for historical reasons, I have *two* addresses subscribed to the old list and so get duplicate mail from it. No one still on the old list = no duplicate mail for me to deal with. That's what keeps drawing the origin of your messages to my attention.)
E. Liddell ____________________________________________________
The migration agent is still left active for forwarding posts from the old ML to the new one. But not back from the new ML to the old. So when someone (by mistake) sends a post to an old ML, everyone gets it. But the answers will remain only in the new ML. We left that because Tim hasn't stopped the old ML yet.
Cheers
E. Liddell wrote:
Not a *big* problem, but I don't know if people subscribed only to the new list are able to see your messages. You shouldn't have to unsubscribe from the old list to register with the new (since I get mail from both) unless your mail setup is very strange.
(Mail from the old list is also a minor persistent irritant for me personally, as, for historical reasons, I have *two* addresses subscribed to the old list and so get duplicate mail from it. No one still on the old list = no duplicate mail for me to deal with. That's what keeps drawing the origin of your messages to my attention.)
But I am just using the list from gmane. I am sure I subscribed to the new one. I have no idea what I have to do next. When this was announced I was under pressure in a project and couldn't follow up properly. I have on the todo to read again what Slavek said about subscribe/unsubscribe. Interestingly I do not see any new list in gmane to subscribe (but I remember Slavek set it up with gmane) Honestly I am waiting to get into the mood for solving it myself Sometimes it takes time though :)
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 08 of January 2021 01:38:42 deloptes via tde-users wrote:
E. Liddell wrote:
Not a *big* problem, but I don't know if people subscribed only to the new list are able to see your messages. You shouldn't have to unsubscribe from the old list to register with the new (since I get mail from both) unless your mail setup is very strange.
(Mail from the old list is also a minor persistent irritant for me personally, as, for historical reasons, I have *two* addresses subscribed to the old list and so get duplicate mail from it. No one still on the old list = no duplicate mail for me to deal with. That's what keeps drawing the origin of your messages to my attention.)
But I am just using the list from gmane. I am sure I subscribed to the new one. I have no idea what I have to do next. When this was announced I was under pressure in a project and couldn't follow up properly. I have on the todo to read again what Slavek said about subscribe/unsubscribe. Interestingly I do not see any new list in gmane to subscribe (but I remember Slavek set it up with gmane) Honestly I am waiting to get into the mood for solving it myself Sometimes it takes time though :)
This is done so that I did update the information on GMane, so under the original news names there should work a new ML. How do you answer? Through GMake or directly by smtp to ML?
Cheers
On Friday 08 of January 2021 02:59:50 Slávek Banko via tde-users wrote:
On Friday 08 of January 2021 01:38:42 deloptes via tde-users wrote:
E. Liddell wrote:
Not a *big* problem, but I don't know if people subscribed only to the new list are able to see your messages. You shouldn't have to unsubscribe from the old list to register with the new (since I get mail from both) unless your mail setup is very strange.
(Mail from the old list is also a minor persistent irritant for me personally, as, for historical reasons, I have *two* addresses subscribed to the old list and so get duplicate mail from it. No one still on the old list = no duplicate mail for me to deal with. That's what keeps drawing the origin of your messages to my attention.)
But I am just using the list from gmane. I am sure I subscribed to the new one. I have no idea what I have to do next. When this was announced I was under pressure in a project and couldn't follow up properly. I have on the todo to read again what Slavek said about subscribe/unsubscribe. Interestingly I do not see any new list in gmane to subscribe (but I remember Slavek set it up with gmane) Honestly I am waiting to get into the mood for solving it myself Sometimes it takes time though :)
This is done so that I did update the information on GMane, so under the original news names there should work a new ML. How do you answer? Through GMake or directly by smtp to ML?
Cheers
Now I have found a problem. For a reason unknown to me on GMane, it is now listed an old address as the main for tde-users and the new address is listed as an alias. I put a request with a question on GMane.
Cheers
Slávek Banko via tde-users wrote:
Now I have found a problem. For a reason unknown to me on GMane, it is now listed an old address as the main for tde-users and the new address is listed as an alias. I put a request with a question on GMane.
Thank you Slavek, this explains it all. I am using knode to read and post. Let's see how it will work in the future.
Thank you once again for the effort.
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 08 of January 2021 09:52:40 deloptes via tde-users wrote:
Slávek Banko via tde-users wrote:
Now I have found a problem. For a reason unknown to me on GMane, it is now listed an old address as the main for tde-users and the new address is listed as an alias. I put a request with a question on GMane.
Thank you Slavek, this explains it all. I am using knode to read and post. Let's see how it will work in the future.
Thank you once again for the effort.
Data on GMane updated again. So I hope that the responses through GMane should again be sent directly to the new ML.
Cheers
On Wednesday 06 January 2021 15:59:04 E. Liddell via tde-users wrote:
On Wed, 06 Jan 2021 20:52:13 +0100 deloptes deloptes@gmail.com wrote:
Also, deloptes, you're still posting to the old list.
E. Liddell
Thou, hypocrite, E. Liddell -- also guilty of posting to the old list!
(Your emails come through in both lists, exactly like deloptes. That is hilarious.)
Bill
On Wed, 6 Jan 2021 18:16:52 -0800 William Morder via tde-users users@trinitydesktop.org wrote:
On Wednesday 06 January 2021 15:59:04 E. Liddell via tde-users wrote:
On Wed, 06 Jan 2021 20:52:13 +0100 deloptes deloptes@gmail.com wrote:
Also, deloptes, you're still posting to the old list.
E. Liddell
Thou, hypocrite, E. Liddell -- also guilty of posting to the old list!
(Your emails come through in both lists, exactly like deloptes. That is hilarious.)
That one did, yes, because I replied to deloptes without correcting the address.
E. Liddell
E. Liddell wrote:
That one did, yes, because I replied to deloptes without correcting the address.
I am subscribed to both lists - if I am not completely missing memories. I think I have to unsubscribe from the old one. It might be bouncing through the gmane mail servers ending up in the old list.
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thursday 07 January 2021 16:11:17 E. Liddell wrote:
On Wed, 6 Jan 2021 18:16:52 -0800
William Morder via tde-users users@trinitydesktop.org wrote:
On Wednesday 06 January 2021 15:59:04 E. Liddell via tde-users wrote:
On Wed, 06 Jan 2021 20:52:13 +0100 deloptes deloptes@gmail.com wrote:
Also, deloptes, you're still posting to the old list.
E. Liddell
Thou, hypocrite, E. Liddell -- also guilty of posting to the old list!
(Your emails come through in both lists, exactly like deloptes. That is hilarious.)
That one did, yes, because I replied to deloptes without correcting the address.
E. Liddell
Something similar happened to me when I replied to Stefan's private email without checking who was to be my recipient; I unwittingly assumed that it was being sent to the TDE list.
There are still a few glitches in the system, which makes for some awkward exchanges. I trust readers know when I am joking, without having to insert emojis. If I am genuinely annoyed with somebody, I try to make it clear. ;-)
And I, too, am annoyed by having to sift out the duplicates from the old list so I can delete them; but all in good time, I hope. There are bigger problems in this world to worry about.
Bill
Stefan Krusche via tde-users wrote:
$ grep Berlin /opt/trinity/share/apps/kweatherservice/stations.dat
EDDB;10;385;Berlin-Schoenefeld;;Germany;6;52-23N;013-31E;52-23N;013-31E;47;50;P
EDDI;10;384;Berlin-Tempelhof;;Germany;6;52-28N;013-24E;52-29N;013-25E;50;49;P
EDDT;10;382;Berlin-Tegel;;Germany;6;52-34N;013-19E;;;37;37; KBML;72;616;Berlin, Berlin Municipal Airport;NH;United States;4;44-34-34N;071-10-43W;44-34-41N;071-10-49W;353;345;
Now the question is: why does Berlin-Schönefeld not show up in the list which kweather offers to choose stations from?
BTW, is there any documentation of the format of this file? Is it also retrieved from noaa.gov? Or created dynamically?
sorry, I was distracted
in the file
.trinity/share/config/weather_panelappletrc
set manually the line
report_location=EDDB
does it help?
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote: in the file
.trinity/share/config/weather_panelappletrc
set manually the line
report_location=EDDB
does it help?
Bullseye!
I didn't know this file, I haven't looked further after I found config/KweatherServicerc …
Thanks for the pointer!
Cheers, Stefan
Am Donnerstag, 7. Januar 2021 schrieb Stefan Krusche via tde-users:
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote: in the file
.trinity/share/config/weather_panelappletrc
set manually the line
report_location=EDDB
does it help?
Bullseye!
I didn't know this file, I haven't looked further after I found config/KweatherServicerc …
This means there are two different rc-files for kweather in /opt/trinity/share/apps/kweatherservice:
$ ls *eather* KWeatherServicerc weather_panelappletrc
With this content: $ cat KWeatherServicerc [WEATHERSTATIONS] stations=EDVE
$ cat weather_panelappletrc [General Options] log_file_name[$e]= logging=false report_location=EDDB reportview_size=5xx,3xx smallview_mode=2 textColor=2xx,2xx,2xx
Wouldn't it make sense to merge them into one? Should I file a bug? With which severity, "wishlist"?!
Cheers, Stefan
Stefan Krusche via tde-users wrote:
Wouldn't it make sense to merge them into one? Should I file a bug? With which severity, "wishlist"?!
yeah, this is why I mentioned the code is stupid ... there are duplications and a kind of spaghetti all over the place, but this is working as it is and no one had the time to rework it. What I like particularly in kweather, that it shows the wind chill. In KDE/Sailfish they use other source that does not do this.
I would suggest file two bugs for kweather. One for the issue and the resolution: You mentioned Berlin-Tegel etc does not exist, so we want to replace it in the weather_stations.desktop file with Berlin-Schoenefeld.
The other might be wish-list or improvement describing the duplication and aiming to rework the code. Most of all I wish all these have one and same source (i.e. stations.dat or whatever) is used to generate the files automatically.
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thursday 07 January 2021 05:56:46 deloptes via tde-users wrote:
Stefan Krusche via tde-users wrote:
Wouldn't it make sense to merge them into one? Should I file a bug? With which severity, "wishlist"?!
yeah, this is why I mentioned the code is stupid ... there are duplications and a kind of spaghetti all over the place, but this is working as it is and no one had the time to rework it. What I like particularly in kweather, that it shows the wind chill. In KDE/Sailfish they use other source that does not do this.
I would suggest file two bugs for kweather. One for the issue and the resolution: You mentioned Berlin-Tegel etc does not exist, so we want to replace it in the weather_stations.desktop file with Berlin-Schoenefeld.
The other might be wish-list or improvement describing the duplication and aiming to rework the code. Most of all I wish all these have one and same source (i.e. stations.dat or whatever) is used to generate the files automatically.
I do not get that from the gkrellm plugin. But I'd suspect kweather is calculating it since all the data to do that is present.
Cheers, Gene Heskett
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote:
Wouldn't it make sense to merge them into one? Should I file a bug? With which severity, "wishlist"?!
yeah, this is why I mentioned the code is stupid ... there are duplications and a kind of spaghetti all over the place, but this is working as it is and no one had the time to rework it. What I like particularly in kweather, that it shows the wind chill. In KDE/Sailfish they use other source that does not do this.
Yes, I like it, too!
I would suggest file two bugs for kweather. One for the issue and the resolution: You mentioned Berlin-Tegel etc does not exist, so we want to replace it in the weather_stations.desktop file with Berlin-Schoenefeld.
I think you're mixing up two things here. Firstly, Berlin-Tegel is in the database (as still is Berlin-Tempelhof; shut down ~2009), but the airport was shut down Nov 8 2020. Berlin-Schönefeld is also in the database already. Secondly, the database is not weather_stations.desktop but stations.dat, which of course could use some care.
The other might be wish-list or improvement describing the duplication and aiming to rework the code. Most of all I wish all these have one and same source (i.e. stations.dat or whatever) is used to generate the files automatically.
See Sláveks answer to this.
Cheers, Stefan
On Thursday 07 January 2021 04:10:11 Stefan Krusche via tde-users wrote:
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote:
Wouldn't it make sense to merge them into one? Should I file a bug? With which severity, "wishlist"?!
yeah, this is why I mentioned the code is stupid ... there are duplications and a kind of spaghetti all over the place, but this is working as it is and no one had the time to rework it. What I like particularly in kweather, that it shows the wind chill. In KDE/Sailfish they use other source that does not do this.
Yes, I like it, too!
I would suggest file two bugs for kweather. One for the issue and the resolution: You mentioned Berlin-Tegel etc does not exist, so we want to replace it in the weather_stations.desktop file with Berlin-Schoenefeld.
I think you're mixing up two things here. Firstly, Berlin-Tegel is in the database (as still is Berlin-Tempelhof; shut down ~2009), but the airport was shut down Nov 8 2020. Berlin-Sch�nefeld is also in the database already. Secondly, the database is not weather_stations.desktop but stations.dat, which of course could use some care.
The other might be wish-list or improvement describing the duplication and aiming to rework the code. Most of all I wish all these have one and same source (i.e. stations.dat or whatever) is used to generate the files automatically.
See Sl�veks answer to this.
Cheers, Stefan
Okay, so I've been following this thread with some interest, because of late I can't use any decent weather pages online. (The only decent pages block me for using Tor.) I used to depend on https://forecast.weather.gov/ and before that, Weather Underground, but they have both turned to crap.
When I try to use kweather-trinity, even after I load my preferred locations and update, etc., all I get is a big question mark. When I click to "show report", I am informed that the network is offline. But it is not true! I can send and receive emails, surf the web, download, upload, all that good stuff.
If I were to guess, it might be that I've never got tdenetworkmanager to work properly. It worked so-so with Debian/Devuan Jessie, but about half the time I had to fall back on wicd. Since upgrading to Devuan Beowulf, tdenetworkmanager has never worked for me (it won't accept login credentials for my in-house wifi); so I've used wicd exclusively. But it works fine, and I can live without TDE in a few things, if I must.
So do I have to dig into the guts of kweather to change something, or should I look elsewhere?
Bill
William Morder via tde-users wrote:
So do I have to dig into the guts of kweather to change something, or should I look elsewhere?
Can you access tgftp.nws.noaa.gov particularly https://tgftp.nws.noaa.gov/data/observations/metar/stations/
if you get the error from kweather, it might not have to do with underlaying networking
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
William Morder via tde-users wrote:
So do I have to dig into the guts of kweather to change something, or should I look elsewhere?
Can you access tgftp.nws.noaa.gov particularly https://tgftp.nws.noaa.gov/data/observations/metar/stations/
That is exactly the page I was talking about.
Cheers, Stefan
Am Donnerstag, 7. Januar 2021 schrieb Stefan Krusche via tde-users:
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
William Morder via tde-users wrote:
So do I have to dig into the guts of kweather to change something, or should I look elsewhere?
Can you access tgftp.nws.noaa.gov particularly https://tgftp.nws.noaa.gov/data/observations/metar/stations/
That is exactly the page I was talking about.
In that directory listing you can also see very old files of phased out stations like the one for Berlin-Tempelhof:
EDDI.TXT 03-Jul-2009 03:26 62
Which means NOAA does keep the latest data set of a particular station even when it has been shut down.
Stefan
On Thursday 07 January 2021 05:40:12 deloptes via tde-users wrote:
William Morder via tde-users wrote:
So do I have to dig into the guts of kweather to change something, or should I look elsewhere?
Can you access tgftp.nws.noaa.gov particularly https://tgftp.nws.noaa.gov/data/observations/metar/stations/
if you get the error from kweather, it might not have to do with underlaying networking
Well, I just opened it as a web page, over Tor, and get an index of text files listing different locations; so the information can be accessed, just not by me through the kweather app.
Bill
Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users:
Well, I just opened it as a web page, over Tor, and get an index of text files listing different locations; so the information can be accessed, just not by me through the kweather app.
There are some stations in weather_applet's list to choose from which don't exist anymore. Maybe you ran into one or more of these?
Cheers, Stefan
Stefan Krusche via tde-users wrote:
There are some stations in weather_applet's list to choose from which don't exist anymore. Maybe you ran into one or more of these?
But he says he is receiving an error regarding network unavailable. In this case we should look into why kweather can not retrieve the data- tcpdump or so. I am also getting the "question mark" from time to time, but then I rightclick and do "update" and it works. IMO it is something with the handling of connections in the background, but never bothered to look into.
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote:
There are some stations in weather_applet's list to choose from which don't exist anymore. Maybe you ran into one or more of these?
But he says he is receiving an error regarding network unavailable. In this case we should look into why kweather can not retrieve the data- tcpdump or so. I am also getting the "question mark" from time to time, but then I rightclick and do "update" and it works. IMO it is something with the handling of connections in the background, but never bothered to look into.
I agree.
Stefan
Dear Bill,
Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users:
When I try to use kweather-trinity, even after I load my preferred locations and update, etc., all I get is a big question mark. When I click to "show report", I am informed that the network is offline.
This also happens when there's no actual data on noaa.gov because the particular station you are requesting has stopped updating data to noaa.gov – See my previous mails for details. It happens when the station shuts down and still is in the kweather database to choose or if you've still configured it.
When you find a station (any) which works that'd be a sign for being a general network problem.
But it is not true! I can send and receive emails, surf the web, download, upload, all that good stuff.
Can you configure kweather to show any station's data?! Or do all fail?
Kind regards, Stefan
On Thursday 07 January 2021 06:00:11 Stefan Krusche via tde-users wrote:
Dear Bill,
Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users:
When I try to use kweather-trinity, even after I load my preferred locations and update, etc., all I get is a big question mark. When I click to "show report", I am informed that the network is offline.
This also happens when there's no actual data on noaa.gov because the particular station you are requesting has stopped updating data to noaa.gov – See my previous mails for details. It happens when the station shuts down and still is in the kweather database to choose or if you've still configured it.
When you find a station (any) which works that'd be a sign for being a general network problem.
But it is not true! I can send and receive emails, surf the web, download, upload, all that good stuff.
Can you configure kweather to show any station's data?! Or do all fail?
Kind regards, Stefan
Besides my local weather (San Francisco - SFO), I like to check the weather at various places where I've lived, have family or friends; not only here in the US, but some other locations round the world. Mostly I just use my local weather, but I do like to wonder now and then what it's like elsewhere.
I attached a screenshot.
Bill
Bill
William Morder via tde-users wrote:
Besides my local weather (San Francisco - SFO), I like to check the weather at various places where I've lived, have family or friends; not only here in the US, but some other locations round the world. Mostly I just use my local weather, but I do like to wonder now and then what it's like elsewhere.
I have 7 stations and all of them show the information :/
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Thursday 07 January 2021 07:44:29 deloptes via tde-users wrote:
William Morder via tde-users wrote:
Besides my local weather (San Francisco - SFO), I like to check the weather at various places where I've lived, have family or friends; not only here in the US, but some other locations round the world. Mostly I just use my local weather, but I do like to wonder now and then what it's like elsewhere.
I have 7 stations and all of them show the information :/
Ha! found it! (or at least I believe so).
I poked around in network settings in the TDE Control Center, and it turns out that proxy had been set to "manually specify proxy settings"; once I clicked change to direct connection, then updated kweather, suddenly I have information for my weather stations.
Now the puzzle is, why are my network and proxy settings changed in the TDE Control Center, when in fact I never use those settings. I have my machine set for direct connection, and manually specify proxy settings for individual applications like browsers or whatever.
Bill
Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users:
On Thursday 07 January 2021 07:44:29 deloptes via tde-users wrote:
William Morder via tde-users wrote:
Besides my local weather (San Francisco - SFO), I like to check the weather at various places where I've lived, have family or friends; not only here in the US, but some other locations round the world. Mostly I just use my local weather, but I do like to wonder now and then what it's like elsewhere.
I have 7 stations and all of them show the information :/
Ha! found it! (or at least I believe so).
I poked around in network settings in the TDE Control Center, and it turns out that proxy had been set to "manually specify proxy settings"; once I clicked change to direct connection, then updated kweather, suddenly I have information for my weather stations.
Now the puzzle is, why are my network and proxy settings changed in the TDE Control Center, when in fact I never use those settings. I have my machine set for direct connection, and manually specify proxy settings for individual applications like browsers or whatever.
This puzzle only you can save! ;-)
Glad it works for you again.
Stefan
On Thursday 07 January 2021 08:21:53 you wrote:
Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users:
On Thursday 07 January 2021 07:44:29 deloptes via tde-users wrote:
William Morder via tde-users wrote:
Besides my local weather (San Francisco - SFO), I like to check the weather at various places where I've lived, have family or friends; not only here in the US, but some other locations round the world. Mostly I just use my local weather, but I do like to wonder now and then what it's like elsewhere.
I have 7 stations and all of them show the information :/
Ha! found it! (or at least I believe so).
I poked around in network settings in the TDE Control Center, and it turns out that proxy had been set to "manually specify proxy settings"; once I clicked change to direct connection, then updated kweather, suddenly I have information for my weather stations.
Now the puzzle is, why are my network and proxy settings changed in the TDE Control Center, when in fact I never use those settings. I have my machine set for direct connection, and manually specify proxy settings for individual applications like browsers or whatever.
This puzzle only you can save! ;-)
Glad it works for you again.
Stefan
Yes, but I wonder why TDE apps will not use system proxy settings. This is my main reason for problems encountered with online weather pages, and with weather apps on my smartphone.
If I am asking what's the weather, then they already know the location close enough for my own information. The weather is about the same if it is in the same city. But no, they want to know my precise real location, as I sit here at my desk, even if I am wondering what is the weather like in London or Moscow. Is it a matter of national security, to know this about me?
It would be nice to be able to torify TDE apps. :-[
Bill
P.S. Sorry, resending to the TDE list. (For some reason I keep getting Stefan's private email as the "reply to" address; must be he is another sending to the old list.) Anyway, apologies for the duplicates!
Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users:
P.S. Sorry, resending to the TDE list. (For some reason I keep getting Stefan's private email as the "reply to" address; must be he is another sending to the old list.) Anyway, apologies for the duplicates!
No problem. I've done it, too. Usually kmail responds correctly to the respective list, but for some reason some emails are responded to directly to the sender…
Stefan
Stefan Krusche via tde-users wrote:
The other might be wish-list or improvement describing the duplication and aiming to rework the code. Most of all I wish all these have one and same source (i.e. stations.dat or whatever) is used to generate the files automatically.
See Sláveks answer to this.
I created PR#10 to get Schönefeld in to the list.
https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/pulls/10
For the rest may be you can sanitize the German part and if you can not add it to the PR, I can do it for you.
For now I tag it as work in progress.
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote:
The other might be wish-list or improvement describing the duplication and aiming to rework the code. Most of all I wish all these have one and same source (i.e. stations.dat or whatever) is used to generate the files automatically.
See Sláveks answer to this.
I created PR#10 to get Schönefeld in to the list.
I've lost you. Or you've lost me. I'm sorry, but I'm pretty sure we misunderstood each other.
--> Berlin-Schoenefeld already *is* in the "list", that is the database of available weather stations (airports) in the file "stations.dat".
--> For some reason this entry "Berlin-Schönefeld", besides many other entries, is not shown in the list of available weather stations in the GUI interface and cannot be chosen to be the one which weatherapplet shows in the weather report (the little window that opens when one clicks on the applet's icon in kicker).
I think there is a reason. Maybe a bug or any technical reason, IDK.
I got it working because your proposal to edit weather_appletrc put me on the right track. But, instead I edited KWeatherServicerc: I added the ICAO (airport code) of B-Schönefeld (EDDB).
$ cat .trinity/share/config/KWeatherServicerc [WEATHERSTATIONS] stations=EDDV,EDDW,EDDH,ETND,EDDB
Only now Berlin-Schönefeld *is* listed under "Chosen stations" in the GUI config dialog and, when picked as the one that the kicker weather applet should use, the data of that station appears in the weather report window (the little window that opens when one clicks on the applet's icon in kicker).
Note: you can not choose "Berlin-Schönefeld" in the GUI from the list of "Available stations" because it doesn't show up in that list. That is the problem and not that there wasn't an entry of it in the database "stations.dat". It was and is there but doesn't get listed (like many, many others). From 111 German stations in the database only 29 appear in the list of available stations.
https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/pulls/10
For the rest may be you can sanitize the German part and if you can not add it to the PR, I can do it for you.
I've wanted to do that, too. I was wondering how to do such a pull request but first I will have to RTFM or other docs to teach myself how to do it.
Thanks for engaging.
Cheers! Stefan
Stefan Krusche via tde-users wrote:
https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/pulls/10
For the rest may be you can sanitize the German part and if you can not add it to the PR, I can do it for you.
I've wanted to do that, too. I was wondering how to do such a pull request but first I will have to RTFM or other docs to teach myself how to do it.
Thanks for engaging.
Yes, welcome. You can use the PR (git pull etc) to prepare patches. You can ask Slavek or Michele to approve your status as contributor and you can push changes directly or you can send me the information (patches) and I do it.
BTW I was not meaning the stations.dat, but the desktop file. AFAIK the problem with TDE is that it is too few people maintaining the code and some things get outdated without even noticing. So if you can summarize what needs to change and where we can save a lot of time and update at least the underlaying data.
For me it is obvious that the desktop file (used in the kicker applet to configure the stations) needs to be updated to match stations.dat The question is what is the origin of stations.dat and if the stations there are still valid.
Anyway I would prefer to move this discussion to Gitea
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
BTW I was not meaning the stations.dat, but the desktop file. AFAIK the problem with TDE is that it is too few people maintaining the code and some things get outdated without even noticing. So if you can summarize what needs to change and where we can save a lot of time and update at least the underlaying data.
For me it is obvious that the desktop file (used in the kicker applet to configure the stations) needs to be updated to match stations.dat The question is what is the origin of stations.dat and if the stations there are still valid.
I feel the need to apologise. I hadn't looked into that .desktop file thinking it was something like, well, "only a .desktop file".
Now I see that it is, indeed, important just like you said.
All right then, let's move this to gitea.
And thanks for hanging in with me.
Cheers, Stefan
On Thursday 07 of January 2021 10:53:21 Stefan Krusche via tde-users wrote:
Am Donnerstag, 7. Januar 2021 schrieb Stefan Krusche via tde-users:
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote: in the file
.trinity/share/config/weather_panelappletrc
set manually the line
report_location=EDDB
does it help?
Bullseye!
I didn't know this file, I haven't looked further after I found config/KweatherServicerc …
This means there are two different rc-files for kweather in /opt/trinity/share/apps/kweatherservice:
$ ls *eather* KWeatherServicerc weather_panelappletrc
With this content: $ cat KWeatherServicerc [WEATHERSTATIONS] stations=EDVE
$ cat weather_panelappletrc [General Options] log_file_name[$e]= logging=false report_location=EDDB reportview_size=5xx,3xx smallview_mode=2 textColor=2xx,2xx,2xx
Wouldn't it make sense to merge them into one? Should I file a bug? With which severity, "wishlist"?!
Cheers, Stefan ____________________________________________________
The service runs independently and can update multiple stations. The applet then displays just one of these stations. Therefore, there are two separate configuration files.
Cheers
Am Donnerstag, 7. Januar 2021 schrieb Slávek Banko via tde-users:
On Thursday 07 of January 2021 10:53:21 Stefan Krusche via tde-users
wrote:
This means there are two different rc-files for kweather in /opt/trinity/share/apps/kweatherservice:
$ ls *eather* KWeatherServicerc weather_panelappletrc
With this content: $ cat KWeatherServicerc [WEATHERSTATIONS] stations=EDVE
$ cat weather_panelappletrc [General Options] log_file_name[$e]= logging=false report_location=EDDB reportview_size=5xx,3xx smallview_mode=2 textColor=2xx,2xx,2xx
Wouldn't it make sense to merge them into one? Should I file a bug? With which severity, "wishlist"?!
The service runs independently and can update multiple stations. The applet then displays just one of these stations. Therefore, there are two separate configuration files.
Good. That makes technical sense and I don't need to bother about it anymore.
Thank you.
Cheers, Stefan
Stefan Krusche via tde-users wrote:
The service runs independently and can update multiple stations. The applet then displays just one of these stations. Therefore, there are two separate configuration files.
Good. That makes technical sense and I don't need to bother about it anymore.
This is quite OK. What I mean is that you have the entries hardcoded in those files and not generated by the same source. This leads to problems like the one we have that someone should update all the files if something changes. It would be better if we generate all those files from the same source.
I also noticed other duplicates in the code and despite I am not a professional C++ developer, I still had to shake my head. I was thinking there should be one service and library doing all the work, no?
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
This is quite OK. What I mean is that you have the entries hardcoded in those files and not generated by the same source. This leads to problems like the one we have that someone should update all the files if something changes. It would be better if we generate all those files from the same source.
If there is such one. And if you have the programmatic framework to automise that. But maybe it's in the source repo already, IDK.
I rather got the impression that stations.dat is a collection of individual data but I could be wrong. It's easy to edit. I changed some of the "ue"s, "oe"s and "ae"s to real german umlauts and it seems to work. As easy would it be possible to add or delete entries.
I also noticed other duplicates in the code and despite I am not a professional C++ developer, I still had to shake my head. I was thinking there should be one service and library doing all the work, no?
Well, yeah, I mean probably! :-)
But, hey, I only learned two hours ago that there are (at least) two different things: kweather, the service, and weather_applet which runs in kicker. And in the help pages for Kweather other applications are mentioned to use the data the daemon retrieves and provides…
Cheers, Stefan
Stefan Krusche via tde-users wrote:
If there is such one. And if you have the programmatic framework to automise that. But maybe it's in the source repo already, IDK.
I'm studying TQt3 for the past couple of years. The biggest problem is time - or better lack of time.
I rather got the impression that stations.dat is a collection of individual data but I could be wrong. It's easy to edit. I changed some of the "ue"s, "oe"s and "ae"s to real german umlauts and it seems to work. As easy would it be possible to add or delete entries.
I do not know what is the source of stations.dat. What I do not know, I do not touch.
Regarding the ue -> ü and oe -> ö, you could help with that, if you want. AS mentioned time is a problem, but you can contribute by working on the PR to pimp this up (see at the end below).
I also noticed other duplicates in the code and despite I am not a professional C++ developer, I still had to shake my head. I was thinking there should be one service and library doing all the work, no?
Well, yeah, I mean probably! :-)
But, hey, I only learned two hours ago that there are (at least) two different things: kweather, the service, and weather_applet which runs in kicker. And in the help pages for Kweather other applications are mentioned to use the data the daemon retrieves and provides…
To me it is spaghetti and I would like to have it at least lasagna :) - but this dish is not on my priority list at all.
Let's look at the bright side. Now we have a branch in Gitea dedicated to the issue #9, so we can work on that. The plan is to work together and update the different files and locations -> this is what you can do - no code modifications at all just prepare the information, find out what is the source of this stations.dat file, write a readme - I just do not have the time to check every one station individually or write a script to do so. I can compile and test all the changes - you can test as well, if you wish of course. When ready some of the Trinity Gods can bless our work and merge it :)
What do you think? regards
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users:
Stefan Krusche via tde-users wrote:
If there is such one. And if you have the programmatic framework to automise that. But maybe it's in the source repo already, IDK.
I'm studying TQt3 for the past couple of years. The biggest problem is time - or better lack of time.
I'd like to, too, but as you said…
I rather got the impression that stations.dat is a collection of individual data but I could be wrong. It's easy to edit. I changed some of the "ue"s, "oe"s and "ae"s to real german umlauts and it seems to work. As easy would it be possible to add or delete entries.
I do not know what is the source of stations.dat. What I do not know, I do not touch.
You are talking about automatically updating stations.dat. This up to now never was a question or problem for me.
The problem is, instead, what I reported. See also https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/issues/9
I think, this should at least be investigated by someone with insight in the source code before.
Regarding the ue -> ü and oe -> ö, you could help with that, if you want. AS mentioned time is a problem, but you can contribute by working on the PR to pimp this up (see at the end below).
Yes, of course! I'd love to.
I also noticed other duplicates in the code and despite I am not a professional C++ developer, I still had to shake my head. I was thinking there should be one service and library doing all the work, no?
Well, yeah, I mean probably! :-)
But, hey, I only learned two hours ago that there are (at least) two different things: kweather, the service, and weather_applet which runs in kicker. And in the help pages for Kweather other applications are mentioned to use the data the daemon retrieves and provides…
To me it is spaghetti and I would like to have it at least lasagna :)
- but this dish is not on my priority list at all.
Let's look at the bright side. Now we have a branch in Gitea dedicated to the issue #9, so we can work on that. The plan is to work together and update the different files and locations -> this is what you can do - no code modifications at all just prepare the information, find out what is the source of this stations.dat file, write a readme - I just do not have the time to check every one station individually or write a script to do so. I can compile and test all the changes - you can test as well, if you wish of course. When ready some of the Trinity Gods can bless our work and merge it :)
What do you think?
Great! Sounds like cooperation. What else can we expect from each other or this community!
Stefan
Stefan Krusche via tde-users wrote:
You are talking about automatically updating stations.dat. This up to now never was a question or problem for me.
The problem is, instead, what I reported. See also https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/issues/9
I think, this should at least be investigated by someone with insight in the source code before.
The problem is that it is a static data you have once in stations.dat and a second time in the desktop file. The service is using stations.dat (if I am not wrong), but the applet is using the desktop file to provide the values for selecting the stations. This is what I see in the code (without too much digging)
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Stefan Krusche via tde-users wrote:
What do you think?
Great! Sounds like cooperation. What else can we expect from each other or this community!
I think I found the source of stations.dat. What could be useful is a mapping of countries to regions. Then weather_stations.desktop could be generated automatically out of stations.dat.
[Main] regions=US CA MX EU AF OZ ME AS M_ AT
in stations.dat you have
Tasiilaq;;Greenland or Lac Benoit;;Canada; or High Island;LA;United States
which becomes
[US] name=United States states=AL AK AZ AR CA CO CT DE DC FL GA HI ID IL IN IA KS KY LA ME MA MD MI MS MN MO MT NE NH NM NV NY ND NJ NC OH OK OR PA RI SC SD TN TX UT VT VA WA WI WV WY
[EU] name=Europe states=AB OS BE BA BY BG CZ HR CY DK EE FI FR MK DE GI GR HU IE IS IT LV LT LU MT MD NL NO PL PT RO RU SK SI SP SE CH TR UA UK YU
[CA] name=Canada states=AB BC MB NB NF NS NT ON QC SK YK
etc.
Now if we know how it maps for example [EU_AB] name=Albania
or
[CA_AB] name=Alberta
we can automatically generate the locX entries for each region and country.
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 08 January 2021 10:57:32 am deloptes via tde-users wrote:
Stefan Krusche via tde-users wrote:
What do you think?
Great! Sounds like cooperation. What else can we expect from each other or this community!
I think I found the source of stations.dat. What could be useful is a mapping of countries to regions. Then weather_stations.desktop could be generated automatically out of stations.dat.
I admit I've only been skiming this thread, I tried kweather once, it didn't have my nearest airport, nor could I figure out how to manually enter my airport's code ID, so it wasn't really useful. That said...
Q1: Isn't there already an 'official' mapping of countries to regions? I know I've used this data on other people's websites (and Timezone data kinda does this as well), so I'd bet there is some goverment function somewhere that already maps it to pull from.
Q2: Wouldn't it be better to have kweather itself auto-generate stations real time off of noaa? That'd at least solve the "can't find my known airport." Or at least a way to manually enter an airports code ID?
Alternative 1: Would it be feasable to pull from wunderground.com (at least by manually entering station names)? Last summer I needed average temps around me for an attic fan setup and used data from wunderground. See attached. It's not pretty, but it worked well enough..
Okay, bowing out, best, Michael
Michael via tde-users wrote:
I admit I've only been skiming this thread, I tried kweather once, it didn't have my nearest airport, nor could I figure out how to manually enter my airport's code ID, so it wasn't really useful. That said...
Now hopefully you know how to set it up manually
Q1: Isn't there already an 'official' mapping of countries to regions? I know I've used this data on other people's websites (and Timezone data kinda does this as well), so I'd bet there is some goverment function somewhere that already maps it to pull from.
I don't know
Q2: Wouldn't it be better to have kweather itself auto-generate stations real time off of noaa? That'd at least solve the "can't find my known airport." Or at least a way to manually enter an airports code ID?
Asked this and the Gods said - no. Also the DB is updated not very frequently
Alternative 1: Would it be feasable to pull from wunderground.com (at least by manually entering station names)? Last summer I needed average temps around me for an attic fan setup and used data from wunderground. See attached. It's not pretty, but it worked well enough..
No because the IDs are different - not sure if these are the same stations at all.
Nice to have would be different backends for kweather.
Okay, bowing out, best, Michael
--------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Friday 08 January 2021 11:11:18 deloptes via tde-users wrote:
Michael via tde-users wrote:
I admit I've only been skiming this thread, I tried kweather once, it didn't have my nearest airport, nor could I figure out how to manually enter my airport's code ID, so it wasn't really useful. That said...
Now hopefully you know how to set it up manually
Q1: Isn't there already an 'official' mapping of countries to regions? I know I've used this data on other people's websites (and Timezone data kinda does this as well), so I'd bet there is some goverment function somewhere that already maps it to pull from.
I don't know
Q2: Wouldn't it be better to have kweather itself auto-generate stations real time off of noaa? That'd at least solve the "can't find my known airport." Or at least a way to manually enter an airports code ID?
Asked this and the Gods said - no. Also the DB is updated not very frequently
Alternative 1: Would it be feasable to pull from wunderground.com (at least by manually entering station names)? Last summer I needed average temps around me for an attic fan setup and used data from wunderground. See attached. It's not pretty, but it worked well enough..
No because the IDs are different - not sure if these are the same stations at all.
Nice to have would be different backends for kweather.
Okay, bowing out, best, Michael
I, too, was just skimming the last couple posts, but I noticed that for US entries, postal codes for states were listed by deloptes from his dat source, but for Europe, etc., similar codes are given. What I remember of UK postal codes (for instance) does not match this two-letter scheme.
Is there some database that can be used as a source, so that it is consistent? It would be okay to use both airport codes and postal codes (called ZIP codes in the US), as well as any other source, but it would be nice if users had some inkling of the source; e.g., as Michael suggested, we could use Weather Underground -- or maybe multiple sources?
The problem here is of course that the business of weather forecasts varies from one place to another; there is no World Weather Federation.
Bill
William Morder via tde-users wrote:
I, too, was just skimming the last couple posts, but I noticed that for US entries, postal codes for states were listed by deloptes from his dat source, but for Europe, etc., similar codes are given. What I remember of UK postal codes (for instance) does not match this two-letter scheme.
Is there some database that can be used as a source, so that it is consistent? It would be okay to use both airport codes and postal codes (called ZIP codes in the US), as well as any other source, but it would be nice if users had some inkling of the source; e.g., as Michael suggested, we could use Weather Underground -- or maybe multiple sources?
The problem here is of course that the business of weather forecasts varies from one place to another; there is no World Weather Federation.
There is issue #4 (https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/issues/4)
but it goes out of the scope of fixing the issue #9
On Friday 08 January 2021 16:38:44 deloptes wrote:
William Morder via tde-users wrote:
I, too, was just skimming the last couple posts, but I noticed that for US entries, postal codes for states were listed by deloptes from his dat source, but for Europe, etc., similar codes are given. What I remember of UK postal codes (for instance) does not match this two-letter scheme.
Is there some database that can be used as a source, so that it is consistent? It would be okay to use both airport codes and postal codes (called ZIP codes in the US), as well as any other source, but it would be nice if users had some inkling of the source; e.g., as Michael suggested, we could use Weather Underground -- or maybe multiple sources?
The problem here is of course that the business of weather forecasts varies from one place to another; there is no World Weather Federation.
There is issue #4 (https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/issues/4)
but it goes out of the scope of fixing the issue #9
Sorry, but I unintentionally conflated US ZIP codes (e.g., 60007 -- for somewhere in the Chicago area) with state codes (e.g., IL for Illinois). I was trying to avoid using Americanisms and confusing international readers. (Thanks to Gene for putting that thought in my head.)
The 5-digit numerical ZIP codes (or extended codes, which are nine digits) and state codes such as IL both originate with our postal system, and have become habit since about the 1980s or so. But in England regions are abbreviated as Oxen., Hants., Bucks., etc., and postal codes (similar to US ZIP codes) are entirely different. The same problem for everywhere else; they will have different systems, and trying to accomodate these variations will be a headache for developers.
Airport codes are more standardized, but not every place has an airport. If we draw from Weather Underground or other online pages, then we are dependent on intermediaries, and access to the data can be interrupted. So the question is, how to draw from the original source(s) themselves, those that are used by online weather pages?
Bill
Am Freitag, 8. Januar 2021 schrieb Michael via tde-users:
I admit I've only been skiming this thread, I tried kweather once, it didn't have my nearest airport, nor could I figure out how to manually enter my airport's code ID, so it wasn't really useful. That said...
If you are still interested you can tell me the station(s) you want to watch and I can add them manually as I'm already in the process of adding all german stations which are still working.
What I'd need to know is the ICAO code of that airport.
Or you can test yourself with some simple dcop calls in your shell like this:
# add Station by ICAO code dcop KWeatherService WeatherService addStation $ICAOcode # you need to wait a sec; I did 'sleep 1' in a script dcop KWeatherService WeatherService update $ICAOcode # again, wait a sec, then request the weather report (the little dialog # window opens and tells you if the station doesn't exist or needs maintaining (in which case you could try later) kweatherreport $ICAOcode # if it doesn't work, remove it dcop KWeatherService WeatherService removeStation $ICAOcode
Cheers, Stefan
On Saturday 09 January 2021 08:14:49 am Stefan Krusche via tde-users wrote:
Am Freitag, 8. Januar 2021 schrieb Michael via tde-users:
I admit I've only been skiming this thread, I tried kweather once, it didn't have my nearest airport, nor could I figure out how to manually enter my airport's code ID, so it wasn't really useful. That said...
If you are still interested you can tell me the station(s) you want to watch and I can add them manually as I'm already in the process of adding all german stations which are still working.
What I'd need to know is the ICAO code of that airport.
Or you can test yourself with some simple dcop calls in your shell like this:
# add Station by ICAO code dcop KWeatherService WeatherService addStation $ICAOcode # you need to wait a sec; I did 'sleep 1' in a script dcop KWeatherService WeatherService update $ICAOcode # again, wait a sec, then request the weather report (the little dialog # window opens and tells you if the station doesn't exist or needs maintaining (in which case you could try later) kweatherreport $ICAOcode # if it doesn't work, remove it dcop KWeatherService WeatherService removeStation $ICAOcode
Cool!
ICAO: KMBT
The command line ‘kweatherreport KMBT’ works and it’ll show in the KWeather applet, but the applet itself won’t display the station data (it displays what I added last, even if I remove it). I added the two references in case there is some other text/data needed.
Thank you!, Michael
PS: To get the dcop calls to work, you need to have (at least) the KWeather applet running.
Ref: https://www.airnav.com/airport/KMBT https://en.wikipedia.org/wiki/Murfreesboro_Municipal_Airport
Am Samstag, 9. Januar 2021 schrieb Michael via tde-users:
The command line ‘kweatherreport KMBT’ works and it’ll show in the KWeather applet, but the applet itself won’t display the station data (it displays what I added last, even if I remove it). I added the two references in case there is some other text/data needed.
Welcome!
After you have done:
dcop KWeatherService WeatherService addStation $ICAOcode
the station should already appear in the config GUI of weather_applet under "Chosen stations…" (my translation). It then also is written to the local config file of your user in
.trinity/share/config/KWeatherServicerc
which lists just these chosen stations for kweatherservice, the daemon. These are then ready to chosen in the config GUI dialog under Display -> location (my translation again).
You could also just add ICAO codes to the above mentioned conf file manually.
PS: To get the dcop calls to work, you need to have (at least) the KWeather applet running.
Thanks, I didn't know. I'been running the applet all along while checking these things out. :-)
Regards, Stefan
PS: just for testing it seems sufficient to just run:
dcop KWeatherService WeatherService update $ICAOcode kweatherreport $ICAOcode
After that the stations is in the list of "chosen stations" but not saved in the config file. It should then be gone after kweather (or TDE) has been restarted.
Stefan Krusche via tde-users wrote:
If you are still interested you can tell me the station(s) you want to watch and I can add them manually as I'm already in the process of adding all german stations which are still working.
What I'd need to know is the ICAO code of that airport.
Or you can test yourself with some simple dcop calls in your shell like this:
# add Station by ICAO code dcop KWeatherService WeatherService addStation $ICAOcode # you need to wait a sec; I did 'sleep 1' in a script dcop KWeatherService WeatherService update $ICAOcode # again, wait a sec, then request the weather report (the little dialog # window opens and tells you if the station doesn't exist or needs maintaining (in which case you could try later) kweatherreport $ICAOcode # if it doesn't work, remove it dcop KWeatherService WeatherService removeStation $ICAOcode
Cheers, Stefan
Hi Stefan, all, we had good progress with help of Slavek to consolidate the patch, however there are still some issues, I highlighted in the ticket.
there are many countries not utilized (it requires creating entries in weather_stations.desktop.in)
For countries like Canada that is listed in the region section as CA) and for all other countries except US, there is no indication to which state the station belongs. The original weather_stations.desktop file had mapping for some stations.
do you have ideas how this can be handled - I mean the mapping of station to state?
thanks
On 2021-01-13 12:40:24 deloptes wrote:
Stefan Krusche via tde-users wrote:
If you are still interested you can tell me the station(s) you want to watch and I can add them manually as I'm already in the process of adding all german stations which are still working.
What I'd need to know is the ICAO code of that airport.
Or you can test yourself with some simple dcop calls in your shell like this:
# add Station by ICAO code dcop KWeatherService WeatherService addStation $ICAOcode # you need to wait a sec; I did 'sleep 1' in a script dcop KWeatherService WeatherService update $ICAOcode # again, wait a sec, then request the weather report (the little dialog # window opens and tells you if the station doesn't exist or needs maintaining (in which case you could try later) kweatherreport $ICAOcode # if it doesn't work, remove it dcop KWeatherService WeatherService removeStation $ICAOcode
Cheers, Stefan
Hi Stefan, all, we had good progress with help of Slavek to consolidate the patch, however there are still some issues, I highlighted in the ticket.
there are many countries not utilized (it requires creating entries in weather_stations.desktop.in)
For countries like Canada that is listed in the region section as CA) and for all other countries except US, there is no indication to which state the station belongs. The original weather_stations.desktop file had mapping for some stations.
do you have ideas how this can be handled - I mean the mapping of station to state?
thanks
Mapping to Canadian provinces wouldn't be too hard; where can I get the list of stations? Don't know about other countries; you'd have to ask people from those places for help.
Leslie --
J Leslie Turriff wrote:
Mapping to Canadian provinces wouldn't be too hard; where can I get the list of stations? Don't know about other countries; you'd have to ask people from those places for help.
https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/k...
$ grep Canada nsd_cccc.txt
Can you create a simple mapping ( station_ID state_ID) and review the state_ids below, please?
[CA] name=Canada states=AB BC MB NB NF NS NT ON QC SK YK
thanks
On Thu, 14 Jan 2021 01:17:05 +0100 deloptes deloptes@gmail.com wrote:
J Leslie Turriff wrote:
Mapping to Canadian provinces wouldn't be too hard; where can I get the list of stations? Don't know about other countries; you'd have to ask people from those places for help.
https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/k...
$ grep Canada nsd_cccc.txt
Can you create a simple mapping ( station_ID state_ID) and review the state_ids below, please?
[CA] name=Canada states=AB BC MB NB NF NS NT ON QC SK YK
The list of provinces/territories is correct, but there are ~700 Canadian weather stations on the list, and some of them are going to be difficult to place. None of them use the "state" field, although some of them annotate the "city" field with a province. Some may have to be tracked down using the latitude and longitude given.
For example:
CYUY;--;---;Rouyn Airport;;Canada;4;48-12N;078-50W;;;301;;
That's presumably a general aviation airport serving Rouyn-Noranda, QC, but I only know that because I've been through the town and was aware it was in close proximity to CYVO in Val D'Or, which allowed me to double-check the coordinates. There are several thousand people for whom CYUY is going to be their nearest weather station, though, so it doesn't seem right to leave it out.
E. Liddell
E. Liddell wrote:
The list of provinces/territories is correct, but there are ~700 Canadian weather stations on the list, and some of them are going to be difficult to place. None of them use the "state" field, although some of them annotate the "city" field with a province. Some may have to be tracked down using the latitude and longitude given.
yeah ... now everybody understands why there were not enough stations to select in the GUI and perhaps you understand why I'm asking here for help.
It is quite of effort to work all these out ... and the 700 are only in Canada ... what about the rest of the world? There are 6702 in the file from which 2590 are already done because they are are in the US. A big portion of the rest is just countries (like Europe etc) Africa, Russia, Mexico are good candidates.
I could easily map everything from Canada to one country Canada, but it will be difficult to find the right station. What do you think
On Thu, 14 Jan 2021 09:31:27 +0100 deloptes deloptes@gmail.com wrote:
E. Liddell wrote:
The list of provinces/territories is correct, but there are ~700 Canadian weather stations on the list, and some of them are going to be difficult to place. None of them use the "state" field, although some of them annotate the "city" field with a province. Some may have to be tracked down using the latitude and longitude given.
yeah ... now everybody understands why there were not enough stations to select in the GUI and perhaps you understand why I'm asking here for help.
It is quite of effort to work all these out ... and the 700 are only in Canada ... what about the rest of the world?
What can I say? Canada is the second-largest country in the world. We have vast tracts of thinly populated land (and vast tracts of largely unpopulated land too), and weather stations are sprinkled all across that.
In a lot of cases, though, a breakdown by country is going to be sufficient. A small African nation might have 20 stations or so, which isn't too much for one list.
There are 6702 in the file from which 2590 are already done because they are are in the US. A big portion of the rest is just countries (like Europe etc) Africa, Russia, Mexico are good candidates.
I could easily map everything from Canada to one country Canada, but it will be difficult to find the right station. What do you think
For the Canadian stations specifically, it should be possible to allocate a lot of them to provinces based on the annotations at the end of the "city" field, which are mostly the old conventional provincial abbreviations that everyone except the post office actually uses:
N. S. = Nova Scotia N. B. = New Brunswick PEI = Prince Edward Island Nfld = Newfoundland Que. = Quebec Ont. = Ontario Man. = Manitoba Sask. = Saskatchewan Alta. = Alberta B. C. = British Columbia N. W. T. = North-West Territories Y. T. = Yukon Territory
There's some variation in capitalization and punctuation, and locations in Nunavut are likely to marked as being in the NWT for historical reasons, but it's a start and should be able to assign most stations in the more populated areas to a province using a few regular expressions for matching.
Some of them can also be assigned automatically based on latitude/longitude ranges (north of a certain latitude mostly places things in the Territories, south of it in the provinces, and Québec and provinces westward *almost* adhere to specific longitudes, although there are some ambiguous zones—I'll see if I can get some numbers tonight).
The rest of them can be dropped in a bin labelled "Canada - Unknown" or the like and assigned whenever someone figures out where they are. (If we can find a way of making these assignments easy for a non-technical person to do, it might be helpful.)
This is mainly a concern for really large countries (Canada, U.S., Russia), where if you pick the wrong weather station by mistake, you could be getting forecasts for the other side of the continent.
E. Liddell
E. Liddell wrote:
What can I say? Canada is the second-largest country in the world. We have vast tracts of thinly populated land (and vast tracts of largely unpopulated land too), and weather stations are sprinkled all across that.
In a lot of cases, though, a breakdown by country is going to be sufficient. A small African nation might have 20 stations or so, which isn't too much for one list.
Yeah it looks like we need a TDE KWeather committee to rule out the division of the world :D
There are 6702 in the file from which 2590 are already done because they are are in the US. A big portion of the rest is just countries (like Europe etc) Africa, Russia, Mexico are good candidates.
I could easily map everything from Canada to one country Canada, but it will be difficult to find the right station. What do you think
For the Canadian stations specifically, it should be possible to allocate a lot of them to provinces based on the annotations at the end of the "city" field, which are mostly the old conventional provincial abbreviations that everyone except the post office actually uses:
N. S. = Nova Scotia N. B. = New Brunswick PEI = Prince Edward Island Nfld = Newfoundland Que. = Quebec Ont. = Ontario Man. = Manitoba Sask. = Saskatchewan Alta. = Alberta B. C. = British Columbia N. W. T. = North-West Territories Y. T. = Yukon Territory
There's some variation in capitalization and punctuation, and locations in Nunavut are likely to marked as being in the NWT for historical reasons, but it's a start and should be able to assign most stations in the more populated areas to a province using a few regular expressions for matching.
Some of them can also be assigned automatically based on latitude/longitude ranges (north of a certain latitude mostly places things in the Territories, south of it in the provinces, and Québec and provinces westward *almost* adhere to specific longitudes, although there are some ambiguous zones—I'll see if I can get some numbers tonight).
we are not writing a PhD here - we want v1.0 v2.0 etc. so lets start simple. I just don't feel like doing this myself. If you know where the name belongs to it would be much easier - to me the names do not say anything (not Canadian)
The rest of them can be dropped in a bin labelled "Canada - Unknown" or the like and assigned whenever someone figures out where they are. (If we can find a way of making these assignments easy for a non-technical person to do, it might be helpful.)
This is mainly a concern for really large countries (Canada, U.S., Russia), where if you pick the wrong weather station by mistake, you could be getting forecasts for the other side of the continent.
Yes, I was going to suggest for version 1 to map the stations to something like unknown. For example Mexico is done like this Mexico -> Mexico. This will become Mexico -> Unknown
I could of course preserve the already used associations.
thank you and regards
Stefan Krusche via tde-users wrote:
Yeah it looks like we need a TDE KWeather committee to rule out the division of the world :D
:-)))
BTW, good job, deloptes. Thank you so much!
Thank you for the motivation. I'm trying to match as many countries as possible. It feels like riding a dead horse https://en.wikipedia.org/wiki/FIPS_county_code
So this thing with the regions and countries might need revision.
On 2021-01-13 18:17:05 deloptes wrote:
J Leslie Turriff wrote:
Mapping to Canadian provinces wouldn't be too hard; where can I get the list of stations? Don't know about other countries; you'd have to ask people from those places for help.
https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/ kweather/kweather/data/nsd_cccc.txt
$ grep Canada nsd_cccc.txt
Can you create a simple mapping ( station_ID state_ID) and review the state_ids below, please?
[CA] name=Canada states=AB BC MB NB NF NS NT ON QC SK YK
Also PE and NU.
| New | Old (Eng., Fr) | Name | --- | ---------------- | --------------------- | AB | Alta, Alb | Alberta | BC | B C, C-B | British Columbia | MB | Man | Manitoba | NB | N B, N-B | New Brunswick | NF | Nfld,N L, T-N-L | Newfoundland | NS | N S, N-E | Nova Scotia | NT | N W T, T N-O | Northwest Territories | NU | Nvt, Nt | Nunavut | ON | Ont | Ontario | PE | P E I, I P E | Prince Edward Island | QC | Que, Qc, PQ, QU | Quebec | SK | Sask | Saskatchewan | YK | Yuk, Yn | Yukon
thanks
Leslie --
On 2021-01-13 18:17:05 deloptes wrote:
J Leslie Turriff wrote:
Mapping to Canadian provinces wouldn't be too hard; where can I get the list of stations? Don't know about other countries; you'd have to ask people from those places for help.
https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/ kweather/kweather/data/nsd_cccc.txt
$ grep Canada nsd_cccc.txt
Can you create a simple mapping ( station_ID state_ID) and review the state_ids below, please?
[CA] name=Canada states=AB BC MB NB NF NS NT ON QC SK YK
thanks ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt op.org
Not sure what to do with this one: | CWBR;71;049;B, R;;Canada;4;66-02N;091-50W;;;31;; 66°2'N, 91°50'W, according to mapquest, is in the middle of Siberia(!) and "B, R" isn't much of a name. :-) Any thoughts?
Leslie --
J Leslie Turriff wrote:
Not sure what to do with this one: | CWBR;71;049;B, R;;Canada;4;66-02N;091-50W;;;31;; 66°2'N, 91°50'W, according to mapquest, is in the middle of Siberia(!) and "B, R" isn't much of a name. :-) Any thoughts?
Just leave it and don't bother - incorrect or incomplete information is out of scope and will be ignored
can you please have a look at my last commits
I would appreciate a mapping such as
STATION_ID;STATUS;<REGION>_<STATE>;NAME
if the name of the station needs to be somehow corrected add it
so for example
CYFB;;CA_NT;Iqaluit, N. W. T. CYZF;;CA_NT;Yellowknife, N. W. T.
and if you know if the station is active, dead or decommissioned mark it as none (the empty field assumes status is unknown and station will be processed)
for example
ETNP;none;EU_DE;Hopsten;;; ETNR;none;EU_DE;Preschen;;;
exists in the original NSD file, but Stefan found out they are decomissioned
this will be enough to update the station_names.txt needed to generate stations.dat and weather_stations.desktop correctly
thank you in advance
On Friday 15 January 2021 04:15:26 am deloptes wrote:
I would appreciate a mapping such as
STATION_ID;STATUS;<REGION>_<STATE>;NAME
if the name of the station needs to be somehow corrected add it
so for example
CYFB;;CA_NT;Iqaluit, N. W. T. CYZF;;CA_NT;Yellowknife, N. W. T.
and if you know if the station is active, dead or decommissioned mark it as none (the empty field assumes status is unknown and station will be processed)
for example
ETNP;none;EU_DE;Hopsten;;; ETNR;none;EU_DE;Preschen;;;
exists in the original NSD file, but Stefan found out they are decomissioned
this will be enough to update the station_names.txt needed to generate stations.dat and weather_stations.desktop correctly
Hi deloptes,
Okay, again I admit I haven’t been following all of this thread. But it seems y’all are manually updating a file that seems like automation should ‘fix’ well enough. With the thought of doing that myself, would you mind attaching, or sending me direct, the starting file [1], any intermediate mapping type files [2], and the end result file [3] you currently have?
That should give me enough to bulk update everything so all you would need to do is a diff check and hopefully save you a lot of time.
Best, Michael
[1] This is the starting file? https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
[2] e.g. where are you grabbing the <REGION>_<STATE> from, what are all the flag field's codes, etc...
[3] station_names.txt ?
Michael via tde-users wrote:
[1] This is the starting file? https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
yes here however city names are wrongly spelled and needed correction (a). because we do not want to update the source file, we created station_names.txt (like a mapping or lookup)
[2] e.g. where are you grabbing the <REGION>_<STATE> from, what are all [the flag field's codes, etc...
this was originally in weather_stations.desktop, but we agreed it will be generated automatically and a skeleton called weather_stations.desktop.in will be the source. Later I found out it held the mapping to regions and states and also some additional information. Which bring us to the next point
[3] station_names.txt ?
I extracted now all information from the original weather_stations.desktop.in combined it with the old station_names.txt and produced a new station_names.txt. For now I am glad that the code produces much more advanced weather_stations.desktop and stations.dat files preserving the old and extending with new information. For example many stations from different US were not included although the state is in the nsd file. Others were added based on country information in the nsd file and this country having a section in the weather_stations.desktop.in.
TBH it will be sufficient if you map whatever station from nsd_cccc.txt to any region and state as listed in weather_stations.desktop.in (b) just double check before doing so if it is not already in station_names.txt (c) and if it is there, is it correct. If the region and state are not in weather_stations.desktop.in - the corresponding section(s) have to be created.
I hope it is not very confusing what I tried to explain
(a) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/issues/9 (b) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/k... (c) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/k...
On Friday 15 January 2021 01:47:31 pm deloptes wrote:
Michael via tde-users wrote:
[1] This is the starting file? https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
yes here however city names are wrongly spelled and needed correction (a). because we do not want to update the source file, we created station_names.txt (like a mapping or lookup)
[2] e.g. where are you grabbing the <REGION>_<STATE> from, what are all [the flag field's codes, etc...
this was originally in weather_stations.desktop, but we agreed it will be generated automatically and a skeleton called weather_stations.desktop.in will be the source. Later I found out it held the mapping to regions and states and also some additional information. Which bring us to the next point
[3] station_names.txt ?
I extracted now all information from the original weather_stations.desktop.in combined it with the old station_names.txt and produced a new station_names.txt. For now I am glad that the code produces much more advanced weather_stations.desktop and stations.dat files preserving the old and extending with new information. For example many stations from different US were not included although the state is in the nsd file. Others were added based on country information in the nsd file and this country having a section in the weather_stations.desktop.in.
TBH it will be sufficient if you map whatever station from nsd_cccc.txt to any region and state as listed in weather_stations.desktop.in (b) just double check before doing so if it is not already in station_names.txt (c) and if it is there, is it correct. If the region and state are not in weather_stations.desktop.in - the corresponding section(s) have to be created.
I hope it is not very confusing what I tried to explain
(a) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/issues/9 (b) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/ kweather/kweather/weather_stations.desktop.in (c) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/ kweather/kweather/data/station_names.txt
I think I've got that, it'll be this weekend.
Best, Michael
Michael via tde-users wrote:
I think I've got that, it'll be this weekend.
OK, not urgent, I just updated most of Africa and fixed some wrong mappings of countries to regions (see my other post as well). if you know GIT - check out the last version or simply download the files
data/nsd_cccc.txt data/station_names.txt genstations.pl weather_stations.desktop.in
the script can produce stations.dat and weather_stations.desktop in the working directory and warns what can not be mapped (see my other post).
perl ./genstations.pl data/nsd_cccc.txt data/station_names.txt ./weather_stations.desktop.in
It is not much work left and improvements can always be submitted.
What I like in particular with those stations is that they report the wind chill - which makes a big difference in the winter :) they just said it will be -16 but will feel like -30°C
thank you and have fun
On 2021-01-15 17:06:39 deloptes wrote:
Michael via tde-users wrote:
I think I've got that, it'll be this weekend.
OK, not urgent, I just updated most of Africa and fixed some wrong mappings of countries to regions (see my other post as well). if you know GIT - check out the last version or simply download the files
data/nsd_cccc.txt data/station_names.txt genstations.pl weather_stations.desktop.in
the script can produce stations.dat and weather_stations.desktop in the working directory and warns what can not be mapped (see my other post).
perl ./genstations.pl data/nsd_cccc.txt data/station_names.txt ./weather_stations.desktop.in
It is not much work left and improvements can always be submitted.
What I like in particular with those stations is that they report the wind chill - which makes a big difference in the winter :) they just said it will be -16 but will feel like -30°C
thank you and have fun
So. I spent ~6 hours making changes to nsd_cccc.txt, and now I find that I'm spinning my wheels, because there are tools available to make the changes.
Leslie --
On Friday 15 January 2021 10:52:24 pm J Leslie Turriff wrote:
So. I spent ~6 hours making changes to nsd_cccc.txt, and now I find that I'm spinning my wheels, because there are tools available to make the changes.
Hi Leslie,
Editing the source file (nsd_cccc.txt) to correct it so that it then can generate all the other files without errors is usually how it's done. Git does need to have the original nsd_cccc.txt somewhere for later updates, so the mapping is generally like this:
nsd_cccc.original.{date}.txt nsd_cccc.original.{date}.txt nsd_cccc.edited.{date}.txt nsd_cccc.edited.{date}.txt
e.g. nsd_cccc.edited.20210116-114406.txt
{date} is easier for follow up people, but many also use {revision} instead. I personally don’t like {revision} as it’s too easy to typo (see Ref:).
The last nsd_cccc.edited.txt is used by the process (perl ./genstations.pl) to generate the downstream files. The nsd_cccc.original.{date}.txt are kept so that any new nsd_cccc.txt can be diff’ed against the last nsd_cccc.original.{date}.txt to extract just what’s changed so only those changes need to be merged into a new nsd_cccc.edited. {date}.txt file.
You time has not been wasted! And thank you tons!
Best, Michael
Ref: alias pd='echo $(date +"%Y%m%d-%H%M%S")'
On 2021-01-15 13:47:31 deloptes wrote:
Michael via tde-users wrote:
[1] This is the starting file? https://tgftp.nws.noaa.gov/data/nsd_cccc.txt
yes here however city names are wrongly spelled and needed correction (a). because we do not want to update the source file, we created station_names.txt (like a mapping or lookup)
[2] e.g. where are you grabbing the <REGION>_<STATE> from, what are all [the flag field's codes, etc...
this was originally in weather_stations.desktop, but we agreed it will be generated automatically and a skeleton called weather_stations.desktop.in will be the source. Later I found out it held the mapping to regions and states and also some additional information. Which bring us to the next point
[3] station_names.txt ?
I extracted now all information from the original weather_stations.desktop.in combined it with the old station_names.txt and produced a new station_names.txt. For now I am glad that the code produces much more advanced weather_stations.desktop and stations.dat files preserving the old and extending with new information. For example many stations from different US were not included although the state is in the nsd file. Others were added based on country information in the nsd file and this country having a section in the weather_stations.desktop.in.
TBH it will be sufficient if you map whatever station from nsd_cccc.txt to any region and state as listed in weather_stations.desktop.in (b) just double check before doing so if it is not already in station_names.txt (c) and if it is there, is it correct. If the region and state are not in weather_stations.desktop.in - the corresponding section(s) have to be created.
I hope it is not very confusing what I tried to explain
(a) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/issues/9 (b) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/ kweather/kweather/weather_stations.desktop.in (c) https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/ kweather/kweather/data/station_names.txt
Well, I've been making my updates to nsd_cccc.txt, not having heard until now about station_names.txt :-(
Leslie --
J Leslie Turriff wrote:
Well, I've been making my updates to nsd_cccc.txt, not having heard until now about station_names.txt :-(
no problem - any source of information can be diagested :)
For Canada I need the station to state mapping - except the few that are already mapped
On Fri, 15 Jan 2021 00:40:43 -0600 J Leslie Turriff jlturriff@mail.com wrote:
Not sure what to do with this one: | CWBR;71;049;B, R;;Canada;4;66-02N;091-50W;;;31;; 66°2'N, 91°50'W, according to mapquest, is in the middle of Siberia(!) and "B, R" isn't much of a name. :-) Any thoughts?
It seems to be somewhere called Brown River, now in Nunavut.
https://wrcc.dri.edu/Monitoring/Stations/station_inventory_show.php?snet=sao...
E. Liddell
On Friday 15 January 2021 12:40:43 am J Leslie Turriff wrote:
On 2021-01-13 18:17:05 deloptes wrote:
J Leslie Turriff wrote:
Mapping to Canadian provinces wouldn't be too hard; where can I get the list of stations? Don't know about other countries; you'd have to ask people from those places for help.
Use AirNav? (Edit AirportsBase.org, below seems easier to sift.)
This gives you many* of British Columbia by City and Airport name
https://www.airnav.com/airports/ca/BC
* "The above list contains only public use airports and may be incomplete."
They also show having lists for Military Use, Private Use, Balloonports, Gliderports, Heliports, Seaplane bases, Ultralight flightparks
Balloonports? How cool...
Not sure what to do with this one: | CWBR;71;049;B, R;;Canada;4;66-02N;091-50W;;;31;;
66°2'N, 91°50'W, according to mapquest, is in the middle of Siberia(!) and "B, R" isn't much of a name. :-) Any thoughts?
AirNav says it doesn't exist? Maybe just not public? Anyway, digging deeper it seems to be in Brown River, Northwest Territories, Canada.
http://airportsbase.org/Canada/Northwest_Territories/Brown_River/Airport_of_...
[AirportsBase.org's] database has more 40000 records about world airports, including ICAO, IATA codes, geographical coordinates (location) of all airports in the world.
HTH, Michael
On 2021-01-15 09:15:12 Michael via tde-users wrote:
On Friday 15 January 2021 12:40:43 am J Leslie Turriff wrote:
On 2021-01-13 18:17:05 deloptes wrote:
J Leslie Turriff wrote:
Mapping to Canadian provinces wouldn't be too hard; where can I get the list of stations? Don't know about other countries; you'd have to ask people from those places for help.
Use AirNav? (Edit AirportsBase.org, below seems easier to sift.)
This gives you many* of British Columbia by City and Airport name
https://www.airnav.com/airports/ca/BC
- "The above list contains only public use airports and may be incomplete."
They also show having lists for Military Use, Private Use, Balloonports, Gliderports, Heliports, Seaplane bases, Ultralight flightparks
Balloonports? How cool...
Not sure what to do with this one: | CWBR;71;049;B, R;;Canada;4;66-02N;091-50W;;;31;;
66°2'N, 91°50'W, according to mapquest, is in the middle of Siberia(!) and "B, R" isn't much of a name. :-) Any thoughts?
AirNav says it doesn't exist? Maybe just not public? Anyway, digging deeper it seems to be in Brown River, Northwest Territories, Canada.
I discovered that the map search tool I was using doesn't translate °'"E|W properly into signed decimal degrees. My bad.
http://airportsbase.org/Canada/Northwest_Territories/Brown_River/Airport_of _Brown_River
[AirportsBase.org's] database has more 40000 records about world airports, including ICAO, IATA codes, geographical coordinates (location) of all airports in the world.
HTH, Michael
Leslie --
deloptes wrote:
we can automatically generate the locX entries for each region and country.
Does someone know what is the meaning of the positions ------ --- like DCZ013 dca in
loc0=Washington/Dulles KIAD DCZ013 dca
or for example IAZ099 or IAZ064
loc22=Fort\ Madison KFSW IAZ099 --- loc23=Iowa\ City KIOW IAZ064 --- loc24=Keokuk KEOK ------ ---
I do not see an easy way to generate this (from where?)
On 2021-01-08 18:35:01 deloptes wrote:
deloptes wrote:
we can automatically generate the locX entries for each region and country.
Does someone know what is the meaning of the positions ------ --- like DCZ013 dca in
loc0=Washington/Dulles KIAD DCZ013 dca
or for example IAZ099 or IAZ064
loc22=Fort\ Madison KFSW IAZ099 --- loc23=Iowa\ City KIOW IAZ064 --- loc24=Keokuk KEOK ------ ---
I do not see an easy way to generate this (from where?)
tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt op.org
I believe that this is the pertinent RFC-equivalent for this data: https://en.wikipedia.org/wiki/METAR#Example_METAR_codes
Leslie --
J Leslie Turriff wrote:
I believe that this is the pertinent RFC-equivalent for this data: https://en.wikipedia.org/wiki/METAR#Example_METAR_codes
Thank you! This helps understand the data. I came to a solution around that anyway, but it is good to know where it is coming from.
I'll put this into the README.
To which region belong Greenland?
[ME] name=Middle East
[US] name=United States
[CA] name=Canada
[MX] name=Mexico
[EU] name=Europe
[AF] name=Africa
[OZ] name=Australasia
[AS] name=Asia
[M_] name=Central and South America
[AT] name=Atlantic
deloptes wrote:
To which region belong Greenland?
[ME] name=Middle East
[US] name=United States
[CA] name=Canada
[MX] name=Mexico
[EU] name=Europe
[AF] name=Africa
[OZ] name=Australasia
[AS] name=Asia
[M_] name=Central and South America
[AT] name=Atlantic
in attachment what stations and countries are not mapped to any region and are not visible in the configurations
If someone with good Geography knowledge is willing to help mapping them
On Friday 15 January 2021 03:47:52 pm deloptes wrote:
[ME] name=Middle East
[US] name=United States
[CA] name=Canada
[MX] name=Mexico
[EU] name=Europe
[AF] name=Africa
[OZ] name=Australasia
[AS] name=Asia
[M_] name=Central and South America
[AT] name=Atlantic
Is that all the regions available to choose from?
in attachment what stations and countries are not mapped to any region and are not visible in the configurations
If someone with good Geography knowledge is willing to help mapping them
I can place most on that list, it'll be tomorrow though before I can look at it.
Best, Michael
On Friday 15 January 2021 03:39:13 pm deloptes wrote:
To which region belong Greenland?
North America, but since that and the Arctic don't exist below?, I'd use Atlantic..
[ME] name=Middle East
[US] name=United States
[CA] name=Canada
[MX] name=Mexico
[EU] name=Europe
[AF] name=Africa
[OZ] name=Australasia
[AS] name=Asia
[M_] name=Central and South America
[AT] name=Atlantic ____________________________________________________ tde-users mailing list -- users@trinitydesktop.org To unsubscribe send an email to users-leave@trinitydesktop.org Web mail archive available at https://mail.trinitydesktop.org/mailman3/hyperkitty/list/users@trinitydeskt op.org
On Saturday 16 January 2021 01:41:10 am deloptes wrote:
Michael via tde-users wrote:
North America, but since that and the Arctic don't exist below?, I'd use Atlantic..
OK, I put it to Atlantic. The question is if you are Greenlander, if you will be able to find it
Thinking about it, Mexico (United Mexican States actually and why is that a top level category?), Honduras, Panama, etc. are North America too.
I think we need a North America added to the region list, as that list is huge (and missing?):
https://en.wikipedia.org/wiki/List_of_sovereign_states_and_dependent_territo...
A bunch of those I would have called Atlantic as well (Bahamas?, Cuba?), but 'eh...
Where did the list of regions you posted earlier come from? “Central and South America” seems made up? This shows Central America as a sub-region of North America. What I’m guessing below is called “Middle East” is officially called “Western Asia.”
https://en.wikipedia.org/wiki/UN_M49
In that, it’s always best to get the mapping correct first, would it be better if I compiled (AKA stripped from wiki!) a list of regions to countries?
Using one level of delineation gives 6 regions:
Africa Antarctica Americas Asia Europe Oceania
Using the second level of delineation gives 17 regions. And shows that list is crap as it combines Central America, South America, and the Caribbean into “Latin America and the Caribbean.” Leave it to the UN to just outright insult people.
# # #
So, great,
https://www.thoughtco.com/official-listing-of-countries-world-region-1435153 https://ourworldindata.org/world-region-map-definitions
nobody seems to have any consistent world region definition. I don’t know, mostly I think I’d chuck the first region list and just go with countries by continent? At least it’s stable and no one is going to have to guess where their country is, also the second link above seems to have a .csv file of that already built. Then again, you’d probably need to change “Oceania” to “Australia and Oceania” (as Oceania is not a continent…).
So completely dazed and confused... Michael
Copy of original list for reference:
[ME] name=Middle East
[US] name=United States
[CA] name=Canada
[MX] name=Mexico
[EU] name=Europe
[AF] name=Africa
[OZ] name=Australasia
[AS] name=Asia
[M_] name=Central and South America
[AT] name=Atlantic
Michael via tde-users wrote:
Thinking about it, Mexico (United Mexican States actually and why is that a top level category?), Honduras, Panama, etc. are North America too.
I think we need a North America added to the region list, as that list is huge (and missing?):
https://en.wikipedia.org/wiki/List_of_sovereign_states_and_dependent_territo...
A bunch of those I would have called Atlantic as well (Bahamas?, Cuba?), but 'eh...
Where did the list of regions you posted earlier come from? “Central and South America” seems made up? This shows Central America as a sub-region of North America. What I’m guessing below is called “Middle East” is officially called “Western Asia.”
The list comes from the original file weather_stations.desktop. I think it was a pragmatic approach to group regions and states and make it easier to navigate in the configuration. Look at the configuration of kweather applet.
https://en.wikipedia.org/wiki/UN_M49
In that, it’s always best to get the mapping correct first, would it be better if I compiled (AKA stripped from wiki!) a list of regions to countries?
Using one level of delineation gives 6 regions:
Africa Antarctica Americas Asia Europe Oceania
Using the second level of delineation gives 17 regions. And shows that list is crap as it combines Central America, South America, and the Caribbean into “Latin America and the Caribbean.” Leave it to the UN to just outright insult people.
Yes I was thinking the same, but the code allows only 2 levels: Region -> State. Bigger countries that have many federal states appear as a region. I do not think this can be changed easily as the code is based on this concept.
So for now it would be enough to get it working in a meaningful state. Remember we started when Stefan complained Berlin Schönefeld is not in the list. Then we found out that only few stations are in the list, because the mapping for the others was missing in weather_stations.desktop
# # #
So, great,
https://www.thoughtco.com/official-listing-of-countries-world-region-1435153
https://ourworldindata.org/world-region-map-definitions
nobody seems to have any consistent world region definition. I don’t know, mostly I think I’d chuck the first region list and just go with countries by continent? At least it’s stable and no one is going to have to guess where their country is, also the second link above seems to have a .csv file of that already built. Then again, you’d probably need to change “Oceania” to “Australia and Oceania” (as Oceania is not a continent…).
So completely dazed and confused... Michael
Yes I can understand it - this is why I wrote we need a world committee of TDEs kweather :D I would go pragmatic - as it seems many people from Canada use TDE it would make sense to extend the list with stations for Canadian states.
If someone complains (like you) we could change also this and that. It is absolutely arbitrary how you group the states into regions, so we can remove/add regions or remap states to regions. What I would avoid is adding a new level, although it would make more sense, because then we could group them into continents or geographic regions -> countries -> states.
On the other hand if you go bottom up it makes sense to define a country as region and map stations to states only if there are too many stations to fit into a country alone ... but who is saying what is "too many"
So I too would say it makes sense to have Australasia split into Australia and for example Pacific Ocean or Oceania and Central and South America split into Central America and South America and some countries defined as regions like Brazil or Russia or even may be China - IMO it depends how many stations are listed there.
You can check for your self if you generate the two files and replace them on the file system - then navigate to kweathers configuration.
Should we try Central America and South America and may be North America for the countries that are not Mexico, USA and Canada?
This can easily be done ... I mean more or less without touching the code but just the mappings.
Copy of original list for reference:
[ME] name=Middle East
[US] name=United States
[CA] name=Canada
[MX] name=Mexico
[EU] name=Europe
[AF] name=Africa
[OZ] name=Australasia
[AS] name=Asia
[M_] name=Central and South America
[AT] name=Atlantic
On Saturday 16 January 2021 11:40:28 am deloptes wrote:
Yes I was thinking the same, but the code allows only 2 levels: Region -> State. Bigger countries that have many federal states appear as a region. I do not think this can be changed easily as the code is based on this concept.
It’s always the original developer’s fault! Which, while mostly a joke, really isn’t :( as they are the ones who inadvertently create constraints like this. So, okay, we only get two levels to play with, which definitely explains why certain countries are top level categories. Band-aids then...
If Greenland is the only country without an existing region then just stick it in Atlantic and be done.
If I find any other countries that don’t fit (tomorrow) I’ll bring it up, but otherwise, closing this?
Best, Michael
Michael via tde-users wrote:
It’s always the original developer’s fault! Which, while mostly a joke, really isn’t :( as they are the ones who inadvertently create constraints like this. So, okay, we only get two levels to play with, which definitely explains why certain countries are top level categories. Band-aids then...
If Greenland is the only country without an existing region then just stick it in Atlantic and be done.
If I find any other countries that don’t fit (tomorrow) I’ll bring it up, but otherwise, closing this?
in the attachment what is left unassigned - except the many (~700) stations from Canada.
I'm just considering the creation of Caribean region ... but also may be in the future.
deloptes wrote:
in the attachment what is left unassigned - except the many (~700) stations from Canada.
I'm just considering the creation of Caribean region ... but also may be in the future.
Looking at the list I realized most of these countries are in the carebean, so I added a mapping.
Based on what we discussed I created one region "North America" and removed regions Atlantic and Mexico. Greenland and Mexico moved to North America region.
so now only those countries in the attachment are not being mapped to any region and will not appear in the configuration
I also renamed Austrasia to Australia and Oceania as it seemed more appropriate given the content.
It would be great if you review the skeleton https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/k...
I am waiting for couple of days to see if someone will submit the mapping of the stations to the Canadian states and will ask for review and merge of the changes.
I am sure it looks 1000x better now
Stefan Krusche via tde-users wrote:
Good day!
Has anyone noticed that kweather applet doesn't update weather data anymore since some weeks?
More exactly, weather data for "Berlin-Tegel". Kweather comes obviously with a database from which you can choose your location (airport). For Berlin that used to be "Berlin-Tegel" and "Berlin-Tempelhof" (which is dead since 2009). I checked with "Braunschweig" and it shows actual current data.
Last time that happened the URL for retrieving the data had changed on the part of the server (noaa.gov). This URL was hardcoded in the source of the software and one of the developers had to change it (Tim did that) and it worked again since.
The National Oceanic and Atmospheric Administration of the U.S. Department of Commerce offers a lot of services on nws.noaa.gov where the local weather data used to be served as single html pages which were named according to their respective ICAO-Codes (airport IDs).
I suspect they again changed something, but I couldn't find anything relevant on their homepage in a couple of minutes.
"QCLCD ASCII Files are no longer available. Please use the Global-Hourly File Access link above."
I don't know what "QCLCD" means. I'm only guessing here anyway.
Maybe only kweather's database of available airport weather stations needs to be updated…
Hi, I just wanted to thank all of you and update you on the final status of this, because a broader audience was involved discussing here. I see the changes were scheduled for 14.0.10. "SlavekB added this to the R14.0.10 release milestone 14 hours ago" If some of you are interested in translating, the strings are also available for translation on Weblate. If you find grave misalignments of stations, countries, regions or other irregularities, raise a hand please. I came to the conclusion the grouping is best to follow a geographical and not political belonging, but even this is not easy for some regions.
On Monday 25 of January 2021 09:54:22 deloptes wrote:
Stefan Krusche via tde-users wrote:
Good day!
Has anyone noticed that kweather applet doesn't update weather data anymore since some weeks?
More exactly, weather data for "Berlin-Tegel". Kweather comes obviously with a database from which you can choose your location (airport). For Berlin that used to be "Berlin-Tegel" and "Berlin-Tempelhof" (which is dead since 2009). I checked with "Braunschweig" and it shows actual current data.
Last time that happened the URL for retrieving the data had changed on the part of the server (noaa.gov). This URL was hardcoded in the source of the software and one of the developers had to change it (Tim did that) and it worked again since.
The National Oceanic and Atmospheric Administration of the U.S. Department of Commerce offers a lot of services on nws.noaa.gov where the local weather data used to be served as single html pages which were named according to their respective ICAO-Codes (airport IDs).
I suspect they again changed something, but I couldn't find anything relevant on their homepage in a couple of minutes.
"QCLCD ASCII Files are no longer available. Please use the Global-Hourly File Access link above."
I don't know what "QCLCD" means. I'm only guessing here anyway.
Maybe only kweather's database of available airport weather stations needs to be updated…
Hi, I just wanted to thank all of you and update you on the final status of this, because a broader audience was involved discussing here. I see the changes were scheduled for 14.0.10. "SlavekB added this to the R14.0.10 release milestone 14 hours ago" If some of you are interested in translating, the strings are also available for translation on Weblate. If you find grave misalignments of stations, countries, regions or other irregularities, raise a hand please. I came to the conclusion the grouping is best to follow a geographical and not political belonging, but even this is not easy for some regions.
Just to add: Who uses deb packages from the PSB (r14.0.x~pre) or PTB (r14.1.0~pre) repositories already have updated packages available.
Thanks to that, I noticed that for some station names there are identical names for more stations - I saw it, for example, in Canada / Yukon - 2 × Dawson, 2 × Tuktoyaktuk. Other stations with the same name can be found in other regions. Maybe there would be a good idea to add some identification to the name, which station is which.
Cheers
Slávek Banko via tde-users wrote:
Thanks to that, I noticed that for some station names there are identical names for more stations - I saw it, for example, in Canada / Yukon - 2 × Dawson, 2 × Tuktoyaktuk. Other stations with the same name can be found in other regions. Maybe there would be a good idea to add some identification to the name, which station is which.
Hi, the case with Yukon - these are two different station ids with similar coordinates
CWON;--;---;Dawson Automatic Weather Reporting System ;;Canada;4;64-03N;139-09W;;;370;; CYDA;71;966;Dawson, Y. T.;;Canada;4;64-03N;139-08W;;;370;370;P
I removed "Automatic Weather Reporting System" from everywhere I found it in station_names.txt - this lead to duplicated names :/ . May be "Automatic Weather Reporting System" should be replaced with AWRS so that it distinguishes from the other
Same for Tuktoyaktuk
CYUB;71;954;Tuktoyaktuk ;;Canada;4;69-27N;133-01W;69-27N;133-01W;5;5; CZUB;71;985;Tuktoyaktuk Automated Reporting Station ;;Canada;4;69-26N;133-02W;;;6;;
But my assessment was that it would not make a big difference if you pick one or the other station anyway
Am Montag, 25. Januar 2021 schrieb deloptes:
the case with Yukon - these are two different station ids with similar coordinates
CWON;--;---;Dawson Automatic Weather Reporting System ;;Canada;4;64-03N;139-09W;;;370;; CYDA;71;966;Dawson, Y. T.;;Canada;4;64-03N;139-08W;;;370;370;P
Sometimes, as I found out with a couple of german stations, these are a civil airport and military air base at the same location.
For the german location I checked them. Most of them are listed on wikipedia.
Cheers, Stefan
Stefan Krusche via tde-users wrote:
Sometimes, as I found out with a couple of german stations, these are a civil airport and military air base at the same location.
For the german location I checked them. Most of them are listed on wikipedia.
Processing duplicates for solving this. Many were introduced from the weather_stations.desktop
This was a good catch Slavek and thank you Stefan it looks indeed in many cases the one is civil the other military or cargo
On Monday 25 of January 2021 14:26:11 deloptes wrote:
Slávek Banko via tde-users wrote:
Thanks to that, I noticed that for some station names there are identical names for more stations - I saw it, for example, in Canada / Yukon - 2 × Dawson, 2 × Tuktoyaktuk. Other stations with the same name can be found in other regions. Maybe there would be a good idea to add some identification to the name, which station is which.
Hi, the case with Yukon - these are two different station ids with similar coordinates
CWON;--;---;Dawson Automatic Weather Reporting System ;;Canada;4;64-03N;139-09W;;;370;; CYDA;71;966;Dawson, Y. T.;;Canada;4;64-03N;139-08W;;;370;370;P
I removed "Automatic Weather Reporting System" from everywhere I found it in station_names.txt - this lead to duplicated names :/ . May be "Automatic Weather Reporting System" should be replaced with AWRS so that it distinguishes from the other
Same for Tuktoyaktuk
CYUB;71;954;Tuktoyaktuk ;;Canada;4;69-27N;133-01W;69-27N;133-01W;5;5; CZUB;71;985;Tuktoyaktuk Automated Reporting Station ;;Canada;4;69-26N;133-02W;;;6;;
But my assessment was that it would not make a big difference if you pick one or the other station anyway ____________________________________________________
Yes, I assume that both stations will provide the same or very similar data. It just seems a little confusing there when the same name is listed repeatedly and there's no way to know which station is really meant. That's why it seemed like a good idea to differentiate the station names in some way. To make the name not much longer, we can add a short "(A)", for example.
Cheers
-
deloptes -
deloptes -
E. Liddell -
E. Liddell
-
Gene Heskett -
J Leslie Turriff -
Michael -
Slávek Banko -
Stefan Krusche -
William Morder