Unfortunately, this turned out to be more of a heartburn than expected. Here is what I found (caution -- editorializing and personal opinion follows, so take it with a spoon of NaCl)
On 8/15/06, Frank Warmerdam <[EMAIL PROTECTED]> wrote:
P Kishor wrote: >> cd "C:\My Documents\resources" >> less foo.ovf > <OGRVRTDataSource> > <OGRVRTLayer name="foo"> > <SrcDataSource>"C:\\My Documents\\Data\\foo.csv"</SrcDataSource> > <SrcLayer>foo</SrcLayer> > <GeometryField encoding="PointFromColumns" x="LONGITUDE" y="LATITUDE"/> > <GeometryType>wkbPoint</GeometryType> > </OGRVRTLayer> > </OGRVRTDataSource> > >> less proj.txt > PROJCS['USA_Contiguous_Lambert_Conformal_Conic',GEOGCS['GCS_Nor... > >> cd "C:\My Documents\Data" >> less foo.csv > ID,A,B,C,D,E,LONGITUDE,LATITUDE,F > 1,10,,,,,-106.524288,35.139437, > 2,10,,,,,-106.522907,35.132337, > 3,10,,,,,-106.519838,35.148427, > >> cd "C:\My Documents\Home" >> ogr2ogr -f "ESRI Shapefile" \ > -a_srs "C:\\My Documents\\resources\\proj.txt" \ > -t_srs "C:\\My Documents\\resources\\proj.txt" \ > foo_shapefile \ > "C:\\My Documents\\resources\\foo.ovf" > > Couldn't run: ogr2ogr -f "ESRI Shapefile" -a_srs "C:/My > Documents/resources/proj.txt" -t_srs "C:/My > Documents/resources/proj.txt" foo_shapefile "C:/My > Documents/resources/foo.ovf" (No such file or directory) > > I can't tell whether ogr2ogr can't file 'foo.ovf', or it can't find > the files referenced inside 'foo.ovf', or if I have something else > wrong altogether. Puneet, I'm guessing this is mostly some sort of shell quoting problem. I will add that you shouldn't use double backslashes to escape backslashes in a .ovf file. OVF files are XML and would only need XML styling escaping internally. So the SrcDataSource line should read: <SrcDataSource>"C:\My Documents\Data\foo.csv"</SrcDataSource> I would encourage you to try your experiment in a path with no spaces so you don't need so much quoting.
The only way I was able to get ogr2ogr to respond was by -- 1. Naming my input file foo.csv (extension .csv). Don't know if this was a categorical reason for failing or not, but doing so made me "safe." If ogr2ogr won't really won't recognize CSV files unless they are named .csv then, imho, that is not very good. 2. Storing the .csv as well as the corresponding .ovf in a path with no spaces. This was definitely a categorical reason for failing. I brought both my .ovf and .csv files to a location which had no spaces, and then it worked as a test. This, again, imho, is really bad. Because of project constraints, I really can't put these files anywhere I want to, so I really can't use ogr2ogr. 3. Quoting the source definition path in the command C:\>ogr2ogr -f "ESRI Shapefile" foo "C:\foo.ovf" This was really strange. If I didn't surround "C:\foo.ovf" above with the double quotes, ogr2ogr would fail. Quoting as above made it work. 4. Not quoting the source path in the .ovf file (see SrcDataSource below) <OGRVRTDataSource> <OGRVRTLayer name="foo"> <SrcDataSource>C:\foo.csv</SrcDataSource> <SrcLayer>spottings_geocoded_good</SrcLayer> <GeometryField encoding="PointFromColumns" x="LONGITUDE" y="LATITUDE"/> <GeometryType>wkbPoint</GeometryType> </OGRVRTLayer> </OGRVRTDataSource> Even more bizarre. NOT QUOTING C:\foo.csv in the line <SrcDataSource>C:\foo.csv</SrcDataSource> was very important. If I quoted it, ogr2ogr would croak. Not very consistent and helpful, but it actually worked. So that was encouraging. Next task was to add the srs_def. I am running this command from within a Perl script via a system call. My srs_def is stored as a variable. If I stored it as a Heredoc variable to make it legible, ogr2ogr would fail. In other words, the following caused it to complain about bad srs_def. $srs = <<END; PROJCS[ 'USA_Contiguous_Lambert_Conformal_Conic', GEOGCS[ 'GCS_North_American_1983', ... END So, I changed the above to a single line like so $srs = "PROJCS['USA_Contiguous_Lambert_Co..." and then I got ERROR 6: Failed to initialize PROJ.4 with `+ellps=GRS80 +units=m +no_defs '. projection not named Failed to create coordinate transformation between the following coordinate systems. This may be because they are not transformable, or because projection services (PROJ.4 DLL/.so) could not be loaded. At that point I gave up and went back to ArcGIS where it worked just fine. Sigh. Anyway, I will add the above notes on the MapServer wiki. Hopefully, someone will save some time and zantac somewhere. -- Puneet Kishor http://punkish.eidesis.org/ Nelson Inst. for Env. Studies, UW-Madison http://www.ies.wisc.edu/ Open Source Geospatial Foundation https://edu.osgeo.org/
