While I'm not GDAL developer or regular contributor (submitted only
few patches),
but still often build GDAL trunk on WIndows and Linux, and less often on Mac.
Personally I think that solution proposed in
https://trac.osgeo.org/gdal/ticket/7080
is more preferable. It does not require *all* depende
Hi John,
The CMake don't required complete restructure the GDAL project. But I
think this changes needed to fit new classes inheritance introduced in
GDAL 2.0. And new sources structure more closer to CMake needs.
Also I would like to note that I have only positive experience with
CMake, esp
Hi Brad.
Yes you are right. Just do this steps:
|git clone https://github.com/nextgis-borsch/lib_gdal.git gdal cd gdal
mkdir build cd build cmake .. cmake --build .|
Some discussion was in this ticket
(https://github.com/nextgis-borsch/lib_gdal/issues/13).
There are 3 scenarios supported b
I have my own build system for GDAL and its dependencies. It uses whatever
build system each project uses. CMake is, by far, the most problematic.
Luckily, I can still use the original autotools-based KML.
If I understand correctly, CMake is going to require a complete restructuring
of the proj
Is there a way to invoke that “do all the dependency work for me”
(`find_anyproject`) from the cmake command line?
So if I clone your lib_gdal repo, it could build GDAL and any required
dependencies?
Brad
___
gdal-dev mailing list
gdal-dev@lists.os
Hi Hiroshi,
I tried to test you solution:
$ git clone --depth 1 https://github.com/miurahr/gdal.git
$ cd gdal/
$ mkdir build
$ cd build
$ cmake ..
-- The C compiler identification is AppleClang 9.0.0.938
[ Skipped ...]
CMake Error at
/Applications/CMake.app
Fyi
http://www.opengeospatial.org/pressroom/pressreleases/2656
"The goal of DGGS is to enable rapid assembly of spatial data without the
difficulties of working with projected coordinate reference systems. The OGC
DGGS Abstract Specification standard defines the conceptual model and a set
of rule
Hi,
FYI, in trunk, I've split the GeoJSON driver into 3 distinct GeoJSON, ESRIJSON
and TopoJSON
drivers.
This is to avoid identifying ESRI Json files and ESRI feature service URL, or
TopoJSON files, as
GeoJSON, which is inappropriate. In particular only true GeoJSON files can be
created and
Hi all,
I posted this to the proj4 mailing list and they seem pretty convinced this
is a GDAL problem.
I have tried the September gdal 2.2.2 build as well as the latest GDAL git
build, and finally have them building thanks to Even's help.
However, now GDAL just segfaults within the pj_init_ctx.
Hi,
Ya, certainly feels that way... Probably not possible to get an image, it's
one of Compute Canada's machines, and so not something I am in charge of. I
could probably find out specific details if that helps?
That does correct the problem, thanks!
Cheers
Chris
On 28 October 2017 at 02:17,
FYI, this is one of the shortcomings of WCS 1.x. Remedied in WCS 2.
-Peter
On 10/28/2017 04:39 PM, Ari Jolma wrote:
> jratike80 kirjoitti 28.10.2017 klo 13:10:
>
>> Ari Jolma-2 wrote
>>>
>>> For example this request to a MapServer WCS (I'm not responsible for
>>> that server so don't know much a
Hi,
Dmitry, Thank you for starting the thread.
I'm Hiroshi, a newbie as user and dev of GDAL. I'm OSM mapper.
On 2017/10/28 06:06, Dmitry Baryshnikov wrote:
>
> As Even said it make sense to move discussion from this ticket
> (https://trac.osgeo.org/gdal/ticket/7080) to the list.
>
The ticket (
jratike80 kirjoitti 28.10.2017 klo 13:10:
Ari Jolma-2 wrote
For example this request to a MapServer WCS (I'm not responsible for
that server so don't know much about it), which is generated in the
driver during a DescribeCoverage for the coverage,
http://194.66.252.155/cgi-bin/BGS_EMODnet_bat
Ari Jolma-2 wrote
> Ari Jolma kirjoitti 27.10.2017 klo 19:38:
>>
>>
>> * I'm testing against existing ArcGIS, GeoServer and MapServer servers
>> on the net
>
> Version 1.0.0 seems to be usually understandable/ok but strangeness
> begins with 1.1
>
> For example this request to a MapServer WCS (
Ari Jolma kirjoitti 27.10.2017 klo 19:38:
* I'm testing against existing ArcGIS, GeoServer and MapServer servers
on the net
Version 1.0.0 seems to be usually understandable/ok but strangeness
begins with 1.1
For example this request to a MapServer WCS (I'm not responsible for
that server
Chris,
There must be something unusual with the system you build on. Is it possible to
get an image
of it ?
Anyway, you can probably workaround the issue with
CXXFLAGS="-DDONT_DEPRECATE_SPRINTF" ./configure [...]
Normally configure has a check to automatically define DONT_DEPRECATE_SPRINTF
o
16 matches
Mail list logo
