P Kishor wrote:
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.
Puneet,
Yes, I believe the extension .csv is required. The problem is that
otherwise, it is very difficult to tell the difference between a
"comma separated value" file, and a text or binary file that just
happens to have some comma characters in it.
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.
If you can provide specific examples of this, I could dig into it.
The intention is certainly that GDAL and OGR path handling should
allow spaces in filenames. But the spaces can be very problematic on
the shell command line.
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.
I find this hard to imagine. I did a quick test with FWTools on windows
and the command:
ogr2ogr -f "ESRI Shapefile" foo C:\warmerda\gdal\data\pcs.csv"
This worked fine. I realize it isn't using an OVF file. If you can
document this in a bug report, I'll try and reproduce it more exactly.
Note that quoting on the commandline is normally just needed to keep
an argument together. So "ESRI Shapefile" needs to be quoted because
it has a space, and the argument is supposed to be just a single
argument. Without quoting it was be passed as two separate arguments.
Keep in mind that commandline quoting requirements are not my fault!
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.
Right, if you quote it, then you are telling OGR to open a filename
that includes quote marks, which it will dutifully try to do.
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
I'm afraid I don't follow the above point. I am guessing this is an
issue with how strings are prepared in perl?
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.
It would seem that a the coordinate system was untranslatable.
I'll grant the error handling could stand some improvement. If
you provide the exact SRS text (was this written to a .prj file?)
I could look into why it might not have worked.
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.
I'm sorry for the pain. The whole OVF mechanism is a bit painful to go
through, and commandline quoting can be a nightmare. There may be a
few bugs in here that can be fixed. If so, I'm keen to do so.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, [EMAIL PROTECTED]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGF, http://osgeo.org
