Hi Maning-
> I tried to decompress the kmz nd converted the doc.kml. ogr2ogr did
> not convert the kml (for good reasons) because it is a mixture of
> placemark, polygons and lines
This is a known limitation of the current driver. I would suggest rearranging
your data into layers comprised of onl
ML as it is part of the specification. How about this: if the document
element _is_ kml and the version _is not_ found or not recognized OGR
issues a warning and proceeds as if the KML were 2.2?
-Chris
Christopher Condit
con...@sdsc.edu
(858) 822-5483
_
Hi Hermann,
> In my context, Lat/Lon values with 6 decimals are just about enough
> precision. I feel that I am pumping a lot of meaningless numbers into
> the kml file, which makes it big. Is there an option to reduce the
> number of decimals for transformed coordinates?
See http://trac.osgeo.or
the dates (which come out as
strings) to actual time stamps.
I wrote something on the wiki about applying styles, but you could
easily adapt this to whatever you need.
http://trac.osgeo.org/gdal/wiki/KML
-Chris
Christopher Condit
con...@sdsc.edu
(858) 822-5483
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
o Ferreira [mailto:ednar...@yahoo.com]
Sent: Wednesday, January 28, 2009 10:20 AM
To: Christopher Condit
Subject: Re: [gdal-dev] ogr2ogr: KML to any format - export fields
Hi!
I really apreciate your attention.
My database will be oracle or postgres. The information in this fields can be
intensamente e num livre abandono à felicidade; isto
>não se perdoa." (Albert Camus)
>
>"Quem confia em traidores a si próprio atraiçoa." (Mariano da Fonseca)
>
>"Há o suficiente no mundo para todas as necessidades humanas, não há o
>suficiente para a cobiça h
elds... This is being worked on.
-Chris
Christopher Condit
con...@sdsc.edu
(858) 822-5483
From: gdal-dev-boun...@lists.osgeo.org
[mailto:gdal-dev-boun...@lists.osgeo.org] On Behalf Of Ednardo Ferreira
Sent: Tuesday, January 27, 2009 11:42 AM
To: gdal-dev@lists.osgeo.org
Subject: [gd
a defect on trac and include the shapefile
2) Email me the shapefile and I'll create the defect
Thanks,
-Chris
Christopher Condit
San Diego Supercomputer Center
858-822-5483
[EMAIL PROTECTED]
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/gdal-dev
looping over
all the children of the layer. I don't know of a quick solution at this time,
but it would be good to get a copy of your sample data (if possible) and file a
ticket against it...
-Chris
Christopher Condit
San Diego Supercomputer Center
858-822-5483
[EMAIL PROTECTED]
___
Hi Mike-
> Thank you for the feedback - I have tried copying the
curl/xdr/pthreads
> headers into the libdap/include folder - and editing the top level
> nmake.opt to DODS_DIR. There just were a number of unclear steps (for
> me) so I'll go back and try again, then report back more completely. I
>
tions for referring to the actual frmts/dods
> directory?
Correct. The makefile for the drivers uses "DODSDIR" to refer to the
directory.
-Chris
Christopher Condit
San Diego Supercomputer Center
858-822-5483
[EMAIL PROTECTED]
___
gdal-dev
Hi Bruce-
The KML driver should behave as follows:
If you define a field using a creation option for NameField (the default
is "Name") then it will be written out as the "Name" element. Likewise
with "Description". You're saying that everything works fine using
ogr2ogr but when you try to create
Hi Craig-
I haven't had any problems building gdal with postgres 8.3 support.
1) What code base are you building with?
2) Can you be more specific about your errors?
Your nmake.opt definition is nearly identical to mine (except for the
location of postgres).
-Chris
From: [EMAI
Hi Tom-
The KML styling has always been problematic because of course everyone
will want something different. I do think this would be a good idea, but
I'm not sure how many folks / organizations are using this kind of setup
now. At my institution we typically write an XSL stylesheet to
postprocess
8 7:13 PM
> To: Christopher Condit
> Cc: Denis Nadeau; gdal-dev@lists.osgeo.org
> Subject: RE: [gdal-dev] netcdf driver
>
> I think the source of the problem in ticket #2492 is not a GDAL
defect,
> but that the variable in the connection string is "u.u". The
.operator
>
Hi Denis-
I put this patch in a few months ago addressing this libdap 3.8 issue:
http://trac.osgeo.org/gdal/ticket/2404
This will get the code to build against libdap3.8 (primarily a namespace
problem), but there are still issues accessing DODS datasources:
http://trac.osgeo.org/gdal/ticket/249
16 matches
Mail list logo
