ServInfo

[Andre Campbell 970821]

When is the next Servinfo coming out.

I heard about an update for it, but then I tried the update and it barely did anything.

[Joshua Greenway 937147]

I take it you mean the one authored by Mark Severn?

 

If so, then I reall don't have any idea what you're talking about. It adds countless airlines to the database, it also corrects certain FIR boundaries and also the callsign that is displayed in the program.

 

I worked closely with Mark when he was developing this addition and his countless hours of research have attracted nothing but positive comments until yours.

 

Correct me if you weren't reffering to Mark - I'm just not aware of any other updates.

[Camilo Bernal 893284]

just my 2 cents,

 

3.5 years and 20 versions after it's first release ServInfo has reached the end of it's development cycle. Version 2.03 is the last ServInfo released version.

 

During these years I have been answering every single mail I received regarding ServInfo bugs, feature requests, installation problems etc. Unfortunately, due to my very limited free time I am no longer in a position to offer this support anymore.

 

Michael Frantzeskakis

 

source: http://www.avsim.com/hangar/utils/servinfo/support.htm

 

The intention of this forum if to compile all the database updates generated in VATSIM for the past 3 years not to add any more features to the program.

 

best regards,

[Ross Carlson]

Perhaps Andre was expecting some feature changes, and that's why he says he didn't notice anything.

 

This forum will be used to discuss updating the ARTCC/FIR boundaries database, and the callsign alias database used by ServInfo to show online ATC. It will also be used to discuss the process of adding VA logos to the ServInfo list.

 

I will soon be sending out an email NOTAM to all controllers at or above the C1 level, asking them to send me updated data. We will be compiling that data into a single update package, similar to the one Mark Severn published, and offering it for download as an "Official VATSIM ServInfo Update". Alex Stjepanovic will be handling collating the data, and I believe he will be using Mark Severn's data files as a base, but I'm not 100% sure about that.

[Paul O'Donnell 969350]

That's great to hear Ross.

Now to dig out the updates I've made to my Servinfo data file.

[Alex Stjepanovic 963114]

Basically there won't be any more actual official-ServInfo-versions. VATSIM is going to do updates to it, by VATSIM for VATSIM. The author Michael Frantzeskakis has stopped developing it in 2005, therefore any network, VA etc is free to update it for themselves as they like.

[Luke Kolin]

VATSIM is going to do updates to it, by VATSIM for VATSIM.

 

About time. Thanks for doing it right!

 

Cheers!

 

Luke

[Thomas Purbs 943647]

I will soon be sending out an email NOTAM to all controllers at or above the C1 level, asking them to send me updated data. We will be compiling that data into a single update package, similar to the one Mark Severn published, and offering it for download as an "Official VATSIM ServInfo Update". Alex Stjepanovic will be handling collating the data, and I believe he will be using Mark Severn's data files as a base, but I'm not 100% sure about that.

But we have to realize, that Servinfo will never really show, which sector is controlled, because it only uses the first 4 letters of the callsign (http://forums.vatsim.net/viewtopic.php?t=22698).

[Dominic Russell 866138]

Nice to see some updating of servinfo... info (is that a good sentence!?) I know servinfo the program is not being updated but good to see there is still some movements in regards to its database.

 

I use Servinfo all the time it in my personal opinion its the best tool out of its kind (personal preference)

 

Thanks

 

Dom

[Alex Stjepanovic 963114]

I will soon be sending out an email NOTAM to all controllers at or above the C1 level, asking them to send me updated data. We will be compiling that data into a single update package, similar to the one Mark Severn published, and offering it for download as an "Official VATSIM ServInfo Update". Alex Stjepanovic will be handling collating the data, and I believe he will be using Mark Severn's data files as a base, but I'm not 100% sure about that.

But we have to realize, that Servinfo will never really show, which sector is controlled, because it only uses the first 4 letters of the callsign (http://forums.vatsim.net/viewtopic.php?t=22698).

 

I'm not too sure what you mean by "it only uses the first 4 letters of the callsign", but as Norman and Kirk have said in that other post you provided the link to, there is a way to use the alias function. Just look at US, Australia and UK as the prime examples. They have created all sorts of sub sectors using the function and it has worked perfectly for years

 

From servinfo.dat:

 

Airports Section

----------------

Format = XXXX/Airport name/Coord/Alias/YYYY/t

XXXX : The 4-letter (uppercase) ICAO code of the airport

Coord : The airport coordinates as degrees in decimal format entered as

sXXX.XXXXXXsYYY.YYYYYY where s is + or - XXX.XXXXXX is the latitude and YYY.YYYYYY is

the longitude. Signs are obligatory, no spaces allowed, lenght must be always 22

characters long.

Alias : An alternative code that controllers use when logging in a control position of this

airport (as Ground, Tower, Approach etc. without the _V and the _GND, _TWR or _APP

part e.g. CHI if controllers at Chicago-O'Hare frequently log in as CHI_V_APP

instead of KORD_V_APP)

YYYY : The 4-letter (uppercase) ICAO code of the FIR (or ARTCC for the USA) within which the

airport lies. This code must be one of the codes contained in the "Controls Section".

t : The index of the time zone (as defined in the "Time Zones" section) the airport belongs to.

This field is also used to identify dummy airport entries, when set to 0

 

The Alias part is optional, but if omitted the delimiter must remain (e.g. XXXX/Name/Coord//YYYY/t)

The time zone index (t) is ommited when the whole of the airport's country lies in one time zone.

In this case this time zone is entered in the "Countries" section.

More than one line might be used for each airport if more than one aliases are used

 

Controls Section

-----------------

Format = XXXX/Control position name/Alias/ZZZZ

XXXX : The 4-letter (uppercase) ICAO code of a _CTR position

Alias : An alternative code that controllers use when logging in that position without the

_V and the _CTR part, e.g. TOR if controllers at Toronto Center frequently log in as

TOR_V_CTR instead of CZYZ_V_CTR)

ZZZZ : If the CTR position is not refering to a FIR (or ARTCC for the USA) then ZZZZ is the

4-letter (uppercase) ICAO code of the FIR (or ARTCC) the CTR position belongs to.

This code must be one of the XXXX fields contained in the "Controls Section".

If the position is not a FIR/ARTCC and it does not belong to any other FIR/ARTCC

then "0000" should be given.

[Daniel Doorgakant]

Alex Stjepanovic will be handling collating the data

 

Alex eh? Well at least I dont have to submit that much, as Alex knows what needs putting in for meh.

[Alex Stjepanovic 963114]

You should still submit stuff anyhow...just to be sure everything that needs updating gets updated

[Daniel Doorgakant]

You should still submit stuff anyhow...just to be sure everything that needs updating gets updated

 

Yep, The things you were never told

 

It seems like a long task, Great Effort Guys!

[Thomas Purbs 943647]

Alex, the alias seems only to work, if you have different prefixes...

e.g. TOR if controllers at Toronto Center frequently log in as

TOR_V_CTR instead of CZYZ_V_CTR)

We have the problem, that EDWW_E_CTR isn´t the same as EDWW_CTR, and EDMM_E_CTR isn´t like EDMM_CTR.

I also tried to get a solution by using the alias feature, but it didn´t work.

 

For our airspace, the only thing we can do is to display EDWW and EDMM as a whole sector, but that is not what we really have, because it may only be the former EDBB sector, which callsign doesn´t exist anymore. In Dolomynum we were able to display it correct, so that is the tool we prefer in this case...

In my opinion Servinfo is a dying tool.

[Stephan Boerner 945550]

In my opinion Servinfo is a dying tool.

As long as it's the only tool really useful for controllers and not only for pilots, I'm glad it's not dying but being updated. Doesn't keep pilots from using DLMN.

[James O Grady 904153]

In my opinion Servinfo is a dying tool.

As long as it's the only tool really useful for controllers and not only for pilots, I'm glad it's not dying but being updated. Doesn't keep pilots from using DLMN.

 

Dolomynum is as useful to controllers as ServInfo is, as is vroute, however, the problem with vroute is its not updated, which takes away from it's great functionality because for something like this you need an up-to-date product first, and a glossy one second.

[Wycliffe Barrett]

seamus

 

What do you mean vroute is not updated. Michal did loads of updates before he went off on vacation and will continue to do so when he gets back. I believe he is on vacation at the moment. Some of these guys who provide stuff for free do have lives you know.

[James O Grady 904153]

seamus

 

What do you mean vroute is not updated. Michal did loads of updates before he went off on vacation and will continue to do so when he gets back. I believe he is on vacation at the moment. Some of these guys who provide stuff for free do have lives you know.

 

Jaysus relax Wycliffe! I know hes done a lot of updates for vroute but I mean updates to navigation data and sectors, which vroute is not up-to-date on. Am I not allowed to comment on a piece of software just because its free?

[Daniel Doorgakant]

ServInfo is not a dying tool

 

I've used ServInfo since I cant remember, tried vroute but the functionality of Servinfo is conveniant and easy. DLMN is also a good tool. And vroute, In my opinion, is only good for bookings.

 

So this work on ServInfo is muchly appreciated by alot of people

[Stephen Donnelly]

ServInfo is not a dying tool

 

I've used ServInfo since I cant remember, tried vroute but the functionality of Servinfo is conveniant and easy. DLMN is also a good tool. And vroute, In my opinion, is only good for bookings.

 

So this work on ServInfo is muchly appreciated by alot of people

 

Sentiments echoed. Servinfo has so much more functionality than any other tool, and presents it in the best format. The only thing it's missing is the booking and the individual profiles that only vroute offers.

[Alex Stjepanovic 963114]

Alex, the alias seems only to work, if you have different prefixes...

e.g. TOR if controllers at Toronto Center frequently log in as

TOR_V_CTR instead of CZYZ_V_CTR)

We have the problem, that EDWW_E_CTR isn´t the same as EDWW_CTR, and EDMM_E_CTR isn´t like EDMM_CTR.

I also tried to get a solution by using the alias feature, but it didn´t work.

 

For our airspace, the only thing we can do is to display EDWW and EDMM as a whole sector, but that is not what we really have, because it may only be the former EDBB sector, which callsign doesn´t exist anymore. In Dolomynum we were able to display it correct, so that is the tool we prefer in this case...

In my opinion Servinfo is a dying tool.

 

Ah that. Well no FIR in the world can display sub sectors separately on SI. If it's the case of using the callsign over what now is a former FIR as you say, I can suggest two things:

 

1. That you submit me the changes to the FIR itself, and make EDWW and EDBB into one large EDWW. That way you can use the same prefix.

2. Change the name in this case Berlin FIR to something like "Bremen East(Formerly Berlin) FIR", but leave the EDBB code so ServInfo can recognize it as a different sector, and use an IATA code for EDDW(Or whatever primary airport or station you wish) and alias it to EDBB. That way, EDWW and the EDWW East are shown seperately.

 

That said, I have a question about this. Is the former EDBB now a part of one large EDWW FIR?

Cause if it is, you should really just make it one large FIR on ServInfo and use whatever sub-sector callsigns when logging-in. You should do this for two reasons:

 

1. This is what the rest of the world does, and it wouldn't be fair on everyone else to have to use sub-sector callsigns over the whole FIR, while you got to do split them up and show individual sectors.

2. There is no specific time of when the next VATSIM SI Update will come through, so if you change your setorization in the meanwhile, you'll be once again stuck with using out of date callsigns. If you have one large FIR, you can light it up and use whatever -new- sub-sector callsign you want.

[Thomas Purbs 943647]

Ah that. Well no FIR in the world can display sub sectors separately on SI. If it's the case of using the callsign over what now is a former FIR as you say, I can suggest two things:

 

1. That you submit me the changes to the FIR itself, and make EDWW and EDBB into one large EDWW. That way you can use the same prefix.

2. Change the name in this case Berlin FIR to something like "Bremen East(Formerly Berlin) FIR", but leave the EDBB code so ServInfo can recognize it as a different sector, and use an IATA code for EDDW(Or whatever primary airport or station you wish) and alias it to EDBB. That way, EDWW and the EDWW East are shown seperately.

 

That said, I have a question about this. Is the former EDBB now a part of one large EDWW FIR?

Cause if it is, you should really just make it one large FIR on ServInfo and use whatever sub-sector callsigns when logging-in. You should do this for two reasons:

 

1. This is what the rest of the world does, and it wouldn't be fair on everyone else to have to use sub-sector callsigns over the whole FIR, while you got to do split them up and show individual sectors.

2. There is no specific time of when the next VATSIM SI Update will come through, so if you change your setorization in the meanwhile, you'll be once again stuck with using out of date callsigns. If you have one large FIR, you can light it up and use whatever -new- sub-sector callsign you want.

In reality EDBB was split into two parts, the southern part went to Munich EDMM, and the northern part went to Bremen EDWW. But here in VATSIM we still have the EDBB FIR, and to make the callsigns more realistic, we split our sector into EDWW_E_CTR and EDMM_E_CTR. It is similar to EDFF and EDLL, which are in real now EDGG (and it is the same as they do at I***).

In the moment there are no intentions to combine the two EDWW sectors and two EDMM sectors as one, and in our mind there is no need to do so, because in real life you also have these sectors, and with DLMN we have a tool, which can display it.

 

All we can do at Servinfo is to display EDMM and EDWW as totally covered, but that is normally not what we are covering. Another callsign change can´t be the solution.

[Alex Stjepanovic 963114]

In reality EDBB was split into two parts, the southern part went to Munich EDMM, and the northern part went to Bremen EDWW.

 

Right gotcha. I'm actually just after looking at VACC-SAG web site, and it looks like EDMM goes far more north(Cutting a chunk of EDFF http://www.vacc-sag.org/images/sag_area.gif) than ServInfo shows it?

 

In reality EDBB was split into two parts, the southern part went to Munich EDMM, and the northern part went to Bremen EDWW. But here in VATSIM we still have the EDBB FIR...

 

In the moment there are no intentions to combine the two EDWW sectors and two EDMM sectors as one, and in our mind there is no need to do so, because in real life you also have these sectors, and with DLMN we have a tool, which can display it.

 

I'm confused. So all the old FIRs still exist, but it's only who controls different parts that has changed, or has their airspace been re-delegated to other FIRs altogether?

[Dieter Brugger 810604]

Alex, maybe I can be a bit helpful here.

 

The former EDBB (Berlin) FIR has been divided into two sectors. The northern sector ist now logging in as EDWW_E_CTR and the southern sector as EDMM_E_CTR. Both sectors only cover the respective part of the former EDBB FIR.

 

So when EDWW_CTR and EDWW_E_CTR are online, Servinfo must show the original EDWW Sector and the EDWW_E_CTR (former northern part of EDBB FIR) as two seperate sectors.

 

Same applies to EDMM.

 

All this is according to real life sectorization.

 

Hope this helps.

[Daniel Doorgakant]

Right so all you'd need to do is extend both FIRs (in the data file) out into the EDBB FIR.