Comments on: OGR GeoJSON Driver

By: mloskot

mloskot — Mon, 13 Apr 2009 22:59:06 +0000

mjollnir,

I agree that past-and-copy is not memory efficient. I believe it could be changed to reuse the buffer if ownership is transfered and if it’s well-documented.
Feel free to discuss it on the gdal-dev list or just submit ticket with patch.

By: mjollnir

mjollnir — Mon, 13 Apr 2009 18:46:07 +0000

Great, I use :
char *poJsonBuf = …
OGRDataSource *srcDS = OGRSFDriverRegistrar::Open(poJsonBuf);

It works now. Althought it’s a little memory waste since it duplicate the data in memory, compare with great virtual file. But it works now, thanks anyway.

By: mloskot

mloskot — Mon, 13 Apr 2009 09:26:51 +0000

Hi mjollnir, Unfortunately, I don't have time to do it. Have you read the GeoJSON driver manual? Are you aware you can pass GeoJSON text directly to the driver, without a GeoJSON file stored on disk? As the manual says: The OGR GeoJSON driver accepts three types of sources of data and see the 3rd one. It means that you can pass GeoJSON text directly to OGRGeoJSONDataSource::Open referenced in const char* pszName. Also, see lines 96 - 99 of this file. It should work.

By: mjollnir

mjollnir — Mon, 13 Apr 2009 06:53:07 +0000

hi, mloskot

can you be kindly to add virtual files support for ogr GeoJSON driver, acutally, it’s very useful to handle GeoJSON without disc operation. sometime we just create GeoJSON in memory, no file needed.

http://www.gdal.org/cpl__vsi_8h.html#66e2e6f093fd42f8a941b962d4c8a19e

By: Luc Van Linden

Luc Van Linden — Fri, 05 Dec 2008 12:27:59 +0000

Mateusz

I am currently trying to figure out if this already is usable wth FDO OGR provider without muc succses. Can you please explain if and so how this should be defined in a connection string for the fdo provider?

Luc

By: mloskot

mloskot — Fri, 30 May 2008 11:10:00 +0000

Markus,

I’ve replied by e-mail already but will repeate it here to keep the story archived for others too. The problem is that opengeocoding.org does not output valid GeoJSON document but a custom JSON structure. So, OGR GeoJSON driver is useless.

By: markusN

markusN — Thu, 29 May 2008 08:08:29 +0000

Hi Mateusz,

I tried it with http://www.opengeocoding.org but didn’t succeed (my bad I guess):

ogrinfo -ro "http://www.opengeocoding.org/geocoding/geoservice.php?country=italy&province=tn&city=Trento&district=&streetnames=via rosmini 10&postcode=38100&output=json" OGRGeoJSON
ERROR 1: GeoJSON parsing error: unexpected character (at offset 0)

Is there a trick to get this working?

thanks
Markus

By: mloskot

mloskot — Wed, 07 Nov 2007 12:03:26 +0000

@Andrea Aime I fixed (Ticket #1968) the parser and now I can access GeoServer using the URL you gave above with success. Certainly, we still don't have the Multi* geometries supported, but I can read this data into OGR objects as a collection of features with NULL geometries assigned.

By: mloskot

mloskot — Wed, 07 Nov 2007 11:02:45 +0000

@Andrea Aime
I forgot to share one observation related to the GeoServer tests.
Using your URL (the big one), I can access topp:states in GeoJSON format, but the OGR driver fails when trying to parse it. Features in this collection have property called PERSONS with float number as value and for first Feature “id”:”states.1″ its value is in E notation:

"PERSONS":1.1430602E7

This is perfectly valid according to the JSON and RFC4627 (2.4. Numbers) but the OGR GeoJSON driver fails with parsing error.

I will try to fix it.

By: mloskot

mloskot — Wed, 07 Nov 2007 10:41:09 +0000

@Andrea Aime
Today, we did some tests with Chris and Hobu against the GeoServer. It looks quite good, but unfortunately we were not able to test the driver with most of the data because the OGR GeoJSON does not support Multi* geometries yet. I will test it more extensively when we have Multies supported. It should happen soon, this week yet and I’ll drop you a note about results. Thanks!