glidernet / ogn-ddb Goto Github PK

Many gliders are shared resources in gliding clubs. Currently each device is bound to a single user (the 'device owner'), the only person who is allowed to edit the device settings. I propose to add a group functionality to enable a group of users to edit the device settings:

Device owners obtain the possibility to grant a group the right to edit the device settings of a certain device. Every user can add such a group and add/delete members (other users) to this group.
The owner and all members of the group a device belongs to can edit the devices settings of a certain device.

Model

• users
• devices
  • device_id
  • owner
  • device settings (identified/tracked for now)
  • access_group
• groups
  • owner
• group_members
  • group
  • member

Frontend

• Add/Delete group (only possible for the group_owner)
• Add/Remove members to a group (only possible for the group_owner)
• Edit device
  • edit aircraft_type/name/registry/access_group (only possible for the device_owner)
  • edit device settings (only possible for the owner and all members of the access_group of a device)

Could you also add definitions for all fields including AIRCRAFT_TYPE which seems to be an integer (1:6?) but what do the integer values mean? Is this defined elsewhere? If so could a reference be included to the meanings?

The aircraft list is now long, and probably a lot of aircrafts, paragliders 😉 will be added in a near future.

It would be useful to have an AJAX live search field. (see example).

Folks,

With the advent of new devices pushing data to the OGN APRS like: SPOT, SPIDER, Capturs, LT24, Naviter/LX, Skylines (XCsoar), etc, ... it is needed to define the source of the data, so the different app parser can parser the new messages.
We started a new repo:

https://github.com/glidernet/ogn-aprs-protocol

with all the data and as forum to discuss the different issues that we can find in the way

However one area that we need to deal at registration time, it is how we are going to register all of those new devices and how we are going to be dealing with the fact that a glider, can have at the same time different devices, for example a Flarm, an OGN tracker, an SPOT and a LX9000 or Oudie all of them transmitting the position to the OGN APRS servers, we do not want to display in our web apps like http://live.glidernet.org 4 gliders on the same position with the same registration, etc, ...
We need to find a way to relate all of those devices to a single glider (when I say glider, may be a tow plane, a chopper, a paraglider, etc, ...) ...
Here some ideas of a new schema for the DDB, essentially consist to add a new table, lets call it PLANES table for the time being, that contains all the data about the plane like: registration, competition id, aircraft type, etc, and the DEVICE table contains only the ID, device type, link to PLANE table and device password as some device requires that.
The other tables AIRCRAFT type and USER will remain the same.
On the PLANES table will have a link to the primary device ID, that way we can maintain the compatibility with the previous design and the download format will be the same.
Of course, we need to develop a new download process.
Please find attached the initial design docs,
Your comments or suggestion will be deeply appreciated.

AC/.

ddb schema.pdf

OGNNEWDDB.TXT

For example _ seems not allowed for the moment.

http://ddb.glidernet.org/download/?j=1 should return the ddb in json format. This does not work anymore. #

I was trying to get the corresponding index for gliders registered in the database. Therefore I have added a json mapping to https://github.com/weglide/GliderList/ to link between glider names present in the ogb-ddb and gliders in GliderList. In the process, I detected that many namings in the ogn-ddb were not quite precise or did not conform to manufacturers naming conventions.

Maybe it would be interesting to integrate GliderList id to the ogn-ddb? This would make it more precise which glider is meant and would also have the benefit of following strict naming conventions for gliders checked with all manufacturers.

If user do an error (wrong captcha, not existing email, ...) while reseting password it is redirected to account creation instead of password recovery page.

When editing an entry in DDB, if i change ID and ID type and then validate, it create a new entry instead of changing the existing one. For example changing from Flarm ID type to ICAO id type.

In ogn-ddb/templates/base.html.twig

<html lang="en">
<head>
    <title>OGN Devices Database</title>

In ogn-ddb/index.php

    $catarray = array(
        1 => 'Gliders/motoGliders',
        2 => 'Planes',
        3 => 'Ultralights',
        4 => 'Helicoters',
        5 => 'Drones/UAV',
        6 => 'Others',
    );

            'type' => $row['ac_type'],

In ogn-ddb/language/french.php

    "full_participation" => "Full participation", //no checkboxes checked
    "full_participation_description" => "<ul>
        <li>Tracking applications that use the OGN DDB will mark the position with aircraft identification</li>
        <li>Aircraft registration and CN are published in the OGN Devices Database</li></ul>",
    "anonymous_participation" => "Anonymous participation", //only noident checkbox checked
    "anonymous_participation_description" => "<ul>
        <li>Tracking applications that use the OGN DDB will mark the position with an <em>anonymous</em> marker</li>
        <li>Aircraft registration and CN are <em>not</em> made public</li></ul>",
    "no_participation" => "No participation", //notrack or both checkboxes checked
    "no_participation_description" => "<ul>
        <li>Tracking applications that use the OGN DDB will <em>not</em> mark your position</li>
        <li>Aircraft registration and CN are <em>not</em> made public.</li>
        <li>SAR-functions <em>may not</em> be available for this device</li>
        <li>This device <em>may not</em> contribute to traffic awareness through OGN</li></ul>",

At first ddb has been conceived for gliders , nowadays ddb welcomes new aircraft types such as ultralight powered aircrafts. In France , these aircrafts have two "callsigns" the radio one F-Jxxx and the visual id sign on the wing two digits reflecting a geographical origin and letters.
For safety reason , it is better to be able to konw these two regisytration id's.

Could it be possible to extend the CN field up to 6 hex characters ? one alternative could be to allow Registration up to 14 hex characters

Regards

We should really break up the index.php file into smaller files/classes for maintainability.
This might however turn out to be a complete rewrite.

We should add input validation for ICAO-IDs.

Why?
According to http://www.kloth.net/radio/icao24alloc.php,

[...] addresses starting with bit combinations
1011, 1101 and 1111 have been reserved for future use.

Unfortunately, there are DDB entries of type 'I' with an address from the reserved range.
Test script:

#!/usr/bin/env python3
from ogn.utils import get_ddb

ddb = {}
for d in get_ddb():
  id = int(d.address, 16)
  ddb.update({id: d})

i = 0
for d in ddb:
  # ICAO-Address in 'reserved for further use'-range
  if ddb[d].address_type == 'I' and bin(d)[2:6] in ['1011','1101','1111']:
    print('{}{}'.format(bin(d), ddb[d]))
    i += 1
print("%i entries" % i)
# current Result: '102 entries'

Currently, it is possible to visit and use the ddb over HTTP without the page redirecting to HTTPS.

For the past hour or so the DDB has been unavailable:

curl -m 5 https://ddb.glidernet.org
curl: (28) Operation timed out after 5004 milliseconds with 0 bytes received

Hi

Some time ago you implemented the JSON REST access to the OGN ddb. Thanks for that!

Now, seeing the growing number of records, I was wondering if you could enrich your service by adding the support of "from/to" url parameters, so that we could have paging?

That would make the browsing page:

http://wiki.glidernet.org/ddb-list

much more responsive.

example

?from=0&to=100 (could be ex. left inlcusive, right -exclusive - give me the recors 0-99)

?from=100&to=200 (records 100-199)

and so on...

Thanks!

When editing an entry, "Aircraft type" field always comes back to "A380" instead of previous value.
This seems to be a regression introduced recently.
@kerel-fs, can you please have a look?

For reference: The AGPL was chosen for ogn-live (glidernet/ogn-live#6).
What are your thoughts? @snip @cunimb @dbursem

When trying to register a second-hand device where the previous owner didn't remove the registration in the DDB, the user is presented with the following:

As was described by @snip on the ML, the user should send a mail to [email protected] with details in this case (after trying to reach out to the previous owner).

This should be communicated in the dialog above (or a link to a description should be included).

The following motor gliders are in "Planes", but they are "Gliders/motoGliders":
Grob G109
RF 3
RF 4
RF 5
RF 5 b

When a user loses their password, an admin needs to do some change manually.
A pull request implementing an automatic process using email (password resetting) is welcome!

The problem keeps coming up with registration of second-hand devices when the previous owner has not un-registered. To avoid the need for "staff" intervention, I suggest "expiring" devices after some time (e.g., 2 years) from registration or modification of the registration record. After that time, a new owner would be allowed to register the same device. Unless and until that happens, the old registration would keep "working" in all other ways.

The essential development bits to implement this are:

• add a date field to the DDB schema "devices" table.
• update that date field to "today" when a device record is created or updated (or "renewed").
• when checking whether the device is already registered to somebody else, check that date, if more than 2 years ago then do allow registering by a new owner.
• when actually registering a new device record for the new owner, delete the existing device record with same device ID.
  The rest is optional. E.g., a "this device registration has expired" notice plus a "renew registration" button would be nice, but can start with just some generic text on the page explaining that one must re-save the record every year or two to avoid it expiring.

For ddb website gzip compression is enabled, but for download (http://ddb.glidernet.org/download/) it is disabled. This affects the android app "OGN viewer", so each startup need 585kB instead of 150kB.

1. I just took a look at the OGN ddb to see if there was anything to tell when a registration will expire and found that it appears to have as problem with formatting the display.
   You appear to have added an expiry clock , but the table doesn’t have enough rows to display correctly [or rather the expiration label is in the wrong row in column 1 to match the clock in column 2 ]

2. Sign in seems to no longer remember my credentials ( at least not on my iPad or iPhone)

We (a group of developpers) are on our way to propose an API to add device for an existing account.

We propose a two ways authentication to access this API

First request : authenticate via user credentials to get a token with a limited valid time

second request : API access with the above token.

we would like to get your feedback on this mechanism before going into dev.

Then we would like also to implement sort of quota on API use to prevent misuse of the API.

Would you prefer :

1. number/time limitation of request to the API
2. any other method that you think should be more appropriate

looking forward to hear from you

Laurent

The DDB is currently giving a 504 Gateway timeout and has for the last hour or so

The service
http://ognstats.ddns.net/igc/
currently provides IGC files of the last & current day.
Thanks @buczakwk for providing this service!!

As far as I can see, this respects our policy "You do not re-distribute OGN data older than 24 hours" (documented here since yesterday 🙈 ) now. Discussion on this policy & license should happen on the ML, not here. :)

Imho it would be great for pilots to be able to download even older data when consent was given.
Do you have any proposals how to enable pilots to state their consent? Should this consent be given in the ogn-ddb (centralized), or in the service which provides the igc files?