You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I'm sorry if this is implemented already, and just not updated towards opendata.antwerpen.be ...
Anyway, our current CSV outputs return a geometry column, which in the case of polygons is filled with an embedded GeoJSON. That's quite unexpected.
A better option would be to fill this column according to the GeoCSV standard, and fill the geometry column with WKT, a very basic way to define geometries.
Default projection is WKT seems to be WGS84, but most Belgian governments will give you their data in Lambert72. There seems to be a way to define projection in WKT, but I don't really understand that part myself. Maybe offering a .prj file with the description of the used projection is an easier option. Or convincing governments to offer their data in WGS84 of course (though most classical local geodata consumers will be expecting Lambert72 anyway). These two projections are VERY hard to confuse, so one might just ignore the problem too and leave it to consumer discretion...
The text was updated successfully, but these errors were encountered:
Hi,
I'm sorry if this is implemented already, and just not updated towards opendata.antwerpen.be ...
Anyway, our current CSV outputs return a geometry column, which in the case of polygons is filled with an embedded GeoJSON. That's quite unexpected.
A better option would be to fill this column according to the GeoCSV standard, and fill the geometry column with WKT, a very basic way to define geometries.
Default projection is WKT seems to be WGS84, but most Belgian governments will give you their data in Lambert72. There seems to be a way to define projection in WKT, but I don't really understand that part myself. Maybe offering a .prj file with the description of the used projection is an easier option. Or convincing governments to offer their data in WGS84 of course (though most classical local geodata consumers will be expecting Lambert72 anyway). These two projections are VERY hard to confuse, so one might just ignore the problem too and leave it to consumer discretion...
The text was updated successfully, but these errors were encountered: