I've just installed OSGeo4W and am trying to run gdal_merge from the OSGeo4W Shell from a directory other than C.
gdal_merge.py -o output.tif -a_nodata 0 1.tif 2.tif
I also tried: gdal_merge -o output.tif -a_nodata 0 1.tif 2.tif
I receive the following error:
gdal_merge is not recognized as an internal or external command.
I checked several directories in C:\OSGeo4W and I found gdal_merge.py is in C:\OSGeo4W\apps\Python37\Scripts. Do I need to duplicate the .py folder somewhere else? Thanks for your help. I thought gdal_merge should be included in the list of shell commands.
This is an issue I also ran into. It is apparently caused by OSGeo4W installing two Python Environments and in this case it defaults to setting up the wrong one.
You can fix the issue by first calling "py3_env".
This will set up the proper Python environment after which you can call gdal_merge.
Also see this thread dealing with approximately the same issue
I hope that helped!
Issue: gdal_merge.py: not found
Solution
apt install gdal-bin
Test it by simply typing gdal_merge.py on the terminal after installation and it'll show you how to use the utility.
Originally I posted my answer here: https://gis.stackexchange.com/a/449274/217765
I am using TcServer Release 3.1.0 on a Windows Environment, specifically the "cluster-node" template, the problem consist that when I run the command to create the server it's based on tomcat-7, and I need it to be based on tomcat-8, here is the command that I am using it:
tcruntime-instance.bat create myserver1 --template cluster-node
and here is the message that i get from the command prompt:
Applying template 'base-tomcat-7'
Reading on the documentation it says that depends on the tc Runtime version to select between "base-tomcat-7" or "base-tomcat-8" to be used by the instance, so any ideas to make mandatory apply the base-tomcat-8?
Thanks in advance.
That tc Server version defaults to tc Runtime 7. You need to pass in the --version parameter specifying the 8.0.XX version along with the templates you want.
I have a basic Ubuntu server setup and I am attempting to run a CGI script on it but receiving the following error whenever I try running the script via the command line:
CGI will be removed from the Perl core distribution in the next major release. Please install the separate libcgi-pm-perl package. It is being used at /etc/perl/RABX.pm, line 583.
CGI::Util will be removed from the Perl core distribution in the next major release. Please install the separate libcgi-pm-perl package. It is being used at /usr/share/perl/5.20/CGI.pm, line 29.
Status: 400 Bad Request
Content-Type: application/octet-stream
Content-Length: 98
E1:0,3:513,82:No REQUEST_METHOD in environment; this script must be run in a CGI/FastCGI context,N
If I attempt to run the script in the browser I just get a 500 Internal Server Error.
I'm cautious about installing the libcgi-pm-perl package as the CGI script is part of a much larger legacy application that I'm worried will be incompatible with newer packages. I have no idea if this is a real error or more of a warning though.
The bit that really confuses me is the last line. Any advice would be greatly appreciated!
The full script can be seen here: https://github.com/mysociety/writetothem/blob/master/web/services/queue.cgi
Also, apologies if this question is better suited to ServerFault - I wasn't sure where was more appropriate.
whenever I try running the script via the command line
...
this script must be run in a CGI/FastCGI context
You get the error "No REQUEST_METHOD in environment" because you are not running within a CGI context but instead on the command line.
Please install the separate libcgi-pm-perl package
I'm cautious about installing the libcgi-pm-perl package as the CGI script is part of a much larger legacy application that I'm worried will be incompatible with newer packages. I have no idea if this is a real error or more of a warning though.
This is a warning, that you better install libcgi-pm-perl, because CGI.pm will not be included in core perl in the future. The CGI.pm in this package is the same as it was in core perl, so you don't need to worry about having a different module. Of course, it is probably a newer version than you used before. But this was also the case in the past when you used a new perl version.
I'm following the instructions found here.
When I try to run $ heroku pg:psql or $ heroku pg:psql HEROKU POSTGRESQL_BROWN I recieve the following error message:
! The local psql command could not be located ! For help
installing psql, see local-postgresql
I can't find anything useful on the link it gives me (it just links to the instructions I was already using, but further down the page) nor can I find this error anywhere else.
If I've missed anything you need to know to answer this, just let me know. I'm rather new to all this and teaching myself as I go.
I had same error even after installing Postgres locally.
But after seeing this
I saw that "pqsl" was not in the PATH so I then did
PATH=%PATH%;C:\Program Files\PostgreSQL\9.2\bin
which worked for me
I have since solved this myself. When I ran heroku pg:info it says the version number is 9.1.8, I was locally running 9.2
installing 9.1.8 and ensuring Path pointed to the appropriate folder solved the problem.
After you change the path, make sure to restart the terminal!
Set the PATH. To find out the PATH of your psql script (on mac) open the sql shell script from your finder in Applications/Postgres installation. This will give you a hint as to where it is installed. That opened a window which told me it is located here: /Library/PostgreSQL/8.4/scripts/runpsql.sh
Then, I set the PATH variable from the terminal window by typing:
$ PATH="/Library/PostgreSQL/8.4/bin:$PATH"
(depends on the location of your PostgreSQL installation, find your bin path first, another exp: /usr/local/Cellar/postgresql#9.6/9.6.8/bin)
OR.....
You can also connect to the shell by opening the shell directly from your postgres installation folder. Then enter the credentials. If you don't know the credentials, here is how to find them out:
$ heroku pg:info
=== HEROKU_POSTGRESQL_RED_URL (DATABASE_URL)
$ heroku pg:credentials HEROKU_POSTGRESQL_RED_URL
Top answer wouldn't work for me oddly, my system would not add the Path via cmd with administrator access (Not sure why).
So check this > Windows key > environment variables > system variables
And add the last line (your version may differ in the path)
Make sure you've installed the toolbelt as psql is installed by default.
However you also need to ensure you've installed a local copy of PostgreSQL; if you don't the toolbelt will be unable to find the native psql client.
Assuming you have installed a local copy of PostgreSQL, make sure you can execute psql from the command line directly (i.e make sure you PATH is set correctly ). If the command does not execute, check your PATH, if it does execute see if you can connect via the PSQL connection string provided in the Heroku control panel. If you can connect reinstall the toolbelt, if you are unable to connect provision another dev database and try again.
If there are still issues, I would suggest contacting Heroku support for assistance after verifying no API issues are listed on the status page located here.
I got rid if this annoying message on Windows by adding a path element without the spaces, i.e.
C:\Progra~1\PostgreSQL\9.4\data
instead of
“C:\Program Files\PostgreSQL\9.4\data”
I followed the instructions here: http://www.computerhope.com/issues/ch000549.htm, which worked for me if you prefer to go the point-and-click configuration of the PATH variable.
This type of error usually appears in the Windows environment, because if you do not update the PATH after installing Postgresql, heroku pg:psql command does not work.
So you need to update your PATH environment variable to add the bin directory of your Postgres installation. The directory will look like this:
C:\Program Files\PostgreSQL\<VERSION>\bin.
For more information, go to the Heroku in Local setup website:
heroku-postgresql: Local setup
I had the same problem and discovered that Heroku doesn't seem to provision the latest version of PostgreSQL by default. Where the Heroku Getting Started instructions said
heroku addons:create heroku-postgresql:hobby-dev
That provisioned a v10 database for some reason (which you can check by clicking on Heroku Postgres in the Add-ons tab of your dashboard). I deleted that database and provisioned a new database using the --version flag:
heroku addons:create heroku-postgresql:hobby-dev --version 11
As of now, at least, you can find the latest version of Postgres supported by Heroku at this link: https://devcenter.heroku.com/articles/heroku-postgresql#version-support-and-legacy-infrastructure
I'm writing this in early 2019, but according to the PostgreSQL website the next version (12) is "tentatively scheduled" for third quarter of 2019 so if you're reading this in late 2019 potentially the same problem will come up for v12 instead
On Mac you can use the following:
export PATH="/Library/PostgreSQL/12/bin/:$PATH"
The only solution that I found on Windows:
go to advanced system settings
go to environment variables
select Path variable and click Edit
add a new line and enter your bin directory path (C:\Program Files\PostgreSQL<version>\bin) and click ok
restart your terminal
enter your psql command (heroku pg:psql)
I'm trying to give pg_bulkload a try.
When I try to use the postgresql executable it provides, I get the following error:
/usr/local/src/pg_bulkload-3.0.1/bin> ./postgresql start -D /pg_data
server starting
/usr/local/src/pg_bulkload-3.0.1/bin>
FATAL: unrecognized configuration parameter "wal_level"
Google turned up an exact match for this error when someone was using a 9.0 version of psql to run a script on an instance of Postgres 8.4. I don't see how that could be related to my case--I have two versions of Postgres, but I'm sure I'm pointing at the right directory... any thoughts are very welcome.
As far as I can tell from the docs, PostgreSQL 9.x supports a configuration parameter named "wal_level", but version 8.4 does not. The postgresql.conf file for my 9.0.something server has that parameter; the one for my 8.4 server does not.
PostgreSQL 9.x server configuration
PostgreSQL 8.4 server configuration
Your error message suggests you're running version 8.4, but it's reading the configuration file for a 9.x server. Check your postgresql.conf and installation process. I'm thinking pg_bulkload might have "helped" you in ways you didn't anticipate.
I think that it can be a bit tricky to install pg_bulkload to the right place if you have more than one version of PostgreSQL installed on your machine. My first problem was that pg_bulkload (version 3.1.6) could not find pg_port library. I copied the library libpgport.a (a static library) to /usr/local/lib where it was found, but this approach is not recommended, because this is only a quick fix that doesn't work at the end. So, very soon there was another problem: "undefined reference to `pstrdup'". I reckon that in pg_bulkload there should be a possibility of pointing out where PostgreSQL is installed. Well, I changed Makefile of pg_bulkload in pg_bulkload-3.1.6/bin, namely line with PG_LIBS: PG_LIBS = $(libpq) -L/current location of your PostgreSQL/PostgreSQL/pgsql/lib -lpgport -lpgcommon. -lpgport has to be added before -lpgcommon. Last but not least, to compile and install pg_bulkload you shoud modify your PATH: PATH=/current location of your PostgreSQL/PostgreSQL/pgsql/bin:$PATH make USE_PGXS=1 [install]; This makes sure that your pg_bulkload will be added to the correct version of PostgreSQL (in my case 9.3). Enjoy!