Le jeudi 08 mai 2014 00:54:50, scottm361 a écrit :
> Hi Even
>
> Thanks for the reply.
>
> the command I am using does use clipping, but not spatial filtering:
>
> gdal\apps\ogr2ogr.exe -overwrite -t_srs
> "layers\NFI_MODIS250m_kNN_Structure_Stand_Age_v0.prj" -clipdst -260
> 570 310
Hi Even
Thanks for the reply.
the command I am using does use clipping, but not spatial filtering:
gdal\apps\ogr2ogr.exe -overwrite -t_srs
"layers\NFI_MODIS250m_kNN_Structure_Stand_Age_v0.prj" -clipdst -260
570 310 1050 -skipfailures
".\temp\nfdb_poly_20111223_21094F1A58AE467E\n
Le mercredi 07 mai 2014 20:30:45, scottm361 a écrit :
> I am a developer on an application that will potentially use ogr2ogr to
> re-project shapefiles (and potentially other ogr supported formats)
>
> What I am wondering about is the nature of geometry error handling in
> ogr2ogr. My assumption
Hi,
This is a call for discussion on "RFC 46: GDAL/OGR unification"
http://trac.osgeo.org/gdal/wiki/rfc46_gdal_ogr_unification
Best regards,
Even
--
Geospatial professional services
http://even.rouault.free.fr/services.html
___
gdal-dev mailing li
I am a developer on an application that will potentially use ogr2ogr to
re-project shapefiles (and potentially other ogr supported formats)
What I am wondering about is the nature of geometry error handling in
ogr2ogr. My assumption is that geometry errors are quite common in user
supplied data,
Le mercredi 07 mai 2014 12:30:04, Jukka Rahkonen a écrit :
> mccorb cox.net> writes:
> > I have shape files that I am wanting to convert to a GML equivalent file.
> > I understand how to use the shape file .PRJ files and EPSG info to
> > translate coordinate systems and all that is working well.
>
mccorb cox.net> writes:
>
> I have shape files that I am wanting to convert to a GML equivalent file. I
> understand how to use the shape file .PRJ files and EPSG info to translate
> coordinate systems and all that is working well.
>
> However, once converted the coordinates are correct but th
