Page 10 of 13 FirstFirst ... 89101112 ... LastLast
Results 91 to 100 of 121

Thread: Discussion about Flightradar24 database

  1. #91
    Passenger
    Join Date
    Mar 2016
    Posts
    16
    Could someone please let me know the correct discussion for reporting ground vehicles which are showing up as an aircraft icon instead of the grey ground vehicle.
    Thank you.

    Feeding FR24 since 11/09/13

  2. #92
    Flight attendant
    Join Date
    Mar 2019
    Posts
    93
    Database sub-forum > data errors.

  3. #93
    Passenger
    Join Date
    Mar 2016
    Posts
    16
    Nice one thanks hexfan.

    Feeding FR24 since 11/09/13

  4. #94
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,002
    Some translations from Peru registry regarding the changes someone just submitted. Looks like they too use suffix somewhat frivolously

    -T and -P

    But as no registry lookup we can't tell if the labels on aircraft are official (no spaces) or registered with -. Jetphotos go with - despite no gaps on wing.

    Sent from my EML-L09 using Tapatalk
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

  5. #95
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,002
    Quote Originally Posted by nomad77 View Post
    So I asked this question before but didn't see a response.

    Are you saying that when a new aircraft is assigned a previously assigned reg/code, that aircraft information
    should be posted as NEW data and not a change to the existing information. If this is the case do we end up
    with two aircraft sharing the same code in the DB. Should this happen how does the system know which aircraft
    is the current one.
    Unsure. But I believe that is how it ends up being handled. Every change is likely a 'new' entry from his perspective.

    I have no visibility to the structure of the DBase myself to know. I think the entry point Maxi sees is quite basic (hex, airframe details and reg etc) And it's the archived tables that do the magic work when submitted in the background.

    A well coded one, will have a master table with HEX and current in-air flight details being recorded and an auto generated ID.
    Another with airframe details to tie to the hex via lookup and a similarly auto generated ID and timestamp which is cross referenced for every in-air entry and or flight log associated with a separate Key ID (hex).

    I would imagine the data is dumped to an archived table every so often that can then lookup the historic details and using the paired generated ID with changed data timestamp get the different recorded data/variables.
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

  6. #96
    Captain
    Join Date
    Feb 2013
    Posts
    6,052
    Quote Originally Posted by Oblivian View Post
    Unsure. But I believe that is how it ends up being handled. Every change is likely a 'new' entry from his perspective.

    I have no visibility to the structure of the DBase myself to know. I think the entry point Maxi sees is quite basic (hex, airframe details and reg etc) And it's the archived tables that do the magic work when submitted in the background.

    A well coded one, will have a master table with HEX and current in-air flight details being recorded and an auto generated ID.
    Another with airframe details to tie to the hex via lookup and a similarly auto generated ID and timestamp which is cross referenced for every in-air entry and or flight log associated with a separate Key ID (hex).

    I would imagine the data is dumped to an archived table every so often that can then lookup the historic details and using the paired generated ID with changed data timestamp get the different recorded data/variables.
    While I am no Guru on data bases I've also understood that each set of records
    needs a unique identifier in order to access that set of records. Since the
    mode S code is unique to one set of records it should be used to access that set

    Using this logic, a new set of records should be created each time a new mode S
    code is entered. Once created any change to the data inside that set of records
    should be made by accessing the records via the unique identifier (mode S code).

    If the data base does not check for duplicates, but simply allows a new set of
    records including a duplicate mode S code then the situation must arise where
    a choice must be made between two or more duplicate records.

    My concern is that if I post information on a new aircraft which uses a previously
    assigned Reg/Mode S, that will be entered as a new record thus leading to
    duplication.

    Ultimately it makes no difference to me where the information is posted, I am
    simply trying to do the right thing.

  7. #97
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,002
    Keys tend to be unique (not allow duplicates), but you can also have searchable indexes. Such as Registration which will also find the entire row from multi tables using joins or AND statements to validate.

    As we have seen it's somehow possible to have 2 airframes with the same mis-coded HEX OR reg, that tends to indicate there is not a single index in use but a number of them/tables.

    If you also take time tags into account, you can to an extent have duplicates and find records based on time order.

    If it is like the local SQL dumping I do, there is a historic table. And there is an in-air table. Each 'leg' of a hex has it's own 'flight' ID. So it can be apparent when searching for a HEX, to see where it did various legs under different registrations over the time periods.

    Similarly here, looking up a registration could conceivably give you all the flights it's done. Including under different HEX or owner. Whereas if you search by HEX, it may only show the current association. (and possibly the reason behind them not associating HEX with region)

    Without seeing what Maxi has to fulfill, it's a big unknown.
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

  8. #98
    Super Moderator
    Join Date
    May 2011
    Location
    T-NZCH1, PP:PH New Zealand
    Posts
    5,002
    Of note is also the description they edited in the first posts. Which depending on interpretation isn't clear

    Errors:
    If you find any errors in FR24 aircraft database you can post the errors and correct data here. It could be wrong registration, wrong plane type, wrong airline or any other aircraft data error.

    New/Added:

    Every day there are new deliveries and old aircraft getting new owners, so new information have to be added into database daily.
    Posts not to be taken as official support representation - Just a helpful uploader who tinkers

  9. #99
    Captain
    Join Date
    Feb 2013
    Posts
    6,052
    Quote Originally Posted by Oblivian View Post
    Of note is also the description they edited in the first posts. Which depending on interpretation isn't clear

    Errors:
    If you find any errors in FR24 aircraft database you can post the errors and correct data here. It could be wrong registration, wrong plane type, wrong airline or any other aircraft data error.

    New/Added:

    Every day there are new deliveries and old aircraft getting new owners, so new information have to be added into database daily.
    I guess I will continue to do it my way until someone tells me not to.

    Thanks

  10. #100
    Captain
    Join Date
    Nov 2011
    Location
    Vergiate Italy
    Posts
    3,595
    From my experience of the site the database key is the registration. Which when you think the whole site is about hex codes is a very strange decision..... But the use of external third party data would only be in registration form so I guess that explains the decision....

    The problem with a badly maintained database is that once a registration is in the DB twice it screws everything and when the third party data also has a registration error the same happens. It’s not about updating it’s about existing errors.

    It’s a shame the database isn’t managed in a commercial way like the rest of the site, Maxi does a great job, but it needs a database manager to go through take out all the dupes and crap. It would be easy to hold off on updates fix the errors and revise the database. But I know it won’t happen.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •