freifunk / openwifimap-api Goto Github PK

OpenWiFiMap database and its api

Python 100.00%

openwifimap-api's Introduction

openwifimap-api (Python)

OpenWiFiMap is a database and map for free network WiFi routers (freifunk and others, too!).

This is the database/backend part of the openwifimap. Make sure to also take a look at its web frontend, the openwifimap HTML5 app.

The original backend was written in Javascript using CouchDB. Since maintaining that was problematic, it was rewritten in 2020/2021 to use Python/FastAPI/PostgreSQL.

API

See the Swagger API docs at /docs on the running backend (at api.openwifimap.net/docs, for example).

The somewhat more verbose old API doc can be found in the old API.md.

License

openwifimap is licensed under the MIT license.

Development info

The backend is basically keeping a list of JSON documents on disk which can get queried and updated via a web API. The database is used as search index only. PostgreSQL is total overkill for this but ¯_(ツ)_/¯

The interesting part of the code is in restapi.py.

In case you wonder, endpoint definitions are a bit complicated (BaseModel, response_model, Field, Query, ...) since FastAPI can generate nice Swagger API docs from this.

Dev notes

sudo docker run --name owm_psql -p 127.0.0.1:5432:5432 -e POSTGRES_PASSWORD= -e POSTGRES_USER=owmuser -e POSTGRES_DB=owmdb -d postgres:latest
PostgreSQL earthdistance extension: https://postindustria.com/postgresql-geo-queries-made-easy/ (not used yet)

openwifimap-api's People

Contributors

Stargazers

Watchers

Forkers

andibraeu ingogaucho mojoaxel weimarnetz jjnf wazowski78 bjangeofan freifunk-berlin tommalvoriddle svenroederer bahati308

openwifimap-api's Issues

update_node should return JSON

$ sh -x test.sh

curl -X PUT api.openwifimap.net/update_node/myid -d {
"type": "node",
"hostname": "myhostname",
"latitude": 52.520791,
"longitude": 13.40951,
"updateInterval": 6000
}

returns a simple "doc updated".

It should instead return some json with status.

Old CouchDB data pre-2021?

I'm very interested in doing historical analysis of the Freifunk Berlin network in preparation for the changes to the routing protocol. Is the old data from before the Postgres migration still available somewhere?

define a common dataset for a node

With the reborn OWM there started some work on the clients again, e.g.

This raises the issue of using different models of a node-dataset. technically this is no problem on the OWM-API / OWM-database, but might become a mightmare to the frontends using the nodes dataset. Having a web-statistic which will only work for data uploaded with certain client, is very likely nothing we want to have.
Example:

{"node": "some node", "latitude":52.436757800214,"longitude":13.546518087387, "height": 20, "script":"luci-app-owm"}

vs.

{"node": "some node", position: {"latitude":52.436757800214,"longitude":13.546518087387, "height": 20}, "script":"fancy-owm"}

I suggest we make a small definition of what data and a suggested format

minimal data required
common data that should be supplied
optional data that can be provided

node updates fail

calling /usr/sbin/owm.lua results in the following error message:

fail Doc Statuscode: 403 http://mapapi.weimarnetz.de/update_node/tp-dev.olsr ({"error":"forbidden","reason":"Field ctime has to be invariant under (new Date(...)).toISOString() (evaluates to Invalid Date)"}

testet with openwrt barrier breaker r36817 on tp-link 1043nd

drop usage of couchdb

As stated in #9 the current API became unmaintained and was finally shutdown. @sarumpaet mentioned this was caused of required API-change to recent couchDB versions, which nobody was willing to do.
@andrenarchy was this the only reason or are there additional ones?

@sarumpaet has the vision of switching to postgres-postGIS. This might be a way to go, as SQL has proven as a stable "API" in the last decades. Also running a postgresql database is more common than a couchDB.
What's the advantage of using the postGIS extension inplace of native postgresql? I expect the native Postgresql support of geometric-data (https://www.postgresql.org/docs/12/datatype-geometric.html) will fit our needs also.

we usually store a node with it's position, the OWM-datablob and some metadata
we will have queries like "select all nodes where position is within BOX()" or "select all nodes where position is within POLYGON()"
probably queries like "is node with pos inside POLYGON()"

this seems to work with native Postgres already.

geotest=# select * from node ;
 name  |     pos     
-------+-------------
 node1 | (13.5,51)
 node2 | (13.5,51.1)
 node3 | (13.4,51.1)

geotest=# select * from node where pos <@ BOX'(13,51.01,13.45,51.2)';
 name  |     pos     
-------+-------------
 node3 | (13.4,51.1)

geotest=# select * from node where pos <@ BOX'(13,51.01,13.5,51.2)';
 name  |     pos     
-------+-------------
 node2 | (13.5,51.1)
 node3 | (13.4,51.1)

The compare operators can be found: https://www.postgresql.org/docs/12/functions-array.html

Can someone help me, please!?
Thanks and best regards

The "useful links" in the "README.md" file are no longer working

Clicking them results in a "page not found" error.