Es ist nun eine neue Version der OHDM-API verfügbar. Diese beinhaltet auch das entfernen von External-Sources.
Die API-Version davon wird in den nächsten Tagen eingespielt.
Die aktuelle Version der Dokumentation ist hier zu finden: OhdmApi-Documentation

Die Authentifizierung ist nun für den Test-Server von OHDM aktiviert.
Sie ist in der Dokumentation im Kapitel 2.1 beschrieben.
Die Dokumentation ist hier zu finden: OhdmApi-Documentation

Die API ist nun auf die neue DB-Struktur umgestellt, welche die Verknüpfung der Tag-Dates anders handhabt.
Sie ist unter http://ohsm.f4.htw-berlin.de:8080/OhdmApi erreichbar. Dort befinden sich auch aktuelle Daten von Berlin (mit richtiger Lat/Lng Zuweisung).

Die API-Version 1.1 ist jetzt auf dem Test-Server http://ohsm.f4.htw-berlin.de:8080/OhdmApi aktiv. Diese enthält eine neue Version der nahen Geographien. Außerdem ist sie komplett auf die neue Datenbank-Struktur umgestellt.

Die neue Dokumentation ist hier zu finden: OhdmApi-Documentation

Die Dokumentation enthält bereits die Authentifizierung, diese ist aber in der aktuellen API noch nicht aktiviert.
Geändert haben sich in der Dokumentation die Kapitel 3.2.2 bis 3.2.5.

– Anpassung der entstandenen Authentifizierungs-Webservices
– Verknüpfung der API mit der Authentifizierung
– Erstellung von Unit-Tests
– Orte in der Nähe (Geometrien liefern) -> verbesserte Version
– Anpassung der API an die neue Datenbank (siehe Änderungen der Datenbank+)
– Auslieferung von Tile-URLs zu Zeiträumen (für die JavaScript-Animation)

Die finale Version der API-Dokumentation für dieses Semester ist jetzt online. Die API wird im nächsten Semester noch weiter entwickelt. Gerade, was das Abfragen von Geometrien in der Nähe angeht, wird noch viel geschehen.
Bitte benutzt diese Funktion derzeit noch sehr Vorsichtig und nehmt nur geringe Radius-Werte und kleine Geometrien, ansonsten wird der Server schnell überlastet.
Bei allen anderen Funktionen sollte es keine Probleme geben.

Download der API-Dokumentation: OhdmApi-Documentation.pdf

Die API ist wieder erreichbar.
Die aktualisierte URL des Test-Systems ist oben zu finden.
Eine erste Version (Inhaltlich komplett, sprachlich noch in Verbesserungsarbeit) ist hier zu finden: OhdmApi-Documentation

Weil wir gerade auf einen neuen Test- und Produktiv-Server umstellen, ist die API leider momentan nicht erreichbar. Wer derzeit damit arbeiten will, kann sie sich lokal installieren. Hierzu wird ein Tomcat-7 + Java 7 benötigt. Die War-Datei der API kann ich dann per Mail zukommen lassen.

Es ist nun kein VPN-Zugang mehr notwendig, um mit der OHDM-API zu kommunizieren.

Aus aktuellem Anlass hier mal ein Beispiel-Code in Java zum Abfragen von Geometrien:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

URL url = new URL("http://141.45.146.152:8080/OhdmApi/geographicObject/nearObjects/highway=primary,highway=traffic_signals/1/"+URLEncoder.encode("MULTILINESTRING((13.513375234473285 52.42776656340422 0,13.513293936940071 52.42797876424454 0))", "UTF-8").replace("+", "%20"));
HttpURLConnection con = (HttpURLConnection) url.openConnection();
con.setRequestMethod("GET");
con.setRequestProperty("Content-Type",
			"application/json; charset=utf-8");
 
int responseCode = con.getResponseCode();
BufferedReader in = new BufferedReader(
		new InputStreamReader(con.getInputStream()));
String inputLine;
StringBuffer response = new StringBuffer();
 
while ((inputLine = in.readLine()) != null) {
	response.append(inputLine);
}
in.close();
System.out.println(response.toString());

Das Löschen von Tag-Dates ist sowohl für alle Tag-Dates mit einer bekannten geographischen Objekt-ID möglich, als auch für ein spezielles Tag-Date mit eindeutiger ID möglich.

Für ein Objekt mit Tag-Date-ID:
DELETE: URL: /tagDate/<geographicTagDateId>

Für alle Objekte mit geographischer Objekt-ID:
DELETE: URL: /tagDate/geographicObject/<geographicObjectId>

HTTP-Status bei Misserfolg: 404 bei nicht vorhandener ID

Das Löschen von geometrischen Objekten ist sowohl für alle geometrischen Objekte mit einer bekannten geographischen Objekt-ID möglich, als auch für ein spezielles geometrisches Objekt mit eindeutiger ID möglich.

Für ein Objekt mit geometrischer Objekt-ID:
DELETE: URL: /geometricObject/<geometricObjectId>

Für alle Objekte mit geographischer Objekt-ID:
DELETE: URL: /geometricObject/geographicObject/<geographicObjectId>

HTTP-Status bei Misserfolg: 404 bei nicht vorhandener ID

Es ist jetzt auch eine Löschfunktion für ein geographisches Objekt implementiert, welche auch alle Abhängigkeiten zu Tag-Daten, Blob-Daten und Geographien entfernt.

DELETE: URL: /geographicObject/<geographicObjectId>

HTTP-Status bei Misserfolg: 404 bei nicht vorhandener ID

Die hier beschriebenen neuen Funktionen ermöglichen das Abfragen aller Geographien mit allen enthaltenen Informationen in der Umgebung.
Zu erkennen ist, dass die Parameter since und until, welche den Zeitraum der Geometrien bestimmen, optional sind. Sollte einer oder beide davon weggelassen werden, gibt es keine Einschränkung in die jeweilige Richtung der Zeitachse.

Mögliche neue URLs:

/geographicObject/nearObjects/<requiredKeys>/since/<since>/until/<until>/<distance>/<geometry>

/geographicObject/nearObjects/<requiredKeys>/since/<since>/<distance>/<geometry>

/geographicObject/nearObjects/<requiredKeys>/until/<until>/<distance>/<geometry>

/geographicObject/nearObjects/<requiredKeys>/<distance>/<geometry>

requiredKeys ist dabei eine dynamische Map, welche eine Reihe von Keys und Values beschreibt, bei der die Values ausgelassen werden können.
Diese Map beschreibt welche keys mit welchen Values in der Ergebnismenge bei den „tagDates“ vorhanden sein müssen.
Ein Beispiel:
key1=value1,key2,key3=value3
Damit wird festgelegt, dass key1 den Wert value1 genauso wie key3 den Wert value3 haben muss. Für key2 ist wegen ausgelassenem Wert nur erforderlich, dass er für das Geographische Objekt existiert. Auf diese Weise ist es möglich nach Straßen, Postleitzahlen etc. zu filtern. Auch alle straßenbezogenen Daten (oder andere Bereiche) wie die Straßen selbst, Verkehrszeichen oder Fußgängerüberwege in gesammelter Form können durch das Setzen des Keys bei weggelassenem Wert erreicht werden. Möchte man beispielsweise alle Objekte mit Straßen-Informationen erhalten, so ist der Parameter einfach nur auf „highway“ zu setzen. Werden die requiredKeys frei gelassen wird (//), so wird kein Filter verwendet und es werden alle Objekte in dem gewählten Umkreis (Angabe in Metern) und der Zeitspanne ermittelt.

Beispiel-Antwort der API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

[  
   {  
      "geographicObjectId":2177858,
      "attributes":{  
 
      },
      "externalSourceId":0,
      "externalSource":{  
         "id":0,
         "title":"OSM_nodes",
         "text":"OSM geometries with the id nodes"
      },
      "originalId":620874781,
      "geoBlobDates":null,
      "tagDates":[  
         {  
            "tags":{  
               "highway":"traffic_signals",
               "osm_timestamp":"2012-09-09T12:37:42Z",
               "osm_user":"Balgofil",
               "osm_version":"3",
               "osm_uid":"95702"
            },
            "valid":{  
               "since":"0001-01-01",
               "until":"3000-01-01"
            }
         }
      ],
      "geometricObjects":[  
         {  
            "valid":{  
               "since":"0001-01-01",
               "until":"3000-01-01"
            },
            "multipolygonString":null,
            "geometryCollectionString":null,
            "multilinestringString":null,
            "multipointString":"SRID=4326;MULTIPOINT(13.513375298118923 52.42776659475573 0)"
         }
      ]
   }
]

Die in diesem Beitrag beschriebenen API-Funktionen wurde wieder entfernt und durch folgende ersetzt:

http://hadizadeh.de/2014/12/16/abfrage-aller-geographien-mit-allen-enthaltenen-informationen-in-der-umgebung/

Bei den neu hinzugefügten API-Befehlen handelt es sich bei allen um GET-Anfragen.

Mögliche neue URLs:

/geometricObject/nearObjects/since/<since>/until/<until>/<distance>/<geometry>

/geometricObject/nearObjects/since/<since>/<distance>/<geometry>

/geometricObject/nearObjects/until/<until>/<distance>/<geometry>

/geometricObject/nearObjects/<distance>/<geometry>

Zu erkennen ist also, dass die Parameter since und until, welche den Zeitraum der Geometrien bestimmen, optional sind. Sollte einer oder beide davon weggelassen werden, gibt es keine Einschränkung in die jeweilige Richtung der Zeitachse.
Die Abfrage der Geometrie-IDs ist derzeit noch nicht auf eine Anzahl beschränkt oder sortiert, bei großem angegebenem Umkreis kann es also zu größeren Datenmengen kommen. Darauf ist bitte beim Testen zu achten. Eine Implementierung dieser Einschränkungen wird noch folgen.

Beispiel-Antwort der API:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[  
   {  
      "key":1217525
   },
   {  
      "key":1217569
   },
   {  
      "key":1217581
   },
   {  
      "key":1238006
   }
]

Folgende API-Funktion liefert alle Daten eines geographischen Objekts. Nur die Medien-Daten sind derzeit noch leer.

GET: URL: /geographicObject/<geographicObjectId>

Beispiel-Ergebnis:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

{  
   "attributes":{  
 
   },
   "externalSourceId":0,
   "externalSource":{  
      "id":0,
      "title":"OSM_nodes",
      "text":"OSM geometries with the id nodes"
   },
   "originalId":2919204078,
   "geoBlobDates":null,
   "tagDates":[  
      {  
         "tags":{  
            "osm_user":"Slight",
            "osm_timestamp":"2014-06-16T19:36:51Z",
            "osm_version":"1",
            "osm_uid":"2120048"
         },
         "valid":{  
            "since":"0001-01-01",
            "until":"3000-01-01"
         }
      }
   ],
   "geometricObjects":[  
      {  
         "valid":{  
            "since":"0001-01-01",
            "until":"3000-01-01"
         },
         "multipointString":"SRID=4326;MULTIPOINT(12.93592839819927 52.391893794756506 0 0)",
         "multilinestringString":null,
         "geometryCollectionString":null,
         "multipolygonString":null
      }
   ]
}

Neue API-Funktionalität:

GET: URL: /geometricObject/geographicObject/<geographicObjectId>

Beispiel-Ergebnis:

1
2
3
4
5
6
7
8
9
10
11
12

[  
   {  
      "valid":{  
         "since":"0001-01-01",
         "until":"3000-01-01"
      },
      "multipointString":"SRID=4326;MULTIPOINT(12.93592839819927 52.391893794756506 0 0)",
      "multilinestringString":null,
      "geometryCollectionString":null,
      "multipolygonString":null
   }
]

Die API auf dem v-Server ist nun auf die ohdm-dev2 umgestellt worden. Dort können Änderungen über die API eingesehen werden.

2 neue APi-Funktionen stehen zur verfügung:

GET: URL: /externalSource/geographicObject/<geographicObjectId>

Beispiel-Ergebnis:

1
2
3
4
5

{  
   "id":0,
   "title":"OHDM",
   "text":"OHDM internal geometries"
}

GET URL: /externalSource/<externalSourceId>

Beispiel-Ergebnis:

1
2
3
4
5

{  
   "id":101,
   "title":"OSM_nodes",
   "text":"OSM geometries with the id nodes"
}

Über die URL /tagDate/geographicObject/<ObjectId> lassen sich nun auch die Tag-Dates zu einem Geographic-Object abrufen. Dabei werden mehrere Tags, welche für das gleiche Datum valide sind, zusammengefasst.

Beispiel-Ergebnis:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[  
   {  
      "tags":{  
         "osm_user":"Slight",
         "osm_timestamp":"2014-06-16T19:36:51Z",
         "osm_version":"1",
         "osm_uid":"2120048"
      },
      "valid":{  
         "since":"0001-01-01",
         "until":"3000-01-01"
      }
   }
]

Die Kommunikation zwischen v-Server und Cluster funktioniert nun. Der Port des v-Servers (Outgoing) war für Postgresql nicht geöffnet. Die aktuelle Version der API ist demnach jetzt testbar.

Das Eintragen von Tag-Dates ist sowohl einzeln über einen POST auf die URL /tagDate/<ObjectId> als auch integriert als PUT in /geographicObject/ implementiert.

Beispieldaten:

1
2
3
4
5
6
7
8
9
10
11

{  
   "tags":{  
      "key1":"value1",
      "key2":"value2",
      "key3":"value3"
   },
   "valid":{  
      "since":"2013-12-01",
      "until":"2014-05-14"
   }
}

Wichtig: Die ObjectId muss natürlich in der Datenbank vorliegen.

Derzeit gibt es noch Probleme mit der Verbindung zwischen dem V-Server und dem Cluster, auf dem die Datenbank liegt.

Die Präsentation ist hier als PDF zu finden: Zwischenpraesentation_04-12-2014

Sie enthält folgende Themen:

– Aufbau der API

– Grundlagen zu REST

– Möglichkeiten zum Upload von Mediendateien für OHDM

– Stand der aktuellen Implementierung

– JSON-Beispiel Anweisungen zum einfachen Anpassen

– Beispielhafter Client-Code

– Planungen

– Zusammenspiel mit Open Layers

Formatierte JSON-Strings aus der Präsentation:

URL (PUT): /externalSource/

1
2
3
4

{  
   "title":"Source-Titel",
   "text":"Source-Text"
}

URL (POST): /geometricObject/<geographicObjectId>

1
2
3
4
5
6
7

{  
   "valid":{  
      "since":"2013-12-01",
      "until":"2014-05-14"
   },
   "multipoint":"MULTIPOINT(1 2,1 2)"
}

URL (PUT): /geographicObject/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45

{  
   "originalId":"12345",
   "attributes":{  
      "key1":"value1",
      "key2":"value2",
      "key3":"value3"
   },
   "externalSourceId":400,
   "geoBlobDates":[  
      {  
         "valid":{  
            "since":"2013-12-01",
            "until":"2014-05-14"
         }
      },
      {  
         "valid":{  
            "since":"2013-10-01",
            "until":"2014-05-11"
         }
      }
   ],
   "tagDates":[  
      {  
         "tags":{  
            "key1":"value1",
            "key2":"value2",
            "key3":"value3"
         },
         "valid":{  
            "since":"2013-12-01",
            "until":"2014-05-14"
         }
      }
   ],
   "geometricObjects":[  
      {  
         "valid":{  
            "since":"2013-12-01",
            "until":"2014-05-14"
         },
         "multipoint":"MULTIPOINT(1 2,1 2)"
      }
   ]
}