EuroBillTracker

Pole Doctor wrote:

Säbb wrote:Is it possible that NIG ignores big and small letters in the location section?

In my (humble) opinion, this should be dealt by EBT site when generating CSV files. Whenever you check a bill page, the location link redirects to the city page ; on this page, the name is always correctly typed. Generating CSV files with city names from the server would avoid this kind of issues, ignoring typos or mistypings. This could be an option to check on the "Download CSV file" page (replace city names by server names Y/N).
Talking about this, I even tend to think that city names should be automatically replaced whenever you enter a bill, which would avoid cheesy city spellings.

Just an idea

I tried to edit my csv-file, but every time an error occurs.

Säbb wrote:I tried to edit my csv-file, but every time an error occurs.

Have you tried editing it in the Notepad?

Säbb wrote:Is it possible that NIG ignores big and small letters in the location section?

This would be extremely desirable, see several other postings in this thread (example, example, example, example) as well as other parts of the forum, as well as mails to contact@ebt, where the reason for this fault in NIG statistics was sought on the side of EBT. Some people even asked to have a correctly rendered location (like "Frankfurt am Main") be corrected (!) into the wrong and finally obsolete version ("Frankfurt am main") because NIG was incapable of recognising the locations as identical.

Users have consistently been referred to this topic, but only a minority of them took the advice to post here. From the point of view of an active member of the support team, this is an unsatisfactory situation.

Pole Doctor wrote:In my (humble) opinion, this should be dealt by EBT site when generating CSV files.

Most definitely not. First of all, it is not a problem of EBT if a third-party software is case-sensitive while EBT is not (any more, since september). Secondly, there are practical matters:

Pole Doctor wrote:Whenever you check a bill page, the location link redirects to the city page ; on this page, the name is always correctly typed.

This is
(a) false, because there continues to be a large number of (rarely visited) city profiles where the name is wrong, probably for historical reasons,
(b) not an automatism but the result of manual work by volunteers who edit the names of city profiles if they can determine which form of capitalisation is correct which ...
(c) ... is not in all cases easy to decide, especially for "exotic" locations, and even more complicated by the fact that information available from common sources (Wikipedia, mapping websites, postal code websites) may be missing or contradictory.

In addition, there are competing ideas about what should or should not be summarised in city profiles, plus political/cultural/linguistic issues about the naming of city profiles in some regions; some of these discussions can be studied here.

Pole Doctor wrote:Talking about this, I even tend to think that city names should be automatically replaced whenever you enter a bill, which would avoid cheesy city spellings.

I believe this is completely out of question. The algorithm, which sorts new locations into city profiles, is not impeccable. While this does not constitute a major problem in general because the worst thing that can happen (when it passes unnoticed, which is rare) is typically a wrong dot (which will reported if it annoys anyone and/or if the note becomes a hit) and a little bit of statistical noise.
However, if the city spelling was "automatically corrected", the (possibly correct) version which was entered would be lost and there would be no way to re-assign the location to the profile where it should have belonged.

Zé da Silva wrote:

Säbb wrote:I tried to edit my csv-file, but every time an error occurs.

Have you tried editing it in the Notepad?

Thank you, it works

It looks like Gauss disliked the ideas I was expressing here. I don't want to be off-topic, but let me post some more elements :

Gauss wrote:

Pole Doctor wrote:In my (humble) opinion, this should be dealt by EBT site when generating CSV files.

Most definitely not. First of all, it is not a problem of EBT if a third-party software is case-sensitive while EBT is not (any more, since september).

NIG processes raw data as extracted from the .csv file. If the same city name is entered in two different ways on EBT and saved in two different ways in the .csv file, NIG will display it in two different ways. So far, this sounds logical to me.

Gauss wrote:

Pole Doctor wrote:Whenever you check a bill page, the location link redirects to the city page ; on this page, the name is always correctly typed.

This is
(a) false, because there continues to be a large number of (rarely visited) city profiles where the name is wrong, probably for historical reasons,

In my (short) experience, this proved to be true in 99.9% of the cases. Every single city in which I entered notes (some of which were remote, upper-valleys villages I can consider to be rarely visited, and not only by EBTers) was correctly labeled. For the remaining 0.01 % ...

Gauss wrote:(b) not an automatism but the result of manual work by volunteers who edit the names of city profiles if they can determine which form of capitalisation is correct which ...

... I just emailed the link to contact@ebt to signal the case. Please notice I did not REQUEST anything. Anyway, the name was kindly and remarkably quickly corrected. I can imagine that the support team has (many) other things to do than correct city name typos. In this case, I would suggest a volunteer-call for this task ; I'd be one of them.

Gauss wrote:(c) ... is not in all cases easy to decide, especially for "exotic" locations, and even more complicated by the fact that information available from common sources (Wikipedia, mapping websites, postal code websites) may be missing or contradictory.

This is remarkably not true, at least in one case. Talking about what I know best, French cities spelling obey to state-driven writing conventions, a summary of which can be found here. To be truly honest, I discovered this rules through EBT, because the way cities were labeled puzzled me, and I discovered they were in the right way. I don't know about other countries, but your remark about Frankfurt am Main makes me think this is not a French exception.

Once again, let me make things clear : I'm NOT requesting anything. NIG just points out that cities can be referred to with different names in EBT. That's NOT criticism, just a remark.

As I said :

Pole Doctor wrote: Just an idea

Please take it as it was : an idea. Period.

I have updated my users_global.txt file - including the top 500 of last night.

I've got a question regarding the NIG tool, most likely this has already been answered.

What's the problem that NIG cannot handle german "Umlauts" correctly?
For example, in the "Locations" part of the generated stats, I have a lot of missing "Umlauts".

Also, I have an improvement idea.

I have a game running, the "Austrian Short Code Game". In a nutshell, the game is about
having all short codes for all ever printed Austrian (serial starting with the letter "N") bills.
I have plans to extend the game to all european countries and their notes.

Although the NIG tool already has an option do generate the stats of all entered short codes
("Detailed short code table"), it would be much easier to spot missing short codes and typos,
if there were a line for any possible short code combination for a given country, regardless if
the user already has a note for this special short code or not.

For example, let's take Austria. For F/N bills, the following short codes are possible:
F001A1-F005J6; in summary 300 different short codes.

My suggestion would be to have all these 300 different codes printed in the section
"Lowest and Highest Short Code" of the generated stats, regardless if the user already
has a bill with one of the short codes or not.

Maybe you can adopt the current "Detailed short code table" option,
or you could also offer another option, for example "Complete short code table".

What are your thoughts about my suggestion?
Regards, Franz

-STAR- wrote:What's the problem that NIG cannot handle german "Umlauts" correctly?
For example, in the "Locations" part of the generated stats, I have a lot of missing "Umlauts".

Oh, NIG handles umlauts correctly, it's the EBT-Tool that doesn't (an encoding issue, EBT was at some point converted to use UTF 8 strings, while the EBT-Tool internally still converts them to (I think) ISO-8859-1 strings). So when you download your note and hit data via the EBT-Tool, or use the EBT-Tool after you downloaded the data separately, NIG can't help but to do the old "garbage in, garbage out".
Solution (for the time being, the EBT-Tool is just being completely rewritten): download your hit and note data directly from the EBT site via your web browser, and don't use the EBT-Tool before you use NIG on those data.

klapotec wrote:Solution (for the time being, the EBT-Tool is just being completely rewritten): download your hit and note data directly from the EBT site via your web browser, and don't use the EBT-Tool before you use NIG on those data.

Many thanks for this tip - the same problem here, which is now solved

Hello Bobtail,

I see, that you have created your personal stats with NIG version 1.64. When will it be available for download? Especially the Trivia page looks better with the new layout of the combination bingo.

marty44

Hi!

first of all i have to say that this prog is really great!!
^^

could it be that the "line" between hitlocations doesn't work in Google earth?

after exporting the data to google earth there is neither a connection if i uncheck the funny color box nor if i check the box...

is this a known prob or am I the only one ?!?
^^
would be quite cool, if you could manage this prob...

greets
fab

Unfortunately, the newest version of Google Earth doesn't like the format of the KML file NIG creates and that's why the lines won't show up.

Maybe in October I'll have time to do something about this.

ok
np
thx for the quick answer...

yli (26-2-2007) wrote:After some days of working through my data I complete a NIG codes file for Luxembourg

It contains :

3 Districts, 12 Cantons and 116 Municipalities

I used the languages : French (German) | Letzebuergian

Is this NIG codes file nowadays in the original ZIP file ?
I didn't saw it at the NIG stats page listed with extra NIG codes files

Some days ago I entered a G008/P032 with Trichet signature, but NIG consider it as a Duisenberg note.
Maybe Bobtail can solve this bug in the next update?
Thanks