Seems the problem is in the python module build. I think I've been here
before 😥
On Wed, Jan 16, 2019, 6:47 PM Andrew Bell Seems strange that configure would place other directories before the
> location for the current source tree. Is this by design? Is there a way to
> change the behavior?
>
>
Seems strange that configure would place other directories before the
location for the current source tree. Is this by design? Is there a way to
change the behavior?
On Wed, Jan 16, 2019, 6:22 PM Even Rouault On mercredi 16 janvier 2019 17:41:26 CET Andrew Bell wrote:
> > I'm trying to build GDAL
On mercredi 16 janvier 2019 17:41:26 CET Andrew Bell wrote:
> I'm trying to build GDAL master branch with the python wrappers and I'm
> getting an error on OSX with clang:
>
>
>
> creating build/temp.macosx-10.7-x86_64-3.6
> creating build/temp.macosx-10.7-x86_64-3.6/extensio
I'm trying to build GDAL master branch with the python wrappers and I'm
getting an error on OSX with clang:
creating build/temp.macosx-10.7-x86_64-3.6
creating build/temp.macosx-10.7-x86_64-3.6/extensions
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g
-f
Hi Even,
st 16. 1. 2019 v 18:20 odesílatel Even Rouault
napsal:
> for complex GML features, use https://www.gdal.org/drv_gmlas.html
thanks, will try. Ma
--
Martin Landa
http://geo.fsv.cvut.cz/gwiki/Landa
http://gismentors.cz/mentors/landa
___
gdal-de
Hi,
st 16. 1. 2019 v 18:16 odesílatel Martin Landa napsal:
> Two geometries are missing:
>
> """
> -552916.13 -1200482.68
> -552916.08 -1200482.70
> """
Correction, it seems that GDAL takes the last geometry:
POINT (-552916.08 -1200482.7)
"""
Martin,
for complex GML features, use https://www.gdal.org/drv_gmlas.html
Even
--
Spatialys - Geospatial professional services
http://www.spatialys.com
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-de
Hi,
it seems that GDAL skips geometry when reading nested objects. See [1].
ogrinfo -ro ~/Downloads/example.gml -al
"""
GRFeature(CIZI_Bod):0
gml_id (String) = CE-20190114-74D6E69478BD4640AAD0D0E780F28A0C
OGC_ANGLE (Real) = 0.026859
OGC_ANGLE_uom (String) = radian
typ (String) = A
pop
Alan,
Did you used --without-libtool on ./configure?
If you do that, I believe that the file ./apps/gdalinfo and all other
executables will be real executables and the makefiles will call
"install_name_tool" to register the libgdal.dylib on the executables. In that
case DYLD_LIBRARY_PATH will
I'm using this python API, I didn't know theses tests which do help (as the
python API is not as documented as the c++ API).
I feel we're off topic here so I'll publish it soon in another thread in
the gdal-dev list.
Thanks!
On Wed, 16 Jan 2019 at 13:36, Even Rouault
wrote:
> On mercredi 16 janv
On mercredi 16 janvier 2019 12:59:51 CET Idan Miara wrote:
> Even,
> Thanks for your pointer!
> It does solve the problem for me!
>
> Andrea,
> Thanks for you input!
> Should I find the time to look into these issues I'll contact you.
>
> I'm working on a python wrapper for gdal translate/wrap/in
David,
>
> Thanks for sharing the updated sample product with srs info included.
>
> I was able to mimic you polygon formatting in the attached TEST.nc file.
> Unfortunately I was not able to get the srs info captured in my shape file
> when applying ogr2ogr.
> I am using the same crs I used suc
12 matches
Mail list logo
