Assuming said csv file is properly structured with Latitude and Longitude. I'm having problems find converters that won't mess up the data types (putting string around integers).
-
1I think that this question is different from http://gis.stackexchange.com/questions/127518/convert-csv-to-kml-or-geojson-etc-using-ogr2ogr-use-latitude-and-longitude, because it talks about conservation of data types – Devdatta Tengshe Mar 25 '15 at 04:44
-
You can't really talk about "messing up" data types, because CSV doesn't have data types: every value is a string. What you want is a tool that can infer data types, which can be error prone - eg, is a numeric identifier a number or a string? – Steve Bennett Jan 31 '18 at 21:49
5 Answers
The most robust way to do this, is to use GDAL's ogr2ogr functionality. Since you know your datatypes, you can specify them in VRT file.
The documentation has this to say about setting field types:
Field (optional, from GDAL 1.7.0): One or more attribute fields may be defined with Field elements. If no Field elements are defined, the fields of the source layer/sql will be defined on the VRT layer. The Field may have the following attributes:
name (required): the name of the field.
type: the field type, one of "Integer", "IntegerList", "Real", "RealList", "String", >"StringList", "Binary", "Date", "Time", or "DateTime". Defaults to "String".
subtype: (GDAL >= 2.0) the field subtype, one of "None", "Boolean", "Int16", "Float32". Defaults to "None".
width: the field width. Defaults to unknown. precision: the field width. Defaults to zero.
src: the name of the source field to be copied to this one. Defaults to the value of "name". nullable (GDAL >= 2.0) can be used to specify whether the field is nullable. It defaults to "true".
So if your CSV data is like this:
Latitude,Longitude,Name, Ht
48.1,0.25,"First point", 3
49.2,1.1,"Second point", 56
47.5,0.75,"Third point", 67
You should build a VRT like this:
<OGRVRTDataSource>
<OGRVRTLayer name="data">
<SrcDataSource>data.csv</SrcDataSource>
<GeometryType>wkbPoint</GeometryType>
<LayerSRS>WGS84</LayerSRS>
<GeometryField encoding="PointFromColumns" x="Longitude" y="Latitude"/>
<Field name="Name" src="Name" type="String"/>
<Field name="Height" src="Ht" type="Real"/>
</OGRVRTLayer>
</OGRVRTDataSource>
Now you can export to GeoJSON with the following command: ogr2ogr -f GeoJSON output.geojson data.vrt
- 41,311
- 35
- 139
- 263
If you use geojson.io, it will not mess up the property data types. Import the csv file into there, then export it out as geojson.
- 658
- 3
- 9
- 17
-
I tried with the sample CSV that I have mentioned in my answer, but geojson.io doesn't recognise the proper data types – Devdatta Tengshe Mar 25 '15 at 05:56
-
I ran a csv through it with latitude and longitude and it maintained my timestamps and prices (properties) just fine. – Kyle Pennell Mar 25 '15 at 17:06
-
1It's just not robust enough. It didn't read the
Htin the CSV in my answer as numeric, and put in inverted commas around the values, making them strings. – Devdatta Tengshe Mar 26 '15 at 04:37
Taking CSV data (test.csv) from Devdatta Tengshe's answer:
Latitude,Longitude,Name, Ht
48.1,0.25,"First point", 3
49.2,1.1,"Second point", 56
47.5,0.75,"Third point", 67
In QGIS you need a *.csvt file (test.csvt) for considering data types. In this case:
Real, Real, String, Integer
At the next imagen it can be observed that the csv layer 'type names' were loaded correctly:

Saving cvs layer as geojson directly:

Loading the geojson layer at the Map View of QGIS and displaying the corresponding attributes table and the content of text file:

- 29,891
- 4
- 41
- 80
Also MyGeoData Converter allows to convert CSV and many other formats to GeoJSON and other formats on-line. It is also possible to use VRT file mentioned above...
- 555
- 4
- 8