This looks like a problem in ogr-to-osm, not related to
GDAL/OGR. These segment/node IDs appear to be created internal
to the script and are not related to GDAL/OGR. I would recommend
going to an OpenStreetMap list of some sort to ask this
particular question.
-- Chris
On Feb 26, 2011, at 12:37
Hi all,
We're having this problem when we run ogr-to-osm.py. (from
http://svn.openstreetmap.org/applications/utils/import/ogr2osm/) I don't
know much about python, so the problem could be obvious. Any help would be
appreciated. Thank you.
G:\PUBLIC\OpenStreetMap\tools\
ogr-to-osm>.\run.bat -e 432
Le vendredi 25 février 2011 22:09:01, Gauthier,Jean-Philippe [CMC] a écrit :
> Hi all,
>
> I think there might be a bug with the OGR_DS_ExecuteSQL call in gdal 1.8,
> this worked fine with 1.7 and I see you`ve rebuilt the SQL part.
>
> I've tried a select on a CANVEC layer which looks something l
Hi all,
I think there might be a bug with the OGR_DS_ExecuteSQL call in gdal 1.8, this
worked fine with 1.7 and I see you`ve rebuilt the SQL part.
I've tried a select on a CANVEC layer which looks something like this:
ogrinfo CanVec/031/h/031h05/031h05_6_0_BS_2010009_2.shp -sql "SELEC
A custom build of fwtools sounds like the perfect solution, here. Then my
bootstrap procedure consists of downloading my FWTools build, opening it up,
running ./install.sh and adding the directory to the path (to allow access
to the libraries).
Thanks, Even, this is great!
On Fri, Feb 25, 2011 at
Le vendredi 25 février 2011 21:02:06, Sam Ritchie a écrit :
> Even,
>
> Thanks for the response, and sorry for my late reply, here.
>
> What you write makes sense, especially after processing this problem a bit
> further. As you mentioned, libgdal1- was installed by apt-get... the
> problem h
Even,
Thanks for the response, and sorry for my late reply, here.
What you write makes sense, especially after processing this problem a bit
further. As you mentioned, libgdal1- was installed by apt-get... the
problem here is that apt-get has libgdal1-1.5.0, and I was building java
bindings f
Thank you, Frank.
Shawn
From: gdal-dev-boun...@lists.osgeo.org [gdal-dev-boun...@lists.osgeo.org] On
Behalf Of Frank Warmerdam [warmer...@pobox.com]
Sent: Thursday, February 24, 2011 4:31 PM
To: gdal-dev@lists.osgeo.org
Subject: Re: [gdal-dev] image head
Anita,
OGR's shapefile driver is reading the large values correctly is able to
display them with ogrinfo.
However, newly created .dbf files get the value -2147483648.
You can track further development regarding this at
http://trac.osgeo.org/gdal/ticket/3982
On Fri, Feb 25, 2011 at 3:04 AM, Anita
Even,
merci beaucoup for your continuous help and support! Creating the fields
on the target layer and using the feature definition from the target
layer does indeed help :-). I even looked at the corresponding part in
ogr2ogr.py before writing to the list but I didn't realise that this
part
Selon Frank Broniewski :
> Hello,
>
> I have a problem when converting datasources from one format to GML.
> Whenever I export my source datasource to a GML - datasource the
> attributes of the features are missing in the resulting gml file. Other
> exports to formats like shapefile, kml or geojso
Hello,
I have a problem when converting datasources from one format to GML.
Whenever I export my source datasource to a GML - datasource the
attributes of the features are missing in the resulting gml file. Other
exports to formats like shapefile, kml or geojson have the attributes
included.
12 matches
Mail list logo
