I also should note, that when trying to apply mutliple -dsco options I have
used this syntax:
ogr2ogr -f GML test.gml shape_folder -dsco PREFIX=tst -dsco
TARGET_NAMESPACE=http://tst.com.au/
In the case above neither the PREFIX or TARGET_NAMESPACE seem to get set in
the output.
--
View this mes
I'm trying to convert some shapefiles to GML using both ogr2ogr and python
code. In both cases I'm having trouble making the 'dataset creation options'
work preoperly.
Setting the XSISCHEMAURI seems to work. i.e
/ogr2ogr -f GML test.gml shape_folder -dsco XSISCHEMAURI=http:\\mytest.com/
If I set
Hi,
gdalinfo 27002570PAS_dem.tif tells me:
...
PARAMETER["false_easting",6458320.41666],
...
UNIT["us_survey_feet",0.3048006096012192],
gdalwarp 27002570PAS_dem.tif out.tif -t_srs epsg:4326 tells me in DEBUG
mode:
OGRCT: Source: +proj=lcc +lat_1=40.97
+lat_2=39.93
Hi Even
Cool stuff!
Unfortunately Yahoo cut the free geocoding service and offers now paid-only
"BOSS" services...
Yours, Stefan
2012/12/30 Even Rouault
> Hi all,
>
> A new API has been added to GDAL/OGR to use geocoding services, such as
> OpenStreetMap Nominatim, MapQuest Nominatim, Yahoo!
Hi Frank,
it’s nice to hear that the intention/plan is to have a consistent encoding
for all strings.
When I did my own C# wraps of the C API to circumvent the problem with the
current C# wrapper I did some experimenting.
Although you wouldn't normally have any non ASCII characters in WKT strings
On Wed, Apr 3, 2013 at 12:54 PM, Tamas Szekeres wrote:
> Frank,
>
> We seem to consider only a subset of the parameters (filenames and fileds)
> that should be utf8 encoded. But it seems that's not enough. For example
> treating fields as utf8 would also require to modify SetAttibuteFilter to
> p
Frank,
We seem to consider only a subset of the parameters (filenames and fileds)
that should be utf8 encoded. But it seems that's not enough. For example
treating fields as utf8 would also require to modify SetAttibuteFilter to
provide match with the same value returned from GetFieldAsString. In
Guys,
Certainly the intention of RFC 23:
http://trac.osgeo.org/gdal/wiki/rfc23_ogr_unicode
Was that we consider OGR string fields to be utf8 and I believe that should
be the default assumption.
Best regards,
Frank
On Wed, Apr 3, 2013 at 12:17 PM, rburhum wrote:
> Hello Tamas and Dennis,
Hello Tamas and Dennis,
This is my personal opinion and there may tons of people that disagree, but
I think it is more sane to always assume UTF8 encoding. There is
functionality among the various drivers to accept/return strings in
different encodings (through the CPL_Recode mechanism) but they a
Hi,
What is the MSVC and the SWIG version are you using? I confirm
MSVC2003/2005/2008/2010 + SWIG1.3.39 compiles successfully.
Best regards,
Tamas
2013/4/3 Finegan Thomas-QTF001
> Hello,
>
> On Windows, none of the swig interfaces are built with the default target.
> I have to “cd swig
Hi,
I've downloaded the file 27002570PAS_dem.zip from
ftp://pamap.pasda.psu.edu/pamap_lidar/cycle1/DEM/South/2008/2000/ and have
attempted to warp the data to WGS84 using gdalwarp. The output should be
around 75W but is being warped to 91W. I'm using gdalwarp 1.9.2 which was
installed as
Howdy, just wondering if anyone has a plugin DLL or dylib of the GDAL DDS
driver handy they could share?
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hello,
On Windows, none of the swig interfaces are built with the default target. I
have to "cd swig" then run nmake from there. Is there a reason the C# and other
wrappers are not built by default?
On Windows, when I run nmake from the swig directory I get:
osr\OsrPINVOKE.cs(192,10): error CS0
Thanks Even,
The 10 char limit on fields names with shapefiles is a problem in my case.
So I will try the VRT format as you have suggested.
Are shapefile and VRT the only formats that can be represented as a multi
layer datasource?
Again - thanks for your help.
--
View this message in context
Selon Matt L :
> Hi Everyone,
>
> I am attempting to use ogr2ogr to convert GeoJSON to GML. It works well for
> a single json file. But I would like to convert several files, such that
> each input file ends up as a separate layer in a single GML output file.
>
> The GML help doc seems to suggest
Hi Everyone,
I am attempting to use ogr2ogr to convert GeoJSON to GML. It works well for
a single json file. But I would like to convert several files, such that
each input file ends up as a separate layer in a single GML output file.
The GML help doc seems to suggest that GML can be written with
Tamas,
If you don't mind me asking, what exactly is your plan?
Are you planning to just fix the methods related to setting and getting of
feature string attributes or are you planning to use UTF8 encoding for other
methods too?
This is a very delicate problem, because if we assume that an unmana
That would great Tamas, Thanks.
And Thanks to Ragi for you input.
I had a look at you workaround, but I think your ghetto fix is not quite correct.
The C# wrapper interprets the unmanaged string as being ANSI encoded, which changes the bytes of the string when converting from ANSI to UTF16 an
18 matches
Mail list logo
