Re: [gdal-dev] Re: Creating a blank raster from scratch
Jorge, I think I was the original poster of the trac snippet, which worked for me on mac os. Great job researching, and yes, please update the snippet as needed. Thanks! Dane On Feb 3, 2009, at 3:53 AM, Jorge wrote: And finally, hello Sorry for being annoying. I've found this ticket closed 2 years ago http://trac.osgeo.org/gdal/ticket/1166 . I'll apply the patch, but I think that this should be added with the FAQ. Saves time :-) Best regards Jorge Jorge escribió: Hello again, I' ve found the problem, I think. Is the version of numpy used by gdalnumeric. The code from FAQ works with numpy version 1.0.1, but fails with numpy version 1.2.1. The fail is because the narray attribute "typecode()" doesn't exist. From the numpy book, available at http://numpy.scipy.org/numpybook.pdf, you can get (page 55): "If you are converting code from Numeric, then you will need to make the following (search and replace) conversions: .typecode() --> .dtype.char; .iscontiguous() --> .flags.contiguous; .byteswapped() --> .byteswap(); .toscalar() --> .item(); and .itemsize() --> .itemsize. The numpy.oldnumeric.alter code1 module can automate this for you." Ok. I've opened gdalnumeric.py, and the last change was from 2006/03/21. The older version from numpy available at sourceforge download's page is from 2007-11-08. Then, gdal is using a really old version of numpy. Maybe I can use the numpy 1.0.1 from my mac, but I think that it would be easier to replace the snippet's code lines that uses numpy from the correct ones. What's the best way to do this # Create blank raster with fully opaque alpha band zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 ) dst_ds.GetRasterBand(1).WriteArray( zeros ) dst_ds.GetRasterBand(2).WriteArray( zeros ) dst_ds.GetRasterBand(3).WriteArray( zeros ) opaque = numpy.zeros((tiff_height,tiff_width), numpy.uint8 )*255 dst_ds.GetRasterBand(4).WriteArray( opaque ) by using gdal? Because, if I'm right, this snippet from the FAQ is deprecated. Regards Jorge Jorge escribió: Hello everybody I'm creating a blank raster from scratch, to rasterize it later. Ok, I've read the FAQ: http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedonavectorfilesextentsforusewithgdal_rasterize I've executed this code with no problems in a Mac, with Leopard. I've used the frameworks at http://www.kyngchaos.com/ software:frameworks. The version of GDAL is 1.6.0, and the numpy version is 1.0.1 Now, I try to execute the code in another machine, a PC with Suse Linux Enterpise 11.0 for 64bits processors. I've installed gdal and numpy from repositories. The version of GDAL is 1.6.0, and numpy version is 1.2.1 So, the gdal versions are the same. But if I open, for example, the file ogr.py in both systems, are different files. Maybe the Framework I'm using is a port of GDAL 1.6.0 to Mac with any changes? And another issue: the code fails in the PC with Suse. The first error is: src_lyr = src_ds.GetLayerByIndex( index = 0 ) AttributeError: DataSource instance has no attribute 'GetLayerByIndex' I could solve the problem by changing the call to "GetLayerByIndex( index = 0 )" for "GetLayer( 0 )". Why is this happening, if the version of GDAL is 1.6.0 on both systems? Again, I think that maybe the Framework I'm using is a port of GDAL 1.6.0 to Mac with any changes. Then, made this change, I get another error, that I couldn't solve yet (create_raster.py is the name of my file): File "./create_raster.py", line 112, in ? dst_ds.GetRasterBand(1).WriteArray( zeros ) File "/usr/lib64/python2.4/site-packages/gdal.py", line 876, in WriteArray return gdalnumeric.BandWriteArray( self, array, xoff, yoff ) File "/usr/lib64/python2.4/site-packages/gdalnumeric.py", line 193, in BandWriteArray datatype = NumericTypeCodeToGDALTypeCode( array.typecode() ) AttributeError: 'numpy.ndarray' object has no attribute 'typecode' So, basically, the method "BandWriteArray" of gdalnumeric.py is expecting an object array, with a method named "typecode()", but the array created with numpy.zeros, don't have this attribute. Am I right? Then, the fact is that in version 1.0.1 of numpy, the array created with numpy.zeros has a method named "typecode()", but in version 1.2.1, this attribute doesn't exist. Do I have to "downgrade" the numpy version from 1.2.1 to 1.0.1 to make the code works in suse? Is there another solution? Sorry for this kind of questions, but I'm very newbie with Python Thanks in advance! Regards Jorge -- "Afirmo con total convicción que la religión cristiana organizada como Iglesia ha sido y es aún la principal enemiga del progreso moral en el mundo" "La religión se basa, pienso, principal y primariamente en el miedo. El miedo es el padre de la crueldad, y por tanto no es sorprendente que crueldad y religión han ido tomadas de la ma
Re: [gdal-dev] erosion/dilation in gdal
> Johan Nouvel wrote: > Hello all, > > Is there a way to do erosion/dilatation on image in gdal ? > > I've looked in alg.h, but I've seen no straight way to do such thing. Johan, On the Python side there is the ndimage package that is included in scipy (http://www.scipy.org/SciPyPackages/Ndimage) that has erosion and dilation functions that you might want to consider. Take a look at binary and grey scale morphology here: http://stsdas.stsci.edu/numarray/numarray-1.5.html/module-numarray.ndimage.h tml If they do what you need, then you can read an image into a numpy array using gdal,perform erosion/dilation, write a new image out with the result and rewrite extent and projection to the image. Vikalpa ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] erosion/dilation in gdal ?
Frank Warmerdam wrote: Johan Nouvel wrote: Hello all, Is there a way to do erosion/dilatation on image in gdal ? I've looked in alg.h, but I've seen no straight way to do such thing. Johan, As you very probably know those are operations of the image processing world. If you don't know it yet have a look at the OpenCV library. It is amazingly fast, but doesn't know anything about coordinates. Joaquim Luis ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] erosion/dilation in gdal ?
Johan Nouvel wrote: Hello all, Is there a way to do erosion/dilatation on image in gdal ? I've looked in alg.h, but I've seen no straight way to do such thing. Johan, I am not aware of anything intended specifically for this. There is the raster fill algorithm which can "grow" an image by a specific amount. Best regards, -- ---+-- I set the clouds in motion - turn up | Frank Warmerdam, warmer...@pobox.com light and sound - activate the windows | http://pobox.com/~warmerdam and watch the world go round - Rush| Geospatial Programmer for Rent ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Transformation from WGS84 to Cape Datum
Dear list I have a shapefile with the following projection, see below (using 'ogrinfo -al Richmond_compartments_WGS84.shp') I would like to perform a datum transformation from WGS84 to the Cape Datum using the clark 1880 spheroid. Is this possible using ogr? I have tried using ogr2ogr but have had no luck as I am not sure how to specify the correct projection parameters and am not sure if ogr supports the Cape Datum and clark 1880 spheroid. One error I receive is that the program fails to initialise PROJ.4. I have installed PROJ.4 prior to my grass instillation so it should be there. Could someone point me towards a tutorial or help file describing the supported datums and spheroids or give an example of the syntax used. Many thanks, Wesley ** INFO: Open of `Richmond_compartments_WGS84.shp' using driver `ESRI Shapefile' successful. Layer name: Richmond_compartments_WGS84 Geometry: Polygon Feature Count: 2798 Extent: (-101046.795901, -3391548.960746) - (-58458.688098, -3267168.091898) Layer SRS WKT: PROJCS["STMLO31", GEOGCS["WGS84", DATUM["WGS84", SPHEROID["WGS84",6378137.0,298.25722358]], PRIMEM["Greenwich",0.0], UNIT["degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"], PARAMETER["False_Easting",0.0], PARAMETER["False_Northing",0.0], PARAMETER["Central_Meridian",31.0], PARAMETER["Scale_Factor",-1.0], PARAMETER["Latitude_of_Origin",0.0], UNIT["Meter",1.0]] ** -- This message is subject to the CSIR's copyright terms and conditions, e-mail legal notice, and implemented Open Document Format (ODF) standard. The full disclaimer details can be found at http://www.csir.co.za/disclaimer.html. This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. MailScanner thanks Transtec Computers for their support. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoJSON from FME
> > I can confirm that FME returns extra bits in GeoJSON output. > As I see, it isn't documented in "FME Readers and Writers" manual, so > little to say. nice to hear i didn't screw it up ! > >> Any of you would know why FME is returning such misformed geoJSON ? > > I would suggest to ask your question on FMETalk > > http://groups.google.com/group/fmetalk nice tip Thanks Guillaume ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Re: Creating a blank raster from scratch
And finally, hello Sorry for being annoying. I've found this ticket closed 2 years ago http://trac.osgeo.org/gdal/ticket/1166. I'll apply the patch, but I think that this should be added with the FAQ. Saves time :-) Best regards Jorge Jorge escribió: > Hello again, > > I' ve found the problem, I think. Is the version of numpy used by > gdalnumeric. The code from FAQ works with numpy version 1.0.1, but fails > with numpy version 1.2.1. The fail is because the narray attribute > "typecode()" doesn't exist. From the numpy book, available at > http://numpy.scipy.org/numpybook.pdf, you can get (page 55): > > "If you are converting code from Numeric, then you > will need to make the following (search and replace) > conversions: .typecode() --> .dtype.char; > .iscontiguous() --> .flags.contiguous; > .byteswapped() --> .byteswap(); .toscalar() > --> .item(); and .itemsize() --> .itemsize. The > numpy.oldnumeric.alter code1 module can automate this for you." > > Ok. I've opened gdalnumeric.py, and the last change was from 2006/03/21. > The older version from numpy available at sourceforge download's page is > from 2007-11-08. Then, gdal is using a really old version of numpy. > Maybe I can use the numpy 1.0.1 from my mac, but I think that it would > be easier to replace the snippet's code lines that uses numpy from the > correct ones. What's the best way to do this > > # Create blank raster with fully opaque alpha band > zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 ) > dst_ds.GetRasterBand(1).WriteArray( zeros ) > dst_ds.GetRasterBand(2).WriteArray( zeros ) > dst_ds.GetRasterBand(3).WriteArray( zeros ) > opaque = numpy.zeros((tiff_height,tiff_width), numpy.uint8 )*255 > dst_ds.GetRasterBand(4).WriteArray( opaque ) > > by using gdal? Because, if I'm right, this snippet from the FAQ is > deprecated. > > Regards > Jorge > > Jorge escribió: > >> Hello everybody >> >> I'm creating a blank raster from scratch, to rasterize it later. Ok, >> I've read the FAQ: >> >> http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedonavectorfilesextentsforusewithgdal_rasterize >> >> I've executed this code with no problems in a Mac, with Leopard. I've >> used the frameworks at http://www.kyngchaos.com/software:frameworks. The >> version of GDAL is 1.6.0, and the numpy version is 1.0.1 Now, I try to >> execute the code in another machine, a PC with Suse Linux Enterpise 11.0 >> for 64bits processors. I've installed gdal and numpy from repositories. >> The version of GDAL is 1.6.0, and numpy version is 1.2.1 So, the gdal >> versions are the same. But if I open, for example, the file ogr.py in >> both systems, are different files. Maybe the Framework I'm using is a >> port of GDAL 1.6.0 to Mac with any changes? >> >> And another issue: the code fails in the PC with Suse. The first error is: >> >> src_lyr = src_ds.GetLayerByIndex( index = 0 ) >> AttributeError: DataSource instance has no attribute 'GetLayerByIndex' >> >> I could solve the problem by changing the call to "GetLayerByIndex( >> index = 0 )" for "GetLayer( 0 )". Why is this happening, if the version >> of GDAL is 1.6.0 on both systems? Again, I think that maybe the >> Framework I'm using is a port of GDAL 1.6.0 to Mac with any changes. >> >> Then, made this change, I get another error, that I couldn't solve yet >> (create_raster.py is the name of my file): >> >> File "./create_raster.py", line 112, in ? >> dst_ds.GetRasterBand(1).WriteArray( zeros ) >> File "/usr/lib64/python2.4/site-packages/gdal.py", line 876, in WriteArray >> return gdalnumeric.BandWriteArray( self, array, xoff, yoff ) >> File "/usr/lib64/python2.4/site-packages/gdalnumeric.py", line 193, in >> BandWriteArray >> datatype = NumericTypeCodeToGDALTypeCode( array.typecode() ) >> AttributeError: 'numpy.ndarray' object has no attribute 'typecode' >> >> So, basically, the method "BandWriteArray" of gdalnumeric.py is >> expecting an object array, with a method named "typecode()", but the >> array created with numpy.zeros, don't have this attribute. Am I right? >> Then, the fact is that in version 1.0.1 of numpy, the array created with >> numpy.zeros has a method named "typecode()", but in version 1.2.1, this >> attribute doesn't exist. Do I have to "downgrade" the numpy version from >> 1.2.1 to 1.0.1 to make the code works in suse? Is there another >> solution? Sorry for this kind of questions, but I'm very newbie with Python >> >> Thanks in advance! >> >> Regards >> Jorge >> >> >> >> >> >> >> > > -- "Afirmo con total convicción que la religión cristiana organizada como Iglesia ha sido y es aún la principal enemiga del progreso moral en el mundo" "La religión se basa, pienso, principal y primariamente en el miedo. El miedo es el padre de la crueldad, y por tanto no es sorprendente que crueldad y religión han ido tomadas de la mano. La ciencia puede ayudarnos a superar este cobarde temor
[gdal-dev] Re: Creating a blank raster from scratch
Hello again, I' ve found the problem, I think. Is the version of numpy used by gdalnumeric. The code from FAQ works with numpy version 1.0.1, but fails with numpy version 1.2.1. The fail is because the narray attribute "typecode()" doesn't exist. From the numpy book, available at http://numpy.scipy.org/numpybook.pdf, you can get (page 55): "If you are converting code from Numeric, then you will need to make the following (search and replace) conversions: .typecode() --> .dtype.char; .iscontiguous() --> .flags.contiguous; .byteswapped() --> .byteswap(); .toscalar() --> .item(); and .itemsize() --> .itemsize. The numpy.oldnumeric.alter code1 module can automate this for you." Ok. I've opened gdalnumeric.py, and the last change was from 2006/03/21. The older version from numpy available at sourceforge download's page is from 2007-11-08. Then, gdal is using a really old version of numpy. Maybe I can use the numpy 1.0.1 from my mac, but I think that it would be easier to replace the snippet's code lines that uses numpy from the correct ones. What's the best way to do this # Create blank raster with fully opaque alpha band zeros = numpy.zeros( (tiff_height, tiff_width), numpy.uint8 ) dst_ds.GetRasterBand(1).WriteArray( zeros ) dst_ds.GetRasterBand(2).WriteArray( zeros ) dst_ds.GetRasterBand(3).WriteArray( zeros ) opaque = numpy.zeros((tiff_height,tiff_width), numpy.uint8 )*255 dst_ds.GetRasterBand(4).WriteArray( opaque ) by using gdal? Because, if I'm right, this snippet from the FAQ is deprecated. Regards Jorge Jorge escribió: > Hello everybody > > I'm creating a blank raster from scratch, to rasterize it later. Ok, > I've read the FAQ: > > http://trac.osgeo.org/gdal/wiki/FAQRaster#HowcanIcreateablankrasterbasedonavectorfilesextentsforusewithgdal_rasterize > > I've executed this code with no problems in a Mac, with Leopard. I've > used the frameworks at http://www.kyngchaos.com/software:frameworks. The > version of GDAL is 1.6.0, and the numpy version is 1.0.1 Now, I try to > execute the code in another machine, a PC with Suse Linux Enterpise 11.0 > for 64bits processors. I've installed gdal and numpy from repositories. > The version of GDAL is 1.6.0, and numpy version is 1.2.1 So, the gdal > versions are the same. But if I open, for example, the file ogr.py in > both systems, are different files. Maybe the Framework I'm using is a > port of GDAL 1.6.0 to Mac with any changes? > > And another issue: the code fails in the PC with Suse. The first error is: > > src_lyr = src_ds.GetLayerByIndex( index = 0 ) > AttributeError: DataSource instance has no attribute 'GetLayerByIndex' > > I could solve the problem by changing the call to "GetLayerByIndex( > index = 0 )" for "GetLayer( 0 )". Why is this happening, if the version > of GDAL is 1.6.0 on both systems? Again, I think that maybe the > Framework I'm using is a port of GDAL 1.6.0 to Mac with any changes. > > Then, made this change, I get another error, that I couldn't solve yet > (create_raster.py is the name of my file): > > File "./create_raster.py", line 112, in ? > dst_ds.GetRasterBand(1).WriteArray( zeros ) > File "/usr/lib64/python2.4/site-packages/gdal.py", line 876, in WriteArray > return gdalnumeric.BandWriteArray( self, array, xoff, yoff ) > File "/usr/lib64/python2.4/site-packages/gdalnumeric.py", line 193, in > BandWriteArray > datatype = NumericTypeCodeToGDALTypeCode( array.typecode() ) > AttributeError: 'numpy.ndarray' object has no attribute 'typecode' > > So, basically, the method "BandWriteArray" of gdalnumeric.py is > expecting an object array, with a method named "typecode()", but the > array created with numpy.zeros, don't have this attribute. Am I right? > Then, the fact is that in version 1.0.1 of numpy, the array created with > numpy.zeros has a method named "typecode()", but in version 1.2.1, this > attribute doesn't exist. Do I have to "downgrade" the numpy version from > 1.2.1 to 1.0.1 to make the code works in suse? Is there another > solution? Sorry for this kind of questions, but I'm very newbie with Python > > Thanks in advance! > > Regards > Jorge > > > > > > -- "Afirmo con total convicción que la religión cristiana organizada como Iglesia ha sido y es aún la principal enemiga del progreso moral en el mundo" "La religión se basa, pienso, principal y primariamente en el miedo. El miedo es el padre de la crueldad, y por tanto no es sorprendente que crueldad y religión han ido tomadas de la mano. La ciencia puede ayudarnos a superar este cobarde temor en que ha vivido la humanidad por tantas generaciones." (Bertrand Russell) ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] erosion/dilation in gdal ?
- Original Message - From: "Johan Nouvel" To: Sent: Tuesday, February 03, 2009 12:00 PM Subject: [gdal-dev] erosion/dilation in gdal ? Hello all, Is there a way to do erosion/dilatation on image in gdal ? I've looked in alg.h, but I've seen no straight way to do such thing. Any idea ? Best way should be using third party (e.g. GIMP can do even batch mode in CLI) or imagemagick, but first you want to save spatial information with 'listgeo' than restore it back after mangling the data as plain 'picture' with 'geotiffcp'. http://svn.osgeo.org/metacrs/geotiff/trunk/libgeotiff/docs/listgeo.html Its an idea. /Cristian. ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] GeoJSON from FME
Guillaume Sueur wrote:
Hi list,
I'm trying to feed my app with a geoJSON file generated by FME, which
then should be translated to postGIS by ogr. But the FME GeoJSON looks
suspicious, as it begins by :
{"LIEU_Geocodes_new":{"type":"FeatureCollection"
where LIEU_Geocodes_new is the name of the original MapInfo file
processed to geoJSON by FME.
this global object is out of the geoJSON specifications, and makes ogr
fail to translate the file. If I just remove this encapsulation, it goes
well.
Guillaume,
I can confirm that FME returns extra bits in GeoJSON output.
As I see, it isn't documented in "FME Readers and Writers" manual, so
little to say.
Any of you would know why FME is returning such misformed geoJSON ?
I would suggest to ask your question on FMETalk
http://groups.google.com/group/fmetalk
Best regards,
--
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] erosion/dilation in gdal ?
Hello all, Is there a way to do erosion/dilatation on image in gdal ? I've looked in alg.h, but I've seen no straight way to do such thing. Any idea ? Regards, Johan. -- Johan Nouvel, R&D Engineer http://www.archivideo.com tel : +33 (0)2 99 86 30 20 ARCHIVIDEO, 40 rue des Veyettes, 35000 RENNES, FRANCE ___ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [Gdal-dev] transform point problem using gdal 1.5 with osr
I'm having the same problem. I tried another way according to one example I
found, which doesn't work either:
from osgeo import ogr, osr
# Get the geometry object
ds = ogr.Open("inFile.shp")
layer = ds.GetLayer()
feature = layer.GetNextFeature()
geom = feature.GetGeometryRef()
# Get the coordinate systems and transform
inSR = osr.SpatialReference()
inSR.GetGeometryRef() # this is WGS84
outSR = osr.SpatialReference()
outSR.ImportFromEPSG(2400) # RT90 (Sweden)
coordTrans = osr.CoordinateTransformation(inSR, outSR)
geom.Transform(coordTrans)
Results in the following error message:
TypeError: in method 'Geometry_Transform', argument 2 of type
'OSRCoordinateTransformationShadow *'
prairie Last wrote:
>
> I am trying to tranform one coordinate system to another (wgs84 to utm).
> Found one example on the internet (adapted a little). It got an error when
> I
> try to run the program. Since I am new to GDAL, I cannot figure out how to
> correct this. Please see the following program. I also tried to add one
> more
> value to "res.ct.TransformPoint(lon, lat)", but it did not solve the
> problem. Any help or hint appreciated. I also attach the error to the
> end.
>
> from osgeo import osr
> import math
> import pyproj
>
> def UTMZone(lon, lat):
> return int((lon + 180) / 6) + 1
> if __name__ == '__main__':
> lat = 41.395304
> lon = 73.310067
>
> wgs84 = osr.SpatialReference()
> utm = osr.SpatialReference()
> wgs84.ImportFromProj4("+proj=latlong +datum=WGS84")
> utm.ImportFromProj4("+proj=utm +zone="+str(UTMZone(lon,lat))+"
> +datum=WGS84")
> ct = osr.CoordinateTransformation(wgs84,utm)
> res= ct.TransformPoint(lon, lat)
> print res
>
>
>
>
>
> Error Message:
>
> Traceback (most recent call last):
> File "C:\Python25\trans.py", line 28, in
> res= ct.TransformPoint(lon, lat)
> File "C:\Python25\lib\site-packages\osgeo\osr.py", line 602, in
> TransformPoint
> return _osr.CoordinateTransformation_TransformPoint(*args)
> NotImplementedError: Wrong number of arguments for overloaded function
> 'CoordinateTransformation_TransformPoint'.
> Possible C/C++ prototypes are:
> TransformPoint(double [3])
> TransformPoint(double [3],double,double,double)
>
> ___
> gdal-dev mailing list
> gdal-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
--
View this message in context:
http://n2.nabble.com/transform-point-problem-using-gdal-1.5-with-osr-tp2036503p2262370.html
Sent from the GDAL - Dev mailing list archive at Nabble.com.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] GeoJSON from FME
Hi list,
I'm trying to feed my app with a geoJSON file generated by FME, which
then should be translated to postGIS by ogr. But the FME GeoJSON looks
suspicious, as it begins by :
{"LIEU_Geocodes_new":{"type":"FeatureCollection"
where LIEU_Geocodes_new is the name of the original MapInfo file
processed to geoJSON by FME.
this global object is out of the geoJSON specifications, and makes ogr
fail to translate the file. If I just remove this encapsulation, it goes
well.
Any of you would know why FME is returning such misformed geoJSON ?
Regards
Guillaume Sueur
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
