Changes between Initial Version and Version 3 of Ticket #4314


Ignore:
Timestamp:
Oct 28, 2011, 12:03:20 PM (12 years ago)
Author:
springmeyer
Comment:

With latest patch and updated tests I get: 

$python ogr_geojson.py

Test Script: ogr_geojson
Succeeded: 21
Failed:    0 (0 blew exceptions)
Skipped:   0
Expected fail:0

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #4314 – Description

    initial v3  
    1 GeoJSON is becoming a very common format for data apis. And therefore it is common for applications to grab it remotely. OGR nicely supports reading geojson from a string via url or locally. But in some cases an application may wish to download the data locally, cache it, and then pass that data to ogr. In the common case that the url does not end in a well know geojson extension, simply saving the file without an extension and passing the filename to ogr fails.
     1GeoJSON is becoming a very common format for data apis. And therefore it is common for applications to grab it remotely. OGR nicely supports reading geojson (and detecting it as geojson) from a string via url or locally.
    22
    3 It would be nice if ogr would handle detection better instead of requiring the calling application to open the file and detect if it is geojson just to give it a filename extension.
     3But in some cases an application may wish to first download the data locally, cache it, and then pass that data to ogr. In the common case that the url does not end in a well know geojson extension, simply saving the file without an extension and passing the filename to ogr fails.
    44
    5 The attached patch is a first stab at that. Im totally unfamiliar with CPL usage and coding styles (eg. I free the `char*` but should the `CPLString` also be freed?), so please have mercy.
     5This failure to detect as geojson a file like 'jsonwithoutextension' is understandable. You would have to open it to see if there is json inside and because OGR already has a ton of other checks for different file types if each driver did this you would likely see quite slow initialization of  OGR datasources. So, feel free to reject this patch outright if this seems like to much to ask of OGR.
     6
     7But, from my limited view, it would be nice if ogr would handle this kind of detection better for GeoJSON because it seems like a potentially common situation. Instead of requiring the calling application to open the file and detect if it is geojson just to give it a filename extension, ogr could do this in one pass (from the perspective of the calling application).
     8
     9The attached patch is a first stab at that. I'm totally unfamiliar with CPL usage and coding styles (eg. I free the `char*` but should the `CPLString` also be freed?), so please have mercy.