Thanks Martin,
I just downloaded configure.in, configure and Makefile.in and now it works.
I still get the conftest2 warning, but that does not matter I guess...(?).
Cheers
Stefan
-Original Message-
From: Martin Landa [mailto:landa.mar...@gmail.com]
Sent: 30. mars 2015 18:28
To: Marku
2015-03-30 18:16 GMT+02:00 Markus Neteler :
> The path changed between G6 and G7, it should be
>
> etc/proj/*
>
> @Martin, is this fixed as well?
yes [1]. Martin
[1]
http://trac.osgeo.org/gdal/browser/branches/1.11/gdal/frmts/grass/pkg/Makefile.in#L30
--
Martin Landa
http://geo.fsv.cvut.cz/gwi
On Mon, Mar 30, 2015 at 5:22 PM, Blumentrath, Stefan
wrote:
...
> I also got an error on “sudo make install”:
>
> cp: cannot stat ‘/usr/local/grass-7.0.1svn/etc/ellipse.table’: No such file
> or directory
>
> make: *** [install] Error 1
The path changed between G6 and G7, it should be
etc/proj/
Does this happen when you use gdal_translate to copy the netcdf file to
another format (say gtiff)?
I am not familiar with c# but there must be a way to compile gdal and you
application to get the exact line of code that causes the crash?
Etienne
On Mon, Mar 16, 2015 at 8:57 AM, Robbie Price wr
Hi,
2015-03-30 17:22 GMT+02:00 Blumentrath, Stefan :
> I just tried to compile the GDAL-GRASS-plugin 1.11.2 against GRASS 7.0.1
> (the release branch).
it should be already fixed in SVN [1], so fixed for upcoming GDAL
1.11.3, see [2]. Martin
[1] http://svn.osgeo.org/gdal/branches/1.11/
[2] http:
On Mon, Mar 30, 2015 at 7:14 AM, Newcomb, Doug wrote:
> +1
>
> The utilities are used by a lot of folks who cannot have compilers loaded
> on their computers for security reasons.
>
> Doug
>
> On Sat, Mar 28, 2015 at 6:06 AM, Damian Dixon
> wrote:
>
>> There are a lot of GIS specialists and geog
Hi,
I just tried to compile the GDAL-GRASS-plugin 1.11.2 against GRASS 7.0.1 (the
release branch).
It seems that there are some issues with the configure /configure.in file in
the plugin
There ".7.0.svn" is hard coded in the library links (while the stable release
puts the libraries in a fold
Hi all,
I recommend that JSON item names match the names of methods of the GDAL
API. If not precisely, then at least in a consistent and predictable way.
Introducing new names increases the amount of needed documentation and
generally sows confusion.
For example, Rasterio's rio-info command (you
Hi Joaquim,
Yes I noted that and have no idea of the problem, I will try to analyze this
asap.
Julien
De : gdal-dev-boun...@lists.osgeo.org [mailto:gdal-dev-boun...@lists.osgeo.org]
De la part de Joaquim Luis
Envoyé : lundi 30 mars 2015 13:31
À : gdal-dev@lists.osgeo.org
Objet : Re: [gdal-dev]
+1
The utilities are used by a lot of folks who cannot have compilers loaded
on their computers for security reasons.
Doug
On Sat, Mar 28, 2015 at 6:06 AM, Damian Dixon
wrote:
> There are a lot of GIS specialists and geographers who are not programmers
> that use the tools to convert or query
Thanks a lot for your advices, my changes are already separated in
different local GIT commits, so I plan to deliver them >into separated
patches/tickets (I already did it for change 7 related to ticket #5291).
Hi Julien,
Please note that I had to reopen #5291 because unfortunately your
Hello,
On 30/03/15 10:20, Even Rouault wrote:
Homme's comments :
>
>> Yes, it would be nice to have support (or the possibility of support)
>> for the
>> information concerning the larger gdal data model. This kind of
high level
>> declarative API is really useful in covering a lot common us
Hi Jukka,
On 30/03/15 09:46, Jukka Rahkonen wrote:
Homme Zwaagstra geodata.soton.ac.uk> writes:
>
>>
>>
>>
>> P.S. on the proposal below, perhaps things could be 'standardised'
>> even more by
>> including the cornerCoordinates in both wgs84 and native coordinate
>> systems
>>
Hi,
(giving my feedback on all comments)
>
> 1: Is there any particular reason to implement XML? Every language has a
> good JSON parser these days, as you note in the RFC XML is more complex to
> implement, and it's not like strict schemas or streaming (usual reasons for
> XML) are going to be
Homme Zwaagstra geodata.soton.ac.uk> writes:
>
>
>
> P.S. on the proposal below, perhaps things could be 'standardised'
> even more by
> including the cornerCoordinates in both wgs84 and native coordinate
> systems
> (much like gdalinfo does at the moment). In this way
Hi Etienne,
Thanks a lot for your advices, my changes are already separated in different
local GIT commits, so I plan to deliver them into separated patches/tickets (I
already did it for change 7 related to ticket #5291).
But I discussed with Even and before deliver the patches I have to add uni
P.S. on the proposal below, perhaps things could be 'standardised' even
more by
including the cornerCoordinates in both wgs84 and native coordinate systems
(much like gdalinfo does at the moment). In this way you can be
guaranteed of
getting geojson output in its default coordinate system.
Hi,
On 29/03/15 23:58, Robert Coup wrote:
Hi,
>
> Good work, thanks for taking this on!
Yes, this will be very useful!
2: In terms of the proposed gdalinfo JSON...
>
> b) personally I'd prefer to be slightly more verbose in attribute
naming. eg. block -> blockSize, colorInterp -> colorInt
18 matches
Mail list logo
