Daar ging het dus mis. Het lijkt erop dat php niet op mijndev draait. Of curl niet is toegevoegd. Of dat het gewoon niet geactiveerd is voor Ligfietsers’ account.
De proxy op mijn server draait prima voor tests, maar dat is niet echt een productieserver te noemen.
Alternatief is het ombouwen van openlayers om >=7 IE < 10 met de alternatieve IE call te ondersteunen maar overpass lijkt dan niet de juiste header terug te geven. Vanf IE10 is CORS volgens de standaard ondersteund en dan gaat het gewoon goed.
Wat ligfietser dus nodig heeft is iemand met meer kennis van mijndev: wel of niet php / curl ?
Ok, zet even een php bestandje met onderstaande code op de server om te bepalen of PHP en of CURL wel geinstalleerd is en roep het bestandje aan in je browser:
<?php
phpinfo();
?>
Ik vermoed dat php-libcurl niet geinstalleerd is.
Edit 1: ligfietser is me voor.
Edit 2: ik heb de beheerder van mijndev (Sander Hoentjen van Oxilion) een mailtje gestuurd.
var proxy = true;
if (proxy){
var QURL = "http://mijndev.openstreetmap.nl/~ligfietser/fiets/api/interpreter/";
}
else{
var QURL = "http://overpass-api.de/api/interpreter/"; //default
}
Doet ook niets in andere browsers dus er is iets nog niet goed.
index.php:
<?
ini_set('display_errors',1);
error_reporting(E_ALL);
// basis url
$overpass_url = "http://overpass-api.de/api/interpreter?data=";
$data = $_GET["data"]; // de string met de query
$bbox = $_GET["bbox"]; // is de bounding box die (bbox) in bovenstaande string vervangt
$data = str_replace( "\\" , "" , $data); // als magic quotes aanstaat dubbele slash verwijderen, en anders niet van invloed
$data = urlencode($data); // vorm geven voor correcte request
$bbox = urlencode($bbox);
$request = $overpass_url.$data."&bbox=".$bbox;
$proxy = curl_init($request);
curl_setopt($proxy, CURLOPT_RETURNTRANSFER, 1);
header('Content-type: application/osm3s+xml'); // dit zet speciale header voor osm-xml
$response = curl_exec($proxy); // stuur de query naar overpass
print $response; // en het resultaat naar de client
curl_close($proxy);
?>
Dus al die tijd waren het drie lettertjes …
Werkt inderdaad prima zo, veel sneller dan die ouwe server hier ook.
tip: haal in de index.html nog de tekst ‘status’ bij de status-div weg en zet in de stylesheet bij div.statusline als extra ‘visibility: hidden;’ . Dan komt er bij het eerste laden niet zo’n loze melding over de status.
Het proxyscriptje wat er nu staat is nogal strak dwz zonder bbox en data geeft ie een fout terug. Adres is http://mijndev.openstreetmap.nl/~ligfietser/fiets/api/interpreter . En het antwoord is hard gecodeerd als Content-type: application/osm3s+xml, dus de meeste browsers laten dat zelfs niet zomaar zien omdat ze het niet herkennen.
Het duizelt me bij het lezen van deze correspondentie. Hier worden grootse dingen verricht!
Helaas mis ik nu hier en daar eenvoudige rwn-routes die wél zijn getagd.
Voorbeelden zijn relaties 284362, 284363 en 284365.
Het zijn slechts wandelroutes maar nu we gelukkig, heel comfortabel, op de bagagedrager van de fietsers mogen meeliften, zou ik het leuk vinden als jullie dat óók nog in orde zouden kunnen brengen.
Veel succes, ik volg het allemaal met belangstelling.
Jan
Om misverstanden te voorkomen heb ik ook de rwn_ref knooppunten die ook rcn_ref fietsknooppunten zijn, eruit gehaald omdat er nog geen oplossing is ze beiden te tonen (kan wel, bv met rwn_ref/rcn_ref, maar dat blijft verwarrend voor de fietsers). Jullie moeten dus maar gauw een eigen kaartje maken, misschien dat Traildino dat kan?