On Wednesday 06 January 2021 06:14:45 am Stefan Krusche via tde-users wrote: zip, nada, nothing "zip help" means roughly "doesn't help at all." "zip all" is another English (US?) derivitive roughtly equals "nothing." HTH, Michael

On Wednesday 06 January 2021 11:54:26 Stefan Krusche via tde-users wrote: 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. Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>

On Thursday 07 January 2021 04:04:29 Stefan Krusche via tde-users wrote: 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 -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>

On Wed, 06 Jan 2021 20:52:13 +0100 deloptes &lt;deloptes(a)gmail.com&gt; 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. 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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 Mittwoch, 6. Januar 2021 schrieb E. Liddell via tde-users: That's right. It is the same, enhanced and modernized airport. 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). 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

E. Liddell wrote: 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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: 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 -- Slávek

On Friday 08 of January 2021 01:38:42 deloptes via tde-users wrote: 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 -- Slávek

Slávek Banko via tde-users wrote: 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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 Wednesday 06 January 2021 15:59:04 E. Liddell via tde-users wrote: 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

E. Liddell wrote: 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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: 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 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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 Stefan Krusche via tde-users: 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

On Thursday 07 January 2021 05:56:46 deloptes via tde-users wrote: 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 -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) If we desire respect for the law, we must first make the law respectable. - Louis D. Brandeis Genes Web page <http://geneslinuxbox.net:6309/gene>

On Thursday 07 January 2021 04:10:11 Stefan Krusche via tde-users wrote: 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

Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users: That is exactly the page I was talking about. Cheers, Stefan

On Thursday 07 January 2021 05:40:12 deloptes via tde-users wrote: 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

Stefan Krusche via tde-users wrote: 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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

Dear Bill, Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users: 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. Can you configure kweather to show any station's data?! Or do all fail? Kind regards, Stefan

William Morder via tde-users wrote: I have 7 stations and all of them show the information :/ --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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 William Morder via tde-users: This puzzle only you can save! ;-) Glad it works for you again. Stefan

Am Donnerstag, 7. Januar 2021 schrieb William Morder via tde-users: 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

Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users: 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. 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

Am Donnerstag, 7. Januar 2021 schrieb deloptes via tde-users: OK. Stefan

On Thursday 07 of January 2021 10:53:21 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. Cheers -- Slávek

Stefan Krusche via tde-users wrote: 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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: I'm studying TQt3 for the past couple of years. The biggest problem is time - or better lack of time. 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). 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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: 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(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)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: 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

On Friday 08 January 2021 11:11:18 deloptes 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. Bill

On Friday 08 January 2021 16:38:44 deloptes wrote: 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

On Saturday 09 January 2021 08:14:49 am Stefan Krusche via tde-users wrote: 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

Stefan Krusche via tde-users wrote: 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

J Leslie Turriff wrote: https://tgftp.nws.noaa.gov/data/nsd_cccc.txt https://mirror.git.trinitydesktop.org/gitea/TDE/tdetoys/src/branch/issue/9/… $ 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

E. Liddell wrote: 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

E. Liddell wrote: Yeah it looks like we need a TDE KWeather committee to rule out the division of the world :D 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) 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: 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: 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 --

On Friday 15 January 2021 04:15:26 am deloptes wrote: 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 ?

On Friday 15 January 2021 01:47:31 pm deloptes wrote: I think I've got that, it'll be this weekend. Best, Michael

On 2021-01-15 17:06:39 deloptes 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. Leslie --

On 2021-01-15 13:47:31 deloptes wrote: Well, I've been making my updates to nsd_cccc.txt, not having heard until now about station_names.txt :-( Leslie --

On Fri, 15 Jan 2021 00:40:43 -0600 J Leslie Turriff &lt;jlturriff(a)mail.com&gt; wrote: It seems to be somewhere called Brown River, now in Nunavut. https://wrcc.dri.edu/Monitoring/Stations/station_inventory_show.php?snet=sa… E. Liddell

On 2021-01-15 09:15:12 Michael via tde-users wrote: I discovered that the map search tool I was using doesn't translate °'"E|W properly into signed decimal degrees. My bad. Leslie --

On 2021-01-08 18:35:01 deloptes wrote: I believe that this is the pertinent RFC-equivalent for this data: https://en.wikipedia.org/wiki/METAR#Example_METAR_codes Leslie --

On Friday 15 January 2021 03:47:52 pm deloptes wrote: Is that all the regions available to choose from? I can place most on that list, it'll be tomorrow though before I can look at it. Best, Michael

Michael via tde-users wrote: OK, I put it to Atlantic. The question is if you are Greenlander, if you will be able to find it

Michael via tde-users wrote: https://en.wikipedia.org/wiki/List_of_sovereign_states_and_dependent_territ… 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. 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 https://www.thoughtco.com/official-listing-of-countries-world-region-1435153 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.

Michael via tde-users 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.

Slávek Banko via tde-users wrote: 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

Stefan Krusche via tde-users wrote: 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