Frank Warmerdam wrote: > Mateusz Loskot wrote: >>> It *seems* like a bad idea to embed such behavior in a particular >>> driver. >> >> Yes, I understand your point. Perhaps I should narrow the test with >> check if URL consists of "geojson" token, like >> http://server/path/geojson/1234 or ftp://server/path/file.geojson >> and if not present, then no remote reading would be performed. >> Should I? > > Mateusz, > > If there was a typical extension for geojson files that would be > helpful.
Looking at http://featureserver.org/ I suppose a typical extension is .json but I sort of proposed also .geojson. I mean, URLs may include string "geojson" as a format request, so I meant this http://server/path/geojson/1234 as specific format request (following RESTful thing): http://server/path/gml/1234 http://server/path/kml/1234 etc. > Alternatively, we could take this out of the geojson driver, and > handle it more like GDAL where we have a final "http" driver that > will fetch http results and then re-invoke OGROpen() on the resulting > downloaded file. Then all the drivers again have a crack at the > file. > > This would make it work for kml, for instance, and would sure we > don't end up downloading it several times if the logic ends up in > several drivers. OK, no problem for me to disable it. Should I? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
